S6720 V200R008C00 Configuration Guide - IP Unicast Routing PDF

S2750&S5700&S6720 Series Ethernet Switches
V200R008C00
Configuration Guide - IP Unicast

Routing
Issue 03
Date 2016-10-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015. 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://e.huawei.com
Issue 03 (2016-10-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Configuration Guide - IP Unicast 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 S2750&S5700&S6720.
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 03 (2016-10-30) Huawei Proprietary and Confidential ii

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.
Security Conventions
l Password setting
Issue 03 (2016-10-30) Huawei Proprietary and Confidential iii

– When configuring a password, the cipher text is recommended. To ensure device

security, change the password periodically.
– When you configure a password in plain text that starts and ends with %^%#, %#
%#, %@%@ or @%@% (the password can be decrypted by the device), the
password is displayed in the same manner as the configured one in the
configuration file. Do not use this setting.
– When you configure a password in cipher text, different features cannot use the
same cipher-text password. For example, the cipher-text password set for the AAA
feature cannot be used for other features.
l Encryption algorithm
Currently, the device uses the following encryption algorithms: 3DES, AES, RSA,
SHA1, SHA2, and MD5. 3DES, RSA and AES are reversible, while SHA1, SHA2, and
MD5 are irreversible. The encryption algorithms DES/3DES/RSA (RSA-1024 or
lower)/MD5 (in digital signature scenarios and password encryption)/SHA1 (in digital
signature scenarios) have a low security, which may bring security risks. If protocols
allowed, using more secure encryption algorithms, such as AES/RSA (RSA-2048 or
higher)/SHA2/HMAC-SHA2, is recommended. The encryption algorithm depends on
actual networking. The irreversible encryption algorithm must be used for the
administrator password, SHA2 is recommended.
l Personal data
Some personal data may be obtained or used during operation or fault location of your
purchased products, services, features, so you have an obligation to make privacy
policies and take measures according to the applicable law of the country to protect
personal data.
l The terms mirrored port, port mirroring, traffic mirroring, and mirroing in this manual
are mentioned only to describe the product's function of communication error or failure
detection, and do not involve collection or processing of any personal information or
communication data of users.
Declaration
This manual is only a reference for you to configure your devices. The contents in the manual,
such as web pages, command line syntax, and command outputs, are based on the device
conditions in the lab. The manual provides instructions for general scenarios, but do not cover
all usage scenarios of all product models. The contents in the manual may be different from
your actual device situations due to the differences in software versions, models, and
configuration files. The manual will not list every possible difference. You should configure
your devices according to actual situations.
The specifications provided in this manual are tested in lab environment (for example, the
tested device has been installed with a certain type of boards or only one protocol is run on
the device). Results may differ from the listed specifications when you attempt to obtain the
maximum values with multiple functions enabled on the device.
Mappings between Product Software Versions and NMS

Versions
The mappings between product software versions and NMS versions are as follows.
Issue 03 (2016-10-30) Huawei Proprietary and Confidential iv

S2750&S5700&S6720 Product eSight

Software Version
V200R008C00 eSight V300R003C20
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 03 (2016-10-30) V200R008C00

This version has the following updates:
Mistakes in the document are corrected.

This version has the following updates:
Some contents are modified according to updates in the product.

Initial commercial release.
Issue 03 (2016-10-30) Huawei Proprietary and Confidential v

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

1 IP Routing Features Supported by the Switches.....................................................................1
2 IP Routing Overview.................................................................................................................... 3
2.1 Introduction to IP Routing.............................................................................................................................................. 4
2.2 Principles........................................................................................................................................................................ 4
2.2.1 Routers and Routing Principles................................................................................................................................... 4
2.2.2 Static Routes and Dynamic Routes............................................................................................................................. 5
2.2.3 Routing Table and FIB Table.......................................................................................................................................6
2.2.4 Route Iteration............................................................................................................................................................. 8
2.2.5 Routing Protocol Preference........................................................................................................................................9
2.2.6 Route Metric.............................................................................................................................................................. 10
2.2.7 Load Balancing and Route Backup........................................................................................................................... 11
2.2.8 IP FRR....................................................................................................................................................................... 12
2.2.9 Route Convergence....................................................................................................................................................13
2.2.10 Default Routes......................................................................................................................................................... 14
2.2.11 Route Importing.......................................................................................................................................................15
2.2.12 Autonomous System................................................................................................................................................15
2.3 FAQ...............................................................................................................................................................................15
2.3.1 Why Communication with the Destination Network Fails After a Route to the Destination Network Is Configured
on a Device?....................................................................................................................................................................... 15
2.4 References.................................................................................................................................................................... 16
3 Static Route Configuration........................................................................................................ 17

3.1 Static Route Overview..................................................................................................................................................18
3.2 Principles...................................................................................................................................................................... 18
3.2.1 Basics of Static Routes.............................................................................................................................................. 18
3.2.2 BFD for Static Routes................................................................................................................................................19
3.2.3 NQA for Static Routes...............................................................................................................................................19
3.2.4 Permanent Advertisement of Static Routes............................................................................................................... 21
3.3 Applications..................................................................................................................................................................23
3.3.1 Load Balancing and Route Backup........................................................................................................................... 23
3.3.2 Default Static Route...................................................................................................................................................24
3.4 Configuration Task Summary.......................................................................................................................................25
Issue 03 (2016-10-30) Huawei Proprietary and Confidential vi

3.5 Default Configuration of Static Routes........................................................................................................................ 27

3.6 Configuring Static Routes............................................................................................................................................ 27
3.6.1 Configuring IPv4 Static Routes................................................................................................................................. 27
3.6.1.1 Creating IPv4 Static Routes....................................................................................................................................27
3.6.1.2 (Optional) Setting the Default Preference Value for IPv4 Static Routes................................................................28
3.6.1.3 (Optional) Configuring Permanent Advertisement of IPv4 Static Routes............................................................. 29
3.6.1.4 (Optional) Preventing a Static Route from Being Selected If the Associated BFD Session Is in AdminDown
State.................................................................................................................................................................................... 29
3.6.1.5 (Optional) Preventing Static Routes from Being Iterated to a Blackhole Route....................................................30
3.6.1.6 Checking the Configuration....................................................................................................................................31
3.6.2 Configuring Static BFD for IPv4 Static Routes........................................................................................................ 31
3.6.3 Associating IPv4 Static Routes with NQA................................................................................................................31
3.6.4 Associating IPv4 Static Routes with EFM................................................................................................................ 33
3.6.5 Configuring IPv6 Static Routes................................................................................................................................. 34
3.6.5.1 Creating IPv6 Static Routes....................................................................................................................................34
3.6.5.2 (Optional) Setting the Default Preference Value for IPv6 Static Routes................................................................35
3.7 Configuration Examples............................................................................................................................................... 36
3.7.1 Example for Configuring IPv4 Static Routes............................................................................................................ 36
3.7.2 Example for Configuring IPv6 Static Routes............................................................................................................ 39
3.7.3 Example for Configuring Static BFD for IPv4 Static Routes................................................................................... 44
3.7.4 Example for Configuring NQA for IPv4 Static Routes.............................................................................................47
3.7.5 Example for Configuring EFM for Static IPv4 Routes............................................................................................. 55
3.8 References.................................................................................................................................................................... 58
4 RIP Configuration....................................................................................................................... 59
4.1 Introduction to RIP....................................................................................................................................................... 60
4.2 Principles...................................................................................................................................................................... 60
4.2.1 RIP Principles............................................................................................................................................................ 60
4.2.2 RIP-2 Enhanced Features.......................................................................................................................................... 62
4.2.3 Split Horizon and Poison Reverse............................................................................................................................. 64
4.2.4 Multi-process and Multi-instance.............................................................................................................................. 65
4.2.5 BFD for RIP...............................................................................................................................................................66
4.2.6 Hot Standby............................................................................................................................................................... 67
4.3 Configuration Task Summary.......................................................................................................................................67
4.4 Configuration Notes..................................................................................................................................................... 71
4.5 Default Configuration...................................................................................................................................................74
4.6 Configuring RIP........................................................................................................................................................... 74
4.6.1 Configuring Basic RIP Functions..............................................................................................................................74
4.6.1.1 Enabling RIP...........................................................................................................................................................74
4.6.1.2 Enabling RIP on the Specified Network Segment..................................................................................................75
4.6.1.3 (Optional) Configuring RIP Neighbors on an NBMA Network............................................................................ 75
4.6.1.4 (Optional) Specifying the RIP Version................................................................................................................... 76
Issue 03 (2016-10-30) Huawei Proprietary and Confidential vii


4.6.2 Configuring RIP-2..................................................................................................................................................... 77
4.6.2.1 Configuring RIP-2 Route Summarization.............................................................................................................. 77
4.6.2.2 Configuring RIP-2 Packet Authentication..............................................................................................................78
4.6.3 Avoiding Routing Loops............................................................................................................................................80
4.6.3.1 Configuring Split Horizon...................................................................................................................................... 80
4.6.3.2 Configuring Poison Reverse................................................................................................................................... 81
4.6.4 Controlling RIP Routing............................................................................................................................................82
4.6.4.1 Configuring RIP Preference................................................................................................................................... 82
4.6.4.2 Configuring Additional Metrics of an Interface..................................................................................................... 82
4.6.4.3 Setting the Maximum Number of Equal-Cost Routes............................................................................................83
4.6.5 Controlling RIP Route Advertisement...................................................................................................................... 84
4.6.5.1 Configuring RIP to Advertise Default Routes........................................................................................................84
4.6.5.2 Disabling an Interface from Sending Update Packets............................................................................................ 85
4.6.5.3 Configuring RIP to Import Routes......................................................................................................................... 86
4.6.6 Controlling Receiving of RIP Routing Information.................................................................................................. 87
4.6.6.1 Disabling an Interface from Receiving RIP Update Packets..................................................................................87
4.6.6.2 Configuring RIP to Deny Host Routes................................................................................................................... 88
4.6.6.3 Configuring RIP to Filter Received Routes............................................................................................................89
4.6.7 Improving RIP Network Performance.......................................................................................................................90
4.6.7.1 Configuring RIP Timers......................................................................................................................................... 90
4.6.7.2 Setting the Interval for Sending Update Packets and Maximum Number of Sent Packets....................................91
4.6.7.3 Enabling replay-protect Function........................................................................................................................... 91
4.6.7.4 Configuring RIP to Check the Validity of Update Packets.................................................................................... 93
4.6.8 Configuring BFD for RIP.......................................................................................................................................... 94
4.6.8.1 Configuring Dynamic BFD for RIP....................................................................................................................... 94
4.6.8.2 Configuring Static BFD for RIP............................................................................................................................. 96
4.6.9 Configuring the Network Management Function for RIP.........................................................................................99
4.7 Maintaining RIP........................................................................................................................................................... 99
4.7.1 Resetting RIP............................................................................................................................................................. 99
4.7.2 Clearing RIP Statistics.............................................................................................................................................100
4.8 Configuration Examples............................................................................................................................................. 100
4.8.1 Example for Configuring Basic RIP Functions....................................................................................................... 100
4.8.2 Example for Configuring RIP to Import Routes..................................................................................................... 104
4.8.3 Example for Configuring One-Arm Static BFD for RIP.........................................................................................108
4.8.4 Example for Configuring Dynamic BFD for RIP....................................................................................................113
Issue 03 (2016-10-30) Huawei Proprietary and Confidential viii

4.9 Common Configuration Errors................................................................................................................................... 118

4.9.1 Failed to Receive RIP Update Packets from Neighbors.......................................................................................... 118
4.9.2 Failed to Send RIP Update Packets to Neighbors....................................................................................................118
4.9.3 Route Flapping Occurs on a RIP Network.............................................................................................................. 119
4.10 References.................................................................................................................................................................119
5 RIPng Configuration.................................................................................................................121
5.1 Introduction to RIPng................................................................................................................................................. 122
5.2 Principles.................................................................................................................................................................... 122
5.2.1 RIPng....................................................................................................................................................................... 122
5.3 Configuration Task Summary.....................................................................................................................................122
5.4 Configuration Notes................................................................................................................................................... 124
5.5 Default Configuration.................................................................................................................................................126
5.6 Configuring RIPng..................................................................................................................................................... 126
5.6.1 Configuring Basic RIPng Functions........................................................................................................................126
5.6.1.1 Enabling RIPng.....................................................................................................................................................127
5.6.1.2 Enabling RIPng on Interfaces...............................................................................................................................127
5.6.1.3 Checking the Configuration..................................................................................................................................128
5.6.2 Avoiding Routing Loops..........................................................................................................................................128
5.6.2.1 Configuring Split Horizon.................................................................................................................................... 129
5.6.2.2 Configuring Poison Reverse................................................................................................................................. 129
5.6.3 Controlling RIPng Routing......................................................................................................................................130
5.6.3.1 Configuring RIPng Preference............................................................................................................................. 130
5.6.3.2 Configuring Additional Metrics of an Interface................................................................................................... 131
5.6.3.3 Setting the Maximum Number of Equal-Cost Routes..........................................................................................132
5.6.4 Controlling RIPng Route Advertisement................................................................................................................ 132
5.6.4.1 Configuring RIPng Route Summarization........................................................................................................... 133
5.6.4.2 Advertising a Default Route................................................................................................................................. 133
5.6.4.3 Configuring a RIPng Process to Import External Routes.....................................................................................134
5.6.4.4 Disabling Sending of RIPng Packets on an Interface...........................................................................................135
5.6.4.5 Disabling Receiving of RIPng Packets on an Interface........................................................................................136
5.6.5 Controlling the Receiving of RIPng Routes............................................................................................................ 137
5.6.6 Improving RIPng Network Performance.................................................................................................................137
5.6.6.1 Configuring RIPng Timers................................................................................................................................... 138
5.6.6.2 Setting the Interval for Sending Update Packets and Maximum Number of Sent Packets..................................139
5.6.6.3 Enabling Zero Field Check for RIPng Packets.....................................................................................................139
5.7 Maintaining RIPng..................................................................................................................................................... 140
5.7.1 Clearing RIPng........................................................................................................................................................ 140
Issue 03 (2016-10-30) Huawei Proprietary and Confidential ix

5.8.1 Example for Configuring RIPng to Filter the Received Routes.............................................................................. 141
5.9 References.................................................................................................................................................................. 145
6 OSPF Configuration..................................................................................................................146
6.1 Introduction to OSPF..................................................................................................................................................147
6.2 Principle......................................................................................................................................................................147
6.2.1 Fundamentals of OSPF............................................................................................................................................ 147
6.2.2 OSPF TE..................................................................................................................................................................158
6.2.3 BFD for OSPF......................................................................................................................................................... 160
6.2.4 OSPF GTSM............................................................................................................................................................161
6.2.5 OSPF Smart-discover.............................................................................................................................................. 162
6.2.6 OSPF VPN...............................................................................................................................................................163
6.2.7 OSPF NSSA............................................................................................................................................................ 170
6.2.8 OSPF Fast Convergence.......................................................................................................................................... 171
6.2.9 Priority-based OSPF Convergence.......................................................................................................................... 172
6.2.10 OSPF-BGP Association.........................................................................................................................................172
6.2.11 OSPF GR............................................................................................................................................................... 173
6.2.12 OSPF-LDP Association......................................................................................................................................... 177
6.2.13 OSPF Database Overflow......................................................................................................................................178
6.2.14 OSPF Mesh-Group................................................................................................................................................ 179
6.3 OSPF Applications..................................................................................................................................................... 181
6.3.1 OSPF GR................................................................................................................................................................. 181
6.3.2 OSPF GTSM............................................................................................................................................................182
6.7 Configuring OSPF...................................................................................................................................................... 189
6.7.1 Configuring Basic OSPF Functions........................................................................................................................ 189
6.7.1.1 Creating an OSPF Process.................................................................................................................................... 189
6.7.1.2 Creating an OSPF Area........................................................................................................................................ 190
6.7.1.3 Enabling OSPF..................................................................................................................................................... 191
6.7.1.4 (Optional) Creating OSPF Virtual Links.............................................................................................................. 192
6.7.1.5 (Optional) Restricting the Flooding of LSA Update Packets............................................................................... 193
6.7.2 Setting Session Parameters for OSPF Neighbor Relationships...............................................................................194
6.7.2.1 Setting the OSPF Packet Retransmission Limit................................................................................................... 195
6.7.2.2 Configuring an Interface to Fill in DD Packets with the Actual MTU................................................................ 195
6.7.3 Configuring OSPF Attributes in Different Types of Networks............................................................................... 196
6.7.3.1 Configuring Network Types of OSPF Interfaces..................................................................................................198
6.7.3.2 Configuring P2MP Network Attributes................................................................................................................199
6.7.3.3 Configuring NBMA Network Attributes..............................................................................................................200
Issue 03 (2016-10-30) Huawei Proprietary and Confidential x

6.7.4 Configuring OSPF Stub Areas................................................................................................................................ 202

6.7.4.1 Defining the Current Area as a Stub Area............................................................................................................ 202
6.7.4.2 (Optional) Configuring Metrics of Default Routes Sent to Stub Areas............................................................... 203
6.7.5 Configuring OSPF NSSA........................................................................................................................................ 204
6.7.6 Adjusting OSPF Route Selection............................................................................................................................ 207
6.7.6.1 Setting the Link Cost for an OSPF Interface........................................................................................................ 207
6.7.6.2 Configuring Equal-Cost Routes............................................................................................................................208
6.7.6.3 Configuring External Route Selection Rules .......................................................................................................210
6.7.7 Controlling OSPF Routing Information.................................................................................................................. 210
6.7.7.1 Configuring OSPF to Import External Routes......................................................................................................211
6.7.7.2 Configuring OSPF to Advertise the Default Route to the OSPF Area.................................................................212
6.7.7.3 Configuring OSPF Route Aggregation.................................................................................................................214
6.7.7.4 Configuring OSPF to Filter the Received Routes................................................................................................ 215
6.7.7.5 Configuring OSPF to Filter the Routes to Be Advertised.................................................................................... 216
6.7.7.6 Configuring the switch to Filter LSAs to Be Sent................................................................................................216
6.7.7.7 Configuring OSPF to Filter ABR Type3 LSA......................................................................................................217
6.7.7.8 (Optional) Enabling the Mesh-Group Function....................................................................................................218
6.7.7.9 Setting the Maximum Number of External LSAs in the LSDB........................................................................... 219
6.7.7.10 Checking the Configuration................................................................................................................................219
6.7.8 Configuring BFD for OSPF.....................................................................................................................................219
6.7.8.1 Configuring Global BFD...................................................................................................................................... 220
6.7.8.2 Configuring BFD for OSPF..................................................................................................................................220
6.7.8.3 (Optional) Preventing an Interface from Dynamically Setting Up a BFD Session..............................................222
6.7.8.4 (Optional) Configuring BFD on the Specified Interface...................................................................................... 223
6.7.9 Configuring OSPF Fast Convergence..................................................................................................................... 224
6.7.9.1 Setting the Convergence Priority of OSPF Routes...............................................................................................225
6.7.9.2 Setting the Interval for Sending Hello Packets.....................................................................................................225
6.7.9.3 Setting the Dead Time of the Neighbor Relationship...........................................................................................226
6.7.9.4 Configuring Smart-discover................................................................................................................................. 227
6.7.9.5 Setting the Interval for Updating LSAs................................................................................................................ 228
6.7.9.6 Setting the Interval for Receiving LSAs...............................................................................................................229
6.7.9.7 Setting the Interval for the SPF Calculation......................................................................................................... 230
6.7.10 Configuring OSPF GR...........................................................................................................................................231
6.7.10.1 Enabling the Opaque-LSA of OSPF...................................................................................................................231
6.7.10.2 (Optional) Configuring the GR Session Parameters on the Restarter................................................................ 232
6.7.10.3 (Optional) Configuring GR Session Parameters on the Helper..........................................................................232
6.7.11 Improving the Stability of an OSPF Network....................................................................................................... 233
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xi

6.7.11.1 Setting the Priority of OSPF............................................................................................................................... 234

6.7.11.2 Configuring the Delay in Transmitting LSAs on the Interface...........................................................................234
6.7.11.3 Configuring the Interval for Retransmitting LSAs............................................................................................. 235
6.7.11.4 Configuring Stub Routers................................................................................................................................... 236
6.7.11.5 Prohibiting an OSPF Interface from Sending and Receiving OSPF Packets..................................................... 236
6.7.12 Improving the Security of an OSPF Network....................................................................................................... 237
6.7.12.1 Configuring the OSPF GTSM Functions........................................................................................................... 238
6.7.12.2 Configuring the Area Authentication Mode....................................................................................................... 239
6.7.12.3 Configuring the Interface Authentication Mode.................................................................................................240
6.7.13 Configuring the Network Management Function of OSPF...................................................................................242
6.7.13.1 Configuring OSPF MIB Binding........................................................................................................................242
6.7.13.2 Configuring OSPF Trap......................................................................................................................................243
6.7.13.3 Configuring OSPF Log.......................................................................................................................................243
6.8 Maintaining OSPF...................................................................................................................................................... 244
6.8.1 Clearing OSPF......................................................................................................................................................... 244
6.8.2 Resetting OSPF........................................................................................................................................................245
6.9.1 Example for Configuring Basic OSPF Functions....................................................................................................245
6.9.2 Example for Configuring OSPF DR Election......................................................................................................... 249
6.9.3 Example for Configuring an OSPF Stub Area........................................................................................................ 254
6.9.4 Example for Configuring an OSPF NSSA.............................................................................................................. 258
6.9.5 Example for Configuring OSPF Load Balancing....................................................................................................263
6.9.6 Example for Configuring OSPF-BGP..................................................................................................................... 268
6.9.7 Example for Configuring OSPF GR........................................................................................................................276
6.9.8 Example for Configuring BFD for OSPF................................................................................................................281
6.10 Common Misconfigurations..................................................................................................................................... 286
6.10.1 OSPF Neighbor Relationship Cannot Be Established........................................................................................... 286
6.10.2 OSPF Cannot Find Routes of a Non-Local Area.................................................................................................. 288
6.11 References.................................................................................................................................................................289
7 OSPFv3 Configuration............................................................................................................. 291

7.1 Introduction to OSPFv3..............................................................................................................................................292
7.2 Principle......................................................................................................................................................................292
7.2.1 Principle of OSPFv3................................................................................................................................................ 292
7.2.2 OSPFv3 GR............................................................................................................................................................. 299
7.2.3 Association between OSPFv3 and BGP.................................................................................................................. 301
7.2.4 Comparison between OSPFv3 and OSPFv2........................................................................................................... 303
7.4 Configuration Notes....................................................................................................................................................311
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xii

7.6 Configuring OSPFv3.................................................................................................................................................. 313

7.6.1 Configuring Basic OSPFv3 Functions.................................................................................................................... 313
7.6.1.1 Enabling OSPFv3................................................................................................................................................. 314
7.6.1.2 Enabling OSPFv3 on an Interface........................................................................................................................ 314
7.6.1.3 Entering the OSPFv3 Area View..........................................................................................................................315
7.6.2 Establishing or Maintaining OSPFv3 Neighbor Relationship.................................................................................317
7.6.2.1 Configuring the Interval for Sending Hello Packets............................................................................................ 317
7.6.2.2 Configuring Dead Time of Neighbor Relationship.............................................................................................. 318
7.6.2.3 Configuring the Interval for Retransmitting LSAs to Neighboring switches.......................................................318
7.6.2.4 Configuring the Delay for Transmitting LSAs on the Interface...........................................................................319
7.6.3 Configuring OSPFv3 Areas.....................................................................................................................................320
7.6.3.1 Configuring OSPFv3 Stub Areas......................................................................................................................... 320
7.6.3.2 Configuring OSPFv3 Virtual Links...................................................................................................................... 321
7.6.4 Configuring OSPFv3 NSSA Areas..........................................................................................................................322
7.6.4.1 Defining the Current Area to Be an NSSA Area..................................................................................................323
7.6.5 Configuring OSPFv3 Route Attributes....................................................................................................................324
7.6.5.1 Setting the Cost of the OSPFv3 Interface.............................................................................................................324
7.6.5.2 Setting the Maximum Number of Equal-Cost Routes..........................................................................................325
7.6.6 Controlling OSPFv3 Routing Information.............................................................................................................. 326
7.6.6.1 Configuring OSPFv3 Route Aggregation.............................................................................................................326
7.6.6.2 Configuring OSPFv3 to Filter the Received Routes............................................................................................ 327
7.6.6.3 Configuring OSPFv3 to Import External Routes................................................................................................. 327
7.6.6.4 (Optional) Configuring OSPFv3 to Filter LSAs in an Area................................................................................. 329
7.6.7 Optimizing an OSPFv3 Network.............................................................................................................................330
7.6.7.1 Configuring the SPF Timer...................................................................................................................................330
7.6.7.2 Suppressing an Interface from Sending and Receiving OSPFv3 Packets............................................................ 331
7.6.7.3 Configuring DR Priority of an Interface...............................................................................................................332
7.6.7.4 Configuring Stub Routers..................................................................................................................................... 333
7.6.7.5 Ignoring MTU Check on DD Packets.................................................................................................................. 333
7.6.8 Configuration OSPFv3 GR......................................................................................................................................334
7.6.8.1 Enabling OSPFv3 GR...........................................................................................................................................335
7.6.8.2 Enabling the Helper of OSPFv3 GR.....................................................................................................................335
7.6.8.3 Check the Configuration.......................................................................................................................................336
7.6.9 Improving OSPFv3 Network Security.................................................................................................................... 336
7.6.9.1 Configuring OSPFv3 GTSM................................................................................................................................ 337
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xiii

7.6.9.2 Configuring an Authentication Mode...................................................................................................................338

7.6.9.3 Checking the Configurations................................................................................................................................ 339
7.6.10 Configuring OSPFv3 IPSec...................................................................................................................................340
7.6.10.1 Configuring Basic IPSec Functions....................................................................................................................340
7.6.10.2 Configuring OSPFv3 IPSec Authentication....................................................................................................... 342
7.6.10.3 Checking the Configurations.............................................................................................................................. 345
7.6.11 Configuring the Network Management Function of OSPFv3............................................................................... 345
7.6.11.1 Configuring OSPFv3 MIB Binding....................................................................................................................345
7.6.11.2 Configuring OSPFv3 Trap..................................................................................................................................346
7.6.11.3 Check the Configuration.....................................................................................................................................346
7.7 Maintaining OSPFv3.................................................................................................................................................. 347
7.7.1 Resetting OSPFv3....................................................................................................................................................347
7.8.1 Example for Configuring OSPFv3 Areas................................................................................................................ 347
7.8.2 Example for Configuring DR Election Through OSPFv3.......................................................................................353
7.8.3 Example for Configuring the OSPFv3 Virtual Link................................................................................................358
7.8.4 Example for Configuring OSPFv3 GR....................................................................................................................362
7.9 References.................................................................................................................................................................. 366
8 IPv4 IS-IS Configuration..........................................................................................................368

8.1 Introduction to IS-IS................................................................................................................................................... 369
8.2 Principles.................................................................................................................................................................... 369
8.2.1 IS-IS Basic Concepts............................................................................................................................................... 369
8.2.2 IS-IS Basic Principles.............................................................................................................................................. 375
8.2.3 IS-IS Authentication................................................................................................................................................ 381
8.2.4 IS-IS Route Leaking................................................................................................................................................ 382
8.2.5 IS-IS Overload......................................................................................................................................................... 383
8.2.6 IS-IS Network Convergence....................................................................................................................................384
8.2.7 IS-IS Administrative Tag.........................................................................................................................................386
8.2.8 IS-IS Wide Metric....................................................................................................................................................387
8.2.9 IS-IS LSP Fragment Extension................................................................................................................................388
8.2.10 IS-IS Host Name Mapping.................................................................................................................................... 391
8.2.11 IS-IS Reliability..................................................................................................................................................... 392
8.2.12 IS-IS GR................................................................................................................................................................ 393
8.2.13 BFD for IS-IS........................................................................................................................................................ 399
8.2.14 IS-IS Auto FRR..................................................................................................................................................... 402
8.2.15 IS-IS TE................................................................................................................................................................. 405
8.2.16 IS-IS Local MT......................................................................................................................................................410
8.2.17 IS-IS Multi-Instance and Multi-Process................................................................................................................ 412
8.6 Configuring IS-IS (IPv4)............................................................................................................................................ 419
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xiv

8.6.1 Configure Basic IS-IS Functions............................................................................................................................. 419

8.6.1.1 Creating IS-IS Processes...................................................................................................................................... 419
8.6.1.2 Configuring a NET............................................................................................................................................... 420
8.6.1.3 Configuring the Device Level.............................................................................................................................. 421
8.6.1.4 Establishing IS-IS Neighbor Relationships.......................................................................................................... 422
8.6.2 Improving IS-IS Network Security..........................................................................................................................426
8.6.2.1 Configuring Interface Authentication...................................................................................................................426
8.6.2.2 Configuring Area or Domain Authentication....................................................................................................... 427
8.6.2.3 Configuring the Optional Checksum.................................................................................................................... 429
8.6.3 Controlling IS-IS Route Selection........................................................................................................................... 430
8.6.3.1 Configuring a Preference Value for IS-IS.............................................................................................................430
8.6.3.2 Configuring the Cost of an IS-IS Interface...........................................................................................................431
8.6.3.3 Configuring Principles for Using Equal-Cost IS-IS Routes................................................................................. 433
8.6.3.4 Configuring IS-IS Route Leaking.........................................................................................................................435
8.6.3.5 Controlling Whether a Level-1 Device Generates a IPv4 Default Route.............................................................436
8.6.4 Controlling IS-IS Route Exchange.......................................................................................................................... 437
8.6.4.1 Configuring IS-IS to Advertise a Default Route.................................................................................................. 437
8.6.4.2 Configuring IS-IS to Import External Routes.......................................................................................................438
8.6.4.3 Configuring IS-IS to Advertise Specified External Routes to an IS-IS Routing Domain....................................439
8.6.4.4 Adding Specified IS-IS Routes to the IP Routing Table...................................................................................... 439
8.6.5 Configuring IS-IS Route Summarization................................................................................................................ 440
8.6.6 Controlling IS-IS Route Convergence.....................................................................................................................441
8.6.6.1 Configuring Attributes for Hello Packets............................................................................................................. 441
8.6.6.2 Configuring Attributes for LSPs...........................................................................................................................443
8.6.6.3 Configuring Attributes for CSNPs....................................................................................................................... 448
8.6.6.4 Setting the SPF Calculation Interval.................................................................................................................... 449
8.6.6.5 Configuring Convergence Priorities for IS-IS Routes..........................................................................................450
8.6.7 Configuring LSP Fragment Extension.................................................................................................................... 451
8.6.8 Configuring a Mesh Group on an NBMA Network................................................................................................ 452
8.6.9 Configuring IS-IS Reliability.................................................................................................................................. 453
8.6.9.1 Configuring Static BFD for IS-IS.........................................................................................................................453
8.6.9.2 Configuring Dynamic BFD for IS-IS................................................................................................................... 455
8.6.9.3 Enabling IS-IS GR................................................................................................................................................457
8.6.10 Configuring the Overload Bit for an IS-IS Device................................................................................................458
8.7 Maintaining IS-IS....................................................................................................................................................... 459
8.7.1 Resetting IS-IS.........................................................................................................................................................459
8.7.2 Improving the Maintainability of IS-IS................................................................................................................... 460
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xv

8.7.3 Configuring the Output of IS-IS Adjacency Status................................................................................................. 461

8.8.1 Example for Configuring Basic IS-IS Functions.....................................................................................................461
8.8.2 Example for Configuring IS-IS Route Aggregation................................................................................................467
8.8.3 Example for Configuring the DIS Election............................................................................................................. 471
8.8.4 Example for Configuring IS-IS Load Balancing..................................................................................................... 478
8.8.5 Example for Configuring Static BFD for IS-IS.......................................................................................................482
8.8.6 Example for Configuring Dynamic BFD for IS-IS................................................................................................. 487
8.8.7 Example for Configuring IS-IS GR.........................................................................................................................494
8.9 Common Configuration Errors................................................................................................................................... 498
8.9.1 Failed to Establish IS-IS Neighbor Relationships................................................................................................... 498
8.9.2 A Device Cannot Learn IS-IS Routes from Its Neighbor........................................................................................499
8.10 References................................................................................................................................................................ 500
9 IPv6 IS-IS Configuration..........................................................................................................502

9.1 Introduction to IS-IS................................................................................................................................................... 503
9.2 Principles.................................................................................................................................................................... 503
9.2.1 IS-IS IPv6................................................................................................................................................................ 503
9.2.2 IS-IS MT..................................................................................................................................................................504
9.6 Configuring IS-IS (IPv6)............................................................................................................................................ 511
9.6.1 Configuring Basic IPv6 IS-IS Functions................................................................................................................. 511
9.6.1.1 Creating IS-IS Processes.......................................................................................................................................511
9.6.1.2 Configuring a NET and Enabling IPv6 IS-IS....................................................................................................... 512
9.6.1.3 Configuring the Device Level.............................................................................................................................. 513
9.6.1.4 Establishing IS-IS Neighbor Relationships.......................................................................................................... 514
9.6.2 Improving IPv6 IS-IS Network Security................................................................................................................. 517
9.6.2.1 Configuring Interface Authentication...................................................................................................................517
9.6.2.2 Configuring Area or Domain Authentication....................................................................................................... 519
9.6.2.3 Configuring the Optional Checksum.................................................................................................................... 520
9.6.3 Controlling IPv6 IS-IS Route Selection.................................................................................................................. 521
9.6.3.1 Configuring a Preference Value for IPv6 IS-IS.................................................................................................... 522
9.6.3.2 Configuring the Cost of an IS-IS Interface on IPv6 network............................................................................... 522
9.6.3.3 Configuring Principles for Using Equal-Cost IPv6 IS-IS Routes........................................................................ 525
9.6.3.4 Configuring IS-IS IPv6 Route Leaking................................................................................................................ 526
9.6.3.5 Controlling Whether a Level-1 Device Generates a IPv6 Default Route.............................................................527
9.6.4 Controlling IPv6 IS-IS Route Exchange................................................................................................................. 528
9.6.4.1 Configuring IS-IS to Advertise a Default Route.................................................................................................. 528
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xvi

9.6.4.2 Configuring IS-IS to Import External Routes.......................................................................................................529

9.6.4.3 Configuring IS-IS to Advertise Specified External Routes to an IS-IS Routing Domain....................................530
9.6.4.4 Adding Specified IS-IS Routes to the IPv6 Routing Table.................................................................................. 530
9.6.5 Configuring IPv6 IS-IS Route Summarization........................................................................................................531
9.6.6 Controlling IPv6 IS-IS Route Convergence............................................................................................................ 532
9.6.6.1 Configuring Attributes for Hello Packets............................................................................................................. 532
9.6.6.2 Configuring Attributes for LSPs...........................................................................................................................534
9.6.6.3 Configuring Attributes for CSNPs....................................................................................................................... 539
9.6.6.4 Setting the SPF Calculation Interval.................................................................................................................... 540
9.6.6.5 Configuring Convergence Priorities for IS-IS Routes..........................................................................................541
9.6.7 Configuring LSP Fragment Extension.................................................................................................................... 542
9.6.8 Configuring a Mesh Group on an NBMA Network................................................................................................ 543
9.6.9 Configuring the Overload Bit for an IS-IS Device..................................................................................................544
9.7 Maintaining IS-IS....................................................................................................................................................... 545
9.7.1 Resetting IS-IS.........................................................................................................................................................545
9.7.2 Improving the Maintainability of IS-IS................................................................................................................... 546
9.7.3 Configuring the Output of IS-IS Adjacency Status................................................................................................. 547
9.8.1 Example for Configuring Basic IS-IS IPv6 Functions............................................................................................ 547
9.9 References.................................................................................................................................................................. 554
10 BGP Configuration..................................................................................................................556
10.1 Introduction to BGP..................................................................................................................................................557
10.2 Principles.................................................................................................................................................................. 557
10.2.1 BGP Concepts........................................................................................................................................................557
10.2.2 BGP Working Principles........................................................................................................................................559
10.2.3 Interaction Between BGP and an IGP................................................................................................................... 561
10.2.4 BGP Security......................................................................................................................................................... 562
10.2.5 BGP Route Selection Rules and Load Balancing..................................................................................................562
10.2.6 Route Reflector......................................................................................................................................................566
10.2.7 BGP Confederation................................................................................................................................................570
10.2.8 Route Summarization............................................................................................................................................ 571
10.2.9 Route Dampening.................................................................................................................................................. 572
10.2.10 BFD for BGP....................................................................................................................................................... 573
10.2.11 BGP Tracking...................................................................................................................................................... 573
10.2.12 BGP GR............................................................................................................................................................... 574
10.2.13 Dynamic Update Peer-Groups............................................................................................................................. 575
10.2.14 MP-BGP.............................................................................................................................................................. 577
10.3 Configuration Task Summary...................................................................................................................................578
10.4 Configuration Notes................................................................................................................................................. 583
10.5 Default Configuration...............................................................................................................................................585
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xvii

10.6 Configuring BGP...................................................................................................................................................... 586

10.6.1 Configuring Basic BGP Functions........................................................................................................................ 586
10.6.1.1 Starting a BGP Process.......................................................................................................................................586
10.6.1.2 Configuring BGP Peers...................................................................................................................................... 587
10.6.1.3 (Optional) Configuring a BGP Peer Group........................................................................................................ 588
10.6.1.4 Configuring BGP to Import Routes....................................................................................................................590
10.6.2 Configuring BGP Security.....................................................................................................................................592
10.6.2.1 Configuring MD5 Authentication...................................................................................................................... 593
10.6.2.2 Configuring Keychain Authentication................................................................................................................593
10.6.2.3 Configuring BGP GTSM....................................................................................................................................594
10.6.3 Simplifying IBGP Network Connections.............................................................................................................. 595
10.6.3.1 Configuring a BGP Route Reflector...................................................................................................................596
10.6.3.2 Configuring a BGP Confederation..................................................................................................................... 597
10.6.4 Configuring BGP Route Selection and Load Balancing....................................................................................... 598
10.6.4.1 Configuring the BGP Priority.............................................................................................................................598
10.6.4.2 Configuring the Next_Hop Attribute..................................................................................................................600
10.6.4.3 Configuring the PrefVal Attribute...................................................................................................................... 601
10.6.4.4 Configuring the Default Local_Pref Attribute....................................................................................................602
10.6.4.5 Configuring the AS_Path Attribute.................................................................................................................... 602
10.6.4.6 Configuring the MED Attribute......................................................................................................................... 605
10.6.4.7 Configuring the BGP Community Attribute...................................................................................................... 606
10.6.4.8 Configuring BGP Load Balancing..................................................................................................................... 608
10.6.5 Controlling the Receiving and Advertisement of BGP Routes............................................................................. 610
10.6.5.1 Configuring a Routing Policy............................................................................................................................. 611
10.6.5.2 Controlling the Advertisement of BGP Routes.................................................................................................. 611
10.6.5.3 Controlling the Receiving of BGP Routes......................................................................................................... 613
10.6.5.4 Configuring BGP Soft Reset.............................................................................................................................. 615
10.6.6 Adjusting the BGP Network Convergence Speed................................................................................................. 617
10.6.6.1 Configuring a BGP ConnectRetry Timer........................................................................................................... 617
10.6.6.2 Configuring BGP Keepalive and Hold Timers...................................................................................................618
10.6.6.3 Configuring a Update Message Timer................................................................................................................620
10.6.6.4 Disabling Rapid EBGP Connection Reset..........................................................................................................620
10.6.6.5 Configuring the BGP Next Hop Delayed Response...........................................................................................621
10.6.6.6 Configuring BGP Route Dampening..................................................................................................................623
10.6.7 Configuring BGP Reliability................................................................................................................................. 624
10.6.7.1 Enabling BGP Tracking......................................................................................................................................625
10.6.7.2 Configuring BFD for BGP................................................................................................................................. 625
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xviii

10.6.7.3 Configuring the BGP GR Function.................................................................................................................... 627

10.6.8 Configuring BGP Route Summarization............................................................................................................... 628
10.6.9 Configuring BGP to Advertise Default Routes to Peers....................................................................................... 629
10.6.10 Configuring MP-BGP..........................................................................................................................................631
10.7 Maintaining BGP...................................................................................................................................................... 632
10.7.1 Configuring Alarm and Clear Alarm Thresholds for the Number of BGP Routes............................................... 632
10.7.2 Resetting BGP Connections.................................................................................................................................. 633
10.7.3 Clearing BGP Statistics......................................................................................................................................... 633
10.8 Configuration Examples........................................................................................................................................... 634
10.8.1 Example for Configuring Basic BGP Functions................................................................................................... 634
10.8.2 Example for Configuring Basic BGP4+ Functions............................................................................................... 640
10.8.3 Example for Configuring Basic MBGP Functions................................................................................................645
10.8.4 Example for Configuring BGP to Interact With an IGP........................................................................................654
10.8.5 Example for Configuring AS-Path Filter...............................................................................................................658
10.8.6 Example for Configuring MED Attributes to Control BGP Route Selection....................................................... 663
10.8.7 Example for Configuring a BGP Route Reflector.................................................................................................668
10.8.8 Example for Configuring a BGP4+ Route Reflection...........................................................................................674
10.8.9 Example for Configuring a BGP Confederation................................................................................................... 679
10.8.10 Example for Configuring the BGP Community Attribute...................................................................................686
10.8.11 Example for Configuring BGP Load Balancing..................................................................................................690
10.8.12 Example for Configuring a BGP Routing Policy................................................................................................ 695
10.8.13 Example for Associating BGP with BFD............................................................................................................715
10.8.14 Example for Configuring BGP GTSM................................................................................................................ 720
10.9 References................................................................................................................................................................ 729
11 Routing Policy Configuration............................................................................................... 731

11.1 Introduction to Routing Policy................................................................................................................................. 732
11.2 Principle.................................................................................................................................................................... 732
11.3 Usage Scenario......................................................................................................................................................... 735
11.4 Configuration Task Summary................................................................................................................................... 736
11.5 Configuration Notes..................................................................................................................................................738
11.6 Configuring Routing Policies................................................................................................................................... 741
11.6.1 Configuring Filters.................................................................................................................................................741
11.6.1.1 Configuring an IP Prefix List..............................................................................................................................741
11.6.1.2 Configuring an AS_Path Filter........................................................................................................................... 742
11.6.1.3 Configuring a Community Filter........................................................................................................................ 742
11.6.1.4 Configuring an Extended Community Filter...................................................................................................... 743
11.6.1.5 Configuring an RD Filter....................................................................................................................................744
11.6.2 Configuring a Routing Policy................................................................................................................................ 744
11.6.2.1 Creating a Routing Policy...................................................................................................................................745
11.6.2.2 (Optional) Configuring an if-match Clause........................................................................................................ 745
11.6.2.3 (Optional) Configuring an apply Clause.............................................................................................................747
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xix

11.6.3 Controlling the Valid Time of Routing Policies.................................................................................................... 749

11.7 Maintaining the Routing Policy................................................................................................................................750
11.8.1 Example for Filtering the Routes to Be Received or Advertised.......................................................................... 751
11.8.2 Example for Applying a Routing Policy for Importing Routes.............................................................................755
11.9 References.................................................................................................................................................................760
12 IP Routing Table Management.............................................................................................761

12.1 Managing IP Routing Tables.................................................................................................................................... 762
12.1.1 Displaying and Maintaining a Routing Table........................................................................................................762
12.1.2 Displaying and Maintaining the Routing Management Module........................................................................... 763
12.1.3 FIB Query and Maintenance..................................................................................................................................764
12.1.4 Configuring IP FRR on the Public Network......................................................................................................... 767
12.1.5 Configuring the ECMP Load Balancing Mode..................................................................................................... 769
12.2.1 Example for Configuring IP FRR on the Public Network.....................................................................................770
13 PBR Configuration.................................................................................................................. 775

13.1 Introduction to Policy-based Routing.......................................................................................................................776
13.2 Configuration Notes................................................................................................................................................. 776
13.3 Configuring PBR...................................................................................................................................................... 778
13.4.1 Example for Configuring PBR Based on IP Addresses........................................................................................ 781
13.4.2 Example for Configuring PBR.............................................................................................................................. 785
13.4.3 Example for Configuring PBR to Import Traffic to the Firewall in Bypass Mode............................................... 789
13.5 FAQ...........................................................................................................................................................................793
13.5.1 Do Huawei Fixed Switches Support PBR?........................................................................................................... 793
13.5.2 How Many PBR-based Routes Do Huawei Switches Support?............................................................................794
13.6 References................................................................................................................................................................ 794
Issue 03 (2016-10-30) Huawei Proprietary and Confidential xx

Configuration Guide - IP Unicast Routing 1 IP Routing Features Supported by the Switches
1 IP Routing Features Supported by the

Switches
This chapter describes IP routing features supported by the switches of different series.
Table 1-1 IP routing features supported by the switches

Featu S2750 S5700 S5700 S5710 S5720 S5720 S5720 S5720 S6720
re S-LI LI -X-LI S-SI SI EI HI EI
Static Suppo Suppo Suppo Suppo Suppo Suppo Suppo Suppo Suppo
routin rted rted rted rted rted rted rted rted rted
g
RIP Not Not Not Not Suppo Suppo Suppo Suppo Suppo
suppo suppo suppor suppor rted rted rted rted rted
rted rted ted ted
RIPng Not Not Not Not Suppo Suppo Suppo Suppo Suppo
rted rted ted ted
OSPF Not Not Not Not Suppo Suppo Suppo Suppo Suppo
rted rted ted ted
OSPF Not Not Not Not Suppo Suppo Suppo Suppo Suppo
v3 suppo suppo suppor suppor rted rted rted rted rted
rted rted ted ted
IS-IS Not Not Not Not Suppo Suppo Suppo Suppo Suppo
(IPv4) suppo suppo suppor suppor rted rted rted rted rted
rted rted ted ted
IS-IS Not Not Not Not Suppo Suppo Suppo Suppo Suppo
(IPv6) suppo suppo suppor suppor rted rted rted rted rted
rted rted ted ted
Issue 03 (2016-10-30) Huawei Proprietary and Confidential 1

Configuration Guide - IP Unicast Routing 1 IP Routing Features Supported by the Switches
Featu S2750 S5700 S5700 S5710 S5720 S5720 S5720 S5720 S6720
re S-LI LI -X-LI S-SI SI EI HI EI
BGP Not Not Not Not Suppo Suppo Suppo Suppo Suppo
rted rted ted ted
Routin Not Not Not Not Suppo Suppo Suppo Suppo Suppo
g suppo suppo suppor suppor rted rted rted rted rted
policy rted rted ted ted
PBR Not Not Not Not Suppo Suppo Suppo Suppo Suppo
rted rted ted ted
NOTE
Only the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI support BFD.
Only the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI support commands with the vpn-
instance parameter.

Configuration Guide - IP Unicast Routing 2 IP Routing Overview
2 IP Routing Overview
About This Chapter
This chapter describes IP routing and how it is a basic element of data communication
networks.
2.1 Introduction to IP Routing
2.2 Principles
2.3 FAQ
2.4 References

2.1 Introduction to IP Routing

According to the destination address, routes are classified into one of the following types:
l Network segment route
The destination is a network segment. In this case, if the destination is an IPv4 address,
the subnet mask is less than 32 bits, and if the destination is an IPv6 address, the prefix
length is less than 128 bits.
l Host route
The destination is a host. In this case, if the destination is an IPv4 address, the subnet
mask is 32 bits, and if the destination is an IPv6 address, the prefix length is 128 bits.
According to whether the destination directly connects to a router, routes are classified into
one of the following types:
l Direct route
The router directly connects to the network where the destination is located.
l Indirect route
The router indirectly connects to the network where the destination is located.
According to the destination address type, routes are classified into one of the following
types:
l Unicast route
The destination address is a unicast address.
l Multicast route
The destination address is a multicast address.
2.2 Principles
2.2.1 Routers and Routing Principles

On the Internet, network connecting devices such as hubs, bridges, switches, and routers
control traffic and ensure data transmission quality. Each of these devices serves a different
role, but for a common purpose: forming a functioning network. The following describes a
router's role in a network, and the purpose and nature of routes.
A router selects routes and forwards packets. Upon receiving a packet, a router selects a
proper path, which may have 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. Optimal route selection depends on 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.
2.2.2 Static Routes and Dynamic Routes

Routers support direct, static, and dynamic routes. Dynamic routes include 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 routing tables, and
guide packet forwarding. Routes are classified into the following types according to their
origin:
l Direct routes: are discovered by link layer protocols.
l Static routes: are manually configured by network administrators.
l Dynamic routes: are discovered by dynamic routing protocols.
Static routes are easy to configure, have low system requirements, and apply to simple, stable,
and small networks. The disadvantage of static routes is that they require subsequent
maintenance as they cannot automatically adapt to network topology changes.
Dynamic routing protocols have routing algorithms. Therefore dynamic routes can
automatically adapt to network topology changes and apply to networks on which Layer 3
devices are deployed. The disadvantages of dynamic routes are that they are complex to
configure, have higher system requirements than static ones, and consume network and
system resources.
Classification of Dynamic Routing Protocols

Dynamic routing protocols are classified into types based on the following two criteria.
According to the application range, dynamic routing protocols are classified into the
following types:
l Interior Gateway Protocols (IGPs)

Run inside an autonomous system (AS), including RIP, OSPF, and IS-IS.
l Exterior Gateway Protocols (EGPs)
Run between ASs, including BGP.
According to the type of algorithm they use, dynamic routing protocols are classified into the
following types:
l Distance-vector routing protocols

Include RIP and BGP. BGP is also called a path-vector protocol.
l Link-state routing protocols
Include OSPF and IS-IS.
The preceding algorithms differ mainly in route discovery and calculation methods.

2.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 (namely, an IP routing table), and each
routing protocol maintains its own routing table.
l Local core routing table

A router uses the local core routing table to store 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.
l Protocol routing table
A protocol routing table stores routing information discovered by the protocol.
A routing protocol can import and advertise routes that are discovered by other routing
protocols. For example, if a router running 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 basic information
about the routing table of the router. The command output is as follows:
<HUAWEI> display ip routing-table
Proto: Protocol Pre: Preference
Route Flags: R - relay, D - download to fib, T - to vpn-instance
------------------------------------------------------------------------------
Routing Table: _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 Vlanif20

10.10.10.0/24 Direct 0 0 D 10.10.10.10 Vlanif20
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 Vlanif20
A routing table contains the following key data for each IP packet:
l Destination: identifies the destination IP address or destination network address of an IP

packet.
l Mask: supplements the destination address to specially identify the address of the
network segment where the destination host or router resides.

The network segment address of a destination host or router is obtained through the
"AND" operation on the destination address and network mask. For example, if the
destination address is 10.1.1.1 and the mask is 255.255.255.0, the address of the network
segment where the host or router resides is 10.1.1.0.
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 2.2.5 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.
In Figure 2-1, the routing table of RouterA shows that it connects to three networks, so it has
three IP addresses and three outbound interfaces.
Figure 2-1 Routing table
Routing Table 10.11.0.0/16

Destination Nexthop Interface
10.11.0.0/16 10.1.1.2 GE1/0/0 RouterB
10.12.0.0/16 10.2.2.2 GE2/0/0 10.1.1.2/24
10.13.0.0/16 10.3.3.2 GE3/0/0
GE1/0/0
10.1.1.1/24
GE2/0/0 GE3/0/0
10.2.2.1/24 3.3.3.1/24
RouterA
RouterC RouterD
10.3.3.2/24
10.2.2.2/24
10.12.0.0/16 10.13.0.0/16

Matching with FIB Table

After selecting an optimal route from the routing table, a router sends it to the FIB table.
When receives a packet, the router compares it against the FIB table to find 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 can also indicate 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 rule.
For example, assume that a router has the following routing table:
Routing Tables:
0.0.0.0/0 Static 60 0 D 192.168.0.2 GigabitEthernet1/0/0
10.20.0.0/16 Direct 0 0 D 172.16.0.1 GigabitEthernet4/0/0
After receiving a packet carrying the destination address 10.9.1.2, 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 192.168.0.2 SU t[37] GigabitEthernet1/0/0
0x0
10.8.0.0/16 192.168.0.2 DU t[37] GigabitEthernet1/0/0
0x0
0x0
0x0
10.20.0.0/16 172.16.0.1 U t[9992] GigabitEthernet4/0/0
0x0
The router performs the "AND" operation on the destination address 19.9.1.2 and the masks
0, 16, and 24 to obtain the network segment addresses: 0.0.0.0/0, 10.9.0.0/16, and 10.9.1.0/24.
The three addresses match three entries in the FIB table. The router chooses the entry
10.9.1.0/24 according to the longest match rule, and forwards the packet through
GigabitEthernet2/0/0.
2.2.4 Route Iteration

Routes can be used to forward traffic only when they have directly connected next hops.
However, this condition may not be met when routes are generated. The system then needs to
search for directly connected next hops and corresponding outbound interfaces. This process
is called route iteration. In most cases, BGP routes, static routes, and user network routes
(UNRs) do not have directly connected next hops, and route iteration is required. The
following examples demonstrate how route iteration generates an FIB entry.
A next-hop IP address of a BGP route is often the IP address of an indirectly connected peer's
loopback interface, and therefore the BGP route needs to be iterated. The system searches the
IP routing table for a direct route (an IGP route in most cases) that is destined for the next-hop

IP address of the BGP route and then adds the next-hop IP address and outbound interface of
the IGP route to the IP routing table. This generates a FIB entry.
A next-hop IP address of a BGP VPN route is often the IP address of an indirectly connected
PE's loopback interface, and the BGP route needs to be iterated to a tunnel. The system
searches the tunnel list for a tunnel that is destined for this loopback IP address and then adds
the tunnel information to the routing table. This generates a FIB entry.
2.2.5 Routing Protocol Preference

Routing protocols (including static routing) may discover different routes to the same
destination, but not all routes are optimal. Only one routing protocol at a time determines the
optimal route to a destination. To select the optimal route, each routing protocol (including
static routing) 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 2-1 lists the default external preferences of
routing protocols.
Table 2-1 Routing protocols and their default external preferences
Routing Protocol or Default External Preference

Route 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 2-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 external preference of all routing protocols except direct routes. The
preference for each static route varies.
Internal preferences of routing protocols cannot be manually configured. Table 2-2 lists the
internal preferences of routing protocols.

Table 2-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. For example, 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:
5. In this case, the router determines the optimal route based on the internal preference listed
in Table 2-2. An OSPF route has an internal preference of 10, and a static route has an
internal preference of 60. This indicates that the OSPF route has a higher preference than the
static route, so the router selects the OSPF route as the optimal route.
2.2.6 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
Path length is the most common factor that affects 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 the 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
just one other router is 1. Other lengths can be deduced in the same manner.
l Network bandwidth
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 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. Continually monitoring the
CPU usage and packets processed per second helps you learn more about network usage.
l Communication cost
The communication cost is 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 are concerned about the operating expenditure.
2.2.7 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, which allows 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 packets' 5-tuple (source IP
address, destination IP address, source port, destination port, and transport protocol). 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 2-2 Networking diagram of load balancing
RouterB
GE1/0/0
10.1.1.0/24
P1～P6 10.1.1.0/24
RouterA 10.2.1.0/24
10.2.1.0/24
P1～P6 RouterD
GE2/0/0
RouterC
In the example shown in Figure 2-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 If RouterA finds that 5-tuple information of P2 destined for 10.1.1.0/24 is the same as
that of P1 destined for 10.1.1.0/24, it forwards P2 and subsequent packets destined for
10.1.1.0/24 through GE1/0/0.
l If RouterA finds that 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, it forwards P1 and subsequent packets destined for
10.2.1.0/24 through GE2/0/0.
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 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.
2.2.8 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 services that are 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 resolves this by ensuring that the forwarding system rapidly detects a link fault and
then uses a backup route to restore services as soon as possible.
IP FRR Classification and Implementation

IP FRR, which is designed for routes on IP networks, is classified into IP FRR on public
networks and IP FRR on private networks.
l IP FRR on public networks protects routers on public networks.
l IP FRR on private networks 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

In the example shown in Figure 2-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 2-3 IP FRR
IP forwarding
Link A PE1
CE1 Link B
IP forwarding
PE2
2.2.9 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 multiple 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 (in descending order of priority). The system then converges routes
according to the assigned scheduling weight to guide service forwarding.
Principles
Routing protocols first compute and deliver routes of high convergence priority to the system.
You can reconfigure the scheduling weight values as required. Table 2-3 lists the default
convergence priorities of public routes.
Table 2-3 Default convergence priorities of public routes

Routing Protocol or Route Type Convergence Priority
Direct high

Routing Protocol or Route Type Convergence Priority
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 priorities of 32-bit OSPF and IS-IS host routes are identified as
medium, and the convergence priorities of the other routes are identified as low.
Priority-based Route Convergence

Figure 2-4 shows a networking arrangement for multicast services. OSPF and IS-IS run on
the network. The receiver connects to RouterA, and 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 10.12.10.0/24. You can set the convergence priority
of route 10.10.10.10/32 to be higher than that of route 10.12.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 2-4 Networking diagram of priority-based route convergence
IS-IS
10.12.10.0/24
OSPF
OSPF
10.10.10.10/32
User RouterA RouterB Source
2.2.10 Default Routes

Default routes are special routes 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.
2.2.11 Route Importing

Different routing protocols using different algorithms may discover different routes. 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 routes discovered by other routing protocols, direct routes,
and static routes.
2.2.12 Autonomous System

An Autonomous System (AS) is a set of IP networks and routers under one administration
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: a 2-
byte AS number (with a number range from 1 to 65535) and a 4-byte AS number (with a
number range from 1 to 4294967295). Available AS numbers can become exhausted thereby
2-byte AS numbers need to be extended to 4-byte AS numbers. A 4-byte AS number is shown
in the X.Y format, where X ranges from 1 to 65535 and Y ranges from 0 to 65535.
Based on the network where they are used, AS numbers are classified into two types. Table
2-4 lists the two types of AS numbers and their ranges.
Table 2-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
2.3 FAQ
2.3.1 Why Communication with the Destination Network Fails

After a Route to the Destination Network Is Configured on a
Device?
As shown in Figure 2-5, TerminalA cannot communicate with ServerB after a route to the
network segment 10.2.2.0/24 of ServerB is configured on SwitchA.

Figure 2-5 Layer 3 communication diagram

G a te w a y G a te w a y
S w itch A S w itch B
N e tw o rk
T e rm in a A S e rve rB
1 0 .1 .1 .1 /2 4 1 0 .2 .2 .1 /2 4
Communication between TerminalA and ServerB is bidirectional. SwitchA must have a route
to 10.2.2.0/24, and SwitchB must have a route to 10.1.1.0/24. After a route to the network
segment 10.2.2.0/24 of ServerB is configured on SwitchA, you also need to configure a route
to the network segment 10.1.1.0/24 of TerminalA on SwitchB. TerminalA and ServerB can
communicate with each other only when they have routes to each other.
2.4 References
None

Configuration Guide - IP Unicast Routing 3 Static Route Configuration
3 Static Route Configuration
About This Chapter
This chapter describes the functions, purposes, and applications of static routes, and explains
how they can be configured.
3.1 Static Route Overview
3.2 Principles
3.3 Applications
3.4 Configuration Task Summary
3.5 Default Configuration of Static Routes
3.6 Configuring Static Routes
3.7 Configuration Examples
3.8 References

3.1 Static Route Overview
Definition
A static route is a fixed route that allows network traffic to reach its target destination.
Typically, static routes are manually configured by network administrators.
Purpose
Static routes are used in different ways on different types of network.
l On simple networks, static routes can be used alone, without the need for dynamic
routes.
l On complex networks, static routes can be used alongside dynamic routes to improve
network performance and ensure bandwidth is available for important applications.
l Static routes associated with VPN instances are used to manage VPN routes.
3.2 Principles
3.2.1 Basics of Static Routes

A router forwards data packets based on routing entries in a routing table. These routing
entries can be manually configured or calculated using dynamic routing protocols. A static
route normally refers to a manually configured route.
Static routes use less bandwidth than dynamic routes and do not use CPU resources for route
calculation and update analysis. When a network fault occurs or the topology changes, static
routes cannot be automatically updated and must be manually reconfigured to adapt to the
network change. A static route has five parameters: destination IP address, mask, outbound
interface, next hop, and preference.
Destination Address and Mask

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

When configuring a static route, depending on the outbound interface type, you need to
specify either an outbound interface or a next-hop IP address.
l For point-to-point (P2P) interfaces, specify an outbound interface. This automatically
sets the IP address of the remote interface connected to the outbound interface as the
next-hop address.

l For non-broadcast multiple access (NBMA) interfaces such as Asynchronous Transfer

Mode (ATM) interfaces, specify a next-hop IP address. This type of interface supports
point-to-multipoint (P2MP) networks and requires mappings between IP addresses and
link-layer addresses to be configured during the configuration of static routes. No
outbound interface needs to be specified.
l For broadcast interfaces (such as Ethernet interfaces) and virtual template (VT)
interfaces, specify a next-hop IP address. Ethernet interfaces are broadcast interfaces,
and VT interfaces can be associated with several virtual access (VA) interfaces. If an
Ethernet interface or a VT interface is specified as the outbound interface, there will be
multiple next hops, and the system will not be able to decide which next hop to use.
Static Route Preference

Different static routes can be configured with different preference values. A smaller
preference value indicates a higher priority. Specifying the same preference value for static
routes with the same destination implements load balancing among these routes. Conversely,
specifying different preference values for static routes with the same destination implements
route backup among the routes. For details, see 3.3.1 Load Balancing and Route Backup.
3.2.2 BFD for Static Routes

Unlike dynamic routes, static routes do not have a dedicated fault detection mechanism. If a
link fault occurs on the network, the administrator needs to rectify it. Bidirectional
Forwarding Detection (BFD) for static routes can be used to bind a static route to a BFD
session so that the BFD session can detect the status of the link associated with the static
route.
l If the BFD session bound to a static route detects a link fault, BFD reports the link fault
to the Routing Management (RM) module. The RM module then sets the route to
inactive, and this route is no longer available in the routing table.
l If the BFD session bound to a static route detects that the faulty link has been re-
established, BFD reports a message to the RM module. The RM module then sets the
route to active, and this route becomes available in the IP routing table once again.
For more details about BFD, see "BFD Configuration - Principles" in Configuration Guide -
Reliability.
3.2.3 NQA for Static Routes

As mentioned previously, static routes do not have a dedicated fault detection mechanism. If a
fault occurs, the corresponding static route will not be automatically deleted from the IP
routing table. This can interrupt services for a significant amount of time. The network
administrator must delete the corresponding static route to allow traffic to switch to an
available path.
This problem requires an effective solution to detect faults in links for static routes. BFD for
static routes is applicable only in situations where both communicating devices support it.
However, if either of the two communicating devices supports Network Quality Analysis
(NQA), NQA for static routes can be used to detect faults.
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. Based on 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 works 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 detects that the link has recovered, the system sets the static route to active. The
route becomes available and is re-added to the IP routing table.
For details about NQA, see "NQA Configuration - Principles" in Configuration Guide -
Network Management and Monitoring.
NOTE
When a static route is associated with an NQA test instance, only ICMP test instances are used to test
whether there are available routes between the source and destination.
Each static route can be associated with only one NQA test instance.
Applications
On the network shown in Figure 3-1, access switches connect to users. Because dynamic
routing protocols are not available for communication between RouterB and users, static
routes are configured on RouterB. To make the network more stable, RouterC is configured
with static routes to the same destination as RouterB, providing backup. 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 configuration is complete, RouterA can use the dynamic routing
protocol to learn from RouterB and RouterC the routes to clients. RouterA uses the link
associated with the static route with the lower cost as the active link, and the other link as the
standby link.
NQA for static routes is also configured on RouterB. NQA tests are performed to check the
active link of RouterB → SwitchA → SwitchC → SwitchD. If the active link fails, the static
route is deleted from the routing table, and traffic diverts to the standby link of RouterC →
SwitchB → SwitchC → SwitchD. If both links are working properly, traffic travels along the
active link.

Figure 3-1 NQA for static routes
IP Network
Router
A
RouterB RouterC
SwitchA SwitchB
......
SwitchC SwitchD
...... ......
Client 1 Client10 Client91 Client100
3.2.4 Permanent Advertisement of Static Routes

Link connectivity determines the stability and availability of a network. Therefore, link
detection plays an important role in network maintenance. BFD cannot be used for link
detection in all scenarios. For example, a simpler method is required for link detection
between different ISPs.
Permanent advertisement of static routes provides a simple, low-cost link detection
mechanism and improves compatibility between Huawei 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 link connectivity.
When permanent advertisement of static routes is configured, 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 in Up or Down state.
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 always be 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 3-2, border routers BR1, BR2, and BR3 belong to ISP1, ISP2, and ISP3
respectively. There are two links between BR1 and BR2, Link A and Link B. However, ISP1
requires that service traffic be forwarded to ISP2 over Link A without traveling through ISP3.
Figure 3-2 Permanent advertisement of static routes
ISP2
BR2
10.1.1.2/24
LinkA
BR1
ISP1
LinkB BR3
ISP3
An External Border Gateway Protocol (EBGP) peer relationship is established between BR1
and BR2, making them BGP peers. For service monitoring purposes, a static route destined
for 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. The network monitoring system periodically pings 10.1.1.2 to determine the
status of Link A.
If Link A is working properly, BR1 forwards ping packets over Link A. If Link A becomes
faulty, the static route is still preferred because permanent advertisement of static routes is
enabled, despite the fact that service traffic can reach BR2 over Link B. BR1 still attempts to
forward ping packets over Link A, but fails. This scenario also applies to BGP packets,
resulting in a link fault that interrupts the BGP peer relationship. The monitoring system
detects service faults as returned in the ping result and prompts maintenance engineers to
rectify the faults before services are affected.

3.3 Applications
3.3.1 Load Balancing and Route Backup

Load Balancing Among Static Routes
To implement load balancing, set the same preference value for different routes to the same
destination, as shown in Figure 3-3.
Figure 3-3 Load balancing among static routes

RouterB
Preference=60
Preference=60
RouterA RouterC
RouterD
Both static routes from RouterA to RouterC have a preference value of 60 and are stored in
the routing table.
Route Backup
To implement route backup, set different preference values for different routes to the same
destination, as shown in Figure 3-4.
Figure 3-4 Route backup

RouterB
Preference=60
Preference=100
RouterA RouterC
RouterD

There are two static routes with different preference values from RouterA to RouterC. Static
route B with next hop RouterB has a smaller value, which signifies a higher preference. The
link associated with static route B functions as the active link. Static route D with next hop
RouterD has a lower preference. The link associated with static route D functions as the
standby link, providing backup in case of a fault occurring on the active link.
l In normal situations, the link associated with static route B is the active link. Static route
B is included in the routing table and is used to forward data. Static route D is not
included in the routing table and is not used to forward data.
l If a fault occurs on the active link, static route B is deleted from the routing table. Static
route D is added to the routing table and is used to forward data.
l When the fault on the active link is resolved, static route B is reactivated, and is once
again used to forward data. Static route D is once again deleted from the routing table
and functions as the backup route.
l Static routes used for backup are also known as floating static routes.
3.3.2 Default Static Route

A default route is a route with the destination IP address set to all 0s. It can be automatically
generated using a routing protocol or manually configured. Manually configured default
routes are called default static routes. Using default static routes can simplify network
configuration. If the destination address of a packet does not match any entries in a router's
routing table, the router forwards the packet along the default route instead.
Figure 3-5 Default static routes
2 RouterB 4
1 5
RouterA RouterC
In Figure 3-5, if no default static route is configured, static routes destined for networks 3, 4,
and 5 must be configured on RouterA, static routes destined for networks 1 and 5 must be
configured on RouterB, and static routes destined for networks 1, 2, and 3 must be configured
on RouterC. Once all of these static routes are configured, RouterA, RouterB, and RouterC
can communicate with each other.
The next hop of packets sent by RouterA to networks 3, 4, and 5 is RouterB. Therefore,
configuring a single default route on RouterA can replace the three static routes destined for
networks 3, 4, and 5. Similarly, configuring a single default route from RouterC to RouterB
can replace the three static routes destined for networks 1, 2, and 3.


You can accurately control route selection on a network by configuring static routes. If static
route functions other than route selection control are required, configure them according to
reference sections. Table 3-1 describes static route configuration tasks.
Table 3-1 Static route configuration tasks

Scenario Description Task
Configuring static routes Static routes are manually l 3.6.1 Configuring IPv4
configured by the Static Routes
administrator to ensure l 3.6.5 Configuring IPv6
normal operations of simple Static Routes
networks and required
bandwidth for important
network applications.

Configuring fault detection In actual networking, static l 3.6.2 Configuring Static

protocols for static routes routes are associated with BFD for IPv4 Static
fault detection protocols to Routes
improve network l 3.6.3 Associating IPv4
performance. Static Routes with
l BFD for static routes: NQA
enables a BFD session to l 3.6.4 Associating IPv4
detect the link status of a Static Routes with
static route and performs EFM
fault detection within
milliseconds. This
compensates for static
routes' lack of a fault
detection mechanism,
and so reduces the
administrator workload.
NOTE
Only the S5720S-SI,
S5720SI, S5720EI,
S5720HI and S6720EI
support BFD for IPv4
static routes.
l Unlike BFD, NQA for
static routes only
requires one end of
interconnected devices to
support NQA and can be
used even if there are
Layer 2 devices. Unlike
ARP, NQA can be used
for all links on a
network. 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, improving
traffic forwarding.
l EFM for static routes:
can be configured to
provide a fault detection
mechanism for static
routes so that the static
routes can detect the link
quality changes in real
time and switch services
immediately.

3.5 Default Configuration of Static Routes

Table 3-2 describes the default configuration of static routes.
Table 3-2 Default configuration of static routes

Parameter Default Setting
Preference of static routes 60
3.6 Configuring Static Routes
Context
Static routes are often used on networks with simple structures. Using static routes can
improve network performance and reduce bandwidth use so that important applications have
access to more bandwidth.
3.6.1 Configuring IPv4 Static Routes
Pre-configuration Tasks
Before configuring IPv4 static routes, configure 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 checking the configuration) as
required and in any sequence.
3.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, depending on the
interface type:
l For point-to-point (P2P) interfaces, specify the outbound interface.
l For non-broadcast multiple access (NBMA) interfaces, specify the next hop.
l For broadcast interfaces (for example, Ethernet interfaces), specify the next hop.
Specifying the same preference value for static routes to the same destination implements load
balancing among these routes. Conversely, specifying different preference values for static
routes to the same destination implements route backup among the routes.

Setting the destination IP address and mask to all 0s configures the default IPv4 static route.
By default, no default IPv4 static route is configured.
Procedure
Step 1 Run:
system-view
The system view is displayed.
Step 2 Configure IPv4 static routes.

l For public networks, 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 ]
An IPv4 static route is configured on the public network.

l For VPN instances, 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 ]
An IPv4 static route is configured on 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.
Only the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI support commands with the vpn-
instance parameter.
----End
3.6.1.2 (Optional) Setting the Default Preference Value for IPv4 Static Routes
Context
The default preference value of IPv4 static routes affects route selection. When an IPv4 static
route is configured without specifying a preference value , the default preference value is
used.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route-static default-preference preference
The default preference value of static routes is set.
The default preference value of static routes is initially set to 60.

NOTE
After the default preference value is reconfigured, the new default preference value is valid only for new
IPv4 static routes.
----End
3.6.1.3 (Optional) Configuring Permanent Advertisement of IPv4 Static Routes
Context
Link connectivity directly affects network stability and availability. Monitoring link status is
an important part of network maintenance. If service traffic needs to be forwarded along a
specified path, you can monitor the status of the path by pinging the destination addresses of
static routes. In this manner, you can monitor services at a very low cost.
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:
ip route-static ip-address { mask | mask-length } { nexthop-address | interface-
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.
NOTE
Only the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI support vpn-instance vpn-instance-
name parameter.
----End
3.6.1.4 (Optional) Preventing a Static Route from Being Selected If the Associated
BFD Session Is in AdminDown State
Context
If the BFD session associated with the switch is in AdminDown state, you can configure the
switch not to select a static route. This ensures that the switch can work together with non-
Huawei devices.
By default, a static route can still be selected by the switch even if the BFD session associated
with it is in AdminDown state. However, this is not the case for non-Huawei devices. As a
result, the switch cannot interwork with non-Huawei devices.

To address this problem, run the ip route-static track bfd-session admindown invalid
command to configure the switch not to select the static route if the associated BFD session is
in AdminDown state.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route-static track bfd-session session-name bfd-name admindown invalid
The switch has been configured not to select the static route if the associated BFD session is
in AdminDown state.
By default, a static route can still be selected by the switch even if the associated BFD session
is in AdminDown state.
----End
3.6.1.5 (Optional) Preventing Static Routes from Being Iterated to a Blackhole

Route
Context
If a link failure occurs on a network with IGP (OSPF for example), static, and blackhole
routes, the static routes may be iterated to the blackhole route to remain active. Static routes
are preferentially selected over OSPF routes because they have a higher priority. Although
active, the static routes are unreachable because they have been iterated to the blackhole
route, resulting in service interruption.
To address this problem, prevent the static routes from being iterated to the blackhole route so
that the OSPF routes will be preferentially selected.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route recursive-lookup blackhole protocol static disable
Static routes are prevented from being iterated to the blackhole route.
By default, static routes can be iterated to a blackhole route.
----End

3.6.1.6 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
3.6.2 Configuring Static BFD for IPv4 Static Routes
Before configuring static BFD for IPv4 static routes, complete the following tasks:
l Configure link layer parameters and IP addresses for interfaces to ensure network-layer
communication between neighbor nodes.
l Configure a BFD session.
For details, see "BFD Configuration" in S2750&S5700&S6720 Series Ethernet Switches
- 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 ]
An IPv4 static route on a public network is associated with a BFD session.
NOTE
Only the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI support BFD for IPv4 static routes.
Before associating a static route with a BFD session, ensure that the BFD session and static route are on
the same link.
----End
Checking the Configuration

Run the following command to check the previous configuration.
l Run the display bfd session all [ verbose ] command to check information about the
BFD session.
3.6.3 Associating IPv4 Static Routes with NQA

Before associating IPv4 static routes with NQA, configure link layer parameters for interfaces
to ensure that the link layer protocol status 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 its view 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, and 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.
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 be used to configure an NQA test instance to start immediately,
at a specified time, or after a specified delay period. You can perform one of the
following operations as required:
– 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 starts immediately.

– 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 will start at a specified time.

– 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 will start after a specified delay period.
8. Run:
quit
Return to the system view.

Step 2 Associate static routes with an NQA test instance.
1. Run:
ip route-static ip-address { mask | mask-length } { nexthop-address |
interface-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 to be associated with an NQA test instance is already associated with a different
NQA test instance, the static route is disassociated from the first NQA test instance once it
becomes associated with the new NQA test instance.
----End

Once IPv4 static routes are associated with NQA, 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.
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.
3.6.4 Associating IPv4 Static Routes with EFM

Background
You can associate Ethernet in the First Mile (EFM) with an IPv4 static route so that the
associated static route can be deleted from the IP routing table when the EFM session of a

specified interface goes Down. Traffic is then switched to a route without link faults to
prevent lengthy service interruptions.
Before associating IPv4 static routes with EFM, set link layer protocol parameters and assign
IP addresses to interfaces to ensure that the link layer protocol status of the interfaces is Up.
Procedure
Step 1 Run:
system-view

Step 2 Run:
type interface-number [ nexthop-address ] } [ preference preference ] track efm-
state interface-type interface-number [ description text ]
EFM is associated with THE IPv4 static route.
----End

l Run the display efm session { all | interface interface-type interface-number command
to check information about EFM OAM on a specified interface.
l Run the display current-configuration | include efm command to check associations
between EFM and IPv4 static routes.
3.6.5 Configuring IPv6 Static Routes
Before configuring IPv6 static routes, configure link layer parameters and IPv6 addresses for
interfaces to ensure network-layer communication between neighbor nodes.
You can perform the following configuration tasks (excluding checking the configuration) as
required and in any sequence.
3.6.5.1 Creating IPv6 Static Routes
Context
When creating IPv6 static routes, you can specify both the outbound interface and next hop.
Alternatively, you can specify only the outbound interface or next hop, depending on the
interface type:
l For point-to-point (P2P) interfaces, specify the outbound interface.
l For non-broadcast multiple access (NBMA) interfaces, specify the next hop.

l For broadcast interfaces, specify the outbound interface. If the next hop address is also
specified, it does not need to be a link-local address.
Specifying the same preference value for IPv6 static routes to the same destination
implements load balancing among these routes. Conversely, specifying different preference
values for IPv6 static routes to the same destination implements route backup among the
routes.
Setting the destination IP address and mask to all 0s configures the default IPv6 static route.
By default, no default IPv6 static route is configured.
Procedure
Step 1 Run:
system-view

l For public networks, run:
ipv6 route-static dest-ipv6-address prefix-length { interface-type interface-
number [ nexthop-ipv6-address ] | nexthop-ipv6-address } [ preference
preference | tag tag ] * [ bfd enable | track { bfd-session cfg-name | nqa
admin-name test-name } ] [ 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 on 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.
Only the the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI supports commands with the vpn-
instance vpn-instance-name parameter.
----End
3.6.5.2 (Optional) Setting the Default Preference Value for IPv6 Static Routes
Context
The default preference value of IPv6 static routes affects route selection. When an IPv6 static
route is configured without specifying a preference value , the default preference value is
used.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipv6 route-static default-preference preference
The default preference value of IPv6 static routes is set.
The default preference value of static routes is initially set to 60.
After the default preference value is reconfigured, the new default preference value 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 the IPv6 routing table.
----End
3.7.1 Example for Configuring IPv4 Static Routes
Networking Requirements
As shown in Figure 3-6, hosts on different network segments are connected using several
Switches. Each two hosts on different network segments can communicate with each other
without using dynamic routing protocols.
Figure 3-6 Networking diagram of configuring IPv4 static routes
PC2
10.1.2.2/24
GE0/0/3
VLANIF40
10.1.2.1/24
GE0/0/1 GE0/0/2
VLANIF10 VLANIF20
10.1.4.2/30 10.1.4.5/30
SwitchB
SwitchA SwitchC
GE0/0/1 GE0/0/1
VLANIF10 VLANIF20
10.1.4.1/30 10.1.4.6/30
GE0/0/2 GE0/0/2
VLANIF30 VLANIF50
10.1.1.1/24 10.1.3.1/24
PC1 PC3
10.1.1.2/24 10.1.3.2/24

Configuration Roadmap
The configuration roadmap is as follows:
1. Create VLANs, add interfaces to the VLANs, and assign IPv4 addresses to VLANIF
interfaces so that neighboring devices can communicate with each other.
2. Configure the IPv4 default gateway on each host, and configure IPv4 static routes or
default static routes on each Switch so that hosts on different network segments can
communicate with each other.
Procedure
Step 1 Create VLANs and add interfaces to the VLANs.
# # Configure SwitchA. The configurations of SwitchB and SwitchC are similar to the
configuration of SwitchA.
<HUAWEI> system-view
[HUAWEI] sysname SwitchA
[SwitchA] vlan batch 10 30
[SwitchA] interface gigabitethernet 0/0/1
[SwitchA-GigabitEthernet0/0/1] port link-type trunk
[SwitchA-GigabitEthernet0/0/1] port trunk allow-pass vlan 10
[SwitchA-GigabitEthernet0/0/1] quit
[SwitchA-GigabitEthernet0/0/2] port link-type access
[SwitchA-GigabitEthernet0/0/2] port default vlan 30
Step 2 Assign IPv4 addresses to the VLANIF interfaces.
# # Configure SwitchA. The configurations of SwitchB and SwitchC are similar to the
[SwitchA] interface vlanif 10
[SwitchA-Vlanif10] ip address 10.1.4.1 30
[SwitchA-Vlanif10] quit
Step 3 Configure hosts.
Set the default gateway addresses of PC1, PC2, and PC3 to 10.1.1.1, 10.1.2.1, and 10.1.3.1
respectively.
Step 4 Configure static routes.
# Configure a default IPv4 route on SwitchA.

[SwitchA] ip route-static 0.0.0.0 0.0.0.0 10.1.4.2
# Configure two IPv4 static routes on SwitchB.

[SwitchB] ip route-static 10.1.1.0 255.255.255.0 10.1.4.1
[SwitchB] ip route-static 10.1.3.0 255.255.255.0 10.1.4.6
# Configure a default IPv4 route on SwitchC.

[SwitchC] ip route-static 0.0.0.0 0.0.0.0 10.1.4.5

Step 5 Verify the configuration.

# Check the routing table on SwitchA.
[SwitchA] display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
0.0.0.0/0 Static 60 0 RD 10.1.4.2 Vlanif10

10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif30
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif30
10.1.4.0/30 Direct 0 0 D 10.1.4.1 Vlanif10
10.1.4.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
# Run the ping command to verify the connectivity.

[SwitchA] ping 10.1.3.1
PING 10.1.3.1: 56 data bytes, press CTRL_C to break
Reply from 10.1.3.1: bytes=56 Sequence=1 ttl=253 time=62 ms
--- 10.1.3.1 ping statistics ---

5 packet(s) transmitted
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.

[SwitchA] tracert 10.1.3.1
traceroute to 10.1.3.1(10.1.3.1), max hops: 30 ,packet length: 40,press CTRL_C
to break
1 10.1.4.2 31 ms 32 ms 31 ms
2 10.1.3.1 62 ms 63 ms 62 ms
----End
Configuration Files
l SwitchA configuration file
#
sysname SwitchA
#
vlan batch 10 30
#
interface Vlanif10
ip address 10.1.4.1 255.255.255.252
#
interface Vlanif30
ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet0/0/1
port link-type trunk
port trunk allow-pass vlan 10
#
port link-type access
port default vlan 30
#

ip route-static 0.0.0.0 0.0.0.0 10.1.4.2

#
return
l SwitchB configuration file

#
sysname SwitchB
#
vlan batch 10 20 40
#
interface Vlanif10
ip address 10.1.4.2 255.255.255.252
#
interface Vlanif20
ip address 10.1.4.5 255.255.255.252
#
interface Vlanif40
ip address 10.1.2.1 255.255.255.0
#
#
#
#
ip route-static 10.1.1.0 255.255.255.0 10.1.4.1
ip route-static 10.1.3.0 255.255.255.0 10.1.4.6
#
return
l SwitchC configuration file

#
sysname SwitchC
#
vlan batch 20 50
#
interface Vlanif20
ip address 10.1.4.6 255.255.255.252
#
interface Vlanif50
ip address 10.1.3.1 255.255.255.0
#
#
#
ip route-static 0.0.0.0 0.0.0.0 10.1.4.5
#
return
3.7.2 Example for Configuring IPv6 Static Routes

Networking requirements
As shown in Figure 3-7, on an IPv6 network, hosts on different network segments are
connected using several Switches. Each two hosts on different network segments can
communicate with each other without using dynamic routing protocols.

Figure 3-7 Networking diagram of configuring IPv6 static routes

PC2
FC00:0:0:2002::2/64
GE0/0/3
VLANIF30
GE0/0/1 FC00:0:0:2002::1/64
GE0/0/2
VLANIF20
VLANIF40
FC00:0:0:2010::2/64
FC00:0:0:2020::1/64
SwitchA SwitchB
SwitchC
GE0/0/1 GE0/0/1
VLANIF20 VLANIF40
FC00:0:0:2010::1/64 FC00:0:0:2020::2/64
GE0/0/2 GE0/0/2
VLANIF10 VLANIF50
FC00:0:0:2001::1/64 FC00:0:0:2003::1/64
PC1 PC3
FC00:0:0:2001::2/64 FC00:0:0:2003::2/64
1. Create VLANs, add interfaces to the VLANs, and assign IPv6 addresses to VLANIF
interfaces so that neighboring devices can communicate with each other.
2. Configure the IPv6 default gateway on each host, and configure IPv6 static routes or
default static routes on each Switch so that hosts on different network segments can
communicate with each other.
Procedure
Step 1 Add interfaces to VLANs.
# Configure SwitchA. The configurations of SwitchB and SwitchC are similar to the
[SwitchA-GigabitEthernet0/0/2] port link-type access
[SwitchA-GigabitEthernet0/0/2] port default vlan 10

[SwitchA] ipv6
[SwitchA-Vlanif10] ipv6 enable

[SwitchA-Vlanif10] ipv6 address fc00:0:0:2001::1/64

Step 3 Configure host addresses and default gateway addresses.

Assign IPv6 addresses to the hosts, and set the default gateway address of PC1, PC2, and PC3
to fc00:0:0:2001::1, fc00:0:0:2002::1, and fc00:0:0:2003::1 respectively.
Step 4 Configure static IPv6 routes.
# Configure a default IPv6 route on SwitchA.
[SwitchA] ipv6 route-static :: 0 vlanif20 fc00:0:0:2010::2
# Configure two IPv6 static routes on SwitchB.

[SwitchB] ipv6 route-static fc00:0:0:2001:: 64 vlanif20 fc00:0:0:2010::1
[SwitchB] ipv6 route-static fc00:0:0:2003:: 64 vlanif40 fc00:0:0:2020::2
# Configure an IPv6 default route on SwitchC.

[SwitchC] ipv6 route-static :: 0 vlanif40 fc00:0:0:2020::1

# Check the IPv6 routing table on SwitchA.
[SwitchA] display ipv6 routing-table
Routing Table : Public
Destination : :: PrefixLength : 0
NextHop : FC00:0:0:2010::2 Preference : 60
Cost : 0 Protocol : Static
RelayNextHop : :: TunnelID : 0x0
Interface : Vlanif20 Flags : D
Destination : ::1 PrefixLength : 128

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

Destination : FC00:0:0:2001::1 PrefixLength : 128

Destination : FC00:0:0:2010:: PrefixLength : 64

Destination : FC00:0:0:2010::1 PrefixLength : 128


Destination : FE80:: PrefixLength : 10

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

[SwitchA] ping ipv6 fc00:0:0:2003::1
PING fc00:0:0:2003::1 : 56 data bytes, press CTRL_C to break
Reply from FC00:0:0:2003::1
bytes=56 Sequence=1 hop limit=63 time = 63 ms
--- fc00:0:0:2003::1 ping statistics ---

0.00% packet loss
# Run the tracert command to verify the connectivity.

[SwitchA] tracert ipv6 fc00:0:0:2003::1
traceroute to fc00:0:0:2003::1 30 hops max,60 bytes packet
1 FC00:0:0:2010::2 31 ms 32 ms 31 ms
2 FC00:0:0:2003::1 62 ms 63 ms 62 ms
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10 20
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:2001::1/64
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:2010::1/64
#
#
#
ipv6 route-static :: 0 Vlanif20 FC00:0:0:2010::2
#
return


#
sysname SwitchB
#
ipv6
#
vlan batch 20 30 40
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:2010::2/64
#
interface Vlanif30
ipv6 enable
ipv6 address FC00:0:0:2002::1/64
#
interface Vlanif40
ipv6 enable
ipv6 address FC00:0:0:2020::1/64
#
#
#
#
ipv6 route-static FC00:0:0:2001:: 64 Vlanif20 FC00:0:0:2010::1
ipv6 route-static FC00:0:0:2003:: 64 Vlanif40 FC00:0:0:2020::2
#
return

#
sysname SwitchC
#
ipv6
#
vlan batch 40 50
#
interface Vlanif40
ipv6 enable
ipv6 address FC00:0:0:2020::2/64
#
interface Vlanif50
ipv6 enable
ipv6 address FC00:0:0:2003::1/64
#
#
#
ipv6 route-static :: 0 Vlanif40 FC00:0:0:2020::1
#
return

3.7.3 Example for Configuring Static BFD for IPv4 Static Routes
As shown in Figure 3-8, SwitchA is connected to the network management system (NMS)
through SwitchB. You need to configure static routes on SwitchA so that SwitchA can
communicate with the NMS. Link fault detection between SwitchA and SwitchB must be at
the millisecond level to improve convergence speed.
Figure 3-8 Networking diagram of configuring static BFD for IPv4 static routes
GE0/0/1 GE0/0/2
VLANIF10 VLANIF20
10.1.1.1/24 10.2.2.2/24
GE0/0/1 10.2.2.1/24
SwitchA VLANIF10 SwitchB NMS
10.1.1.2/24
1. Configure a BFD session between SwitchA and SwitchB to implement link fault
detection at the millisecond level.
2. Configure a static route from SwitchA to the NMS and bind a BFD session to the static
route. This configuration can implement link fault detection at the millisecond level and
improve convergence speed of static routes.
Procedure
Step 1 Add interfaces to the VLANs.
# Configure SwitchA. The configurations of SwitchB are similar to the configuration of
SwitchA.
[SwitchA] vlan 10
[SwitchA-vlan10] quit
Step 2 Assign IP addresses to the VLANIF interfaces.

# Configure SwitchA. The configurations of SwitchB are similar to the configuration of
SwitchA.
Step 3 Configure a BFD session between SwitchA and SwitchB.

# Create a BFD session on SwitchA.

[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bfd aa bind peer-ip 10.1.1.2
[SwitchA-bfd-session-aa] discriminator local 10
[SwitchA-bfd-session-aa] discriminator remote 20
[SwitchA-bfd-session-aa] commit
[SwitchA-bfd-session-aa] quit
# Create a BFD session on SwitchB.

[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] bfd bb bind peer-ip 10.1.1.1
[SwitchB-bfd-session-bb] discriminator local 20
[SwitchB-bfd-session-bb] discriminator remote 10
[SwitchB-bfd-session-bb] commit
[SwitchB-bfd-session-bb] quit
Step 4 Configure a static route and bind the route to the BFD session.
# Configure a default static route to the external network on SwitchA and bind the static route
to the BFD session named aa.
[SwitchA]ip route-static 10.2.2.0 24 10.1.1.2 track bfd-session aa

# After the configuration is complete, run the display bfd session all command on SwitchA
and SwitchB. You can view that the BFD session is established and its status is Up.
Take the display on SwitchA as an example.
[SwitchA] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
10 20 10.1.1.2 Up S_IP_PEER -
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
# Check the IP routing table on SwitchA, and you can find that the static route exists in the
routing table.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.2.2.0/24 Static 60 0 RD 10.1.1.2 Vlanif10
# Run the shutdown command on GE 0/0/1 of SwitchB to simulate a link fault.

[SwitchB] interface gigabitethernet 0/0/1
[SwitchB-GigabitEthernet0/0/1] shutdown
# Check the routing table on SwitchA, and you can find that default route 10.2.2.0/24 does not
exist. The reason is that the default static route is bound to a BFD session, and BFD
immediately notifies that the bound static route is unavailable when a fault is detected.
[SwitchA]display ip routing-table

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

# Run the undo shutdown command on GE0/0/1 of SwitchB to simulate link recovery.
[SwitchB-GigabitEthernet0/0/1]undo shutdown
# Check the routing table on SwitchA, and you can find default route 10.2.2.0/24 in the
routing table. After detecting link recovery, BFD immediately notifies that the bound static
route is reachable.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.2.2.0/24 Static 60 0 RD 10.1.1.2 Vlanif10
----End
Configuration Files
l Switch configuration file
#
sysname SwitchA
#
vlan batch 10
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
#
bfd aa bind peer-ip 10.1.1.2
discriminator local 10
discriminator remote 20
commit
#
ip route-static 10.2.2.0 255.255.255.0 10.1.1.2 track bfd-session aa
#
return

#
sysname SwitchB
#
vlan batch 10 20
#
bfd
#
interface Vlanif10

ip address 10.1.1.2 255.255.255.0

#
interface Vlanif20
ip address 10.2.2.2 255.255.255.0
#
#
#
bfd bb bind peer-ip 10.1.1.1
commit
#
return
3.7.4 Example for Configuring NQA for IPv4 Static Routes

On a company network shown in Figure 3-9, access switches SwitchD and SwitchE connect
to aggregation switches SwitchB and SwitchC in dual-homing mode through static routes to
implement redundancy. The requirements are as follows:
l A detection mechanism is deployed for static routes so that static routes can detect link
faults and traffic can switch from a faulty link to prevent lengthy service interruptions.
l In normal cases, traffic is transmitted along the primary link SwitchB→SwitchD.
l When the primary link becomes faulty, traffic switches to the backup link
SwitchC→SwitchD.
Figure 3-9 NQA for IPv4 static routes
IP Network
SwitchA
VLANIF30 VLANIF40
GE0/0/1 GE0/0/2
VLANIF30 VLANIF40
SwitchB GE0/0/1 GE0/0/1 SwitchC
VLANIF10 VLANIF20
VL 0
GE0/0/3 F6 GE0/0/3
AN
A N I 0 /2
GE IF 5 VL E0/
0 /0 0 G
/2
VLANIF10 0 VL VLANIF20
GE0/0/1 IF 6 AN
GE0/0/1
L A N 0 /0 /2 G E IF 5
V 0/0 0
GE ...... /2
VLANIF70 G VLANIF80
E0
GE0/0/4
/3
GE0/0/4 /0
/0
/3
E0
SwitchD SwitchE
G
...... ......
Client1 Client10 Client91 Client100

Device Name Interface IP Address
VLANIF 30 192.168.3.1/24
SwitchA
VLANIF 40 192.168.4.1/24
VLANIF 30 192.168.3.2/24
SwitchB VLANIF 50 192.168.5.1/24
VLANIF 10 192.168.1.1/24
VLANIF 40 192.168.4.2/24
SwitchC VLANIF 60 192.168.6.1/24
VLANIF 20 192.168.2.1/24
VLANIF 10 192.168.1.2/24
SwitchD VLANIF 60 192.168.6.2/24
VLANIF 70 192.168.7.1/24
VLANIF 20 192.168.2.2/24
SwitchE VLANIF 50 192.168.5.2/24
VLANIF 80 192.168.8.1/24
1. Create an Internet Control Message Protocol (ICMP) NQA test instance to monitor the
status of the primary link.
Create an ICMP NQA test instance on the NQA client SwitchB to test whether the
primary link SwitchB→SwitchD is running properly.
2. Configure static routes and associate the static routes with the NQA test instance.
Configure static routes on aggregation switches SwitchB and SwitchC, and associate the
static route configured on SwitchB with the ICMP NQA test instance. When the ICMP
NQA test instance detects a link fault, it instructs the routing management module to
delete the associated static route from the IPv4 routing table.
3. Configure a dynamic routing protocol. Configure a dynamic routing protocol on
aggregation switches SwitchA, SwitchB, and SwitchC so that they can learn routes from
each other.
4. Configure the dynamic routing protocol to import static routes, and set a higher cost for
the static route used for the backup link than for the static route used for the primary link
to improve link reliability.
Configure the dynamic routing protocol on aggregation switches SwitchB and SwitchC
to import static routes, and set a higher cost for the static route imported by SwitchC than
for the static route imported by SwitchB. This configuration allows SwitchA to
preferentially select the link SwitchB→SwitchD with a lower cost.

Procedure
Step 1 Configure VLANs that each interface belongs to.
# Configure SwitchA. Ensure that the configurations of SwitchB, SwitchC, SwitchD, and
SwitchE are the same as the configuration of SwitchA.
Step 2 Configure an IP address for each VLANIF interface.
Step 3 Create an NQA test instance on SwitchB to test the link between SwitchB and SwitchD.
[SwitchB] nqa test-instance user test
[SwitchB-nqa-user-test] test-type icmp
[SwitchB-nqa-user-test] destination-address ipv4 192.168.1.2
[SwitchB-nqa-user-test] frequency 10
[SwitchB-nqa-user-test] probe-count 2
[SwitchB-nqa-user-test] interval seconds 5
[SwitchB-nqa-user-test] timeout 4
[SwitchB-nqa-user-test] start now
[SwitchB-nqa-user-test] quit
# Configure an IPv4 static route on SwitchB and associate it with the NQA test instance.
[SwitchB] ip route-static 192.168.7.0 255.255.255.0 Vlanif 10 192.168.1.2 track
nqa user test
# Configure an IPv4 static route on SwitchC.

[SwitchC] ip route-static 192.168.7.0 255.255.255.0 Vlanif 60 192.168.6.2
Step 5 Configure a dynamic routing protocol on SwitchA, SwitchB, and SwitchC. OSPF is used in
this example.
# Configure OSPF on SwitchA.

[SwitchA] ospf 1 router-id 10.1.1.1
[SwitchA-ospf-1] area 0.0.0.0
[SwitchA-ospf-1-area-0.0.0.0] network 192.168.3.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Configure OSPF on SwitchB.

[SwitchB] ospf 1 router-id 10.2.2.2

[SwitchB-ospf-1] area 0.0.0.0
[SwitchB-ospf-1-area-0.0.0.0] network 192.168.3.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
# Configure OSPF on SwitchC.

[SwitchC] ospf 1 router-id 10.3.3.3
[SwitchC-ospf-1] area 0.0.0.0
[SwitchC-ospf-1-area-0.0.0.0] network 192.168.4.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] quit
[SwitchC-ospf-1] quit
Step 6 Configure OSPF on SwitchB and SwitchC to import static routes.

# Configure OSPF on SwitchB to import a static route, and set the cost to 10 for the static
route.
[SwitchB] ospf 1
[SwitchB-ospf-1] import-route static cost 10
# Configure OSPF on SwitchC to import a static route, and set the cost to 20 for the static
route.
[SwitchC] ospf 1
[SwitchC-ospf-1] import-route static cost 20

After the configuration is complete, run the display current-configuration | include nqa
command on aggregation switch Switch B in the system view. The command output shows
that the IPv4 static route has been associated with the NQA test instance. Run the display nqa
results command. The command output shows that an NQA test instance has been created.
# Display configurations of NQA for IPv4 static routes.
[SwitchB] display current-configuration | include nqa
ip route-static 192.168.7.0 255.255.255.0 Vlanif10 192.168.1.2 track nqa user test
nqa test-instance user test
# Display NQA test results.

[SwitchB] display nqa results test-instance user test
NQA entry(user, test) :testflag is active ,testtype is icmp

1 . Test 288 result The test is finished
Send operation times: 2 Receive response times: 2
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:192.168.1.2
Min/Max/Average Completion Time: 3/4/3
Sum/Square-Sum Completion Time: 7/25
Last Good Probe Time: 2014-09-09 09:55:38.2
Lost packet ratio: 0 %
The command output shows "Lost packet ratio 0 %," indicating that the link is running
properly.
# Display the routing table on Switch B.
[SwitchB] display ip routing-table

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

192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
192.168.3.0/24 Direct 0 0 D 192.168.3.2 Vlanif30
192.168.3.2/32 Direct 0 0 D 127.0.0.1 Vlanif30
192.168.4.0/24 OSPF 10 2 D 192.168.3.1 Vlanif30
192.168.5.0/24 Direct 0 0 D 192.168.5.1 Vlanif50
192.168.5.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
192.168.7.0/24 Static 60 0 D 192.168.1.2 Vlanif10
# Display the routing table on aggregation switch SwitchA.

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

192.168.3.0/24 Direct 0 0 D 192.168.3.1 Vlanif30
192.168.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif30
192.168.4.0/24 Direct 0 0 D 192.168.4.1 Vlanif40
192.168.4.1/32 Direct 0 0 D 127.0.0.1 Vlanif40
192.168.7.0/24 O_ASE 150 10 D 192.168.3.2 Vlanif30
The command output shows that a route to 192.168.7.0/24 exists in the routing table. The
route's next hop address is 192.168.3.2 and the cost is 10. Traffic is preferentially transmitted
along the link SwitchB -> SwitchD.
# Shut down GigabitEthernet0/0/3 on SwitchB to simulate a link fault.
[SwitchB] interface GigabitEthernet0/0/3
[SwitchB-GigabitEthernet0/0/3] quit
# Display NQA test results.

[SwitchB] display nqa results test-instance user test
NQA entry(user, test) :testflag is active ,testtype is icmp

1 . Test 309 result The test is finished
Send operation times: 2 Receive response times: 0
Completion:failed RTD OverThresholds number: 0
Attempts number:1 Drop operation number:2
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:192.168.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 %
The command output shows "Completion:failed" and "Lost packet ratio is 100 %," indicating
that the link is faulty.
# Display the routing table on SwitchB.

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

192.168.3.0/24 Direct 0 0 D 192.168.3.2 Vlanif30
192.168.3.2/32 Direct 0 0 D 127.0.0.1 Vlanif30
192.168.4.0/24 OSPF 10 2 D 192.168.3.1 Vlanif30
192.168.5.0/24 Direct 0 0 D 192.168.5.1 Vlanif50
192.168.5.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
192.168.7.0/24 O_ASE 150 20 D 192.168.3.1 Vlanif30
The command output shows that the static route has been deleted.
# Display the routing table on SwitchA.
------------------------------------------------------------------------------

192.168.3.0/24 Direct 0 0 D 192.168.3.1 Vlanif30
192.168.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif30
192.168.4.0/24 Direct 0 0 D 192.168.4.1 Vlanif40
192.168.4.1/32 Direct 0 0 D 127.0.0.1 Vlanif40
192.168.7.0/24 O_ASE 150 20 D 192.168.4.2 Vlanif40
The static route has been associated with the NQA test instance on SwitchB. If NQA detects a
link fault, it rapidly notifies SwitchB that the associated static route is unavailable. SwitchA
cannot learn the route to 192.168.7.0/24 from SwitchB. However, SwitchA can learn the route
to 192.168.7.0/24 from SwitchC. The route's next hop address is 192.168.4.2, and the cost is
20. Traffic switches to the link SwitchC -> SwitchD.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 30 40
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
interface Vlanif40
ip address 192.168.4.1 255.255.255.0
#
#
#
ospf 1 router-id 10.1.1.1
area 0.0.0.0

network 192.168.3.0 0.0.0.255

network 192.168.4.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 10 30 50
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.2 255.255.255.0
#
interface Vlanif50
ip address 192.168.5.1 255.255.255.0
#
#
#
#
import-route static cost 10
area 0.0.0.0
network 192.168.3.0 0.0.0.255
#
ip route-static 192.168.7.0 255.255.255.0 Vlanif10 192.168.1.2 track nqa user
test
#
nqa test-instance user test
test-type icmp
destination-address ipv4 192.168.1.2
frequency 10
interval seconds 5
timeout 4
probe-count 2
start now
#
return
#
sysname SwitchC
#
vlan batch 20 40 60
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif40
ip address 192.168.4.2 255.255.255.0
#
interface Vlanif60
ip address 192.168.6.1 255.255.255.0
#
#

#
#
import-route static cost 20
area 0.0.0.0
network 192.168.4.0 0.0.0.255
#
ip route-static 192.168.7.0 255.255.255.0 Vlanif60 192.168.6.2
#
return
l Switch configuration file
#
sysname SwitchD
#
vlan batch 10 60 70
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif60
ip address 192.168.6.2 255.255.255.0
#
interface Vlanif70
ip address 192.168.7.1 255.255.255.0
#
#
#
#
return
l SwitchE configuration file
#
sysname SwitchE
#
vlan batch 20 50 80
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif50
ip address 192.168.5.2 255.255.255.0
#
interface Vlanif80
ip address 192.168.8.1 255.255.255.0
#
#
#


#
return
3.7.5 Example for Configuring EFM for Static IPv4 Routes

As shown in Figure 3-10, SwitchA connects to the NMS across a network segment through
SwitchB. SwitchA and SwitchB need to detect the link quality in real time. When the link
between them becomes faulty, the corresponding static route is deleted from the IP routing
table. Then traffic switches from the faulty link to a normal route to improve network
reliability.
Figure 3-10 Networking for configuring EFM for a static IPv4 route
GE0/0/1 GE0/0/2
VLANIF10 VLANIF20
192.168.1.1/24 192.168.2.2/24
GE0/0/1 192.168.2.1/24
SwitchA VLANIF10 SwitchB NMS
192.168.1.2/24
1. Enable EFM OAM globally and on interfaces of SwitchA and SwitchB to implement
real-time link quality detection.
2. Configure a static route from SwitchA to the NMS and binds the static route to the EFM
state to associate the static route with EFM. When a link where the static routes resides
becomes faulty, traffic switches to a route without link faults.
Procedure
Step 1 Specify the VLAN to which the interfaces belong.
# Configure SwitchA. The configuration of SwitchB is similar to that of SwitchA.
[SwitchA] vlan 10

# Configure SwitchA. The configuration of SwitchB is similar to that of SwitchA.

Step 3 Configure an EFM session between SwitchA and SwitchB.
# Enable EFM OAM on SwitchA.

[SwitchA] efm enable
[SwitchA-GigabitEthernet0/0/1] efm enable
# Enable EFM OAM on SwitchB.

[SwitchB] efm enable
[SwitchB-GigabitEthernet0/0/1] efm enable
[SwitchB-GigabitEthernet0/0/1] quit
Step 4 Configure a static route and bind it to the EFM state.
# Configure a static route from SwitchA to the external network and bind it to the EFM state
of GigabitEthernet0/0/1.
[SwitchA] ip route-static 192.168.2.0 24 192.168.1.2 track efm-state
gigabitethernet0/0/1
# After the configuration is complete, run the display efm session all command on SwitchA
and SwitchB. The command output shows that an EFM session has been set up and in detect
mode. That is, the interface is in handshake state. The following uses the display on SwitchA
as an example.
[SwitchA] display efm session all
Interface EFM State Loopback Timeout
----------------------------------------------------------------------
GigabitEthernet0/0/1 detect --
# Check the IP routing table on SwitchA. The IP routing table contains the static route.
------------------------------------------------------------------------------

192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
192.168.2.0/24 Static 60 0 RD 192.168.1.2 Vlanif10
# Run the undo efm enable command in the view of GigabitEthernet0/0/1 on SwitchB to
simulate a link fault.
[SwitchB-GigabitEthernet0/0/1] undo efm enable
# Run the display efm session all command on SwitchA. The command output shows that the
EFM OAM protocol state is discovery, indicating that the interface is in OAM discovery
state.
----------------------------------------------------------------------
GigabitEthernet0/0/1 discovery --

# Check the IP routing table on SwitchA. The IP routing table does not contain the static route
192.168.2.0/24. This is because the static route is bound to the EFM state. After EFM OAM
detects a link fault, it rapidly notifies SwitchA that the static route is unavailable.
------------------------------------------------------------------------------

192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
# Run the efm enable command in the view of GigabitEthernet0/0/1 on SwitchB to simulate
link recovery.
[SwitchB-GigabitEthernet0/0/1]efm enable
# Run the display efm session all command on SwitchA. The command output shows that the
EFM OAM protocol state is detect, indicating that the interface is in handshake state again.
----------------------------------------------------------------------
GigabitEthernet0/0/1 detect --
# Check the IP routing table on SwitchA. The IP routing table contains the static route
192.168.2.0/24 again. After EFM OAM detects that the link recovers from a fault, it rapidly
notifies that the bound static route is valid again.
------------------------------------------------------------------------------

192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
192.168.2.0/24 Static 60 0 RD 192.168.1.2 Vlanif10
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
efm enable
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#

efm enable
#
ip route-static 192.168.2.0 255.255.255.0 192.168.1.2 track efm-state
GigabitEthernet0/0/1
#
return

#
sysname SwitchB
#
vlan batch 10 20
#
efm enable
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
efm enable
#
#
return
3.8 References
None

Configuration Guide - IP Unicast Routing 4 RIP Configuration
4 RIP Configuration
About This Chapter
This chapter describes how to configure the Routing Information Protocol (RIP). RIP is
widely used on small-sized networks to discover routes and generate routing information.
4.1 Introduction to RIP

4.2 Principles
4.4 Configuration Notes
4.5 Default Configuration
4.6 Configuring RIP
4.7 Maintaining RIP
RIP maintenance includes resetting RIP connections and clearing RIP statistics.
4.9 Common Configuration Errors
4.10 References

4.1 Introduction to 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.
4.2 Principles
4.2.1 RIP 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 4-1 RIP routing table generation

RouterA RouterB
Request
Response

Figure 4-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.

Figure 4-2 Triggered update
The network to
10.4.0.0 fails The network to
10.4.0.0 fails
10.1.0.0
E0 10.2.0.0
RouterB
S0 S0 S1
RouterA
RouterC 10.3.0.0
E0 S0
The network to
10.4.0.0 fails
10.4.0.0
As shown in Figure 4-2, RouterC first learns that network 10.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 10.4.0.0. In
this case, the next hops of the routes from RouterB or RouterC to network 10.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.
4.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 4-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 4-4 shows the packet format.

Figure 4-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 4-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.

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).
4.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 4-5.
Figure 4-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. 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 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.

Figure 4-6 Neighbor-based split horizon
10.0.0.0/8 172.16.0.0/16
RouterA RouterB
RouterC
As shown in Figure 4-6, after split horizon is configured on an NBMA network, RouterA
sends route 172.16.0.0/16 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 4-7 Poison reverse
10.0.0.0/8
RouterA RouterB
As shown in Figure 4-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.
4.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.

4.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 4-1 lists the link fault detection mechanisms and convergence speed before and after
BFD is associated with RIP.
Table 4-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.

Figure 4-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 4-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.
4.2.6 Hot Standby

Devices with distributed architecture support the RIP hot standby feature.
During hot standby, a device backs up RIP data from the active main board (AMB) to the
standby main board (SMB). When the AMB becomes faulty, the SMB becomes active and
takes over the AMB's tasks. This prevents RIP from being affected and ensures normal data
forwarding.

Table 4-2 describes the RIP configuration tasks.

Table 4-2 RIP configuration tasks

Configuring basic RIP Basic RIP functions include 4.6.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.
Configuring RIP-2 features RIP-2 is a classless routing 4.6.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 multi-
authentication modes to
enhance security.

Preventing routing loops RIP is a routing protocol 4.6.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.
Controlling RIP routing To use RIP more flexibly on 4.6.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 4.6.5 Controlling RIP

and receiving of RIP routes meet network requirements, Route Advertisement
you can configure different 4.6.6 Controlling
parameters to accurately Receiving of RIP Routing
control the advertising and Information
receiving of RIP routes.

Improving RIP network In practical applications, 4.6.7 Improving RIP

performance you can configure special Network Performance
RIP 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.

Configuring BFD for RIP In general, RIP maintains 4.6.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.
Configuring the Network By binding RIP to the MIB, 4.6.9 Configuring the
Management Function for you can view RIP Network Management
RIP information and configure Function for RIP
RIP through the NMS.
Involved Network Elements

Other network elements are required to support RIP.
License Support
RIP is not under license control.

Version Support
Table 4-3 Products and minimum version supporting RIP

Series Product Model Minimum Version
Required
S1700 S1720 Not supported
S2700 S2700SI Not supported (The S2700SI

is unavailable in V200R001
and later versions.)
S2700EI Not supported (The

S2700EI is unavailable in
V200R001 and later
versions.)
S2710SI Not supported (The S2710SI

S2720EI V200R009. Supported only

when Layer 3 hardware
forwarding for IPv4 packets
is enabled. To enable this
function, run the assign
forward-mode ipv4-
hardware command.

forward-mode ipv4-
hardware command.
S3700 S3700SI V100R005 (The S3700SI is

unavailable in V200R001
S3700EI V100R005 (The S3700EI is

S3700HI V100R006 (The S3700HI is



Required
S5700 S5700LI/S5700S-LI V200R009. S5700-10P-

PWR-LI-AC/S5700-10P-LI-
AC support RIP only when
Layer 3 hardware
forward-mode ipv4-
hardware command.
S5710-C-LI Not supported (The S5710-

C-LI is unavailable in
V200R002 and later
versions.)
S5710-X-LI V200R009
S5700SI V100R005 (The S5700SI is



S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

Feature Dependencies and Limitations

None.

Table 4-4 describes the default configuration of RIP.
Table 4-4 Default configuration of RIP

Maximum number of equal-cost routes 8
RIP function Disabled
Split horizon Enabled
4.6 Configuring RIP
4.6.1 Configuring Basic RIP Functions
Before configuring basic RIP functions, configure 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.
4.6.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
4.6.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.
a. Run the system-view command to enter the system view.
b. Run the rip [ process-id ] command to enter the RIP view.
c. (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.
d. 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.
----End
4.6.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
The RIP neighbor is configured.
----End
4.6.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.
c. 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.
b. Run the interface interface-type interface-number command to enter the interface
view.
c. (Optional) On an Ethernet interface, run:
undo portswitch
The interface is switched to Layer 3 mode.
By default, an Ethernet interface works in Layer 2 mode.

NOTE
Only the S5720HI, S5720EI, and S6720EI support switching between Layer 2 and Layer 3
modes.
d. 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-namevpn-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
4.6.2 Configuring RIP-2
Before configuring RIP-2, configure basic RIP functions.
You can perform the following configuration tasks (excluding the task of Checking the
Configuration) in any sequence as required.
4.6.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.
c. Run the version 2 command to set the RIP version to RIP-2.
d. Run the summary command to enable automatic route summarization.
e. (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.
b. Run the interface interface-type interface-number command to enter the interface
view.
undo portswitch

NOTE
modes.
d. 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
4.6.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 (Optional) On an Ethernet interface, run:

undo portswitch

NOTE
Only the S5720HI, S5720EI, and S6720EI support switching between Layer 2 and Layer 3 modes.
Step 4 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 }
NOTICE
Simple and MD5 authentication has potential risks. HMAC-SHA256 cipher text
authentication is recommended.
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).
Only the S5720EI, S5720HI and S6720EI support keychain keychain-name.

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 | vpn-instance vpn-instance-name ] command to view
the running status and configurations of RIP.
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
4.6.3 Avoiding Routing Loops
Before configuring split horizon and poison reverse, configure basic RIP functions.
4.6.3.1 Configuring Split Horizon
Context
Split horizon can prevent routing loops.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch


NOTE
Step 4 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
4.6.3.2 Configuring Poison Reverse
Context
Poison reverse can prevent routing loops.
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 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
4.6.4 Controlling RIP Routing
Before configuring RIP route attributes, configure basic RIP functions.
4.6.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
4.6.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.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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 but affects route selection on other devices in the network.
----End
4.6.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. The default value is 8.
----End
Procedure
devices.
----End
4.6.5 Controlling RIP Route Advertisement
Before controlling RIP route advertisement, configure basic RIP functions.
4.6.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 ]

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
4.6.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
a. Run:
system-view

b. Run:
rip [ process-id ]

c. 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
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. 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
4.6.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.

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
4.6.6 Controlling Receiving of RIP Routing Information
Before controlling receiving of RIP routing information, configure basic RIP functions.
4.6.6.1 Disabling an Interface from Receiving RIP Update Packets
Context
Routing loops can be avoided by disabling interfaces from receiving Update packets.

Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 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
4.6.6.2 Configuring RIP to Deny Host Routes
Context
In certain cases, the switch 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 switch 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 switch.

NOTE
The undo host-route command is invalid for RIP-2.
----End
4.6.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.
l Run the display rip process-id route command to check all the RIP routes that are
learned from other switches.
----End
4.6.7 Improving RIP Network Performance
Before improving RIP network performance, configure basic RIP functions.
4.6.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 switch 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.
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
4.6.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:

undo portswitch

NOTE
Step 4 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
4.6.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 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:

undo portswitch

NOTE
Step 4 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 5 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

4.6.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.
Procedure
l Configure the zero field check for RIPv1 packets.
a. Run:
system-view

b. Run:
rip [ process-id ]

c. 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.
a. Run:
system-view

b. Run:
rip [ process-id ]

c. 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
4.6.8 Configuring BFD for RIP
Before configuring BFD for RIP, configure basic RIP functions.
You can perform the following configuration tasks in any sequence as required.
4.6.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.
a. Run:
system-view

b. Run:
bfd

BFD is enabled globally.

c. Run:
quit

d. Run:
rip [ process-id ]

e. 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.
f. (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.
n If links have a high reliability requirement, reduce the interval at which BFD
packets are sent.
n 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.
g. (Optional) Perform the following operations to prevent an interface in the RIP
process from establishing a BFD session:
n Run the quit command to return to the system view.
n Run the interface interface-type interface-number command to enter the view
of a specified interface.
n Run the rip bfd block command to prevent the interface from establishing a
BFD session.
l Enable BFD on RIP interfaces.
a. Run:
system-view

b. Run:
bfd

c. Run:
quit

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

e. (Optional) On an Ethernet interface, run:
undo portswitch

NOTE
modes.
f. Run:
rip bfd enable
BFD is enabled on the interface to establish a BFD session.

g. (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
switch is displayed Up.
4.6.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

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

address.
2. Set discriminators.
– Run:
The local discriminator is set.

– Run:
discriminator remote discr-value
The remote discriminator is set.
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. (Optional) On an Ethernet interface, run:
undo portswitch

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

4. 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.
4.6.9 Configuring the Network Management Function for RIP
Before configuring the network management function for RIP, configure basic RIP
functions.
Procedure
Step 1 Run:
system-view

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.
4.7 Maintaining RIP

RIP maintenance includes resetting RIP connections and clearing RIP statistics.
4.7.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
4.7.2 Clearing RIP Statistics

Context
NOTICE
RIP information cannot be restored after it is cleared. Exercise caution when running the
commands.
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
4.8.1 Example for Configuring Basic RIP Functions

As shown in Figure 4-9, SwitchA, SwitchB, SwitchC, and SwitchD are located on a small-
sized network, and they need to communicate with each other.

Figure 4-9 Networking diagram for configuring the RIP version

SwitchC
GE0/0/2
VLANIF20
172.16.1.2/24
GE0/0/2
GE0/0/1 VLANIF20 GE0/0/3
VLANIF10 172.16.1.1/24 VLANIF30
192.168.1.1/24 10.1.1.2/24
GE0/0/1 GE0/0/3
SwitchA VLANIF10 SwitchB VLANIF30 SwitchD
192.168.1.2/24 10.1.1.1/24
The network size is small, so RIP-2 is recommended. The configuration roadmap is as
follows:
1. Configure VLAN and IP address for each interface to ensure network reachability.
2. Enable RIP on each switch to implement network connections between processes.
3. Configure RIP-2 on each switch to improve RIP performance.
Procedure
Step 1 Configure VLANs that the related interfaces belong to. The configurations of Switch B,
Switch C, and Switch D are similar to the configuration of Switch A, and are not mentioned
here.
[SwitchA] vlan 10
Step 2 Configure an IP address to each VLANIF interface. The configurations of Switch B, Switch
C, and Switch D are similar to the configuration of Switch A, and are not mentioned here.
Step 3 Configure the basic RIP functions.

# Configure Switch A.
[SwitchA] rip
[SwitchA-rip-1] network 192.168.1.0
[SwitchA-rip-1] quit
# Configure Switch B.

[SwitchB] rip
[SwitchB-rip-1] network 192.168.1.0
[SwitchB-rip-1] quit
# Configure Switch C.
[SwitchC] rip
[SwitchC-rip-1] network 172.16.0.0
[SwitchC-rip-1] quit
# Configure Switch D.
[SwitchD] rip
[SwitchD-rip-1] network 10.0.0.0
[SwitchD-rip-1] quit
# Check the RIP routing table of Switch A.

[SwitchA] display rip 1 route
Route Flags : R - RIP
A - Aging, G - Garbage-collect
----------------------------------------------------------------------------
Peer 192.168.1.2 on Vlanif10
Destination/Mask Nexthop Cost Tag Flags Sec
172.16.0.0/16 192.168.1.2 1 0 RA 14
10.0.0.0/8 192.168.1.2 1 0 RA 14
From the routing table, you can find that the routes advertised by RIP-1 use natural masks.
Step 4 Configure the RIP version.
# Configure RIPv2 on Switch A.
[SwitchA] rip
[SwitchA-rip-1] version 2
# Configure RIPv2 on Switch B.

[SwitchB] rip
[SwitchB-rip-1] version 2
# Configure RIPv2 on Switch C.

[SwitchC] rip
[SwitchC-rip-1] version 2
# Configure RIPv2 on Switch D.

[SwitchD] rip
[SwitchD-rip-1] version 2

# Check the RIP routing table of Switch A.
[SwitchA] display rip 1 route
Route Flags : R - RIP
----------------------------------------------------------------------------
Peer 192.168.1.2 on Vlanif10
Destination/Mask Nexthop Cost Tag Flags Sec
172.16.1.0/24 192.168.1.2 1 0 RA 32
10.1.1.0/24 192.168.1.2 1 0 RA 32

From the routing table, you can find that the routes advertised by RIP-2 contain more accurate
subnet masks.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
#
rip 1
version 2
network 192.168.1.0
#
return

#
sysname SwitchB
#
vlan batch 10 20 30
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif20
ip address 172.16.1.1 255.255.255.0
#
interface Vlanif30
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

#
sysname SwitchC
#
vlan batch 20
#

interface Vlanif20
ip address 172.16.1.2 255.255.255.0
#
#
rip 1
version 2
network 172.16.0.0
#
return
l SwitchD configuration file

#
sysname SwitchD
#
vlan batch 30
#
interface Vlanif30
ip address 10.1.1.2 255.255.255.0
#
#
rip 1
version 2
network 10.0.0.0
#
return
4.8.2 Example for Configuring RIP to Import Routes
As shown in Figure 4-10, two RIP processes, RIP100 and RIP200, run on SwitchB. SwitchA
needs to communicate with network segment 192.168.3.0/24.
Figure 4-10 Network diagram of configuring RIP to import external routes
GE0/0/1 GE0/0/2
VLANIF50 VLANIF30
192.168.0.1/24 192.168.3.1/24
GE0/0/2 GE0/0/1
VLANIF10 VLANIF20
192.168.2.1/24 GE0/0/3
192.168.1.2/24
GE0/0/2 GE0/0/1 VLANIF40
VLANIF10 VLANIF20 192.168.4.1/24
SwitchA 192.168.1.1/24 SwitchB 192.168.2.2/24 SwitchC
RIP 100 RIP 200


2. Import routes between RIP100 and RIP200 on SwitchB and set the default metric of
routes imported from RIP200 to 3.
3. Configure an ACL on SwitchB to filter route 192.168.4.0/24 imported from RIP200 so
that SwitchA can only communicate with network segment 192.168.3.0/24.
Procedure
Step 1 Configure VLANs that the related interfaces belong to.The configurations of Switch B, and
Switch C are similar to the configuration of Switch A, and are not mentioned here.
Step 2 Configure an IP address to each VLANIF interface. The configurations of Switch B, and
Switch C are similar to the configuration of Switch A, and are not mentioned here.
Step 3 Configure the basic RIP functions.

# Enable RIP process 100 on SwitchA.
[SwitchA] rip 100
# Enable RIP processes 100 and 200 on SwitchB.

[SwitchB] rip 100
[SwitchB] rip 200
# Enable RIP process 200 on SwitchC.

[SwitchC] rip 200
# View the routing table on SwitchA.

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


192.168.0.0/24 Direct 0 0 D 192.168.0.1 Vlanif50
192.168.0.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
The routing table of SwitchA does not contain the routes imported from other processes.
Step 4 Configure RIP to import external routes.
# On SwitchB, set the default metric of imported routes to 3 in RIP 100 process and configure
the RIP processes to import routes into each other's routing table.
[SwitchB] rip 100
[SwitchB-rip-100] default-cost 3
[SwitchB-rip-100] import-route rip 200
[SwitchB] rip 200
[SwitchB-rip-200] import-route rip 100
# View the routing table of SwitchA after the routes are imported.
------------------------------------------------------------------------------

192.168.0.0/24 Direct 0 0 D 192.168.0.1 Vlanif50
192.168.0.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
192.168.2.0/24 RIP 100 4 D 192.168.1.2 Vlanif10
192.168.3.0/24 RIP 100 4 D 192.168.1.2 Vlanif10
192.168.4.0/24 RIP 100 4 D 192.168.1.2 Vlanif10
The routing table of SwitchA contains routes 192.168.2.0/24, 192.168.3.0/24, and

192.168.4.0/24, which are learned by RIP200 on SwitchB.
Step 5 Configure RIP to filter imported routes.
# Configure an ACL on SwitchB and add a rule to the ACL. The rule denies the packets sent
from 192.168.4.0/24.
[SwitchB] acl 2000
[SwitchB-acl-basic-2000] rule deny source 192.168.4.0 0.0.0.255
[SwitchB-acl-basic-2000] rule permit
[SwitchB-acl-basic-2000] quit
# Configure SwitchB to filter route 192.168.4.0/24 imported from RIP200.

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

# Display the RIP routing table of SwitchA after the routes are filtered.

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

192.168.0.0/24 Direct 0 0 D 192.168.0.1 Vlanif50
192.168.0.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Vlanif10
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
192.168.2.0/24 RIP 100 4 D 192.168.1.2 Vlanif10
192.168.3.0/24 RIP 100 4 D 192.168.1.2 Vlanif10
The routing table of SwitchA does not contain the route originating from 192.168.4.0/24.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 50
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Vlanif50
ip address 192.168.0.1 255.255.255.0
#
#
#
rip 100
network 192.168.0.0
network 192.168.1.0
#
return

#
sysname SwitchB
#
vlan batch 10 20
#
acl number 2000
rule 5 deny source 192.168.4.0 0.0.0.255
rule 10 permit
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif20
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 SwitchC
#
vlan batch 20 30 40
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
interface Vlanif40
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
4.8.3 Example for Configuring One-Arm Static BFD for RIP

As shown in Figure 4-11, there are four switches that communicate using RIP on a small-
sized network. Services are transmitted through the primary link
SwitchA→SwitchB→SwitchD. Reliability must be improved for data transmitted from
SwitchA to SwitchB so that services can be rapidly switched to another path for transmission
when the primary link fails.

Figure 4-11 Networking diagram for One-Arm static BFD for RIP
GE0/0/1 GE0/0/1 GE0/0/3

SwitchA VLANIF10 VLANIF10 SwitchB VLANIF40 SwitchD
10.2.2.1/24 10.2.2.2/24 172.16.1.1/24
GE0/0/1
VLANIF20 VLANIF30 172.16.1.2/24
10.3.3.1/24 10.4.4.1/24
GE0/0/2 GE0/0/1
VLANIF20 VLANIF30
10.3.3.2/24 SwitchC 10.4.4.2/24
1. Configure IP address for each interface to ensure network reachability.

3. Configure One-Arm static BFD on SwitchA. BFD can rapidly detect the link status and
help RIP speed up route convergence to implement fast link switching.
Procedure
Step 1 Configure VLANs that the related interfaces belong to.The configurations of SwitchB,
SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not mentioned
here.
Step 2 Configure an IP address to each VLANIF interface.The configurations of SwitchB, SwitchC,

and SwitchD are similar to the configuration of SwitchA, and are not mentioned here.
Step 3 Configure basic RIP functions.
# Configure SwitchA.
[SwitchA] rip 1
# Configure SwitchB.

[SwitchB] rip 1
# Configure SwitchC.
[SwitchC] rip 1
# Configure SwitchD.
[SwitchD] rip 1
# After completing the preceding operations, run the display rip neighbor command. The
command output shows that SwitchA, SwitchB, and SwitchC have established neighbor
relationships with each other. In the following example, the display on SwitchA is used.
[SwitchA] display rip 1 neighbor
---------------------------------------------------------------------
IP Address Interface Type Last-Heard-Time
---------------------------------------------------------------------
10.2.2.2 Vlanif10 RIP 0:0:10
Number of RIP routes : 2
10.3.3.2 Vlanif20 RIP 0:0:8
# Run the display ip routing-table command. The command output shows that the devices
have imported routes from each other. In the following example, the display on SwitchA is
used.
------------------------------------------------------------------------------
10.2.2.0/24 Direct 0 0 D 10.2.2.1 Vlanif10

10.2.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.3.3.0/24 Direct 0 0 D 10.3.3.1 Vlanif20
10.3.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.4.4.0/24 RIP 100 1 D 10.2.2.2 Vlanif10
RIP 100 1 D 10.3.3.2 Vlanif20
172.16.1.0/24 RIP 100 1 D 10.2.2.2 Vlanif10
The preceding command output shows that the next-hop address and outbound interface of the
route to destination 172.16.1.0/24 are 10.2.2.2 and VLANIF10 respectively, and traffic is
transmitted over the active link SwitchA->SwitchB.
Step 4 Configure One-Arm static BFD on SwitchA.
# Configure one-arm BFD on SwitchA.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bfd 1 bind peer-ip 10.2.2.2 interface vlanif 10 source-ip 10.1.1.1 one-
arm-echo
//source-ip 10.1.1.1 can be configured as the IP address of another interface

(such as loopback interface) on the device.This parameter must be configured.

Otherwise, the BFD session cannot be set up.
[SwitchA-bfd-session-1] discriminator local 1

[SwitchA-bfd-session-1] min-echo-rx-interval 200
[SwitchA-bfd-session-1] commit
[SwitchA-bfd-session-1] quit
# Enable static BFD on VLANIF 10.

[SwitchA-Vlanif10] rip bfd static
# After the configurations are completed, run the display bfd session all command on
SwitchA and you can see that a static BFD session is set up.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 - 10.2.2.2 Up S_IP_IF Vlanif10
--------------------------------------------------------------------------------

# Run the shutdown command on GigabitEthernet0/0/1 of SwitchB 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.
# Check the routing table of SwitchA.

------------------------------------------------------------------------------
10.3.3.0/24 Direct 0 0 D 10.3.3.1 Vlanif20

10.3.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.4.4.0/24 RIP 100 1 D 10.3.3.2 Vlanif20
172.16.1.0/24 RIP 100 2 D 10.3.3.2 Vlanif20
The preceding command output shows that the standby link SwitchA->SwitchC->SwitchB is
used after the active link fails, and the next-hop address and outbound interface of the route to
destination 172.16.1.0/24 are 10.3.3.2 and VLANIF20 respectively.
----End
Configuration files
l Configuration file of SwitchA
#
sysname SwitchA
#
vlan batch 10 20

#
bfd
#
interface Vlanif10
ip address 10.2.2.1 255.255.255.0
rip bfd static
#
interface Vlanif20
ip address 10.3.3.1 255.255.255.0
#
#
#
bfd 1 bind peer-ip 10.2.2.2 interface Vlanif10 source-ip 10.1.1.1 one-arm-echo
min-echo-rx-interval 200
commit
#
rip 1
version 2
network 10.0.0.0
#
return
l Configuration file of SwitchB
#
sysname SwitchB
#
vlan batch 10 30 40
#
interface Vlanif10
ip address 10.2.2.2 255.255.255.0
#
interface Vlanif30
ip address 10.4.4.1 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
#
#
#
rip 1
version 2
network 10.0.0.0
network 172.16.0.0
#
return
l Configuration file of SwitchC
#
sysname SwitchC
#
vlan batch 20 30
#
interface Vlanif20

ip address 10.3.3.2 255.255.255.0

#
interface Vlanif30
ip address 10.4.4.2 255.255.255.0
#
#
#
rip 1
version 2
network 10.0.0.0
#
return
l Configuration file of SwitchD

#
sysname SwitchD
#
vlan batch 40
#
interface Vlanif40
ip address 172.16.1.2 255.255.255.0
#
#
rip 1
version 2
network 172.16.0.0
#
return
4.8.4 Example for Configuring Dynamic BFD for RIP
As shown in Figure 4-12, there are four switches that communicate using RIP on a small-
sized network. Services are transmitted through the primary link
SwitchA→SwitchB→SwitchD. Reliability must be improved for data transmitted from
SwitchA to SwitchB so that services can be rapidly switched to another path for transmission
when the primary link fails.
Figure 4-12 Networking diagram for configuring BFD for RIP
GE0/0/1 GE0/0/1 GE0/0/3

SwitchA VLANIF10 VLANIF10 SwitchB VLANIF40 SwitchD
10.2.2.1/24 10.2.2.2/24 172.16.1.1/24
GE0/0/1
VLANIF20 VLANIF30 172.16.1.2/24
10.3.3.1/24 10.4.4.1/24
GE0/0/2 GE0/0/1
VLANIF20 VLANIF30
10.3.3.2/24 SwitchC 10.4.4.2/24

1. Configure IP address for each interface to ensure network reachability.
3. Configure BFD for RIP on interfaces at both ends of the link between SwitchA and
SwitchB. BFD can rapidly detect the link status and help RIP speed up route
convergence to implement fast link switching.
Procedure
Step 1 Configure VLANs that the related interfaces belong to.The configurations of SwitchB,
SwitchC, and SwitchD are similar to the configuration of SwitchA, and are not mentioned
here.
Step 2 Configure an IP address to each VLANIF interface.The configurations of SwitchB, SwitchC,

and SwitchD are similar to the configuration of SwitchA, and are not mentioned here.
Step 3 Configure basic RIP functions.

[SwitchA] rip 1
[SwitchB] rip 1
[SwitchC] rip 1
[SwitchD] rip 1


# After completing the preceding operations, run the display rip neighbor command. The
command output shows that SwitchA, SwitchB, and SwitchC have established neighbor
relationships with each other. In the following example, the display on SwitchA is used.
[SwitchA] display rip 1 neighbor
---------------------------------------------------------------------
IP Address Interface Type Last-Heard-Time
---------------------------------------------------------------------
10.2.2.2 Vlanif10 RIP 0:0:14
10.3.3.2 Vlanif20 RIP 0:0:19
# Run the display ip routing-table command. The command output shows that the switches
have imported routes from each other. In the following example, the display on SwitchA is
used.
------------------------------------------------------------------------------
10.2.2.0/24 Direct 0 0 D 10.2.2.1 Vlanif10

10.2.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.3.3.0/24 Direct 0 0 D 10.3.3.1 Vlanif20
10.3.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.4.4.0/24 RIP 100 1 D 10.3.3.2 Vlanif20
RIP 100 1 D 10.2.2.2 Vlanif10
172.16.1.0/24 RIP 100 1 D 10.2.2.2 Vlanif10
The preceding command output shows that the next-hop address and outbound interface of the
route to destination 172.16.1.0/24 are 10.2.2.2 and VLANIF10 respectively, and traffic is
transmitted over the active link SwitchA->SwitchB.
Step 4 Configure BFD in RIP processes.
# Configure BFD on all interfaces of SwitchA. The configuration of SwitchB is similar to that
of SwitchA, and is not provided here.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] rip 1
[SwitchA-rip-1] bfd all-interfaces enable
[SwitchA-rip-1] bfd all-interfaces min-tx-interval 100 min-rx-interval 100 detect-
multiplier 10
# After completing the preceding operations, run the display rip bfd session command on
SwitchA. The command output shows that SwitchA and SwitchB have established a BFD
session and the BFDState field value is displayed as Up. In the following example, the display
on SwitchA is used.
[SwitchA] display rip 1 bfd session all
LocalIp : 10.2.2.1 RemoteIp : 10.2.2.2 BFDState :
Up
TX : 100 RX : 100 Multiplier :
10
BFD Local Dis : 8192 Interface : Vlanif10
Diagnostic Info : No diagnostic information

LocalIp : 10.3.3.1 RemoteIp : 10.3.3.2 BFDState :

Down
TX : 2800 RX : 2800 Multiplier :
0
BFD Local Dis : 8193 Interface : Vlanif20
Diagnostic Info : No diagnostic information

# Run the shutdown command on GigabitEthernet0/0/1 of SwitchB 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.

------------------------------------------------------------------------------
10.3.3.0/24 Direct 0 0 D 10.3.3.1 Vlanif20

10.3.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.4.4.0/24 RIP 100 1 D 10.3.3.2 Vlanif20
172.16.1.0/24 RIP 100 2 D 10.3.3.2 Vlanif20
The preceding command output shows that the standby link SwitchA->SwitchC->SwitchB is
used after the active link fails, and the next-hop address and outbound interface of the route to
destination 172.16.1.0/24 are 10.3.3.2 and VLANIF20 respectively.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
bfd
#
interface Vlanif10
ip address 10.2.2.1 255.255.255.0
#
interface Vlanif20
ip address 10.3.3.1 255.255.255.0
#
#
#
rip 1

version 2
network 10.0.0.0
bfd all-interfaces min-tx-interval 100 min-rx-interval 100 detect-multiplier
10
#
return
#
sysname SwitchB
#
vlan batch 10 30 40
#
bfd
#
interface Vlanif10
ip address 10.2.2.2 255.255.255.0
#
interface Vlanif30
ip address 10.4.4.1 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
#
#
#
rip 1
version 2
network 10.0.0.0
network 172.16.0.0
bfd all-interfaces min-tx-interval 100 min-rx-interval 100 detect-multiplier
10
#
return
#
sysname SwitchC
#
vlan batch 20 30
#
interface Vlanif20
ip address 10.3.3.2 255.255.255.0
#
interface Vlanif30
ip address 10.4.4.2 255.255.255.0
#
#
#
rip 1
version 2
network 10.0.0.0

#
return

#
sysname SwitchD
#
vlan batch 40
#
interface Vlanif40
ip address 172.16.1.2 255.255.255.0
#
#
rip 1
version 2
network 172.16.0.0
#
return
4.9.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 version number in the RIP packet sent by the peer interface matches
the version number in the RIP packet received by the local interface. If not, the two
interfaces cannot establish the RIP neighbor relationship.
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
4.9.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.
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
4.9.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
4.10 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.

Configuration Guide - IP Unicast Routing 5 RIPng Configuration
5 RIPng Configuration
About This Chapter
This chapter describes how to configure RIPng. RIPng is widely used on small-sized
networks to discover routes and generate routing information.
5.1 Introduction to RIPng

5.2 Principles

5.6 Configuring RIPng
5.7 Maintaining RIPng
5.9 References

5.1 Introduction to RIPng

The 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+.
5.2 Principles
5.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 RIPng
protocol. If other RIPng functions are required, configure them according to reference
sections.
Table 5-1 describes the RIPng configuration tasks.

Table 5-1 RIPng configuration tasks

Configuring basic RIPng Basic RIPng functions 5.6.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 5.6.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 RIPng routing To use RIPng more flexibly 5.6.3 Controlling RIPng
on the existing network and Routing
meet various user
requirements, you can
configure different
parameters to control RIPng
routing.

Controlling the advertising In practical applications, to 5.6.4 Controlling RIPng

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

performance you can configure special Network Performance
RIPng functions to improve
RIPng network
performance.
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.

Other network elements are required to support RIPng.
License Support
RIPng is not under license control.

Version Support
Table 5-2 Products and minimum version supporting RIPng

Required


V200R001 and later
versions.)

S2720EI Not supported
S3700 S3700SI V100R005 (The S3700SI is



S5700 S5700LI/S5700S-LI Supported. Only the

S5700-10P-PWR-LI-AC/
S5700-10P-LI-AC do not
support RIPng.

V200R002 and later
versions.)
S5710-X-LI V200R009




Required

S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

None.

Table 5-3 describes the default configuration of RIPng.
Table 5-3 Default configuration of RIPng

Maximum number of equal-cost routes 8
RIPng function Disabled
5.6 Configuring RIPng
5.6.1 Configuring Basic RIPng Functions

Before configuring basic RIPng functions, complete the following tasks:
l Enable IPv6 on the switch.
l Configure 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.
5.6.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
5.6.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:

undo portswitch

NOTE
Step 4 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.
If RIPng needs to be enabled on multiple interfaces of a switch, 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
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 [ verbose | neighbor neighbor-ipv6-address ] } command to check statistics
about RIPng interfaces.
----End
5.6.2 Avoiding Routing Loops
Before configuring split horizon and poison reverse, configure basic RIPng functions.

5.6.2.1 Configuring Split Horizon
Context
Split horizon can prevent routing loops.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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
5.6.2.2 Configuring Poison Reverse
Context
Poison reverse can prevent routing loops.
Procedure
Step 1 Run:
system-view

Step 2 Run:


undo portswitch

NOTE
Step 4 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
5.6.3 Controlling RIPng Routing
Before configuring RIPng route attributes, configure basic RIPng functions.
5.6.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:
The RIPng view is displayed.
Step 3 Run:
The RIPng preference is set.
By default, the RIPng preference is 100.
----End
5.6.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:

undo portswitch

NOTE
Step 4 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
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:
The maximum number of equal-cost routes is set. The default value is 8.
----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
5.6.4 Controlling RIPng Route Advertisement

Before controlling RIPng route advertisement, configure basic RIPng functions.
5.6.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:

undo portswitch

NOTE
Step 4 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
5.6.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:

undo portswitch

NOTE
Step 4 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
5.6.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.
Step 4 Run:
import-route { { ripng | isis | ospfv3 } [ process-id ] | bgp [ permit-ibgp ] |
unr | direct | static } [ [ cost cost | inherit-cost ] | route-policy route-
policy-name ] *
External routes are imported.

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

A RIPng process can use ACL6, route policy and IPv6 prefix lists to filter imported routes,
allowing only the routes matching ACL6, route policy 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
5.6.4.4 Disabling Sending of RIPng Packets on an Interface
Context
When a device running RIPng is connected to a network running other routing protocols, you
can run the undo ripng output command on the interface that connects the device to the
network to prevent the interface from sending useless packets to the network.
Procedure
Step 1 Run:
system-view

Step 2 Run:


undo portswitch

NOTE
Step 4 Run:
undo ripng output
The interface is disabled from sending RIPng packets.

By default, an interface is allowed to send RIPng packets.
----End
5.6.4.5 Disabling Receiving of RIPng Packets on an Interface
Context
When a device running RIPng is connected to a network running other routing protocols, you
can run the undo ripng input command on the interface that connects the device to the
network to prevent the interface from receiving useless packets from the network.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
undo ripng input
The interface is disabled from receiving RIPng packets.

By default, an interface is allowed to receive RIPng packets.
----End

Procedure
l Run the display ripng process-id database [ verbose ] command to check all activated
----End
5.6.5 Controlling the Receiving of RIPng Routes
Before controlling the receiving of RIPng routes, configure basic RIPng functions.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ripng [ process-id ]
Step 3 Run:
filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name
| route-policy route-policy-name } import
The RIPng process is configured to filter received routes.
You can use ACL6, route policy and IPv6 prefix lists to filter received RIPng routes, allowing
only the routes matching ACL6, route policy 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 switches.
5.6.6 Improving RIPng Network Performance
Before improving RIPng network performance, configure basic RIPng functions.

5.6.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.
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 switch 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

5.6.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:

undo portswitch

NOTE
Step 4 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
5.6.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
5.7 Maintaining RIPng
5.7.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

5.8.1 Example for Configuring RIPng to Filter the Received

Routes
As shown in Figure 5-1, the prefix length of all the IPv6 addresses is 64 bits. In addition, the
VLANIF interfaces between the neighboring Switches are assigned IPv6 link-local addresses.
All the Switches must learn IPv6 routing information on the network through RIPng. SwitchB
should filter the routes received from SwitchC (FC00:0:0:3::/64). That is, SwitchB does not
add the routes to its own routing table or advertise the routes to SwitchA.
Figure 5-1 Networking diagram for configuring RIPng to filter the received routes
SwitchB
GE0/0/1 GE0/0/2
VLANIF20 VLANIF30
SwitchA SwitchC GE0/0/2

VLANIF40
GE0/0/1 GE0/0/1 FC00:0:0:2::1/64
VLANIF20 VLANIF30
GE0/0/2 GE0/0/3
VLANIF10 VLANIF50
FC00:0:0:1::1/64 FC00:0:0:3::1/64
1. Enable RIPng on each Switch so that the Switches can communicate with each other.
2. Configure an ACL on SwitchB to filter the received routes.
Procedure
# Configure SwitchA. Ensure that the configurations of SwitchB, and SwitchC are the same
as the configuration of SwitchA.
[SwitchA] vlan 10


[SwitchA] vlan 20
Step 2 Assign IP addresses to the VLANIF interfaces.

[SwitchA] ipv6
[SwitchA-Vlanif20] ipv6 address auto link-local
Step 3 Configure the basic RIPng functions.

[SwitchA] ripng 1
[SwitchA-ripng-1] quit
[SwitchA-Vlanif10] ripng 1 enable
[SwitchA-Vlanif20] ripng 1 enable
[SwitchB] ripng 1
[SwitchB-ripng-1] quit
[SwitchB] interface vlanif 20
[SwitchB-Vlanif20] ripng 1 enable
[SwitchB-Vlanif20] quit
[SwitchB-Vlanif30] ripng 1 enable
[SwitchC] ripng 1
[SwitchC-ripng-1] quit
[SwitchC] interface vlanif 30
[SwitchC-Vlanif30] ripng 1 enable
[SwitchC-Vlanif30] quit
# Display the RIPng routing table of SwitchB.

[SwitchB] display ripng 1 route
Route Flags: R - RIPng

----------------------------------------------------------------
Peer FE80::D472:0:3C23:1 on Vlanif20
Dest FC00:0:0:1::/64,
via FE80::D472:0:3C23:1, cost 1, tag 0, RA, 4 Sec
Peer FE80::F54C:0:9FDB:1 on Vlanif30
Dest FC00:0:0:2::/64,
via FE80::F54C:0:9FDB:1, cost 1, tag 0, RA, 3 Sec
Dest FC00:0:0:3::/64,
The preceding information shows that the RIPng routing table of SwitchB contains the routes
of network segment FC00:0:0:3::/64.
# Display the RIPng routing table of SwitchA.
[SwitchA] display ripng 1 route
----------------------------------------------------------------
Peer FE80::476:0:3624:1 on Vlanif20

Dest FC00:0:0:2::/64,
via FE80::476:0:3624:1, cost 2, tag 0, RA, 21 Sec
Dest FC00:0:0:3::/64,
The preceding information shows that the RIPng routing table of SwitchA contains the routes
of network segment FC00:0:0:3::/64 advertised by SwitchB.
Step 4 Configure SwitchB to filter the received routes.
[SwitchB] acl ipv6 number 2000
[SwitchB-acl6-basic-2000] rule deny source fc00:0:0:3:: 64
[SwitchB-acl6-basic-2000] rule permit
[SwitchB-acl6-basic-2000] quit
[SwitchB] ripng 1
[SwitchB-ripng-1] filter-policy 2000 import
[SwitchB-ripng-1] quit

NOTE
After the aging time of the filtered routing entry expires, check the verification result. The default aging time
is 180 seconds.
# Check the RIPng routing table of SwitchB. The RIPng routing table should not contain the
routes of network segment FC00:0:0:3::/64.
[SwitchB] display ripng 1 route
----------------------------------------------------------------
Peer FE80::D472:0:3C23:1 on Vlanif20
Dest FC00:0:0:1::/64,
via FE80::D472:0:3C23:1, cost 1, tag 0, RA, 25 Sec
Peer FE80::F54C:0:9FDB:1 on Vlanif30
Dest FC00:0:0:2::/64,
# Check the RIPng routing table of SwitchA. The RIPng routing table should not contain the
routes of network segment FC00:0:0:3::/64.
[SwitchA] display ripng 1 route
----------------------------------------------------------------
Peer FE80::476:0:3624:1 on Vlanif20

Dest FC00:0:0:2::/64,
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10 20
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1::1/64
ripng 1 enable
#
interface Vlanif20
ipv6 enable
ipv6 address auto link-local
ripng 1 enable
#
#
#
ripng 1
#
return

#
sysname SwitchB
#
ipv6
#
vlan batch 20 30
#
acl ipv6 number 2000
rule 0 deny source FC00:0:0:3::/64
rule 1 permit
#
interface Vlanif20
ipv6 enable
ripng 1 enable
#
interface Vlanif30
ipv6 enable
ripng 1 enable
#
#
#
ripng 1

filter-policy 2000 import

#
return

#
sysname SwitchC
#
ipv6
#
vlan batch 30 40 50
#
interface Vlanif30
ipv6 enable
ripng 1 enable
#
interface Vlanif40
ipv6 enable
ripng 1 enable
#
interface Vlanif50
ipv6 enable
ripng 1 enable
#
#
#
#
ripng 1
#
return
5.9 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.

Configuration Guide - IP Unicast Routing 6 OSPF Configuration
6 OSPF Configuration
About This Chapter
This chapter describes how to configure OSPF. You can build an OSPF network to discover
and calculate routes in an autonomous system (AS). OSPF applies to large networks
composed of several hundreds of devices.
6.1 Introduction to OSPF

6.2 Principle
6.3 OSPF Applications
6.7 Configuring OSPF
6.8 Maintaining OSPF
6.10 Common Misconfigurations
6.11 References

6.1 Introduction to 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.
6.2 Principle
6.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.

Packet Type
Table 6-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 6-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

(Type 4) Router (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.

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 6-1 lists common Router types used in OSPF.
Figure 6-1 Router type

IS-IS ASBR
Area1 Area4
Internal Router Backbone Router
Area0
Area2 ABR Area3
Table 6-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.

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 An ASBR exchanges routing information with other ASs.
Router) 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 6-4 lists route types in descending priority order.
Table 6-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

Area Type
Table 6-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 and inter-area routes, the
ABR in a totally stub area advertises Type 3 default routes to the
entire totally stub area. All AS external and inter-area 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 7 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 and Type 7
default routes to the entire totally NSSA area. All inter-area routes
must be advertised by the ABR.

OSPF Network Type

Table 6-6 lists four OSPF network types that are classified based on link layer protocols.
Table 6-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

(P2MP) of 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.

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

To exchange routing information on an OSPF network, neighbor routers must establish
adjacencies. The differences between neighbor relationships and adjacencies are described as
follows:
l Neighbor relationship: After the local router starts, it uses an OSPF interface to send a
Hello packet to the remote router. After the remote router receives the packet, it checks
whether the parameters carried in the packet are consistent with its own parameters. If
the parameters carried in the packet are consistent with its own parameters, the local and
remote routers establish a neighbor relationship.
l Adjacency: After the local and remote routers establish a neighbor relationship, they
exchange DD packets and LSAs to establish an adjacency.
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 is Exstart when the two neighbors 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.
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.
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 6-7 lists principles for advertising default routes in different areas.
Table 6-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.

Area Type Function
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.
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
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 6-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.
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.
6.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 6-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
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
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.
6.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 6-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
Principle
Figure 6-3 BFD for OSPF
RouterA RouterB GE3/0/0

172.16.1.1/24
GE2/0/0 GE2/0/0
GE1/0/0 10.3.3.1/24 10.3.3.2/24 GE1/0/0
10.1.1.1/24 10.2.2.2/24
GE1/0/0 GE2/0/0
10.1.1.2/24 10.2.2.1/24
RouterC Area0
The principle of BFD for OSPF is shown in Figure 6-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.
6.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.
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.
6.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 6-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.
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.
6.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 6-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.
Figure 6-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 6-5.

Figure 6-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 6-11 Domain ID

Comparison Between Local and Local and Route Type
Remote Domain IDs Remote
Domain
IDs the
Same Or
Not
Both the local and remote domain IDs are The same Inter-area route
null.
The remote domain ID is the same as the The same Inter-area route
local primary domain ID or one of the local
secondary domain IDs.

Comparison Between Local and Local and Route Type

Remote Domain IDs Remote
Domain
IDs the
Same Or
Not
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.
Routing Loop Prevention

Between PEs and CEs, routing loops may occur when OSPF and BGP learn routes from each
other.
Figure 6-6 OSPF VPN routing loops
PE1
VPN
backbone
vpn1 site1 10.1.1.1/32
CE1
PE2
As shown in Figure 6-6, 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.
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 6-12.
Table 6-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 generated Type 3, Type 5, or
a 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 When a PE detects that the
5 or Type 7 LSAs generated by PEs VPN route tag in the
according to the received BGP private incoming LSA is the same
route. as that in the local LSA, the
Not transmitted in BGP extended PE ignores this LSA.
community attributes, the VPN route Consequently, routing loops
tag is valid only on the PEs that are avoided.
receive BGP routes and generate
OSPF LSAs.
Default Route A route with the destination address PEs do not calculate default
and mask being all 0s is a default routes.
route. Default routes are used to
forward the traffic from CEs
or the sites where CEs
reside to the VPN backbone
network.

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 6-7, inter-AS VPN Option A is deployed. OSPF is running between PE1
and CE1. CE1 sends VPN routes to CE2.
Figure 6-7 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 6-8, 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 6-8. ASBR2 will deny the
Type 5 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 10.1.1.1 and
the router ID 10.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs
sent by ASBR4 with the router ID 10.4.4.4, ASBR2 will check the DN bit and deny these
Type 3 LSAs because the DN bit is set to 1.
Figure 6-8 Networking diagram for full-mesh ASBRs in the inter-AS VPN Option A scenario
OSPF Router ID OSPF Router ID

10.1.1.1 10.2.2.2
ASBR1 ASBR2
OSPF AS: 200

AS: 100
ASBR3 ASBR4
OSPF Router ID OSPF Router ID
10.3.3.3 10.4.4.4
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.
6.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 6-9 NSSA

RIP RIP
Type5 Type5 NSSA Area
Type5 Type5 Type7

ASBR Area2 Area0 Area1 ASBR
ABR ABR
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.
6.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 6.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).
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 6.2.5 OSPF Smart-discover
6.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.
6.2.10 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 6-10, 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.

Figure 6-10 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 6-10, 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.
6.2.11 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.

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.

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 6-11.
Figure 6-11 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 6-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 Grace-LSA with the Age being
s. all neighbors before master/slave 3600s from the Restarter, the
switchover. neighbor relationship between
the Helper and Restarter enters
the Full state.

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 changes.
as the Restarter changes. l Helper receives the LSA
l Restarter receives the one-way Hello that is inconsistent with the
packet from the Helper. LSA in the local LSDB
from another router. This
l The Restarter receives the Grace- situation can be excluded
LSA that is generated by another after the Helper is
router on the same network segment. configured not to perform
Only one router can perform GR on strict LSA check.
the same network segment.
l Helper receives Grace-
l On the same network segment, LSAs from two routers on
neighbors of the Restarter have the same network segment
different DRs or BDRs because of at the same time.
the topology changes.
l Neighbor relationships
between Helper and other
neighbors change.
Comparison Between GR Mode and Non-GR Mode
Table 6-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, l No packets are lost during forwarding, and
and services are interrupted. services are not affected.

6.2.12 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 6-12, the primary link adopts the path PE1→P1→P2→P3→PE2, and the
backup link adopts the path PE1→P1→P4→P3→PE2.
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 6-12 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 6-15 OSPF-LDP association

Enabling Status of OSPF-LDP Traffic Interruption Time
Association
Not enabled. Seconds level
Enabled. Milliseconds level
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.
6.2.13 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 overflow timer. The router automatically exits from the overflow state after the timer
expires, By default, it is 5 seconds.

Table 6-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.
6.2.14 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.

Principles
As shown in Figure 6-13, 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 6-13 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 6-14.
Figure 6-14 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 6-15, 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.

Figure 6-15 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.
6.3 OSPF Applications
6.3.1 OSPF GR
In Figure 6-16, 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 6-16 OSPF GR
s
d oe er RouterC
t e r B Rout A
u y r
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

6.3.2 OSPF GTSM

As shown in Figure 6-17, 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 6-17 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. On the basic
OSPF network, you can configure other OSPF functions as required.
Table 6-17 describes the OSPF configuration tasks.

Table 6-17 OSPF configuration tasks

Configuring Basic OSPF The configuration of basic 6.7.1 Configuring Basic

Functions OSPF functions is the OSPF Functions
foundation of the OSPF 6.7.2 Setting Session
network and the Parameters for OSPF
precondition for other OSPF Neighbor Relationships
functions.
6.7.3 Configuring OSPF
Attributes in Different
Types of Networks
Configuring OSPF Areas l In a stub area, the area 6.7.4 Configuring OSPF
border router (ABR) Stub Areas
does not transmit learned 6.7.5 Configuring OSPF
autonomous system (AS) NSSA
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 on which 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 meet various user 6.7.6 Adjusting OSPF

Selection requirements, you can adjust Route Selection
OSPF parameters to flexibly
control OSPF routing.
Controlling OSPF Routing To meet network 6.7.7 Controlling OSPF

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

Controlling the convergence To enable OSPF to quickly 6.7.9 Configuring OSPF

speed of OSPF routes detect changes in the Fast Convergence
network topology, you can
speed up OSPF route
convergence. To decrease
the impact of route flapping
on the network and relieve
loads on devices, you can
lower the convergence speed
of OSPF routes.

Improving the Reliability of l By default, the interval 6.7.8 Configuring BFD for
an OSPF Network for OSPF to send Hello OSPF
packets is 10 seconds on 6.7.10 Configuring OSPF
broadcast networks; on GR
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 switch does not
receive a Hello packet
from its neighbor within
the dead time, the switch
deletes the neighbor.
That is, the switch
detects neighbor faults at
the second level. 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
mechanism. BFD
ensures that the detection
interval is reduced to the
millisecond level.
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 to
ensure correct packet
forwarding.
l When a switch restarts or
performs an active/
standby switchover, it
directly ages all routing

entries in the Forward

Information Base (FIB)
table. This results in
route interruption. In
addition, neighboring
switches remove this
switch from the neighbor
list, and notify other
switches. This causes the
re-calculation of SPF. If
this switch recovers
within a few seconds, the
neighbor relationship
becomes unstable. This
results in route flapping.
After being enabled with
OSPF Graceful Restart
(GR), a switch can
ensure continuous packet
forwarding in the event
of a restart caused by an
abnormality. In such a
case, route flapping is
avoided during the short
restart of the switch.
Improving the Stability of You can improve the 6.7.11 Improving the
an OSPF Network stability of the OSPF Stability of an OSPF
network to reduce route Network
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 6.7.12 Improving the

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

Other network elements are required to support OSPF.

License Support
OSPF is not under license control.
Version Support
Table 6-18 Products and minimum version supporting OSPF

Required


V200R001 and later
versions.)




S5700 S5700LI/S5700S-LI Not supported

V200R002 and later
versions.)
S5710-X-LI Not supported



Required


S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

None.

Table 6-19 describes the default configuration of OSPF.
Table 6-19 Default configuration of OSPF

OSPF Disabled
Interval for sending Hello By default, the interval for sending Hello packets is 10
packets seconds on P2P and broadcast interfaces; the interval is
30 seconds on P2MP and NBMA interfaces.

Dead interval for OSPF By default, the dead interval for OSPF neighbors is 40
neighbors seconds on P2P and broadcast interfaces; the interval is
120 seconds on P2MP and NBMA interfaces.
Period during which a device 500 seconds

continues to act as a stub router
Bandwidth reference value used 100 Mbit/s

to calculate the link cost
6.7 Configuring OSPF
6.7.1 Configuring Basic OSPF Functions
When OSPF is configured on multiple switches 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 switches 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 task:
l Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer
6.7.1.1 Creating an OSPF Process
Context
To run OSPF, the switch needs to have a router ID. A router ID of the switch is a 32-bit
unsigned integer, which uniquely identifies the switch in an AS. To ensure the stability of
OSPF, you need to manually configure a router ID for each device during network planning.
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 switch 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 switches. Therefore, different switches can also exchange packets
even though they have different process IDs.
l The parameter router-id router-id specifies the router ID of the switch.
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 to ensure stability.
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
6.7.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

Step 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.

Step 3 Run:
area area-id

The OSPF area view is displayed.

Areas are not equally important. The area with an area ID 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
6.7.1.3 Enabling 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, 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. As a result, an OSPF neighbor relationship is not 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:
– The IP address mask length of the interface is equal to or greater than the mask
length specified in the network command.
– 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:

undo portswitch

NOTE
3. 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 IPv4 address format.
----End
6.7.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 connectivity with the backbone area and that the backbone areas in different OSPF
areas maintain connectivity with each other. In real world situations, this requirement may not
be met because of certain restrictions. To resolve this problem, you can configure OSPF
virtual links.
Perform the following steps on the switch running OSPF.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
area area-id

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 switch.
NOTICE
If plain is selected, 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.
MD5 authentication and HMAC-MD5 authentication have potential security risks. HMAC-
SHA256 authentication mode is recommended.
----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.
6.7.1.5 (Optional) Restricting the Flooding of LSA Update Packets
Context
When multiple neighboring switches are configured or a large number of LSA update packets
are flooded, the neighboring switch may receive a large number of LSA update packets in a
short period. This keeps the neighboring switch busy processing a burst of LSA update
packets and causes the neighboring switch to 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 will be exchanged. This increases
the frequency of 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.
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 switches 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 information in the OSPF
LSDB.
----End
6.7.2 Setting Session Parameters for OSPF Neighbor

Relationships
Before configuring session parameters for OSPF neighbor or adjacency relationships,
complete the following tasks:
l Configuring a link layer protocol

the network layer
l 6.7.1 Configuring Basic OSPF Functions

Perform one or more of the following configuration tasks (excluding "Checking the
Configuration") as required.
6.7.2.1 Setting the OSPF Packet Retransmission Limit
Context
After an OSPF switch 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 switch 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
6.7.2.2 Configuring an Interface to Fill in DD Packets 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.

undo portswitch

NOTE
Step 4 Run:
ospf mtu-enable
The interface is configured to fill in DD packets with the actual MTU and check whether the
MTU in DD packets from the neighbor exceeds the MTU of the local end.
By default, the MTU in DD packets sent by an interface is 0.
NOTICE
Setting the MTU in a DD packet will lead to the re-establishment 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
6.7.3 Configuring OSPF Attributes in Different Types of

Networks

In Table 6-20, OSPF classifies networks into four types based on the type of link layer
protocols.
NOTE
Differentiated OSPF configurations that are applicable only to NBMA networks and P2MP networks are
provided in this section. The OSPF configurations not provided here are applicable to the four types of
networks.
Table 6-20 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 Ethernet or Fiber Distributed
LSAck packets are multicasted; Data Interface (FDDI), OSPF
DD packets and LSR packets are regards the network as a
unicasted. broadcast 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 NBMA network by default.
LSAck packets are unicasted.
The NBMA network must be
fully meshed. Any two switches
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

multipoint packets are multicasted; DD as a P2MP network by default
(P2MP) 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 described in Table 6-20, the difference between OSPF configurations on networks of

different types lies in the packet transmission mode.
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
6.7.3.1 Configuring Network Types of OSPF Interfaces
Context
You can configure one of the following network types for an interface as required:
l P2MP: P2MP is not a link layer protocol. Therefore, a P2MP network must be forcibly
changed from other network types.
l NBMA: An NBMA network must be fully meshed. That is, any two switches on the
NBMA network must be directly reachable. In most cases, however, this requirement
cannot be met. In this case, you need to forcibly change the network type using
commands.
l Broadcast: To speed up the establishment of the neighbor relationship, you can change
the network type of broadcast to P2P network.
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
ospf network-type { broadcast | nbma | p2mp | p2p [ peer-ip-ignore ] }
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.
When the network type is configured for an interface, the original network type of the
interface is replaced.
The network type can be configured to suit networking requirements.

l If the network type of an interface is broadcast and a switch does not support multicast
addresses, change the network type of the interface to NBMA.
l If the network type of an interface is NBMA and the network is fully meshed or any two
switches are directly connected, change the network type of the interface to broadcast
and do not configure neighboring switch information on the interface.
l If the network type of an interface is NBMA and the network is not fully meshed, change
the network type of the interface to P2MP. After that, two indirectly connected switches
can communicate through one switch that can directly reach both the two switches. After
the network type of the interface is changed to P2MP, configuring neighboring switch
information on the interface is unnecessary.
l If only two switches 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
6.7.3.2 Configuring P2MP Network Attributes
Procedure
Step 1 Disable OSPF from checking the network mask.
1. Run:
system-view

2. Run:

undo portswitch

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

A P2MP network is forcibly changed from another type of network. For details, see
Configuring Network Types for OSPF Interfaces.
5. Run:
ospf p2mp-mask-ignore
OSPF is disabled from checking the network mask on the P2MP network.
Step 2 Configure the switch to filter the LSA packets to be sent.

When multiple links exist between two switches, you can configure the local switch 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 ]

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 switch 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
6.7.3.3 Configuring NBMA Network Attributes
Procedure
Step 1 (Optional) Set the network type to NBMA.
An NBMA network must be fully meshed. Any two switches 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:

undo portswitch

NOTE
4. 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 switch 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 switch on the NBMA network.
If the network type of an interface is NBMA, the interface cannot broadcast Hello packets to
discover neighboring switches. Therefore, the IP address of a neighboring switch must be
configured on the interface and whether the neighboring switch can participate in DR election
must be determined on the interface.
1. Run:
quit
Exit from the interface view.

2. Run:
ospf [ process-id ]

3. Run:
peer ip-address [ dr-priority priority ]
A neighboring switch 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 either of the following commands 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 either of the following commands 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
6.7.4 Configuring OSPF Stub Areas
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.
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 switches 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 6-18 Flowchart of configuring OSPF stub areas
Configure OSPF stub areas
Configure metrics of default routes

sent to stub areas
Mandatory
procedure
Optional
procedure
6.7.4.1 Defining the Current Area as 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 [ no-summary | default-route-advertise backbone-peer-ignore ] *
The specified area is configured as a stub area.

The parameter no-summary is used to forbids the ABR to send Type 3 LSAs to the stub area.
The parameter default-route-advertise is used to enables the ABR to generate default Type 3
LSAs and advertise them to the stub area.
The parameter backbone-peer-ignore is used to prevents the ABR from checking the
neighbor status when the ABR generates default Type 3 LSAs and advertises them to the stub
area. Specifically, the ABR generates default Type 3 LSAs and advertises them to the stub
area as long as an interface that is Up exist in the backbone area.
NOTE
l Stub attributes must be configured on all switches in a stub area using the stub command.
l Configuring or deleting stub attributes will update routing information in the area. Stub attributes
can be deleted or reconfigured only after the routing update is complete.
----End
6.7.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 [ no-summary | default-route-advertise backbone-peer-ignore ] *
The specified area is configured as a stub area.

The parameter no-summary is used to forbids the ABR to send Type 3 LSAs to the stub area.

The parameter default-route-advertise is used to enables the ABR to generate default Type 3
LSAs and advertise them to the stub area.
The parameter backbone-peer-ignore is used to prevents the ABR from checking the
neighbor status when the ABR generates default Type 3 LSAs and advertises them to the stub
area. Specifically, the ABR generates default Type 3 LSAs and advertises them to the stub
area as long as an interface that is Up exist in the backbone area.
NOTE
l Stub attributes must be configured on all switches in a stub area using the stub command.
l Configuring or deleting stub attributes will update routing information in the area. Stub attributes
can be deleted or reconfigured only after the routing update is complete.
Step 5 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.
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 switches 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 |
[ 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.
6.7.5 Configuring OSPF NSSA
To both import external routes and prevent resource consumption caused by external routes,
you can configure an NSSA.

The NSSA is a special type of OSPF area. Neither an NSSA nor a stub area transmits routes
learned from other areas in the AS where it resides. A stub area does not allow AS external
routes to be imported, whereas an NSSA allows AS external routes to be imported and
advertised 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 selectively translates received Type 7 LSAs 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:
l Configuring IP addresses for interfaces to ensure that neighboring switches 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 [ backbone-peer-ignore ] | suppress-default-
route } | 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 | translator-strict ]*
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 update the routing information in the area and
disconnect neighbor relationships. NSSA attributes can be reconfigured or deleted only after the
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 on the ASBR only when the default route
0.0.0.0/0 exists in the routing table.

l When the area to which the ASBR belongs is configured as an NSSA, invalid Type 5
LSAs from other switches in the area where LSAs are flooded will be reserved. These
LSAs will be deleted only when the aging time reaches 3600s. The switch performance
is affected because the forwarding of a large number of LSAs consumes 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
switches can be deleted in time.
NOTE
– When the LS age field value (aging time) in the header of an LSA reaches 3600s, the LSA is
deleted.
– 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.
l If an ASBR also functions as an ABR, the no-import-route parameter can be 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.
NOTE
After the nssa default-route-advertise backbone-peer-ignore no-summary command is run, the
ABR generates default Type 7 and Type 3 LSAs as long as an interface that is Up exist in the
backbone area. The default Type 3 LSAs preferentially take effect.
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 switch and neighboring switches.
l If multiple ABRs are deployed in the NSSA, the system automatically selects an ABR
(generally the switch 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 switches 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 |
[ 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.
6.7.6 Adjusting OSPF Route Selection
On complex networks, you can adjust OSPF parameters to flexibly optimize load balancing
requirements.
Before adjusting OSPF route selection, complete the following tasks:
the network layer
Perform one or more configuration tasks (excluding "Checking the Configuration") as
required.
6.7.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 using commands.
If you do not set the cost of an OSPF interface 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
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. Run:
ospf cost cost
The cost of the OSPF interface is set.

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

b. Run:
ospf [ process-id ]

c. 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 switches in an OSPF process are the same.
----End
6.7.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 6-19, three routes between switchA and switchB that run OSPF have the
same costs. The three routes are equal-cost routes for load balancing.
Figure 6-19 Networking diagram of equal-cost routes
IP Network
co
5 st =
st= 10
co
cost=10 cost=5
IP Network
SwitchA SwitchB
co
st = 7
8 st=
co
IP Network
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
The maximum number of equal-cost routes is set.
NOTE
The maximum number of equal-cost routes is 8; by default, it is 8.

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 are 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

6.7.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 switch, specify a route selection rule based on the switch configuration. The switch
complies with the route selection rule defined in RFC 1583 by default. If the neighboring
switch complies with the route selection rule defined in RFC 2328, configure the local switch
to comply with that defined in RFC 2328. This allows all switches in the OSPF area to
comply with the same route selection rule.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
undo rfc1583 compatible
The switch is configured to comply with the route selection rule defined in RFC 2328, not
RFC 1583.
By default, the switch complies with route selection rule defined in RFC 1583.
----End
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
6.7.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.
6.7.7.1 Configuring OSPF to Import External Routes
Context
To access a switch running a non-OSPF protocol, an OSPF-capable switch needs to import
routes of the non-OSPF protocol into the OSPF network.
OSPF can ensure loop-free intra-area 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 switch that functions as the ASBR running OSPF:
Procedure
l Configuring OSPF to import the routes discovered by other protocols
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. 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
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. 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; 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 priority.
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
6.7.7.2 Configuring OSPF to Advertise the Default Route to the OSPF Area
Context
Multiple switches often reside on the area border and AS border of an OSPF network 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.
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.
switches 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. switches in the AS use the received default route to forward AS external packets.
When no exactly matched route is discovered, the switch 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 6-21.

Table 6-21 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
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run the following commands as required:
n 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.

○ always indicates that an LSA describing the default route is generated
and then advertised regardless of whether there are 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 switches 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.
n 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 switch, 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
6.7.7.3 Configuring OSPF Route Aggregation
Context
Route summarization on a large-scale OSPF network efficiently reduces routing entries. This
function minimizes consumption of system resources while maintaining system performance.
In addition, if a specific link frequently alternates between Up and Down states, the links
uninvolved in the route summarization will not be affected. This prevents route flapping and
improves network stability.
When an ABR sends routing information to other areas, it originates Type 3 LSAs for each
network segment. If any contiguous segments exist in this area, run the abr-summary
command to summarize these segments into one. An ABR then sends just one summarized
LSA to other areas, and no LSAs that belong to the summarized network segment specified
by this command. Therefore, the routing table size is reduced, and switch performance is
improved.
Carry out the following steps on the switch running OSPF.
Procedure
l Configuring ABR route aggregation
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run:
area area-id

d. Run:
abr-summary ip-address mask [ [ cost { cost | inherit-minimum } |
[ advertise [ generate-null0-route ] | not-advertise | generate-null0-
route [ advertise ] ] ] * ]
ABR route aggregation is configured.

l Configuring ASBR route aggregation
a. Run:
system-view


b. Run:
ospf [ process-id ]

c. (Optional) Run:
asbr-summary type nssa-trans-type-reference [ cost nssa-trans-cost-
reference ]
OSPF is configured to refer to Type 5 LSAs that have been translated from Type 7
LSAs when it sets types and costs for summary routes on ASBRs.
If this command is not executed, OSPF does not refer to Type 5 LSAs that have
been translated from Type 7 LSAs when it sets types and costs for summary routes
on ASBRs.
d. Run:
asbr-summary ip-address mask [ not-advertise | tag tag | cost cost |
distribute-delay interval ] *
ASBR route aggregation is configured.
NOTE
After route summarization is configured, the routing table on the local OSPF switch remains
unchanged. The routing table on another OSPF switch, however, contains just one
summarized route, and no specific routes. This summarized route will not be removed unless
all specific routes are interrupted.
----End
6.7.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
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 criteria are added to the routing table. Routes that do not pass the
filtering criteria cannot be added to the OSPF routing table but can be advertised.
----End
6.7.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:
policy route-policy-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 criteria 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.
l The parameter route-policy route-policy-name specifies the name of the route policy.
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 criteria.
----End
6.7.7.6 Configuring the switch to Filter LSAs to Be Sent
Context
When multiple links exist between two switches, you can configure the local switch to filter
the LSAs to be sent. This prevents transmission of unnecessary LSAs and saves bandwidth
resources.

Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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
6.7.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.
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 will be filtered.
----End
6.7.7.8 (Optional) Enabling the Mesh-Group Function
Context
When concurrent links exist between two switches, 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 switch.
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

6.7.7.9 Setting the Maximum Number of External LSAs in the LSDB
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
6.7.8 Configuring BFD for OSPF
OSPF enables the switch to periodically send Hello packets to a neighboring switch 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 prolonged detection period 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.
Before configuring BFD for OSPF, complete the following tasks:
the network layer
Figure 6-20 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
6.7.8.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
6.7.8.2 Configuring BFD for OSPF
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.

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 } * 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.
NOTE
If only the bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-interval |

detect-multiplier multiplier-value } * command is run to set BFD parameters, and the bfd all-
interfaces enable command is not run, BFD cannot be enabled.
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 if high
network reliability is required. A long interval at which BFD packets are transmitted can be
configured if high network reliability is not required.

NOTE
l Actual interval at which BFD packets are transmitted on the local switch = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local switch, configured interval receive-
interval at which BFD packets are received on the peer switch }
l Actual interval at which BFD packets are received on the local switch = Max { configured interval
transmit-interval at which BFD packets are transmitted on the peer switch, configured interval receive-
interval at which BFD packets are received on the local switch }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
switch x Configured detection multiplier multiplier-value on the peer switch
For example:
l On the local switch, 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 switch, 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 switch, 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 switch, 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
6.7.8.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.
undo portswitch

NOTE

Step 4 Run:
ospf bfd block
The interface is prevented from dynamically establishing a BFD session.
----End
6.7.8.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 switch 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 switch:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the interface enabled with BFD for OSPF is displayed.

undo portswitch

NOTE
Step 4 Run:
ospf bfd enable
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 if high
network reliability is required. A long interval at which BFD packets are transmitted can be
configured if high network reliability is not required.
NOTE
l Actual interval at which BFD packets are transmitted on the local switch = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local switch, configured interval receive-
interval at which BFD packets are received on the peer switch }
l Actual interval at which BFD packets are received on the local switch = Max { configured interval
transmit-interval at which BFD packets are transmitted on the peer switch, configured interval receive-
interval at which BFD packets are received on the local switch }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
switch x Configured detection multiplier multiplier-value on the peer switch
For example:
l On the local switch, 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 switch, 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 switch, 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 switch, 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.
Procedure
l Run either 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
6.7.9 Configuring OSPF Fast Convergence
Before configuring OSPF fast convergence, complete the following tasks:

l Configuring a link layer protocol

the network layer
required.
6.7.9.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.
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 ]
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 the 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.
During LSA flooding, LSAs are placed into the corresponding critical, high, medium, and low
queues according to priorities to speed up the processing of high-priority LSAs.
NOTE
This command takes effect only on the public network.
----End
6.7.9.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:

undo portswitch

NOTE
Step 4 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
6.7.9.3 Setting the Dead Time of the Neighbor Relationship
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch


NOTE
Step 4 Run:
ospf timer dead interval
The dead time after which the neighbor relationship between two switches 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 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 their respective default values upon a change to
the network type.
----End
6.7.9.4 Configuring Smart-discover
Context
Before Smart-discover is configured, when the neighbor status of the switch changes or the
DR/BDR on the multi-access network (broadcast or NBMA network) changes, the switch
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 switch changes or the DR/BDR on the multi-
access network (broadcast or NBMA network) changes, the switch 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:

undo portswitch

NOTE
Step 4 Run:
ospf smart-discover
Smart-discover is configured on the interface.
----End
6.7.9.5 Setting the Interval for Updating LSAs
Context
In OSPF, the interval for updating LSAs is defined as 5s. 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, changes to the topology or
the routes can be immediately advertised on the network through LSAs, thereby speeding up
route convergence on the network.
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, an 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. Details about the interval for updating LSAs are as follows:

1. The initial interval for updating LSAs is specified by start-interval.

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 Step 3.1 and updates LSAs at the
initial interval specified by start-interval.
----End
6.7.9.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, changes to the topology or
the routes can be immediately advertised on the network through LSAs, thereby speeding up
route convergence on the network.
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 changes to the topology or the routes can be detected
immediately.
By default, an 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:
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).
specified by max-interval, OSPF receives LSAs at the maximum interval for three
consecutive times. Then, OSPF goes back to step Step 3.1 and receives LSAs at the
initial interval specified by start-interval.
----End
6.7.9.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
setting a correct 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.

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).
specified by max-interval, OSPF performs the SPF calculation at the maximum interval
for three consecutive times. Then, OSPF goes back to step Step 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
6.7.10 Configuring OSPF GR
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 of 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.
Before configuring OSPF GR, complete the following tasks:
l Configuring IP addresses for interfaces to ensure that neighboring switches are reachable
l Configuring Basic OSPF Functions
6.7.10.1 Enabling the Opaque-LSA of OSPF

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
The OSPF GR feature is enabled.
----End
6.7.10.2 (Optional) Configuring the GR Session Parameters on the Restarter
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
graceful-restart [ period period | planned-only | partial ] *
The GR session parameters is set.

l Set period, the GR period on the Restarter is set. By default, the restart time is 120
seconds.
l Set planned-only, the Restarter supports only planned GR. By default, the Restarter
supports both planned GR and unplanned GR.
l Set partial, the Restarter supports partial GR. By default, the Restarter supports totally
GR.
----End
6.7.10.3 (Optional) Configuring GR Session Parameters on the Helper

Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [process-id]

Step 3 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 switch 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 planned GR. By default, the Helper supports
both planned GR and unplanned GR.
l Set never, the switch will not enter the Helper mode.
----End
Prerequisites
All configurations of OSPF GR are complete.
Procedure
l Run the display ospf [ process-id ] graceful-restart [ verbose ] command to check
information about OSPF GR.
----End
6.7.11 Improving the Stability of an OSPF Network
By configuring timers, you can reduce the number of unnecessary packets on networks and
reduce the load on the device to improve network performance.
Before improving the security of an OSPF network, complete the following task:
6.7.1 Configuring Basic OSPF Functions

required.
6.7.11.1 Setting the Priority of OSPF
Context
Routing protocols may share and select routing information because the switch 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.
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
6.7.11.2 Configuring the Delay in Transmitting LSAs on the Interface
Procedure
Step 1 Run:
system-view

Step 2 Run:


undo portswitch

NOTE
Step 4 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
6.7.11.3 Configuring the Interval for Retransmitting LSAs
Context
After sending an LSA packet to the neighboring switch, the switch waits for a response. If no
response is received within the set interval, the switch retransmits the LSA packet to the
neighboring switch.
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
ospf timer retransmit interval
The interval for retransmitting LSAs between adjacent switches is set.
By default, the interval for retransmitting LSAs is 5 seconds.

NOTE
The interval for retransmitting LSAs between adjacent switches cannot be set too small. Generally, the
interval needs to be larger than the round trip time of a packet transmitted between two switches.
Otherwise, certain LSAs are retransmitted unnecessarily.
----End
6.7.11.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 switch. This ensures an uninterrupted route on the switch during upgrades and other
maintenance operations.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
stub-router [ on-startup [ interval ] ]
A stub switch is configured.

By default, no switch is configured as a stub router.
If a switch is configured as a stub router, the switch continues to function as a stub router for
500s.
NOTE
There is no relationship between the stub switch configured through this command and the switch in a
stub area.
----End
6.7.11.5 Prohibiting an OSPF Interface from Sending and Receiving OSPF

Packets
Context
You can prohibit an OSPF interface from sending and receiving OSPF packets to prevent
local OSPF routing information from being obtained by devices on other networks. This
restriction also prevents the local device from receiving the routing update information
advertised by other devices on the same network.
After an OSPF interface is prohibited from sending and receiving OSPF packets, the interface
can still advertise its direct routes, but not Hello packets. Therefore, no neighbor relationship

can be set up between the device and its neighbor. The OSPF network becomes more adaptive
and network resources are saved.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
silent-interface { all | interface-type interface-number }
An OSPF interface is prohibited from sending and receiving OSPF packets.

By default, an interface is allowed to send and receive OSPF packets.
You can prohibit an interface from sending and receiving OSPF packets in different OSPF
processes, but the silent-interface command is valid only for the OSPF interface in the local
process.
----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
6.7.12 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 switch by simulating real OSPF unicast packets, the switch finds
that itself is the destination of the packets after the interface board receives these packets. The

switch directly sends the packets to the control plane for OSPF processing without checking
the validity of the packets. The switch 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 switch by checking whether the TTL value in the IP packet
header is in a pre-defined range to enhance the system security.
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.
6.7.12.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 packets that match 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 switch
connections for GTSM. If the packets sent from a switch 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 information about dropped packets. This
information facilitates fault location.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf valid-ttl-hops hops [ nonstandard-multicast ] [ vpn-instance vpn-instance-
name ]
OSPF GTSM functions are configured.

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 only the private network policy or the public network policy is configured, 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 criteria.
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 device in the system view. The information about the
packets dropped by GTSM is recorded in the log.
----End
6.7.12.2 Configuring the Area Authentication Mode
Context
In area authentication, all the switches 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 saving mode brings security risks. It is
Simple, MD5 authentication, and HMAC-MD5 cipher text authentication have potential
security risks. HMAC-SHA256 cipher text authentication is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run any of the following commands 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 } ]
The specified 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
Keychain authentication is configured for the OSPF area.

NOTE
Before using 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
6.7.12.3 Configuring the Interface Authentication Mode
Context
The interface authentication mode is used among neighbor switches 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 saving mode brings security
risks. It is recommended that you select cipher to save the password in cipher text.
Simple, MD5 authentication, and HMAC-MD5 cipher text authentication have potential
security risks. HMAC-SHA256 cipher text authentication is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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 } ]
The specified 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
Keychain authentication is configured for the OSPF area.

NOTE
Before using 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.
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
6.7.13 Configuring the Network Management Function of OSPF
OSPF supports the network management function. You can bind OSPF MIB to 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.
6.7.13.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 switch:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf mib-binding process-id
OSPF MIB binding is configured.
----End
6.7.13.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
6.7.13.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.
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
6.8 Maintaining OSPF
6.8.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 device.
----End
6.8.2 Resetting OSPF
Context
NOTICE
Running the reset ospf command will tear down the OSPF adjacency relationship between
the switches. 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
6.9.1 Example for Configuring Basic OSPF Functions
As shown in Figure 6-21, there are three switches on the network. Three switches need to
communicate with each other, and the entire network can be extended based on SwitchA and
SwitchB as the main service devices.
Figure 6-21 Networking diagram of configuring basic OSPF functions
Area1 SwitchA Area0

192.168.1.1/24 192.168.0.1/24
SwitchC VLANIF20 VLANIF10 SwitchB
GE0/0/2 GE0/0/1
GE0/0/1 GE0/0/1
VLANIF20 VLANIF10
192.168.1.2/24 192.168.0.2/24

1. Configure IP addresses and VLANs for the VLANIF interfaces on switches to
implement communication within network segments.
2. Configure basic OSPF functions on each switch. Configure SwitchA as the ABR to
divide the OSPF network to two areas Area0 and Area1 so that the entire OSPF network
can be extended using the area where SwitchA and SwitchB are located as the backbone
area.
Procedure
# Configure SwitchA. Ensure that the configurations of SwitchB and SwitchC are the same as
the configuration of SwitchA.

Step 3 Configure basic OSPF functions.

[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.1] return
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] return
[SwitchC-ospf-1] area 1


[SwitchC-ospf-1-area-0.0.0.1] return
# Check information about OSPF neighbors of SwitchA.

<SwitchA> display ospf peer
OSPF Process 1 with Router ID 10.1.1.1

Neighbors
Area 0.0.0.0 interface 192.168.0.1(Vlanif10)'s neighbors

Router ID: 10.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

DR: 192.168.1.2 BDR: 192.168.1.1 MTU: 0
# Check the OSPF routing information on SwitchC.

<SwitchC> display ospf routing

Routing Tables
Routing for Network

Destination Cost Type NextHop AdvRouter Area
192.168.1.0/24 1 Transit 192.168.1.2 10.3.3.3 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.1
Total Nets: 2
Intra Area: 1 Inter Area: 1 ASE: 0 NSSA: 0
The preceding command output shows that SwitchC has a route to the network segment
192.168.0.0/24 and the route is marked as an inter-area route.
# Check the routing table of SwitchB, and perform the ping operation to test the connectivity
between SwitchB and SwitchC.
<SwitchB> display ospf routing

Routing Tables
Routing for Network

192.168.0.0/24 1 Transit 192.168.0.2 10.2.2.2 0.0.0.0
192.168.1.0/24 2 Inter-area 192.168.0.1 10.1.1.1 0.0.0.0
Total Nets: 2
The preceding command output shows that SwitchB has a route to the network segment
192.168.1.0/24 and the route is marked as an inter-area route.

# Perform the ping operation on SwitchB to test the connectivity between SwitchB and
SwitchC.
<SwitchB> ping 192.168.1.2

0.00% packet loss
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
interface Vlanif10
ip address 192.168.0.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
#
#
#
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 SwitchB
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.0.2 255.255.255.0
#
#
area 0.0.0.0
network 192.168.0.0 0.0.0.255
#
return


#
sysname SwitchC
#
vlan batch 20
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
#
#
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
return
6.9.2 Example for Configuring OSPF DR Election

As shown in Figure 6-22, an OSPF network consists of five switches. Switch is a Layer 2
switch that connects the other four switches running OSPF. The default DR elected among the
four switches does not meet the network requirements. Therefore, SwitchA needs to be
elected as the DR to exchange LSA information with other devices on the OSPF network, and
SwitchC needs to be used as the backup of SwitchA. For other service demands, SwitchB
needs to exchange LSA information with other devices on the OSPF network through the DR.
Figure 6-22 Networking diagram of configuring OSPF DR election
SwitchA SwitchB
GE0/0/1 G GE0/0/1
E0
2 /
VLANIF10
/0
VLANIF10 /0
E0
192.168.1.1/24 /1 192.168.1.2/24
G
G
3
E0
/
/0
GE0/0/1 Switch GE0/0/1

E0
/0
VLANIF10 /4 VLANIF10
G
192.168.1.3/24 192.168.1.4/24
SwitchC SwitchD
1. Configure basic OSPF functions on each switch and check the default DR election
among the four switches.
2. Configure the DR priorities for interfaces on SwitchA, SwitchB, and SwitchC to 100, 0,
and 2 respectively. In this way, SwitchA is elected as the DR and SwitchC as the BDR,

SwitchB never becomes the DR or BDR, and SwitchD uses the default DR priority and
remains unchanged.
Procedure
# Configure SwitchA. Ensure that the configurations of Switch, SwitchB, SwitchC, and
SwitchD are the same as the configuration of SwitchA.
[SwitchA] vlan batch 10

# Configure SwitchA. Ensure that the configurations of SwitchB, SwitchC, and SwitchD are
the same as the configuration of SwitchA.

[SwitchD] ospf 1 router-id 10.4.4.4
[SwitchD-ospf-1] area 0
[SwitchD-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[SwitchD-ospf-1-area-0.0.0.0] quit
[SwitchD-ospf-1] quit
[SwitchD] quit
# Check information about OSPF neighbors on SwitchA.

[SwitchA] 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
The preceding command output shows that SwitchD is the DR and SwitchC is the BDR by
default. When the DR priorities are the same, the device with a higher router ID is elected as
the DR.
Step 4 Set the DR priority on each switch interface.
[SwitchA-Vlanif10] ospf dr-priority 100
[SwitchA] quit
[SwitchB-Vlanif10] ospf dr-priority 0
[SwitchB] quit
[SwitchC-Vlanif10] ospf dr-priority 2
[SwitchC] quit
# Check information about OSPF neighbors on SwitchD.

<SwitchD> 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
The preceding command output shows that the DR election among the four switches does not
change. When the DR and BDR election is complete, a new device cannot immediately
become the DR on the network segment even if the device has the highest DR priority. The
DR are BDR are elected again only after the OSPF process is restarted.
Step 5 Restart the OSPF process.
# In the user view of each switch, run the reset ospf 1 process command to restart the OSPF
process. The simultaneous restart of the OSPF process enables each switch to participate in
elections of the DR and BDR.
# Restart SwitchA.
<SwitchA> reset ospf 1 process
# Restart SwitchB.
<SwitchB> reset ospf 1 process
# Restart SwitchC.
<SwitchC> reset ospf 1 process
# Restart SwitchD.
<SwitchD> reset ospf 1 process

# Check information about OSPF neighbors on SwitchD.
<SwitchD> display ospf peer

Neighbors

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

State: 2-Way Mode:Nbr is Master Priority: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0


DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
The preceding command output shows that SwitchA is elected as the DR and SwitchC as the
BDR. The neighbor status between SwitchD and SwitchB is 2-Way; neither of them is the DR
or BDR and they do not need to exchange LSA information.
----End
Configuration Files
l Configuration file of Switch
#
sysname Switch
#
vlan batch 10
#
#
#
#
#
return

#
sysname SwitchA
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
ospf dr-priority 100
#
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 10

#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
ospf dr-priority 0
#
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname SwitchC
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.3 255.255.255.0
ospf dr-priority 2
#
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname SwitchD
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.4 255.255.255.0
#
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
6.9.3 Example for Configuring an OSPF Stub Area

As shown in Figure 6-23, the OSPF protocol is run among three switches, the entire OSPF
network is divided into two areas Area0 and Area1, and SwitchB functions as the ASBR to
communicate with external networks. The scale of the OSPF routing table on SwitchC needs
to be reduced without affect the communication.

Figure 6-23 Networking diagram of configuring an OSPF stub area
SwitchA
192.168.1.2/24 192.168.0.2/24
VLANIF20 Area1 Area0 VLANIF10 ASBR
GE0/0/1 GE0/0/1
GE0/0/2 GE0/0/1
192.168.1.1/24 192.168.0.1/24
Stub
1. Configure basic OSPF functions on each switch to implement basic connections on the
OSPF network.
2. Configure static routes on SwitchB and import them to the OSPF routing table so that
there are reachable routes between the OSPF network and external networks.
3. Configure Area1 as a stub area to gradually reduce the scale of the OSPF routing table
on SwitchC.
4. Disable the ABR (SwitchA) from advertising Type 3 LSA to Area1 to be configured as a
totally stub area. This greatly reduces the scale of the OSPF routing table on SwitchC.
Procedure

Ensure that the configurations of SwitchB and SwitchC are the same as the configuration of
SwitchA. (The details are omitted.)


Step 4 # Configure SwitchB to import static routes.

[SwitchB] ip route-static 10.0.0.0 8 null 0
[SwitchB] ospf 1
[SwitchB-ospf-1] import-route static type 1
# Check the OSPF routing table of SwitchC. The AS external routes exist in the table.
[SwitchC] display ospf routing

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.2 10.3.3.3 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.1
Routing for ASEs

Destination Cost Type Tag NextHop AdvRouter
10.0.0.0/8 3 Type1 1 192.168.1.1 10.2.2.2
Total Nets: 3
Step 5 Configure Area1 as a stub area.

[SwitchA] ospf 1
[SwitchA-ospf-1-area-0.0.0.1] stub
[SwitchC] ospf 1
[SwitchC-ospf-1-area-0.0.0.1] stub

# Check the OSPF routing table of SwitchC. The AS external routes do not exist in the table,
but a default route to the external is added.

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.2 10.3.3.3 0.0.0.1
0.0.0.0/0 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.1
Total Nets: 3
Step 6 Configure Area1 as a totally stub area.

[SwitchA] ospf 1
[SwitchA-ospf-1-area-0.0.0.1] stub no-summary

# Check the OSPF routing table of SwitchC. The route with the destination address
192.168.0.0/24 does not exist in the table, but the intra-area OSPF routes and a default route
to the external are reserved.

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.2 10.3.3.3 0.0.0.1
0.0.0.0/0 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.1
Total Nets: 2
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
interface Vlanif10
ip address 192.168.0.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
#
#


#
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 SwitchB
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.0.2 255.255.255.0
#
#
import-route static type 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
#
ip route-static 10.0.0.0 255.0.0.0 NULL0
#
return

#
sysname SwitchC
#
vlan batch 20
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
#
#
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
#
return
6.9.4 Example for Configuring an OSPF NSSA
As shown in Figure 6-24, the OSPF protocol is run among four switches and the entire OSPF
network is divided into two areas Area0 and Area1. It is required that the devices in Area1
should not receive external route information imported by other OSPF areas and the switches
in Area1 should import external routes through the intra-area devices to communicate with
external networks. In addition, many services are configured on SwitchB; therefore, SwitchA
needs to be specified as a translator to translate Type7 LSA to Type5 LSA and send it to other
OSPF areas.

Figure 6-24 Networking diagram of configuring an OSPF NSSA

Area1 Area0
192.168.3.1/24 SwitchA 192.168.1.1/24
192.168.3.2/24 VLANIF30 VLANIF10 192.168.1.2/24
VLANIF30 GE0/0/1 GE0/0/2 VLANIF10
GE0/0/1 GE0/0/1
192.168.4.2/24 192.168.2.1/24
VLANIF40 VLANIF20
SwitchD GE0/0/2 GE0/0/1 GE0/0/2 GE0/0/2 SwitchC
ASBR VLANIF40 VLANIF20
192.168.4.1/24 192.168.2.2/24
NSSA SwitchB
OSPF network.
2. Configure Area1 as an NSSA, configure static routes on SwitchD, and import them to
the OSPF routing table. In this way, the switches in Area1 can communicate with
external networks through SwitchD.
3. Configure SwitchA as a translator so that SwitchA is specified to translate Type7 LSA to
Type5 LSA and send it to other OSPF areas.
Procedure
# Configure SwitchA.Ensure that the configurations of SwitchB, SwitchC, and SwitchD are
# Configure SwitchA.Ensure that the configurations of SwitchB, SwitchC, and SwitchD are


Step 4 Configure Area1 as an NSSA.

[SwitchA] ospf 1
[SwitchA-ospf-1-area-0.0.0.1] nssa
[SwitchB] ospf 1
[SwitchB-ospf-1-area-0.0.0.1] nssa
[SwitchD] ospf 1
[SwitchD-ospf-1-area-0.0.0.1] nssa
Step 5 Configure SwitchD to import static routes.

[SwitchD] ip route-static 172.16.0.0 16 null 0

[SwitchD] ospf 1
[SwitchD-ospf-1] import-route static
# Check the OSPF routing table on SwitchC.


Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.2 10.3.3.3 0.0.0.0
192.168.2.0/24 1 Transit 192.168.2.2 10.3.3.3 0.0.0.0
192.168.3.0/24 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.0
192.168.4.0/24 2 Inter-area 192.168.2.1 10.2.2.2 0.0.0.0
Routing for ASEs

172.16.0.0/16 1 Type2 1 192.168.1.1 10.2.2.2
Total Nets: 5
The preceding command output shows that the AS external routes imported by the NSSA are
advertised to other areas through SwitchB that translates Type7 LSA to Type5 LSA. OSPF
selects the ABR with a larger router ID as a translator.
Step 6 Configure SwitchA as a translator.
[SwitchA] ospf 1
[SwitchA-ospf-1-area-0.0.0.1] nssa translator-always

# Check the OSPF routing table on SwitchC after 40 seconds.

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.2 10.3.3.3 0.0.0.0
192.168.2.0/24 1 Transit 192.168.2.2 10.3.3.3 0.0.0.0
192.168.3.0/24 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.0
192.168.4.0/24 2 Inter-area 192.168.2.1 10.2.2.2 0.0.0.0
Routing for ASEs

172.16.0.0/16 1 Type2 1 192.168.1.1 10.1.1.1
Total Nets: 5
The preceding command output shows that the AS external routes imported by the NSSA are
advertised to other areas through SwitchA that functions as a translator.
NOTE
By default, the new translator plays a translator role together with the original translator for 40 seconds.
After 40 seconds, only the new translator takes over the job.
----End

Configuration Files
#
sysname SwitchA
#
vlan batch 10 30
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
#
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
area 0.0.0.1
network 192.168.3.0 0.0.0.255
nssa translator-always
#
return

#
sysname SwitchB
#
vlan batch 20 40
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif40
ip address 192.168.4.2 255.255.255.0
#
#
#
area 0.0.0.0
network 192.168.2.0 0.0.0.255
area 0.0.0.1
network 192.168.4.0 0.0.0.255
nssa
#
return

#
sysname SwitchC
#
vlan batch 10 20
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#

interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
#
#
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return

#
sysname SwitchD
#
vlan batch 30 40
#
interface Vlanif30
ip address 192.168.3.2 255.255.255.0
#
interface Vlanif40
ip address 192.168.4.1 255.255.255.0
#
#
#
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
6.9.5 Example for Configuring OSPF Load Balancing
As shown in Figure 6-25, there are four switches all belonging to Area0 on the OSPF
network. Load balancing needs to be configured so that the traffic of SwitchA is sent to
SwitchD through SwitchB and SwitchC.

Figure 6-25 Networking diagram for configuring load balancing among OSPF routes
SwitchB
10.1.1.2/24 192.168.0.1/24
VLANIF10 VLANIF30
GE0/0/1 GE0/0/2
172.16.1.1/24 172.17.1.1/24
GE0/0/3 VLANIF10 VLANIF30 GE0/0/3
10.1.1.1/24 192.168.0.2/24
SwitchA SwitchD
GE0/0/2 Area0 GE0/0/2
VLANIF20 VLANIF40
10.1.2.1/24 192.168.1.2/24
GE0/0/1 GE0/0/2
VLANIF20 VLANIF40
10.1.2.2/24 192.168.1.1/24
SwitchC
OSPF network.
2. Configure load balancing on SwitchA.
Procedure
[SwitchA] vlan batch 10 20 50





------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Vlanif20
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
172.16.1.0/24 Direct 0 0 D 172.16.1.1 Vlanif50
172.16.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.17.1.0/24 OSPF 10 3 D 10.1.1.2 Vlanif10
OSPF 10 3 D 10.1.2.2 Vlanif20
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Vlanif20
As shown in the routing table, the next hops of SwitchA, that is, 10.1.1.2 (SwitchB) and
10.1.2.2 (SwitchC), become valid routes. This is because the default number of equal-cost
routes is 8.

Step 4 Configure the weight of equal-cost routes on SwitchA.

If you do not want to implement load balancing between SwitchB and SwitchC, set the weight
of equal-cost routes to specify the next hop.
[SwitchA] ospf 1
[SwitchA-ospf-1] nexthop 10.1.2.2 weight 1

------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Vlanif20
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
172.16.1.0/24 Direct 0 0 D 172.16.1.1 Vlanif50
172.16.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.17.1.0/24 OSPF 10 3 D 10.1.2.2 Vlanif20
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Vlanif20
As shown in the routing table, the priority of the next hop 10.1.2.2 (SwitchC) with the weight
as 1 is higher than that of 10.1.1.2 (SwitchB), after the weight is set for equal-cost routes.
OSPF selects the route with the next hop 10.1.2.2 as the optimal route.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 50
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
#
interface Vlanif50
ip address 172.16.1.1 255.255.255.0
#
#
#
#

nexthop 10.1.2.2 weight 1

area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 10 30
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif30
ip address 192.168.0.1 255.255.255.0
#
#
#
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 20 40
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
#
interface Vlanif40
ip address 192.168.1.1 255.255.255.0
#
#
#
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
return
#
sysname SwitchD
#
vlan batch 30 40 60
#
interface Vlanif30
ip address 192.168.0.2 255.255.255.0

#
interface Vlanif40
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif60
ip address 172.17.1.1 255.255.255.0
#
#
#
#
area 0.0.0.0
network 172.17.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
return
6.9.6 Example for Configuring OSPF-BGP
As shown in Figure 6-26, an EBGP connection is established between SwitchD and SwitchE.
IBGP connections are established between switches in AS 10, and OSPF is used as an IGP
protocol. OSPF-BGP needs to be enabled on SwitchB so that the traffic from SwitchA to AS
20 will not be interrupted after SwitchB restarts.
Figure 6-26 Networking diagram of configuring OSPF-BGP
Loopback0
10.10.10.3/32
GE0/0/2 GE0/0/1
VLANIF20 VLANIF30
10.1.2.2/30 10.1.4.1/30
GE0/0/2 GE0/0/2
SwitchC Loopback0 VLANIF60
VLANIF20 GE0/0/1 10.10.10.4/32 10.3.1.1/30
10.1.2.1/30
10.10.10.1/32
VLANIF30
Loopback0
SwitchE
10.1.4.2/30 EBGP
SwitchA SwitchD
GE0/0/2 GE0/0/3 GE0/0/1
GE0/0/1 VLANIF40 VLANIF50 VLANIF50
VLANIF10 10.1.3.2/30 10.2.1.1/30 10.2.1.2/30
10.1.1.1/30 SwitchB Loopback0
GE0/0/1 GE0/0/2 10.10.10.5/32
VLANIF10 VLANIF40
10.1.1.2/30 10.1.3.1/30
Loopback0
10.10.10.2/32 AS 10 AS 20

1. Configure IP addresses and VLANs for the VLANIF interfaces on switches to
implement communication within network segments.
2. Configure basic OSPF functions and IBGP connections on SwitchA, SwitchB, SwitchC,
and SwitchD (excluding 10.2.1.1/30) to implement device connections within AS 10.
3. Configure EBGP connections between SwitchD and SwitchE, and import direct routes
and OSPF routes to implement communication between AS 10 and AS 20.
4. Set the OSPF protocol cost is set to 2 on SwitchC so that SwitchA only selects SwitchB
as the intermediate router to the network segment 10.2.1.0 and SwitchC becomes the
backup of SwitchB.
5. OSPF-BGP needs to be enabled on SwitchB so that the traffic from SwitchA to AS 20
will not be interrupted after SwitchB restarts.
Procedure
Step 2 Assign IP addresses for the VLANIF interfaces and LoopBack interfaces.
[SwitchA] interface loopback 0
[SwitchA-LoopBack0] ip address 10.10.10.1 32
[SwitchA-LoopBack0] quit

[SwitchA] router id 10.10.10.1
[SwitchA] ospf 1


Step 4 Configure IBGP fully meshed connections.

[SwitchA] bgp 10
[SwitchA-bgp] peer 10.10.10.2 as-number 10
[SwitchA-bgp] peer 10.10.10.2 connect-interface LoopBack 0
[SwitchA-bgp] quit
[SwitchB] bgp 10
[SwitchB-bgp] peer 10.10.10.1 as-number 10
[SwitchB-bgp] peer 10.10.10.1 connect-interface LoopBack 0
[SwitchB-bgp] quit
[SwitchC] bgp 10
[SwitchC-bgp] peer 10.10.10.1 as-number 10
[SwitchC-bgp] peer 10.10.10.1 connect-interface LoopBack 0
[SwitchC-bgp] quit
[SwitchD] bgp 10
[SwitchD-bgp] peer 10.10.10.1 as-number 10
[SwitchD-bgp] peer 10.10.10.1 connect-interface LoopBack 0
[SwitchD-bgp] quit
Step 5 Establish an EBGP connection.

[SwitchD] bgp 10
[SwitchD-bgp] import-route direct
[SwitchD-bgp] import-route ospf 1
[SwitchD-bgp] quit
# Configure SwitchE.
[SwitchE] bgp 20
[SwitchE-bgp] router-id 10.10.10.5
[SwitchE-bgp] peer 10.2.1.1 as-number 10
[SwitchE-bgp] ipv4-family unicast
[SwitchE-bgp-af-ipv4] network 10.3.1.0 30
[SwitchE-bgp-af-ipv4] quit
[SwitchE-bgp] quit

Step 6 Configure the OSPF protocol cost on SwitchC.

[SwitchC-Vlanif20] ospf cost 2
[SwitchC-Vlanif30] ospf cost 2
# Check the routing table on SwitchA. As shown in the routing table, the route to the
destination network segment 10.3.1.0 is learned through BGP, and the outbound interface is
Vlanif10.
------------------------------------------------------------------------------
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/30 Direct 0 0 D 10.1.2.1 Vlanif20
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.1.3.0/30 OSPF 10 2 D 10.1.1.2 Vlanif10
10.1.4.0/30 OSPF 10 3 D 10.1.2.2 Vlanif20
OSPF 10 3 D 10.1.1.2 Vlanif10
10.2.1.0/30 IBGP 255 0 RD 4.4.4.4 Vlanif10
10.3.1.0/30 IBGP 255 0 RD 10.2.1.2 Vlanif10
10.10.10.2/32 OSPF 10 1 D 10.1.1.2 Vlanif10
10.10.10.3/32 OSPF 10 1 D 10.1.2.2 Vlanif20
10.10.10.4/32 OSPF 10 2 D 10.1.1.2 Vlanif10
# Check the routing table of SwitchB.

------------------------------------------------------------------------------
10.1.1.0/30 Direct 0 0 D 10.1.1.2 Vlanif10

10.1.1.2/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/30 OSPF 10 2 D 10.1.1.1 Vlanif10
10.1.3.0/30 Direct 0 0 D 10.1.3.1 Vlanif40
10.1.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif40
10.1.4.0/30 OSPF 10 2 D 10.1.3.2 Vlanif40
10.2.1.0/30 IBGP 255 0 RD 4.4.4.4 Vlanif40
10.3.1.0/30 IBGP 255 0 RD 10.2.1.2 Vlanif40
10.10.10.1/32 OSPF 10 1 D 10.1.1.1 Vlanif10
10.10.10.3/32 OSPF 10 2 D 10.1.1.1 Vlanif10
OSPF 10 2 D 10.1.3.2 Vlanif40
10.10.10.4/32 OSPF 10 1 D 10.1.3.2 Vlanif40
As shown in the routing table, the route to the destination network segment 10.3.1.0 is learned
by SwitchB through BGP, and the outbound interface is Vlanif40. The routes to the network
segments 10.1.2.0 and 10.1.4.0 can be learned through OSPF. The costs of these routes are the
same, namely, 2.

Step 7 Configure OSPF-BGP on SwitchB.

[SwitchB] ospf
[SwitchB-ospf-1] stub-router on-startup
[SwitchB-ospf-1] return

# Save the configuration.
<SwitchB> save
The system displays a message to tell you that the current configuration will be saved and ask
you whether to continue. Entery y.
# Restart SwitchB.
<SwitchB> reboot
The system displays a message to tell you that the system will reboot and ask you whether to
continue. Entery y.
# Check the routing table on SwitchA. As shown in the routing table, the route to the
destination network segment 10.3.1.0 is learned through BGP, and the outbound interface is
Vlanif20.
<SwitchA> display ip routing-table
------------------------------------------------------------------------------
10.1.2.0/30 Direct 0 0 D 10.1.2.1 Vlanif20

10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.1.4.0/30 OSPF 10 3 D 10.1.2.2 Vlanif20
10.2.1.0/30 IBGP 255 0 RD 4.4.4.4 Vlanif20
10.3.1.0/30 IBGP 255 0 RD 10.2.1.2 Vlanif20
10.10.10.3/32 OSPF 10 1 D 10.1.2.2 Vlanif20
10.10.10.4/32 OSPF 10 3 D 10.1.2.2 Vlanif20
# Check the routing table of SwitchB. As shown in the routing table, only OSPF routes exist
in the routing table temporarily and their costs are at least 65535. This is because IGP routes
can be converged faster than BGP routes.
<SwitchB> display ip routing-table
------------------------------------------------------------------------------
10.1.1.0/30 Direct 0 0 D 10.1.1.2 Vlanif10

10.1.1.2/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/30 OSPF 10 65536 D 10.1.1.1 Vlanif10
10.1.3.0/30 Direct 0 0 D 10.1.3.1 Vlanif40
10.1.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif40
10.1.4.0/30 OSPF 10 65536 D 10.1.3.2 Vlanif40
10.10.10.1/32 OSPF 10 65535 D 10.1.1.1 Vlanif10
10.10.10.3/32 OSPF 10 65536 D 10.1.1.1 Vlanif10
OSPF 10 65536 D 10.1.3.2 Vlanif40
10.10.10.4/32 OSPF 10 65535 D 10.1.3.2 Vlanif40


# After the network is stable, check the routing table of SwitchB again.
<SwitchB> display ip routing-table
------------------------------------------------------------------------------
10.1.1.0/30 Direct 0 0 D 10.1.1.2 Vlanif10

10.1.1.2/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/30 OSPF 10 2 D 10.1.1.1 Vlanif10
10.1.3.0/30 Direct 0 0 D 10.1.3.1 Vlanif40
10.1.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif40
10.1.4.0/30 OSPF 10 2 D 10.1.3.2 Vlanif40
10.2.1.0/30 IBGP 255 0 RD 4.4.4.4 Vlanif40
10.3.1.0/30 IBGP 255 0 RD 10.2.1.2 Vlanif40
10.10.10.1/32 OSPF 10 1 D 10.1.1.1 Vlanif10
10.10.10.3/32 OSPF 10 2 D 10.1.1.1 Vlanif10
OSPF 10 2 D 10.1.3.2 Vlanif40
10.10.10.4/32 OSPF 10 1 D 10.1.3.2 Vlanif40
As shown in the routing table, after BGP routes on SwitchB are converged, the routing
information is restored to the one that is displayed before the restart.
----End
Configuration Files
#
sysname SwitchA
#
router id 10.10.10.1
#
vlan batch 10 20
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.252
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.252
#
#
#
interface LoopBack0
ip address 10.10.10.1 255.255.255.255
#
bgp 10
peer 10.10.10.2 as-number 10
peer 10.10.10.2 connect-interface LoopBack0

#
ipv4-family unicast
undo synchronization
peer 10.10.10.2 enable
#
ospf 1
area 0.0.0.0
network 10.10.10.1 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.1.2.0 0.0.0.3
#
return
#
sysname SwitchB
#
#
vlan batch 10 40
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.252
#
interface Vlanif40
ip address 10.1.3.1 255.255.255.252
#
#
#
interface LoopBack0
ip address 10.10.10.2 255.255.255.255
#
bgp 10
#
ipv4-family unicast
#
ospf 1
stub-router on-startup
area 0.0.0.0
network 10.10.10.2 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.1.3.0 0.0.0.3
#
return
#
sysname SwitchC
#
#
vlan batch 20 30

#
interface Vlanif20
ip address 10.1.2.2 255.255.255.252
ospf cost 2
#
interface Vlanif30
ip address 10.1.4.1 255.255.255.252
ospf cost 2
#
#
#
interface LoopBack0
ip address 10.10.10.3 255.255.255.255
#
bgp 10
#
ipv4-family unicast
#
ospf 1
area 0.0.0.0
network 10.10.10.3 0.0.0.0
network 10.1.2.0 0.0.0.3
network 10.1.4.0 0.0.0.3
#
return
#
sysname SwitchD
#
#
vlan batch 30 40 50
#
interface Vlanif30
ip address 10.1.4.2 255.255.255.252
#
interface Vlanif40
ip address 10.1.3.2 255.255.255.252
#
interface Vlanif50
ip address 10.2.1.1 255.255.255.252
#
#
#

#
interface LoopBack0
ip address 10.10.10.4 255.255.255.255
#
bgp 10
#
ipv4-family unicast
import-route direct
import-route ospf 1
#
ospf 1
area 0.0.0.0
network 10.10.10.4 0.0.0.0
network 10.1.3.0 0.0.0.3
network 10.1.4.0 0.0.0.3
#
return
l Configuration file of SwitchE

#
sysname SwitchE
#
vlan batch 50 60
#
interface Vlanif50
ip address 10.2.1.2 255.255.255.252
#
interface Vlanif60
ip address 10.3.1.1 255.255.255.252
#
#
#
interface LoopBack0
ip address 10.10.10.5 255.255.255.255
#
bgp 20
router-id 10.10.10.5
#
ipv4-family unicast
network 10.3.1.0 255.255.255.252
#
return
6.9.7 Example for Configuring OSPF GR

As shown in Figure 6-27, the OSPF protocol is run among three devices and the entire OSPF
network is divided into two areas Area0 and Area1. It is required that data forwarding should
not be affected during the restart process of the OSPF protocol run on SwitchC.
Figure 6-27 Networking diagram for configuring OSPF GR
Area1 SwitchA Area0

192.168.1.1/24 192.168.0.1/24
GE0/0/2 GE0/0/1
GE0/0/1 GE0/0/1
VLANIF20 VLANIF10
192.168.1.2/24 192.168.0.2/24
OSPF network.
2. Enable the Opaque LSA function on SwitchA and SwitchC so that OSPF supports OSPF
GR through Type9 LSA.
3. Configure the GR function on SwitchA and SwitchC so that data is forwarded properly
when the OSPF protocol restarts.
Procedure




Step 4 Enable the Opaque LSA function.

[SwitchA] ospf 1
[SwitchA-ospf-1] opaque-capability enable
[SwitchC] ospf 1
[SwitchC-ospf-1] opaque-capability enable
Step 5 Configure the OSPF GR feature.

[SwitchA] ospf 1
[SwitchA-ospf-1] graceful-restart
[SwitchA-ospf-1] return
[SwitchC] ospf 1
[SwitchC-ospf-1] graceful-restart
[SwitchC-ospf-1] return

# Check the GR status of SwitchC.
<SwitchC> display ospf graceful-restart

Graceful-restart capability : enabled
Graceful-restart support : planned and un-planned, totally
Helper-policy support : planned and un-planned, strict lsa check

Current GR state : normal

Graceful-restart period : 120 seconds
Number of neighbors under helper:

Normal neighbors : 0
Virtual neighbors : 0
Sham-link neighbors : 0
Total neighbors : 0
Number of restarting neighbors : 0
Last exit reason:

On graceful restart : none
On Helper : none
# Check the neighbor status on SwitchA.


Neighbors

Router ID: 10.2.2.2 Address: 192.168.0.2 GR State: Normal
DR: 192.168.0.2 BDR: 192.168.0.1 MTU: 0
Neighbors

DR: 192.168.1.1 BDR: 192.168.1.2 MTU: 0
The preceding command output shows that the OSPF neighbor status of SwitchA is Full and
GR status is Normal.
# Restart the OSPF process of SwitchC gracefully.
<SwitchC> reset ospf process graceful-restart
# Check the neighbor status on SwitchA.


Neighbors

DR: 192.168.0.2 BDR: 192.168.0.1 MTU: 0
Neighbors


DR: 192.168.1.1 BDR: 192.168.1.2 MTU: 0

The preceding command output shows that the neighbor status of SwitchA and SwitchC is
still Full without being affected by the graceful restart of the OSPF process of SwitchC.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
interface Vlanif10
ip address 192.168.0.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
#
#
#
graceful-restart
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 SwitchB
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.0.2 255.255.255.0
#
#
area 0.0.0.0
network 192.168.0.0 0.0.0.255
#
return

#
sysname SwitchC
#
vlan batch 20
#

interface Vlanif20
ip address 192.168.1.2 255.255.255.0
#
#
graceful-restart
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
return
6.9.8 Example for Configuring BFD for OSPF
As shown in Figure 6-28, OSPF is run among SwitchA, SwitchB, and SwitchC, and the
switch between SwitchA and SwitchB only provides the transparent transmission function.
SwitchA and SwitchB need to quickly detect the status of the link between them. When the
link SwitchA-SwitchB is faulty, services can be quickly switched to the backup link SwitchA-
SwitchC-SwitchB.
Figure 6-28 Networking diagram of configuring BFD for OSPF
Area0
10.3.3.1/24 10.3.3.2/24
SwitchA VLANIF30 VLANIF30 SwitchB
GE0/0/2 GE0/0/1
GE0/0/3
GE0/0/1 VLANIF40
GE0/0/2
VLANIF10 172.16.1.1/24
VLANIF20
10.1.1.1/24
10.2.2.2/24
GE0/0/1 GE0/0/2
VLANIF10 VLANIF20
10.1.1.2/24 10.2.2.1/24
SwitchC
OSPF network.
2. Configure BFD for OSPF on each switch so that services can be quickly switched to the
backup link when the link between SwitchA and SwitchB is faulty.

Procedure


# After the preceding configurations, run the display ospf peer command. The neighbor
relationships are established among SwitchA, SwitchB, and SwitchC. The command output of
SwitchA is used as an example.
[SwitchA] display ospf peer

Neighbors

DR: 10.1.1.2 BDR: 10.1.1.1 MTU: 0
Neighbors

DR: 10.3.3.2 BDR: 10.3.3.1 MTU: 0
# Check the OSPF routing table on SwitchA. You can see the routing entries to SwitchB and
SwitchC. However, the next-hop address of the route to the destination network segment
172.16.1.0/24 is 10.3.3.2, which indicates that the traffic is transmitted on the link
SwitchA→SwitchB.
[SwitchA] display ospf routing

Routing Tables
Routing for Network

10.1.1.0/24 1 Transit 10.1.1.1 10.10.10.1 0.0.0.0
10.2.2.0/24 2 Transit 10.1.1.2 10.10.10.3 0.0.0.0
10.2.2.0/24 2 Transit 10.3.3.2 10.10.10.3 0.0.0.0
10.3.3.0/24 1 Transit 10.3.3.1 10.10.10.1 0.0.0.0
172.16.1.0/24 2 Stub 10.3.3.2 10.10.10.2 0.0.0.0
Total Nets: 5
Step 4 Configure BFD for OSPF.
# Configure BFD for OSPF on SwitchA.

[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] ospf 1
[SwitchA-ospf-1] bfd all-interfaces enable
# Configure BFD for OSPF on SwitchB.

[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] ospf 1
[SwitchB-ospf-1] bfd all-interfaces enable
# Configure BFD for OSPF on SwitchC.

[SwitchC] bfd
[SwitchC-bfd] quit
[SwitchC] ospf 1
[SwitchC-ospf-1] bfd all-interfaces enable

# After the preceding configurations, run the display ospf bfd session all command on
SwitchA, SwitchB, or SwitchC. The peer BFD session is Up. The command output on
SwitchA is used as an example.
[SwitchA] display ospf bfd session all

Area 0.0.0.0 interface 10.1.1.1(Vlanif10)'s BFD Sessions
NeighborId:10.10.10.3 AreaId:0.0.0.0 Interface:Vlanif10

BFDState:up rx :1000 tx :1000
Multiplier:3 BFD Local Dis:8195 LocalIpAdd:10.1.1.1
RemoteIpAdd:10.1.1.2 Diagnostic Info:No diagnostic information
Area 0.0.0.0 interface 10.3.3.1(Vlanif30)'s BFD Sessions
NeighborId:10.10.10.2 AreaId:0.0.0.0 Interface:Vlanif30

BFDState:up rx :1000 tx :1000
Multiplier:3 BFD Local Dis:8194 LocalIpAdd:10.3.3.1
RemoteIpAdd:10.3.3.2 Diagnostic Info:No diagnostic information

# Run the shutdown command on GE0/0/1 of SwitchB to simulate the link fault.
# Check the OSPF routing table on SwitchA.


Routing Tables
Routing for Network

10.1.1.0/24 1 Transit 10.1.1.1 10.10.10.1 0.0.0.0
10.2.2.0/24 2 Transit 10.1.1.2 10.10.10.3 0.0.0.0
10.3.3.0/24 1 Stub 10.3.3.1 10.10.10.1 0.0.0.0
172.16.1.0/24 3 Stub 10.1.1.2 10.10.10.2 0.0.0.0
Total Nets: 4
When the link SwitchA-SwitchB is faulty, the backup link SwitchA-SwitchC-SwitchB takes
effect and the next-hop address of the route to the destination network segment 172.16.1.0/24
changes to 10.1.1.2.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 30
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif30
ip address 10.3.3.1 255.255.255.0
#

#
#
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.3.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 20 30 40
#
bfd
#
interface Vlanif20
ip address 10.2.2.2 255.255.255.0
#
interface Vlanif30
ip address 10.3.3.2 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
#
#
#
area 0.0.0.0
network 10.2.2.0 0.0.0.255
network 10.3.3.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 10 20
#
bfd
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif20
ip address 10.2.2.1 255.255.255.0
#


#
#
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return
6.10 Common Misconfigurations
6.10.1 OSPF Neighbor Relationship Cannot Be Established
Fault Symptom
OSPF neighbor relationship cannot be established between two devices.
Procedure
Step 1 Check whether the physical status and protocol status of interfaces on both ends are Up and
stable, whether packets are lost on the interfaces, and whether the two devices can ping each
other with large packets.
If the physical status of the interfaces is not Up or unstable (interfaces flap for example),
check the physical link and link layer protocol and ensure that the physical status and protocol
status of the interfaces are Up and the interfaces have no error packet statistics.
You can perform a ping test for a long time to check whether packets are lost on the interfaces
and ping with large packets (longer than 1500 bytes) to check whether the two devices can
ping each other with large packets.
Step 2 Check whether the two devices have the same OSPF process router ID.
Run the display ospf [ process-id ] brief command on the two devices to check the OSPF
process router ID.
Each router ID in an OSPF process must be unique. Otherwise, devices on both ends cannot
establish OSPF neighbor relationships and routing information will be incorrect. You need to
configure a unique router ID for each OSPF process on the devices.
If the two devices have the same OSPF process router ID, run the ospf [ process-id ] router-
id router-id command in the system view to change the OSPF process router ID and ensure
that the two devices have different OSPF process router IDs.
After changing the OSPF process router ID, you must run the reset ospf [ process-id ]
process command in the user view to make the configured router ID take effect.
Step 3 Check whether the two devices have the same OSPF area ID.
Run the display ospf [ process-id ] brief command on the two devices to check the OSPF
area ID.

If the two devices have different OSPF area IDs, run the area area-id command in the OSPF
view to change the OSPF area ID and ensure that the two devices have the same OSPF area
ID.
Step 4 Check whether OSPF interfaces on both ends have the same network type.
Run the display ospf [ process-id ] interface command on the two devices to check the OSPF
interface network type.
The network types of the OSPF interfaces on both ends of a link must be the same; otherwise,
the two interfaces cannot establish an OSPF neighbor relationship.
If the network types of the two OSPF interfaces are different, run the ospf network-type
{ broadcast | nbma | p2mp | p2p } command in the OSPF interface view to change the OSPF
interface network type and ensure that the two OSPF interfaces have the same network type.
NOTE
If the network types of OSPF interfaces on both ends are both NBMA, you must run the peer ip-address
[ dr-priority priority ] command in the OSPF view to configure NBMA neighbors.
Step 5 Check whether OSPF interfaces on both ends have the same IP address mask.
Run the display current-configuration interface interface-type interface-number command
on the two devices to check the IP address of the specified OSPF interface.
The IP address masks of the OSPF interfaces on both ends of a link must be the same;
otherwise, the two interfaces cannot establish an OSPF neighbor relationship. On a P2MP
network, however, you can run the ospf p2mp-mask-ignore command in the OSPF interface
view to disable a device from checking the network mask so that an OSPF neighbor
relationship can be established.
If the two OSPF interfaces have different IP address masks, run the ip address ip-address
{ mask | mask-length } command in the OSPF interface view to change the IP address mask
and ensure that the two OSPF interfaces have the same IP address mask.
Step 6 Check whether IP addresses of OSPF interfaces on both ends belong to the network segment
specified by the network command.
Run the display current-configuration interface interface-type interface-number command
on devices on both ends to check IP addresses of OSPF interfaces on both ends and run the
display current-configuration configuration ospf command on the two devices to check the
OSPF process configuration.
OSPF can run on an interface only when the following conditions are met:
l The mask length of the IP address of the interface is longer than or equal to that specified
by the network command. OSPF uses reverse mask. For example 0.0.0.255 indicates
that the mask length is 24 bits.
l The primary IP address of the interface belongs to the network segment specified by the
network command.
If the IP address of the interface does not meet the preceding conditions, run the ip address
ip-address { mask | mask-length } command in the OSPF-enabled interface view to change
the IP address of the interface or run the network command in the view of the area that the
OSPF process belongs to change the configured network segment so that the IP address of the
interface can meet the preceding conditions.
Step 7 Check whether the DR priorities of OSPF interfaces on both ends are both 0.

Run the display ospf [ process-id ] interface command on the two devices to check the OSPF
interface DR priority.
On a broadcast or NBMA network, there must be at least one OSPF interface of which the DR
priority is not 0 to ensure that the DR can be elected. Otherwise, the neighbor status of
devices on both ends can be only 2-Way.
If the DR priorities of the two OSPF interfaces are both 0, run the ospf dr-priority priority
command in the OSPF interface view to change the DR priority and ensure that there is at
least one OSPF interface of which the DR priority is not 0.
----End
6.10.2 OSPF Cannot Find Routes of a Non-Local Area
Symptom
When the link is normal, OSPF cannot find routes of a non-local area.
Procedure
Step 1 Check whether the area where the device resides is connected to the backbone area.
Run the display ospf [ process-id ] brief command on the ABR in the area where the device
resides to check area configuration.
OSPF requires that all non-backbone areas remain connected to the backbone area.
If no backbone area information is configured on the ABR, run the area area-id command in
the OSPF view to modify the OSPF area information. Ensure that at least one interface on the
ABR runs in the backbone area.
NOTE
If some non-backbone areas cannot be connected to the backbone area due to networking restrictions,
configure OSPF virtual links to resolve this problem.
Step 2 Check whether the area where the device resides is a totally stub area.
Run the display current-configuration configuration ospf [ process-id ] command on the

device to check the OSPF process configuration.
If you specify the parameter no-summary (run the stub no-summary command in the OSPF
area view) when configuring a non-backbone area as a stub area on the ABR, the area is
configured as a totally stub area.
A totally stub area allows only intra-area routes to be advertised within the area.
If the area where the device resides is configured as a totally stub area, perform the following
configuration based on service requirements:
l To restore the totally stub area to a common area, run the undo stub command in the
OSPF area view on all devices in the area.
l To restore a totally stub area to a stub area, run the undo stub command in the OSPF
area view on the ABR in the area and then run the stub command.
Step 3 Check whether the area where the device resides is a totally NSSA.

Run the display current-configuration configuration ospf [ process-id ] command on the

device to check the OSPF process configuration.
If you specify the parameter no-summary (run the nssa no-summary command in the OSPF
area view) when configuring a non-backbone area as an NSSA on the ABR, the area is
configured as a totally NSSA.
A totally NSSA allows only intra-area routes to be advertised within the area.
If the area where the device resides is configured as a totally NSSA, perform the following
configuration based on service requirements:
l To restore the totally NSSA to a common area, run the undo nssa command in the OSPF
area view on all devices in the area.
l To restore a totally NSSA to a stub area, run the undo nssa command in the OSPF area
view on the ABR in the area and then run the nssa command.
----End
6.11 References
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.

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 This RFC is
Time to Live (TTL) (IPv4) or Hop Limit (IPv6) experimental and
to 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.

Configuration Guide - IP Unicast Routing 7 OSPFv3 Configuration
7 OSPFv3 Configuration
About This Chapter
This chapter describes how to configure Open Shortest Path First Version 3 (OSPFv3). By
building 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 switches.
7.1 Introduction to OSPFv3

7.2 Principle
7.6 Configuring OSPFv3
7.7 Maintaining OSPFv3
7.9 References

7.1 Introduction to 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 5340 (the same as 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.
7.2 Principle
7.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.

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.

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 7-1 Router type

IS-IS ASBR
Area1 Area4
Internal Router Backbone Router
Area0
Area2 ABR Area3
Table 7-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.

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 7-2 lists route types in a descending order of priority.
Table 7-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.

Area Type
Table 7-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 7-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.

Point-to-Multipoint Regardless of the link layer protocol, OSPFv3 does not default
(P2MP) the 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.
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 7-2 OSPFv3 virtual link
Area0 Area2
Virtual Link
ABR Area1 ABR
Transit Area
As shown in Figure 7-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.
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.
7.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.

GR Process
Figure 7-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 7-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.
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:
– The GR restarter exits from the GR process and OSPFv3 recalculates routes.
– The GR restarter updates the routing table on the main control board and the FIBs
on interface boards and deletes invalid routing entries.
– 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 7-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
network and route flapping occurs the active/standby switchover occurs, other
over a short period of time. routers do not sense the route changes.
l Packets are lost during forwarding, l No packets are lost during forwarding, and
and services are interrupted. services are not affected.
7.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 7-5, traffic from RouteA to RouterD passes through RouterC, and
traverses a BGP network.
Figure 7-5 Traffic traversing a BGP network

RouterB
Router Nexthop
BGP FC00:0:0:1::1 RouterD
OSPFv3 RouterD RouterC
RouterD
RouterA
OSPFv3
BGP Routes
FC00:0:0:1::1/128
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 7-6.
Figure 7-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.
7.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.
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.
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 7-6 describes the OSPFv3 configuration tasks.

Table 7-6 OSPFv3 configuration tasks

Constructing a basic Before configuring OSPFv3, l 7.6.1 Configuring Basic

OSPFv3 network you must enable the OSPFv3 Functions
OSPFv3 process and specify l 7.6.2 Establishing or
the router ID. Other Maintaining OSPFv3
OSPFv3 functions then can Neighbor Relationship
be configured or 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.

Configuring OSPFv3 special After the basic OSPFv3 l 7.6.3 Configuring

area attributes network is constructed, OSPFv3 Areas
OSPFv3 special area l 7.6.4 Configuring
attributes can be flexibly OSPFv3 NSSA Areas
used to deploy the OSPFv3
network according to actual
needs.
l OSPFv3 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 OSPFv3 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 OSPFv3 virtual link: All
the non-backbone areas
need to be connected to
the backbone area in the
OSPFv3 deployment.
Otherwise, some areas
will be unreachable.
However, in actual
applications, physical
connectivity between the
non-backbone area and
backbone area cannot be

ensured because of
various limitations. In
this case, OSPFv3 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 7.6.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 7.6.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 7.6.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.

Configuring OSPFv3 GR To prevent route flapping 7.6.8 Configuration

and 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.

Improving OSPFv3 network On networks that require 7.6.9 Improving OSPFv3

security high security, the OSPFv3 Network Security
GTSM and authentication
method can be configured to
improve OSPFv3 network
security.
l The Generalized TTL
Security Mechanism
(GTSM) defends against
attacks by checking the
TTL value. If an attacker
simulates real OSPFv3
unicast packets and
keeps sending them to a
switch, an interface card
on the switch receives
the packets and directly
sends them to the control
plane for OSPFv3
processing, without
checking the packet
validity. As a result, the
switch is busy in
processing these packets,
causing high CPU usage.
The GTSM function
protects the switch by
checking whether the
TTL value in the IP
packet header is in a pre-
defined range to improve
the system security.
l OSPF authentication is
an encryption method
based on network
security requirements. It
encrypts OSPF packets
by adding the
authentication field to
the packets. When the
local device receives
OSPF packets sent from
a remote device, if the
authentication passwords
are different from the
local configuration, the
local device will discard
the packets to implement
self-protection.

Configuring the OSPFv3 OSPFv3 supports the 7.6.11 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.

Other network elements are required to support OSPFv3.
License Support
OSPFv3 is not under license control.
Version Support
Table 7-7 Products and minimum version supporting OSPFv3

Required


V200R001 and later
versions.)




Required



V200R002 and later
versions.)



S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009


None.

Table 7-8 describes the default configuration of OSPFv3.
Table 7-8 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 The dead interval of OSPFv3 neighbor is 40 seconds for
OSPFv3 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.
The period during which a 500 seconds

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

used to calculate the link cost.
7.6 Configuring OSPFv3
7.6.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

7.6.1.1 Enabling OSPFv3
Context
OSPFv3 supports multiple processes. Multiple OSPFv3 processes running on one switch 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 switches.
In the format of an IPv4 address, a router ID is a 32-bit unsigned integer that uniquely
identifies a switch 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 switches in an AS
are different. When multiple processes are enabled on a switch, 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 switch that runs OSPFv3.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 [ process-id ]
OSPFv3 is enabled and the OSPFv3 view is displayed.
Step 3 Run:
router-id router-id
A Router ID is set.
----End
7.6.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:

undo portswitch

NOTE
Step 4 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 5 (Optional) Run the ospfv3 network-type { broadcast | nbma | p2mp [ non-broadcast ] |
p2p } [ instance instance-id ] command to configure the network type of an interface.
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
7.6.1.3 Entering the OSPFv3 Area View
Context
You must configure the switches in the same area based on the area. Otherwise, the neighbor
switches 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:
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.
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 commands as follow to check the OSPFv3 routing table:
– display ospfv3 [ process-id ] routing uninstalled
– display ospfv3 [ process-id ] routing [ ipv6-address prefix-length | abr-routes |
asbr-routes | intra-routes | inter-routes | ase-routes | nssa-routes | [ statistics ]
[ uninstalled ] ]
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

7.6.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 7.6.1 Configuring Basic OSPFv3 Functions
7.6.2.1 Configuring the Interval for Sending Hello Packets
Context
Hello packets are periodically sent to the neighbor switch 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:

undo portswitch


NOTE
Step 4 Run:
ospfv3 timer hello interval [ instance instance-id ]
The interval for sending Hello packets is set on the interface.
----End
7.6.2.2 Configuring Dead Time of Neighbor Relationship
Context
If a switch does not receive any Hello packet from its neighbor during a specified period, the
neighbor switch 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:

undo portswitch

NOTE
Step 4 Run:
ospfv3 timer dead interval [ instance instance-id ]
The dead time of the neighbor relationship is specified.
----End
7.6.2.3 Configuring the Interval for Retransmitting LSAs to Neighboring

switches
Context

Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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
switches.
NOTE
Do not set a value which is too small, for the interval between LSA retransmissions. Otherwise,
unnecessary retransmissions may occur.
----End
7.6.2.4 Configuring the Delay for Transmitting LSAs on the Interface
Context
The LSA ages out in the LSDB of a local switch 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:


undo portswitch

NOTE
Step 4 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
7.6.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:
7.6.3.1 Configuring OSPFv3 Stub Areas
Context
Do as follows on each switch that runs OSPFv3 in the stub area:

Procedure
Step 1 Run:
system-view

Step 2 Run:

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
switches 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
7.6.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:

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 |
authentication-mode { hmac-sha256 key-id key-id { plain plain-text | [ cipher ]
cipher-text } | keychain keychain-name } ] *
A virtual link is created and configured.
----End
Prerequisites
The configurations for the OSPFv3 Areas are complete.
Procedure
[ uninstalled ] ]
l Run the display ospfv3 [ process-id ] vlink command to check the information about
OSPFv3 virtual links.
----End
7.6.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.
Before configuring an OSPFv3 NSSA, complete the following tasks:
7.6.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 switches 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.
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
[ uninstalled ] | ipv6-address prefix-length | intra-routes | inter-routes | ase-routes
| nssa-routes ]
----End
7.6.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:
7.6.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:


undo portswitch

NOTE
Step 4 Run:
ospfv3 cost cost [ instance instance-id ]
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 switch that runs OSPFv3:
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
The maximum number of equal-cost routes is set.
----End
Prerequisites
The configurations for the OSPFv3 Route Attributes are complete.
Procedure

[ uninstalled ] ]
----End
7.6.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:
7.6.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.
Procedure
l Configure route summarization on an ABR.
Do as follows on the ABR that runs OSPFv3:
a. Run:
system-view

b. Run:


c. Run:
area area-id

d. 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.
----End
7.6.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
Step 2 Run:
Step 3 Run:
filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-
name } 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
7.6.6.3 Configuring OSPFv3 to Import External Routes

Context
OSPFv3 is a link-state routing protocol and cannot directly filter advertised LSAs, therefore
OSPFv3 must filter routes when importing them. In this way, only the routes that pass the
filtering criteria can be advertised.
Carry out the following steps on the switch that runs OSPFv3.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
default { cost cost | tag tag | type type }*
Default parameters of imported routes are 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 an OSPFv3 process may lead to routing loops.

After the import-route command is executed on an OSPFv3 switch to import external routes, the switch
becomes an ASBR.

default-route-advertise [ always | cost cost | type type | tag tag | route-policy
route-policy-name ]*
Default routes are advertised to the OSPFv3 routing area.

filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-
name } export [ protocol [ process-id ] ]
Imported external routes are filtered.

To filter a certain type of routes, you must specify protocol. If protocol is not specified,
OSPFv3 filters all imported routes.
NOTE
The filter-policy command takes effect only for the routes imported by an ASBR using the import-
route command. That is, the ASBR filters routes when importing the 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

7.6.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.
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 ]


[ uninstalled ] ]
----End
7.6.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:
7.6.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.
a. Run:
system-view


b. Run:

c. Run:
spf timers delay-interval hold-interval
An SPF normal timer is configured.

l Configure an SPF intelligent timer.
a. Run:
system-view

b. Run:

c. Run:
spf-schedule-interval delay-interval hold-interval
An SPF intelligent timer is configured.
NOTE
An SPF normal timer and an SPF intelligent timer are mutually exclusive.
----End
7.6.7.2 Suppressing an Interface from Sending and Receiving OSPFv3 Packets
Context
To prevent a switch from advertising routes to the switch on a certain network and from
importing the routes of other switches, 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 switch. No OSPFv3 neighbor relationship can
be set up on the interface. Therefore, the OSPFv3 adaptability is enhanced.
7.6.7.3 Configuring DR Priority of an Interface
Context
The DR priority on a switch interface qualifies the interface for the DR election. If the DR
priority is 0, the switch cannot be elected as a DR or BDR.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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 switches and therefore are used only when necessary.
l Restarting all switches.
l Running the shutdown and undo shutdown commands on the interface on which the
OSPFv3 neighbor relationship is set up.

7.6.7.4 Configuring Stub Routers
Context
A stub router is used to control traffic. It notifies OSPFv3 switches not to forward data by the
stub router, but they can have a route to the stub router.
Procedure
Step 1 Run:
system-view

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 switch in the
stub area.
----End
7.6.7.5 Ignoring MTU Check on DD Packets
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch


NOTE
Step 4 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
[ uninstalled ] ]
----End
7.6.8 Configuration OSPFv3 GR

By configuring OSPFv3 GR, you can avoid route flapping and packet loss after an OSPFv3
switch 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.

Before configuring OSPFv3 GR, complete the following task:
7.6.8.1 Enabling OSPFv3 GR
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
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
7.6.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
7.6.8.3 Check the Configuration
Prerequisites
The configurations for OSPFv3 GR are complete.
Procedure
l Run the display ospfv3 [ process-id ] graceful-restart-information command to check
the status of OSPFv3 GR.
----End
7.6.9 Improving OSPFv3 Network Security

If an Open Shortest Path First version 3 (OSPFv3) network requires high security, you can
configure OSPFv3 generalized TTL security mechanism (GTSM) and an authentication mode
to improve network security.
Usage Scenario
If an OSPFv3 network requires high security, you can configure OSPFv3 generalized TTL
security mechanism (GTSM) and an authentication mode to improve network security.
l During network attacks, attackers may simulate OSPFv3 unicast packets and
continuously send them to the switch. If the packets are destined for the switch, it
directly forwards them to the control plane for processing without validating them. As a
result, the increased processing workload on the control plane leads to high CPU usage.
GTSM protects the switch against potential attacks and improves system security by
checking whether the time to live (TTL) value in each IP packet header is within a pre-
defined range.
NOTE
OSPFv3 GTSM takes effect only on unicast packets and therefore applies to virtual links and sham
links.
l In OSPFv3 authentication, an authentication field is added to each OSPFv3 packet for
encryption. When a local device receives an OSPFv3 packet from a remote device, the
local device discards the packet if the authentication password carried in the packet is
different from the local one, which protects the local device against potential attacks.
Therefore, OSPFv3 authentication improves network security.
Before improving OSPFv3 network security, complete the following tasks:

l Configure an IP address for each interface to ensure that neighboring routers can use the
IP addresses to communicate with each other.
7.6.9.1 Configuring OSPFv3 GTSM
Context
GTSM checks the time to live (TTL) values of only the packets that match a GTSM policy.
You can configure the switch to allow the unmatched packets to pass through the filter or to
be discarded. If you configure the switch to discard the unmatched packets, enable GTSM on
switch with which the switch may communicate because the switch discards all packets from
GTSM-incapable switch, and as a result, connections cannot be established.
In addition, you can configure the switch to log discarded packets to facilitate future fault
locating.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospfv3 valid-ttl-hops valid-ttl-hops-value [ vpn-instance vpn-instance-name ]
OSPFv3 GTSM is configured.

GTSM must be enabled at both ends of an OSPFv3 connection.
The ospfv3 valid-ttl-hops command enables OSPFv3 GTSM and sets a TTL value. If you
specify vpn-instance in the command, the switch checks the TTL values of packets only in
this VPN. Therefore, if you want to apply the configured TTL value to packets only in a VPN
or the public network, specify pass in the gtsm default-action command to prevent the
OSPFv3 packets in other instances from being discarded incorrectly.
NOTE
The valid TTL value ranges from 255 – valid-ttl-hops-value + 1 to 255.

An action is configured for the switch to perform on the packets that do not match the GTSM
policy.
By default, pass is executed on packets that do not match the GTSM policy.
NOTE
If an action is configured but a GTSM policy is not, GTSM does not take effect.

gtsm log drop-packet { slot-id all }
The switch is configured to log the packets discarded on the specified board.
----End

7.6.9.2 Configuring an Authentication Mode
Context
OSPFv3 supports keychain and HMAC-SHA256 authentications. The following procedure
uses keychain authentication as an example.
Before you configure keychain authentication, run the keychain command to configure a
keychain, the key-id command to configure a key ID, the key-string command to configure a
password, and the algorithm command to configure an algorithm. If these commands are not
run, OSPFv3 authentication fails.
NOTICE
If plain is selected during the configuration of the 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
Procedure
l Configure OSPFv3 area authentication.
a. Run:
system-view

b. Run:

c. Run:
area area-id

d. Run:
authentication-mode { hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] cipher-text } | keychain keychain-name }
OSPFv3 area authentication is configured.
NOTE
If you use OSPFv3 area authentication, the authentication and password configurations on all
switch in the same area must be the same.
l Configure OSPFv3 process authentication.
a. Run:
system-view

b. Run:

c. Run:
authentication-mode { hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] cipher-text } | keychain keychain-name }
OSPFv3 process authentication is configured.

l Configure OSPFv3 interface authentication.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. Run:
ospfv3 authentication-mode { hmac-sha256 key-id key-id { plain plain-
text | [ cipher ] cipher-text } | keychain keychain-name } [ instance
instance-id ]
OSPFv3 interface authentication is configured.
NOTE
OSPFv3 interface authentication takes precedence over OSPFv3 area authentication.

If you use HMAC-SHA256 authentication, the authentication and password configurations on all
the interfaces on the same network segment must be the same.
----End
7.6.9.3 Checking the Configurations
Prerequisites
Improvements on OSPFv3 network security have been made.
Procedure
l Run the display gtsm statistics { slot-id | all } command to check GTSM statistics.
----End

7.6.10 Configuring OSPFv3 IPSec

OSPFv3 IPSec provides a complete set of IPSec mechanisms to authenticate sent and
received OSPFv3 packets, protecting devices against forged OSPFv3 packets.
Before Configuring OSPFv3 IPSec, complete the following task:
7.6.1 Configuring Basic OSPFv3 Functions
7.6.10.1 Configuring Basic IPSec Functions
Context
Internet Protocol Security (IPSec) can be configured to prevent data theft and spoofing during
data transmission in a network.
A security association (SA) must be established so that IPSec can protect transmitted data. An
SA is a unidirectional logical connection set up for security purpose and specifies the
elements used by two IPSec peers (two parties that use the IPSec protocol to protect data
transmitted between them). The elements of an SA include the following:
l Security protocol
l Authentication or encryption algorithm supported by the security protocol
l Data encapsulation mode
l Security parameter index (SPI) of the SA
l Authentication key or encryption key of the SA
The first three elements are specified in an IPSec proposal. To configure IPSec functions, first
configure an IPSec proposal on the IPSec peers, and then configure an SA.
Procedure
Step 1 Configure an IPSec proposal.
1. Run:
system-view

2. Run:
ipsec proposal proposal-name
An IPSec proposal is created and the IPSec proposal view is displayed.

3. Run:
transform { ah | esp }
A security protocol is specified for the IPSec proposal.
By default, the security protocol used by an IPSec proposal is the Encapsulation Security
Protocol (ESP).
4. An authentication or encryption algorithm is configured.

– If AH is used, you can only configure the AH-specific authentication algorithm

because AH only authenticates packets.
Run the ah authentication-algorithm { md5 | sha1 | sha2-256 } command to
specify the authentication algorithm for the AH protocol.
By default, the AH protocol uses the Secure Hash Algorithm-256 (SHA-256)
authentication algorithm.
– When ESP is specified, ESP can encrypt/authenticate, or encrypt and authenticate
packets. Configure the ESP-specific authentication or encryption algorithm.
n Run the esp authentication-algorithm { md5 | sha1 | sha2-256 } command to
specify the authentication algorithm for the ESP protocol.
By default, the ESP protocol uses the SHA-256 authentication algorithm.
n Run the esp encryption-algorithm { des | 3des | aes [ 128 | 192 | 256 ] }
command to specify the encryption algorithm for the ESP protocol.
By default, ESP uses the Advanced Encryption Standard-256 (AES-256)
encryption algorithm.
The MD5, SHA-1, DES, and 3DES algorithms are not recommended because they
cannot meet your security defense requirements.
5. Run:
encapsulation-mode transport
A data encapsulation mode is specified for the security protocol.

By default, the data encapsulation mode is tunnel.
NOTE
– Currently, only the transport mode is supported on the device.

– In transport mode, the packet encryption device and decryption device must be the originator
and receiver of packets.
Step 2 Configure an IPSec SA.

1. Run:
quit

2. Run:
ipsec sa sa-name
An IPSec SA is created and the IPSec SA view is displayed.

By default, no IPSec SA exists in the system.
3. Run:
proposal proposal-name
The IPSec proposal is bound to the IPSec SA.

By default, an IPSec policy does not reference any IPSec proposal.
NOTE
An IPSec can use only one IPSec proposal. To bind a new IPSec proposal to the IPSec SA, delete
the original IPSec proposal.
4. Run:
sa spi { inbound | outbound } { ah | esp } spi-number

An SPI is configured for the SA.
NOTE
– An SPI uniquely identifies an SA. Each SA must be configured with an inbound SPI and an
outbound SPI. The outbound SPI on the local end must be the same as the inbound SPI on the
remote end.
– The security protocol (AH or ESP) you select when configuring the SPI must be the same as
that used in the IPSec proposal bound to the SA.
5. Configure a key according to the security protocol used in the IPSec proposal bound to
the SA.
– If the AH protocol is used, you can configure an authentication key that is a
hexadecimal number or a character string.
n Run the sa authentication-hex { inbound | outbound } ah [ cipher ] hex-
cipher-key command to configure a hexadecimal authentication key.
n Run the sa string-key { inbound | outbound } ah [ cipher ] string-cipher-key
command to configure a character string as the authentication key.
– If the ESP protocol is used, you can run one of the following commands to
configure the authentication key or the encryption key. You can also configure both
the authentication key and encryption key. If the two keys are configured at the
same time, they can only be hexadecimal keys.
n Run the sa authentication-hex { inbound | outbound } esp [ cipher ] hex-
cipher-key command to configure a hexadecimal authentication key.
n Run the sa string-key { inbound | outbound } esp [ cipher ] string-cipher-
key command to configure a character string as the authentication key.
n Run the sa encryption-hex { inbound | outbound } esp [ cipher ] hex-cipher-
key command to configure a hexadecimal encryption key.
NOTE
– The security protocol (AH or ESP) you select when configuring the key must be the same as
that used in the IPSec proposal bound to the SA.
– The outbound key on the local end must be the same as the inbound key on the remote end.
– The IPSec peers must use the authentication or encryption key in the same format. For
example, if the key on one end is a character string but the key on the other end is a
hexadecimal number, the IPSec tunnel cannot be set up.
– If you configure multiple keys in different formats, the last configured key takes effect.
----End
7.6.10.2 Configuring OSPFv3 IPSec Authentication
Context
NOTE
To ensure the device forwarding, you are advised to configure OSPFv3 IPSec on all the devices running
OSPFv3.
Procedure
l OSPFv3 uses the SA to authenticate packets in the specified OSPFv3 process.

a. Run:
system-view

b. Run:

c. Run:
ipsec sa sa-name
An SA is configured in the OSPFv3 process.

By default, no SA is configured in the OSPFv3 process.
An OSPFv3 process can be associated with multiple OSPFv3 areas. An SA applied
in the OSPFv3 process can be used in the associated areas.
l OSPFv3 uses the SA to authenticate packets in the specified OSPFv3 area.
a. Run:
system-view

b. Run:

c. Run:
area area-id

d. Run:
ipsec sa sa-name
An SA is configured in the OSPFv3 area.

By default, no SA is configured in the OSPFv3 area.
NOTE
The SA configured on an OSPFv3 area takes precedence over that configured in an OSPFv3
process.
l OSPFv3 uses the SA to authenticate packets sent and received by the interface.
a. Run:
system-view

b. Run:

undo portswitch


NOTE
modes.
d. Run:
ospfv3 ipsec sa sa-name
An SA is configured on the interface.
By default, no SA is configured in the OSPFv3 interface.
NOTE
The SA configured on an OSPFv3 interface takes precedence over that configured in an

OSPFv3 process and an OSPFv3 area.
l OSPFv3 uses the SA to authenticate packets sent and received on the virtual link.
a. Run:
system-view

b. Run:

c. Run:
area area-id

d. Run:
vlink-peer router-id ipsec sa sa-name
An SA is configured to authenticate the packets sent and received on the virtual

link.
NOTE
The SA configured on a virtual link takes precedence over that configured in an OSPFv3
process and OSPFv3 area 0.
l OSPFv3 uses the SA to authenticate packets sent and received on the sham link.
a. Run:
system-view

b. Run:

c. Run:
area area-id

d. Run:
sham-link source-address destination-address ipsec sa sa-name
An SA is configured on the sham link.

NOTE
The SA configured on a sham link takes precedence over that configured in an OSPFv3
process and OSPFv3 area 0.
----End
7.6.10.3 Checking the Configurations
Procedure
l Run the display ipsec proposal [ name proposal-name ] command to check IPSec
proposal information.
l Run the display ipsec sa [ name sa-name ] [ brief ] command to check information
about a Security Association (SA).
l Run the display ipsec statistics [ sa-name sa-name slot slot-number ] command to
check statistics about packets processed by IPSec.
l Run the display ospfv3 [ process-id ] command to check the SA applied in a specified
process.
l Run the display ospfv3 [ process-id ] interface command to check the SA applied on a
specified interface.
l Run the display ospfv3 [ process-id ] area [ area-id ] command to check the SA applied
in a specified area.
l Run the display ospfv3 [ process-id ] vlink command to check the SA applied on the
peer end of a virtual link.
l Run the display ospfv3 [ process-id ] sham-link command to check the SA applied on
the peer end of a sham link.
----End
7.6.11 Configuring the Network Management Function of OSPFv3
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:
7.6.11.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 switch.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 mib-binding process-id
OSPFv3 MIB binding OSPFv3 process is configured.
----End
7.6.11.2 Configuring OSPFv3 Trap
Context
Do as follows on the OSPFv3 switch.
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
7.6.11.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 switch.
----End
7.7 Maintaining OSPFv3
7.7.1 Resetting OSPFv3
Context
NOTICE
The OSPFv3 adjacency is removed when you reset the OSPFv3 connection. 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.
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
7.8.1 Example for Configuring OSPFv3 Areas
As shown in Figure 7-7, OSPFv3 is enabled on all Switches and the AS is divided into three
areas. SwitchB and SwitchC serve as ABRs to forward the inter-area routes.
You need to configure Area 2 as a stub area. The LSAs advertised to this area can thus be
reduced, without affecting the reachability of routes.

Figure 7-7 Networking diagram for configuring an OSPFv3 area

Area 0
SwitchB VLANIF30 SwitchC
FC00:0:0:1000::1/64
GE0/0/2
VLANIF30
GE0/0/1 GE0/0/1
FC00:0:0:1000::2/64
VLANIF20 GE0/0/2 VLANIF40
FC00:0:0:1001::1/64 FC00:0:0:1002::1/64
GE0/0/1 GE0/0/2
VLANIF20 VLANIF40
FC00:0:0:1001::2/64 FC00:0:0:1002::2/64
SwitchA SwitchD
GE0/0/3
VLANIF10 Area 2
FC00:0:0:2000::1/64
Stub
Area 1
1. Configure IPv6 addresses for interfaces.

2. Enable basic OSPFv3 functions on each Switch.
3. Configure Area 2 as a stub area by running the stub command on all the Switches in
Area 2 and check the OSPFv3 routing table of SwitchD.
4. Configure the Area 2 as a totally stub area and check the OSPFv3 routing table of
SwitchD.
Procedure
[SwitchA] vlan 10
[SwitchA] vlan 20

[SwitchA] ipv6
Step 3 Configure the basic OSPFv3 functions.

[SwitchA] ospfv3
[SwitchA-ospfv3-1] router-id 10.1.1.1
[SwitchA-ospfv3-1] quit
[SwitchA-Vlanif10] ospfv3 1 area 1
[SwitchB] ospfv3
[SwitchB-ospfv3-1] router-id 10.2.2.2
[SwitchB-ospfv3-1] quit
[SwitchB-Vlanif20] ospfv3 1 area 1
[SwitchC] ospfv3
[SwitchC-ospfv3-1] router-id 10.3.3.3
[SwitchC-ospfv3-1] quit
[SwitchC-Vlanif30] ospfv3 1 area 0
[SwitchD] ospfv3
[SwitchD-ospfv3-1] router-id 10.4.4.4
[SwitchD-ospfv3-1] quit
[SwitchD] interface vlanif 40
[SwitchD-Vlanif40] ospfv3 1 area 2
[SwitchD-Vlanif40] quit
# View the status of the OSPFv3 neighbors of SwitchB.

[SwitchB] display ospfv3 peer
OSPFv3 Process (1)
OSPFv3 Area (0.0.0.0)
Neighbor ID Pri State Dead Time Interface Instance ID
10.3.3.3 1 Full/DR 00:00:32 Vlanif30 0
10.1.1.1 1 Full/Backup 00:00:34 Vlanif20 0

# View the status of the OSPFv3 neighbors of SwitchC.

[SwitchC] display ospfv3 peer
OSPFv3 Process (1)
10.2.2.2 1 Full/DR 00:00:37 Vlanif30 0
# View the OSPFv3 routing table of SwitchD.

[SwitchD] display ospfv3 routing
Codes : E2 - Type 2 External, E1 - Type 1 External, IA - Inter-Area,
N - NSSA, U - Uninstalled, D - Denied by Import Policy
OSPFv3 Process (1)
Destination Metric
Next-hop
IA FC00:0:0:1000::/64 2
via FE80::1572:0:5EF4:1, Vlanif40
IA FC00:0:0:1001::/64 3
via FE80::1572:0:5EF4:1, Vlanif40
FC00:0:0:1002::/64 1
directly connected, Vlanif40
IA FC00:0:0:2000::/64 4
via FE80::1572:0:5EF4:1, Vlanif40
Step 4 Configure the stub areas.
# Configure the stub area of SwitchD.

[SwitchD] ospfv3
[SwitchD-ospfv3-1] area 2
[SwitchD-ospfv3-1-area-0.0.0.2] stub
[SwitchD-ospfv3-1-area-0.0.0.2] quit
# Configure the stub area of SwitchC, and set the cost of the default route advertised to the
stub area to 10.
[SwitchC] ospfv3
[SwitchC-ospfv3-1] area 2
[SwitchC-ospfv3-1-area-0.0.0.2] stub
[SwitchC-ospfv3-1-area-0.0.0.2] default-cost 10
# View the OSPFv3 routing table of SwitchD, and you can see a new default route in the
routing table. The cost of the default route is the sum of the cost of the directly connected
routes and the configured cost.
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 2
via FE80::1572:0:5EF4:1, Vlanif40
IA FC00:0:0:1000::/64 2
via FE80::1572:0:5EF4:1, Vlanif40
IA FC00:0:0:1001::/64 3
via FE80::1572:0:5EF4:1, Vlanif40
FC00:0:0:1002::/64 1
IA FC00:0:0:2000::/64 4
via FE80::1572:0:5EF4:1, Vlanif40
Step 5 Configure the totally sub area.

# On SwitchC, configure Area 2 as the totally stub area.

[SwitchC-ospfv3-1-area-0.0.0.2] stub no-summary

# View the OSPFv3 routing table of SwitchD, and you can see that the entries in the routing
table are reduced; other non-directly connected routes are suppressed; only the default route is
reserved.
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 2
via FE80::1572:0:5EF4:1, Vlanif40
FC00:0:0:1002::/64 1
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10 20
#
ospfv3 1
router-id 10.1.1.1
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:2000::1/64
ospfv3 1 area 0.0.0.1
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:1001::2/64
#
#
#
return

#
sysname SwitchB
#
ipv6
#
vlan batch 20 30
#
ospfv3 1
router-id 10.2.2.2
#

interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:1001::1/64
#
interface Vlanif30
ipv6 enable
ipv6 address FC00:0:0:1000::1/64
#
#
#
return
#
sysname SwitchC
#
ipv6
#
vlan batch 30 40
#
ospfv3 1
router-id 10.3.3.3
area 0.0.0.2
stub no-summary
#
interface Vlanif30
ipv6 enable
ipv6 address FC00:0:0:1000::2/64
#
interface Vlanif40
ipv6 enable
ipv6 address FC00:0:0:1002::1/64
#
#
#
return
#
sysname SwitchD
#
ipv6
#
vlan batch 40
#
ospfv3 1
router-id 10.4.4.4
area 0.0.0.2
stub
#
interface Vlanif40
ipv6 enable
ipv6 address FC00:0:0:1002::2/64

#
#
return
7.8.2 Example for Configuring DR Election Through OSPFv3
As shown in Figure 7-8, the priority of SwitchA is 100, which is the highest priority on the
network; therefore, SwitchA is elected as the DR. SwitchC, which has the second highest
priority, is elected as the BDR. The priority of SwitchB is 0, which means that it cannot
become the DR. SwitchD is not configured with a priority, that is, SwitchD uses the default
priority, namely, 1.
Figure 7-8 Networking diagram for configuring DR election through OSPFv3
SwitchA SwitchB
GE0/0/1 GE GE0/0/1
2
VLANIF10
/
VLANIF10 0/0
/0
E0
FC00:0:0:1001::1/64 /1 FC00:0:0:1001::2/64
G
G
3
E0
/
/0
Switch /0
E0
FC00:0:0:1001::3/64 /4 FC00:0:0:1001::4/64
G
VLANIF10 VLANIF10
GE0/0/1 GE0/0/1
SwitchC SwitchD
2. Configure the router ID of each Switch, enable OSPFv3, and specify the network
segments.
3. Check the DR/BDR status of each Switch when the default priority is used.
4. Set the DR priority of the interface on each Switch and check whether the Switch
becomes the DR or BDR.
Procedure

[SwitchA] vlan 10

[SwitchA] ipv6

# On SwitchA, enable OSPFv3 and set the router ID to 10.1.1.1.
[SwitchA] ospfv3
# On SwitchB, enable OSPFv3 and set the router ID to 10.2.2.2.

[SwitchB] ospfv3
# On SwitchC, enable OSPFv3 and set the router ID to 10.3.3.3.

[SwitchC] ospfv3
# On SwitchD, enable OSPFv3 and set the router ID to 10.4.4.4.

[SwitchD] ospfv3
Check the neighbors of SwitchA. You can view the DR priority and the neighbor status. By
default, the DR priority is 1. Now SwitchD functions as the DR and SwitchC functions as the
BDR.
NOTE
When the priorities of two Switches are the same, the Switch that has a greater router ID is elected as the
DR. If the VLANIF interface of an Switch becomes the DR, the other broadcast interfaces of this Switch
have a high priority in the future DR election. That is, the Switch still functions as the DR. The DR
cannot be preempted.

[SwitchA] display ospfv3 peer

OSPFv3 Process (1)
10.2.2.2 1 Full/DROther 00:00:32 Vlanif10 0
10.4.4.4 1 Full/DR 00:00:38 Vlanif10 0
# View the neighbors of SwitchD, and you can see that the status of the neighbor relationship
between SwitchD and other devices is Full.
[SwitchD] display ospfv3 peer
OSPFv3 Process (1)
Step 4 Configure the DR priorities of interfaces.

# Configure the DR priority of SwitchA to 100.
[SwitchA-Vlanif10] ospfv3 dr-priority 100
# Configure the DR priority of SwitchB to 0.

[SwitchB-Vlanif10] ospfv3 dr-priority 0
# Configure the DR priority of SwitchC to 2.

[SwitchC-Vlanif10] ospfv3 dr-priority 2
# View the neighbors of SwitchA, and you can see that the other DR priority is updated but
the DR and BDR are unchanged.
OSPFv3 Process (1)
10.4.4.4 1 Full/DR 00:00:31 Vlanif10 0
# View the neighbors of SwitchD, and you can see that the other DR priority is updated.
OSPFv3 Process (1)
Step 5 Perform DR/BDR election again.

# Run the shutdown and undo shutdown commands on the VLANIF interface that
establishes the OSPFv3 neighbor relationship to re-elect the DR and BDR.
[SwitchA-Vlanif10] shutdown
[SwitchA-Vlanif10] undo shutdown


[SwitchB-Vlanif10] shutdown
[SwitchB-Vlanif10] undo shutdown
[SwitchC-Vlanif10] shutdown
[SwitchC-Vlanif10] undo shutdown
[SwitchD-Vlanif10] shutdown
[SwitchD-Vlanif10] undo shutdown

# View the neighbors of SwitchA, and you can see that SwitchC is the BDR.
OSPFv3 Process (1)
# View the neighbors of SwitchD, and you can see that SwitchA is the DR.
OSPFv3 Process (1)
10.1.1.1 100 Full/DR 00:00:39 Vlanif10 0
10.2.2.2 0 2-Way/DROther 00:00:35 Vlanif10 0
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
#
#
#
return

#
sysname SwitchA
#
ipv6

#
vlan batch 10
#
ospfv3 1
router-id 10.1.1.1
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1001::1/64
ospfv3 dr-priority 100
#
#
return
#
sysname SwitchB
#
ipv6
#
vlan batch 10
#
ospfv3 1
router-id 10.2.2.2
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1001::2/64
#
#
return
#
sysname SwitchC
#
ipv6
#
vlan batch 10
#
ospfv3 1
router-id 10.3.3.3
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1001::3/64
#
#
return
#
sysname SwitchD
#
ipv6
#

vlan batch 10
#
ospfv3 1
router-id 10.4.4.4
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1001::4/64
#
#
return
7.8.3 Example for Configuring the OSPFv3 Virtual Link
As shown in Figure 7-9, OSPFv3 is enabled on all Switches and the AS is divided into three
areas. SwitchB and SwitchC serve as ABRs to forward the inter-area routes. Area 2 is not
directly connected to the backbone area, Area 0. Area 1 is the area between Area 0 and Area
2.
You need to configure a virtual link in Area 1 where SwitchB and SwitchC are located so that
SwitchA and SwitchD can communicate with each other.
Figure 7-9 Networking diagram for configuring OSPFv3 virtual links
Area 2 Area 1 Area 0

VLANIF30
VLANIF10 VLANIF20
FC00:0:0:1001::2/64 FC00:0:0:1000::2/64 FC00:0:0:1002::2/64
GE0/0/1 GE0/0/2 GE0/0/2
GE0/0/1 GE0/0/2 GE0/0/1

VLANIF10 VLANIF20 VLANIF30
FC00:0:0:1001::1/64 FC00:0:0:1000::1/64 FC00:0:0:1002::1/64
SwitchA SwitchB SwitchC SwitchD

3. Configure a virtual link between SwitchB and SwitchC to connect the non-backbone
areas to the backbone area.

Procedure

[SwitchA] ipv6

[SwitchA] ospfv3

[SwitchB] ospfv3

[SwitchC] ospfv3
# On SwitchD, enable OSPFv3 and set the router ID to 10.4.4.4.

[SwitchD] ospfv3

# View the OSPFv3 routing table of SwitchC, and you can see that the routing table of
SwitchC does not contain the routes of Area 2 because Area 2 is not directly connected to
Area 0.
[SwitchC] display ospfv3 routing

OSPFv3 Process (1)

Destination Metric
Next-hop
FC00:0:0:1000::/64 1
FC00:0:0:1002::/64 1
Step 4 Configure a virtual link in Area 1 where SwitchB and SwitchC are located.
[SwitchB] ospfv3
[SwitchB-ospfv3-1] area 1
[SwitchB-ospfv3-1-area-0.0.0.1] vlink-peer 10.3.3.3
[SwitchB-ospfv3-1-area-0.0.0.1] return
[SwitchC] ospfv3
[SwitchC-ospfv3-1] area 1
[SwitchC-ospfv3-1-area-0.0.0.1] vlink-peer 10.2.2.2
[SwitchC-ospfv3-1-area-0.0.0.1] return

# Check the OSPFv3 routing table of SwitchC.
<SwitchC> display ospfv3 routing

OSPFv3 Process (1)

Destination Metric
Next-hop
FC00:0:0:1000::/64 1
FC00:0:0:1000::1/128 1
via FE80::4D67:0:EB7D:2, Vlanif20
FC00:0:0:1000::2/128 0
IA FC00:0:0:1001::/64 2
via FE80::4D67:0:EB7D:2, Vlanif20
FC00:0:0:1002::/64 1
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10

#
ospfv3 1
router-id 10.1.1.1
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1001::2/64
#
#
return
#
sysname SwitchB
#
ipv6
#
vlan batch 10 20
#
ospfv3 1
router-id 10.2.2.2
area 0.0.0.1
vlink-peer 10.3.3.3
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1001::1/64
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:1000::1/64
#
#
#
return
#
sysname SwitchC
#
ipv6
#
vlan batch 20 30
#
ospfv3 1
router-id 10.3.3.3
area 0.0.0.1
vlink-peer 10.2.2.2
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:1000::2/64
#
interface Vlanif30
ipv6 enable
ipv6 address FC00:0:0:1002::1/64

#
#
#
return

#
sysname SwitchD
#
ipv6
#
vlan batch 30
#
ospfv3 1
router-id 10.4.4.4
#
interface Vlanif30
ipv6 enable
ipv6 address FC00:0:0:1002::2/64
#
#
return
7.8.4 Example for Configuring OSPFv3 GR
As shown in Figure 7-10, SwitchA, SwitchB, and SwitchC belong to the same OSPFv3 area.
They communicate with each other through the OSPFv3 protocol and are enabled with GR.
When OSPFv3 adjacencies are established between SwitchA, SwitchC, and SwitchB, the
three switches can exchange routing information. If the OSPFv3 protocol restarts on SwitchA,
SwitchA synchronizes data with the neighboring switches through GR.
Figure 7-10 Networking diagram for configuring OSPFv3 GR
VLANIF10 VLANIF20
FC00:0:0:1000::1/64 FC00:0:0:2000::1/64
GE0/0/1 GE0/0/2
VLANIF10 VLANIF20
FC00:0:0:1000::2/64 FC00:0:0:2000::2/64
SwitchA GE0/0/1 SwitchB GE0/0/1 SwitchC
10.1.1.1 10.2.2.2 10.3.3.3


3. Enable the OSPFv3 helper in the OSPFv3 view of SwitchB.
4. Enable the OSPFv3 GR in the OSPFv3 view of SwitchA.
Procedure
[SwitchA] vlan 10
[SwitchA] ipv6
Step 3 Configure basic OSPFv3 functions.

[SwitchA] ospfv3 100

[SwitchB] ospfv3 100

[SwitchC] ospfv3 100
Step 4 Enable OSPFv3 GR for SwitchA.

[SwitchA] ospfv3 100

[SwitchA-ospfv3-100] graceful-restart
[SwitchA-ospfv3-100] return
Step 5 Enable OSPFv3 helper for SwitchB.

[SwitchB] ospfv3 100
[SwitchB-ospfv3-100] helper-role
[SwitchB-ospfv3-100] return
# Run the display ipv6 fib command on SwitchA to view the FIB information.
<SwitchA> display ipv6 fib
IPv6 FIB Table:
Destination: ::1 PrefixLength: 128

Nexthop : ::1 Flag : HU
Interface : InLoopBack0 Tunnel ID : 0x0
TimeStamp : 2007-06-25 17:31:46
Destination: FE80:: PrefixLength: 10

Nexthop : :: Flag : BU
Interface : NULL0 Tunnel ID : 0x0
TimeStamp : 2007-06-25 17:31:46
Destination: FC00:0:0:1000::1 PrefixLength: 128

TimeStamp : 2007-06-25 17:31:46
Destination: FC00:0:0:1000:: PrefixLength: 64

Nexthop : FC00:0:0:1000::1 Flag : U
Interface : Vlanif10 Tunnel ID : 0x0
TimeStamp : 2007-06-25 17:31:46

Nexthop : FE80::200:1FF:FE00:200 Flag : DGU
TimeStamp : 2007-06-25 17:31:46
# Restart OSPFv3 process 100 on SwitchA without using the GR mechanism.

<SwitchA> reset ospfv3 100
# Run the display ipv6 fib command on SwitchA immediately to view the FIB information.
IPv6 FIB Table:

TimeStamp : 2007-06-25 17:31:46

TimeStamp : 2007-06-25 17:31:46

TimeStamp : 2007-06-25 17:31:46



TimeStamp : 2007-06-25 17:31:46
The preceding information shows that the FIB information on SwitchA is modified and the
forwarding service is affected.
# Restart OSPFv3 process 100 on SwitchA by using the GR mechanism.
<SwitchA> reset ospfv3 100 graceful-restart
# Run the display ipv6 fib command on SwitchA immediately to view the FIB information.
Check whether GR functions normally. If GR functions normally, the FIB information is not
modified and the forwarding is not affected when you restart the OSPFv3 process through GR
on SwitchA.
IPv6 FIB Table:

TimeStamp : 2007-06-25 17:31:46

TimeStamp : 2007-06-25 17:31:46

TimeStamp : 2007-06-25 17:31:46

TimeStamp : 2007-06-25 17:31:46

Nexthop : FE80::200:1FF:FE00:200 Flag : DGU
TimeStamp : 2007-06-25 17:31:46
The preceding information shows that the FIB information on SwitchA is not modified and
the forwarding is not affected.
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10
#
ospfv3 100
router-id 10.1.1.1
graceful-restart
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1000::1/64
ospfv3 100 area 0.0.0.0

#
#
return

#
sysname SwitchB
#
ipv6
#
vlan batch 10 20
#
ospfv3 100
router-id 10.2.2.2
helper-role
#
interface Vlanif10
ipv6 enable
ipv6 address FC00:0:0:1000::2/64
ospfv3 100 area 0.0.0.0
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:2000::1/64
ospfv3 100 area 0.0.0.0
#
#
#
return

#
sysname SwitchC
#
ipv6
#
vlan batch 20
#
ospfv3 100
router-id 10.3.3.3
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:2000::2/64
ospfv3 100 area 0.0.0.0
#
#
return
7.9 References
The following table lists the references of this document.

Document Description Rema

rks
RFC5340, the This document describes the modifications to OSPF to -

same as RFC2740 support version 6 of the Internet Protocol (IPv6).
draft-ietf-ospf- This document describes the OSPFv3 graceful restart. The -

ospfv3-graceful- OSPFv3 graceful restart is identical to OSPFv2 except for
restart the 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 -

ospfv3-mib-11 Information 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.

Configuration Guide - IP Unicast Routing 8 IPv4 IS-IS Configuration
8 IPv4 IS-IS Configuration
About This Chapter
This chapter describes how to configure IPv4 IS-IS. You can build an IPv4 IS-IS network to
allow IS-IS to discover and calculate routes in an autonomous system (AS).
8.1 Introduction to IS-IS

8.2 Principles
8.6 Configuring IS-IS (IPv4)
8.7 Maintaining IS-IS
8.10 References

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
8.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 8-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.

Figure 8-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 8-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 8-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.

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
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).

Figure 8-3 Pseudonode
L1 L1 L1 L1
Pseudonode
L1 DIS L1 L1 DIS L1
Physical
connection
Virtual
connection
As shown in Figure 8-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 8-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 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 8-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.

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
8-5 shows the TLV format. A TLV is also called a code-length-value (CLV).

Figure 8-5 TLV format
No. of Octets
Type 1
Length 1
Value Length
TLVs vary according to PDU types, as shown in Table 8-1.
Table 8-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 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.
8.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.

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 8-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 8-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
a. RouterA broadcasts a Level-2 LAN IS-IS Hello PDU (IIH) with no neighbor ID
specified.
b. 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.
c. 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.
d. 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

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.

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 8-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

1. As shown in Figure 8-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

Figure 8-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 8-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.
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.
8.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:
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.
8.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.

Figure 8-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 8-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.
8.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.

Figure 8-10 IS-IS Overload
RouterD RouterE
10.1.1.0/24
Overload
RouterA RouterC
RouterB
As shown in Figure 8-10, RouterB forwards the packets sent from RouterA to network
segment 10.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 10.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.
8.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.
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.
8.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 8-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 8-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 8-12 shows the
topology formed on RouterA.

Figure 8-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.
8.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 8-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.

Table 8-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.
8.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.

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 8-13 IS-IS LSP fragment extension
RouterA1
RouterB RouterA
RouterA2

O Usag Principles Example Precautions

pe e
rat Scena
in rio
g
M
od
e
M Some Virtual systems In Figure 8-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
rk do containing information LSP fragment LSP. If the LSPs sent
not about links to each extension in mode-1. by a virtual system
suppor virtual system. RouterA1 and contain TLVs specified
t LSP Similarly, each virtual RouterA2 are virtual in other features, these
fragm system advertises LSPs systems of RouterA TLVs must be the same
ent containing information and send LSPs carrying as those in common
extens about links to the some routing LSPs.
ion. originating system. information of The virtual system
Virtual systems look RouterA. After carries neighbor
like the physical receiving LSPs from information indicating
routers that connect to RouterA, RouterA1, that the neighbor is the
the originating system. and RouterA2, RouterB originating system,
Mode-1 is a considers that there are with the metric equal
transitional mode for three individual routers to the maximum value
the earlier versions that at the remote end and minus 1. The
do not support LSP calculates routes. originating system
fragment extension. In Because the cost of the carries neighbor
earlier versions, IS-IS route from RouterA to information indicating
cannot identify the IS RouterA1 and the cost that the neighbor is the
Alias ID TLV and of the route from virtual system, with the
processes the received RouterA to RouterA2 metric 0. This ensures
LSP that is advertised are both 0, the cost of that the virtual system
by a virtual system as the route from RouterB is the downstream node
an LSP advertised by to RouterA is the same of the originating
an IS-IS process. as the cost of the route system when other
from RouterB to routers calculate
RouterA1. routes.

O Usag Principles Example Precautions

pe e
rat Scena
in rio
g
M
od
e
M All Virtual systems do not In Figure 8-13, -

od the participate in SPF RouterB supports LSP
e-2 router calculation. All the fragment extension,
s on routers on the network and RouterA is
the know that the LSPs configured to support
netwo generated by virtual LSP fragment
rk systems actually extension in mode-2.
suppor belong to the RouterA1 and
t LSP originating system. RouterA2 are virtual
fragm An IS-IS router systems of RouterA
ent working in mode-2 can and send LSPs carrying
extens identify the IS Alias ID some routing
ion. TLV, which is used as a information of
reference for RouterA. When
calculating the SPT receiving LSPs from
and routes. RouterA1 and
RouterA2, RouterB
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).
8.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 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.
8.2.11 IS-IS Reliability

As networks develop, services have higher network requirements. IS-IS provides high
reliability to ensure uninterrupted service forwarding when a network fault occurs or when
network devices need maintenance.
IS-IS reliability includes hot standby, batch backup, real-time backup, BFD for IS-IS, and IS-
IS GR.
In hot standby, IS-IS backs up data from the Active Main Board (AMB) to the Standby Main
Board (SMB). Whenever the AMB fails, the SMB becomes active and takes over the tasks of
the AMB to ensure normal IS-IS running. This improves IS-IS reliability.
IS-IS information backup includes data backup and command line backup:
l Data backup: The system backs up data of processes and interfaces.
Data backup ensures the same IS-IS data on the AMB and SMB. When an AMB/SMB
switchover occurs, neighbors do not detect the switchover.
l Command line backup: The system backs up the command lines that are successfully
executed on the AMB to the SMB.
Whether to send command lines to the SMB for processing is determined by the the
execution results of command lines on the AMB. If command lines are successfully

executed on the AMB, the command lines are sent to the SMB for processing.
Otherwise, the command lines are not sent to the SMB and the command line execution
failure is logged. If the command lines fail to be executed on the SMB, this failure is
logged.
The AMB sends only the successfully executed command lines to the SMB for
processing. If a fault occurs on the AMB, IS-IS neighbor relationships on the device
need to be established again after the AMB/SMB switchover is performed.
Hot Standby
Devices with distributed architecture support IS-IS hot standby.
In IS-IS hot standby, IS-IS configurations on the AMB and SMB are consistent. When an
AMB/SMB switchover occurs, the new AMB performs GR and resends a request for
establishing neighbor relationships to neighbors to synchronize its LSDB. This prevents
traffic transmission from being affected.
Batch Backup
l Batch data backup
When the SMB is installed, all data of the AMB is backed up to the SMB at a time. No
configuration can be changed during batch backup.
l Batch command line backup
When the SMB is installed, all configurations of the AMB are backed up to the SMB at a
time. No configuration can be changed during batch backup.
Real-time Backup
l Real-time data backup
Changed data of processes and interfaces are backed up in real time to the SMB.
l Real-time command line backup
The command lines that are executed successfully on the AMB are backed up to the
SMB.
8.2.12 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.
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 8-14 shows the format of the restart TLV.
Figure 8-14 Restart TLV

0 1 2 3 4 5 6 7
Type(211)
Length(1 to 9)
Reserved SA RA RR
Remaining Time
Table 8-3 describes the fields of the restart TLV.
Table 8-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.

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 8-15 shows the process of IS-IS restarting.

Figure 8-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
a. After performing the protocol restart, the GR restarter performs the following
actions:
n Starts T1, T2, and T3 timers.
n 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.
b. After receiving an IIH packet, the GR helper performs the following actions:
n Maintains the neighbor relationship and refreshes the current Holdtime.
n 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.
n 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.
c. 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:
n 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.

n Deletes the T1 timer maintained by the interface that receives the ACK packet
and CSNPs.
n 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.
d. 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.
e. After the T2 timer is deleted, the LSDB of the level is synchronized.
n In the case of a Level-1 or Level-2 router, SPF calculation is triggered.
n 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.
f. 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.
g. 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 8-16.

Figure 8-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
a. After the GR restarter is started, it performs the following actions:

n Starts the T2 timer for the synchronization of LSDBs of each level.
n 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.
b. After the neighbor receives the IIH packet that carries the restart TLV, it performs
the following actions depending on whether GR is supported:
n 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.
n 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 the advertisement of the adjacency with the GR restarter. On a P2P

link, the neighbor also sends a CSNP.
c. 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.
d. After the T1 timer expires, the GR restarter sends an IIH packet in which both RR
and SA are set to 1.
e. 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.
f. 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.
g. After receiving the CSNP from the helper, the GR restarter synchronizes the LSDB.
h. After the LSDB of this level is synchronized, the T2 timer is deleted.
i. After all T2 timers are deleted, the SPF calculation is started and LSPs are
regenerated and flooded.
j. At this point, the IS-IS starting of the GR restarter is complete.
8.2.13 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 8-17, basic IS-IS functions are configured on every router, and BFD for IS-IS is
enabled on RouterA and RouterB.
Figure 8-17 BFD for IS-IS

Router A Router D Router B
Primary Path
Backup Path
Probed Path
Router C

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 8-4 Two implementation modes for BFD for IS-IS

Impleme Principles Differences
ntation
Mode
Static BFD BFD session parameters, l Static BFD can be manually

for IS-IS including local and remote controlled and is easy to deploy. To
discriminators, are manually save memory and ensure reliability
configured using commands, and of key links, deploy BFD on
the requests for establishing BFD specified links.
sessions are 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
BFD for created but not manually static BFD. In dynamic BFD, routing
IS-IS configured. When detecting protocols trigger the setup of BFD
faults, BFD informs IS-IS of the sessions, preventing the configuration
faults through the routing errors caused by manual configuration.
management (RM) module. IS-IS Dynamic BFD is easy to configure and
then turns the neighbors Down, applies to the scenarios where BFD
rapidly advertises the changed needs to be configured on the entire
LSPs, and performs incremental network.
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.

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.
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.
8.2.14 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 8-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.
NOTE
If the outbound interface of the backup link is the actual outbound interface of the TE tunnel, IP
protecting TE fails.

Figure 8-18 IP protecting TE

RouterS TE Tunnel: IS-IS cost = 1 RouterD
IS-IS cost = 13
IS
-IS
co
1
t=
st
s
=1
co
0
-IS
IS
RouterN
Traffic in normal
Traffic in case of failure
l TE protecting IP
As shown in Figure 8-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 8-19 TE protecting IP

RouterS TE Tunnel: IS-IS cost = 12 RouterD
IS-IS cost = 13
1
=
st
IS
co
- IS
-IS
co
IS
s t=
10
RouterN
Traffic in normal
Traffic in case of failure
IS-IS Auto FRR traffic protection is classified into link protection and link-node dual
protection.

Figure 8-20 IS-IS Auto FRR link protection
cost = 10
RouterS co RouterD
st
10
=
=
10
st
co
RouterN
Figure 8-21 IS-IS Auto FRR link-node dual protection

RouterE
co
s
5
t=
=
st
10
co
RouterS co RouterD
st
10
=
=
10
st
co
RouterN

Table 8-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 8-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 In Figure 8-21, traffic is
k- node or the 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) < inequality. When RouterE or
pro hop Distance_opt(N,S) + the link between RouterS
tect node. Distance_opt(S,D) and RouterE fails, RouterS
ion Node l The interface cost of the router must switches the traffic to the
protectio satisfy the following inequality: backup link RouterS-
n takes Distance_opt(N,D) < >RouterN so that the traffic
preceden Distance_opt(N,E) + can be further transmitted
ce over Distance_opt(E,D) along downstream paths.
link This ensures that the traffic
protectio interruption time is within
n. 50 ms.
NOTE
In Table 8-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.
8.2.15 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. 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 8-22
shows the relationships between IS-IS TE, MPLS TE, and CSPF.
Figure 8-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.
Table 8-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 22 36 Indicates the TLV of the

sub-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.
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 8-23,
a TE tunnel is set up between RouterA and RouterD.
Figure 8-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.

Figure 8-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 8-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 8-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.

8.2.16 IS-IS Local MT

IS-IS local multicast-topology (MT) creates a separate multicast topology on the local device,
without affecting the protocol packets exchanged between devices, to allow both TE tunnels
and multicast to be configured on the backbone network.
NOTE
The mentioned TE tunnel specifies the TE tunnel enabled with IGP Shortcut (AA).
Background
When multicast and an MPLS TE tunnel are deployed in a network simultaneously, the
multicast function may be affected by the TE tunnel.
This is because after the TE tunnel is enabled with IS-IS Shortcut (AA), the outbound
interface of a route calculated by an IS-IS is not the actual physical interface but a TE tunnel
interface. According to the unicast route to the multicast source address, a router sends a
Report message through a TE tunnel interface. Routers spanned by the TE tunnel cannot sense
the Report message, so multicast forwarding entries cannot be created. The TE tunnel is
unidirectional, so multicast data packets sent by the multicast source are sent to the routers
spanned by the tunnel through the related physical interfaces. The routers do not have any
multicast forwarding entry. Therefore, the multicast data packets are discarded.
Figure 8-25 TE tunnel scenario
172.16.1.2/24 Client Server 192.168.3.2/24
GE1/0/0 GE2/0/0
172.16.1.1/24 192.168.3.1/24
Router-id Router-id
RouterA 1.1.1.1 RouterE
5.5.5.5
GE2/0/0 GE1/0/0
10.0.0.1/24 10.0.3.3/24
GE1/0/0 GE1/0/0
10.0.0.2/24 RouterB 10.0.3.1/24 RouterD
Router-id Router-id
Tunnel1/0/0 4.4.4.4
2.2.2.2
GE2/0/0 RouterC GE2/0/0
10.0.1.2/24 10.0.2.1/24
Router-id
Tunnel1/0/0 3.3.3.3 Join
Multicast
GE1/0/0 GE2/0/0 Packets
10.0.1.1/24 10.0.2.2/24
As shown in Figure 8-25, RouterA, RouterB, RouterC, RouterD, and RouterE are Level-2
routers. The routers run IS-IS to implement interconnection. The multicast services are
normal. A unidirectional MPLS TE tunnel is set up between RouterB and RouterD. The
MPLS TE tunnel is enabled with IS-IS Shortcut (AA). When you view the multicast routing

table on RouterC spanned by the TE tunnel, you cannot find any multicast forwarding entry.
Therefore, the multicast services are interrupted.
The process of transmitting multicast packets between the client and the multicast server is as
follows:
1. To join a multicast group, the client sends a Report message to SwitchA. SwitchA then
sends a Join message to SwitchB.
2. When the Join message reaches SwitchB, SwitchB uses Tunnel 1/0/0 as the Reverse Path
Forwarding (RPF) interface and forwards the message to SwitchC through GE 2/0/0 by
using the MPLS label.
3. The Join message is forwarded with the MPLS label, so SwitchC just forwards the
message and does not create a multicast routing entry. In the topology shown in Figure
8-25, SwitchC is the penultimate hop of the MPLS forwarding. SwitchC pops out the
MPLS label, and then forwards the Join message to SwitchD through GE 2/0/0.
4. After receiving the Join message, SwitchD creates a multicast forwarding entry. The
inbound interface is GE 2/0/0 and the outbound interface is GE 1/0/0. SwitchD then
forwards the message to SwitchE. The SPT is set up.
5. When the multicast source sends the traffic to SwitchD, SwitchD forwards the traffic to
SwitchC. SwitchC does not create any forwarding entry in advance. Therefore, the traffic
is discarded and the multicast service is interrupted.
As described in the preceding process of transmitting multicast packets, the forwarding of
multicast packets relies on the unicast routing table and the TE tunnel is unidirectional.
Therefore, the multicast packets are discarded. This problem can be avoided by using the
following methods:
l Manually configuring static multicast routes to guide the forwarding of multicast
packets.
l Configuring a bidirectional TE tunnel. In this case, the returned multicast packets can be
sent by using the same tunnel. Routers spanned by the TE tunnel use the tunnel to
transmit multicast packets.
l Configuring the Multicast Border Gateway Protocol (MBGP) to separate the unicast
topology from the multicast topology. MBGP provides the topology that does not contain
the TE tunnel for multicast separately. Multicast is used to perform RPF check on MBGP
routes.
l Configuring local MT
The preceding methods are used to prevent the interruption of multicast services. The
disadvantage of the first three methods is that a lot of manual configurations need to be done.
As a result, if the network is complex, the planning, configuration, and maintenance tasks
become heavier. Therefore, in the preceding network environment, local MT needs to be
configured.
Principles
Local MT creates a separate multicast topology on the local device, without affecting the
protocol packets exchanged between devices. Devices support local MT. This ensures that
multicast services are still available when both multicast and the MPLS TE tunnel enabled
with IGP Shortcut are deployed.
After local MT is enabled, the router at the ingress of a TE tunnel creates a separate multicast
IGP (MIGP) routing table to store the physical interfaces to which the TE tunnel corresponds.

This ensures that multicast protocol packets are correctly forwarded. The correct routing
entries are created in the multicast routing table (MRT).
l Create an MIGP routing table.
Multicast protocol packets are forwarded according to the unicast routing table. After
local MT is enabled on SwitchB, RM creates separate MIGP routing tables for multicast
protocols. When the outbound interface of a route is a TE tunnel interface, an IGP
calculates out the actually physical outbound interface for the route and adds the
outbound interface to the MIGP routing table.
l Guide the forwarding of multicast protocol packets.
Before forwarding a multicast protocol packet, a router needs to search the unicast
routing table. If the router finds that the next hop is the TE tunnel, the router continues to
search the MIGP routing table for the related physical outbound interface to guide the
forwarding of the multicast protocol packet.
Figure 8-26 Local MT Topology
172.16.1.2/24 Client Server 192.168.3.2/24
GE1/0/0 GE2/0/0
172.16.1.1/24 192.168.3.1/24
RouterA Router-id Router-id
1.1.1.1 RouterE
5.5.5.5
GE2/0/0 GE1/0/0
10.0.0.1/24 10.0.3.3/24
GE1/0/0 GE1/0/0
10.0.0.2/24 RouterB RouterD 10.0.3.1/24
Router-id Tunnel1/0/0 Router-id
2.2.2.2 4.4.4.4
GE2/0/0 RouterC GE2/0/0
10.0.1.2/24 10.0.2.1/24
Router-id
Tunnel1/0/0 3.3.3.3 Join
Multicast
GE1/0/0 GE2/0/0 Packets
10.0.1.1/24 10.0.2.2/24
As shown in Figure 8-26, if the outbound interface of multicast source 192.168.3.2/24 is TE

tunnel 1/0/0, the physical outbound interface of the route calculated by IS-IS is GE 2/0/0. IS-
IS installs the route to the MIGP routing table. The multicast services are not affected by the
TE tunnel. Multicast packets are forwarded through the physical outbound interfaces
according to the MIGP routing table for the general IP forwarding. The related routing entries
are created in the MRT. Multicast data packets are then correctly forwarded.
8.2.17 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 8-7 describes the default configuration of IPv4 IS-IS.
Table 8-7 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
Bandwidth reference value 100 Mbit/s

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.
Table 8-8 describes the IS-IS configuration tasks.

Table 8-8 IS-IS configuration tasks

Configuring basic IS-IS To deploy the IS-IS protocol 8.6.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.
Configuring IS-IS network On IS-IS networks, 8.6.2 Improving IS-IS

security unauthorized users can Network Security
attack 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 8.6.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 8.6.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.

Configuring IS-IS route Route aggregation allows 8.6.5 Configuring IS-IS

aggregation multiple routes with the Route Summarization
same 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.6.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 8.6.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.

Configuring mesh groups On the NBMA network, 8.6.8 Configuring a Mesh

when an interface of the Group on an NBMA
switch receives a new LSP, Network
the LSP is flooded to other
interfaces of the switch. On
highly-connected networks
that have multiple P2P links,
this processing method
results in repeated LSP
flooding and wastes
bandwidth resources.
To solve this problem, create
a mesh group and add some
interfaces to the group. The
switch 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 8.6.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 GR
helper to implement fast
switchover. This improves
IS-IS reliability.

Configuring IS-IS overload If the system cannot store 8.6.10 Configuring the
new LSPs or synchronize Overload Bit for an IS-IS
the 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.

Other network elements are required to support IS-IS (IPv4).
License Support
IS-IS (IPv4) is not under license control.
Version Support
Table 8-9 Products and minimum version supporting IS-IS (IPv4)

Required



Required

V200R001 and later
versions.)





V200R002 and later
versions.)



S5720EI V200R007
S5720SI/S5720S-SI V200R008



Required

S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

None.
8.6.1 Configure Basic IS-IS Functions
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.
8.6.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.
descriptiondescription
Description for the IS-IS process is configured.

Step 4 (Optional) Enable IS-IS to add the POI and hostname TLV to Purge LSPs.
Run:
purge-originator-identification enable [ always ]
IS-IS is enabled to determine whether to add the POI TLV and hostname TLV to Purge LSPs
based on the authentication configuration.
l If the purge-originator-identification enable command is run and the send-only
parameter is specified when configuring authentication, generated Purge LSPs do not
carry the POI TLV or hostname TLV.
l If the purge-originator-identification enable command is run and MD5 or HMAC-
MD5 authentication is configured, generated Purge LSPs do not carry the POI TLV or
hostname TLV. If the purge-originator-identification enable command is run and
authentication of another type is configured or no authentication is configured, generated
Purge LSPs carry the POI TLV and hostname TLV.
l If the purge-originator-identification enable always command is run, generated Purge
LSPs carry the POI TLV and hostname TLV, regardless of whether authentication is
configured or whether the send-only parameter is specified when configuring
authentication.
----End
8.6.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
8.6.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 }

The level of the switch is configured.
By default, the level of the switch is Level-1-2.
----End
8.6.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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. 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
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.
e. 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.
f. (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.
Level-1-2 broadcast interfaces select the DIS using Level-1 and Level-2 separately.
To select the DIS only for Level-1 or Level-2 interfaces, specify the level.
g. (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.
h. (Optional) Configure a delay for the IS-IS neighbor relationship establishment.
Run:
isis delay-peer track last-peer-expired [ delay-time delay-interval ]
A delay is configured for the IS-IS neighbor relationship establishment.

On an IS-IS network, if the IS-IS link has the network transmission delay or
transmission error, a few Hello packets may be lost or incorrectly transmitted. In
this case, the neighbor relationship frequently changes between the Up and Down
states, leading to route flapping.
By default, delay-interval is 60s.
If a new delay-interval is configured and it is less than the remaining time of the
ongoing delay, the new delay-interval takes effect immediately; if the new delay-

interval is greater than the remaining time of the ongoing delay, the ongoing delay
continues until the new delay-interval takes effect at the next delay.
l Establish an IS-IS neighbor relationship on a P2P link.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. Run:
isis enable [ process-id ]
IS-IS is enabled on the interface.

e. Run:

By default, the level of an interface is level-1-2.
f. Run:
isis circuit-type p2p [ strict-snpa-check ]
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:
n After a broadcast interface is simulated as a P2P interface using the isis
circuit-type p2p [ strict-snpa-check ] command, the interval for sending
Hello packets, the number of Hello packets that IS-IS does not receive from a
neighbor before the neighbor is declared Down, interval for resending 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.
n 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 packets that IS-IS does not receive from a neighbor before the neighbor
is declared 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.

g. 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.

h. 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.

i. 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.
j. (Optional) Configure a delay for the IS-IS neighbor relationship establishment.
Run:
isis delay-peer track last-peer-expired [ delay-time delay-interval ]
A delay is configured for the IS-IS neighbor relationship establishment.
On an IS-IS network, if the IS-IS link has the network transmission delay or
transmission error, a few Hello packets may be lost or incorrectly transmitted. In
this case, the neighbor relationship frequently changes between the Up and Down
states, leading to route flapping.
By default, delay-interval is 60s.
If a new delay-interval is configured and it is less than the remaining time of the
ongoing delay, the new delay-interval takes effect immediately; if the new delay-
interval is greater than the remaining time of the ongoing delay, the ongoing delay
continues until the new delay-interval takes effect at the next delay.
----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
8.6.2 Improving IS-IS Network Security
Before improving IS-IS network security, complete the following task:
l 8.6.1 Configure Basic IS-IS Functions
8.6.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.
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
Simple authentication and MD5 authentication have potential security risks. HMAC-SHA256
authentication mode is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:


undo portswitch

NOTE
Step 4 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-
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.
----End
8.6.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
Simple and MD5 authentication authentication have potential security risks. HMAC-SHA256
Characters %^%# are used as the prefix and suffix of existing passwords with variable
lengths. Therefore, characters %^%# cannot be configured together at the beginning or end of
a simple text password.
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 ]
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 ] plain-cipher-text } [ ip | osi ] | keychain keychain-name | hmac-

sha256 key-id key-id } [ snp-packet { authentication-avoid | send-only } |

all-send-only ]
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
8.6.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.

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.6.3 Controlling IS-IS Route Selection
Before configuring IS-IS route selection, complete the following task:
8.6.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.
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
8.6.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 the neighbor relationship is re-
established.
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.
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:

undo portswitch

NOTE
4. 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

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 [ compatible ]
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 8-10.
Table 8-10 Mapping between IS-IS interface costs and interface bandwidth
Cost Bandwidth Range
60 Interface bandwidth ≤ 10 Mbit/s
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
8.6.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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. Run:
The maximum number of load-balancing equal-cost IS-IS routes is set.

By default, load balancing is supported and a maximum of 8 equal-cost routes can
participate in load balancing.
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 lower preference value (higher preference) are selected
for load balancing.
2. Next hop System ID: If routes have the same priorities, routes with smaller System ID
are selected for load balancing.
3. Interface index: If routes have the same priorities and System ID, routes with lower
interface index values are selected for load balancing.
l Configure preference values for equal-cost IS-IS routes.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. Run:
nexthop ip-address weight value
A preference value is configured for an equal-cost IS-IS route.

By default, the preference value configured for equal-cost IS-IS routes is 255. A
smaller value indicates a higher priority.
----End

8.6.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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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 } | direct { allow-filter-policy | allow-up-down-bit }
* ] *
Routes that meet the specified conditions in the Level-2 areas are leaked into the
local Level-1 area.
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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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 } | direct allow-filter-policy ] *
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
8.6.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 ]
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
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
8.6.4 Controlling IS-IS Route Exchange
Before controlling IS-IS route exchange, complete the following task:
8.6.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.
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
8.6.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 ]
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

8.6.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
8.6.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 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
IS-IS LSDB information.
l Run the display ip routing-table [ verbose ] command to check the IP routing table.
----End
8.6.5 Configuring IS-IS Route Summarization
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:
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.
8.6.6 Controlling IS-IS Route Convergence
Before configuring IS-IS route convergence, complete the following task:
8.6.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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. 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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. 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.6.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 be more information in each LSP.
LSPs generated
and LSPs to
be received.
Set the Set the When a switch 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 switches, the lifetime of the LSP is reduced
LSPs LSPs to gradually. If the switch does not receive any more update
ensure the LSPs and the lifetime of the LSP is reduced to 0, the LSP
validity of will be deleted from the LSDB 60s later if no more
an LSP updated LSPs are 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 switch sends an LSP to its neighbors and then the
LSPs to neighbors send the received LSP to their respective
synchronize neighbors except the switch that first sends the LSP. In this
LSDBs. manner, the LSP is flooded among the switches of the
same level. LSP flooding allows each switch of the same
level to have the same LSP information and synchronize
its LSDB with each other.


Parameters
Set the Set the Reducing the minimum interval for sending LSPs speeds
minimum interval for up LSP flooding.
interval at sending an
which LSPs LSP during
are sent LSP update.
Configure the Control the On an IS-IS network, if the local routing information
intelligent interval for changes, a switch needs to generate a new LSP to notify
timer used to generating this change. If the local routing information changes
generate LSPs LSPs frequently, a large number of new LSPs are generated,
intelligently which occupies a lot of system resources and decreases
to speed up system performance. To speed up network convergence
route and prevent system performance from being affected,
convergenc configure an intelligent timer for generating LSPs. This
e and timer can adjust the delay in generating LSPs based on the
reduce routing information change frequency.
system
load.
Enable LSP Control the When an IS-IS switch receives new LSPs from other
fast flooding number of switches, it switch updates the LSPs in the local LSDB
LSPs and periodically floods out the updated LSPs according to
flooded a 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
interface to number smaller than the specified number before
speed up calculating routes. This speeds up LSDB synchronization.
IS-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.
are retransmitti The device at one end of the link sends an LSP. If the
retransmitted ng LSPs to device at the other end receives this LSP, it replies with a
over a P2P link ensure PSNP. If the device that has sent an LSP does not receive a
LSDB PSNP from the other end in a period of time, the device
synchroniza will retransmit the LSP.
tion on a
P2P
network.
Procedure
l Set the maximum length for LSPs.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. Set the maximum length for LSPs.
n Run:
lsp-length originate max-size
The maximum length is set for each generated LSP.

n 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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. 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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. (Optional) Run:

A broadcast interface is simulated as a P2P interface.
NOTE
If the interface type is P2P, this step is not required.

e. 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.6.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:

undo portswitch

NOTE
Step 4 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
8.6.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:
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-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 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.6.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.
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.
----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
8.6.7 Configuring LSP Fragment Extension
Before configuring LSP fragment extension, complete the following task:
l 8.6.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 switch 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.
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 ] ]
8.6.8 Configuring a Mesh Group on an NBMA Network
Before configuring a mesh group, complete the following task:
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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.6.9 Configuring IS-IS Reliability
Before configuring IS-IS reliability, complete the following task:
8.6.9.1 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
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.
Only the S5720EI, S5720HI and S6720EI support BFD for IS-IS.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd


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
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:

undo portswitch

NOTE

Step 10 Run:
isis bfd static
Static IPv4 BFD is enabled on the specified interface.
----End

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.
8.6.9.2 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
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.
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.
Only the S5720EI, S5720HI and S6720EI BFD for IS-IS.
Procedure
l Configure dynamic BFD for IS-IS in a specified IS-IS process.
a. Run:
system-view


b. Run:
bfd

c. Run:
quit

d. Run:
isis process-id

e. 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.
f. (Optional) Run:
bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval
transmit-interval | detect-multiplier multiplier-value } *
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.
g. (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.
a. Run:
system-view

b. Run:
bfd

c. Run:
quit

d. Run:

e. (Optional) On an Ethernet interface, run:
undo portswitch


NOTE
modes.
f. Run:
isis bfd enable
BFD is enabled on the interface to establish a BFD session.

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.
g. (Optional) Run:
isis bfd { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value } *
Run this command when BFD session parameters need to be configured for a
h. (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.
8.6.9.3 Enabling IS-IS GR
Context
The restart of an IS-IS switch causes the temporary interruption of the network, because the
adjacency relationship between the switch and its neighbor is torn down. The LSPs of the
switch 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 switch
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 switch restarts.
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]


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.
8.6.10 Configuring the Overload Bit for an IS-IS Device
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 ]
Step 3 Run:
set-overload [ on-startup [ timeout1 | start-from-nbr system-id [ timeout1
[ timeout2 ] ] | wait-for-bgp [ timeout1 ] ] [ send-sa-bit [ timeout3 ] ] ]
[ 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
8.7.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 ] 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
8.7.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

8.7.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
8.8.1 Example for Configuring Basic IS-IS Functions

As shown in Figure 8-27, there are four switches (SwitchA, SwitchB, SwitchC, and SwitchD)
on the network. The four switches need to communicate with each other. SwitchA and
SwitchB can only process a small amount of data because they have lower performance than
the other two switches.

Figure 8-27 Networking diagram of configuring basic IS-IS functions
SwitchA
L1
GE0/0/1
VLANIF10
10.1.1.2/24
GE0/0/2
SwitchC GE0/0/1 VLANIF40
GE0/0/1
VLANIF10 L1/2 VLANIF30 172.16.1.1/24
10.1.1.1/24 192.168.0.2/24
IS-IS
Area 10 GE0/0/2 GE0/0/3
VLANIF20 VLANIF30 SwitchD
10.1.2.1/24 192.168.0.1/24 L2
GE0/0/1 IS-IS
VLANIF20 Area 20
10.1.2.2/24
SwitchB
L1
1. Enable IS-IS on each switch so that the switches can be interconnected. Configure
SwitchA and SwitchB as Level-1 devices to enable them to maintain less data.
Procedure
Step 1 Create VLANs and add corresponding interfaces to the VLANs.
Step 2 Assign an IP address to each VLANIF interface.
Step 3 Run the IS-IS progress on each Switch, specify the network entity title, and configure the
level.

[SwitchA] isis 1
[SwitchA-isis-1] is-level level-1
[SwitchA-isis-1] network-entity 10.0000.0000.0001.00
[SwitchA-isis-1] quit
[SwitchB] isis 1
[SwitchB-isis-1] is-level level-1
[SwitchB-isis-1] network-entity 10.0000.0000.0002.00
[SwitchB-isis-1] quit
[SwitchC] isis 1
[SwitchC-isis-1] network-entity 10.0000.0000.0003.00
[SwitchC-isis-1] quit
[SwitchD] isis 1
[SwitchD-isis-1] is-level level-2
[SwitchD-isis-1] network-entity 20.0000.0000.0004.00
[SwitchD-isis-1] quit
Step 4 Enable the IS-IS progress on each interface.

[SwitchA-Vlanif10] isis enable 1
[SwitchB-Vlanif20] isis enable 1
[SwitchC-Vlanif10] isis enable 1
[SwitchD-Vlanif30] isis enable 1

# View the IS-IS LSDB of each Switch.
[SwitchA] 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* 0x0000006e 0x953e 862 68 0/0/0
0000.0000.0002.00-00 0x0000006a 0xc015 766 68 0/0/0
0000.0000.0002.01-00 0x00000008 0xccb6 766 55 0/0/0
0000.0000.0003.00-00 0x00000086 0x529e 1155 111 1/0/0
0000.0000.0003.01-00 0x0000005e 0xf238 1155 55 0/0/0
Total LSP(s): 5
*(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended),
ATT-Attached, P-Partition, OL-Overload
[SwitchB] display isis lsdb

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

-------------------------------------------------------------------------------
0000.0000.0001.00-00 0x0000006e 0x953e 899 68 0/0/0
0000.0000.0002.00-00* 0x0000006a 0xc015 808 68 0/0/0
0000.0000.0002.01-00* 0x00000008 0xccb6 808 55 0/0/0
0000.0000.0003.00-00 0x00000086 0x529e 1195 111 1/0/0
0000.0000.0003.01-00 0x0000005e 0xf238 1195 55 0/0/0
Total LSP(s): 5
[SwitchC] display isis lsdb

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

-------------------------------------------------------------------------------
0000.0000.0001.00-00 0x0000006e 0x953e 953 68 0/0/0
0000.0000.0002.00-00 0x0000006a 0xc015 859 68 0/0/0
0000.0000.0002.01-00 0x00000008 0xccb6 859 55 0/0/0
0000.0000.0003.00-00* 0x00000085 0x549d 937 111 1/0/0
0000.0000.0003.01-00* 0x0000005d 0xf437 937 55 0/0/0
Total LSP(s): 5

-------------------------------------------------------------------------------
0000.0000.0003.00-00* 0x0000008a 0x513c 876 100 0/0/0
0000.0000.0004.00-00 0x00000063 0x48ad 761 84 0/0/0
0000.0000.0004.01-00 0x0000005b 0x3aef 761 55 0/0/0
Total LSP(s): 3
[SwitchD] display isis lsdb

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

-------------------------------------------------------------------------------
0000.0000.0003.00-00 0x0000008a 0x513c 901 100 0/0/0
0000.0000.0004.00-00* 0x00000063 0x48ad 789 84 0/0/0
0000.0000.0004.01-00* 0x0000005b 0x3aef 789 55 0/0/0
Total LSP(s): 3
# View the IS-IS routing table of each Switch. A default route is available in the routing table
of the Level-1 devices and the next hop is a Level-1-2 device. The routing table of the Level-2
device contains all Level-1 and Level-2 routes.
[SwitchA] display isis route
Route information for ISIS(1)

-----------------------------
ISIS(1) Level-1 Forwarding Table

--------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL Vlanif10 10.1.1.1 A/-/-/-
192.168.0.0/24 20 NULL Vlanif10 10.1.1.1 A/-/-/-
10.1.1.0/24 10 NULL Vlanif10 Direct D/-/L/-
10.1.2.0/24 20 NULL Vlanif10 10.1.1.1 A/-/-/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set
[SwitchB] display isis route

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

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

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL Vlanif20 10.1.2.1 A/-/-/-
192.168.0.0/24 20 NULL Vlanif20 10.1.2.1 A/-/-/-
10.1.1.0/24 20 NULL Vlanif20 10.1.2.1 A/-/-/-
U-Up/Down Bit Set
[SwitchC] display isis route

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

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

-------------------------------------------------------------------------------
U-Up/Down Bit Set

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

-------------------------------------------------------------------------------
172.16.1.0/24 20 NULL Vlanif30 192.168.0.2 A/-/-/-


U-Up/Down Bit Set
[SwitchD] display isis route

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

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

-------------------------------------------------------------------------------
10.1.1.0/24 20 NULL Vlanif30 192.168.0.1 A/-/-/-
10.1.2.0/24 20 NULL Vlanif30 192.168.0.1 A/-/-/-
U-Up/Down Bit Set
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
#
return

#
sysname SwitchB
#
vlan batch 20
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
#
return

#
sysname SwitchC

#
vlan batch 10 20 30
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
interface Vlanif30
ip address 192.168.0.1 255.255.255.0
isis enable 1
#
#
#
#
return

#
sysname SwitchD
#
vlan batch 30 40
#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
interface Vlanif30
ip address 192.168.0.2 255.255.255.0
isis enable 1
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
#
#
return
8.8.2 Example for Configuring IS-IS Route Aggregation
As shown in Figure 8-28, three switches run IS-IS to communicate with each other. SwitchA
is a Level-2 device, SwitchB is a Level-1-2 device, and SwitchC is a Level-1 device. SwitchA

is heavily loaded because there are too many routing entries on the IS-IS network. Therefore,
system resource consumption of SwitchA needs to be reduced.
Figure 8-28 Networking diagram for configuring IS-IS route aggregation
GE0/0/2
Network1 VLANIF20
172.16.1.0/24 172.16.1.1/24
SwitchB
SwitchC GE0/0/1 SwitchA
GE0/0/3 GE0/0/1 L1/L2
L1 VLANIF50 L2
VLANIF30 VLANIF10
172.16.2.1/24 172.16.4.2/24 172.17.1.1/24
Network2
172.16.2.0/24 GE0/0/1 GE0/0/2
VLANIF10 VLANIF50
172.16.4.1/24 172.17.1.2/24
Area20
GE0/0/4 Area10
VLANIF40
Network3
172.16.3.1/24
172.16.3.0/24
1. Configure IP addresses for interfaces and enable IS-IS on each switch so that the
switches can be interconnected.
2. Configure route summarization on SwitchB to reduce the routing table size of SwitchA
without affecting data forwarding so that the system resource consumption of SwitchA
can be reduced.
Procedure


Step 3 Configure basic IS-IS functions.
[SwitchA] isis 1
[SwitchB] isis 1
[SwitchC] isis 1
[SwitchC-isis-1] is-level level-1
Step 4 Check the IS-IS routing table of SwitchA.

[SwitchA]display isis route

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

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

-------------------------------------------------------------------------------
172.16.1.0/24 30 NULL Vlanif50 172.17.1.2 A/-/-/-
172.16.2.0/24 30 NULL Vlanif50 172.17.1.2 A/-/-/-
172.16.3.0/24 30 NULL Vlanif50 172.17.1.2 A/-/-/-
172.16.4.0/24 20 NULL Vlanif50 172.17.1.2 A/-/-/-
U-Up/Down Bit Set
Step 5 Configure route aggregation on SwitchB.
# Aggregate 172.16.1.0/24, 172.16.2.0/24, 172.16.3.0./24, and 172.16.4.0/24 as 172.16.0.0/16

on SwitchB.

[SwitchB] isis 1
[SwitchB-isis-1] summary 172.16.0.0 255.255.0.0 level-1-2
# Check the IS-IS routing table of SwitchA. The routing table contains the route
172.16.0.0/16 aggregated from 172.16.1.0/24, 172.16.2.0/24, 172.16.3.0./24, and
172.16.4.0/24.

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

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

-------------------------------------------------------------------------------
172.16.0.0/16 20 NULL Vlanif50 172.17.1.2 A/-/-/-
U-Up/Down Bit Set
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 50
#
isis 1
is-level level-2
network-entity 20.0000.0000.0001.00
#
interface Vlanif50
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
#
return

#
sysname SwitchB
#
vlan batch 10 50
#
isis 1
network-entity 10.0000.0000.0002.00
summary 172.16.0.0 255.255.0.0 level-1-2
#
interface Vlanif10
ip address 172.16.4.2 255.255.255.0
isis enable 1
#
interface Vlanif50
ip address 172.17.1.2 255.255.255.0
isis enable 1
#

#
#
return

#
sysname SwitchC
#
vlan batch 10 20 30 40
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
interface Vlanif10
ip address 172.16.4.1 255.255.255.0
isis enable 1
#
interface Vlanif20
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface Vlanif30
ip address 172.16.2.1 255.255.255.0
isis enable 1
#
interface Vlanif40
ip address 172.16.3.1 255.255.255.0
isis enable 1
#
#
#
#
#
return
8.8.3 Example for Configuring the DIS Election

As shown in Figure 8-29, four switches on the broadcast network communicate using IS-IS.
SwitchA and SwitchB are Level-1-2 devices, SwitchC is a Level-1 device, and SwitchD is a
Level-2 device. SwitchA with high performance needs to be configured as a Level-2 DIS.

Figure 8-29 Networking diagram for configuring the DIS election
SwitchA SwitchB
L1/L2 L1/L2
GE0/0/1 G GE0/0/1
E0
/2
VLANIF10
/0
VLANIF10 /0
E0
10.1.1.1/24 /1 10.1.1.2/24
G
/3 G
E0
/0
GE0/0/1 Switch GE0/0/1
E0
/0
VLANIF10 / 4 VLANIF10
G
10.1.1.3/24 10.1.1.4/24
SwitchC SwitchD
L1 L2
1. Configure IS-IS to enable network interconnectivity.
2. Configure the DIS priority of Switch A to 100 so that SwitchA can be elected as a
Level-2 DIS.
Procedure

Step 3 View the MAC address of the VLANIF 10 interface on each Switch.
# View the MAC address of the VLANIF 10 interface on SwitchA.
[SwitchA] display interface Vlanif 10
Vlanif10 current state : UP

Line protocol current state : UP

Last line protocol up time : 2014-12-02 18:02:15 UTC+08:00
Description:
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 10.1.1.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc10-afec
Current system time: 2014-12-02 18:03:12+08:00
Input bandwidth utilization : --
Output bandwidth utilization : --
# View the MAC address of the VLANIF 10 interface on SwitchB.

[SwitchB] display interface Vlanif 10
Description:
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fccd-acdf
# View the MAC address of the VLANIF 10 interface on SwitchC.

[SwitchC] display interface Vlanif 10
Description:
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc50-25fe
# View the MAC address of the VLANIF 10 interface on SwitchD.

[SwitchD] display interface Vlanif 10
Description:
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fcfd-305c
Step 4 Configure the basic IS-IS functions.
[SwitchA] isis 1
[SwitchB] isis 1


[SwitchC] isis 1
[SwitchD] isis 1
# View information about the IS-IS neighbors of SwitchA.

[SwitchA] display isis peer
Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type

PRI
-------------------------------------------------------------------------------
0000.0000.0002 Vlanif10 0000.0000.0002.01 Up 9s L1(L1L2)
64
0000.0000.0003 Vlanif10 0000.0000.0002.01 Up 27s L1
64
0000.0000.0002 Vlanif10 0000.0000.0002.01 Up 28s L2(L1L2)
64
0000.0000.0004 Vlanif10 0000.0000.0002.01 Up 8s L2
64
Total Peer(s): 4
# View information about the IS-IS interface of SwitchA.

[SwitchA] display isis interface
Interface information for ISIS(1)

---------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
Vlanif10 001 Up Down 1497 L1/L2 No/No
# View information about the IS-IS interface of SwitchB.

[SwitchB] display isis interface

---------------------------------
Vlanif10 001 Up Down 1497 L1/L2 Yes/Yes
# View information about the IS-IS interface of SwitchD.

[SwitchD] display isis interface

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

NOTE
When the default DIS priority is used, the interface on SwitchB has the greatest MAC address among all
the interfaces on the Level-1 Switches. Therefore, SwitchB is elected as the Level-1 DIS. The interface
on SwitchD has the greatest MAC address among all the interfaces on the Level-2 Switches. Therefore,
SwitchD is elected as the Level-2 DIS. The Level-1 pseudonode is 0000.0000.0002.01. The Level-2
pseudonode is 0000.0000.0004.01.
Step 5 Set the DIS priority of SwitchA.

[SwitchA-Vlanif10] isis dis-priority 100
# View information about the IS-IS neighbors of SwitchA.

System Id Interface Circuit Id State HoldTime

Type PRI
-------------------------------------------------------------------------------
0000.0000.0002 Vlanif10 0000.0000.0001.01 Up 21s
L1(L1L2) 64
0000.0000.0003 Vlanif10 0000.0000.0001.01 Up 27s
L1 64
0000.0000.0002 Vlanif10 0000.0000.0001.01 Up 28s
L2(L1L2) 64
0000.0000.0004 Vlanif10 0000.0000.0001.01 Up 30s
L2 64
Total Peer(s): 4
# View information about the IS-IS interface of SwitchA.

[SwitchA] display isis interface

---------------------------------
Vlanif10 001 Up Down 1497 L1/L2 Yes/Yes
As shown in the output information, after the DIS priority of the IS-IS interface is changed,
SwitchA immediately becomes a Level-1 and Level-2 DIS and its pseudonode is
0000.0000.0001.01.
# View information about the IS-IS neighbors and IS-IS interfaces on SwitchB.
[SwitchB] display isis peer
System Id Interface Circuit Id State HoldTime

Type PRI
-------------------------------------------------------------------------------
0000.0000.0001 Vlanif10 0000.0000.0001.01 Up 7s
L1(L1L2) 100
0000.0000.0003 Vlanif10 0000.0000.0001.01 Up 25s
L1 64
0000.0000.0001 Vlanif10 0000.0000.0001.01 Up 7s
L2(L1L2) 100
0000.0000.0004 Vlanif10 0000.0000.0001.01 Up 25s
L2 64
Total Peer(s): 4

[SwitchB] display isis interface

---------------------------------
# View information about the IS-IS neighbors and IS-IS interfaces on SwitchD.
[SwitchD] display isis peer
System Id Interface Circuit Id State HoldTime Type

PRI
-------------------------------------------------------------------------------
0000.0000.0002 Vlanif10 0000.0000.0001.01 Up 28s L2 64
0000.0000.0001 Vlanif10 0000.0000.0001.01 Up 9s L2
100
Total Peer(s): 2
[SwitchD] display isis interface

---------------------------------
----End
Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
#
#
#
return

#
sysname SwitchA
#
vlan batch 10
#
isis 1
network-entity 10.0000.0000.0001.00
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
isis enable 1

isis dis-priority 100

#
#
return

#
sysname SwitchB
#
vlan batch 10
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
#
return

#
sysname SwitchC
#
vlan batch 10
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
interface Vlanif10
ip address 10.1.1.3 255.255.255.0
isis enable 1
#
#
return

#
sysname SwitchD
#
vlan batch 10
#
isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
#
interface Vlanif10
ip address 10.1.1.4 255.255.255.0
isis enable 1
#
#
return

8.8.4 Example for Configuring IS-IS Load Balancing

As shown in Figure 8-30, switches run IS-IS to implement IP interworking. Congestion of the
network from SwitchA to destination address 172.17.1.0/24 needs to be relieved to improve
network resource efficiency.
Figure 8-30 Networking diagram for configuring IS-IS load balancing
GE0/0/1 GE0/0/2
VLANIF10 VLANIF30
10.1.1.2/24 192.168.0.1/24
GE0/0/1 SwitchB GE0/0/1
VLANIF10 L2 VLANIF30
GE0/0/3 10.1.1.1/24 192.168.0.2/24 GE0/0/3
VLANIF50 VLANIF60
172.16.1.1/24 SwitchA Area 10 SwitchD 172.17.1.1/24
L2 L2
GE0/0/2 GE0/0/2
VLANIF20 VLANIF40
SwitchC 192.168.1.2/24
10.1.2.1/24
L2 GE0/0/2
GE0/0/1
VLANIF20 VLANIF40
10.1.2.2./24 192.168.1.1/24
1. Configure basic IS-IS functions on each switch to implement IP interworking.
2. Configure load balancing to balance traffic from SwitchA to SwitchD between SwitchB
and SwitchC.
Procedure
Step 1 Configure VLANs that the related interfaces belong to.



[SwitchA] isis 1
Step 4 Set the number of equal-cost routes for load balancing to 1 on SwitchA.
[SwitchA] isis 1
[SwitchA-isis-1] maximum load-balancing 1
# View the routing table of SwitchA.


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

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

-------------------------------------------------------------------------------
172.17.1.0/24 30 NULL Vlanif10 10.1.1.2 A/-/-/-
192.168.0.0/24 20 NULL Vlanif10 10.1.1.2 A/-/-/-
192.168.1.0/24 20 NULL Vlanif20 10.1.2.2 A/-/-/-
U-Up/Down Bit Set
As shown in the routing table, when the maximum number of equal-cost routes for load
balancing is set to 1, IS-IS selects 10.1.1.2 as the next hop to the destination network
172.17.1.0. This is because SwitchB has a smaller system ID.
Step 5 Restore the default number of equal-cost routes for load balancing on SwitchA.
[SwitchA] isis 1
[SwitchA-isis-1] undo maximum load-balancing



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

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

-------------------------------------------------------------------------------
172.17.1.0/24 30 NULL Vlanif10 10.1.1.2 A/-/-/-
Vlanif20 10.1.2.2
192.168.0.0/24 20 NULL Vlanif10 10.1.1.2 A/-/-/-
192.168.1.0/24 20 NULL Vlanif20 10.1.2.2 A/-/-/-
U-Up/Down Bit Set
As shown in the routing table, the number of equal-cost routes for load balancing is restored
to the default value 8. Both the next hops of SwitchA, 10.1.1.2 (SwitchB) and 10.1.2.2
(SwitchC) now become valid.
Step 6 (Optional) Set the preference for equal-cost routes on SwitchA.
[SwitchA] isis
[SwitchA-isis-1] nexthop 10.1.2.2 weight 1


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

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

-------------------------------------------------------------------------------
172.17.1.0/24 30 NULL Vlanif20 10.1.2.2 A/-/-/-
192.168.0.0/24 20 NULL Vlanif10 10.1.1.2 A/-/-/-
192.168.1.0/24 20 NULL Vlanif20 10.1.2.2 A/-/-/-
U-Up/Down Bit Set
As shown in the routing table, the preference of the next hop 10.1.2.2 (SwitchC) with the
weight as 1, is higher than that of 10.1.1.2 (SwitchB), after the weight is set for equal-cost
routes. Therefore, IS-IS selects route with the next hop 10.1.2.2 as the optimal route.
----End
Configuration Files
#
sysname SwitchA
#

vlan batch 10 20 50
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
nexthop 10.1.2.2 weight 1
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
interface Vlanif50
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
#
#
#
return
#
sysname SwitchB
#
vlan batch 10 30
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface Vlanif30
ip address 192.168.0.1 255.255.255.0
isis enable 1
#
#
#
return
#
sysname SwitchC
#
vlan batch 20 40
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00

#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
interface Vlanif40
ip address 192.168.1.1 255.255.255.0
isis enable 1
#
#
#
return

#
sysname SwitchD
#
vlan batch 30 40 60
#
isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
#
interface Vlanif30
ip address 192.168.0.2 255.255.255.0
isis enable 1
#
interface Vlanif40
ip address 192.168.1.2 255.255.255.0
isis enable 1
#
interface Vlanif60
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
#
#
#
return
8.8.5 Example for Configuring Static BFD for IS-IS

As shown in Figure 8-31, three routers are interconnected using IS-IS, and SwitchA and
SwitchB communicate with each other through a Layer 2 switch. When the link between
SwitchA and SwitchB is faulty, the two routers need to rapidly respond to the fault and
reestablish a neighbor relationship.

Figure 8-31 Networking diagram of configuring static BFD for IS-IS

GE0/0/1 GE0/0/1 GE0/0/2
VLANIF10 VLANIF10 VLANIF30
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24
GE0/0/1
SwitchA Switch SwitchB VLANIF30 SwitchC
10.2.1.2/24
NOTE
BFD for IS-IS cannot be used to detect the multi-hop link between SwitchA and SwitchC, because the
IS-IS neighbor relationship cannot be established between SwitchA and SwitchC.
1. Configure IP addresses for interfaces and enable IS-IS on each router to ensure reachable
routes between the routers.
2. Enable static BFD for IS-IS on SwitchA and SwitchB so that routers can rapidly detect
link faults.
Procedure
# Configure SwitchA. Ensure that the configurations of Switch, SwitchB and SwitchC are the
same as the configuration of SwitchA.
Step 2 Assign the IP addresses for VLANIF interfaces.


[SwitchA] isis 1
[SwitchA-isis-1] network-entity aa.1111.1111.1111.00

[SwitchB] isis 1
[SwitchB-isis-1] network-entity aa.2222.2222.2222.00
[SwitchC] isis 1
[SwitchC-isis-1] network-entity aa.3333.3333.3333.00
# After the preceding configurations, you can see that the neighbor relationship is established
between SwitchA and SwitchB.
System Id Interface Circuit Id State HoldTime Type PRI

-------------------------------------------------------------------------------
2222.2222.2222 Vlanif10 1111.1111.1111.01 Up 23s L2 64
Total Peer(s): 1
The IS-IS routing table of SwitchA contains the routes to SwitchB and SwitchC.

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

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

-------------------------------------------------------------------------------
10.2.1.0/24 20 NULL Vlanif10 10.1.1.2 A/-/L/-
U-Up/Down Bit Set
Step 4 Configure BFD.

# Enable BFD on SwitchA and configure a BFD session.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bfd atob bind peer-ip 10.1.1.2 interface vlanif 10
[SwitchA-bfd-session-atob] discriminator local 1
[SwitchA-bfd-session-atob] discriminator remote 2
[SwitchA-bfd-session-atob] commit
[SwitchA-bfd-session-atob] quit
# Enable BFD on SwitchB and configure a BFD session.

[SwitchB] bfd
[SwitchB-bfd] quit

[SwitchB] bfd btoa bind peer-ip 10.1.1.1 interface vlanif 10

[SwitchB-bfd-session-btoa] discriminator local 2
[SwitchB-bfd-session-btoa] discriminator remote 1
[SwitchB-bfd-session-btoa] commit
[SwitchB-bfd-session-btoa] quit
After the preceding configurations, run the display bfd session command on SwitchA or
SwitchB, and you can see that the status of the BFD session is Up.
The following uses the display on SwitchA as an an example.

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 2 10.1.1.2 Up S_IP_IF Vlanif10
--------------------------------------------------------------------------------
Step 5 Enable IS-IS fast detect.
[SwitchA-Vlanif10] isis bfd static
[SwitchB-Vlanif10] isis bfd static
# Enable log information display on SwitchA.

[SwitchA] info-center source bfd channel 1 log level debugging state on
[SwitchA] quit
<SwitchA> debugging isis circuit-information
<SwitchA> terminal debugging
<SwitchA> terminal logging
<SwitchA> terminal monitor
# Run the shutdown command on GigabitEthernet0/0/1 on SwitchB to simulate a link fault.

[SwitchB]interface gigabitethernet 0/0/1
# On SwitchA, you can view the following log and debugging information, which indicates
that IS-IS deletes the neighbor relationship with SwitchB after being notified by BFD of the
fault.
May 19 2013 09:34:49+08:00 SwitchB %%01ISIS/4/PEER_DOWN_BFDDOWN(l)[2]:ISIS 1 ne
ighbor 2222.2222.2222 was Down on interface Vlanif2710 because the BFD node was d
own.
The Hello packet was received at 09:29:39 last time; the maximum interval for se
nding Hello packets was 8944; the local router sent 392 Hello packets and receiv
ed 2 packets; the type of the Hello packet was Lan Level-2.
Run the display isis route command or the display isis peer command on SwitchA, and you
can see that no information is displayed. This indicates that the IS-IS neighbor relationship
between SwitchA and SwitchB is deleted.
----End

Configuration Files
#
sysname Switch
#
vlan batch 10
#
#
#
return

#
sysname SwitchA
#
vlan batch 10
#
info-center source BFD channel 1 log level debugging
#
bfd
#
isis 1
is-level level-2
network-entity aa.1111.1111.1111.00
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis bfd static
#
#
bfd atob bind peer-ip 10.1.1.2 interface Vlanif10
commit
#
return

#
sysname SwitchB
#
vlan batch 10 30
#
bfd
#
isis 1
is-level level-2
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
isis enable 1
isis bfd static
#
interface Vlanif30
ip address 10.2.1.1 255.255.255.0
isis enable 1
#

#
#
bfd btoa bind peer-ip 10.1.1.1 interface Vlanif10
commit
#
return

#
sysname SwitchC
#
vlan batch 30
#
isis 1
is-level level-2
#
interface Vlanif30
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
#
return
8.8.6 Example for Configuring Dynamic BFD for IS-IS

As shown in Figure 8-32, three routers are interconnected using IS-IS, and SwitchA and
SwitchB communicate with each other through a Layer 2 switch. When the link that passes
through the switch between SwitchA and SwitchB fails, the two routers need to rapidly
respond to the fault, and traffic can be switched to the link that passes through SwitchC for
forwarding.
Figure 8-32 Networking diagram of configuring dynamic BFD for IS-IS

GE0/0/2 GE0/0/2 GE0/0/3
Switch A VLANIF20 VLANIF20 SwitchB VLANIF40
10.3.3.1/24 10.3.3.2/24 172.16.1.1/24
GE0/0/1 GE0/0/2
GE0/0/1 GE0/0/1
VLANIF10 VLANIF50
10.1.1.1/24 10.2.2.2/24
GE0/0/1 GE0/0/2
VLANIF10 VLANIF50
10.1.1.2/24 10.2.2.1/24
SwitchC

1. Configure IP addresses for interfaces and enable IS-IS on each router to ensure reachable
routes between the routers.
2. Set the IS-IS interface cost to control route selection of the routers to make the link that
passes through the switch from SwitchA to SwitchB as the primary link and the link that
passes through SwitchC as the backup link.
3. Configure dynamic BFD for IS-IS on SwitchA, SwitchB, and SwitchC so that link faults
can be detected rapidly and traffic can be switched to the backup link for forwarding.
Procedure
# Configure SwitchA. Ensure that the configurations of Switch, SwitchB, and SwitchC are the
same as the configuration of SwitchA.
Step 2 Assign the IP addresses for VLANIF interfaces.


[SwitchA] isis
[SwitchA] interface vlanif10
[SwitchB] isis


[SwitchC] isis
# After the preceding configurations, run the display isis peer command. You can see that the
neighbor relationships are established between SwitchA and SwitchB, and between SwitchA
and SwitchC. The following uses the configuration of SwitchA as an example.

-------------------------------------------------------------------------------
0000.0000.0003 Vlanif10 0000.0000.0001.02 Up 21s L2 64
0000.0000.0002 Vlanif20 0000.0000.0002.01 Up 9s L2 64
Total Peer(s): 2
# Switchs have learned routes from each other. The following uses the routing table of
SwitchA as an example.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.2.2.0/24 ISIS-L2 15 20 D 10.3.3.2 Vlanif20
ISIS-L2 15 20 D 10.1.1.2 Vlanif10
10.3.3.0/24 Direct 0 0 D 10.3.3.1 Vlanif20
10.3.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
172.16.1.0/24 ISIS-L2 15 20 D 10.3.3.2 Vlanif20
As shown in the routing table, the next-hop address of the route to 172.16.1.0/24 is 10.3.3.2,
and traffic is transmitted on the primary link SwitchA→SwitchB.
Step 4 Set the interface cost.


[SwitchA-Vlanif20] isis cost 5
[SwitchB-Vlanif20] isis cost 5
Step 5 Configure BFD for IS-IS processes.

# Enable BFD for IS-IS on SwitchA.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] isis
[SwitchA-isis-1] bfd all-interfaces enable
# Enable BFD for IS-IS on SwitchB.

[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] isis
[SwitchB-isis-1] bfd all-interfaces enable
# Enable BFD for IS-IS on SwitchC.

[SwitchC] bfd
[SwitchC-bfd] quit
[SwitchC] isis
[SwitchC-isis-1] bfd all-interfaces enable
# After the preceding configurations, run the display isis bfd session all command on
SwitchA, SwitchB, and SwitchC. You can see that the BFD session status is Up.
The following uses the display on SwitchA as an example.
[SwitchA] display isis bfd session all
BFD session information for ISIS(1)

-----------------------------------
Peer System ID : 0000.0000.0003 Interface : Vlanif10

TX : 1000 BFD State : up Peer IP Address : 10.1.1.2
RX : 1000 LocDis : 8193 Local IP Address: 10.1.1.1
Multiplier : 3 RemDis : 8193 Type : L2
Diag : No diagnostic information

Total BFD session(s): 2
As shown in the preceding display, the status of the BFD session between SwitchA and
SwitchB and that between SwitchA and SwitchC is Up.
Step 6 Configure BFD for IS-IS interfaces.
# Configure BFD on VLANIF20 of SwitchA, 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.


[SwitchA-Vlanif20] isis bfd enable
[SwitchA-Vlanif20] isis bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
# Configure BFD on VLANIF20 of SwitchB, 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.
[SwitchB-Vlanif20] isis bfd enable
[SwitchB-Vlanif20] 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
SwitchA or SwitchB. You can see that the BFD parameters have taken effect. The following
uses the display on SwitchB as an example.
[SwitchB] display isis bfd session all

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



# Run the shutdown command on GigabitEthernet0/0/2 of SwitchB to simulate a primary
link failure.
Step 8 # View the routing table of SwitchA.

------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.2.2.0/24 ISIS-L2 15 20 D 10.1.1.2 Vlanif10
10.3.3.0/24 Direct 0 0 D 10.3.3.1 Vlanif20
10.3.3.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
172.16.1.0/24 ISIS-L2 15 30 D 10.1.1.2 Vlanif10
As shown in the routing table, the backup link SwitchA→SwitchC→SwitchB takes effect
after the primary link fails, and the next-hop address of the route to 172.16.1.0/24 becomes
10.1.1.2.

# Run the display isis bfd session all command on SwitchA. You can see that the status of the
BFD session between SwitchA and SwitchC is Up.
[SwitchA] display isis bfd session all

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

----End
Configuration Files
#
sysname Switch
#
vlan batch 20
#
#
#
return

#
sysname SwitchA
#
vlan batch 10 20
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface Vlanif20
ip address 10.3.3.1 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
#
#

#
return
#
sysname SwitchB
#
vlan batch 20 40 50
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
interface Vlanif20
ip address 10.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
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface Vlanif50
ip address 10.2.2.2 255.255.255.0
isis enable 1
#
#
#
#
return
#
sysname SwitchC
#
vlan batch 10 50
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface Vlanif50
ip address 10.2.2.1 255.255.255.0
isis enable 1
#
#

#
return
8.8.7 Example for Configuring IS-IS GR
As shown in Figure 8-33, SwitchA, SwitchB, and SwitchC belong to the same autonomous
system. They run the IS-IS protocol to implement interworking and provide the GR
mechanism. When IS-IS is restarted on SwitchA, SwitchA resends connection requests to
neighbors to synchronize the LSDB.
Figure 8-33 Networking diagram of IS-IS GR configuration

SwitchA SwitchC SwitchB
GE0/0/1 GE0/0/2
L1 VLANIF10 L1/L2 VLANIF20 L2
10.1.1.1/24 10.2.1.1/24
GE0/0/1 GE0/0/1
VLANIF10 VLANIF20
10.1.1.2/24 10.2.1.2/24
1. Enable IS-IS on each Switch so that the Switches can be interconnected.
2. Configure GR in the IS-IS view on each Switch and configure the same interval for the
restart.
Procedure
Step 1 Configure VLANs that the related interfaces belong to.
[SwitchA] vlan 10
[SwitchA] interface vlanif10

Step 3 Configure the basic function of IS-IS.
[SwitchA] isis 1
[SwitchB] isis 1
[SwitchC] isis 1
Step 4 Configure IS-IS GR and set the restart interval.
[SwitchA] isis 1
[SwitchA-isis-1] graceful-restart
[SwitchA-isis-1] graceful-restart interval 150
[SwitchA] quit
# Run the display fib command on SwitchA to view the Forwarding Information Base (FIB)
table.
<SwitchA> display fib
Route Flags: G - Gateway Route, H - Host Route, U - Up Route
S - Static Route, D - Dynamic Route, B - Black Hole Route
L - Vlink Route
--------------------------------------------------------------------------------
FIB Table:
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID

127.0.0.1/32 127.0.0.1 HU t[21] InLoop0 0x0
127.0.0.0/8 127.0.0.1 U t[21] InLoop0 0x0
10.1.1.1/32 127.0.0.1 HU t[20678] InLoop0 0x0
10.1.1.0/24 10.1.1.1 U t[20678] Vlanif10 0x0
10.2.1.0/24 10.1.1.2 DGU t[79388] Vlanif10 0x0
# Reset the IS-IS process by using the GR method on SwitchA.

<SwitchA> reset isis all graceful-restart

NOTE
The Switch restarts an IS-IS process in GR mode only when GR is enabled for the IS-IS process.
# Run the display fib command on SwitchA and view the FIB table to check whether GR
works normally. If GR works normally, the FIB table does not change and the forwarding
service is not affected when SwitchA restarts the IS-IS process in GR mode.
L - Vlink Route
--------------------------------------------------------------------------------
FIB Table:

127.0.0.1/32 127.0.0.1 HU t[21] InLoop0 0x0
127.0.0.0/8 127.0.0.1 U t[21] InLoop0 0x0
10.1.1.1/32 127.0.0.1 HU t[20678] InLoop0 0x0
10.1.1.0/24 10.1.1.1 U t[20678] Vlanif10 0x0
10.2.1.0/24 10.1.1.2 DGU t[79388] Vlanif10 0x0
As shown in the display, the FIB table on SwitchA does not change and the forwarding
service is not affected.
# Disable IS-IS GR on SwitchA.
<SwitchA> system-view
[SwitchA] isis 1
[SwitchA-isis-1] undo graceful-restart
[SwitchA] quit
# Reset the IS-IS process on SwitchA.

<SwitchA> reset isis all
# Run the display fib command on SwitchA to view the FIB table.
L - Vlink Route
--------------------------------------------------------------------------------
FIB Table:

127.0.0.1/32 127.0.0.1 HU t[21] InLoop0 0x0
127.0.0.0/8 127.0.0.1 U t[21] InLoop0 0x0
10.1.1.1/32 127.0.0.1 HU t[20678] InLoop0 0x0
10.1.1.0/24 10.1.1.1 U t[20678] Vlanif10 0x0
As shown in the display, the FIB table on SwitchA changes and the forwarding service is
affected.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#

isis 1
graceful-restart
graceful-restart interval 150
is-level level-1
network-entity 10.0000.0000.0001.00
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
#
return

#
sysname SwitchB
#
vlan batch 20
#
isis 1
graceful-restart
is-level level-2
network-entity 10.0000.0000.0002.00
#
interface Vlanif20
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
#
return

#
sysname SwitchC
#
vlan batch 10 20
#
isis 1
graceful-restart
network-entity 10.0000.0000.0003.00
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface Vlanif20
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
#
#
return

8.9.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
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.
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
8.9.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 8.9.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.
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
8.10 References
Table 8-11 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 Multiple

TCP/IP 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
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)

9 IPv6 IS-IS Configuration
About This Chapter
This chapter describes how to configure IPv6 IS-IS. 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.

9.2 Principles
9.9 References

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.
9.2 Principles
9.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.
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.

9.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 9-1 shows the IS-IS MT. Values in Figure 9-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.

Figure 9-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.

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

Configuring basic IS-IS To deploy the IS-IS protocol 9.6.1 Configuring Basic
(IPv6) 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.

Configuring IS-IS (IPv6) On IS-IS networks, 9.6.2 Improving IPv6 IS-IS

network security unauthorized users can Network Security
attack the IS-IS network by
carried on IS-IS networks,
configure the area or domain
authentication and interface
authentication.
Configuring IS-IS (IPv6) If multiple redundant links 9.6.3 Controlling IPv6 IS-
route 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 (IPv6) In practical applications, to 9.6.4 Controlling IPv6 IS-

routing information meet network requirements, IS Route Exchange
exchange configure route policies to
accurately control
advertising and receiving of

Configuring IS-IS (IPv6) Route aggregation allows 9.6.5 Configuring IPv6 IS-
route aggregation multiple routes with the IS Route Summarization
same 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 (IPv6) To enable IS-IS to rapidly 9.6.6 Controlling IPv6 IS-
route 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 9.6.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.

Configuring mesh groups On the NBMA network, 9.6.8 Configuring a Mesh

when an interface of the Group on an NBMA
switch receives a new LSP, Network
the LSP is flooded to other
interfaces of the switch. On
highly-connected networks
that have multiple P2P links,
this processing method
results in repeated LSP
flooding and wastes
bandwidth resources.
To solve this problem, create
a mesh group and add some
interfaces to the group. The
switch 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 (IPv6) If the system cannot store 9.6.9 Configuring the
overload new LSPs or synchronize Overload Bit for an IS-IS
the 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.


Other network elements are required to support IS-IS (IPv6).
License Support
IS-IS (IPv6) is not under license control.
Version Support
Table 9-2 Products and minimum version supporting IS-IS (IPv6)

Required


V200R001 and later
versions.)



V200R001 and later
versions.)



Required

V200R002 and later
versions.)



S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V200R001 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

None.

Table 9-3 describes the default configuration of IPv6 IS-IS.

Table 9-3 Default configuration of IPv6 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
Bandwidth reference value 100 Mbit/s
9.6.1 Configuring Basic IPv6 IS-IS Functions
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
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.
9.6.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 description
Description for the IS-IS process is configured.

Step 4 (Optional) Enable IS-IS to add the POI and hostname TLV to Purge LSPs.
Run:
purge-originator-identification enable [ always ]
IS-IS is enabled to determine whether to add the POI TLV and hostname TLV to Purge LSPs
based on the authentication configuration.
l If the purge-originator-identification enable command is run and the any
authentication is configured, generated Purge LSPs do not carry the POI TLV or
hostname TLV.
l If the purge-originator-identification enable command is run and no authentication is
configured, generated Purge LSPs carry the POI TLV or hostname TLV.
l If the purge-originator-identification enable always command is run, generated Purge
LSPs carry the POI TLV and hostname TLV, regardless of whether authentication is
configured.
----End
9.6.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 ]

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
9.6.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 }
The level of the switch is configured.

By default, the level of the switch is Level-1-2.
----End
9.6.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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. Run:
ipv6 enable

IPv6 is enabled on the interface.

e. Run:
isis ipv6 enable [ process-id ]

After this command is run, IS-IS establishes neighbor relationships and floods LSPs
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.
f. 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.
g. (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.
h. (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.
a. Run:
system-view

b. Run:

undo portswitch


NOTE
modes.
d. Run:
ipv6 enable

e. Run:
isis ipv6 enable [ process-id ]
IS-IS IPv6 is enabled on the interface.

f. Run:

By default, the level of an interface is Level-1-2.
g. 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:
n After a broadcast interface is simulated as a P2P interface using the isis
circuit-type p2p [ strict-snpa-check ] 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.
n 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 packets that IS-IS does not receive from a neighbor before the neighbor
is declared 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.
h. 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.
i. 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.

j. 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
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
9.6.2 Improving IPv6 IS-IS Network Security
Before improving IS-IS network security, complete the following task:
l 9.6.1 Configuring Basic IPv6 IS-IS Functions
9.6.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
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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-
Simple authentication is configured for the IS-IS interface.

l Run:
isis authentication-mode md5 { plain plain-text | [ cipher ] plain-cipher-
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 VLANIF interfaces on which IS-IS is enabled using the
isis ipv6 enable command.
----End
9.6.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
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 ]
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.

l Run:
domain-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 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
9.6.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.
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
9.6.3 Controlling IPv6 IS-IS Route Selection
Before configuring IS-IS route selection, complete the following task:

9.6.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 ]

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
9.6.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 the neighbor relationship is re-
established.
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.
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:

undo portswitch


NOTE
4. 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.
NOTE
You can configure the parameter maximum only when the IS-IS cost style is wide or wide-compatible.
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.
Enable IS-IS interface to automatically calculate the interface cost on IPv6 network.
1. Run:
system-view

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 [ compatible ]
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 9-4.
Table 9-4 Mapping between IS-IS interface costs and interface bandwidth
Cost Bandwidth Range
60 Interface bandwidth ≤ 10 Mbit/s
20 622 Mbit/s < Interface bandwidth ≤ 2.5 Gbit/s
10 2.5 Gbit/s < Interface bandwidth
----End
9.6.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.
Procedure
l Configure equal-cost IS-IS routes to work in load-balancing mode.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. Run:
ipv6 maximum load-balancing number
The maximum number of load-balancing equal-cost IPv6 IS-IS routes is set.
By default, load balancing is supported and a maximum of 8 equal-cost routes can

participate in load balancing.

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 lower preference value (higher preference) are selected
for load balancing.
2. Next hop System ID: If routes have the same priorities, routes with smaller System ID
are selected for load balancing.
3. Interface index: If routes have the same priorities and System ID, routes with lower
interface index values are selected for load balancing.
----End
9.6.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.
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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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 } | direct { allow-filter-policy | allow-
up-down-bit } * ] *
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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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 }| direct allow-filter-policy ] *
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
9.6.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 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
routing information.
----End
9.6.4 Controlling IPv6 IS-IS Route Exchange
Before controlling IS-IS route exchange, complete the following task:
9.6.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
9.6.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 ]

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
9.6.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:
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
9.6.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
IS-IS LSDB information.
[ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ] * command to check IS-IS
l Run the display ipv6 routing-table command to check the IPv6 routing table.
----End
9.6.5 Configuring IPv6 IS-IS Route Summarization
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
9.6.6 Controlling IPv6 IS-IS Route Convergence
Before configuring IS-IS route convergence, complete the following task:
9.6.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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. 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

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.
a. Run:
system-view

b. Run:

undo portswitch


NOTE
modes.
d. 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
9.6.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 be more information in each LSP.
LSPs generated
and LSPs to
be received.
Set the Set the When a switch 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 switches, the lifetime of the LSP is reduced
LSPs LSPs to gradually. If the switch does not receive any more update
ensure the LSPs and the lifetime of the LSP is reduced to 0, the LSP
validity of will be deleted from the LSDB 60s later if no more
an LSP updated LSPs are received.
before its
updated
LSP is
received.


Parameters
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 switch sends an LSP to its neighbors and then the
LSPs to neighbors send the received LSP to their respective
synchronize neighbors except the switch that first sends the LSP. In this
LSDBs. manner, the LSP is flooded among the switches of the
same level. LSP flooding allows each switch 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
minimum interval for up LSP flooding.
interval at sending an
which LSPs LSP during
are sent LSP update.
Configure the Control the On an IS-IS network, if the local routing information
intelligent interval for changes, a switch needs to generate a new LSP to notify
timer used to generating this change. If the local routing information changes
generate LSPs LSPs frequently, a large number of new LSPs are generated,
intelligently which occupies a lot of system resources and decreases
to speed up system performance. To speed up network convergence
route and prevent system performance from being affected,
convergenc configure an intelligent timer for generating LSPs. This
e and timer can adjust the delay in generating LSPs based on the
reduce routing information change frequency.
system
load.
Enable LSP Control the When an IS-IS switch receives new LSPs from other
fast flooding number of switches, it switch updates the LSPs in the local LSDB
LSPs and periodically floods out the updated LSPs according to
flooded a 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
interface to number smaller than the specified number before
speed up calculating routes. This speeds up LSDB synchronization.
IS-IS
network
convergenc
e.


Parameters
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.
are retransmitti The device at one end of the link sends an LSP. If the
retransmitted ng LSPs to device at the other end receives this LSP, it replies with a
over a P2P link ensure PSNP. If the device that has sent an LSP does not receive a
LSDB PSNP from the other end in a period of time, the device
synchroniza will retransmit the LSP.
tion on a
P2P
network.
Procedure
l Set the maximum length for LSPs.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. Set the maximum length for LSPs.
n Run:
lsp-length originate max-size
The maximum length is set for each generated LSP.

n 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.
a. Run:
system-view

b. Run:
isis [ process-id ]


c. 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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. 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.

a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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.
a. Run:
system-view

b. Run:
isis [ process-id ]

c. 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.
a. Run:
system-view

b. Run:

undo portswitch

NOTE
modes.
d. (Optional) Run:
A broadcast interface is simulated as a P2P interface.
NOTE
If the interface type is P2P, the step is not required.

e. 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
9.6.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.
Procedure
Step 1 Run:

system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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
9.6.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:
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-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 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
9.6.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 }
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
----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
9.6.7 Configuring LSP Fragment Extension
Before configuring LSP fragment extension, complete the following task:
l 9.6.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 switch 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 ] ]
9.6.8 Configuring a Mesh Group on an NBMA Network
Before configuring a mesh group, complete the following task:
Procedure
Step 1 Run:

system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 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 ]
9.6.9 Configuring the Overload Bit for an IS-IS Device
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 ]

Step 3 Run:
set-overload [ on-startup [ timeout1 | start-from-nbr system-id [ timeout1
[ timeout2 ] ] | wait-for-bgp [ timeout1 ] ] [ send-sa-bit [ timeout3 ] ] ]
[ 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
9.7.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 ] 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

9.7.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

9.7.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
9.8.1 Example for Configuring Basic IS-IS IPv6 Functions

As shown in Figure 9-2, there are four switches on the IPv6 topology network. The four
switches need to communicate with each other. In addition, SwitchA and SwitchB can only
process less data.

Figure 9-2 Networking diagram of basic IS-IS IPv6 feature
GE0/0/1
VLANIF10
SwitchA FC00:0:0:10::2/64
L1
GE0/0/2
GE0/0/1 SwitchC VLANIF40
VLANIF10 L1/L2 FC00:0:0:25::1/64
FC00:0:0:10::1/64
IS-IS GE0/0/2
GE0/0/1
Area10 VLANIF20 GE0/0/3 VLANIF30 SwitchD
FC00:0:0:20::1/64 VLANIF30 FC00:0:0:30::2/64 L2
FC00:0:0:30::1/64
IS-IS
SwitchB Area20
L1 GE0/0/1
VLANIF20
FC00:0:0:20::2/64
1. Configure IPv6 addresses on interfaces of each switch so that the switches can be
interconnected.
2. Enable IS-IS on each switch so that the switches can be interconnected. Configure
SwitchA and SwitchB as Level-1 switches to enable them to maintain less data.
Procedure
Step 1 Configure VLANs that interfaces belong to.
Step 2 Enable the capability of IPv6 forwarding, and configure IPv6 address for each interface.

[SwitchA] ipv6
Step 3 Configure IS-IS.

[SwitchA] isis 1
[SwitchA-isis-1] ipv6 enable
[SwitchA-Vlanif10] isis ipv6 enable 1
[SwitchB] isis 1
[SwitchB-isis-1] ipv6 enable
[SwitchB-Vlanif20] isis ipv6 enable 1
[SwitchC] isis 1
[SwitchC-isis-1] ipv6 enable
[SwitchC-Vlanif10] isis ipv6 enable 1
[SwitchC-Vlanif30] isis circuit-level level-2
[SwitchD] isis 1
[SwitchD-isis-1] ipv6 enable
[SwitchD-Vlanif30] isis ipv6 enable 1
[SwitchD] interface vlanif40
[SwitchD-Vlanif40] isis ipv6 enable 1

# Display the IS-IS routing table of SwitchA.

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


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

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL
IPV6 Dest. ExitInterface NextHop Cost Flags

-------------------------------------------------------------------------------
::/0 Vlanif10 FE80::244:1FF:FE41:5411 10 A/-/-
FC00:0:0:10::/64
Vlanif10 Direct 10 D/L/-
FC00:0:0:20::/64
Vlanif10 FE80::244:1FF:FE41:5411 20 A/-/-

U-Up/Down Bit Set
# Display the IS-IS neighbors of SwitchC.

[SwitchC] display isis peer verbose

-------------------------------------------------------------------------------
0000.0000.0001 Vlanif10 0000.0000.0001.01 Up 8s L1 64
MT IDs supported : 0(UP)

Local MT IDs : 0
Area Address(es) : 10
Peer IPv6 Address(es): FE80::1234:FCFF:FEFC:199
Uptime : 00:02:08
Adj Protocol : IPV6
Restart Capable : YES
Suppressed Adj : NO
Peer System Id : 0000.0000.0001
0000.0000.0002 Vlanif20 0000.0000.0003.02 Up 24s L1 64

Local MT IDs : 0
Peer IPv6 Address(es): FE80::225:9EFF:FEFB:494A
Uptime : 00:02:09
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0002
0000.0000.0004 Vlanif30 0000.0000.0003.03 Up 27s L2 64

Local MT IDs : 0
Peer IPv6 Address(es): FE80::244:1FF:FE41:5410
Uptime : 00:02:16
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0004
Total Peer(s): 3
# Display the IS-IS LSDB of SwitchC.

[SwitchC] display isis lsdb verbose

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

-------------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000005 0x3cb9 1009 86 0/0/0
SOURCE 0000.0000.0001.00
NLPID IPV6
AREA ADDR 10
INTF ADDR V6 FC00:0:0:10::2
Topology Standard
NBR ID 0000.0000.0001.01 COST: 10
IPV6 FC00:0:0:10::/64 COST: 10
0000.0000.0001.01-00 0x00000001 0xd8f1 1009 55 0/0/0

SOURCE 0000.0000.0001.01
NLPID IPV6
NBR ID 0000.0000.0001.00 COST: 0
NBR ID 0000.0000.0003.00 COST: 0
0000.0000.0002.00-00 0x00000005 0x864b 1007 86 0/0/0

SOURCE 0000.0000.0002.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 0000.0000.0003.02 COST: 10
IPV6 FC00:0:0:20::/64 COST: 10
0000.0000.0003.00-00* 0x00000007 0xcf9b 1012 143 1/0/0

SOURCE 0000.0000.0003.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 0000.0000.0001.01 COST: 10
NBR ID 0000.0000.0003.02 COST: 10
IPV6 FC00:0:0:10::/64 COST: 10
IPV6 FC00:0:0:20::/64 COST: 10
0000.0000.0003.02-00* 0x00000001 0xc9fa 1009 55 0/0/0

SOURCE 0000.0000.0003.02
NLPID IPV6
NBR ID 0000.0000.0003.00 COST: 0
NBR ID 0000.0000.0002.00 COST: 0
Total LSP(s): 5

-------------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000006 0x8ff6 1014 146 0/0/0
SOURCE 0000.0000.0003.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 0000.0000.0003.03 COST: 10
IPV6 FC00:0:0:10::/64 COST: 10
IPV6 FC00:0:0:20::/64 COST: 10

IPV6 FC00:0:0:30::/64 COST: 10
0000.0000.0003.03-00* 0x00000001 0xfac6 1012 55 0/0/0

SOURCE 0000.0000.0003.03
NLPID IPV6
NBR ID 0000.0000.0003.00 COST: 0
NBR ID 0000.0000.0004.00 COST: 0
0000.0000.0004.00-00 0x00000005 0x5943 1009 86 0/0/0

SOURCE 0000.0000.0004.00
NLPID IPV6
AREA ADDR 20
Topology Standard
NBR ID 0000.0000.0003.03 COST: 10
IPV6 FC00:0:0:30::/64 COST: 10
Total LSP(s): 3
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
ipv6 enable topology standard
#
#
interface Vlanif10
ipv6 enable
isis ipv6 enable 1
#
#
return

#
sysname SwitchB
#
ipv6
#
vlan batch 20
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
#
#
interface Vlanif20
ipv6 enable


isis ipv6 enable 1
#
#
return
#
sysname SwitchC
#
ipv6
#
vlan batch 10 20 30
#
isis 1
network-entity 10.0000.0000.0003.00
#
#
#
interface Vlanif10
ipv6 enable
isis ipv6 enable 1
#
interface Vlanif20
ipv6 enable
isis ipv6 enable 1
#
interface Vlanif30
ipv6 enable
isis ipv6 enable 1
isis circuit-level level-2
#
#
#
#
return
#
sysname SwitchD
#
ipv6
#
vlan batch 30 40
#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
#
#
interface Vlanif30
ipv6 enable


isis ipv6 enable 1
#
interface Vlanif40
ipv6 enable
isis ipv6 enable 1
#
#
#
return
9.9 References
Table 9-5 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 Multiple

TCP/IP 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
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)

Configuration Guide - IP Unicast Routing 10 BGP Configuration
10 BGP Configuration
About This Chapter
This chapter describes how to configure the Border Gateway Protocol (BGP). BGP is used
between Autonomous Systems (ASs) to transmit routing information. BGP applies to large
and complex networks.
10.1 Introduction to BGP

10.2 Principles
10.6 Configuring BGP
10.7 Maintaining BGP
10.9 References

10.1 Introduction to BGP
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.
l BGP provides 10.2.8 Route Summarization and 10.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 10.2.10 BFD for BGP, 10.2.11 BGP Tracking, and 10.2.12
BGP GR to improve network reliability.
10.2 Principles
10.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 10-1, BGP is classified into two types according to where it runs: Internal
BGP (IBGP) and External BGP (EBGP).
Figure 10-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.
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 10.2.6 Route Reflector and 10.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.
10.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.
BGP State Machine

As shown in Figure 10-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 10-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
Established
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.
– If the TCP connection is established, the BGP device sends an Open message to the
peer and changes to the OpenSent state.
– If the TCP connection fails to be established, the BGP device moves to the Active
state.
– 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.
– 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.
– If the TCP connection fails to be established, the BGP device stays in the Active
state.

– 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.
– If the received Open message is valid, the BGP device sends a Keepalive message
and changes to the OpenConfirm state.
– 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.
– 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.
– 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.
– If the BGP device receives a Route-refresh message, it does not change its status.
– If the BGP device receives a Notification message, it returns to the Idle state.
– 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.
10.2.3 Interaction Between BGP and an IGP

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.
10.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.
10.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 10-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
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 10-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.
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.
The Community attribute includes self-defined community attributes and well-known
community attributes. Table 10-2 lists well-known community attributes.
Table 10-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

(0xFFFFFF02) received route with the No_Advertise
attribute to any peer.
No_Export 4294967041 A BGP device does not advertise the

(0xFFFFFF01) received route with the No_Export attribute
to devices outside the local AS.
No_Export_Subco 4294967043 A BGP device does not advertise the

nfed (0xFFFFFF03) received 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 10.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
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.
After the bestroute igp-metric-ignore command is run, the IGP metrics are not compared for
routes during route selection.
9. Prefers the route with the shortest Cluster_List.
NOTE
By default, Cluster_List takes precedence over Originator_ID during BGP route selection. To
enable Originator_ID to take precedence over Cluster_List during BGP route selection, run the
bestroute routerid-prior-clusterlist command.
10. Prefers the route advertised by the device with the smallest router ID.
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.
10.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 10-3, the following roles are involved in RR scenarios in an AS.

Figure 10-3 Networking diagram of the RR
Route Reflector Non-Client

IBGP IBGP
Client1
Cluster1 IBGP
IBGP
AS65000
Client2 Client3
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 10-3, 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.
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 10-4 Backup RR
RR1 RR2
IBGP
Cluster
IBGP IBGP IBGP
Client1 Client2 Client3

AS65000
As shown in Figure 10-4, 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
Figure 10-5 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 10-5, 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 10-6 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
As shown in Figure 10-6, 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
10.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 10-7 Networking diagram of a confederation
EBGP EBGP
IBGP IBGP AS65003
AS65001 AS65002 AS100
As shown in Figure 10-7, 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 10-3 compares a route reflector and a confederation in terms of the configuration,
device connection, and applications.
Table 10-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.
10.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.
10.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. Frequent route flapping consumes lots of bandwidths and CPU resources and even
affects normal network operation.
Figure 10-8 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 10-8, 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 reuse 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.
10.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.
Figure 10-9 Networking diagram of BFD for BGP
EBGP
AS100 AS200
RouterA RouterB
As shown in Figure 10-9, 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.
10.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 10-10, 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 10-10 Networking diagram of BGP tracking

RouterA RouterB RouterC
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.
10.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.
10.2.13 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 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 10-11, 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 10-11 Networking diagram of the international gateway
AS1000
AS200
AS65001
AS30
Internet Route
IGW
Router
AS100
AS65002
AS120
l RR
As shown in Figure 10-12, 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.
Figure 10-12 Networking diagram of RRs
AS100
RR1 RR2
IBGP IBGP
Client Client Client Client Client Client

l ASBR
As shown in Figure 10-13, 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 10-13 Networking diagram of a PE connecting to multiple IBGP neighbors
AS200
RouterC
IBGP
AS100 RouterD
RouterA EBGP
RouterB RouterE
IBGP
RouterF
10.2.14 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.
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-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 10-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.
Table 10-4 BGP configuration tasks
Configuring basic BGP The configuration of basic 10.6.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, 10.6.2 Configuring BGP

unauthorized users can Security
attack 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 10.6.3 Simplifying IBGP

connection from the IBGP neighbors Network Connections
will not 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.
Configuring BGP route In a BGP routing table, 10.6.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 10.6.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.
Configuring and adjusting To enable BGP to rapidly 10.6.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 10.6.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.

Configuring BGP route The BGP routing table on a 10.6.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.

Configuring a local BGP The BGP routing table on a 10.6.9 Configuring BGP to
device to send a default medium or large BGP Advertise Default Routes
route to its peer network contains a large to 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 MP-BGP Traditional BGP-4 only 10.6.10 Configuring MP-

manages IPv4 unicast BGP
routing information and
does not support route
transmission between ASs
of other networks such as
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
multicast networks are
called Multicast BGP
(MBGP).

Other network elements are required to support BGP.
License Support
The BGP4/BGP4+ feature is not under license control.
Version Support
Table 10-5 Products and minimum version supporting BGP
Series Product Model Minimum Minimum

Version Required Version Required
Supporting BGP Supporting
BGP4+
S1700 S1720 Not supported Not supported
S2700 S2700SI Not supported (The Not supported (The

S2700SI is S2700SI is
unavailable in unavailable in
V200R001 and later V200R001 and later
versions.) versions.)


BGP4+
S2700EI Not supported (The Not supported (The

S2700EI is S2700EI is
S2710SI Not supported (The Not supported (The

S2720EI Not supported Not supported
S2750EI Not supported Not supported
S3700 S3700SI Not supported (The Not supported (The

S3700EI V100R005 (The Not supported (The

S3700HI V100R006 (The V200R001 (The

S3700HI is S3700HI is
S5700 S5700LI/S5700S-LI Not supported Not supported
S5710-C-LI Not supported (The Not supported (The

S5710-C-LI is S5710-C-LI is
S5710-X-LI Not supported Not supported
S5700SI Not supported (The Not supported (The



BGP4+
S5700EI V100R005 (The V200R001 (The

S5710EI V200R001 (The V200R001 (The

S5720EI V200R007 V200R007
S5720SI/S5720S-SI V200R008 V200R008
S5700HI V100R006 (The V200R001 (The

S5710HI V200R003 (The V200R003 (The

S5720HI V200R006 V200R006
S6700 S6700EI V100R006 (The V200R001 (The

S6720EI V200R008 V200R008
S6720S-EI V200R009 V200R009

None.

Table 10-6 describes the default configuration of BGP.

Table 10-6 Default configuration of BGP

BGP Disabled
Keepalive message interval 60s
Hold time 180s
10.6 Configuring BGP
10.6.1 Configuring Basic BGP Functions
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.
10.6.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

NOTE
By default, BGP automatically selects the router ID in the system view. If the IP address of a physical
interface is used as the router ID, route flapping occurs when the IP address of the physical interface
changes. To enhance network stability, configuring the address of a loopback interface as the router ID is
recommended. For Router ID selection rules in the system view, see descriptions in Command
Reference about the router-id command.
----End
10.6.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
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 10.6.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.

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
10.6.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 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:

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 10.6.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, the outbound interface of a BGP packet serves as the source interface of a BGP
packet.
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
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
10.6.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
a. Run:
system-view

b. Run:

c. Enter the corresponding address family view based on network type to configure
BGP devices on networks.
n Run:
ipv4-family { unicast | multicast }
The IPv4 address family view is displayed.

n Run:

d. Run:
import-route protocol [ process-id ] [ med med | route-policy route-
policy-name ] *
BGP is configured to import routes of other routing protocols.

e. (Optional) Run:
default-route imported
BGP is allowed to import default routes from the local IP routing table.
To import default routes, you need to run both the default-route imported
command and the import-route (BGP) command. If only the import-route (BGP)
command is used, default routes cannot be imported. In addition, the default-route
imported command is used to import only the default routes that exist in the local
routing table.
By default, BGP does not add default routes to BGP routing tables.
l In network mode
a. Run:
system-view

b. Run:

n Run:

n Run:


d. 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.
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 } [ longer-
prefixes ] ] ] 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
10.6.2 Configuring BGP 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.

10.6.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 you select cipher to save the password in cipher text. MD5 authentication
has potential security risks.
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
10.6.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 S2750&S5700&S6720 Configuration Guide - Security
Configuration.
Procedure
Step 1 Run:
system-view
Step 2 Run:
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. SHA256 and HMAC-
SHA256 encryption algorithm are recommended in keychain authentication.
l BGP MD5 authentication and BGP keychain authentication are mutually exclusive, and only one of
them can be configured for a BGP peer.
l Only the S5720EI, S5720HI and S6720EI support keychain keychain-name.
----End
10.6.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:

The default action to be taken on the packets that do not match a GTSM policy is set.
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
10.6.3 Simplifying IBGP Network Connections
Before simplifying IBGP network connections, complete the following configuration task:

Perform the following configuration tasks in any sequence as required.
10.6.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.
Within an AS, an RR transmits routing information and forwards traffic. When an RR

connects to a large number of clients and non-clients, many CPU resources are consumed if
the RR transmits routing information and forwards traffic simultaneously. This also reduces
route transmission efficiency. To improve route transmission efficiency, prohibit BGP from
adding preferred routes to IP routing tables on the RR to enable the RR only to transmit
Procedure
Step 1 Run:
system-view
Step 2 Run:
The BGP is abled and the bpg view is displayed.
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 { group-name | ipv4-address | ipv6-address } reflect-client
An RR and its client are configured.
By default, the route reflector and its client are not 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.
routing-table 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

prefixes ] ] ] command to check routing information in a BGP routing table.
10.6.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:
The BGP is abled and the bgp view is displayed.

Step 3 Run:
confederation id { as-number-plain | as-number-dot }
A confederation ID is configured.
By default, no BGP confederation 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.

By default, no sub-AS number of the confederation is configured.
confederation nonstandard
Confederation compatibility is configured.

By default, confederations comply with RFC 3065.
----End

l Run the display bgp peer [ ipv4-address ] verbose command to check detailed
information about BGP peers.
10.6.4 Configuring BGP Route Selection and Load Balancing
Before configuring BGP route attributes, complete the following task:
l Configure Basic BGP Functions.
Perform the following configuration tasks as required. The following configuration tasks
(excluding the task of checking the configuration) can be performed in any sequence. For
detailed route selection rules, see 10.2.5 BGP Route Selection Rules and Load Balancing.
10.6.4.1 Configuring the BGP Priority

Context
The routing protocols may share and select routing information because switches 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:
Step 4 Run:
preference { external internal local | route-policy route-policy-name }Or
preference external internal local route-policy route-policy-name
The BGP priority is set.
The default BGP priority is 255.
The smaller the preference value, the higher the preference.
BGP has the following types of routes:
l EBGP routes learned from peers in other ASs

l IBGP routes learned from peers in the same AS
l Locally originated routes (A locally originated route is a route summarized by using the
summary automatic command or the aggregate command.)
Different preference values can be set for these three types of routes.
In addition, a routing policy can also be used to set the preferences for the routes that match
the policy. The routes that do not match the policy use the default preference.
NOTE
You cannot use the peer route-policy command on BGP peers to apply routing policies to set the BGP
priority.
----End

10.6.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:
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
10.6.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.
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

10.6.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.

By default, the Local_Pref attribute is 100.
----End
10.6.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.
By default, all routes meet matching rules. For details, see 11.6.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.

By default, repeated local AS number is not allowed.
l Run:
peer { ipv4-address | group-name | ipv6-address } public-as-only [ force ]
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.
a. Run:
quit
Return to the BGP view.

b. (Optional) Run one of the following commands to configure the AS_Path attribute
as required.
n 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.

n Run:
peer { ipv4-address | group-name | ipv6-address } fake-as [ prepend-
global-as ]
The peer fake-as command can be used to hide the actual AS number of a
BGP device. EBGP peers in other ASs will use the fake AS number of this
BGP device to set up EBGP peer relationships with this device.
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.
n 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
10.6.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 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.

By default, BGP compares only the MEDs of the routes from the same AS.
----End
10.6.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 11.6.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:

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 To advertise an extended community attribute to a specified peer or peer group, perform
the following steps:
a. Run the peer { ipv4-address | group-name | ipv6-address } advertise-ext-
community command to advertise an extended community attribute to a specified
peer or peer group.
b. Run the ext-community-change enable command to enable the device to change
extended community attributes using a routing policy.
By default, BGP peers cannot change extended community attributes using a route-
policy; specifically, BGP peers advertise only the extended community attributes
carried in routes to a specified peer or peer group, and the peer route-policy
command cannot be used to modify the extended community attributes.
----End
10.6.4.8 Configuring BGP Load Balancing
Context
On a large network, there may be multiple valid BGP routes to the same destination. A switch
will select and add the optimal BGP route to its routing table for traffic forwarding and
advertises this route to its peers. This, however, will result in uneven load balancing of many
traffic. Configuring BGP load balancing can enable the switch to add these multiple equal-
cost BGP routes to its routing table, implementing traffic load balancing and reducing
network congestion. After BGP load balancing is configured, the switch will still select the
optimal route among the multiple routes and advertise only this route to its peers.
Equal-cost BGP routes can only be generated for traffic load balancing when the first eight
route attributes described in "BGP Route Selection Policies" are the same. Change load

balancing rules by adjusting some configurations, for example, ignoring the comparison of the
AS_Path attribute. When adjusting 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 [ ecmp-nexthop-changed ]
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 implemented.
NOTE
l On a public network, if the routes to the same destination implement load balancing, the system will
determine the optimal route type. 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 BGP AS_Path
information.
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
10.6.5 Controlling the Receiving and Advertisement of BGP

Routes
Before controlling the receiving and advertisement of BGP routes, complete the following
task:

Figure 10-14 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
10.6.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 "11 Routing Policy
Configuration" in the S2750&S5700&S6720 Series Ethernet Switches Configuration Guide -
IP Routing.
10.6.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.
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.
a. Run:
system-view

b. Run:


n Run:

n Run:

d. Perform either of the following operations to configure the BGP device to advertise
routes to all peers or peer groups:
n 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.
n 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.
a. Run:
system-view

b. Run:

n Run:

n Run:

d. Perform any of the following operations to configure the BGP device to advertise
routes to a specific peer or peer group:
n 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.
n 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 | ipv4-
address | ipv6-address } ipv6-prefix ipv6-prefix-name export command.

n 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.
n 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
10.6.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.
a. Run:
system-view

b. Run:

n Run:

n Run:

d. Perform either of the following operations to configure the BGP device to filter the
routes received from all its peers or peer groups:
n 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.
n 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.
a. Run:
system-view

b. Run:

n Run:

n Run:

d. Perform any of the following operations to configure the BGP device to filter the
routes received from a specific peer or peer group:
n 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.
n 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 | ipv4-
address | ipv6-address } ipv6-prefix ipv6-prefix-name import command.
n 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.
n To filter routes based on a route-policy, run the peer { ipv4-address | group-
name | ipv6-address } route-policy route-policy-name import command.
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.
e. (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
10.6.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.
a. Run:
system-view

b. Run:

c. (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.
d. Run:
quit

e. Run:
quit
Return to the user view.

f. 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 | ipv4-address | 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.

a. Run:
system-view

b. Run:

n Run:

n 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.
d. 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
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-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
10.6.6 Adjusting the BGP Network Convergence Speed
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.
10.6.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.
a. Run:
system-view

b. Run:

c. 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.
a. Run:
system-view

b. Run:

c. 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
10.6.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 switches.
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.
a. Run:
system-view

b. Run:

c. Run:
timer keepalive keepalive-time hold hold-time [ min-holdtime min-
holdtime ]
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.
a. Run:
system-view

b. Run:

c. Run:
peer { ipv4-address | group-name | ipv6-address } timer keepalive
keepalive-time hold hold-time [ min-holdtime min-holdtime ]
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
10.6.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:

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
10.6.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.
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
10.6.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 10-15, 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 10-15 Networking diagram for configuring the BGP next hop delayed response
CE1 PE3 P PE1
CE2
RR PE2
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 Set a delay in responding to next hop changes.
The iteration results are as follows:

l Urgent iteration result change: The iterated next hop is changed, and BGP route
reachability is also changed. For example, if a fault occurs on a network, a device finds
no next-hop route or tunnel to which a BGP route is iterated. As a result, traffic is
interrupted.

l Non-urgent iteration result change: The iterated next hop is changed, and BGP route
reachability is not affected. For example, after the interface or type of a tunnel to which
the next hop of a BGP route is iterated is changed, traffic keeps traveling over the BGP
route.
Run either of the following commands to set a delay time after which a device responds to a
BGP next hop change:
l To enable a device to delay responses to all next hop changes, run:
nexthop recursive-lookup delay [ delay-time ]
l To enable a device to delay responses to non-urgent next hop changes, run:

nexthop recursive-lookup non-critical-event delay [ delay-time ]
If delay-time is not specified, the default delay time of 5s takes effect.

The preceding commands can be run separately or simultaneously. The nexthop recursive-
lookup non-critical-event delay command takes precedence over the nexthop recursive-
lookup delay command if both commands are run.
The delay time specified in the nexthop recursive-lookup non-critical-event delay
command must be greater than or equal to that specified in the nexthop recursive-lookup
delay command if both commands are run.
----End
10.6.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:

on networks.
l Run:
ipv4-family { unicast | multicast | vpnv4 [ unicast ] | vpn-instance vpn-
instance-name }


l Run:
ipv6-family [ unicast | vpn-instance vpn-instance-name ]

Step 4 Run:
dampening [ ibgp ] [ half-life-reach reuse suppress ceiling | route-policy route-
policy-name ] *
BGP route dampening parameters are configured.
NOTE
The dampening command is valid only for EBGP routes.
----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 regular-expression as-regular-
expression
----End
10.6.7 Configuring BGP Reliability
Before configuring BGP reliability, complete the following task:

tasks can be performed at any sequence.
10.6.7.1 Enabling BGP Tracking
Context
BFD 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
10.6.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 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.
NOTE
Only the S5720EI, S5720HI and S6720EI BFD for BGP.
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 [ single-hop-prefer ]
BFD is configured for the peer or peer group, and default BFD parameters are used to
establish BFD sessions.
single-hop-prefer takes effect only on IBGP peers. By default, if single-hop-prefer is not
specified, multi-hop sessions are established between direct IBGP peers (Huawei devices). To
interconnect a Huawei device and a non-Huawei device that defaults the sessions between
IBGP peers to single-hop, configure single-hop-prefer in the command.
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 } *
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.

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.
10.6.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.

By default, the time for waiting for End-of-RIB messages is 600 seconds.
graceful-restart peer-reset
The device is enabled to reset a BGP session in GR mode.

By default, a device is not enabled to reset a BGP connection in GR mode.
----End

l Run the display bgp peer verbose command to check detailed information about BGP
GR.
10.6.8 Configuring BGP Route Summarization
Before configuring BGP route summarization, complete the following task:
Procedure
l Configure automatic route summarization.
a. Run:
system-view

b. Run:

n Run:

d. 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.
a. Run:
system-view

b. Run:

n Run:

n Run:

d. Perform any of the following operations to configure manual route summarization.
n To advertise the summarized routes and specific routes, run the aggregate
ipv4-address { mask | mask-length } command.
n 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.
n 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.
n 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.
n 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.
n 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.
10.6.9 Configuring BGP to Advertise Default Routes to Peers

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:

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.
----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.
prefixes ] | mask [ longer-prefixes ] ] ] command to check received MBGP default
routes.

10.6.10 Configuring MP-BGP
Before configuring MP-BGP, complete the following task:
l 10.6.1.1 Starting a BGP Process
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

l Run:
ipv6-family vpnv6
The BGP-VPNv6 address family view is displayed.

l Run:
ipv6-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv6 address family view is displayed.

NOTE
l Only the S6720EI supports BGP-VPNv4 address family view and BGP-VPNv6 address family view.
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 Switch 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, 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
10.7 Maintaining BGP
10.7.1 Configuring Alarm and Clear Alarm Thresholds for the

Number of BGP Routes
Context
The number of BGP routes that can be added to a routing table is limited. If the number
exceeds a limit, new routes cannot be added to the routing table, which may interrupt services.
To address this problem, configure alarm and clear alarm thresholds for the number of BGP
routes. With the alarm and clear alarm thresholds, alarms are generated and cleared as
expected. The alarms prompt you to check whether an exception occurs and to take preventive
measures. You can configure the alarm and clear alarm thresholds as required.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
routing-table limit threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value
Alarm and clear alarm thresholds are configured for the number of BGP routes.
l upper-limit-value specifies the alarm threshold. If the ratio of BGP routes to the
maximum number that is allowed exceeds the alarm threshold, an alarm is generated.
l lower-limit-value specifies the clear alarm threshold. If the ratio of BGP routes to the
maximum number that is allowed falls below this threshold, the alarm is cleared.

l upper-limit-value must be greater than lower-limit-value; otherwise, alarms are generated

and cleared repeatedly if route flapping occurs.
By default, upper-limit-value is 80%, and lower-limit-value is 70%.
----End
10.7.2 Resetting BGP Connections
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 switch 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
10.7.3 Clearing BGP Statistics

Context
NOTICE
BGP statistics cannot be restored after being cleared. Exercise caution when you reset BGP
statistics.
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
10.8.1 Example for Configuring Basic BGP Functions

As shown in Figure 10-16, BGP runs between Switches; an EBGP connection is established
between SwitchA and SwitchB; IBGP full-mesh connections are established between
SwitchB, SwitchC, and SwitchD.
Figure 10-16 Networking diagram for configuring basic BGP functions

SwitchC
GE0/0/1
VLANIF20
172.16.3.2/24
GE0/0/2 GE0/0/2
VLANIF50 VLANIF20 GE0/0/2
GE0/0/1 172.16.3.1/24
10.1.1.1/16 VLANIF10 VLANIF40
192.168.1.1/24 172.16.2.1/24
AS65009
GE0/0/1 SwitchB GE0/0/3 GE0/0/2
SwitchAVLANIF10 VLANIF40
192.168.1.2/24 VLANIF30 172.16.2.2/24
172.16.1.1/24
AS65008 GE0/0/1
VLANIF30
172.16.1.2/24 SwitchD

1. Configure IBGP connections between SwitchB, SwitchC, and SwitchD.
2. Configure an EBGP connection between SwitchA and SwitchB.
Procedure
Step 1 Create VLANs and add interfaces to the corresponding VLANs.
# Configure SwitchA. Ensure that the configurations of SwitchB,SwitchC, and SwitchD are

Step 3 Configure IBGP connections.

[SwitchB] bgp 65009
[SwitchB-bgp] router-id 172.17.2.2
[SwitchB-bgp] quit
[SwitchC] bgp 65009
[SwitchC-bgp] router-id 172.17.3.3
[SwitchC-bgp] quit
[SwitchD] bgp 65009
[SwitchD-bgp] router-id 172.17.4.4
[SwitchD-bgp] quit

Step 4 Configure EBGP connections.

[SwitchA] bgp 65008
[SwitchA-bgp] router-id 172.17.1.1
[SwitchA-bgp] quit
[SwitchB] bgp 65009
[SwitchB-bgp] quit
# Check the status of BGP connections.

[SwitchB] display bgp peer
BGP local router ID : 172.17.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
172.16.1.2 4 65009 49 62 0 00:44:58 Established 0

172.16.3.2 4 65009 56 56 0 00:40:54 Established 0
192.168.1.2 4 65008 49 65 0 00:44:03 Established 0
You can view that the BGP connections between SwitchB and all the other Switches are set
up.
Step 5 Configure SwitchA to advertise route 10.1.0.0/16.
# Configure SwitchA to advertise routes.
[SwitchA] bgp 65008
[SwitchA-bgp] ipv4-family unicast
[SwitchA-bgp-af-ipv4] network 10.1.0.0 255.255.0.0
[SwitchA-bgp-af-ipv4] quit
[SwitchA-bgp] quit

[SwitchA] display bgp routing-table
BGP Local router ID is 172.17.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
*> 10.1.0.0/16 0.0.0.0 0 0 i

[SwitchB] display bgp routing-table



*> 10.1.0.0/16 192.168.1.2 0 0 65008i
# Check the routing table of SwitchC.

[SwitchC] display bgp routing-table


i 10.1.0.0/16 192.168.1.2 0 100 0 65008i
According to the routing table, you can view that SwitchC has learned the route to the
destination 10.1.0.0 in AS 65008, but the next hop 192.168.1.2 is unreachable. Therefore, this
route is invalid.
Step 6 Configure BGP to import direct routes.
[SwitchB] bgp 65009
[SwitchB-bgp] ipv4-family unicast
[SwitchB-bgp-af-ipv4] import-route direct
[SwitchB-bgp-af-ipv4] quit
[SwitchB-bgp] quit
# Check the BGP routing table of SwitchA.



*> 10.1.0.0/16 0.0.0.0 0 0 i

*> 172.16.1.0/24 192.168.1.1 0 0 65009?
*> 172.16.3.0/24 192.168.1.1 0 0 65009?
192.168.1.0 192.168.1.1 0 0 65009?



*>i 10.1.0.0/16 192.168.1.2 0 100 0 65008i

*>i 172.16.1.0/24 172.16.3.1 0 100 0 ?
i 172.16.3.0/24 172.16.3.1 0 100 0 ?
*>i 192.168.1.0 172.16.3.1 0 100 0 ?
You can view that the route destined for 10.1.0.0 becomes valid, and the next hop is the
address of SwitchA.

# Perform the ping operation to verify the configuration.

[SwitchC] ping 10.1.1.1

0.00% packet loss
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 50
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif50
ip address 10.1.1.1 255.255.0.0
#
#
#
bgp 65008
peer 192.168.1.1 as-number 65009
#
ipv4-family unicast
network 10.1.0.0 255.255.0.0
#
return

#
sysname SwitchB
#
vlan batch 10 20 30
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Vlanif20
ip address 172.16.3.1 255.255.255.0
#
interface Vlanif30
ip address 172.16.1.1 255.255.255.0
#


#
#
#
bgp 65009
peer 172.16.1.2 as-number 65009
peer 172.16.3.2 as-number 65009
peer 192.168.1.2 as-number 65008
#
ipv4-family unicast
import-route direct
#
return
#
sysname SwitchC
#
vlan batch 20 40
#
interface Vlanif20
ip address 172.16.3.2 255.255.255.0
#
interface Vlanif40
ip address 172.16.2.1 255.255.255.0
#
#
#
bgp 65009
peer 172.16.2.2 as-number 65009
peer 172.16.3.1 as-number 65009
#
ipv4-family unicast
#
return
#
sysname SwitchD
#
vlan batch 30 40
#
interface Vlanif30
ip address 172.16.1.2 255.255.255.0
#
interface Vlanif40
ip address 172.16.2.2 255.255.255.0
#


#
#
bgp 65009
peer 172.16.1.1 as-number 65009
peer 172.16.2.1 as-number 65009
#
ipv4-family unicast
#
return
10.8.2 Example for Configuring Basic BGP4+ Functions
As shown in Figure 10-17, there are two ASs: 65008 and 65009. SwitchA belongs to AS
65008, and SwitchB, SwitchC, and SwitchD belong to AS 65009. Routing Protocol is
required to exchange the routing information between the two ASs.
Figure 10-17 Networking diagram for configuring basic BGP4+ functions
SwitchC
FC
GE IF5 1/6
VL :0:9
00
AN 2::
0/0 0
/64
:0
/2
IF30
93::2
VLAN 0/3
/
GE0
:0:0:
AS 65008
4
AS 65009
/64
FC00
IF30
93::1
VLAN 0/3
FC
GE IF5 2/6
/
VL :0:9
GE0
00
:0:0:
GE0/0/1
AN 2::
0/0 0
:0
VLANIF10
/2
FC00
FC00:0:0:8::1/64 GE0/0/2 GE0/0/1

VLANIF20 VLANIF40
FC00:0:0:100::1/64 FC00:0:0:91::1/64
4
GE0/0/2 GE0/0/1
SwitchAVLANIF20 SwitchB VLANIF40 SwitchD
FC00:0:0:100::2/64 FC00:0:0:91::2/64
1. Configure IBGP connections between SwitchB, SwitchC, and SwitchD.

2. Configure an EBGP connection between SwitchA and SwitchB.
Procedure
Step 2 Enable the IPv6 forwarding capability, and assign an IPv6 address for each interface.
[SwitchA] ipv6
Step 3 Configure IBGP.

[SwitchB] bgp 65009
[SwitchB-bgp] peer fc00:0:0:91::2 as-number 65009
[SwitchB-bgp-af-ipv6] peer fc00:0:0:91::2 enable
[SwitchB-bgp-af-ipv6] network fc00:0:0:91:: 64
[SwitchB-bgp] quit
[SwitchC] bgp 65009
[SwitchC-bgp] peer fc00:0:0:93::1 as-number 65009
[SwitchC-bgp] peer fc00:0:0:92::2 as-number 65009
[SwitchC-bgp] ipv6-family unicast
[SwitchC-bgp-af-ipv6] peer fc00:0:0:93::1 enable
[SwitchC-bgp-af-ipv6] peer fc00:0:0:92::2 enable
[SwitchC-bgp-af-ipv6] network fc00:0:0:93:: 64
[SwitchC-bgp-af-ipv6] network fc00:0:0:92:: 64
[SwitchC-bgp-af-ipv6] quit
[SwitchC-bgp] quit

[SwitchD] bgp 65009

[SwitchD-bgp] peer fc00:0:0:91::1 as-number 65009
[SwitchD-bgp] peer fc00:0:0:92::1 as-number 65009
[SwitchD-bgp] ipv6-family unicast
[SwitchD-bgp-af-ipv6] peer fc00:0:0:91::1 enable
[SwitchD-bgp-af-ipv6] peer fc00:0:0:92::1 enable
[SwitchD-bgp-af-ipv6] network fc00:0:0:92:: 64
[SwitchD-bgp-af-ipv6] network fc00:0:0:91:: 64
[SwitchD-bgp-af-ipv6] quit
[SwitchD-bgp] quit
Step 4 Configure the EBGP connection.
[SwitchA] bgp 65008
[SwitchA-bgp] peer fc00:0:0:100::1 as-number 65009
[SwitchA-bgp-af-ipv6] peer fc00:0:0:100::1 enable
[SwitchA-bgp-af-ipv6] network fc00:0:0:100:: 64
[SwitchA-bgp-af-ipv6] network fc00:0:0:8:: 64
[SwitchA-bgp] quit
[SwitchB] bgp 65009
[SwitchB-bgp] quit
# View the status of the BGP4+ peers.

[SwitchB] display bgp ipv6 peer

FC00:0:0:91::2 4 65009 8 9 0 00:05:37 Established 2

FC00:0:0:93::2 4 65009 2 2 0 00:00:09 Established 2
FC00:0:0:100::2 4 65008 9 7 0 00:05:38 Established 1
The preceding information shows that the BGP4+ connections between SwitchB and other
Switches are set up.
# Display the routing table of SwitchA.

[SwitchA] display bgp ipv6 routing-table


*> Network : FC00:0:0:91:: PrefixLen : 64
NextHop : FC00:0:0:100::1 LocPrf :
MED : 0 PrefVal : 0
Label :
Path/Ogn : 65009 i


MED : PrefVal : 0
Label :
Path/Ogn : 65009 i
MED : 0 PrefVal : 0
Label :
Path/Ogn : 65009 i
NextHop : :: LocPrf :
MED : 0 PrefVal : 0
Label :
Path/Ogn : i

MED : 0 PrefVal : 0
Label :
Path/Ogn : 65009 i
The routing table shows that SwitchA has learned the route from AS 65009. AS 65008 and
AS 65009 can exchange their routing information.
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10 20
#
interface Vlanif10
ipv6 enable
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:100::2/64
#
#
#
bgp 65008
router-id 10.1.1.1
peer FC00:0:0:100::1 as-number 65009
#
ipv4-family unicast
#
ipv6-family unicast
network FC00:0:0:8:: 64
network FC00:0:0:100:: 64
peer FC00:0:0:100::1 enable
#
return

#
sysname SwitchB
#
ipv6
#
vlan batch 20 30 40
#
interface Vlanif20
ipv6 enable
ipv6 address FC00:0:0:100::1/64
#
interface Vlanif30
ipv6 enable
#
interface Vlanif40
ipv6 enable
#
#
#
#
bgp 65009
router-id 10.2.2.2
peer FC00:0:0:91::2 as-number 65009
peer FC00:0:0:100::2 as-number 65008
#
ipv4-family unicast
#
ipv6-family unicast
network FC00:0:0:91:: 64
network FC00:0:0:93:: 64
network FC00:0:0:100:: 64
#
return
#
sysname SwitchC
#
ipv6
#
vlan batch 30 50
#
interface Vlanif30
ipv6 enable
#
interface Vlanif50
ipv6 enable
#

#
#
bgp 65009
router-id 10.3.3.3
#
ipv4-family unicast
#
ipv6-family unicast
network FC00:0:0:92:: 64
network FC00:0:0:93:: 64
#
return

#
sysname SwitchD
#
ipv6
#
vlan batch 40 50
#
interface Vlanif40
ipv6 enable
#
interface Vlanif50
ipv6 enable
#
#
#
bgp 65009
router-id 10.4.4.4
#
ipv4-family unicast
#
ipv6-family unicast
network FC00:0:0:91:: 64
network FC00:0:0:92:: 64
#
return
10.8.3 Example for Configuring Basic MBGP Functions

As shown in Figure 10-18, 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.
Figure 10-18 Networking diagram of MBGP configuration
AS100 AS200
SwitchD
Loopback0
Source SwitchA SwitchB
Loopback0 Loopback0
SwitchC Loopback0
Receiver
MBGP peers
Interface and IP Address Interface and IP Address
GE0/0/2 GE0/0/1
VLANIF101 VLANIF100 GE0/0/2
GE0/0/1
10.10.10.1/24 192.168.1.1/24 VLANIF200
VLANIF100
192.168.4.2/24
192.168.1.2/24
SwitchA GE0/0/3
SwitchB VLANIF300
Loopback0 192.168.3.2/24
10.1.1.1/32
Loopback0
10.2.2.2/32

Loopback0
10.4.4.4/32
SwitchD
GE0/0/1
GE0/0/3
VLANIF400 GE0/0/2
VLANIF300
192.168.5.1/24 VLANIF200
192.168.3.1/24
192.168.4.1/24 GE0/0/1
SwitchC
VLANIF400
GE0/0/2 Loopback0 192.168.5.2/24
VLANIF102 10.3.3.3/32
10.22.22.1/24
1. Configure MBGP peers for inter-AS multicast transmission.
2. Configure the routes advertised by MBGP.
3. Enable the multicast function on each switch.
4. Configure basic PIM-SM functions on each switch 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.
Procedure
Step 1 Configure the IP addresses for the interfaces on each Switch and the OSPF protocol in the
ASs.
# Configure IP addresses and masks for the interfaces on each switch according to Figure
10-18 and configure OSPF on the switches in ASs. Ensure that Switch B, Switch C, Switch 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 the MBGP peers.
# Configure BGP and the MBGP peer on SwitchA.
[SwitchA] bgp 100
[SwitchA-bgp] ipv4-family multicast
[SwitchA-bgp-af-multicast] peer 192.168.1.2 enable
[SwitchA-bgp-af-multicast] quit
[SwitchA-bgp] quit
# Configure BGP and the MBGP peer on SwitchB.

[SwitchB] bgp 200
[SwitchB-bgp] ipv4-family multicast
[SwitchB-bgp-af-multicast] peer 192.168.1.1 enable

[SwitchB-bgp-af-multicast] quit
[SwitchB-bgp] quit
# Configure BGP and the MBGP peer on SwitchC.

[SwitchC] bgp 200
[SwitchC-bgp] ipv4-family multicast
[SwitchC-bgp-af-multicast] peer 192.168.3.2 enable
[SwitchC-bgp-af-multicast] peer 192.168.5.2 enable
[SwitchC-bgp-af-multicast] quit
[SwitchC-bgp] quit
# Configure BGP and the MBGP peer on SwitchD.

[SwitchD] bgp 200
[SwitchD-bgp] ipv4-family multicast
[SwitchD-bgp-af-multicast] peer 192.168.4.2 enable
[SwitchD-bgp-af-multicast] peer 192.168.5.1 enable
[SwitchD-bgp-af-multicast] quit
[SwitchD-bgp] quit
Step 3 Configure the routes to be advertised.
# Configure the routes to be advertised on SwitchA.

[SwitchA] bgp 100
[SwitchA-bgp] import-route direct
[SwitchA-bgp] ipv4-family multicast
[SwitchA-bgp-af-multicast] import-route direct
[SwitchA-bgp-af-multicast] quit
[SwitchA-bgp] quit
# Configure the routes to be advertised on SwitchB.

[SwitchB] bgp 200
[SwitchB-bgp] import-route direct
[SwitchB-bgp] import-route ospf 1
[SwitchB-bgp] ipv4-family multicast
[SwitchB-bgp-af-multicast] import-route direct
[SwitchB-bgp-af-multicast] import-route ospf 1
[SwitchB-bgp-af-multicast] quit
[SwitchB-bgp] quit
Step 4 Enable multicast on each Switch and the interfaces that are connected.
[SwitchA] multicast routing-enable
[SwitchA-Vlanif100] pim sm
[SwitchA-Vlanif101] pim sm
[SwitchB] multicast routing-enable
[SwitchB-Vlanif100] pim sm

[SwitchC] multicast routing-enable
[SwitchC-Vlanif400] pim sm
[SwitchC-Vlanif102] igmp enable
[SwitchD] multicast routing-enable
[SwitchD-Vlanif400] pim sm
[SwitchD-Vlanif200] pim sm
Step 5 Configure BSR and RP within each AS.
[SwitchA] interface LoopBack 0
[SwitchA-LoopBack0] ip address 10.1.1.1 255.255.255.255
[SwitchA-LoopBack0] pim sm
[SwitchA-LoopBack0] quit
[SwitchA] pim
[SwitchA-pim] c-bsr LoopBack 0
[SwitchA-pim] c-rp LoopBack 0
[SwitchA-pim] quit
[SwitchB] interface LoopBack 0
[SwitchB-LoopBack0] ip address 10.2.2.2 255.255.255.255
[SwitchB-LoopBack0] pim sm
[SwitchB-LoopBack0] quit
[SwitchB] pim
[SwitchB-pim] c-bsr LoopBack 0
[SwitchB-pim] c-rp LoopBack 0
[SwitchB-pim] quit
Step 6 Configure the BSR boundary on the interfaces connecting two ASs.
[SwitchA-Vlanif100] pim bsr-boundary
[SwitchB-Vlanif100] pim bsr-boundary
Step 7 Configure MSDP peers.

[SwitchA] msdp
[SwitchA-msdp] peer 192.168.1.2 connect-interface Vlanif100
[SwitchA-msdp] quit
[SwitchB] msdp
[SwitchB-msdp] peer 192.168.1.1 connect-interface Vlanif100
[SwitchB-msdp] quit

# Run the display bgp multicast peer command to view the MBGP peer relationship
between switches. For example, the following information shows the MBGP peer relationship
on SwitchA:
[SwitchA] display bgp multicast peer
192.168.1.2 4 200 82 75 0 00:30:29 Established 17
# Run the display msdp brief command to view information about the MSDP peer
relationship between switches. For example, the following information shows the MBGP peer
relationship on SwitchB:
[SwitchB] display msdp brief
MSDP Peer Brief Information
Configured Up Listen Connect Shutdown Down
1 1 0 0 0 0
Peer's Address State Up/Down time AS SA Count Reset Count

192.168.1.1 Up 00:07:17 100 1 0
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100 to 101
#
multicast routing-enable
#
interface Vlanif100
ip address 192.168.1.1 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif101
ip address 10.10.10.1 255.255.255.0
pim sm
#
#
#
interface LoopBack0
ip address 10.1.1.1 255.255.255.255
pim sm

#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
bgp 100
#
ipv4-family unicast
import-route direct
#
#
msdp
peer 192.168.1.2 connect-interface Vlanif100
#
return
#
sysname SwitchB
#
vlan batch 100 200 300
#
#
interface Vlanif100
ip address 192.168.1.2 255.255.255.0
pim bsr-boundary
pim sm
#
interface Vlanif200
ip address 192.168.4.2 255.255.255.0
pim sm
#
interface Vlanif300
ip address 192.168.3.2 255.255.255.0
pim sm
#
#
#
#
interface LoopBack0
ip address 10.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.2.2 0.0.0.0
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
bgp 200


#
ipv4-family unicast
import-route direct
import-route ospf 1
#
import-route direct
import-route ospf 1
#
msdp
peer 192.168.1.1 connect-interface Vlanif100
#
return
#
sysname SwitchC
#
#
#
interface Vlanif102
ip address 10.22.22.1 255.255.255.0
pim sm
igmp enable
#
interface Vlanif300
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface Vlanif400
ip address 192.168.5.1 255.255.255.0
pim sm
#
#
#
#
interface LoopBack0
ip address 10.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.3.3.3 0.0.0.0
network 10.22.22.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
bgp 200


#
ipv4-family unicast
#
#
return

#
sysname SwitchD
#
vlan batch 200 400
#
#
interface Vlanif200
ip address 192.168.4.1 255.255.255.0
pim sm
#
interface Vlanif400
ip address 192.168.5.2 255.255.255.0
pim sm
#
#
#
interface LoopBack0
ip address 10.4.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.4.4.4 0.0.0.0
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
bgp 200
#
ipv4-family unicast
#
#
return

10.8.4 Example for Configuring BGP to Interact With an IGP

The network shown in Figure 10-19 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 10-19 Networking diagram for configuring BGP to interact with an IGP
GE0/0/2 GE0/0/2
10.8.1.1/24 VLANIF10 VLANIF20 10.9.2.1/24
10.3.1.1/24 10.9.1.2/24
GE0/0/1 GE0/0/2
Switch A VLANIF10 Switch B VLANIF20 Switch C
10.3.1.2/24 10.9.1.1/24
AS65008 AS65009
1. Configure OSPF on SwitchB and SwitchC so that these devices can access each other.
2. Establish an EBGP connection between SwitchA and SwitchB so that these devices can
exchange routing information.
3. Configure BGP and OSPF to import routes from each other on SwitchB so that the two
ASs can communicate with each other.
4. (Optional) Configure BGP route summarization on SwitchB to simplify the BGP routing
table.
Procedure



Step 3 Configure OSPF.
[SwitchB] ospf 1
[SwitchC] ospf 1
Step 4 Configure an EBGP connection.
[SwitchA] bgp 65008
[SwitchA-bgp] quit
[SwitchB] bgp 65009
Step 5 Configure BGP to interact with an IGP.
# On SwitchB, configure BGP to import OSPF routes.

[SwitchB-bgp-af-ipv4] import-route ospf 1
[SwitchB-bgp] quit



*> 10.8.1.0/24 0.0.0.0 0 0 i

*> 10.9.1.0/24 10.3.1.1 0 0 65009?
*> 10.9.2.0/24 10.3.1.1 2 0 65009?

# On SwitchB, configure OSPF to import BGP routes.

[SwitchB] ospf
[SwitchB-ospf-1] import-route bgp

[SwitchC] display ip routing-table
------------------------------------------------------------------------------
10.8.1.0/24 O_ASE 150 1 D 10.9.1.1 Vlanif20

10.9.1.0/24 Direct 0 0 D 10.9.1.2 Vlanif20
10.9.1.2/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.9.2.0/24 Direct 0 0 D 10.9.2.1 Vlanif40
10.9.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif40
Step 6 Configure automatic aggregation.
[SwitchB] bgp 65009
[SwitchB-bgp-af-ipv4] summary automatic
[SwitchB-bgp] quit
# Check the BGP routing table of SwitchA.



*> 10.0.0.0 10.3.1.1 0 65009?

*> 10.8.1.0/24 0.0.0.0 0 0 i
# Perform the ping operation to verify the configuration.

[SwitchA] ping -a 10.8.1.1 10.9.2.1

0.00% packet loss
----End

Configuration Files
#
sysname SwitchA
#
vlan batch 10 30
#
interface Vlanif10
ip address 10.3.1.2 255.255.255.0
#
interface Vlanif30
ip address 10.8.1.1 255.255.255.0
#
#
#
bgp 65008
router-id 10.1.1.1
#
ipv4-family unicast
network 10.8.1.0 255.255.255.0
#
return

#
sysname SwitchB
#
vlan batch 10 20
#
interface Vlanif10
ip address 10.3.1.1 255.255.255.0
#
interface Vlanif20
ip address 10.9.1.1 255.255.255.0
#
#
#
bgp 65009
router-id 10.2.2.2
#
ipv4-family unicast
summary automatic
import-route ospf 1
#
ospf 1
import-route bgp
area 0.0.0.0
network 10.9.1.0 0.0.0.255
#
return


#
sysname SwitchC
#
vlan batch 20 40
#
interface Vlanif20
ip address 10.9.1.2 255.255.255.0
#
interface Vlanif40
ip address 10.9.2.1 255.255.255.0
#
#
#
ospf 1
area 0.0.0.0
network 10.9.1.0 0.0.0.255
network 10.9.2.0 0.0.0.255
#
return
10.8.5 Example for Configuring AS-Path Filter
On the network shown in Figure 10-20, SwitchB establish EBGP connections with SwitchA
and SwitchC. The user wants to disable the devices in AS 10 from communicating with
devices in AS 30.
Figure 10-20 Networking diagram for configuring the AS-Path filter
AS 10 GE0/0/1
VLANIF10
10.0.1.1/24
GE0/0/2
VLANIF20
192.168.2.1/24 SwitchA
EBGP
GE0/0/2
VLANIF20 GE0/0/2 GE0/0/1
192.168.2.2/24 VLANIF30 VLANIF40
EBGP 192.168.3.2/24 10.1.1.1/24
GE0/0/1
SwitchB SwitchC
VLANIF30
AS 20 192.168.3.1/24 AS 30

1. Establish EBGP connections between SwitchA and SwitchB and between SwitchB and
SwitchC 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 SwitchB 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 3 Configure EBGP connections.

[SwitchA] bgp 10
[SwitchA-bgp] import-route direct
[SwitchA-bgp] quit
[SwitchB] bgp 20
[SwitchB-bgp] import-route direct
[SwitchB-bgp] quit
[SwitchC] bgp 30

[SwitchC-bgp] import-route direct

[SwitchC-bgp] quit
# Check the routing table advertised by SwitchB to peer 200.1.3.2. Take the routing table
advertised by SwitchB to SwitchC as an example. You can find that SwitchB advertises the
routes destined to the network segment between SwitchA and SwitchC.
[SwitchB] display bgp routing-table peer 192.168.3.2 advertised-routes


*> 10.0.1.0/24 192.168.3.1 0 20 10?

*> 10.1.1.0/24 192.168.3.1 0 20 30?
*> 192.168.2.0 192.168.3.1 0 0 20?
*> 192.168.3.0 192.168.3.1 0 0 20?
Check the routing table of SwitchC. You can find that SwitchC learns the advertised by
SwitchB.


*> 10.0.1.0/24 192.168.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 ?
*> 192.168.2.0 192.168.3.1 0 0 20?
*> 192.168.3.0 0.0.0.0 0 0 ?
192.168.3.1 0 0 20?
*> 192.168.3.2/32 0.0.0.0 0 0 ?
Step 4 Configure the AS-Path filter on SwitchB and apply the filter on the outbound interface of
SwitchB.
# Create AS-Path filter 1, denying the passing of routes carrying AS 30. The regular
expression "_30_" indicates any AS list that contains AS 30 and ".*" matches any character.
[SwitchB] ip as-path-filter path-filter1 deny _30_
[SwitchB] ip as-path-filter path-filter1 permit .*
# Create AS-Path filter 2, denying the passing of routes carrying AS 10. The regular
expression "_10_" indicates any AS list that contains AS 10 and "*" matches any character.
[SwitchB] ip as-path-filter path-filter2 deny _10_
[SwitchB] ip as-path-filter path-filter2 permit .*
# Apply the AS-Path filter on two outbound interfaces of SwitchB.

[SwitchB] bgp 20
[SwitchB-bgp] peer 192.168.2.1 as-path-filter path-filter1 export
[SwitchB-bgp] peer 192.168.3.2 as-path-filter path-filter2 export
[SwitchB-bgp] quit

Step 5 Check the routing table advertised by SwitchB, and you can find that the advertised routes to
the network segment between SwitchA and SwitchC do not exist. Take the route advertised by
SwitchB to SwitchC as an example.


*> 192.168.2.0 192.168.3.1 0 0 20?

*> 192.168.3.0 192.168.3.1 0 0 20?
Similarly, the BGP routing table of SwitchC does not have the two routes.


*> 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 ?
*> 192.168.2.0 192.168.3.1 0 0 20?
*> 192.168.3.0 0.0.0.0 0 0 ?
192.168.3.1 0 0 20?
*> 192.168.3.2/32 0.0.0.0 0 0 ?
Check the routing table advertised by SwitchB, and you can find that advertised routes
directly connected to SwitchA and SwitchC do not exist. Take the route advertised by
SwitchB to SwitchA as an example.


*> 192.168.2.0 192.168.2.2 0 0 20?

*> 192.168.3.0 192.168.2.2 0 0 20?
Similarly, the BGP routing table of SwitchA does not have the two routes.



*> 10.0.1.0/24 0.0.0.0 0 0 ?

*> 10.0.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 ?
*> 192.168.2.0 0.0.0.0 0 0 ?
192.168.2.2 0 0 20?
*> 192.168.2.1/32 0.0.0.0 0 0 ?
*> 192.168.3.0 192.168.2.2 0 0 20?
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
interface Vlanif10
ip address 10.0.1.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
#
#
bgp 10
#
ipv4-family unicast
import-route direct
#
return

#
sysname SwitchB
#
vlan batch 20 30
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
#
#
bgp 20

#
ipv4-family unicast
import-route direct
peer 192.168.2.1 as-path-filter path-filter1 export
peer 192.168.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_
ip as-path-filter path-filter2 permit .*
#
return

#
sysname SwitchC
#
vlan batch 30 40
#
interface Vlanif30
ip address 192.168.3.2 255.255.255.0
#
interface Vlanif40
ip address 10.1.1.1 255.255.255.0
#
#
#
bgp 30
#
ipv4-family unicast
import-route direct
#
return
10.8.6 Example for Configuring MED Attributes to Control BGP

Route Selection
As shown in Figure 10-21, BGP is configured on all switches; Switch A resides in AS 65008;
Switch B and Switch C reside in AS 65009. EBGP connections are established between
Switch A and Switch B, and between Switch A and Switch C. An IBGP connection is
established between Switch B and Switch C. After a period, traffic from AS 65008 to AS
65009 needs to first pass through SwitchC.

Figure 10-21 Networking diagram for configuring MED attributes of routes to control route
selection
GE0/0/1
VLANIF10
192.168.1.1/24
SwitchB
GE0/0/1 EBGP
VLANIF10 GE0/0/2
AS 65008 192.168.1.2/24
VLANIF30
AS 65009 10.1.1.1/24
SwitchA IBGP
GE0/0/2
GE0/0/2
VLANIF30
VLANIF20
EBGP 10.1.1.2/24
192.168.2.2/24
SwitchC
GE0/0/1
VLANIF20
192.168.2.1/24
1. Establish EBGP connections between SwitchA and SwitchB and between SwitchA and
SwitchC, and establish an IBGP connection between SwitchB and SwitchC.
2. Apply a routing policy to increase the MED value of the route sent by SwitchB to
SwitchA so that SwitchA will send traffic to AS 65009 through SwitchC.
Procedure


The configurations of SwitchB and SwitchC are the same as the configuration of SwitchA,
and are not mentioned here.
Step 3 Establish an BGP connection.
[SwitchA] bgp 65008
[SwitchA-bgp] quit
[SwitchB] bgp 65009
[SwitchB-bgp-af-ipv4] network 10.1.1.0 255.255.255.0
[SwitchB-bgp] quit
[SwitchC] bgp 65009
[SwitchC-bgp-af-ipv4] network 10.1.1.0 255.255.255.0
[SwitchC-bgp] quit



*> 10.1.1.0/24 192.168.1.1 0 0 65009i

* 192.168.2.1 0 0 65009i
According to the routing table, you can view that there are two valid routes destined for
10.1.1.0/24. The route whose next hop is 192.168.1.1 is the optimal route because the router
ID of SwitchB is smaller.
Step 4 Configure load balancing.
[SwitchA] bgp 65008
[SwitchA-bgp-af-ipv4] maximum load-balancing 2
[SwitchA-bgp] quit



*> 10.1.1.0/24 192.168.1.1 0 0 65009i

*> 192.168.2.1 0 0 65009i
According to the routing table, you can view that the BGP route 10.1.1.0/24 has two next
hops that are 192.168.1.1 and 192.168.2.1. Both of them are optimal routes.
Step 5 Set the MED.
# Set the MED sent from SwitchB to SwitchA through the policy.
[SwitchB] route-policy 10 permit node 10
[SwitchB-route-policy] apply cost 100
[SwitchB-route-policy] quit
[SwitchB] bgp 65009
[SwitchB-bgp] peer 192.168.1.2 route-policy 10 export


*> 10.1.1.0/24 192.168.2.1 0 0 65009i

* 192.168.1.1 100 0 65009i
According to the routing table, you can view that the MED of the next hop 192.168.1.1
(SwitchB) is 100, and that of the next hop 192.168.2.1 is 0. Therefore, the route with the
smaller MED is selected.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
#

#
bgp 65008
peer 192.168.1.1 as-number 65009
peer 192.168.2.1 as-number 65009
#
ipv4-family unicast
maximum load-balancing 2
#
return
#
sysname SwitchB
#
vlan batch 10 30
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Vlanif30
ip address 10.1.1.1 255.255.255.0
#
#
#
bgp 65009
peer 192.168.1.2 as-number 65008
#
ipv4-family unicast
network 10.1.1.0 255.255.255.0
peer 192.168.1.2 route-policy 10 export
#
route-policy 10 permit node 10
apply cost 100
#
return
#
sysname SwitchC
#
vlan batch 20 30
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif30
ip address 10.1.1.2 255.255.255.0
#
#

#
bgp 65009
peer 192.168.2.2 as-number 65008
#
ipv4-family unicast
network 10.1.1.0 255.255.255.0
#
return
10.8.7 Example for Configuring a BGP Route Reflector
As shown in Figure 10-22, eight Switches need to form an IBGP network. Full-mesh BGP
connections have been established between SwitchB, SwitchD, and SwitchE. Users require
that the IBGP network be formed without interrupting full-mesh BGP connections between
SwitchB, SwitchD, and SwitchE and require simplified device configuration and
management.
Figure 10-22 Networking diagram for configuring a BGP RR
SwitchA
AS 65010
SwitchC SwitchH
SwitchB
Cluster1 Cluster2
SwitchD SwitchE SwitchF SwitchG
GE0/0/3 GE0/0/1
VLANIF100 VLANIF10
10.0.9.1/24 SwitchA 10.1.1.1/24
GE0/0/1 GE0/0/2
VLANIF10 VLANIF30 SwitchB
GE0/0/2
10.1.1.2/24 10.1.3.2/24 GE0/0/3
VLANIF20
VLANIF40 GE0/0/4 10.1.2.1/24
10.1.4.1/24 VLANIF50
10.1.5.1/24

GE0/0/1
GE0/0/1 VLANIF40
GE0/0/5
VLANIF30 10.1.4.2/24
SwitchC VLANIF90 GE0/0/2
10.1.3.1/24
10.1.9.1/24 VLANIF60
GE0/0/2 10.1.6.1/24
GE0/0/4
VLANIF20 VLANIF80
10.1.2.2/24 10.1.8.1/24 SwitchD
GE0/0/3
VLANIF70
10.1.7.1/24
GE0/0/1 GE0/0/1
VLANIF50 VLANIF70
GE0/0/2
10.1.5.2/24 10.1.7.2/24
VLANIF60
10.1.6.2/24
SwitchE SwitchF
SwitchH
GE0/0/1
VLANIF80
10.1.8.2/24 GE0/0/1
VLANIF90
SwitchG
10.1.9.2/24
1. Configure SwitchB as the route reflector of Cluster1 and SwitchD and SwitchE as the
clients of SwitchB. Prohibit communication between the clients to form an IBGP
network without interrupting full-mesh BGP connections between SwitchB, SwitchD,
and SwitchE.
2. Configure SwitchC as the route reflector of Cluster2 and SwitchF, SwitchG, and
SwitchH as the clients of SwitchC to simplify device configuration and management.
Procedure
The configurations of SwitchB, SwitchC, SwitchD, SwitchE, SwitchF, SwitchG, and SwitchH
are the same as the configuration of SwitchA, and are not mentioned here.


Step 3 Establish IBGP connections between the clients and the RR, and between the non-clients and
the RR. The configuration details are not mentioned here.
Step 4 Configure SwitchA to advertise the local network route 10.0.9.0/24. The configuration details
are not mentioned here.
Step 5 Configure the RR.
[SwitchB] bgp 65010
[SwitchB-bgp] group in_rr internal
[SwitchB-bgp] peer 10.1.4.2 group in_rr
[SwitchB-bgp] peer 10.1.5.2 group in_rr
[SwitchB-bgp-af-ipv4] peer in_rr reflect-client
[SwitchB-bgp-af-ipv4] undo reflect between-clients
[SwitchB-bgp-af-ipv4] reflector cluster-id 1
[SwitchB-bgp] quit
[SwitchC] bgp 65010
[SwitchC-bgp] group in_rr internal
[SwitchC-bgp] peer 10.1.7.2 group in_rr
[SwitchC-bgp-af-ipv4] peer in_rr reflect-client
[SwitchC-bgp-af-ipv4] reflector cluster-id 2
[SwitchC-bgp] quit
# Check the routing table of SwitchD.

[SwitchD] display bgp routing-table 10.0.9.0

Paths: 1 available, 0 best, 0 select
BGP routing table entry information of 10.0.9.0/24:
From: 10.1.4.1 (172.16.2.2)
Route Duration: 01h04m30s
Relay IP Nexthop: 0.0.0.0
Relay IP Out-Interface:
Original nexthop: 10.1.1.2
Qos information : 0x0
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255
Originator: 172.16.1.1
Cluster list: 0.0.0.1
Not advertised to any peer yet

According to the routing table, you can view that SwitchD has learned the route advertised by
SwitchA from SwitchB. You can also view the Originator and Cluster_ID of the route.
----End
Configuration Files
#
sysname SwitchA
#
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif30
ip address 10.1.3.2 255.255.255.0
#
interface Vlanif100
ip address 10.0.9.1 255.255.255.0
#
#
#
#
bgp 65010
#
ipv4-family unicast
network 10.0.9.0 255.255.255.0
#
return

#
sysname SwitchB
#
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
#
interface Vlanif40
ip address 10.1.4.1 255.255.255.0
#
interface Vlanif50
ip address 10.1.5.1 255.255.255.0
#

#
#
#
#
bgp 65010
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
#
return
#
sysname SwitchC
#
vlan batch 20 30 70 80 90
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
#
interface Vlanif30
ip address 10.1.3.1 255.255.255.0
#
interface Vlanif70
ip address 10.1.7.1 255.255.255.0
#
interface Vlanif80
ip address 10.1.8.1 255.255.255.0
#
interface Vlanif90
ip address 10.1.9.1 255.255.255.0
#
#
#

#
#
#
bgp 65010
group in_rr internal
#
ipv4-family unicast
reflector cluster-id 2
peer in_rr enable
peer in_rr reflect-client
#
return

#
sysname SwitchD
#
vlan batch 40 60
#
interface Vlanif40
ip address 10.1.4.2 255.255.255.0
#
interface Vlanif60
ip address 10.1.6.1 255.255.255.0
#
#
#
bgp 65010
#
ipv4-family unicast
#
return

NOTE
The configuration files of other Switches are similar to the configuration file of SwitchD, and are not
mentioned here.
10.8.8 Example for Configuring a BGP4+ Route Reflection
As shown in Figure 10-23, four devices belong to two ASs. You are required to perform
simplified configuration to ensure that the two ASs communicate with each other.
Figure 10-23 Networking diagram for configuring the BGP4+ route reflectors
AS 100 SwitchC AS 200
/96
FC
GE NIF4 ::1/9
VL :0:1
IF30
11::1
VLAN 0/2
00
A
0/0 0
:0
/
GE0
/1
:0:0:
2
FC00
6
/96
IF30
11::2
VLAN 0/1
FC
GE NIF4 ::2/9
VL :0:1
/
00
GE0/0/1 GE0
:0:0:
A
0/0 0
:0
VLANIF10 GE0/0/2
/1
F C00
FC00:0:0:1::1/64 VLANIF20
2
FC00:0:0:10::1/96
6
GE0/0/2
VLANIF20 SwitchB
SwitchA FC00:0:0:10::2/96 SwitchD
1. Configure basic BGP4+ functions to allow BGP neighbors to communicate.
2. Configure SwitchC as a route reflector so that no IBGP connection needs to be
established between SwitchB and SwitchD. This simplifies the configuration.
Procedure


Step 2 Enable the IPv6 forwarding capability, and assign an IPv6 address for each interface.
[SwitchA] ipv6
[SwitchA-Vlanif10] ipv6 address fc00:0:0:0:1::1/64
[SwitchA-Vlanif20] ipv6 address fc00:0:0:0:10::1/96
Step 3 Configure the basic BGP4+ functions.

[SwitchA] bgp 100
[SwitchA-bgp] peer fc00:0:0:0:10::2 as-number 200
[SwitchA-bgp-af-ipv6] peer fc00:0:0:0:10::2 enable
[SwitchA-bgp-af-ipv6] network fc00:0:0:0:1:: 64
[SwitchA-bgp-af-ipv6] network fc00:0:0:0:10:: 96
[SwitchB] bgp 200
[SwitchB-bgp] peer fc00:0:0:0:10::1 as-number 100
[SwitchB-bgp] peer fc00:0:0:0:11::1 as-number 200
[SwitchB-bgp-af-ipv6] peer fc00:0:0:0:10::1 enable
[SwitchB-bgp-af-ipv6] peer fc00:0:0:0:11::1 enable
[SwitchB-bgp-af-ipv6] network fc00:0:0:0:10:: 96
[SwitchB-bgp-af-ipv6] network fc00:0:0:0:11:: 96
[SwitchB-bgp] quit
[SwitchC] bgp 200
[SwitchC-bgp] peer fc00:0:0:0:11::2 as-number 200
[SwitchC-bgp] peer fc00:0:0:0:12::2 as-number 200
[SwitchC-bgp-af-ipv6] peer fc00:0:0:0:11::2 enable
[SwitchC-bgp-af-ipv6] peer fc00:0:0:0:12::2 enable
[SwitchC-bgp-af-ipv6] network fc00:0:0:0:11:: 96
[SwitchC-bgp-af-ipv6] network fc00:0:0:0:12:: 96
[SwitchD] bgp 200
[SwitchD-bgp] peer fc00:0:0:0:12::1 as-number 200

[SwitchD-bgp-af-ipv6] peer fc00:0:0:0:12::1 enable

[SwitchD-bgp-af-ipv6] network fc00:0:0:0:12:: 96
[SwitchD-bgp] quit
Step 4 Configure the route reflector.

# Configure SwitchC as the route reflector and SwitchB and SwitchD as the clients.
[SwitchC-bgp-af-ipv6] peer fc00:0:0:0:11::2 reflect-client
[SwitchC-bgp-af-ipv6] peer fc00:0:0:0:12::2 reflect-client
# View the routing table of SwitchB.

[SwitchB] display bgp ipv6 routing-table

*> Network : 1:: PrefixLen : 64
NextHop : FC00:0:0:0:10::1 LocPrf :
MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i
*> Network : FC00:0:0:0:10:: PrefixLen : 96
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
NextHop : FC00:0:0:0:10::1 LocPrf :

MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i
*> Network : FC00:0:0:0:11:: PrefixLen : 96
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
i
NextHop : FC00:0:0:0:11::1 LocPrf : 100
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
*>i Network : FC00:0:0:0:12:: PrefixLen : 96
NextHop : FC00:0:0:0:11::1 LocPrf : 100
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
# View the routing table of SwitchD.

[SwitchD] display bgp ipv6 routing-table


*>i Network : FC00:0:0:1:: PrefixLen : 64
NextHop : FC00:0:0:10::1 LocPrf : 100
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 tables show that SwitchD and SwitchB have learned the routing information
advertised by SwitchA from SwitchC.
----End
Configuration Files
#
sysname SwitchA
#
ipv6
#
vlan batch 10 20
#
interface Vlanif10
ipv6 enable
#
interface Vlanif20
ipv6 enable
#
#
#
bgp 100
router-id 10.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
network FC00:0:0:1:: 64
network FC00:0:0:10:: 96
#
return

#
sysname SwitchB

#
ipv6
#
vlan batch 20 30
#
interface Vlanif20
ipv6 enable
#
interface Vlanif30
ipv6 enable
#
#
#
bgp 200
router-id 10.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
network FC00:0:0:10:: 96
network FC00:0:0:11:: 96
#
return
#
sysname SwitchC
#
ipv6
#
vlan batch 30 40
#
interface Vlanif30
ipv6 enable
#
interface Vlanif40
ipv6 enable
#
#
#
bgp 200
router-id 10.3.3.3
#
ipv4-family unicast
#

ipv6-family unicast
network FC00:0:0:11:: 96
network FC00:0:0:12:: 96
peer FC00:0:0:11::2 reflect-client
peer FC00:0:0:12::2 reflect-client
#
return

#
sysname SwitchD
#
ipv6
#
vlan batch 40
#
interface Vlanif40
ipv6 enable
#
#
bgp 200
router-id 10.4.4.4
#
ipv4-family unicast
#
ipv6-family unicast
network FC00:0:0:12:: 96
#
return
10.8.9 Example for Configuring a BGP Confederation

As shown in Figure 10-24, there are multiple BGP switches in AS 200. It is required that the
number of IBGP connections be reduced.

Figure 10-24 Networking diagram for configuring a BGP confederation

AS 200
SwitchB SwitchC
AS 65002 GE0/0/1
VLANIF20
GE0/0/1 10.1.2.2/24
VLANIF10 AS 65003
10.1.1.2/24
AS 100
GE0/0/2 AS 65001
GE0/0/1
VLANIF70 VLANIF10
10.0.1.1/24 GE0/0/1 GE0/0/2 GE0/0/1
VLANIF60 10.1.1.1/24 VLANIF20 VLANIF30
192.168.1.2/24 SwitchA 10.1.2.1/24 10.1.3.2/24
GE0/0/5 GE0/0/3
SwitchD
SwitchF VLANIF60 VLANIF30 GE0/0/2
192.168.1.1/24 GE0/0/4 10.1.3.1/24 VLANIF50
VLANIF40 10.1.5.1/24
10.1.4.1/24 GE0/0/2
VLANIF50
GE0/0/1
10.1.5.2/24
VLANIF40
10.1.4.2/24
SwitchE
1. Configure a BGP confederation on each switch in AS 200 to divide AS 200 into three
sub-ASs: AS 65001, AS 65002, and AS 65003. Three switches in AS 65001 establish
full-mesh IBGP connections to reduce the number of IBGP connections.
Procedure
[SwitchA] vlan batch 10 20 30 40 60


The configurations of SwitchB, SwitchC, SwitchD, SwitchE, and SwitchF are the same as the
configuration of SwitchA, and are not mentioned here.
The configurations of SwitchB, SwitchC, SwitchD, SwitchE, and SwitchF are the same as the
configuration of SwitchA, and are not mentioned here.
Step 3 Configure the BGP confederation.
[SwitchA] bgp 65001
[SwitchA-bgp] confederation id 200
[SwitchA-bgp] confederation peer-as 65002 65003
[SwitchA-bgp-af-ipv4] peer 10.1.1.2 next-hop-local
[SwitchA-bgp] quit
[SwitchB] bgp 65002
[SwitchB-bgp] confederation id 200
[SwitchB-bgp] confederation peer-as 65001 65003
[SwitchB-bgp] quit
[SwitchC] bgp 65003
[SwitchC-bgp] confederation id 200
[SwitchC-bgp] confederation peer-as 65001 65002
[SwitchC-bgp] quit
Step 4 Establish IBGP connection in AS 65001.

[SwitchA] bgp 65001


[SwitchD] bgp 65001
[SwitchD-bgp] quit
# Configure SwitchE.
[SwitchE] bgp 65001
[SwitchE-bgp] router-id 172.16.5.5
[SwitchE-bgp] quit
Step 5 Establish an EBGP connection between AS 100 and AS 200.
[SwitchA] bgp 65001
[SwitchA-bgp] quit
# Configure SwitchF.
[SwitchF] bgp 100
[SwitchF-bgp] router-id 172.16.6.6
[SwitchF-bgp] peer 192.168.1.1 as-number 200
[SwitchF-bgp] ipv4-family unicast
[SwitchF-bgp-af-ipv4] network 10.0.1.0 255.255.255.0
[SwitchF-bgp-af-ipv4] quit
[SwitchF-bgp] quit
# Check the BGP routing table of SwitchB.

[SwitchB] display bgp routing-table

*>i 10.0.1.0/24 10.1.1.1 0 100 0 (65001) 100i

[SwitchB] display bgp routing-table 10.0.1.0

From: 10.1.1.1 (172.16.1.1)
Relay IP Out-Interface: Vlanif10
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 SwitchD.

[SwitchD] display bgp routing-table


*>i 10.0.1.0/24 10.1.3.1 0 100 0 100i

[SwitchD] display bgp routing-table 10.0.1.0

From: 10.1.3.1 (172.16.1.1)
Relay IP Out-Interface: Vlanif30
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal,
best,select, active, pre 255
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 30 40 60
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
#
interface Vlanif30
ip address 10.1.3.1 255.255.255.0
#
interface Vlanif40
ip address 10.1.4.1 255.255.255.0
#
interface Vlanif60
ip address 192.168.1.1 255.255.255.0
#
#
#
#


#
#
bgp 65001
confederation id 200
confederation peer-as 65002 65003
#
ipv4-family unicast
peer 10.1.1.2 next-hop-local
#
return
#
sysname SwitchB
#
vlan batch 10
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
#
bgp 65002
#
ipv4-family unicast
#
return
#
sysname SwitchC
#
vlan batch 20
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
#
#
bgp 65003

#
ipv4-family unicast
#
return
#
sysname SwitchD
#
vlan batch 30 50
#
interface Vlanif30
ip address 10.1.3.2 255.255.255.0
#
interface Vlanif50
ip address 10.1.5.1 255.255.255.0
#
#
#
bgp 65001
#
ipv4-family unicast
#
return
l Configuration file of SwitchE
#
sysname SwitchE
#
vlan batch 40 50
#
interface Vlanif40
ip address 10.1.4.2 255.255.255.0
#
interface Vlanif50
ip address 10.1.5.2 255.255.255.0
#
#
#
bgp 65001
#
ipv4-family unicast


#
return
l Configuration file of SwitchF
#
sysname SwitchF
#
vlan batch 60 70
#
interface Vlanif60
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif70
ip address 10.0.1.1 255.255.255.0
#
#
#
bgp 100
#
ipv4-family unicast
network 10.0.1.0 255.255.255.0
#
return
10.8.10 Example for Configuring the BGP Community Attribute

As shown in Figure 10-25, EBGP connections are established between SwitchB and
SwitchA, and between SwitchB and SwitchC. It is required that AS 20 not advertise the
routes advertised by AS 10 to AS 30.
Figure 10-25 Networking diagram for configuring the BGP community
AS 10 GE0/0/1
VLANIF10
GE0/0/2 10.1.1.1/24
VLANIF20
192.168.2.1/24
SwitchA
EBGP
GE0/0/2 AS 20 AS 30
VLANIF20 GE0/0/3
192.168.2.2/24 VLANIF30
EBGP 192.168.3.2/24
GE0/0/3
SwitchBVLANIF30 SwitchC
192.168.3.1/24

1. Configure a route-policy on SwitchA to advertise the No_Export attribute so that AS 20
does not advertise the routes advertised by AS 10 to AS 30.
Procedure

Step 3 Configure EBGP.

# ConfigureSwitchA.
[SwitchA] bgp 10
[SwitchA-bgp] quit
[SwitchB] bgp 20
[SwitchB-bgp] quit
[SwitchC] bgp 30
[SwitchC-bgp] quit



From: 192.168.2.1 (172.16.1.1)
Direct Out-interface: Vlanif20
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select,
active, pre 255
Advertised to such 2 peers:
192.168.2.1
192.168.3.2
You can view that SwitchB advertises the received routes to SwitchC in AS 30.

*> 10.11.1.0/24 192.168.3.1 0 20 10i
You can find that SwitchC has learned a route to the destination 10.1.1.0/24 from SwitchB.
Step 4 Configure BGP community attributes.
# Configure the routing policy on SwitchA to enable SwitchB not to advertise the routes
advertised by SwitchA to any other AS.
[SwitchA] route-policy comm_policy permit node 10
[SwitchA-route-policy] apply community no-export
[SwitchA-route-policy] quit
# Apply routing policies.

[SwitchA] bgp 10
[SwitchA-bgp-af-ipv4] peer 192.168.2.2 route-policy comm_policy export
[SwitchA-bgp-af-ipv4] peer 192.168.2.2 advertise-community


From: 192.168.2.1 (172.16.1.1)
Community:no-export
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select, activ
e, pre 255

You can view the configured community attribute in the BGP routing table of SwitchB. At
this time, there are no routes to the destination 10.1.1.0/24 in the BGP routing table of
SwitchC.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
#
#
bgp 10
#
ipv4-family unicast
network 10.1.1.0 255.255.255.0
peer 192.168.2.2 route-policy comm_policy export
peer 192.168.2.2 advertise-community
#
route-policy comm_policy permit node 10
apply community no-export
#
return

#
sysname SwitchB
#
vlan batch 20 30
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
#
#
bgp 20


#
ipv4-family unicast
#
return

#
sysname SwitchC
#
vlan 30
#
interface Vlanif30
ip address 192.168.3.2 255.255.255.0
#
#
bgp 30
#
ipv4-family unicast
#
return
10.8.11 Example for Configuring BGP Load Balancing

On the network shown in Figure 10-26, BGP is configured on all switches. SwitchA is in AS
100. SwitchB and SwitchC are in AS 300. SwitchD is in AS 200. Network congestion from
SwitchA to destination address 8.1.1.0/24 needs to be relieved and network resources need to
be fully utilized.

Figure 10-26 Networking diagram of configuring BGP load balancing
SwitchA AS100
GE0/0/1 GE0/0/2
VLANIF10 VLANIF20
192.168.1.1/24 192.168.2.1/24
GE0/0/1 GE0/0/2
VLANIF10 VLANIF20
192.168.1.2/24 192.168.2.2/24
SwitchB SwitchC
AS300
GE0/0/2 GE0/0/1
VLANIF30 VLANIF40
192.168.3.2/24 192.168.4.2/24
GE0/0/2 GE0/0/1
VLANIF30 VLANIF40
192.168.3.1/24 192.168.4.1/24
SwitchD GE0/0/3
VLANIF50
AS200
10.1.1.1/24
1. Establish EBGP connections between SwitchA and SwitchB and between SwitchA and
SwitchC, between SwitchD and SwitchB and between SwitchD and SwitchC to enable
ASs to communicate with each other using BGP.
2. Configuring load balancing on SwitchA so that SwitchA can send traffic to SwitchD
through either SwitchB or SwitchC.
Procedure



Step 3 Establish BGP connections.

# Configure RouterA.
[SwitchA] bgp 100
[SwitchA-bgp] quit
# Configure RouterB.
[SwitchB] bgp 300
[SwitchB-bgp] quit
# Configure RouterC.
[SwitchC] bgp 300
[SwitchC-bgp] quit
# Configure RouterD.
[SwitchD] bgp 200
[SwitchD-bgp-af-ipv4] network 10.1.1.0 255.255.255.0
[SwitchD-bgp] quit

[SwitchA] display bgp routing-table 10.1.1.0 24

From: 192.168.1.2 (172.16.2.2)
Route Duration: 0d00h00m50s
AS-path 300 200, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
192.168.2.2

192.168.1.2
From: 192.168.2.2 (172.16.3.3)
AS-path 300 200, origin igp, pref-val 0, valid, external, pre 255, not preferred
for router ID
The preceding command output shows that there are two valid routes from SwitchA to
destination 10.1.1.0/24. The route with the next-hop address of 192.168.1.2 is the optimal
route because the router ID of SwitchB is smaller.
Step 4 Configure BGP load balancing.
# Configure load balancing on SwitchA.
[SwitchA] bgp 100
[SwitchA-bgp-af-ipv4] maximum load-balancing 2
[SwitchA-bgp] quit

[SwitchA] display bgp routing-table 10.1.1.0 24

From: 192.168.1.2 (172.16.2.2)
AS-path 300 200, origin igp, pref-val 0, valid, external, best, select, active,
pre 255
192.168.2.2
192.168.1.2
From: 192.168.2.2 (172.16.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 10.1.1.0/24 has two next hops:
192.168.1.2 and 192.168.2.2. Both of them are optimal routes.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20

#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
#
#
bgp 100
#
ipv4-family unicast
maximum load-balancing 2
#
return
#
sysname SwitchB
#
vlan batch 10 30
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.2 255.255.255.0
#
#
#
bgp 300
#
ipv4-family unicast
#
return
#
sysname SwitchC
#
vlan batch 20 40
#
interface Vlanif20
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif40

ip address 192.168.4.2 255.255.255.0

#
#
#
bgp 300
#
ipv4-family unicast
#
return
#
sysname SwitchD
#
vlan batch 30 40 50
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
interface Vlanif40
ip address 192.168.4.1 255.255.255.0
#
interface Vlanif50
ip address 10.1.1.1 255.255.255.0
#
#
#
#
bgp 200
#
ipv4-family unicast
network 10.1.1.0 255.255.255.0
#
return
10.8.12 Example for Configuring a BGP Routing Policy

Figure 10-27 shows the simplified MPLS network that carries multiple types of L3VPN
services, such as multimedia, signaling, and accounting. In Figure 10-27, two sites, each of

which has two PEs accessing the core layer, are taken as an example. The core layer is
divided into two planes. All the P nodes on the same plane are full-meshed P nodes. Nodes on
different planes are connected to provide backup paths across plane. MP-BGP is used to
advertise inner labels and VPNv4 routes between the PEs. All PEs set up MP-IBGP peer
relationships with the RR.
NOTE
Figure 10-27 is a simplified networking diagram, in which two sites are taken as an example and each
plane takes three P nodes and one RR as an example. In the actual network, there are 14 sites with 28
PEs and each plane has four P nodes and two RR nodes, and each RR needs to set up MP-IBGP
connections with 28 PEs.
Figure 10-27 Networking diagram
P1 P3
Plane A
PE1 PE3
P5
VPN site 2
10.22.1.0/24
VPN site 1
10.21.1.0/24 RR
P2
PE4
PE2 P4
Plane
Plane B
B
P6
GE1/0/0 GE1/0/0
VLANIF10 VLANIF40
10.1.1.1/30 10.1.4.2/30 GE2/0/0
GE5/0/0 P1 GE2/0/0 VLANIF60
VLANIF50 VLANIF20 GE5/0/0 P2 10.1.8.1/30
10.1.5.1/30 10.1.2.1/30 VLANIF90
10.1.9.1/30 GE3/0/0
VLANIF30 GE4/0/0
VLANIF40 10.1.7.1/30
10.1.3.1/30 VLANIF80
VLANIF60
10.1.4.1/30
10.1.6.1/30
GE1/0/0 GE2/0/0
VLANIF10 GE1/0/0 VLANIF120
10.1.1.2/30 GE4/0/0 VLANIF70 10.1.11.2/30
P3 10.1.7.2/30
GE2/0/0 VLANIF130
VLANIF110 10.1.12.1/30
10.1.10.1/30 GE4/0/0
GE3/0/0 P4 VLANIF160
VLANIF120 GE3/0/0
10.1.14.1/30
10.1.11.1/30 VLANIF150
10.1.13.1/30

GE2/0/0 GE2/0/0
VLANIF110 VLANIF170
10.1.10.2/30 10.1.15.2/30
GE1/0/0
VLANIF20 GE3/0/0
10.1.2.2/30 P5 GE1/0/0 VLANIF150
VLANIF80 P6 10.1.13.2/30
GE3/0/0
10.1.6.2/30
VLANIF170
10.1.15.1/30
PE1 GE1/0/0
GE1/0/0
VLANIF50
VLANIF30
10.1.5.2/30
10.1.3.2/30
GE2/0/0
GE2/0/0
VLANIF100
VLANIF60 RR 10.1.16.1/30
10.1.8.2/30
GE2/0/0
VLANIF100 GE1/0/0
VLANIF130 PE3
10.1.16.2/30
10.1.12.2/30
GE1/0/0
VLANIF90 GE2/0/0
PE2
10.1.9.2/30 VLANIF140
10.1.17.1/30
GE2/0/0
VLANIF140
10.1.17.2/30
PE4
GE1/0/0
VLANIF160
10.1.14.2/30
Table 10-7 IP addresses of loopback interfaces

Local Device IP Address of the Remote Device IP Address of the
local Loopback 0 Remote Loopback
Interface 0 Interface
P1 10.1.1.9/32 P2 10.2.2.9/32
P3 10.3.3.9/32 P4 10.4.4.9/32
P5 10.5.5.9/32 P6 10.6.6.9/32
PE1 10.7.7.9/32 PE2 10.8.8.9/32
PE3 10.9.9.9/32 PE4 10.10.10.9/32
RR 10.11.11.9/32 - -

Table 10-8 BGP parameter Value
BGP Parameter Value
AS number 65000
Router ID Same as the address of Loopback 0 interface
BGP community attribute Plane A: 65000:100

Plane B: 65000:200
BGP local preference Plane A: The local preference of community

attribute 65000:100 is set to 200.
Plane B: The local preference of community
attribute 65000:200 is set to 200.
NOTE
By default, the BGP local preference is 100. The
greater the value, the higher the preference.
Routing policy name Route import policy: local_pre

Route export policy: comm
Community filter name 1
BGP peer group name Client
In Figure 10-27, each PE sends BGP Update messages to the RR, other PEs receive BGP
Update messages from different planes. Therefore, routing policies need to be deployed to
ensure that one VPN flow is transmitted only through one plane.
1. Configure different RDs for two PEs in the same site to ensure that each PE can receive
two routes from different BGP next hops in the remote site. When two PEs in a site
advertise the routes to the same destination, configuring different RDs for the two PEs
can ensure that BGP peers consider the advertised routes as two different routes. This is
because BGP-VPNv4 uses the VPNv4 addresses that consist of IPv4 addresses and RDs.
2. Assign different communities for BGP routes from PE in plane A and BGP routes from
PE in plane B.
3. Set different local preferences for routes based on the community attributes of the routes.
In this manner, the PEs in plane A choose the routes advertised by remote PEs in plane
A, and the PEs in plane B always choose the routes advertised by the remote PEs in
plane B.
Procedure
Step 1 Configure names for devices and IP addresses for interfaces.
For detailed configurations, see the configuration files of this example.

Step 2 Configure an IGP.
In this example, IS-IS is used as an IGP. For detailed configurations, see the configuration
files of this example.
After the configuration, run the display ip routing-table command. You can view that PEs,
Ps and PEs, and Ps have learned the addresses of Loopback 0 interfaces from each other.
Step 3 Establish MP-IBGP connections between the PEs and RR.
# Take the configuration of PE1 as an example. Configurations of other PEs are the same as
that of PE1, and are not mentioned here.
[PE1] bgp 65000
[PE1-bgp] peer 10.11.11.9 as-number 65000
[PE1-bgp] peer 10.11.11.9 connect-interface LoopBack0
[PE1-bgp] ipv4-family unicast
[PE1-bgp-af-ipv4] undo peer 10.11.11.9 enable
[PE1-bgp-af-ipv4] quit
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 10.11.11.9 enable
# Configure the RR.

[RR] bgp 65000
[RR-bgp] group client internal
[RR-bgp] peer client connect-interface LoopBack0
[RR-bgp] ipv4-family unicast
[RR-bgp-af-ipv4] undo peer client enable
[RR-bgp-af-ipv4] quit
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo policy vpn-target
[RR-bgp-af-vpnv4] peer client enable
[RR-bgp-af-vpnv4] peer 10.7.7.9 group client
[RR-bgp-af-vpnv4] peer client reflect-client
NOTE
You need to run the undo policy vpn-target command in the BGP-VPNv4 address family view of the
RR to ensure that VPN-target-based filtering is not performed on VPNv4 routes. By default, an RR
performs VPN-target-based filtering on the received VPNv4 routes. The matching routes are added to
the VPN routing table, and the other routes are discarded. In this example, VPN instances are not
configured on the RR. As a result, if VPN-target-based filtering is enabled, all the received VPNv4
routes will be discarded.
After the configuration, run the display bgp vpnv4 all peer command on the RR. You can
view that the RR sets up MP-IBGP peers with all PEs.
[RR] display bgp vpnv4 all peer
Peer V AS MsgRcvd MsgSent OutQ Up/Down State
PrefRcv
10.7.7.9 4 65000 79 82 0 00:01:31
Established 0
10.8.8.9 4 65000 42 66 0 00:01:16
Established 0
10.9.9.9 4 65000 21 34 0 00:00:50
Established 0
10.10.10.9 4 65000 2 4 0 00:00:21
Established 0
Step 4 Configure a routing policy.

NOTE
Take the configurations of PE1, PE2, and the RR as an example. The configurations of PE3 and PE4 are
the same as the configurations of PE1 and PE2 respectively, and are not mentioned here.
# Configure a routing policy on PE1 so that the BGP VPNv4 route advertised by PE1 can
carry community attribute 65000:100.
[PE1] route-policy comm permit node 10
[PE1-route-policy] apply community 65000:100
# Configure the routing policy on PE2 so that the BGP VPNv4 route advertised by PE2 can
carry community attribute 65000:200.
[PE2] route-policy comm permit node 10
[PE2-route-policy] apply community 65000:200
# On PE1, apply the routing policy to the BGP VPNv4 route advertised by PE1 to the RR so
that the route can carry the community attribute.
[PE1] bgp 65000
[PE1-bgp-af-vpnv4] peer 10.11.11.9 route-policy comm export
[PE1-bgp-af-vpnv4] peer 10.11.11.9 advertise-community
# On PE2, apply the routing policy to the advertised BGP VPNv4 route advertised by PE2 to
the RR so that the route can carry the community attribute.
[PE2] bgp 65000
[PE2-bgp-af-vpnv4] peer 10.11.11.9 route-policy comm export
[PE2-bgp-af-vpnv4] peer 10.11.11.9 advertise-community
# Configure the RR to advertise the community attribute to the PEs.

[RR] bgp 65000
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] peer client advertise-community
# Configure the community attribute filter on PE1.

[PE1] ip community-filter 1 permit 65000:100
# Configure the community attribute filter on PE2.

[PE2] ip community-filter 1 permit 65000:200
# On PE1, configure a routing policy and set the local preference of the route with community
attribute 65000:100 to 200.
[PE1] route-policy local_pre permit node 10
[PE1-route-policy] if-match community-filter 1
[PE1-route-policy] apply local-preference 200
[PE1-route-policy] quit
# On PE2, configure a routing policy and set the local preference of the route with community
attribute 65000:200 to 200.
[PE2] route-policy local_pre permit node 10
[PE2-route-policy] if-match community-filter 1
[PE2-route-policy] apply local-preference 200
[PE2-route-policy] quit
# On PE1, apply the routing policy to the imported BGP VPNv4 route so that the PE1 chooses
the route advertised by the remote PEs in plane A.
[PE1] bgp 65000
[PE1-bgp-af-vpnv4] peer 10.11.11.9 route-policy local_pre import

# On PE2, apply the routing policy to the imported BGP VPNv4 route so that the PE2 chooses
the route advertised by the remote PEs in plane B.
[PE2] bgp 65000
[PE2-bgp-af-vpnv4] peer 10.11.11.9 route-policy local_pre import
NOTE
After this configuration, you also need to configure MPLS, establish tunnels, configure MPLS L3VPN, and
configure PEs to access CEs. For detailed configurations, see the configuration files in this example.
Run the display bgp vpnv4 all routing-table community command on a PE. You can view
information about the VPNv4 routes with community attributes. Take the display on PE1 and
PE2 as an example.
[PE1] display bgp vpnv4 all routing-table community

Total Number of Routes from all PE: 2

Route Distinguisher: 65000:10001012
Network NextHop MED LocPrf PrefVal Community
*> 10.22.1.0/24 10.9.9.9 0 200 65000:100

* 10.10.10.9 0 100 65000:200
VPN-Instance NGN_Media, router ID 10.7.7.9:

*>i 10.22.1.0/24 10.9.9.9 0 200 0 65000:100

* 10.10.10.9 0 100 0 65000:200
[PE2] display bgp vpnv4 all routing-table community

Total Number of Routes from all PE: 2


*> 10.22.1.0/24 10.10.10.9 0 200 65000:200

* 10.9.9.9 0 100 65000:100
VPN-Instance NGN_Media, router ID 10.7.7.9:

Total routes of vpn-instance NGN_Media: 2

*>i 10.22.1.0/24 10.10.10.9 0 200 0 65000:200

* 10.9.9.9 0 100 0 65000:100
Run the display ip routing-table vpn-instance NGN_Media 10.22.1.0 24 command on PE1,

and you can find that the next hop of route 10.22.1.0/24 is PE3. That is, PE1 chooses the route
advertised by PE3.
[PE1] display ip routing-table vpn-instance NGN_Media 10.22.1.0 24
------------------------------------------------------------------------------
Routing Table: NGN_Media
Summary Count: 1
10.22.1.0/24 IBGP 255 0 RD 10.9.9.9 Vlanif50
----End
Configuration Files
l Configuration file of P1
#
sysname P1
#
vlan batch 10 20 30 40 50
#
mpls lsr-id 10.1.1.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0100.1009.00
#
interface Vlanif10
description toP3Vlanif10
ip address 10.1.1.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif30
description toRRVlanif30
ip address 10.1.3.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif40
ip address 10.1.4.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif50
ip address 10.1.5.1 255.255.255.252
isis enable 64
mpls
mpls ldp

#
#
#
#
#
#
interface LoopBack0
ip address 10.1.1.9 255.255.255.255
isis enable 64
#
return
#
sysname P2
#
vlan batch 40 60 70 80 90
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0200.2009.00
#
interface Vlanif40
ip address 10.1.4.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif60
description toRRVlanif60
ip address 10.1.8.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif70
ip address 10.1.7.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif80
ip address 10.1.6.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif90

description toPE2Vlanif90
ip address 10.1.9.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
#
#
#
#
interface LoopBack0
ip address 10.2.2.9 255.255.255.255
isis enable 64
#
return
#
sysname P3
#
vlan batch 10 110 120 130
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0300.3009.00
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif110
ip address 10.1.10.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif120
ip address 10.1.11.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif130
ip address 10.1.12.1 255.255.255.252

isis enable 64
mpls
mpls ldp
#
#
#
#
#
interface LoopBack0
ip address 10.3.3.9 255.255.255.255
isis enable 64
#
return
#
sysname P4
#
vlan batch 70 120 150 160
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0400.4009.00
#
interface Vlanif70
ip address 10.1.7.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif120
ip address 10.1.11.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif150
ip address 10.1.13.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif160
ip address 10.1.14.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#


#
#
#
#
interface LoopBack0
ip address 10.4.4.9 255.255.255.255
isis enable 64
#
return
#
sysname P5
#
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0500.5009.00
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif110
ip address 10.1.10.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif170
ip address 10.1.15.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
#
#
interface LoopBack0
ip address 10.5.5.9 255.255.255.255
isis enable 64

#
return
#
sysname P6
#
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0600.6009.00
#
interface Vlanif80
ip address 10.1.6.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif150
ip address 10.1.13.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif170
ip address 10.1.15.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
#
#
interface LoopBack0
ip address 10.6.6.9 255.255.255.255
isis enable 64
#
return
l Configuration file of PE1
#
sysname PE1
#
vlan batch 50 100
#
ip vpn-instance NGN_Media
ipv4-family
route-distinguisher 65000:10001012
apply-label per-instance
vpn-target 65000:100 export-extcommunity
vpn-target 65000:100 65000:200 65000:300 import-extcommunity
#
ip vpn-instance NGN_Other

ipv4-family
#
ip vpn-instance NGN_Signaling
ipv4-family
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0700.7009.00
#
interface Vlanif50
ip address 10.1.5.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif100
ip address 10.1.16.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
interface GigabitEthernet3/0/0.10
dot1q termination vid 180
ip binding vpn-instance NGN_Media
ip address 10.21.1.73 255.255.255.252
#
ip binding vpn-instance NGN_Signaling
ip address 10.21.1.77 255.255.255.252
#
ip binding vpn-instance NGN_Other
ip address 10.21.1.81 255.255.255.252
#
#
#
interface LoopBack0
ip address 10.7.7.9 255.255.255.255
isis enable 64
#
bgp 65000
peer 10.11.11.9 as-number 65000
#
ipv4-family unicast

undo peer 10.11.11.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 10.11.11.9 route-policy local_pre import
peer 10.11.11.9 route-policy comm export
#
ipv4-family vpn-instance NGN_Media
aggregate 10.21.1.0 255.255.255.0 detail-suppressed
import-route direct
#
ipv4-family vpn-instance NGN_Other
import-route direct
#
ipv4-family vpn-instance NGN_Signaling
import-route direct
#
route-policy comm permit node 10
apply community 65000:100
#
route-policy local_pre permit node 10
if-match community-filter 1
apply local-preference 200
#
ip community-filter 1 permit 65000:100
#
return
#
sysname PE2
#
vlan batch 90 100
#
ipv4-family
#
ipv4-family
#
ipv4-family
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0800.8009.00
#
interface Vlanif90

ip address 10.1.9.2 255.255.255.252

isis enable 64
mpls
mpls ldp
#
interface Vlanif100
ip address 10.1.16.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
ip address 10.21.1.13 255.255.255.252
#
ip address 10.21.1.17 255.255.255.252
#
ip address 10.21.1.21 255.255.255.252
#
#
#
interface LoopBack0
ip address 10.8.8.9 255.255.255.255
isis enable 64
#
bgp 65000
peer 10.11.11.9 as-number 65000
#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
import-route direct
#
import-route direct
#
import-route direct
#


#
#
#
return
#
sysname PE3
#
vlan batch 130 140
#
ipv4-family
#
ipv4-family
#
ipv4-family
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0900.9009.00
#
interface Vlanif130
ip address 10.1.12.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif140
ip address 10.1.17.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
ip address 10.22.1.73 255.255.255.252
#
ip address 10.22.1.77 255.255.255.252

#
ip address 10.22.1.81 255.255.255.252
#
#
#
interface LoopBack0
ip address 10.9.9.9 255.255.255.255
isis enable 64
#
bgp 65000
peer 10.11.11.9 as-number 65000
#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
import-route direct
#
import-route direct
#
import-route direct
#
#
#
#
#
return
#
sysname PE4
#
vlan batch 140 160
#
ipv4-family

#
ipv4-family
#
ipv4-family
#
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.1001.0009.00
#
interface Vlanif140
ip address 10.1.17.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface Vlanif160
ip address 10.1.14.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
ip address 10.22.1.13 255.255.255.252
#
ip address 10.22.1.17 255.255.255.252
#
ip address 10.22.1.21 255.255.255.252
#
#
#
interface LoopBack0
ip address 10.10.10.9 255.255.255.255
isis enable 64
#
bgp 65000
peer 10.11.11.9 as-number 65000

#
ipv4-family unicast
#
ipv4-family vpnv4
policy vpn-target
#
import-route direct
#
import-route direct
#
import-route direct
#
#
#
#
return
l Configuration file of the RR
#
sysname RR
#
vlan batch 30 60
#
isis 64
network-entity 49.0091.0100.1101.1009.00
#
interface Vlanif30
ip address 10.1.3.2 255.255.255.252
isis enable 64
#
interface Vlanif60
ip address 10.1.8.2 255.255.255.252
isis enable 64
#
#
#
interface LoopBack0
ip address 10.11.11.9 255.255.255.255
isis enable 64
#
bgp 65000
group client internal
peer client connect-interface LoopBack0


peer 10.10.10.9 as-number 65000
#
ipv4-family unicast
undo peer client enable
#
ipv4-family vpnv4
undo policy vpn-target
peer client enable
peer client reflect-client
peer client advertise-community
peer 10.7.7.9 group client
#
return
10.8.13 Example for Associating BGP with BFD
As shown in Figure 10-28, SwitchA belongs to AS 100, SwitchB and SwitchC belong to AS
200. EBGP connections are established between SwitchA and SwitchB, and between SwitchA
and SwitchC.
Service traffic is transmitted along the primary link SwitchA→SwitchB. The link
SwitchA→SwitchC→SwitchB 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 10-28 Networking diagram for configuring BFD for BGP
SwitchB GE0/0/3
GE0/0/2 VLANIF40
VLANIF20 172.16.1.1/24
192.168.1.2/24
GE0/0/2 GE0/0/1
VLANIF20 EBGP VLANIF30
192.168.1.1/24 10.1.1.1/24
SwitchA IBGP
GE0/0/1 GE0/0/2
VLANIF10 VLANIF30
192.168.2.1/24 EBGP
10.1.1.2/24
GE0/0/1
VLANIF10
AS 100 192.168.2.2/24 AS 200
SwitchC

1. Configure basic BGP functions on each switch.
2. Configure the MED attribute to control route selection.
3. Enable BFD on SwitchA and SwitchB.
NOTE
If two switches 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

Step 3 Configure basic BGP functions. Establish EBGP peer relationships between Switch A and
Switch B, and between Switch A and Switch C and an IBGP peer relationship between
Switch B and Switch C.
# Configure Switch A.
[SwitchA] bgp 100
[SwitchA-bgp] peer 192.168.1.2 ebgp-max-hop
[SwitchA-bgp] peer 192.168.2.2 ebgp-max-hop
[SwitchA-bgp] quit
# Configure Switch B.
[SwitchB] bgp 200
[SwitchB-bgp] peer 192.168.1.1 ebgp-max-hop


[SwitchB-bgp] network 172.16.1.0 255.255.255.0
[SwitchB-bgp] quit
# Configure Switch C.
[SwitchC] bgp 200
[SwitchC-bgp] peer 192.168.2.1 ebgp-max-hop
[SwitchC-bgp] import-route direct
[SwitchC-bgp] quit
# Check the status of BGP peer relationships on Switch A. The command output shows that
the BGP peer relationships are in the Established state.
[SwitchA] display bgp peer
192.168.1.2 4 200 2 5 0 00:01:25 Established 0

192.168.2.2 4 200 2 4 0 00:00:55 Established 0
Step 4 Set the MED.

Set the MED sent from SwitchB to SwitchC through the policy.
[SwitchB] route-policy 10 permit node 10
[SwitchB] bgp 200
[SwitchB-bgp] peer 192.168.1.1 route-policy 10 export
[SwitchB-bgp] quit
[SwitchC] route-policy 10 permit node 10
[SwitchC-route-policy] apply cost 150
[SwitchC-route-policy] quit
[SwitchC] bgp 200
[SwitchC-bgp] peer 192.168.2.1 route-policy 10 export
[SwitchC-bgp] quit
# View all BGP routing information on SwitchA.



*> 10.1.1.0/24 192.168.2.2 150 0 200?
*> 172.16.1.0/24 192.168.1.2 100 0 200i
* 192.168.2.2 150 0 200i
*> 192.168.2.0 192.168.1.2 100 0 200?
192.168.2.2 150 0 200?
According to the BGP routing table, the next hop address of the route destined for
172.16.1.0/24 is 192.168.1.2 and service flow is transmitted on the active link SwitchA →
SwitchB.

Step 5 Configure BFD, and set the interval for transmitting BFD packets, the interval for receiving
BFD packets, and the local detection multiplier.
# Enable BFD on Switch A. Set the minimum intervals for transmitting and receiving BFD
packets to 100 ms and the local detection multiplier to 4.
[SwitchA] bfd
[SwitchA-bfd] quit
[SwitchA] bgp 100
[SwitchA-bgp] peer 192.168.1.2 bfd enable
[SwitchA-bgp] peer 192.168.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
[SwitchA-bgp] quit
# Enable BFD on Switch B. Set the minimum intervals for transmitting and receiving BFD
packets to 100 ms and the local detection multiplier to 4.
[SwitchB] bfd
[SwitchB-bfd] quit
[SwitchB] bgp 200
[SwitchB-bgp] peer 192.168.1.1 bfd enable
[SwitchB-bgp] peer 192.168.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
[SwitchB-bgp] quit
# Display all BFD sessions on Switch A.

[SwitchA] display bgp bfd session all
Local_Address Peer_Address LD/RD Interface
192.168.1.1 192.168.1.2 8201/8201 Vlanif20
Tx-interval(ms) Rx-interval(ms) Multiplier Session-State
100 100 4 Up
Wtr-interval(m)
0
# Run the shutdown command on VLANIF20 of SwitchB to simulate faults on the active
link.
[SwitchB-Vlanif20] shutdown
# Check the BGP routing table on SwitchA.



*> 10.1.1.0/24 192.168.2.2 150 0 200?
*> 172.16.1.0/24 192.168.2.2 150 0 200i
192.168.2.0 192.168.2.2 150 0 200?
According to the BGP routing table, the standby link SwitchA → SwitchC → SwitchB takes
effect after the active link fails. The next hop address of the route destined for 172.16.1.0/24
becomes 192.168.2.2.
----End

Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
bfd
#
interface Vlanif10
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
#
#
#
bgp 100
peer 192.168.1.2 ebgp-max-hop 255
peer 192.168.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
peer 192.168.1.2 bfd enable
#
ipv4-family unicast
#
return

#
sysname SwitchB
#
vlan batch 20 30 40
#
bfd
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif30
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
#
#

#
bgp 200
peer 192.168.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
peer 192.168.1.1 bfd enable
#
ipv4-family unicast
network 172.16.1.0 255.255.255.0
#
apply cost 100
#
return
#
sysname SwitchC
#
vlan batch 10 30
#
bfd
#
interface Vlanif10
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif30
ip address 10.1.1.2 255.255.255.0
#
#
#
bgp 200
#
ipv4-family unicast
import-route direct
#
apply cost 150
#
return
10.8.14 Example for Configuring BGP GTSM

As shown in Figure 10-29, SwitchA belongs to AS 10, and SwitchB, SwitchC, and SwitchD
belong to AS 20. BGP is run in the network .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.
Figure 10-29 Networking diagram for configuring BGP GTSM
GE0/0/1 SwitchB GE0/0/2 GE0/0/1

VLANIF20 VLANIF20 SwitchC
VLANIF10
10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
IBGP
SwitchA EBGP 17 Loo GE0/0/2
2. pb VLANIF30
Loopback0 16 a IBGP
172.16.2.9/32 .3 ck0 10.2.2.1/24
IB .9
GP /3 GE0/0/1
2
GE0/0/1 VLANIF30
VLANIF10 10.2.2.2/24
10.1.1.1/24
AS10
AS20 PC SwitchD
Loopback0
172.16.4.9/32
1. Configure OSPF on SwitchB, SwitchC, and SwitchD to implement interworking in AS
20.
2. Set up an EBGP connection between SwitchA and SwitchB, and set up IBGP
connections between SwitchB, SwitchC, and SwitchD through loopback interfaces.
3. Configure GTSM on SwitchA, SwitchB, SwitchC, and SwitchD so that it can protect
SwitchB against CPU-utilization attacks.
Procedure
Step 2 Assign an IP address to each interface.

# Configure SwitchB. Ensure that the configurations of SwitchA, SwitchC, and SwitchD are
[SwitchB-Vlanif10] ip address 10.1.1.2 24
[SwitchB-Vlanif20] ip address 10.2.1.2 24

[SwitchB] interface loopback 0
[SwitchB-LoopBack0] ip address 172.16.2.9 32
[SwitchB-LoopBack0] quit
Step 3 Configure OSPF.

# Configure SwitchB. Ensure that the configurations of SwitchC, and SwitchD are the same
[SwitchB] ospf
[SwitchB-ospf-1] area 0.0.0.0
Step 4 Configure an IBGP connection.

[SwitchB] bgp 20
[SwitchB-bgp] peer 172.16.3.9 connect-interface LoopBack0
[SwitchB-bgp] peer 172.16.3.9 next-hop-local
[SwitchB-bgp] peer 172.16.4.9 connect-interface LoopBack0
[SwitchB-bgp] peer 172.16.4.9 next-hop-local
[SwitchC] bgp 20
[SwitchC-bgp] peer 172.16.2.9 connect-interface LoopBack0
[SwitchC-bgp] peer 172.16.4.9 connect-interface LoopBack0
[SwitchD] bgp 20
[SwitchD-bgp] peer 172.16.2.9 connect-interface LoopBack0
[SwitchD-bgp] peer 172.16.3.9 connect-interface LoopBack0
Step 5 Configure an EBGP connection.

[SwitchA] bgp 10
[SwitchB-bgp] quit
# Display the connection status of the BGP peers.

[SwitchB] display bgp peer


172.16.3.9 4 20 8 7 0 00:05:06 Established 0

172.16.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 SwitchB has set up BGP connections with other routers.
Step 6 Configure GTSM on SwitchA and SwitchB. SwitchA and SwitchB are directly connected, so
the range of the TTL value between the two switches is [255, 255]. The value of valid-ttl-
hops is 1.
# Configure GTSM on SwitchA.
[SwitchA-bgp] peer 10.1.1.2 valid-ttl-hops 1
# Configure GTSM of the EBGP connection on SwitchB.

[SwitchB-bgp] peer 10.1.1.1 valid-ttl-hops 1
# Check the GTSM configuration.

[SwitchB] display bgp peer 10.1.1.1 verbose
BGP Peer is 10.1.1.1, remote AS 10

Type: EBGP link
BGP version 4, Remote router ID 172.16.1.9
Update-group ID : 0
BGP current state: Established, Up for 00h49m35s
BGP current event: RecvKeepalive
BGP last state: OpenConfirm
BGP Peer Up count: 1
Received total routes: 0
Received active routes total: 0
Advertised total routes: 0
Port: Local - 179 Remote - 52876
Configured: Connect-retry Time: 32 sec
Configured: Min Hold Time: 0 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 4-byte-as capability
Address family IPv4 Unicast: advertised and received
Received: Total 59 messages
Update messages 0
Open messages 2
KeepAlive messages 57
Notification messages 0
Refresh messages 0
Sent: Total 79 messages
Update messages 5
Open messages 2
Refresh messages 0
Authentication type configured: None
Last keepalive received: 2012/03/06 19:17:37
Last keepalive sent : 2012/03/06 19:17:37
Last update received: 2012/03/06 19:17:43
Last update sent : 2012/03/06 19:17:37
Minimum route advertisement interval is 30 seconds
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
GTSM has been enabled, valid-ttl-hops: 1
Peer Preferred Value: 0

Routing policy configured:

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 7 Configure GTSM on SwitchB and SwitchC. SwitchB and SwitchC are directly connected, so
hops is 1.
# Configure GTSM on SwitchB.
# Configure GTSM of the IBGP connection on SwitchC.

[SwitchC-bgp] peer 172.16.2.9 valid-ttl-hops 1
# View the GTSM configuration.


Type: IBGP link
Update-group ID : 1
BGP current event: KATimerExpired
Update messages 0
Open messages 1
Refresh messages 0
Update messages 10
Open messages 1
Refresh messages 0
Last update sent : 2012/03/06 19:18:37
Nexthop self has been configured
Connect-interface has been configured


Step 8 Configure GTSM on SwitchC and SwitchD. SwitchC and SwitchD are directly connected, so
hops is 1.
# Configure GTSM of the IBGP connection on SwitchC.

[SwitchC-bgp] peer 172.16.4.9 valid-ttl-hops 1
# Configure GTSM of the IBGP connection on SwitchD.

[SwitchD-bgp] peer 172.16.3.9 valid-ttl-hops 1

[SwitchC] display bgp peer 172.16.4.9 verbose

Type: IBGP link
Update-group ID : 1
BGP current event: KATimerExpired
Update messages 0
Open messages 1
Refresh messages 0
Update messages 0
Open messages 2
Refresh messages 0
Last update sent : 2012/03/06 19:19:37


Step 9 Configure GTSM on SwitchB and SwitchD. SwitchB and SwitchD are connected by
SwitchC, so the range of the TTL value between the two switches is [254, 255]. The value of
valid-ttl-hops is 2.
# Configure GTSM of the IBGP connection on SwitchB.
# Configure GTSM on SwitchD.

[SwitchD-bgp] peer 172.16.2.9 valid-ttl-hops 2


Type: IBGP link
Update-group ID : 1
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 : 2012/03/06 19:20:37
Nexthop self has been configured


You can view that GTSM is configured, the valid hop count is 2, and the BGP connection is in
NOTE
l In this example, if the value of valid-ttl-hops of either SwitchB or SwitchD is smaller than 2, the
IBGP connection cannot be set up.
l GTSM must be configured on the two ends of the BGP connection.

# Run the display gtsm statistics all command on SwitchB to check the GTSM statistics of
SwitchB. By default, SwitchB does not discard any packet when all packets match the GTSM
policy.
[SwitchB] 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
0 OSPFv3 0 0 0
0 RIP 0 0 0
----------------------------------------------------------------
If the host simulates the BGP packets of SwitchA to attack SwitchB, the packets are discarded
because their TTL value is not 255 when reaching SwitchB. In the GTSM statistics of
SwitchB, the number of dropped packets increases accordingly.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
#
bgp 10
peer 10.1.1.2 valid-ttl-hops 1
#
ipv4-family unicast
#
return

#
sysname SwitchB

#
vlan batch 10 20
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif20
ip address 10.2.1.1 255.255.255.0
#
#
#
interface LoopBack0
ip address 172.16.2.9 255.255.255.255
#
bgp 20
#
ipv4-family unicast
import-route ospf 1
#
ospf 1
area 0.0.0.0
network 172.16.2.9 0.0.0.0
network 10.2.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 20 30
#
interface Vlanif20
ip address 10.2.1.2 255.255.255.0
#
interface Vlanif30
ip address 10.2.2.1 255.255.255.0
#
#
#
interface LoopBack0
ip address 172.16.3.9 255.255.255.255
#

bgp 20
#
ipv4-family unicast
#
ospf 1
area 0.0.0.0
network 172.16.3.9 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return

#
sysname SwitchD
#
vlan batch 30
#
interface Vlanif30
ip address 10.2.2.2 255.255.255.0
#
#
interface LoopBack0
ip address 172.16.4.9 255.255.255.255
#
bgp 20
#
ipv4-family unicast
#
ospf 1
area 0.0.0.0
network 172.16.4.9 0.0.0.0
network 10.2.2.0 0.0.0.255
#
return
10.9 References
Table 10-9 lists the references of this feature.

Table 10-9 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 -

bfd-down- Message
subcode-00

Configuration Guide - IP Unicast Routing 11 Routing Policy Configuration
11 Routing Policy Configuration
About This Chapter
This chapter describes how to configure routing policies. Routing policies, when applied to
routing information, change the paths through which network traffic passes.
11.1 Introduction to Routing Policy

11.2 Principle
11.3 Usage Scenario
11.6 Configuring Routing Policies
11.7 Maintaining the Routing Policy
11.9 References

11.1 Introduction to Routing Policy
Definition
Routing policies are used to filter routes and set route attributes. By changing the attributes of
a route, a route policy can change the path that network traffic passes through.
Purpose
When advertising, receiving, and importing routes, routing protocols implement certain
policies to filter routes and change the attributes of the routes based on the following
networking requirements:
l Control route receiving and advertising.
Only required and valid routes are received or advertised. This reduces the size of the
routing table and improves network security.
l 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 Modify attributes of specified routes.
Attributes of routes that are filtered by a routing policy are modified to meet the
requirements of the local device.
Benefits
Routing policies offer the following benefits:
l System resources are saved by controlling the size of the routing table.
l Network security is improved by controlling route receiving, advertising and importing.
l Network performance is improved by modifying attributes of routes for proper traffic
planning.
11.2 Principle
A routing policy uses different matching rules and modes to select routes and change route
attributes. Six different filters in the routing policy can be used independently to filter routes
in specific scenarios. If the device supports the Border Gateway Protocol (BGP) to Interior
Gateway Protocol (IGP) function, BGP private attributes can serve as matching rules when
the IGP imports BGP routes.

Routing Policy Principle
Figure 11-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
Figure 11-1 shows that a routing policy consists of N nodes (N ≥ 1). Each node has its own
set of if-match clauses that must be matched in order to accept a policy. The if-match clauses
define matching rules related to route attributes and six filters. The system checks routes in
the nodes of a routing policy in ascending order of node IDs.
When a route matches all if-match clauses in a node, the route enters the matching mode
without other nodes checking. The two supported matching modes are:
l permit: A route is permitted, and actions defined by apply clauses are performed on the
route to set its attributes.
l deny: A route is denied.
If a route does not match any if-match clause in a node, the route is passed to the next node.
If the route does not match any node, 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 route
distinguisher (RD) filter. These filters have their own matching rules and modes and can be
used independently to filter routes in specific situations. The following offers a brief
explanation to each of these filters.
ACL
ACLs filter routes based on the inbound interface, source or destination IP address, source or
destination port number, and protocol of packets. They can be used independently when

routing protocols advertise and receive routes. The if-match clauses in a routing policy
support only basic ACLs.
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 filter routes based on the IP prefixes of the source IP address, destination IP
address, and next-hop IP address of packets. 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 the nodes of a routing policy in ascending order of node IDs. If a route
matches one node, the route is not checked by additional 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 an 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.
Extended Community 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.
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.
BGP to IGP Function

The BGP to IGP function enables IGPs 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, matching rules do not take effect.

11.3 Usage Scenario
Filtering Specific Routes

Figure 11-2 shows an OSPF-enabled network where RouterA receives routes from the
Internet and advertises some of the routes to RouterB. Networking configurations to consider
are as follows:
l RouterA advertises only routes 172.16.17.0/24, 172.16.18.0/24, and 172.16.19.0/24 to
RouterB.
l RouterC accepts only the route 172.16.18.0/24.
l RouterD accepts all the routes advertised by RouterB.
Figure 11-2 Networking diagram for filtering received and advertised routes
RouterC
Internet
OSPF
172.16.16.0/24
172.16.17.0/24
172.16.18.0/24
172.16.19.0/24
RouterB 172.16.20.0/24
RouterA
RouterD
The following two approaches can be used to meet the preceding network requirements:
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 routing policies.
– Configure a routing policy (matching rules can be the IP prefix list, cost, or route
tag) on RouterA and configure this routing policy as an export policy of RouterA to
be used by OSPF.
– Configure another routing policy on RouterC. Configure this routing policy as an
import policy of RouterC to be used by OSPF.
Compared with an IP prefix list, a routing 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 11-3, an autonomous system (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 11-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 routing policy on RouterA to set a tag for the
imported IS-IS routes. RouterD then identifies the IS-IS routes from OSPF routes based on
the tag.

Table 11-1 describes the routing policy configuration tasks. 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 11-1 Routing policy configuration tasks

Configuring the filter Routing policy filters include: 11.6.1 Configuring

ACLs, IP prefix lists, AS path Filters
filters, community filters,
extended community filters, and
RD filters. These routing policy
filters can be applied to the if-
match clauses of a routing
policy and can also be used
separately in specific situations.

Configuring routing policies To reduce network burden and 11.6.2 Configuring a

ensure network security, apply Routing Policy
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

Configuring the valid time In practical applications, when 11.6.3 Controlling the
of a routing policy multiple cooperative Valid Time of Routing
configurations of a routing Policies
policy change, the routing
management (RM) module
immediately informs the
protocols to re-apply the routing
policy after a configuration is
complete. If routing policies are
incomplete, route flapping
occurs, which results 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 valid 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 the configured valid
time and then apply a new
routing policy.
l If the configuration of the
routing policy changes again
during the configured valid
time, the RM module resets
the timer.
To configure the valid time, run
the route-policy-change notify-
delay command.

Other network elements are not required.

License Support
Route-policy is not under license control.
Version Support
Table 11-2 Products and minimum version supporting route-policy

Required


V200R001 and later
versions.)


forward-mode ipv4-
hardware command.

forward-mode ipv4-
hardware command.





Required
S5700 S5700LI/S5700S-LI V200R009. S5700-10P-

PWR-LI-AC/S5700-10P-LI-
AC support Route-policy
only when Layer 3 hardware
forward-mode ipv4-
hardware command.

V200R002 and later
versions.)
S5710-X-LI V200R009



S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009


None.
11.6 Configuring Routing Policies
11.6.1 Configuring Filters
Before configuring filters, configure routing protocols.
Configure each of the filters in any sequence according to network requirements.
11.6.1.1 Configuring an IP Prefix List
Context
Configuring an IP prefix list controls the advertising and receiving of routes based on the
destination address.
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 } ipv4-
address mask-length [ match-network ] [ greater-equal greater-equal-value ]
[ less-equal less-equal-value ]
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 [ match-network ] [ 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.
11.6.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 specified AS number. On a complex network, multiple ACLs or IP prefix lists
must be configured to filter BGP routes. This can be a complicated process; configuring an
AS_Path filter can simplify 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 indicates that the AS_Path filter uses a regular
expression to define matching rules. For further details about regular expressions, see "CLI
Overview" in the S2750&S5700&S6720switch - Configuration Guide - Basic Configuration.
----End

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.
11.6.1.3 Configuring a Community Filter
Context
The community attribute identifies routes with the same characteristics without considering IP
prefixes and AS numbers. Configuring community filters and community attributes simplifies

route management when it is inconvenient to use the IP prefix list or AS_Path filter. For
example, a company branch needs to receive routes only from its headquarters and from
branches in adjacent countries. In this case, you can configure different community attributes
for each of the branches. Routes in the original branch can then be managed based on
community attributes, without considering IP prefixes and AS numbers of routes in different
countries.
Community filters are classified into basic and advanced community filters. An advanced
community filter supports regular expressions and is more flexible than a basic community
filter.
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 community filter uses a
regular expression to define matching rules. For further details about regular expressions, see
"CLI Overview" in the S2750&S5700&S6720switch - 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.
11.6.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 [ basic-extcomm-filter-num | advanced-extcomm-
filter-num | extcomm-filter-name ] command to check information about a configured
extended community filter.
11.6.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

l Run the display ip rd-filter [ rd-filter-number ] command to check information about a
configured RD filter.
11.6.2 Configuring a Routing Policy
Before configuring a routing policy, configure 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 according to network
requirements.

11.6.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.

When a routing policy is used to filter a route, the route is matched with nodes in the routing
policy in ascending order of node ID. Therefore, a route is first matched with the node with
the smallest node ID. If a route matches a node in the routing policy, the system does not
continue to 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
11.6.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, routes match the routing
policy 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 a route matches this node only when they
match all the if-match clauses in this node. This rule does not apply to if-match as-path-
filter, if-match community-filter, if-match extcommunity-filter, if-match interface, or if-
match route-type clauses. The relationship between these clauses is "OR", and the
relationship between these clauses and other if-match clauses is "AND". For example, if
multiple if-match as-path-filter clauses are configured in a node, the relationship between
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 most recently 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 also perform the configuration task of 11.6.3 Controlling
the Valid Time of Routing Policies. 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 according to your 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 }
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 rd-filter rd-filter-number
An if-match clause is configured to match the RD filter.

l Run the following commands as required to match the type of route:
l Run 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
An if-match clause is configured to match the tag of routes.
----End
11.6.2.3 (Optional) Configuring an apply Clause
Context
An apply clause specifies the action of setting attributes for routes that have matched a
routing policy node. If a node does not have an apply clause configured, the node will only
filter routes. If one or more apply clauses are configured in a node, all the apply clauses are
applied to routes that have matched the node.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The route-policy view is displayed.
Step 3 Run the following commands as required to configure apply clauses. 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.

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 commands 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 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.

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
11.6.3 Controlling the Valid Time of Routing Policies

None
Procedure
Step 1 Run:
system-view
Step 2 Run:
route-policy-change notify-delay delay-time
The delay in applying the routing policy is set.
The value ranges from 1 to 180, in seconds.
By default, the RM immediately instructs protocols to apply a new policy when the existing
routing policy changes.
Step 3 Run:
quit
Return to the user view.

refresh bgp all { export | import }
BGP is configured to apply the new routing policy.
After a routing policy is configured, to make policy-based filtering take effect immediately,
use this command to configure BGP to apply the new policy immediately.
The policies 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 in applying a routing policy.
11.7 Maintaining the Routing Policy
Context
NOTICE
Statistics of IP prefix lists cannot be restored after being cleared. Exercise caution when
running these commands.

Procedure
l Run reset ip ip-prefix [ ip-prefix-name ] command in the user view to clear IPv4 prefix
list statistics.
l Run reset ip ipv6-prefix [ ipv6-prefix-name ] command in the user view to clear IPv6
prefix list statistics.
----End
11.8.1 Example for Filtering the Routes to Be Received or

Advertised
Figure 11-4 shows how on an OSPF network, SwitchA receives routes from the Internet and
provides these routes for the OSPF network. A user wants devices on the OSPF network to
access only the network segments 172.16.17.0/24, 172.16.18.0/24, and 172.16.19.0/24, and
SwitchC to access only the network segment 172.16.18.0/24.
Figure 11-4 Networking diagram for filtering the received and advertised routes
172.16.16.0/24
172.16.17.0/24
GE0/0/1 GE0/0/1 172.16.18.0/24
GE0/0/2 GE0/0/1 172.16.19.0/24
SwitchC SwitchA 172.16.20.0/24
SwitchB
OSPF
Device Interface VLANIF Interface IP Address
SwitchA GE0/0/1 VLANIF10 192.168.1.1/24
SwitchB GE0/0/1 VLANIF10 192.168.1.2/24
SwitchC GE0/0/1 VLANIF20 192.168.2.2/24

1. Configure a routing policy on SwitchA and apply the routing policy during route
advertisement. When routes are advertised, the routing policy allows SwitchA to provide
routes from network segments 172.16.17.0/24, 172.16.18.0/24, and 172.16.19.0/24 for
SwitchB, and allows devices on the OSPF network to access the three network segments.
2. Configure a routing policy on SwitchC and apply the routing policy during route
importing. When routes are imported, the routing policy allows SwitchC to receive only
the routes from the network segment 172.16.18.0/24 and access this network segment.
Procedure
Step 2 Assign IP addresses to VLANIF interfaces.


[SwitchA] ospf
[SwitchB] ospf
[SwitchC] ospf
Step 4 Configure five static routes on SwitchA and import these routes into OSPF.

[SwitchA] ip route-static 172.16.16.0 24 NULL 0

[SwitchA] ospf
[SwitchA-ospf-1] import-route static
# Check the IP routing table on SwitchB. You can see that the five static routes are imported
into OSPF.
------------------------------------------------------------------------------

172.16.16.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
172.16.17.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
172.16.18.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
172.16.19.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
172.16.20.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
192.168.1.0/24 Direct 0 0 D 192.168.1.2 Vlanif10
192.168.1.2/32 Direct 0 0 D 127.0.0.1 Vlanif10
192.168.2.0/24 Direct 0 0 D 192.168.2.1 Vlanif20
192.168.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
Step 5 Configure a policy for advertising routes.
# Configure an IP prefix list named a2b on SwitchA.

[SwitchA] ip ip-prefix a2b index 10 permit 172.16.17.0 24
# Configure a policy for advertising routes on SwitchA, and use the IP prefix list a2b to filter
routes.
[SwitchA] ospf
[SwitchA-ospf-1] filter-policy ip-prefix a2b export static
# Check the IP routing table on SwitchB. You can see that SwitchB receives only three routes
defined in a2b.
------------------------------------------------------------------------------

172.16.17.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
172.16.18.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
172.16.19.0/24 O_ASE 150 1 D 192.168.1.1 Vlanif10
192.168.1.0/24 Direct 0 0 D 192.168.1.2 Vlanif10
192.168.1.2/32 Direct 0 0 D 127.0.0.1 Vlanif10
192.168.2.0/24 Direct 0 0 D 192.168.2.1 Vlanif20
192.168.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
Step 6 Configure a policy for receiving routes.

# Configure an IP prefix list named in on SwitchC.

[SwitchC] ip ip-prefix in index 10 permit 172.16.18.0 24
# Configure a policy for receiving routes on SwitchC, and use the IP prefix list in to filter
routes.
[SwitchC] ospf
[SwitchC-ospf-1] filter-policy ip-prefix in import
# Check the IP routing table on SwitchC. You can see that the IP routing table contains only
one route defined in the IP prefix list in.
[SwitchC] display ip routing-table
------------------------------------------------------------------------------

172.16.18.0/24 O_ASE 150 1 D 192.168.2.1 Vlanif20
192.168.2.0/24 Direct 0 0 D 192.168.2.2 Vlanif20
192.168.2.2/32 Direct 0 0 D 127.0.0.1 Vlanif20
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
interface Vlanif10
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.16.17.0 24
#
#
return

#
sysname SwitchB
#
vlan batch 10 20

#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif20
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
#
return

#
sysname SwitchC
#
vlan batch 20
#
interface Vlanif20
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.16.18.0 24
#
return
11.8.2 Example for Applying a Routing Policy for Importing

Routes
In Figure 11-5, SwitchB exchanges routing information with SwitchA through OSPF, and
with SwitchC through IS-IS. A user wants SwitchB to import IS-IS routes into the OSPF
network. The user also wants the route to 172.17.1.0/24 on the OSPF network to have a low
preference and the route to 172.17.2.0/24 to have a tag, making it easy to reference by a
routing policy.

Figure 11-5 Networking diagram for applying a routing policy for importing routes
OSPF IS-IS
GE0/0/2
GE0/0/1 GE0/0/1 GE0/0/3

GE0/0/1 GE0/0/2
SwitchA SwitchC GE0/0/4
SwitchB
Device Interface VLANIF Interface IP Address
SwitchA GE0/0/1 VLANIF10 192.168.1.1/24
1. Configure a routing policy on SwitchB, 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 to have a low preference.
2. Configure a routing policy on SwitchB, set the tag of the route to 172.17.2.0/24 to 20,
and apply the routing policy when OSPF imports IS-IS routes. This allows the tag of the
route to 172.17.2.0/24 to take effect, making it easy to reference by a routing policy.
Procedure
Step 2 Assign IP addresses to VLANIF interfaces.



Step 3 Configure IS-IS.

[SwitchC] isis
[SwitchC-Vlanif20] isis enable
[SwitchB] isis
[SwitchB-Vlanif20] isis enable
Step 4 Configure OSPF and import routes.

# Configure SwitchA and enable OSPF.
[SwitchA] ospf
# Configure SwitchB, enable OSPF, and import IS-IS routes.

[SwitchB] ospf
[SwitchB-ospf-1] import-route isis 1
# Check the OSPF routing table on SwitchA. You can see the imported routes.

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 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 5 Set the filtering list.

# Configure ACL 2002 to match 172.17.2.0/24.
[SwitchB] acl number 2002
[SwitchB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
[SwitchB-acl-basic-2002] quit
# Configure an IP prefix list named prefix-a to match 172.17.1.0/24.

[SwitchB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
Step 6 Configure a routing policy.

[SwitchB] route-policy isis2ospf permit node 10
[SwitchB-route-policy] if-match ip-prefix prefix-a
[SwitchB-route-policy] if-match acl 2002
[SwitchB-route-policy] apply tag 20
Step 7 Apply the routing policy when routes are imported.

# Configure SwitchB and apply the routing policy when routes are imported.
[SwitchB] ospf
[SwitchB-ospf-1] import-route isis 1 route-policy isis2ospf
# Check the OSPF routing table on SwitchA. You can see that the cost of the route to
172.17.1.0/24 is 100; the tag of the route to 172.17.2.0/24 is 20; other route attributes remain
unchanged.

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 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 SwitchA

#
vlan batch 10
#
interface Vlanif10
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 SwitchB
#
vlan batch 10 20
#
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
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif20
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
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 SwitchC
#
#
isis 1

is-level level-2
network-entity 10.0000.0000.0001.00
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
isis enable 1
#
interface Vlanif30
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
interface Vlanif40
ip address 172.17.2.1 255.255.255.0
isis enable 1
#
interface Vlanif50
ip address 172.17.3.1 255.255.255.0
isis enable 1
#
#
#
#
#
return
11.9 References
None.

Configuration Guide - IP Unicast Routing 12 IP Routing Table Management
12 IP Routing Table Management
About This Chapter
This chapter describes how to manage IP routing tables.
12.1 Managing IP Routing Tables


12.1 Managing IP Routing Tables
12.1.1 Displaying and Maintaining a Routing Table
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 switch 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 the IPv4 routing table.
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.
l Run the display ipv6 routing-table verbose command to check detailed information
about the IPv6 routing table.

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 { 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
12.1.2 Displaying and Maintaining the Routing Management

Module
Context
If the device 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 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 rm interface [ interface-type interface-number ] command to check
IPv4 routing management (RM) information on the specified interface.
l Run the display rm ipv6 interface [ interface-type interface-number ] command to
check IPv6 RM information on the specified interface.
l Maintaining the RM Module
Configure a limit on the number of public route prefixes.
a. Run:
system-view

b. Run either of the following commands as required:
n Run:
ip prefix-limit number { alert-percent [ route-unchanged ] | simply-
alert }
A limit on the number of IPv4 public route prefixes is configured.

By default, the maximum number of IPv4 public route prefixes is not limited.
n Run:
ipv6 prefix-limit number { alert-percent [ route-unchanged ] |
simply-alert }
A limit on the number of IPv6 public route prefixes is configured.

By default, the maximum number of IPv6 public route prefixes is not limited.
alert-percent indicates the percentage of the maximum number of public route
prefixes that are supported. If you specify alert-percent in the command, an alarm is

generated when the number of public route prefixes exceeds the value calculated by
the following formula:
(number x alert-percent)/100
New public route prefixes can still be added to the routing table until the number of
public route prefixes reaches the value of number. Subsequent route prefixes are
then discarded.
If you specify simply-alert in the command, new public route prefixes can still be
added to the routing table and only an alarm is generated after the number of public
route prefixes exceeds the value of number. However, when the total number of
private and public route prefixes reaches the limit on the number of unicast route
prefixes specified in the PAF file, subsequent public route prefixes are discarded.
If you decrease the value of alert-percent after the number of public route prefixes
exceeds the value of number, whether the routing table remains unchanged is
determined by route-unchanged.
n If you specify route-unchanged in the command, the routing table remains
unchanged.
n If you do not specify route-unchanged in the command, the system deletes all
the routes from the routing table and re-adds routes.
NOTE
After the number of public route prefixes exceeds the limit, note the following rules:
l If you run the ip prefix-limit command to increase the value of number or run the
undo ip prefix-limit command to delete the limit, the device relearns IPv4 public
route prefixes.
l If you run the ipv6 prefix-limit command to increase the value of number or run the
undo ipv6 prefix-limit command to delete the limit, the device relearns IPv6 public
route prefixes.
l Direct and static routes can still be added to the IP routing table.
c. (Optional) Run:
ip prefix-limit log-interval interval
An interval at which the system generates logs after the number of public route
prefixes exceeds the limit is configured.
By default, the system generates logs at an interval of 5s after the number of public
route prefixes exceeds the limit.
You can run the command to set a longer interval to decrease the frequency at
which these logs are generated.
----End
12.1.3 FIB Query and Maintenance
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.
– 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 [ slot-id ] 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 ] ipv6-
address [ 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 ] ipv6-
address 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.
NOTE
Only the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI support vpn-instance vpn-
instance-name parameter.

l Maintain the FIB.

– Enable the alarm function for the IPv4 route prefix usage and specify the alarm
threshold.
i. Run:
system-view

ii. Run:
fib threshold-alarm upper-limit upper-limit-value lower-limit lower-
limit-value
The alarm function for the IPv4 route prefix usage is enabled and the alarm
threshold is specified.
By default, the alarm function for IPv4 route prefix usage is enabled. The
upper alarm threshold is 85% and the lower alarm threshold is 75%.
– Configure the resource mode of the extended entry space register to adjust the IPv4
and IPv6 FIB entry spaces.
i. (Optional) Run the display resource-mode configuration command to check
the resource mode configuration of the extended entry space.
ii. Run the system-view command to enter the system view.
iii. Configure the resource mode of the extended entry space.
○ On the S5720EI, run the assign resource-mode { enhanced-mac |
enhanced-ipv4 | enhanced-ipv6 } [ slot slot-id | all ] command to
configure the resource mode.
○ On the S6720EI, run the assign resource-mode { enhanced-mac |
enhanced-arp | enhanced-ipv4 | ipv4-ipv6 6:1 } [ slot slot-id | all ]
command to configure the resource mode.
By default, the resource allocation mode of the S5720EI is enhanced-mac and
that of the S6720EI is enhanced-arp.
– Configure periodic refresh of FIB entries.
i. Run:
system-view

ii. Run:
undo fib regularly-refresh disable
Periodic refresh of FIB entries is enabled.

By default, periodic refresh of FIB entries is enabled.
iii. 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.
– Configure periodic refresh of IPv6 FIB entries.
i. Run:
system-view

ii. Run:
undo ipv6 fib regularly-refresh disable
Periodic refresh of IPv6 FIB entries is enabled.

iii. You can run either of the following commands according to the actual
requirements.
○ Run:
ipv6 fib regularly-refresh interval interval
The interval for refreshing IPv6 FIB entries is configured.

By default, the interval for refreshing IPv6 FIB entries is 1 second.
○ Run:
ipv6 fib regularly-refresh entry-number entry-number
The number of IPv6 FIB entries refreshed at an interval is configured.

By default, the number of IPv6 FIB entries refreshed at an interval is 100.
○ Run:
ipv6 fib regularly-refresh start-time start-time
The time at which IPv6 FIB entries are refreshed is configured.

By default, FIB entries are refreshed at 00:00 a.m.
----End
12.1.4 Configuring IP FRR 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.
NOTE
This function is supported only by the S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI.
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 11.6.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 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
– If a backup outbound interface is specified on a P2P link, no backup next hop needs to be
specified.
– 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.
12.1.5 Configuring the ECMP Load Balancing Mode

Equal-Cost Multi-Path routing (ECMP) implements load balancing and link backup.
Context
ECMP applies to the network where multiple links to the same destination are available. In
the traditional routing technology, packets are forwarded to the destination through one link
only; the other links are in backup or inactive state; switching between these links requires a
certain period when dynamic routes are used. Different from the traditional routing
technology, ECMP can use multiple links to increase transmission bandwidth and transmit
data on a faulty link without any delay or packet loss.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ecmp load-balance sip [ dip ] [ port ]
The ECMP load balancing mode is set.
By default, ECMP load balancing is performed on packets based on the source IP address,
destination IP address, and transport-layer source port number.
NOTE
Only the S5720EI, S5720HI and S6720EI support the ECMP load balancing mode.
----End

12.2.1 Example for Configuring IP FRR on the Public Network
As shown in Figure 12-1, RouterB and RouterC are egress routers on the Internet. SwitchA is
connected to two core switches SwitchB and SwitchC through two GE interfaces. Each of
SwitchB and SwitchC is connected to the two egress routers through two GE interfaces.
When a fault occurs on the link between SwitchB and RouterB, SwitchB must rapidly
respond to the link fault and use a backup route for data forwarding to ensure that services are
forwarded correctly.
Figure 12-1 Networking diagram of configuring IP FRR on the public network
Internet
192.168.1.1/24 10.55.1.1/24
RouterC RouterB
GE0/0/2 GE0/0/2
VLANIF30 10.40.1.1/24 10.20.1.2/24 VLANIF10
10.30.1.1/24 10.10.1.2/24
SwitchC SwitchB
GE0/0/3 GE0/0/3
VLANIF50 10.70.1.1/24 10.70.1.2/24 VLANIF60
10.50.1/24 10.60.1.1/24
GE0/0/1 GE0/0/2
VLANIF50 VLANIF60
10.50.1.2/24 10.60.1.2/24
SwitchA
1. Configure static routes on SwitchA to ensure that packets destined for 192.168.1.1/24 are
forwarded by SwitchC and packets destined for 10.55.1.1/24 are forwarded by SwitchB.
2. Configure a route-policy on SwitchB and apply this route-policy for IP FRR on the
public network so that services can be rapidly switched to the backup link
SwitchB→SwitchC→RouterB when the primary link SwitchB→RouterB fails.

Procedure
Step 1 Create VLANs and add interfaces to the VLANs.
Step 2 Assign IPv4 addresses to VLANIF interfaces.

Step 3 Configure basic OSPF functions on SwitchB and SwitchC.

[SwitchB] ospf
[SwitchC] ospf
Step 4 Configure IPv4 addresses and basic OSPF functions on RouterB and RouterC to ensure that
there are reachable routes between RouterB, RouterC, SwitchB, and SwitchC.
Step 5 Configure static routes on SwitchA to ensure that packets destined for 192.168.1.1/24 are
forwarded by SwitchC and packets destined for 10.55.1.1/24 are forwarded by SwitchB.
[SwitchA] ip route-static 10.55.1.0 24 vlanif 60 10.60.1.1
[SwitchA] ip route-static 192.168.1.0 24 vlanif 50 10.50.1.1
Step 6 Configure a route-policy and enable IP FRR on the public network.

# Configure an IP prefix list on SwitchB.

[SwitchB] ip ip-prefix ip_frr_pre index 10 permit 10.55.1.0 24
# On SwitchB, configure a route-policy, backup next hop, and backup outbound interface.
[SwitchB] route-policy ip_frr_rp permit node 10
[SwitchB-route-policy] if-match ip-prefix ip_frr_pre
[SwitchB-route-policy] apply backup-nexthop 10.70.1.1
[SwitchB-route-policy] apply backup-interface vlanif 70
# On SwitchB, enable IP FRR on the public network.

[SwitchB] ip frr route-policy ip_frr_rp
Step 7 Check information about the backup outbound interface and backup next hop.
# Check information about the backup outbound interface and backup next hop on SwitchB.
[SwitchB] display ip routing-table verbose
------------------------------------------------------------------------------
Destination: 10.55.1.0/24
Protocol: OSPF Process ID: 1
Preference: 10 Cost: 2
NextHop: 10.10.1.1 Neighbour: 0.0.0.0
State: Active Adv Age:
1d17h58m22s
Tag: 0 Priority:
medium
Label: NULL QoSInfo:
0x0
IndirectID: 0x80000001
RelayNextHop: 0.0.0.0 Interface: Vlanif10
TunnelID: 0x0 Flags: RD
BkNextHop: 10.70.1.1 BkInterface: Vlanif70
BkLabel: NULL SecTunnelID: 0x0
BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x0
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 50 60
#
interface Vlanif50
ip address 10.50.1.2 255.255.255.0
#
interface Vlanif60
ip address 10.60.1.2 255.255.255.0
#
#
#

ip route-static 10.55.1.0 255.255.255.0 Vlanif60

10.60.1.1
ip route-static 192.168.1.0 255.255.255.0 Vlanif50 10.50.1.1
#
return
#
sysname SwitchB
#
#
ip frr route-policy ip_frr_rp
#
interface Vlanif10
ip address 10.10.1.2 255.255.255.0
#
interface Vlanif20
ip address 10.20.1.2 255.255.255.0
#
interface Vlanif60
ip address 10.60.1.1 255.255.255.0
#
interface Vlanif70
ip address 10.70.1.2 255.255.255.0
#
#
#
#
#
ospf 1
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 10.20.1.0 0.0.0.255
network 10.60.1.0 0.0.0.255
network 10.70.1.0 0.0.0.255
#
ip ip-prefix ip_frr_pre index 10 permit 10.55.1.0 24
#
route-policy ip_frr_rp permit node 10
if-match ip-prefix ip_frr_pre
apply backup-nexthop 10.70.1.1
apply backup-interface Vlanif70
#
return
#
sysname SwitchC
#
#
interface Vlanif30
ip address 10.30.1.1 255.255.255.0
#
interface Vlanif40
ip address 10.40.1.1 255.255.255.0
#

interface Vlanif50
ip address 10.50.1.1 255.255.255.0
#
interface Vlanif70
ip address 10.70.1.1 255.255.255.0
#
#
#
#
#
ospf 1
area 0.0.0.0
network 10.30.1.0 0.0.0.255
network 10.40.1.0 0.0.0.255
network 10.50.1.0 0.0.0.255
network 10.70.1.0 0.0.0.255
#
return

Configuration Guide - IP Unicast Routing 13 PBR Configuration
13 PBR Configuration
About This Chapter
This chapter describes how to configure PBR to improve network security and implement
load balancing.
13.1 Introduction to Policy-based Routing

13.3 Configuring PBR
13.5 FAQ
13.6 References

13.1 Introduction to Policy-based Routing

Definition
Policy-based routing (PBR) is a mechanism that makes routing decisions based on user-
defined policies.
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.
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.
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.

Other network elements are not required.
License Support
PBR is not under license control.

Version Support
Table 13-1 Products and minimum version supporting PBR

Required

S2700EI Supported only by S2752EI

V100R005 and V100R006
(The S2700EI is unavailable
in V200R001 and later
versions.)

S3700 S3700SI V100R005 (The S3700SI is




V200R002 and later
versions.)




Required

S5720EI V200R007
S5720SI/S5720S-SI V200R008


S5720HI V200R006
S6700 S6700EI V100R006 (The S6700EI is

S6720EI V200R008
S6720S-EI V200R009

None.
13.3 Configuring PBR
Context
By configuring the redirection action, the device redirects packets matching traffic
classification rules to the next hop address.
A traffic policy containing the redirection action can only be used globally, on an interface, or
in a VLAN in the inbound direction.
Before configuring 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

Procedure
1. Configure a traffic classifier.
For details about how to configure a traffic classifier, see "MQC Configuration -
Configuring a Traffic Classifier" in the S2750&S5700&S6720 Series Ethernet Switches
Configuration Guide - QoS Configuration.
2. Configure a traffic behavior.
a. Run:
traffic behavior behavior-name
A traffic behavior is created and the traffic behavior view is displayed, or the view
of an existing traffic behavior is displayed.
b. Run the following commands as required.
n Run:
redirect ip-nexthop { ip-address } &<1-4> [ forced ] *
The device is configured to redirect packets matching traffic classification

rules to the next hop.
If multiple next hop IP addresses are configured, the device redirects packets
in active/standby mode. A maximum of four next hop IP addresses can be
configured in a traffic behavior. The device determines the primary path and
backup paths according to the sequence in which next hop IP addresses were
configured. The next hop IP address that was configured first has the highest
priority and this next hop is used as the primary path. Other next hops are used
as backup paths. When the primary path is Down, the backup path with the
highest priority is used as the primary path.
NOTE
The policy-based routing (PBR) function can be implemented by configuring

redirection.
n Run:
redirect ipv6-nexthop { ipv6-address | link-local link-local-address
interface interface-type interface-number } &<1-4> [ forced ]
The device is configured to redirect IPv6 packets matching traffic

classification rules to the next hop.
n Run:
redirect ip-multihop { nexthop ip-address } &<2-4>
The device is configured to redirect packets matching traffic classification

rules to one of the multiple next hops.
If multiple next hops are specified, the device redirects packets through the
equal-cost routes that work in load balancing mode.
If the outbound interface corresponding to a next hop IP address becomes
Down or a route changes, the device switches traffic to the outbound interface
corresponding to an available next hop.
If the device has no ARP entry matching the specified next hop IP address, the
redirect ip-multihop command can be used but redirection does not take
effect. The device still forwards packets to the original destination until the
device has the corresponding ARP entry.
n Run:
redirect ipv6-multihop { ipv6-address | link-local link-local-
address interface interface-type interface-number } &<2-4>

The device is configured to redirect IPv6 packets matching traffic

classification rules to one of the multiple next hops.
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.

NOTE
Only the S5720S-SI, S5720SI, S5720EI, S5720HI, and S6720EI support PBR commands. The
S5720S-SI and S5720SI do not support the redirect ip-multihop and redirect ipv6-multihop
commands.
3. Configure a traffic policy.
For details about configuring a traffic policy, see "MQC Configuration - Configuring a
Traffic Policy" in the S2750&S5700&S6720 Series Ethernet Switches Configuration
Guide - QoS Configuration.
4. Apply the traffic policy.
– Applying a traffic policy to an interface
i. Run:
system-view

ii. Run:

iii. Run:
traffic-policy policy-name inbound
A traffic policy is applied to the inbound direction of the interface.

– Applying a traffic policy to a VLAN
i. Run:
system-view

ii. Run:
vlan vlan-id
The VLAN view is displayed.

iii. Run:
traffic-policy policy-name inbound
A traffic policy is applied to a VLAN.

Subsequently, the system performs traffic policing on the incoming packets
that are sent from the VLAN and match traffic classification rules.
– Applying a traffic policy globally

i. Run:
system-view

ii. Run:
traffic-policy policy-name global inbound [ slot slot-id ]
A traffic policy is applied globally.

l Run the display traffic classifier user-defined [ classifier-name ] command to check the
traffic classifier configuration.
l Run the display traffic behavior user-defined [ behavior-name ] command to check the
traffic behavior configuration.
l Run the display traffic policy user-defined [ policy-name [ classifier classifier-name ] ]
command to check the user-defined traffic policy configuration.
l Run the display traffic-applied [ interface [ interface-type interface-number ] | vlan
[ vlan-id ] ] { inbound | outbound } [ verbose ] command to check ACL-based
simplified and MQC-based traffic policies applied to the system, a VLAN, or an
interface.
NOTE
Traffic policies can be applied to a sub-interface, but the display traffic-applied command cannot be
used to check the ACL-based simplified and MQC-based traffic policies applied to the sub-interface.
l Run the display traffic policy { interface [ interface-type interface-number
[.subinterface-number ] ] | vlan [ vlan-id ] | global } [ inbound | outbound ] command
to check the traffic policy configuration.
l Run the display traffic-policy applied-record [ policy-name ] command to check the
application record of a specified traffic policy.
13.4.1 Example for Configuring PBR Based on IP Addresses

As shown in Figure 13-1, the Switch on the aggregation layer serves as the Layer 3
forwarding device, and an LSW on the access layer serves as the user gateway. There is a
reachable route between the Switch and LSW. The Switch is connected to two core routers
through two links: low-speed link with the gateway 10.1.20.1/24 and high-speed link with the
gateway 10.1.30.1/24.
The enterprise requires that the Switch forward packets from 192.168.100.0/24 and
192.168.101.0/24 to the core layer through the high-speed link and low-speed link,
respectively.

Figure 13-1 Networking diagram for configuring PBR

10.1.20.1/24
GE0/0/1
Core
Network Switch Network
GE0/0/3
LSW GE0/0/2
Enterprise 10.1.30.1/24
Implement PBR based on redirection to provide differentiated services. The configuration
roadmap is as follows:
1. Create VLANs and configure interfaces to implement interconnection between the
company and external networks.
2. Configure ACL rules to match packets with source IP addresses 192.168.100.0/24 and
192.168.101.0/24.
3. Configure traffic classifiers to match ACL rules so that the switch can differentiate
packets.
4. Configure traffic behaviors to redirect the packets matching different rules to
10.1.20.1/24 or 10.1.30.1/24.
5. Configure traffic policies, bind them to traffic classifiers and traffic behaviors, and apply
the traffic policies to the inbound direction of GE0/0/3 to implement PBR.
Procedure
Step 1 Create VLANs and configure interfaces.
# Create VLANs 100 and 200 on the Switch.
[HUAWEI] sysname Switch
[Switch] vlan batch 100 200
Configure GE0/0/1, GE0/0/2, and GE0/0/3 on the Switch as trunk interfaces, and add them to
VLANs 100 and 200.
[Switch] interface gigabitethernet 0/0/1
[Switch-GigabitEthernet0/0/1] port link-type trunk
[Switch-GigabitEthernet0/0/1] port trunk allow-pass vlan 100 200
[Switch-GigabitEthernet0/0/1] quit
# Create VLANIF 100 and VLANIF 200, and configure IP addresses for them.
[Switch] interface vlanif 100
[Switch-Vlanif100] ip address 10.1.20.2 24
[Switch-Vlanif100] quit


Step 2 Configure ACL rules.

# On the Switch, create advanced ACLs 3001 and 3002 that respectively allow packets with
source IP addresses 192.168.100.0/24 and 192.168.101.0/24 to pass through.
[Switch] acl 3001
[Switch-acl-adv-3001] rule permit ip source 192.168.100.0 0.0.0.255
[Switch-acl-adv-3001] quit
[Switch] acl 3002
[Switch-acl-adv-3002] rule permit ip source 192.168.101.0 0.0.0.255
Step 3 Configure traffic classifiers.

# On the Switch, create traffic classifiers c1 and c2. Bind c1 to ACL 3001 and c2 to ACL
3002.
[Switch] traffic classifier c1 operator or

[Switch-classifier-c1] if-match acl 3001
[Switch-classifier-c1] quit
[Switch] traffic classifier c2 operator or
Step 4 Configure traffic behaviors.

# On the Switch, create traffic behaviors b1 and b2, which redirect traffic to 10.1.20.1/24 and
10.1.30.1/24, respectively.
[Switch] traffic behavior b1
[Switch-behavior-b1] redirect ip-nexthop 10.1.20.1
[Switch-behavior-b1] quit
Step 5 Configure traffic policies and apply them to the interfaces.

# On the Switch, create traffic policy p1 and bind it to the traffic classifiers and traffic
behaviors.
[Switch] traffic policy p1
[Switch-trafficpolicy-p1] classifier c1 behavior b1
[Switch-trafficpolicy-p1] quit
# Apply p1 to the inbound direction of GE0/0/3.

[Switch-GigabitEthernet0/0/3] traffic-policy p1 inbound
[Switch-GigabitEthernet0/0/3] return

# Check the ACL configurations.
<Switch> display acl 3001
Advanced ACL 3001, 1 rule
Acl's step is 5
rule 5 permit ip source 192.168.100.0 0.0.0.255 (match-counter 0)
Advanced ACL 3002, 1 rule
Acl's step is 5
rule 5 permit ip source 192.168.101.0 0.0.0.255 (match-counter 0)

# Check the traffic classifier configurations.

<Switch> display traffic classifier user-defined
User Defined Classifier Information:
Classifier: c2
Operator: OR
Rule(s) :if-match acl 3002
Classifier: c1
Operator: OR
Rule(s) : if-match acl 3001
Total classifier number is 2
# Check the traffic policy configurations.

<Switch> display traffic policy user-defined p1
User Defined Traffic Policy Information:
Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
Redirect: no forced
Redirect ip-nexthop
10.1.20.1
Classifier: c2
Operator: OR
Behavior: b2
Redirect: no forced
Redirect ip-nexthop
10.1.30.1
----End
Configuration Files
l Configuration file of the Switch
#
sysname Switch
#
vlan batch 100 200
#
acl number 3001
rule 5 permit ip source 192.168.100.0 0.0.0.255
acl number 3002
rule 5 permit ip source 192.168.101.0 0.0.0.255
#
traffic classifier c1 operator or
if-match acl 3001
traffic classifier c2 operator or
if-match acl 3002
#
traffic behavior b1
redirect ip-nexthop 10.1.20.1
traffic behavior b2
#
traffic policy p1 match-order config
classifier c1 behavior b1
#
interface Vlanif100
ip address 10.1.20.2 255.255.255.0
#
interface Vlanif200
ip address 10.1.30.2 255.255.255.0
#


port trunk allow-pass vlan 100 200
#
#
traffic-policy p1 inbound
#
return
13.4.2 Example for Configuring PBR

As shown in Figure 13-2, enterprise users are dual-homed to external network devices
through Switch. Among the two links, one link is the low-speed link and the gateway address
is 10.1.20.1/24, and the other link is the high-speed link and the gateway address is
10.1.30.1/24.
The enterprise requires that outgoing packets with IP priorities 4, 5, 6, and 7 be transmitted on
the high-speed link and outgoing packets with IP priorities 0, 1, 2, and 3 be transmitted on the
low-speed link.
Figure 13-2 PBR networking

20.1.20.1/24
GE0/0/1
Core
Switch Network
GE0/0/3
LSW GE0/0/2
Enterprise 20.1.30.1/24
Redirection is used to implement PBR so that the device can provide differentiated services.
1. Create VLANs and configure interfaces so that the device can connect to external
network devices.
2. Configure ACL rules to match the packets with IP precedences of 4, 5, 6, and 7 and the
packets with IP precedences of 0, 1, 2, and 3.
3. Configure traffic classifiers and reference ACL rules in the traffic classifiers so that the
HUAWEI can differentiate packets.
4. Configure traffic behaviors to redirect the packets matching traffic classification rules to
10.1.20.1/24 and 10.1.30.1/24.
5. Configure a traffic policy and bind the traffic policy to the traffic classifiers and traffic
behaviors, and apply the traffic policy to GE0/0/3 in the inbound direction to implement
PBR.

Procedure
Step 1 Create VLANs and configure interfaces.
# Create VLAN 100 and VLAN 200 on the Switch.
[HUAWEI] sysname Switch
[Switch] vlan batch 100 200
# Configure GE0/0/1, GE0/0/2, and GE0/0/3 on the Switch as trunk interfaces and add them
to VLAN 100 and VLAN 200.
NOTE
Configure the interface of the LSW connected to Switch as a trunk interface and add it to VLAN 100
and VLAN 200.
# Create VLANIF 100 and VLANIF 200 and configure IP addresses for them.
Step 2 Configure ACLs.

# Create advanced ACLs 3001 and 3002 on the Switch. ACL 3001 permits packets with IP
precedences of 0, 1, 2, and 3 and ACL 3002 permits packets with IP precedences of 4, 5, 6,
and 7.
[Switch] acl 3001
[Switch-acl-adv-3001] rule permit ip precedence 0
[Switch] acl 3002
Step 3 Configure traffic classifiers.

Create traffic classifiers c1 and c2 on the Switch, and bind c1 to ACL 3001 and c2 to ACL
3002.
[Switch] traffic classifier c1 operator and


[Switch] traffic classifier c2 operator and

Step 4 Configure traffic behaviors.

# Create traffic behaviors b1 and b2 on the Switch that redirect traffic to 10.1.20.1/24 and
10.1.30.1/24 respectively.
Step 5 Configure a traffic policy and apply the traffic policy to interfaces.
# Create a traffic policy p1 on the Switch and bind the traffic policy to the traffic classifier
and traffic behavior.
[Switch] traffic policy p1
[Switch-trafficpolicy-p1] quit
# Apply the traffic policy p1 to GE0/0/3 in the inbound direction.

[Switch-GigabitEthernet0/0/3] traffic-policy p1 inbound
[Switch-GigabitEthernet0/0/3] return

# View the ACL configuration.
Advanced ACL 3001, 4 rules
Acl's step is 5
rule 5 permit ip precedence routine (match-counter 0)
rule 10 permit ip precedence priority (match-counter 0)
rule 15 permit ip precedence immediate (match-counter 0)
rule 20 permit ip precedence flash (match-counter 0)
Advanced ACL 3002, 4 rules
Acl's step is 5
rule 5 permit ip precedence flash-override (match-counter 0)
rule 10 permit ip precedence critical (match-counter 0)
rule 15 permit ip precedence internet (match-counter 0)
rule 20 permit ip precedence network (match-counter 0)
# View the traffic classifier configuration.

<Switch> display traffic classifier user-defined
Classifier: c2
Operator: AND
Rule(s) :if-match acl 3002
Classifier: c1
Operator: AND
Rule(s) : if-match acl 3001
Total classifier number is 2
# View the traffic policy configuration.

<Switch> display traffic policy user-defined p1

Policy: p1
Classifier: c1
Operator: AND
Behavior: b1
Redirect: no forced
Redirect ip-nexthop
10.1.20.1
Classifier: c2
Operator: AND
Behavior: b2
Redirect: no forced
Redirect ip-nexthop
10.1.30.1
----End
Configuration Files
l Configuration file of the Switch
#
sysname Switch
#
vlan batch 100 200
#
acl number 3001
rule 5 permit ip precedence routine
rule 10 permit ip precedence priority
rule 15 permit ip precedence immediate
rule 20 permit ip precedence flash
acl number 3002
rule 5 permit ip precedence flash-override
rule 10 permit ip precedence critical
rule 15 permit ip precedence internet
rule 20 permit ip precedence network
#
traffic classifier c1 operator and
if-match acl 3001
if-match acl 3002
#
traffic behavior b1

traffic behavior b2

#
#
interface Vlanif100
ip address 10.1.20.2 255.255.255.0
#
interface Vlanif200
ip address 10.1.30.2 255.255.255.0
#
#
#

#
return
13.4.3 Example for Configuring PBR to Import Traffic to the

Firewall in Bypass Mode
As shown in Figure 13-3, enterprise users need to access the Internet. Users access the
Internet through SwitchA (core switch) and the router (access gateway).
To ensure enterprise intranet security, traffic entering the enterprise intranet needs to be
imported to the firewall in bypass mode for detection.

Figure 13-3 Networking for configuring PBR to import traffic to the firewall in bypass mode
Internet
Router
GE0/0/3 GE0/0/1
10.1.10.5/24 10.1.10.6/24 10.1.1.2/24
Switch A
10.1.11.5/24 GE0/0/4
Firewall 10.1.11.6/24 GE0/0/2
10.1.20.1/24
Switch B
……
Intranet
Interface with
redirection configured
Packet flow
l Configure an IP address for each interface and configure a routing protocol between the
switch and firewall to ensure that there is a reachable route.
l Configure PBR on SwitchA to redirect traffic that is sent from the external network to
the enterprise intranet to the firewall for detection.
NOTE
This section provides only the switch configuration. For the firewall configuration, see the firewall
documentation.

Procedure
Step 1 Configure an IP address for each interface on SwitchA and the firewall, and configure a
routing protocol on SwitchA.
# Assign an IP address to each interface of SwitchA. By default, a switch interface is a Layer
2 interface. Before configuring an IP address for a switch interface, run the undo portswitch
command to switch the interface to a Layer 3 interface.
[SwitchA-GigabitEthernet0/0/1] undo portswitch
[SwitchA-GigabitEthernet0/0/1] ip address 10.1.1.2 24
# Configure a routing protocol on SwitchA to ensure Layer 3 connectivity. OSPF is used here.
Generally, two OSPF processes are configured on the firewall to advertise uplink and
downlink network segments, so two OSPF processes need to be configured on SwitchA.
[SwitchA] ospf 100
[SwitchA] ospf 200
Step 2 Configure PBR on SwitchA to redirect traffic that is sent from the external network to the
enterprise intranet to the firewall for detection.
# Configure a traffic classifier to match all traffic.
[SwitchA] traffic classifier c1
[SwitchA-classifier-c1] if-match any
[SwitchA-classifier-c1] quit
# Configure a traffic behavior to redirect matching traffic to the firewall (next hop address
10.1.10.5).
[SwitchA] traffic behavior b1
[SwitchA-behavior-b1] redirect ip-nexthop 10.1.10.5
[SwitchA-behavior-b1] quit
# Configure a traffic policy.

[SwitchA] traffic policy p1
[SwitchA-trafficpolicy-p1] classifier c1 behavior b1
[SwitchA-trafficpolicy-p1] quit
# Apply the traffic policy to GigabitEthernet0/0/1 on SwitchA in the inbound direction.


[SwitchA-GigabitEthernet0/0/1] traffic-policy p1 inbound
[SwitchA] quit

# View the traffic classifier configuration.
<SwitchA> display traffic classifier user-defined c1
Classifier: c1
Operator: AND
Rule(s) : if-match any
# View the traffic behavior configuration.

<SwitchA> display traffic behavior user-defined b1
User Defined Behavior Information:
Behavior: b1
Redirect: no forced
Redirect ip-nexthop
10.1.10.5
# View the traffic policy configuration.

<SwitchA> display traffic policy user-defined p1
Policy: p1
Classifier: c1
Operator: AND
Behavior: b1
Redirect: no forced
Redirect ip-nexthop
10.1.10.5
# View the traffic policy record.

<SwitchA> display traffic-policy applied-record
#
-------------------------------------------------
Policy Name: p1
Policy Index: 0
Classifier:c1 Behavior:b1
-------------------------------------------------
*interface GigabitEthernet0/0/1
slot 0 : success
-------------------------------------------------
Policy total applied times: 1.
#
----End
Configuration Files
#
sysname SwitchA
#
if-match any
#
traffic behavior b1
#
#

undo
portswitch
ip address 10.1.1.2
255.255.255.0
#
undo
portswitch
ip address 10.1.20.1 255.255.255.0
#
undo
portswitch
ip address 10.1.10.6 255.255.255.0
#
undo
portswitch
ip address 10.1.11.6 255.255.255.0
#
ospf
100
area
0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.10.0
0.0.0.255
#
ospf
200
area
0.0.0.0
network 10.1.11.0 0.0.0.255
network 10.1.20.0
0.0.0.255
#
return
13.5 FAQ
13.5.1 Do Huawei Fixed Switches Support PBR?
The following describes PBR supported by Huawei fixed switches.
Version Huawei Fixed Switches Supporting PBR
V100R006C05 S2700-52P-EI, S2700-52P-PWR-EI, S3700SI, and S3700EI
V200R001 S3700HI, S5700EI, S5700HI, S5710EI, and S6700
V200R002 S5700EI, S5700HI, S5710EI, and S6700
V200R003 S5700EI, S5700HI, S5710EI, S5710HI, and S6700
V200R005 S5700EI, S5700HI, S5710EI, S5710HI, and S6700
V200R006 S5720HI

Version Huawei Fixed Switches Supporting PBR
V200R007 S5720EI and S5720HI
V200R008 S5720S-SI, S5720SI, S5720EI, S5720HI and S6720EI
V200R009 S5720S-SI, S5720SI, S5720EI, S5720HI, S6720EI and

S6720S-EI
13.5.2 How Many PBR-based Routes Do Huawei Switches

Support?
Huawei switches support four PBR-based routes. A maximum of four next hop addresses can
be defined in a traffic behavior.
When the redirect ip-nexthop or redirect ipv6-nexthop command is used to configure
multiple next hop IP addresses, the switch redirects packets in active/standby mode. The
device determines the primary path and backup paths according to the sequence in which next
hop IP addresses were configured. The next hop IP address that is configured first has the
highest priority and this next hop is used as the primary path. Other next hops are used as
backup paths. If the primary link becomes Down, a next hop with higher priority is used as
the primary link.
When the redirect ip-multihop or redirect ipv6-multihop command is used to configure
multiple next hop IP addresses, the switch redirects packets using equal-cost routes in load
balancing mode.
13.6 References
None


S6720 V200R008C00 Configuration Guide - IP Unicast Routing PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S6720 V200R008C00 Configuration Guide - IP Unicast Routing PDF

Uploaded by

Copyright:

Available Formats

S2750&S5700&S6720 Series Ethernet Switches

Configuration Guide - IP Unicast

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 03 (2016-10-30) Huawei Proprietary and Confidential i

About This Document

Indicates an imminently hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Issue 03 (2016-10-30) Huawei Proprietary and Confidential ii

NOTE Calls attention to important information,

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

&<1-n> The parameter before the & sign can be repeated 1 to n

# A line starting with the # sign is comments.

Interface Numbering Conventions

Issue 03 (2016-10-30) Huawei Proprietary and Confidential iii

– When configuring a password, the cipher text is recommended. To ensure device

Mappings between Product Software Versions and NMS

Issue 03 (2016-10-30) Huawei Proprietary and Confidential iv

S2750&S5700&S6720 Product eSight

V200R008C00 eSight V300R003C20

Changes in Issue 03 (2016-10-30) V200R008C00

Changes in Issue 02 (2015-10-23) V200R008C00

Changes in Issue 01 (2015-07-31) V200R008C00

Issue 03 (2016-10-30) Huawei Proprietary and Confidential v

About This Document.....................................................................................................................ii

3 Static Route Configuration........................................................................................................ 17

Issue 03 (2016-10-30) Huawei Proprietary and Confidential vi

3.5 Default Configuration of Static Routes........................................................................................................................ 27

Issue 03 (2016-10-30) Huawei Proprietary and Confidential vii

4.6.1.5 Checking the Configuration....................................................................................................................................77

Issue 03 (2016-10-30) Huawei Proprietary and Confidential viii

4.9 Common Configuration Errors................................................................................................................................... 118

Issue 03 (2016-10-30) Huawei Proprietary and Confidential ix

Issue 03 (2016-10-30) Huawei Proprietary and Confidential x

6.7.4 Configuring OSPF Stub Areas................................................................................................................................ 202

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xi

6.7.11.1 Setting the Priority of OSPF............................................................................................................................... 234

7 OSPFv3 Configuration............................................................................................................. 291

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xii

7.6 Configuring OSPFv3.................................................................................................................................................. 313

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xiii

7.6.9.2 Configuring an Authentication Mode...................................................................................................................338

8 IPv4 IS-IS Configuration..........................................................................................................368

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xiv

8.6.1 Configure Basic IS-IS Functions............................................................................................................................. 419

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xv

8.7.3 Configuring the Output of IS-IS Adjacency Status................................................................................................. 461

9 IPv6 IS-IS Configuration..........................................................................................................502

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xvi

9.6.4.2 Configuring IS-IS to Import External Routes.......................................................................................................529

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xvii

10.6 Configuring BGP...................................................................................................................................................... 586

Issue 03 (2016-10-30) Huawei Proprietary and Confidential xviii

10.6.7.3 Configuring the BGP GR Function.................................................................................................................... 627