Configuration Guide - IP Routing

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

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

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

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

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

l Commissioning Engineer
l Data Configuration Engineer
l Network Monitoring Engineer
l System Maintenance Engineer
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation which, if not

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

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

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

tips.
NOTE is used to address information not related to personal
injury, equipment damage, and environment deterioration.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
Issue 02 (2014-09-30) Huawei Proprietary and Confidential iii

Convention Description
[ x | y | ... ] Optional items are grouped in brackets and separated by

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

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

vertical bars. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 02 (2014-09-30)

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

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

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

1 IP Routing Basic Configuration..................................................................................................1
1.1 Routing Management.....................................................................................................................................................3
1.1.1 Displaying of the Routing Table.................................................................................................................................3
1.1.2 Displaying of the Routing Management Module........................................................................................................4
1.1.3 FRR Principle..............................................................................................................................................................4
1.2 Configuring IPv4 Multi-Topology.................................................................................................................................5
1.2.1 Before You Start..........................................................................................................................................................5
1.2.2 Creating an IPv4 Topology Instance...........................................................................................................................6
1.2.3 Binding an Interface to an IPv4 Topology Instance....................................................................................................7
1.2.4 Checking the Configurations.......................................................................................................................................8
1.3 Configuring IPv6 Multi-Topology.................................................................................................................................9
1.3.1 Before You Start..........................................................................................................................................................9
1.3.2 Creating an IPv6 Topology Instance.........................................................................................................................10
1.3.3 Binding an Interface to an IPv6 Topology Instance..................................................................................................11
1.3.4 Checking the Configurations.....................................................................................................................................11
1.4 Configuring Public Network IP FRR...........................................................................................................................12
1.4.1 Before You Start........................................................................................................................................................12
1.4.2 Configuring a Route-Policy.......................................................................................................................................13
1.4.3 Enabling Public Network IP FRR.............................................................................................................................14
1.5 Configuring Public Network IPv6 FRR.......................................................................................................................15
1.5.1 Before You Start........................................................................................................................................................16
1.5.2 Configuring a Route-Policy.......................................................................................................................................16
1.5.3 Enabling Public Network IPv6 FRR.........................................................................................................................17
1.6 Configuring VRRP for Direct Routes..........................................................................................................................19
1.6.1 Before You Start........................................................................................................................................................19
1.6.2 Configuring a VRRP Backup Group.........................................................................................................................20
1.6.3 Associating an Interface with a VRRP Backup Group..............................................................................................21
1.7 Configuring an IPv4 Direct Route to Respond to L3VE Interface Status Changes After a Delay..............................23
Issue 02 (2014-09-30) Huawei Proprietary and Confidential v

1.8 Configuring an IPv6 Direct Route to Respond to L3VE Interface Status Changes After a Delay..............................26
1.9 Configuring the Association Between the IPv4 Direct Route and PW Status.............................................................28
1.10 Configuring the Association Between the IPv6 Direct Route and PW Status...........................................................31
1.11 Configuring the Association Between the IPv4 Direct Routes and IPSec Instance Status........................................33
1.12 Configuring a Device to Deactivate the IPv4 Network Segment Route That Corresponds to an L3VE Sub-interface
............................................................................................................................................................................................35
1.13 Configuring a Device to Deactivate the IPv6 Network Segment Route That Corresponds to an L3VE Sub-interface
............................................................................................................................................................................................38
1.14 Configuring AGGs to Load-Balance RNC-to-CSG Traffic.......................................................................................42
1.15 Configuring the Advertisement of IPv4 ARP Vlink Direct Routes on the Public Network......................................46
1.15.1 Before You Start......................................................................................................................................................46
1.15.2 Enabling the Advertisement of IPv4 ARP Vlink Direct Routes.............................................................................47
1.15.3 Checking the Configurations...................................................................................................................................48
1.16 Configuring the Advertisement of IPv6 NDP Vlink Direct Routes on the Public Network......................................49
1.16.1 Before You Start......................................................................................................................................................49
1.16.2 Enabling the Advertisement of IPv6 NDP Vlink Direct Routes.............................................................................50
1.17 Maintaining the Route Management Module.............................................................................................................52
1.17.1 Configuring Thresholds for the Number of IPv4 Route Prefixes............................................................................52
1.17.2 Configuring Thresholds for the Number of IPv6 Route Prefixes............................................................................53
1.17.3 Configuring a Limit on the Number of IPv4 Public Route Prefixes.......................................................................54
1.17.4 Configuring a Limit on the Number of IPv6 Public Route Prefixes.......................................................................55
1.18 Configuration Example...............................................................................................................................................57
1.18.1 Example for Configuring Public Network IP FRR.................................................................................................57
1.18.2 Example for Configuring Public Network IPv6 FRR.............................................................................................60
1.18.3 Example for Configuring VRRP for Direct Routes.................................................................................................65
1.18.4 Example for Importing IPv4 ARP Vlink Direct Routes to BGP.............................................................................72
1.18.5 Example for Importing IPv6 NDP Vlink Direct Routes to BGP4+........................................................................79
2 IP Static Route Configuration...................................................................................................89

2.1 Introduction..................................................................................................................................................................91
2.1.1 Static Route................................................................................................................................................................91
2.1.2 Static Routing Features Supported by the NE80E/40E.............................................................................................91
2.2 Configuring an IPv4 Static Route.................................................................................................................................93
2.2.1 Before You Start........................................................................................................................................................93
2.2.2 Configuring an IPv4 Static Route on the Public Network.........................................................................................94
2.2.3 (Optional) Setting the Default Preference for IPv4 Static Routes.............................................................................95
2.2.4 (Optional) Configuring Static Route Selection Based on Relay Depth.....................................................................95
2.2.5 (Optional) Configuring Permanent Advertisement of IPv4 Static Routes................................................................96
2.2.6 Configuring Static IPv4 Routes in a Topology Instance...........................................................................................96
2.3 Configuring an IPv6 Static Route.................................................................................................................................97
2.3.1 Before You Start........................................................................................................................................................98
Issue 02 (2014-09-30) Huawei Proprietary and Confidential vi

2.3.2 Configuring an IPv6 Static Route on the Public Network.........................................................................................98

2.3.3 (Optional) Setting the Default Preference for IPv6 Static Routes.............................................................................99
2.3.4 Configuring Static IPv6 Routes in a Topology Instance...........................................................................................99
2.4 Configuring BFD for IPv4 Static Routes on the Public Network..............................................................................100
2.4.1 Before You Start......................................................................................................................................................100
2.4.2 Configuring an IPv4 static route..............................................................................................................................101
2.4.3 Configuring a BFD Session.....................................................................................................................................102
2.4.4 Binding a Static Route to a BFD Session................................................................................................................103
2.5 Configuring BFD for IPv6 Static Routes on the Public Network..............................................................................104
2.5.1 Before You Start......................................................................................................................................................104
2.5.2 Configuring an IPv6 static route..............................................................................................................................105
2.5.3 Configuring a BFD Session.....................................................................................................................................105
2.5.4 Binding a Static Route to a BFD Session................................................................................................................106
2.6 Configuring NQA for IPv4 Static Routes...................................................................................................................107
2.6.1 Before You Start......................................................................................................................................................108
2.6.2 Configuring an ICMP Type NQA Test Instance.....................................................................................................109
2.6.3 Binding an IPv4 Static Route to an NQA Test Instance..........................................................................................110
2.7 Configuring NQA for IPv6 Static Routes...................................................................................................................112
2.7.1 Before You Start......................................................................................................................................................112
2.7.2 Configuring an ICMP NQA Test Instance..............................................................................................................113
2.7.3 Associating a IPv6 Static Route with an NQA Test Instance..................................................................................115
2.8 Configuring IPv4 Static Routes to Inherit the Costs of Iterated Routes.....................................................................117
2.9 Configuring IPv6 Static Routes to Inherit the Costs of Iterated Routes.....................................................................119
2.10 Configuration Examples...........................................................................................................................................121
2.10.1 Example for Configuring IPv4 Static Routes........................................................................................................122
2.10.2 Example for Configuring IPv6 Static Routes........................................................................................................125
2.10.3 Example for Configuring BFD for IPv4 Static Routes..........................................................................................128
2.10.4 Example for Configuring BFD for IPv6 Static Routes..........................................................................................131
2.10.5 Example for Configuring NQA for IPv4 Static Routes.........................................................................................135
2.10.6 Example for Configuring NQA for IPv6 Static Routes.........................................................................................142
2.10.7 Example for Configuring Permanent Advertisement of IPv4 Static Routes.........................................................148
3 RIP Configuration.....................................................................................................................155
3.1 Introduction................................................................................................................................................................157
3.1.1 Overview of RIP......................................................................................................................................................157
3.1.2 RIP Features Supported by the NE80E/40E............................................................................................................158
3.2 Configuring Basic RIP Functions...............................................................................................................................158
Issue 02 (2014-09-30) Huawei Proprietary and Confidential vii

3.2.1 Before You Start......................................................................................................................................................158

3.2.2 Enabling RIP............................................................................................................................................................159
3.2.3 Enabling RIP on the Specified Network Segment...................................................................................................160
3.2.4 Configuring RIP Version Number...........................................................................................................................160
3.3 Configuring RIP Route Attributes..............................................................................................................................164
3.3.1 Before You Start......................................................................................................................................................164
3.3.2 Configuring Additional Metrics of an Interface......................................................................................................164
3.3.3 Configuring RIP Preference....................................................................................................................................166
3.3.4 Setting the Maximum Number of Equal-Cost Routes.............................................................................................167
3.4 Configuring RIP to Import External Routes...............................................................................................................168
3.5 Controlling the Advertising of RIP Routing Information..........................................................................................169
3.5.1 Before You Start......................................................................................................................................................169
3.5.2 Configuring RIP to Advertise Default Routes.........................................................................................................170
3.5.3 Disabling an Interface from Sending RIP Update Packets......................................................................................170
3.5.4 Configuring RIP to Filter the Routes to be Sent......................................................................................................172
3.6 Controlling the Receiving of RIP Routing Information.............................................................................................174
3.6.1 Before You Start......................................................................................................................................................174
3.6.2 Disabling an Interface from Receiving RIP Update Packets...................................................................................175
3.6.3 Disabling RIP from Receiving Host Routes............................................................................................................175
3.6.4 Configuring RIP to Filter the Received Routes.......................................................................................................176
3.7 Configuring RIP-2 Features........................................................................................................................................179
3.7.1 Before You Start......................................................................................................................................................179
3.7.2 Configuring RIP-2 Route Summarization...............................................................................................................180
3.7.3 Configuring Packet Authentication of RIP-2..........................................................................................................181
3.8 Optimizing a RIP Network.........................................................................................................................................189
3.8.1 Before You Start......................................................................................................................................................189
3.8.2 Configuring RIP Timers..........................................................................................................................................190
3.8.3 Setting the Interval for Sending Packets and the Maximum Number of the Sent Packets......................................191
3.8.4 Configuring Split Horizon and Poison Reverse......................................................................................................191
3.8.5 Enabling replay-protect Function............................................................................................................................192
3.8.6 Configuring RIP to Check the Validity of Update Packets.....................................................................................193
3.8.7 Configuring RIP Neighbors.....................................................................................................................................194
3.8.8 Configuring the RIP GTSM Functions....................................................................................................................195
3.9 Configuring RIP GR...................................................................................................................................................196
3.9.1 Before You Start......................................................................................................................................................196
Issue 02 (2014-09-30) Huawei Proprietary and Confidential viii

3.9.2 Enabling RIP GR.....................................................................................................................................................197

3.10 Configuring BFD for RIP.........................................................................................................................................198
3.11 Configuring Static BFD for RIP...............................................................................................................................201
3.12 Configuring the Network Management Function in RIP.........................................................................................204
3.12.1 Before You Start....................................................................................................................................................204
3.12.2 Binding RIP to MIBs.............................................................................................................................................204
3.12.3 Checking the Configurations.................................................................................................................................205
3.13 Maintaining RIP.......................................................................................................................................................205
3.13.1 Resetting RIP.........................................................................................................................................................205
3.13.2 Clearing RIP..........................................................................................................................................................205
3.14.1 Example for Configuring RIP Version..................................................................................................................206
3.14.2 Example for Configuring RIP to Import External Routes.....................................................................................209
3.14.3 Example for Configuring One-Arm Static BFD for RIP.......................................................................................213
3.14.4 Example for Configuring BFD for RIP.................................................................................................................219
4 RIPng Configuration.................................................................................................................225
4.1 Introduction................................................................................................................................................................227
4.1.1 RIPng Overview......................................................................................................................................................227
4.1.2 RIPng Features Supported by the NE80E/40E........................................................................................................228
4.2 Configuring Basic RIPng Functions...........................................................................................................................228
4.2.1 Before You Start......................................................................................................................................................228
4.2.2 Enabling RIPng and Entering the RIPng View.......................................................................................................229
4.2.3 Enabling RIPng in the Interface View.....................................................................................................................229
4.3 Configuring RIPng Route Attributes..........................................................................................................................232
4.3.1 Before You Start......................................................................................................................................................232
4.3.2 Configuring the RIPng Preference..........................................................................................................................233
4.3.3 Configuring Additional Metrics of an Interface......................................................................................................233
4.3.4 Configuring the Maximum Number of Equal-Cost Routes.....................................................................................234
4.4 Configuring RIPng Route Summarization.................................................................................................................236
4.5 Configuring RIPng to Import External Routes...........................................................................................................236
4.6 Controlling the Advertising of RIPng Routing Information......................................................................................237
4.6.1 Before You Start......................................................................................................................................................237
4.6.2 Configuring RIPng to Advertise the Default Routes...............................................................................................238
4.6.3 Disabling Sending of RIPng Packets on an Interface..............................................................................................238
4.6.4 Configuring RIPng to Filter the Routes to be Sent..................................................................................................239
4.7 Controlling the Receiving of RIPng Routing Information.........................................................................................242
4.7.1 Before You Start......................................................................................................................................................242
Issue 02 (2014-09-30) Huawei Proprietary and Confidential ix

4.7.2 Disabling Receiving of RIPng Packets on an Interface...........................................................................................243

4.7.3 Configuring RIPng to Filter the Received Routes...................................................................................................244
4.8 Optimizing a RIPng Network.....................................................................................................................................247
4.8.1 Before You Start......................................................................................................................................................247
4.8.2 Configuring RIPng Timers......................................................................................................................................248
4.8.3 Setting the Interval for Sending Update Packets and the Maximum Number of Packets Sent Each Time.............248
4.8.4 Configuring Split Horizon and Poison Reverse......................................................................................................249
4.8.5 Enabling the Zero Field Check for RIPng Packets..................................................................................................249
4.9 Configuring IPSec Authentication for RIPng.............................................................................................................250
4.9.1 Before You Start......................................................................................................................................................251
4.9.2 Configuring IPSec Authentication in a RIPng Process...........................................................................................251
4.9.3 Configuring IPSec Authentication on a RIPng Interface........................................................................................252
4.10.1 Example for Configuring RIPng to Filter the Received Routes............................................................................254
5 OSPF Configuration..................................................................................................................258
5.1 Introduction................................................................................................................................................................260
5.1.1 OSPF Overview.......................................................................................................................................................260
5.1.2 OSPF Features Supported by the NE80E/40E........................................................................................................263
5.2 Configuring Basic OSPF Functions...........................................................................................................................268
5.2.1 Before You Start......................................................................................................................................................268
5.2.2 Enabling OSPF........................................................................................................................................................269
5.2.3 (Optional) Creating OSPF Virtual Links.................................................................................................................271
5.2.4 (Optional) Configuring a Route Selection Rule on the router.................................................................................272
5.2.5 (Optional) Setting the OSPF Priority.......................................................................................................................272
5.2.6 (Optional) Restricting the Flooding of LSA Update Packets..................................................................................273
5.2.7 (Optional) Configuring the Maximum Number of Packet Retransmission Attempts.............................................274
5.2.8 (Optional) Setting an Interval at Which an LSA Packet Is Retransmitted to the Neighboring router....................275
5.2.9 (Optional) Configuring an Interface to Fill in a DD Packet with the Interface MTU.............................................275
5.3 Configuring OSPF on the NBMA or P2MP Network................................................................................................277
5.3.1 Before You Start......................................................................................................................................................277
5.3.2 Configuring Network Types for OSPF Interfaces...................................................................................................279
5.3.3 Configuring NBMA Network Attributes.................................................................................................................280
5.3.4 Configuring P2MP Network Attributes...................................................................................................................281
5.4 Configuring an OSPF Route Selection Rule..............................................................................................................285
5.4.1 Before You Start......................................................................................................................................................285
5.4.2 Setting the Interface Cost........................................................................................................................................286
Issue 02 (2014-09-30) Huawei Proprietary and Confidential x

5.4.3 Configuring Equal-Cost Routes...............................................................................................................................287

5.4.4 Configuring a Stub Router.......................................................................................................................................288
5.4.5 Suppressing an Interface from Receiving and Sending OSPF Packets...................................................................289
5.4.6 Configuring an OSPF Interface to Automatically Adjust the Link Cost.................................................................290
5.5 Controlling OSPF Routing Information.....................................................................................................................291
5.5.1 Before You Start......................................................................................................................................................292
5.5.2 Configuring OSPF to Import External Routes........................................................................................................292
5.5.3 Configuring OSPF to Import a Default Route.........................................................................................................295
5.5.4 Configuring Route Summarization..........................................................................................................................297
5.5.5 Configuring OSPF to Filter Routes Received by OSPF..........................................................................................298
5.5.6 Configuring the router to Filter LSAs to Be Sent....................................................................................................300
5.5.7 (Optional) Configuring OSPF to Filter LSAs in an Area........................................................................................303
5.5.8 (Optional) Enabling the Mesh-Group Function.......................................................................................................307
5.5.9 Setting the Maximum Number of External LSAs in the LSDB..............................................................................308
5.6 Configuring an OSPF Dynamic Hostname................................................................................................................309
5.7 Configuring an OSPF Stub Area................................................................................................................................311
5.8 Configuring an NSSA.................................................................................................................................................313
5.9 Configuring Local MT................................................................................................................................................316
5.10 Configuring BFD for OSPF......................................................................................................................................318
5.10.1 Before You Start....................................................................................................................................................318
5.10.2 Configuring BFD for OSPF in a Specified Process..............................................................................................319
5.10.3 Configuring BFD for OSPF on a Specified Interface............................................................................................321
5.11 Configuring OSPF IP FRR.......................................................................................................................................324
5.11.1 Before You Start....................................................................................................................................................324
5.11.2 Enabling OSPF IP FRR.........................................................................................................................................325
5.11.3 (Optional) Binding OSPF IP FRR and BFD.........................................................................................................326
5.11.4 (Optional) Disabling OSPF IP FRR on an Interface.............................................................................................327
5.12 Configuring OSPF GR..............................................................................................................................................328
5.12.1 Before You Start....................................................................................................................................................328
5.12.2 Enabling OSPF GR................................................................................................................................................329
5.12.3 (Optional) Configuring the GR Session Parameters on the Restarter...................................................................330
5.12.4 (Optional) Configuring GR Session Parameters on the Helper.............................................................................330
5.13 Improving Security of an OSPF Network................................................................................................................333
5.13.1 Before You Start....................................................................................................................................................333
5.13.2 Configuring the OSPF GTSM Functions..............................................................................................................334
5.13.3 Configuring the Authentication Mode...................................................................................................................335
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xi


5.14 Configuring the Network Management Function of OSPF......................................................................................338
5.14.1 Before You Start....................................................................................................................................................338
5.14.2 Configuring OSPF MIB Binding...........................................................................................................................338
5.14.3 Configuring OSPF Trap.........................................................................................................................................339
5.14.4 Configuring OSPF Log..........................................................................................................................................339
5.15 Maintaining OSPF....................................................................................................................................................340
5.15.1 Resetting OSPF......................................................................................................................................................340
5.15.2 Clearing OSPF.......................................................................................................................................................341
5.16.1 Example for Configuring Basic OSPF Functions..................................................................................................341
5.16.2 Example for Configuring OSPF Virtual Links......................................................................................................347
5.16.3 Example for Configuring DR Election of OSPF...................................................................................................350
5.16.4 Example for Configuring OSPF Load Balancing..................................................................................................355
5.16.5 Example for Configuring an OSPF Stub Area......................................................................................................360
5.16.6 Example for Configuring an OSPF NSSA............................................................................................................364
5.16.7 Example for Configuring Local OSPF MT...........................................................................................................370
5.16.8 Example for Configuring BFD for OSPF..............................................................................................................378
5.16.9 Example for Configuring OSPF IP FRR...............................................................................................................383
5.16.10 Example for Configuring OSPF GR....................................................................................................................386
5.16.11 Example for Configuring OSPF-BGP.................................................................................................................390
5.16.12 Example for Configuring OSPF GTSM..............................................................................................................399
6 OSPFv3 Configuration.............................................................................................................404
6.1 Introduction................................................................................................................................................................406
6.1.1 OSPFv3 Overview...................................................................................................................................................406
6.1.2 OSPFv3 Features Supported by NE80E/40E..........................................................................................................406
6.2 Configuring Basic OSPFv3 Functions.......................................................................................................................407
6.2.1 Before You Start......................................................................................................................................................407
6.2.2 Enabling OSPFv3....................................................................................................................................................407
6.2.3 Enabling OSPFv3 on an Interface...........................................................................................................................408
6.2.4 Entering the OSPFv3 Area View.............................................................................................................................409
6.3 Establishing or Maintaining OSPFv3 Neighbor Relationship....................................................................................410
6.3.1 Before You Start......................................................................................................................................................410
6.3.2 Configuring the Interval for Sending Hello Packets...............................................................................................411
6.3.3 Configuring Dead Time of Neighbor Relationship.................................................................................................412
6.3.4 Configuring the Interval for Retransmitting LSAs to Neighboring Routers...........................................................412
6.3.5 Configuring the Delay for Transmitting LSAs on the Interface..............................................................................413
6.4 Configuring OSPFv3 Areas........................................................................................................................................414
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xii

6.4.1 Before You Start......................................................................................................................................................414

6.4.2 Configuring OSPFv3 Stub Areas............................................................................................................................415
6.4.3 Configuring OSPFv3 Virtual Links.........................................................................................................................415
6.5 Configuring OSPFv3 NSSA Areas.............................................................................................................................417
6.5.1 Before You Start......................................................................................................................................................417
6.5.2 Defining the Current Area to Be an NSSA Area.....................................................................................................417
6.6 Configuring OSPFv3 Route Attributes.......................................................................................................................418
6.6.1 Before You Start......................................................................................................................................................419
6.6.2 Setting the Cost of the OSPFv3 Interface................................................................................................................419
6.6.3 Setting the Maximum Number of Equal-Cost Routes.............................................................................................420
6.7 Controlling OSPFv3 Routing Information.................................................................................................................421
6.7.1 Before You Start......................................................................................................................................................421
6.7.2 Configuring OSPFv3 Route Aggregation................................................................................................................422
6.7.3 Configuring OSPFv3 to Filter the Received Routes...............................................................................................423
6.7.4 Configuring OSPFv3 to Import External Routes....................................................................................................426
6.7.5 (Optional) Configuring OSPFv3 to Filter LSAs in an Area....................................................................................429
6.8 Optimizing an OSPFv3 Network................................................................................................................................434
6.8.1 Before You Start......................................................................................................................................................434
6.8.2 Configuring the SPF Timer.....................................................................................................................................435
6.8.3 Setting the Interval for Receiving LSAs..................................................................................................................436
6.8.4 Configuring an Intelligent Timer for Generating LSAs..........................................................................................436
6.8.5 Suppressing an Interface from Sending and Receiving OSPFv3 Packets...............................................................437
6.8.6 Configuring DR Priority of an Interface..................................................................................................................438
6.8.7 Configuring Stub Routers........................................................................................................................................439
6.8.8 Ignoring MTU Check on DD Packets.....................................................................................................................439
6.9 Configuration OSPFv3 GR.........................................................................................................................................440
6.9.1 Before You Start......................................................................................................................................................440
6.9.2 Enabling OSPFv3 GR..............................................................................................................................................441
6.9.3 Enabling the Helper of OSPFv3 GR........................................................................................................................441
6.10 Configuring BFD for OSPFv3..................................................................................................................................443
6.10.1 Before You Start....................................................................................................................................................444
6.10.2 Enabling BFD for OSPFv3....................................................................................................................................444
6.10.3 Configuring OSPFv3 BFD Parameters at Process Level......................................................................................445
6.10.4 Enabling OSPFv3 BFD at Interface Level............................................................................................................446
6.10.5 Configuring OSPFv3 BFD Parameters at Interface Level....................................................................................447
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiii


6.11 Configuring OSPFv3 IP FRR...................................................................................................................................448
6.11.1 Before You Start....................................................................................................................................................448
6.11.2 Enabling OSPFv3 IP FRR.....................................................................................................................................449
6.11.3 (Optional) Binding OSPFv3 IP FRR and BFD.....................................................................................................450
6.11.4 (Optional) Disabling OSPFv3 IP FRR on an Interface.........................................................................................451
6.12 Configuring OSPFv3 IPSec......................................................................................................................................453
6.12.1 Before You Start....................................................................................................................................................453
6.12.2 Enabling IPSec in an OSPFv3 Process..................................................................................................................454
6.12.3 Enabling IPSec in an OSPFv3 Area......................................................................................................................454
6.12.4 Enabling IPSec on an Interface.............................................................................................................................455
6.12.5 Enabling IPSec on the Virtual Link.......................................................................................................................455
6.12.6 Enabling IPSec on the Sham Link.........................................................................................................................456
6.13 Improving OSPFv3 Network Security.....................................................................................................................458
6.13.1 Before You Start....................................................................................................................................................459
6.13.2 Configuring OSPFv3 GTSM.................................................................................................................................460
6.13.3 Configuring an Authentication Mode....................................................................................................................460
6.14 Configuring the Network Management Function of OSPFv3..................................................................................463
6.14.1 Before You Start....................................................................................................................................................463
6.14.2 Configuring OSPFv3 MIB Binding.......................................................................................................................463
6.14.3 Configuring OSPFv3 Trap.....................................................................................................................................464
6.15 Maintaining OSPFv3................................................................................................................................................464
6.15.1 Resetting OSPFv3..................................................................................................................................................464
6.16.1 Example for Configuring OSPFv3 Areas..............................................................................................................465
6.16.2 Example for Configuring OSPFv3 DR Election...................................................................................................470
6.16.3 Example for Configuring OSPFv3 Virtual Links..................................................................................................475
6.16.4 Example for Configuring OSPFv3 GR..................................................................................................................479
6.16.5 Example for Configuring BFD for OSPFv3..........................................................................................................482
6.16.6 Example for Configuring IPSec for OSPFv3........................................................................................................487
7 IS-IS Configuration...................................................................................................................493
7.1 Introduction................................................................................................................................................................496
7.1.1 Basic Concepts of IS-IS...........................................................................................................................................496
7.1.2 IS-IS Features Supported by the NE80E/40E..........................................................................................................497
7.2 Configuring Basic IPv4 IS-IS Functions....................................................................................................................504
7.2.1 Before You Start......................................................................................................................................................504
7.2.2 Creating IPv4 IS-IS Processes.................................................................................................................................505
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiv

7.2.3 Configuring IPv4 IS-IS Interfaces...........................................................................................................................507

7.2.4 (Optional) Configuring the IPv4 IS-IS Interfaces...................................................................................................509
7.2.5 (Optional) Configuring IPv4 IS-IS Attributes for Interfaces on Different Types of Networks..............................512
7.3 Establishing or Maintaining IS-IS Neighbor Relationships or Adjacencies..............................................................517
7.3.1 Before You Start......................................................................................................................................................517
7.3.2 Configuring IS-IS Timers for Packets.....................................................................................................................517
7.3.3 Configuring LSP Parameters...................................................................................................................................520
7.4 Configuring IPv4 IS-IS Route Selection....................................................................................................................524
7.4.1 Before You Start......................................................................................................................................................524
7.4.2 Configuring IPv4 IS-IS Route Leaking...................................................................................................................525
7.4.3 Configuring Principles for Using Equal-Cost IPv4 IS-IS Routes...........................................................................529
7.4.4 Filtering IPv4 IS-IS Routes.....................................................................................................................................531
7.4.5 Configuring an Overload Bit for an IPv4 IS-IS Device..........................................................................................533
7.4.6 Configuring IS-IS to Generate IPv4 Default Routes...............................................................................................533
7.4.7 Configuring an IPv4 IS-IS Interface to Automatically Adjust the Link Cost.........................................................535
7.5 Configuring IPv4 IS-IS Route Summarization...........................................................................................................538
7.6 Configuring IPv4 IS-IS to Interact with Other Routing Protocols.............................................................................539
7.6.1 Before You Start......................................................................................................................................................539
7.6.2 Configuring a Preference Value for IPv4 IS-IS.......................................................................................................540
7.6.3 Configuring IPv4 IS-IS to Import External Routes.................................................................................................541
7.7 Configuring the IPv4 IS-IS Route Convergence Speed.............................................................................................547
7.7.1 Before You Start......................................................................................................................................................547
7.7.2 Configuring the Interval for Detecting IS-IS Neighboring Device Failures...........................................................548
7.7.3 Setting Flooding Parameters of SNPs and LSPs.....................................................................................................549
7.7.4 Setting the SPF Calculation Interval.......................................................................................................................553
7.7.5 Configuring Convergence Priorities for IPv4 IS-IS Routes....................................................................................554
7.8 Configuring Static BFD for IPv4 IS-IS......................................................................................................................557
7.9 Configuring Dynamic BFD for IPv4 IS-IS.................................................................................................................559
7.10 Configuring Multi-Topology for IPv4 IS-IS............................................................................................................562
7.10.1 Before You Start....................................................................................................................................................562
7.10.2 Enabling Multi-Topology for IPv4 IS-IS Processes..............................................................................................563
7.10.3 Enabling Multi-Topology for IPv4 IS-IS Interfaces..............................................................................................564
7.11 Configuring IPv4 IS-IS Auto FRR...........................................................................................................................567
7.11.1 Before You Start....................................................................................................................................................567
7.11.2 Enabling IPv4 IS-IS Auto FRR.............................................................................................................................568
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xv

7.11.3 (Optional) Disabling an Interface from Being Involved in IPv4 LFA Calculation...............................................569
7.12 Configuring Basic IPv6 IS-IS Functions..................................................................................................................571
7.12.1 Before You Start....................................................................................................................................................571
7.12.2 Creating IPv6 IS-IS Processes...............................................................................................................................572
7.12.3 Configuring IPv6 IS-IS Interfaces.........................................................................................................................574
7.12.4 (Optional) Configuring the IPv6 IS-IS Interfaces.................................................................................................575
7.12.5 (Optional) Configuring IPv6 IS-IS Attributes for Interfaces on Different Types of Networks............................578
7.13 Configuring IPv6 IS-IS Route Selection..................................................................................................................583
7.13.1 Before You Start....................................................................................................................................................583
7.13.2 Configuring IPv6 IS-IS Route Leaking.................................................................................................................584
7.13.3 Configuring Principles for Using Equal-Cost IPv6 IS-IS Routes.........................................................................589
7.13.4 Filtering IPv6 IS-IS Routes...................................................................................................................................590
7.13.5 Configuring an Overload Bit for an IPv6 IS-IS Device........................................................................................592
7.13.6 Configuring IS-IS to Generate IPv6 Default Routes.............................................................................................593
7.14 Configuring IPv6 IS-IS Route Summarization.........................................................................................................597
7.15 Configuring IPv6 IS-IS to Interact with Other Routing Protocols...........................................................................598
7.15.1 Before You Start....................................................................................................................................................598
7.15.2 Configuring a Preference Value for IPv6 IS-IS.....................................................................................................599
7.15.3 Configuring IPv6 IS-IS to Import External Routes...............................................................................................600
7.16 Configuring the IPv6 IS-IS Route Convergence Speed...........................................................................................606
7.16.1 Before You Start....................................................................................................................................................606
7.16.2 Configuring the Interval for Detecting IS-IS Neighboring Device Failures.........................................................607
7.16.3 Setting Flooding Parameters of SNPs and LSPs...................................................................................................609
7.16.4 Setting the SPF Calculation Interval.....................................................................................................................613
7.16.5 Configuring Convergence Priorities for IPv6 IS-IS Routes..................................................................................613
7.17 Configuring Dynamic BFD for IPv6 IS-IS...............................................................................................................616
7.18 Configuring Multi-Topology for IPv6 IS-IS............................................................................................................619
7.18.1 Before You Start....................................................................................................................................................619
7.18.2 Enabling Multi-Topology for IPv6 IS-IS Processes..............................................................................................620
7.18.3 Enabling Multi-Topology for IPv6 IS-IS Interfaces..............................................................................................621
7.19 Configuring IPv6 IS-IS Auto FRR...........................................................................................................................624
7.19.1 Before You Start....................................................................................................................................................624
7.19.2 Enabling IPv6 IS-IS Auto FRR.............................................................................................................................626
7.19.3 (Optional) Disabling an Interface from Participating in IPv6 LFA Calculation...................................................626
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvi

7.20 Configuring Local MT..............................................................................................................................................629

7.20.1 Before You Start....................................................................................................................................................629
7.20.2 Enabling Local MT................................................................................................................................................630
7.20.3 Controlling the Scale of the MIGP Routing Table................................................................................................630
7.21 Configuring IS-IS GR...............................................................................................................................................633
7.21.1 Before You Start....................................................................................................................................................633
7.21.2 Enabling IS-IS GR.................................................................................................................................................634
7.21.3 Configuring Parameters of an IS-IS GR Session...................................................................................................635
7.22 Improving Security of an IS-IS Network.................................................................................................................637
7.22.1 Before You Start....................................................................................................................................................637
7.22.2 Configuring IS-IS Authentication.........................................................................................................................638
7.22.3 Configuring the Optional Checksum.....................................................................................................................641
7.23 Maintaining IS-IS.....................................................................................................................................................643
7.23.1 Resetting IS-IS Data Structure..............................................................................................................................643
7.23.2 Resetting a Specific IS-IS Neighbor......................................................................................................................643
7.24.1 Example for Configuring Basic IS-IS Functions...................................................................................................644
7.24.2 Example for Configuring IS-IS in an NBMA Network........................................................................................649
7.24.3 Example for Configuring IS-IS Route Summarization.........................................................................................652
7.24.4 Example for Configuring the DIS Election of IS-IS.............................................................................................656
7.24.5 Example for Configuring IS-IS Load Balancing...................................................................................................661
7.24.6 Example for Configuring IS-IS to Interact with BGP...........................................................................................665
7.24.7 Example for Configuring IS-IS MT......................................................................................................................669
7.24.8 Example for Configuring Local MT......................................................................................................................675
7.24.9 Example for Configuring Basic IS-IS IPv6 Functions..........................................................................................682
7.24.10 Example for Configuring IS-IS Fast Convergence..............................................................................................688
7.24.11 Example for Configuring IS-IS Auto FRR (IP protecting IP).............................................................................691
7.24.12 Example for Configuring IS-IS Auto FRR (TE protecting IP)...........................................................................698
7.24.13 Example for Configuring IS-IS GR.....................................................................................................................714
7.24.14 Example for Configuring Static BFD for IS-IS...................................................................................................717
7.24.15 Example for Configuring Dynamic BFD for IS-IS.............................................................................................721
7.24.16 Example for Configuring Dynamic BFD for IPv6 IS-IS.....................................................................................727
8 BGP Configuration....................................................................................................................734
8.1 Introduction................................................................................................................................................................737
8.1.1 BGP Overview.........................................................................................................................................................737
8.1.2 BGP Features Supported by the NE80E/40E..........................................................................................................738
8.2 Configuring the Format of BGP 4-Byte AS Numbers...............................................................................................754
8.3 Configuring Basic BGP Functions.............................................................................................................................756
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvii

8.3.1 Before You Start......................................................................................................................................................756

8.3.2 Starting a BGP Process............................................................................................................................................757
8.3.3 Configuring BGP Peers...........................................................................................................................................757
8.3.4 Configuring BGP to Import Routes.........................................................................................................................759
8.4 Configuring BGP Route Attributes............................................................................................................................762
8.4.1 Before You Start......................................................................................................................................................762
8.4.2 Configuring the BGP Preference.............................................................................................................................763
8.4.3 Configuring Preferred Values for BGP Routes.......................................................................................................764
8.4.4 Configuring a Default Local_Pref Attribute for a Device.......................................................................................765
8.4.5 Configuring MED Attributes for BGP Routes........................................................................................................765
8.4.6 Configuring Next_Hop Attributes for Routes.........................................................................................................768
8.4.7 Configuring AS_Path Attributes for Routes............................................................................................................770
8.5 Configuring BGP to Advertise Routes.......................................................................................................................775
8.5.1 Before You Start......................................................................................................................................................775
8.5.2 Configuring BGP Filters..........................................................................................................................................776
8.5.3 Configuring to Controll the Advertisement of BGP Routing Information..............................................................781
8.5.4 Configuring BGP Soft Reset...................................................................................................................................786
8.6 Configuring BGP to Receive Routes..........................................................................................................................789
8.6.1 Before You Start......................................................................................................................................................789
8.6.2 Configuring BGP Filters..........................................................................................................................................790
8.6.3 Configuring to Controll the Acceptment of BGP Routing Information..................................................................795
8.6.4 Configuring BGP Soft Reset...................................................................................................................................801
8.7 Configuring a Device to Advertise BGP Supernet Unicast Routes to BGP Peers.....................................................804
8.8 Configuring BGP Route Aggregation........................................................................................................................806
8.9 Configuring BGP Peer Groups...................................................................................................................................808
8.9.1 Before You Start......................................................................................................................................................808
8.9.2 Creating IBGP Peer Groups....................................................................................................................................809
8.9.3 Creating Pure EBGP Peer Groups...........................................................................................................................809
8.9.4 Creating Mixed EBGP Peer Groups........................................................................................................................810
8.10 Configuring BGP Route Reflectors..........................................................................................................................812
8.10.1 Before You Start....................................................................................................................................................812
8.10.2 Configuring a Route Reflector and Specifying Clients.........................................................................................813
8.10.3 (Optional) Disabling Route Reflection Between Clients......................................................................................814
8.10.4 (Optional) Configuring the Cluster ID for a Route Reflector................................................................................814
8.10.5 (Optional) Preventing BGP Routes from Being Added into the IP Routing Table...............................................816
8.10.6 (Optional) Enabling the RR to Modify the Route Attributes Using the Export Policy.........................................817
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xviii


8.11 Configuring a BGP Confederation...........................................................................................................................819
8.12 Configuring BGP Community Attributes.................................................................................................................821
8.12.1 Before You Start....................................................................................................................................................821
8.12.2 Configuring Community Attribute-Related Routing Policies...............................................................................822
8.12.3 Configuring a BGP Device to Send Community Attributes to Its Peer................................................................823
8.13 Configuring Prefix-based BGP ORF........................................................................................................................824
8.14 Configuring to Adjust the BGP Network Convergence Speed................................................................................827
8.14.1 Before You Start....................................................................................................................................................828
8.14.2 Configuring a BGP ConnectRetry Timer..............................................................................................................829
8.14.3 Configuring BGP Keepalive and Hold Timers......................................................................................................830
8.14.4 Configuring a MinRouteAdvertisementIntervalTimer..........................................................................................833
8.14.5 Configuring the Rate at which BGP Updates Routes in Response to Non-critical Iteration Changes..................834
8.14.6 Disabling Fast Reset of EBGP Connections..........................................................................................................835
8.14.7 Enabling BGP Peer Tracking................................................................................................................................836
8.15 Configuring BGP Route Dampening........................................................................................................................838
8.16 Configuring a BGP Device to Send a Default Route to Its Peer..............................................................................840
8.17 Configuring BGP Load Balancing...........................................................................................................................843
8.18 Configuring Path MTU Auto Discovery..................................................................................................................849
8.19 Configuring the BGP Next Hop Delayed Response.................................................................................................852
8.20 Configuring BFD for BGP.......................................................................................................................................854
8.21 Configuring BGP Auto FRR....................................................................................................................................857
8.22 Configuring BGP GR...............................................................................................................................................860
8.22.1 Before You Start....................................................................................................................................................860
8.22.2 Enabling BGP GR.................................................................................................................................................861
8.22.3 Configuring Parameters for a BGP GR Session....................................................................................................862
8.23 Configuring BGP Security........................................................................................................................................864
8.23.1 Before You Start....................................................................................................................................................864
8.23.2 Configuring MD5 Authentication.........................................................................................................................865
8.23.3 Configuring Keychain Authentication...................................................................................................................866
8.23.4 Configuring BGP GTSM.......................................................................................................................................867
8.24 Disabling the BGP-IPv4 Unicast Address Family...................................................................................................871
8.25 Applying BGP AS_Path Regular Expressions.........................................................................................................872
8.26 Maintaining BGP......................................................................................................................................................883
8.26.1 Configuring BGP to Record Peer Status Changes and Event Information...........................................................883
8.26.2 Resetting BGP Connections..................................................................................................................................884
8.26.3 Clearing BGP Information.....................................................................................................................................885
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xix

8.27 BGP Route Selection Rules......................................................................................................................................886

8.27.1 Route Processing on the BGP router.....................................................................................................................886
8.27.2 BGP Route Selection Rules...................................................................................................................................887
8.27.3 BGP Routing Table...............................................................................................................................................891
8.27.4 Route Attributes.....................................................................................................................................................896
8.28.1 Example for Configuring Basic BGP Functions...................................................................................................959
8.28.2 Example for Configuring BGP to Interact with an IGP........................................................................................965
8.28.3 Example for Configuring AS_Path Filters............................................................................................................969
8.28.4 Example for Configuring MED Attributes to Control BGP Route Selection.......................................................974
8.28.5 Example for Configuring BGP Routing Policies..................................................................................................978
8.28.6 Example for Configuring BGP Route Reflectors..................................................................................................996
8.28.7 Example for Configuring BGP Confederations...................................................................................................1001
8.28.8 Example for Configuring BGP Community Attributes for Routes.....................................................................1007
8.28.9 Example for Configuring Prefix-based BGP ORF..............................................................................................1011
8.28.10 Example for Configuring BGP Load Balancing................................................................................................1019
8.28.11 Example for Configuring BFD for BGP............................................................................................................1024
8.28.12 Example for Configuring BGP Auto FRR........................................................................................................1030
8.28.13 Example for Configuring BGP GTSM..............................................................................................................1035
9 BGP4+ Configuration.............................................................................................................1045
9.1 Introduction..............................................................................................................................................................1047
9.1.1 BGP4+ Overview..................................................................................................................................................1047
9.1.2 BGP4+ Features Supported by the NE80E/40E....................................................................................................1047
9.2 Configuring Basic BGP4+ Functions.......................................................................................................................1048
9.2.1 Before You Start....................................................................................................................................................1048
9.2.2 Starting a BGP Process..........................................................................................................................................1048
9.2.3 Configuring an IPv6 Peer......................................................................................................................................1049
9.2.4 (Optional) Configuring the Local Interfaces Used for BGP4+ Connections........................................................1051
9.3 Configuring BGP4+ Route Attributes......................................................................................................................1052
9.3.1 Before You Start....................................................................................................................................................1052
9.3.2 Configuring the BGP4+ Preference.......................................................................................................................1054
9.3.3 Configuring BGP4+ Preferred Value for Routing Information.............................................................................1054
9.3.4 Configuring the Default Local_Pref Attribute of the Local Router......................................................................1055
9.3.5 Configuring the MED Attribute............................................................................................................................1055
9.3.6 Configuring the Next_Hop Attribute.....................................................................................................................1056
9.3.7 Configuring the AS_Path Attribute.......................................................................................................................1057
9.3.8 Configuring the BGP4+ Community Attribute.....................................................................................................1059
9.4 Controlling the Advertising and Receiving of BGP4+ Routing Information...........................................................1061
9.4.1 Before You Start....................................................................................................................................................1061
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xx

9.4.2 Configuring BGP4+ to Advertise Local IPv6 Routes...........................................................................................1062

9.4.3 Configuring BGP4+ Route Aggregation...............................................................................................................1063
9.4.4 Configuring BGP4+ to Import and Filter External Routes....................................................................................1063
9.4.5 Configuring Routers to Advertise a Default Route to a Peer................................................................................1064
9.4.6 Configuring the Policy for Advertising BGP4+ Routing Information..................................................................1065
9.4.7 Configuring the Policy for Receiving BGP4+ Routing Information.....................................................................1068
9.4.8 Configuring BGP4+ Soft Resetting.......................................................................................................................1070
9.5 Configuring Parameters of a Connection Between BGP4+ Peers............................................................................1072
9.5.1 Before You Start....................................................................................................................................................1072
9.5.2 Configuring BGP4+ Timers..................................................................................................................................1073
9.5.3 Configuring the Interval for Sending Update Packets...........................................................................................1075
9.5.4 Setting the BGP4+ ConnectRetry Interval............................................................................................................1075
9.5.5 Configuring the Rate at which BGP4+ Updates Routes in Response to Non-critical Iteration Changes.............1076
9.6 Configuring BFD for BGP4+...................................................................................................................................1079
9.6.1 Before You Start....................................................................................................................................................1079
9.6.2 Configuring BFD for BGP4+ in the Public Network Instance..............................................................................1080
9.6.3 Configuring BFD for BGP4+ in a Private Network..............................................................................................1082
9.7 Configuring BGP4+ PeerTracking...........................................................................................................................1084
9.7.1 Before You Start....................................................................................................................................................1084
9.7.2 Enabling BGP4+ Peer Tracking............................................................................................................................1085
9.8 Configuring BGP4+ Route Dampening...................................................................................................................1086
9.8.1 Before You Start....................................................................................................................................................1086
9.8.2 Enabling BGP4+ Route Dampening......................................................................................................................1087
9.9 Configuring BGP4+ Load Balancing.......................................................................................................................1088
9.10 Configuring a BGP4+ Peer Group..........................................................................................................................1092
9.10.1 Before You Start..................................................................................................................................................1093
9.10.2 Creating an IBGP Peer Group.............................................................................................................................1093
9.10.3 Creating a Pure EBGP Peer Group......................................................................................................................1094
9.10.4 Creating a Mixed EBGP Peer Group...................................................................................................................1095
9.10.5 Checking the Configurations...............................................................................................................................1096
9.11 Configuring a BGP4+ Route Reflector..................................................................................................................1096
9.11.1 Before You Start..................................................................................................................................................1096
9.11.2 Configuring a Route Reflector and Specifying Clients.......................................................................................1097
9.11.3 (Optional) Disabling a Route Reflection Between Clients..................................................................................1097
9.11.4 (Optional) Configuring the Cluster ID for a Route Reflector..............................................................................1098
9.11.5 (Optional) Preventing BGP4+ Routes from Being Added into the IPv6 Routing Table....................................1098
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xxi

9.11.6 (Optional) Enabling the RR to Modify the Route Attributes Using the Export Policy.......................................1099
9.12 Configuring a BGP4+ Confederation.....................................................................................................................1101
9.12.1 Before You Start..................................................................................................................................................1101
9.12.2 Configuring a BGP4+ Confederation Attribute...................................................................................................1101
9.13 Configuring BGP4+ 6PE........................................................................................................................................1103
9.13.1 Before You Start..................................................................................................................................................1103
9.13.2 Configuring a 6PE Peer.......................................................................................................................................1104
9.13.3 (Optional) Enabling 6PE Routes Sharing the Explicit Null Label......................................................................1104
9.14 Configuring Inter-AS 6PE......................................................................................................................................1106
9.14.1 Before You Start..................................................................................................................................................1106
9.14.2 Configuring Inter-AS 6PE OptionB (with ASBRs as PEs).................................................................................1107
9.14.3 Configuring Inter-AS 6PE OptionB....................................................................................................................1108
9.14.4 Configuring Inter-AS 6PE OptionC....................................................................................................................1110
9.15 Configuring BGP4+ 6PE FRR...............................................................................................................................1113
9.15.1 Before You Start..................................................................................................................................................1113
9.15.2 Configuring BGP4+ 6PE Peers...........................................................................................................................1114
9.15.3 Enabling 6PE FRR...............................................................................................................................................1114
9.16 Configuring BGP4+ Security.................................................................................................................................1116
9.16.1 Before You Start..................................................................................................................................................1116
9.16.2 Configuring MD5 Authentication.......................................................................................................................1117
9.16.3 Configuring Keychain Authentication.................................................................................................................1118
9.16.4 Configuring Basic BGP4+ GTSM Functions......................................................................................................1119
9.17 Maintaining BGP4+................................................................................................................................................1120
9.17.1 Resetting BGP4+ Connections............................................................................................................................1120
9.17.2 Clearing BGP4+ Statistics...................................................................................................................................1121
9.18 Configuration Examples.........................................................................................................................................1122
9.18.1 Example for Configuring Basic BGP4+ Functions.............................................................................................1122
9.18.2 Example for Configuring a BGP4+ Route Reflection.........................................................................................1127
9.18.3 Example for Configuring BFD for BGP4+.........................................................................................................1132
9.18.4 Example for Configuring BGP4+ 6PE................................................................................................................1137
9.18.5 Example for Configuring Inter-AS 6PE OptionB (with ASBRs as PEs)............................................................1144
9.18.6 Example for Configuring Inter-AS 6PE OptionB...............................................................................................1151
9.18.7 Example for Configuring Inter-AS 6PE OptionC (Solution 1)...........................................................................1161
9.18.8 Example for Configuring Inter-AS 6PE OptionC (Solution 2)...........................................................................1173
9.18.9 Example for Configuring BGP4+ 6PE FRR........................................................................................................1184
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xxii

10 Routing Policy Configuration.............................................................................................1193

10.1 Introduction............................................................................................................................................................1194
10.1.1 Overview of the Routing Policy..........................................................................................................................1194
10.1.2 Routing Policy Features Supported by the NE80E/40E......................................................................................1195
10.2 Configuring the IP-Prefix List................................................................................................................................1196
10.2.1 Before You Start..................................................................................................................................................1197
10.2.2 Configuring an IPv4 Prefix List..........................................................................................................................1197
10.2.3 Configuring an IPv6 Prefix List..........................................................................................................................1198
10.3 Configuring the Route-Policy.................................................................................................................................1200
10.3.1 Before You Start..................................................................................................................................................1200
10.3.2 Creating a Route-Policy.......................................................................................................................................1201
10.3.3 (Optional) Configuring the If-Match Clause.......................................................................................................1201
10.3.4 (Optional) Configuring the Apply Clause...........................................................................................................1204
10.3.5 Applying a Route-Policy.....................................................................................................................................1206
10.4 Applying Filters to Received Routes......................................................................................................................1221
10.4.1 Before You Start..................................................................................................................................................1221
10.4.2 Filtering Routes Received by RIP.......................................................................................................................1223
10.4.3 Filtering Routes Received by OSPF....................................................................................................................1225
10.4.4 Filtering Routes Received by IS-IS.....................................................................................................................1226
10.4.5 Filtering Routes Received by BGP......................................................................................................................1228
10.5 Applying Filters to Advertised Routes...................................................................................................................1233
10.5.1 Before You Start..................................................................................................................................................1233
10.5.2 Filtering Routes Advertised by RIP.....................................................................................................................1234
10.5.3 Filtering Routes Advertised by OSPF.................................................................................................................1236
10.5.4 Filtering Routes Advertised by IS-IS..................................................................................................................1238
10.5.5 Filtering Routes Advertised by BGP...................................................................................................................1240
10.6 Applying Filters to Imported Routes......................................................................................................................1245
10.6.1 Before You Start..................................................................................................................................................1246
10.6.2 Applying Route-Policy to Routes Imported by RIP............................................................................................1246
10.6.3 Applying Route-Policy to Routes Imported by OSPF.........................................................................................1247
10.6.4 Applying Route-Policy to Routes Imported by IS-IS..........................................................................................1247
10.6.5 Applying Route-Policy to Routes Imported by BGP..........................................................................................1248
10.7 Controlling the Valid Time of the Routing policy.................................................................................................1249
10.7.1 Before You Start..................................................................................................................................................1249
10.7.2 Configuring the Delay for Applying the Routing Policy....................................................................................1250
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xxiii

10.8 Maintaining the Routing Policy..............................................................................................................................1251

10.9 Configuration Examples.........................................................................................................................................1251
10.9.1 Example for Filtering Received and Advertised Routes.....................................................................................1252
10.9.2 Example for Applying the Routing Policy When Importing Routes...................................................................1257
11 Route Monitoring Group Configuration..........................................................................1262

11.1 Overview................................................................................................................................................................1263
11.1.1 Introduction.........................................................................................................................................................1263
11.1.2 Route Monitoring Group Features Supported by the NE80E/40E......................................................................1263
11.2 Configuring a Route Monitoring Group.................................................................................................................1264
A Glossary....................................................................................................................................1268
B Acronyms and Abbreviations...............................................................................................1272
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xxiv

Configuration Guide - IP Routing 1 IP Routing Basic Configuration
1 IP Routing Basic Configuration
About This Chapter
This chapter describes IP routing, which functions as the basis for data communication networks.
1.1 Routing Management
To forward data, routers need to establish and refresh routing tables and forward packets
according to the information in routing tables.
1.2 Configuring IPv4 Multi-Topology
By configuring multi-topology on an IPv4 network, you can properly allocate network resources.
1.4 Configuring Public Network IP FRR
Public network IP FRR is applicable to the services that are sensitive to packet loss and delay
on the public network.
1.5 Configuring Public Network IPv6 FRR
Public network IPv6 FRR is applicable to the services that are very sensitive to packet loss and
delay on the public network.
1.6 Configuring VRRP for Direct Routes
If VRRP for direct routes is configured on a master device of an IPv4 network, the master device
effectively diagnoses a link fault, improving the security of the IPv4 network.
1.7 Configuring an IPv4 Direct Route to Respond to L3VE Interface Status Changes After a
Delay
This section describes how to configure an IPv4 direct route to respond to Layer 3 Virtual
Ethernet (L3VE) interface status changes after a delay. During traffic switchback after an L3VE
interface recovers, this configuration can reduce traffic loss and improve network reliability.
1.8 Configuring an IPv6 Direct Route to Respond to L3VE Interface Status Changes After a
Delay
1.9 Configuring the Association Between the IPv4 Direct Route and PW Status
Issue 02 (2014-09-30) Huawei Proprietary and Confidential 1

This section describes how to configure the association between the IPv4 direct route and pseudo
wire (PW) status. During traffic switchback after the primary PW recovers, this configuration
can reduce traffic loss and improve network reliability.
1.10 Configuring the Association Between the IPv6 Direct Route and PW Status
1.11 Configuring the Association Between the IPv4 Direct Routes and IPSec Instance Status
The association between IPv4 direct routes and IP security (IPSec) instance status ensures that
data encrypted using IPSec can be transmitted to the correct radio network controller site gateway
(RSG).
1.12 Configuring a Device to Deactivate the IPv4 Network Segment Route That Corresponds
to an L3VE Sub-interface
To prevent a device from generating black-hole routes and ensure that local cell site gateways
(CSGs) can communicate, configure the device to deactivate the IPv4 network segment route
that corresponds to the Layer 3 virtual Ethernet (L3VE) sub-interface of the secondary pseudo
wire (PW).
1.13 Configuring a Device to Deactivate the IPv6 Network Segment Route That Corresponds
to an L3VE Sub-interface
wire (PW).
1.14 Configuring AGGs to Load-Balance RNC-to-CSG Traffic

This section describes how to configure access aggregation gateways (AGGs) to load-balance
radio network controller (RNC)-to-cell site gateway (CSG) traffic. The load balancing
configuration can improve network resource usage and reliability.
1.15 Configuring the Advertisement of IPv4 ARP Vlink Direct Routes on the Public Network
Advertising IPv4 ARP Vlink direct routes on the public network allows precise control of data
traffic.
1.16 Configuring the Advertisement of IPv6 NDP Vlink Direct Routes on the Public Network
On an IPv6 public network, advertising IPv6 neighbor discover protocol (NDP) Vlink direct
routes allows precise control of data traffic.
1.17 Maintaining the Route Management Module

The operations of Route Management (RM) maintenance include configuring thresholds for the
number of route prefixes on a device and configuring a limit on the number of public route
prefixes.
1.18 Configuration Example

IP routing configuration examples provide networking requirements, networking diagrams,
configuration notes, configuration roadmap, and configuration procedures.

1.1 Routing Management

To forward data, routers need to establish and refresh routing tables and forward packets
according to the information in routing tables.
1.1.1 Displaying of the Routing Table

Routing tables are one of the best sources of information about a network. Checking these tables
helps you locate faults.
Prerequisites
The following lists common commands for displaying information about the routing table.
Note that display commands can be run in all views.
Procedure
l For IPv4 routing table:
– Run the display ip routing-table command to check brief information about current
active routes.
– Run the display ip routing-table verbose command to check detailed information
about the IP routing table.
– Run the display ip routing-table ip-address [ mask | mask-length ] [ longer-match ]
[ verbose ] command to check the routes to a specified destination address.
– Run the display ip routing-table ip-address1 { mask1 | mask-length1 } ip-address2
{ mask2 | mask-length2 } [ verbose ] command to check the routes whose destination
addresses are within a specified address range.
– Run the display ip routing-table acl { acl-number | acl-name } [ verbose ] command
to check the routes filtered by a specified basic ACL.
– Run the display ip routing-table ip-prefix ip-prefix-name [ verbose ] command to
check the routes filtered by a specified IP prefix list.
– Run the display ip routing-table protocol protocol [ inactive | verbose ] command to
check the routes discovered by a specified protocol.
– Run the display ip routing-table statistics command to check statistics about the IP
routing table.
– Run the display ip routing-table vpn-instance vpn-instance-name command to check
brief information about the VPN routing table.
– Run the display ip routing-table vpn-instance vpn-instance-name verbose command
to check detailed information about the VPN routing table.
l For IPv6 routing table:
– Run the display ipv6 routing-table command to check brief information about current
active routes.
– Run the display ipv6 routing-table verbose command to check detailed information
about the IPv6 routing table.

– Run the display ipv6 routing-table ipv6-address [ prefix-length ] [ longer-match ]

[ verbose ] command to check the IPv6 routes to a specified destination address.
– Run the display ipv6 routing-table ipv6-address1 [ prefix-length1 ] ipv6-address2
prefix-length2 [ verbose ] command to check the routes whose destination addresses
are within a specified address range.
– Run the display ipv6 routing-table acl { acl6-number | acl6-name } [ verbose ]
command to check the IPv6 routes filtered by a specified basic ACL.
– Run the display ipv6 routing-table ipv6-prefix ipv6-prefix-name [ verbose ] command
to check the IPv6 routes filtered by a specified IPv6 prefix list.
– Run the display ipv6 routing-table protocol protocol [ inactive | verbose ] command
to check the routes discovered by a specified protocol.
– Run the display ipv6 routing-table statistics command to check statistics about the IP
routing table.
– Run the display ipv6 routing-table vpn-instance vpn-instance-name command to
check brief information about the IPv6 VPN routing table.
– Run the display ipv6 routing-table vpn-instance vpn-instance-name verbose
command to check detailed information about the IPv6 VPN routing table.
----End
1.1.2 Displaying of the Routing Management Module

You can use display commands of the routing management (RM) module to locate routing
problems.
Context
The display commands can be run in all views.
Procedure
l Run the display rm interface [ interface-type interface-number ] command to check RM
information about a specified interface.
l Run the display rm ipv6 interface [ interface-type interface-number ] command to check
IPv6 RM information about a specified interface.
l Run the display rm interface vpn-instance vpn-instance-name command to check RM
information about the private network interface.
l Run the display rm ipv6 interface vpn-instance vpn-instance-name command to check
IPv6 RM information about the private network interface.
----End
1.1.3 FRR Principle

FRR is a technique that allows the physical layer or data link layer to report a fault (if any) to
the upper layer routing system so that packets are forwarded over a backup link.

Context
On traditional IP networks, after a forwarding device such as the router detects a fault on the
lower layer link, it takes the routing system several seconds to complete route convergence (to
re-select an available route).
A second-level convergence may interrupt the services that are extremely sensitive to packet
loss and delay. For example, Voice over IP (VoIP) service can tolerate a maximum of 50 ms of
network interruption.
Therefore, to prevent services from being seriously affected by link faults, the forwarding system
must be able to detect and rectify faults and restore the affected services immediately.
Fast Reroute (FRR) is applicable to the services that are sensitive to packet loss and delay. After
FRR is configured, when a fault is detected at the lower layer (physical layer or link layer), the
fault is reported to the upper layer routing system. Meanwhile, packets are forwarded over a
backup link. Therefore, the impact of link faults on services is minimized.
According to the application scope, FRR is classified into IP FRR and VPN FRR. IP FRR can
be further classified into public network IP FRR and VPN IP FRR.
l Public network IP FRR: protects routers on the public network.

l VPN IP FRR: protects Customer Edges (CEs).
l VPN FRR: protects Provider Edges (PEs).
For detailed introduction of FRR, see the HUAWEI NetEngine80E/40E Router Feature
Description- IP Route.
For detailed configuration of VPN IP FRR and VPN FRR, see the HUAWEI NetEngine80E/
40E Router Configuration Guide - VPN.
FRR can provide backup for direct, static, and dynamic routes (including OSPF, IS-IS, and BGP
routes) of NE80E/40Es.

1.2.1 Before You Start

Before configuring IPv4 multi-topology, familiarize yourself with the usage scenario, complete
the pre-configuration tasks, and obtain the required data. This can help you complete the
configuration task quickly and accurately.
Applicable Environment
On a traditional IP network, only one unicast topology exists, and only one unicast forwarding
table exists on the forwarding plane. Services to the same destination IPv4 address share the
same per-hop forwarding behavior. This means that various end-to-end services (for example,
voice and data services) share the same physical link. Some links may be heavily congested
while other links are relatively idle. A solution to this problem is to divide a physical network
into different logical topologies for different services. Such a solution is called multi-topology.

As shown in Figure 1-1, multi-topology is configured on the network; the base topology includes
all devices on the network; other topology instances (such as the green topology, red topology,
and blue topology) just include some devices because they bear their respective services. By
deploying services (for example, voice and data services) in different topology instances as
required, you can isolate network resources on a network.
Figure 1-1 Networking diagram of multi-topology
base topology
green topology
red topology
blue topology
Pre-configuration Tasks
None.
Data Preparation
To configure IPv4 multi-topology, you need the following data.
No. Data
1 Name of the IPv4 topology instance
1.2.2 Creating an IPv4 Topology Instance

By configuring IPv4 topology instances, you can properly use network resources.

Context
Before configuring multi-topology on an IPv4 network, you need to create an IPv4 topology
instance.
Each topology instance is a subset of the base topology instance. Each topology instance bears
a type of services and maintains its own routing table and forwarding table.
Perform the following steps on the device where an IPv4 topology instance needs to be created:
Procedure
Step 1 Run:
system-view
The system view is displayed.
Step 2 Run:
ip topology topology-name
An IPv4 topology instance is created, and the topology view is displayed.
By default, there are only base topology instances in the system.
Generally, "base" is the name of a base topology instance, and "multicast" is the name of a
multicast topology instance. A maximum of 32 IPv4 topology instances (including 1 base
topology instance, 1 multicast topology instance, and 30 unicast topology instances) can be
created.
Step 3 (Optional) Run:

routing-table limit number { alert-percent | simply-alert }
You can set the maximum number of routes supported by a specified topology instance to prevent
a device from importing too many routes.
By default, the maximum number of routes supported by a topology instance is not set.
When a large number of routes exist on a device but only some important routes need to be
imported for a topology instance, you are recommended to run the routing-table limit command
to set the maximum number of routes supported by the topology instance.
----End
1.2.3 Binding an Interface to an IPv4 Topology Instance

To add direct routes of an interface to an IPv4 topology instance, you need to bind the interface
to the IPv4 topology instance.
Context
instance. To add direct routes or IS-IS routes of an interface to the topology instance, you need
to bind the interface to the topology instance.
Perform the following steps on the interface where an IPv4 topology instance needs to be bound:

Procedure
Step 1 Run:
system-view
Step 2 Run:
interface interface-type interface-name
The interface view is displayed.
Step 3 Run:
ip topology topology-name enable
Multi-topology is configured in the specified interface view, and the specified interface is bound
to the specified topology instance.
By default, the interface is bound to the base topology instance only.
An interface can be bound to multiple topology instances, and multiple interfaces can be bound
to the same topology instance.
----End
1.2.4 Checking the Configurations

After IPv4 multi-topology is configured, you can check information about the created topology
instance.
Prerequisites
IPv4 multi-topology has been configured.
Procedure
l Run the display ip topology [ topology-name ] [ verbose ] command to check IPv4 multi-
topology information.
l Run the display ip routing-table topology topology-name [ verbose ] command to check
the routing table of IPv4 multi-topology.
----End
Example
Run the display ip topology topology-name verbose command after configuring IPv4 multi-
topology. If the following is displayed, it means that the configuration succeeds.
<HUAWEI> display ip topology red verbose
Topology Name : red
Topology ID : 0x0100
Maximum Routes Limit : 1000
Threshold Routes Limit : 50%
Interface:
GigabitEthernet1/0/0



Before configuring IPv6 multi-topology, familiarize yourself with the usage scenario, complete
On a traditional IP network, only one unicast topology exists, and only one unicast forwarding
table exists on the forwarding plane. Services to the same destination IPv6 address share the
same per-hop forwarding behavior. This means that various end-to-end services (for example,
voice and data services) share the same physical link. Some links may be heavily congested
while other links are relatively idle. A solution to this problem is to divide a physical network
into different logical topologies for different services. Such a solution is called multi-topology.
As shown in Figure 1-2, multi-topology is configured on the network; the base topology includes
all devices on the network; other topology instances (such as the green topology, red topology,
and blue topology) just include some devices because they bear their respective services. By
deploying services (for example, voice and data services) in different topology instances as
required, you can isolate network resources on a network.
Figure 1-2 Networking of multi-topology
base topology
green topology
red topology
blue topology

None.
Data Preparation
To configure IPv6 multi-topology, you need the following data.
No. Data
1 Name of the IPv6 topology instance
1.3.2 Creating an IPv6 Topology Instance

By configuring IPv6 topology instances, you can properly use network resources.
Context
instance.
Each topology instance is a subset of the base topology instance. Each topology instance bears
a type of services and maintains its own routing table and forwarding table.
Perform the following steps on the device where an IPv6 topology instance needs to be created:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 topology topology-name
An IPv6 topology instance is created, and the IPv6 topology view is displayed.
By default, there are only base topology instances in the system.
Generally, "base" is the name of a base topology instance, and "multicast" is the name of a
multicast topology instance. A maximum of 32 IPv6 topology instances (including 1 base
topology instance, 1 multicast topology instance, and 30 unicast topology instances) can be
created.

routing-table limit number { alert-percent | simply-alert }
The maximum number of routes supported by a specified IPv6 topology instance is set.
By default, the maximum number of routes supported by a topology instance is not set.

When a large number of routes exist on a device but only some important routes need to be
imported for a topology instance, you are recommended to run the routing-table limit command
to set the maximum number of routes supported by the topology instance.
----End
1.3.3 Binding an Interface to an IPv6 Topology Instance

To add direct routes of an interface to an IPv6 topology instance, you need to bind the interface
to the IPv6 topology instance.
Context
instance. To add direct routes or IS-IS routes of an interface to the topology instance, you need
to bind the interface to the topology instance.
Perform the following steps on the interface where an IPv6 topology instance needs to be bound:
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface interface-type interface-name
Step 3 Run:
ipv6 topology topology-name enable
Multi-topology is configured in the specified interface view, and the specified interface is bound
to the specified topology instance.
By default, the interface is bound to the base topology instance only.
An interface can be bound to multiple topology instances, and multiple interfaces can be bound
to the same topology instance.
----End

After IPv6 multi-topology is configured, you can check information about the created topology
instance.
Prerequisites
IPv6 multi-topology has been configured.

Procedure
l Run the display ipv6 topology [ topology-name ] [ verbose ] command to check IPv6
multi-topology information.
l Run the display ipv6 routing-table topology topology-name [ verbose ] command to
check the routing table of IPv6 multi-topology.
----End
Example
Run the display ipv6 topology topology-name verbose command after configuring IPv6 multi-
topology. If the following is displayed, it means that the configuration succeeds.
<HUAWEI> display ipv6 topology red verbose
Topology Name : red
Topology ID : 0x0100
Maximum Routes Limit : 1000
Threshold Routes Limit : 50%
Interface:
1.4 Configuring Public Network IP FRR

Public network IP FRR is applicable to the services that are sensitive to packet loss and delay

Before configuring public network IP FRR, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the data required for the configuration.
Public network IP Fast Reroute (FRR) is applicable to the services that are sensitive to packet
loss and delay on the public network.
Before configuring public network IP FRR, complete the following tasks:
l Configure a static route or an IGP to ensure that nodes are reachable.

l Set different costs to generate two routes.
Data Preparation
To configure public network IP FRR, you need the following data.
No. Data
1 Name of the route-policy and the number of the node
2 Outbound interface of the backup route

No. Data
3 Next hop of the backup route
1.4.2 Configuring a Route-Policy

When configuring public network IP FRR, you can use a route-policy to correctly establish the
backup relationship between routes.
Context
Perform the following steps on the router to which public network IP FRR is applied:
Procedure
Step 1 Run:
system-view
Step 2 Run:
route-policy route-policy-name { permit | deny } node node
The node of the route-policy is created and the route-policy view is displayed.

if-match
The matching condition is set to filter the routes to be backed up.
You can use the if-match command according to the description in (Optional) Configuring
the If-Match Clause.
If the matching condition is not set, IP FRR backs up outbound interfaces and next hops for all
routes in the routing table. In this manner, certain routes that do not need to be backed up are
also configured with backup information. Therefore, you need to correctly set the relationship
between routes to be backed up and backup routes. Using the matching condition to specify the
routes to be backed up is recommended.
Step 4 Run:
apply backup-interface interface-type interface-number
The backup outbound interface is specified.
Step 5 Run:
apply backup-nexthop ip-address
The backup next hop is specified.

NOTE
l If a backup next hop is specified, a backup outbound interface also needs to be specified.
l If a backup outbound interface is specified on a Point-to-Point (P2P) link, no backup next hop needs
to be specified.
l If a backup outbound interface is specified on a non-P2P link, a backup next hop also needs to be
specified.
----End
1.4.3 Enabling Public Network IP FRR

After IP FRR is configured on the public network, service traffic can be switched to the backup
link immediately after the primary link fails. This ensures the normal transmission of service
traffic.
Context
Perform the following steps on the router to which public network IP FRR is applied:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip frr route-policy route-policy-name
IP FRR is enabled.
Before applying IP FRR, use this command to enable IP FRR. In this manner, the route-policy
used to specify backup outbound interfaces and backup next hops can take effect.
Only one route-policy can be applied at a time. If the ip frr command is run more than once,
the latest configuration overrides the previous one.
Step 3 (Optional) Enable the IP FRR poison reverse.
1. Run:
interface interface-type interface-number [.sub-interface-number]
The interface or sub-interface view is displayed.

The Eth-Trunk interface view, Eth-Trunk sub-interface view, GE interface view, GE sub-
interface view, IP-Trunk interface view, and POS interface view are supported.
2. Run:
poison-reverse enable
The IP FRR poison reverse is enabled.

On an IP ring network configured with IP FRR, the poison-reverse enable command is
used to prevent instantaneous traffic storms caused by the route convergence.
Both poison reverse and BAS services cannot be configured on one interface.
Both poison reverse and inter-VLAN proxy ARP cannot be configured on one interface.

In the load balancing scenario, poison reverse does not take effect.
----End

After public network IP FRR is configured, you can check backup information about routes.
Prerequisites
Public network IP FRR has been configured.
Procedure
l Run the display route-policy [ route-policy-name ] command to check the route-policy.
l Run the display ip routing-table verbose command to check backup outbound interfaces
and backup next hops of all routes in the routing table.
l Run the display ip routing-table ip-address [ mask | mask-length ] [ longer-match ]
verbose command to check the backup outbound interface and the backup next hop of a
specified route in the routing table.
l Run the display ip routing-table ip-address1 { mask1 | mask-length1 } ip-address2
{ mask2 | mask-length2 } verbose command to check the backup outbound interfaces and
the backup next hops of the routes in the address range determined by ip-address1 and ip-
address2 in the routing table.
----End
Example
Run the display ip routing-table ip-address verbose command to view the backup outbound
interface and the backup next hop in the routing table. An example command output is as follows:
<HUAWEI> display ip routing-table 172.17.1.0 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination: 172.17.1.0/24
Protocol: OSPF Process ID: 1
Preference: 10 Cost: 3
NextHop: 192.168.10.2 Neighbour: 0.0.0.0
State: Active Adv Age: 00h06m49s
Tag: 0 Priority: low
Label: NULL QoSInfo: 0x0
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet2/0/0
TunnelID: 0x0 Flags: D
BkNextHop: 192.168.20.2 BkInterface: GigabitEthernet3/0/0
BkLabel: NULL SecTunnelID: 0x0
BkPETunnelID: 0x0 BkPESecTunnelID: 0x0
BkIndirectID: 0x0
1.5 Configuring Public Network IPv6 FRR

Public network IPv6 FRR is applicable to the services that are very sensitive to packet loss and
delay on the public network.


Before configuring IPv6 FRR on the public network, familiarize yourself with the usage
scenario, complete the pre-configuration tasks, and obtain the required data.
As networks develop, services such as audio, online video, and finance have more requirements
for real-time transmission. Generally, active/backup links are deployed to ensure service
stability.
However, in traditional forwarding modes, when there are multiple routes to the same
destination, the system selects the optimal route, and delivers it to the FIB table to guide data
forwarding. When the optimal route goes Down, the system can select another optimal route
and deliver the route to the Forwarding Information Base (FIB) table only after route
convergence is complete. Then the service can be recovered. This leads to a long-time service
interruption and cannot meet service requirements.
IPv6 Fast Reroute (FRR) can specify a backup next hop and a backup interface and set backup
forwarding information for IPv6 routes. When the active link becomes faulty, the system can
switch the traffic immediately to the backup link. This process is irrelevant to route convergence
and therefore services can be recovered in a short period of time.
Before configuring IPv6 FRR on the public network, complete the following tasks:
l Configuring static routes or an IGP to ensure reachable routes among nodes

l Configuring different costs for routes
Data Preparation
Before configuring IPv6 FRR on the public network, you need the following data:
No. Data
1 Name of the route-policy and the number of the node
2 Backup outbound interface of an IPv6 route
3 Backup next hop of an IPv6 route
1.5.2 Configuring a Route-Policy

When configuring IPv6 FRR for the public network, you can configure a route-policy to specify
the backup next hops and backup outbound interfaces for routes.
Context
Perform the following steps on the router to which IPv6 FRR needs to be applied:

Procedure
Step 1 Run:
system-view

Step 2 Run:
The route-policy node is created and the route-policy view is displayed.

if-match
Matching conditions are set to filter the routes to be backed up.

Select the if-match clauses according to 10.3.3 (Optional) Configuring the If-Match
Clause.
If no matching condition is specified, backup interfaces and backup next hops will be configured
for all IPv6 routes of the router. To correctly configure backup relationship between routes,
specifying matching conditions is recommended.
Step 4 Run:
apply ipv6 backup-interface interface-type interface-number
The backup outbound interface is set.

Step 5 Run:
apply ipv6 backup-nexthop ipv6-address
The backup next hop is set.
----End
1.5.3 Enabling Public Network IPv6 FRR

Public network IPv6 FRR can be configured to switch traffic to a backup link when the active
link becomes unavailable, preventing long time service interruption.
Context
Perform the following steps on the router to which IPv6 FRR needs to be applied:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipv6 frr route-policy route-policy-name
IPv6 FRR is enabled.

By default, IPv6 FRR is disabled.

Before applying IPv6 FRR, you must use this command to enable IPv6 FRR. IPv6 FRR takes
effect only when route-policy route-policy-name configured in this command is configured with
a backup outbound interface and a backup next hop.
Step 3 (Optional) Enable the IP FRR poison reverse.

1. Run:
interface interface-type interface-number [.sub-interface-number]
The interface or sub-interface view is displayed.
The Eth-Trunk interface view, Eth-Trunk sub-interface view, GE interface view, GE sub-
interface view, IP-Trunk interface view, and POS interface view are supported.
2. Run:
poison-reverse enable
The IP FRR poison reverse is enabled.
On an IP ring network configured with IP FRR, the poison-reverse enable command is

used to prevent instantaneous traffic storms caused by the route convergence.
Both poison reverse and BAS services cannot be configured on one interface.
Both poison reverse and inter-VLAN proxy ARP cannot be configured on one interface.
In the load balancing scenario, poison reverse does not take effect.
----End

After IPv6 FRR is configured, you can view backup information about routes.
Prerequisites
Public network IPv6 FRR has been configured.
Procedure
l Run the display route-policy [ route-policy-name command to check the route-policy
information.
l Run the following commands to check the backup outbound interface and the backup next
hop in the routing table.
– display ipv6 routing-table verbose
– display ipv6 routing-table ipv6-address [ prefix-length ] [ longer-match ] verbose
– display ipv6 routing-table ip-address1 [ prefix-length1 ] ip-address2 prefix-length2
verbose
----End
Example
Run the display ipv6 routing-table ipv6-address verbose command to view the backup
outbound interface and the backup next hop in the routing table. An example command output
is as follows:

<HUAWEI> display ipv6 routing-table 2001:db8:2::2 verbose

Routing Table :
Summary Count : 1
Destination : 2001:db8:2::2 PrefixLength : 128

NextHop : FE80::2E0:52FF:FE10:8100 Preference : 10
Neighbour : 202:202:: ProcessID : 1
Label : NULL Protocol : OSPFv3
State : Active Adv Cost : 2
Entry ID : 267337828 EntryFlags : 0x80002100
Reference Cnt: 2 Tag : 1
Priority : medium Age : 8sec
IndirectID : 0x0
RelayNextHop : :: TunnelID : 0x0
Interface : GigabitEthernet1/0/0 Flags : D
BkNextHop : 2001:db8:2001::2 BkInterface : GigabitEthernet1/0/1
BkLabel : NULL BkTunnelID : 0x0
BkPETunnelID : 0x0 BkIndirectID : 0x0
1.6 Configuring VRRP for Direct Routes

If VRRP for direct routes is configured on a master device of an IPv4 network, the master device
effectively diagnoses a link fault, improving the security of the IPv4 network.

Before configuring VRRP for direct routes, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain data. This can help you complete the
As the Internet develops, the demand for higher reliability is increasing. To help LAN users
access the Internet at any time, the VRRP provides reliability for LAN hosts.
On an IP RAN enabled with VRRP, if a UPE recovers from a fault, its interface connected to
the RSG goes Up and generates a direct route, allowing a traffic switchback. As the UPE does
not learn the RSG's MAC address, the UPE fails to switch back some packets. To help prevent
the problem, the direct route has to be generated after the VRRP status changes to Master. If
VRRP for direct routes is configured, the UPE adjusts the direct route's cost based on the VRRP
status. This allows the UPE to perform a successful traffic switchback if recovering from a fault.
For detailed configurations of an IP RAN, see the section "IP RAN Configuration" in the
HUAWEI NetEngine80E/40E Router Configuration Guide - VPN.
Before configuring VRRP for direct routes, complete the following task:
l Configuring parameters for a data link layer protocol and IP addresses for interfaces to
ensure that the data link layer protocol on the interfaces is Up
Data Preparation
To configure VRRP for direct routes, you need the following data.

No. Data
1 VRRP backup group ID
2 Virtual IP address of a VRRP backup group
3 Priority levels of routers in a VRRP backup group
4 Name of an interface associated with a VRRP backup group
1.6.2 Configuring a VRRP Backup Group

A VRRP backup group allows LAN hosts to communicate with external networks in a reliable
manner.
Context
VRRP groups multiple routers to a virtual router. The virtual router uses a mechanism to switch
traffic to another router if a fault occurs on the current router, providing continuous and reliable
communication services.
VRRP works in master/backup mode to provide IP address backup. A virtual router (a VRRP
backup group) in master/backup mode consists of a master router and one or multiple backup
routers. The master and backup routers form a backup group. In master/backup mode, only one
VRRP backup group is set up. Routers in the VRRP backup group are prioritized. The router
with the highest priority functions as the master router and other routers function as backup
routers.
l The master router transmits all services if it works properly.

l If the master router fails, a backup router takes over services.
For detailed configurations of a VRRP backup group, see the section "VRRP Configuration" in
the HUAWEI NetEngine80E/40E Router Configuration Guide - Reliability.
Perform the following steps on devices in a VRRP backup group:
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface interface-type interface-number
Step 3 Run:
vrrp vrid virtual-router-id virtual-ip virtual-address
A VRRP backup group is configured and its virtual IP address is assigned.

NOTE
l The virtual IP addresses of VRRP backup groups must be different.

l All devices in a VRRP backup group must be assigned the same virtual router ID.
l Virtual router IDs set on different interfaces of one device can be the same.
If the first virtual IP address is assigned to a VRRP backup group, the system automatically
creates the VRRP backup group. If another virtual IP address is assigned to the VRRP backup
group, the system only adds the virtual IP address to the virtual IP address list for the VRRP
backup group.
On a network where a VRRP backup group is the gateway for multiple hosts, a default gateway
address saved on any host does not change even if the VRRP backup group's location changes.
To help hosts adapt to changes in the VRRP backup group's location, the VRRP backup group
is assigned multiple virtual IP addresses for different hosts. A maximum of 16 virtual IP
addresses is assigned to a VRRP backup group.
NOTE
The direct routes generated by the virtual IP addresses in a VRRP backup group can be imported by
OSPF, IS-IS and RIP. By default, this kind of route can be advertised by OSPF, IS-IS and RIP to the
neighboring devices. On actual networks, it is possible that there are a large number of routes generated
by the virtual IP addresses in a VRRP backup group; if all of the routes are imported and advertised to the
neighboring devices by OSPF, IS-IS and RIP, it will bring a heavy load to some devices on the networks
and affect the network performance. In this situation, you can use the vrrp virtual-ip route-advertise
disable command to disable OSPF, IS-IS and RIP from advertising the routes generated by the virtual IP
addresses in the VRRP backup group.
Step 4 Run:
vrrp vrid virtual-router-id priority priority-value
The priority value of a device in a backup group is set.
By default, the priority value is 100.
l Priority 0: is reserved for special use.

l Priority 255: is reserved for the IP address owner. The priority of the IP address owner is
fixed.
The configurable priority value ranges from 1 to 254.
Step 5 Run:
vrrp vrid virtual-router-id timer advertise advertise-interval
The interval at which a VRRP Advertisement packet is sent is set.
By default, a VRRP Advertisement packet is sent every second. If multiple VRRP backup groups
are configured on a device, the interval can be increased to prevent frequent VRRP status
switchovers.
----End
1.6.3 Associating an Interface with a VRRP Backup Group

After an interface is associated with a VRRP backup group, the cost of the direct route in a
network segment, to which the interface belongs, changes based on the VRRP status.

Context
The VRRP status changes during a master/backup switchover. Associating an interface with a
VRRP backup group allows the cost of the direct route in the network segment to which the
interface belongs to change based on the VRRP status.
Perform the following steps on the interface to be associated with a VRRP backup group:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
direct-route track vrrp vrid virtual-router-id degrade-cost cost
The interface is associated with a VRRP backup group.
By default, the interface is associated with no VRRP backup group.
VRRP for direct routes works as follows:
l If the VRRP status becomes Backup, the direct route's cost increases by degrade-cost cost,
lowering the direct route's priority. The direct route will no longer be an optimal route.
l If the VRRP status becomes Master, the direct route's cost is set to 0, allowing the direct
route's priority to be the highest. The direct route will be an optimal route.
----End

After the VRRP for direct routes has been configured, view the information about the VRRP
backup group status.
Prerequisites
A VRRP backup group has been configured.
Procedure
l Run the display vrrp [ interface interface-type interface-number [ virtual-router-id ] ]
[ brief ] command to check the VRRP backup group status.
l Run the display ip routing-table [ verbose ] command to check the information about the
IPv4 routing table.
----End

Example
If a VRRP backup group is configured successfully, run the display vrrp command, and you
can view the VRRP backup group status. For example, the VRRP backup group status is Master.
<HUAWEI> display vrrp
GigabitEthernet2/0/0 | Virtual Router 1
State : Master
Virtual IP : 10.1.3.111
Master IP : 10.1.3.1
PriorityRun : 120
PriorityConfig : 120
MasterPriority : 120
Preempt : YES Delay Time : 0 s
TimerRun : 10 s
TimerConfig : 10 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0102
Check TTL : YES
Config type : normal-vrrp
Create time : 2010-08-16 12:02:57
Last change time : 2010-08-17 10:27:11
1.7 Configuring an IPv4 Direct Route to Respond to L3VE

Interface Status Changes After a Delay
As shown in Figure 1-3, an Layer 2 Virtual Private Network (L2VPN) connection is set up
between each access aggregation gateway (AGG) and the cell site gateway (CSG) through Layer
2 Virtual Ethernet (L2VE) interfaces, while BGP VPNv4 peer relationships are set up between
AGGs and radio network controller site gateways (RSGs) on an Layer 3 Virtual Private Network
(L3VPN). L3VE interfaces are configured on AGGs and VPN instances are bound to the L3VE
interfaces, so that the CSG can access the L3VPN. BGP is configured on AGGs to import direct
routes between the CSG and AGGs. These direct routes are converted to BGP VPNv4 routes
and advertised to RSGs.

Figure 1-3 Networking of a direct route responding to L3VE interface status changes after a
delay
AGG1 RSG1
CSG
Link A
Link B
NodeB RNC
AGG2 RSG2
L2VPN L3VPN
AGG1 is used as the master device in the preceding figure. In normal cases, RSGs select routes
advertised by AGG1 and traffic travels along Link A. If AGG1 or the CSG-AGG1 link fails,
traffic is switched over to Link B. After AGG1 or the CSG-AGG1 link recovers, the L3VE
interface on AGG1 goes from Down to Up, and AGG1 immediately generates a direct route
destined for the CSG and advertises the route to RSGs. Downstream traffic is then switched over
to Link A. However, AGG1 has not learned the MAC addresses of the base stations yet, so
downstream traffic will be lost.
After you configure a cost for a direct route and allow the direct route to restore its default cost
0 after a delay, when the L3VE interface on AGG1 goes from Down to Up, the cost of the direct
route between the CSG and AGG1 is modified to the configured cost. In this case, RSGs do not
select routes advertised by AGG1 and downstream traffic still travels along Link B. After the
configured delay expires, the cost of the direct route to the CSG is restored to the default value
0. Then, RSGs select routes advertised by AGG1 and downstream traffic is switched over to
Link A. At this time, AGG1 has learned the MAC addresses of the base stations, and downstream
traffic loss will be reduced.
Before you configure an IPv4 direct route to respond to L3VE interface status changes after a
delay, complete the following task:
l Configuring link-layer protocol parameters and IP addresses for interfaces to ensure that
the link layer protocol of each interface is Up
Data Preparation
To configure an IPv4 direct route to respond to L3VE interface status changes after a delay, you
need the following data.

No. Data
1 Cost of the L3VE interface's direct route to the CSG
2 Delay before the direct route cost is restored to the default value 0
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface virtual-ethernet interface-number
A VE interface is created and the VE interface view is displayed.

Step 3 Run:
ve-group ve-group-id l3-access
The VE interface is configured as an L3VE interface and bound to a VE group.
NOTE
The L2VPN can access the L3VPN only if the L2VE and L3VE interfaces are bound to the same VE group
and reside on the same board.
Step 4 Run:
quit
Return to the system view.

Step 5 Run:
interface virtual-ethernet interface-number.subinterface-number
A VE sub-interface is created and the VE sub-interface view is displayed.

Step 6 Run:
direct-route degrade-delay delay-time degrade-cost cost
The direct route is configured to respond to L3VE interface status changes after a delay.
After you run the direct-route degrade-delay command on an L3VE interface, and the L3VE
interface goes from Down to Up, the cost of the L3VE interface's direct route to the CSG is
modified to the configured cost. After the configured delay-time expires, the direct route cost is
restored to the default value 0.
NOTE
The direct-route degrade-delay command, the direct-route track pw-state command, and the direct-
route track vrrp command cannot be all configured on one L3VE interface.
----End
Checking the Configurations

If an AGG's L3VE interface goes from Down to Up, run the display ip routing-table vpn-
instance vpn-instance-name [ ip-address ] [ verbose ] command on the AGG. The command

output shows that the cost of the L3VE interface's direct route to the CSG is the configured cost.
After the configured delay-time expires, run the display ip routing-table vpn-instance vpn-
instance-name [ ip-address ] [ verbose ] command on the AGG. The command output shows
that the cost of the direct route to the L3VE interface is the default value 0.
1.8 Configuring an IPv6 Direct Route to Respond to L3VE

Interface Status Changes After a Delay
As shown in Figure 1-4, an Layer 2 Virtual Private Network (L2VPN) connection is set up
between each access aggregation gateway (AGG) and the cell site gateway (CSG) through Layer
2 Virtual Ethernet (L2VE) interfaces, while BGP virtual private network version 4 (VPNv4)
peer relationships are set up between AGGs and radio network controller site gateways (RSGs)
on an Layer 3 Virtual Private Network (L3VPN). L3VE interfaces are configured on AGGs and
VPN instances are bound to the L3VE interfaces, so that the CSG can access the L3VPN. BGP
is configured on AGGs to import direct routes between the CSG and AGGs. These direct routes
are converted to BGP VPNv6 routes and advertised to RSGs.
Figure 1-4 Networking of an IPv6 direct route responding to L3VE interface status changes
after a delay
AGG1 RSG1
CSG
Link A
Link B
NodeB RNC
AGG2 RSG2
L2VPN BGP/MPLS IPv6 VPN
advertised by AGG1 and traffic travels along LinkA. If AGG1 or the CSG-AGG1 link fails,
traffic is switched over to LinkB. After AGG1 or the CSG-AGG1 link recovers, the L3VE
interface on AGG1 goes from Down to Up, and AGG1 immediately generates an IPv6 direct
route destined for the CSG and advertises the route to RSGs. Downstream traffic is then switched
over to LinkA. However, AGG1 has not learned the MAC addresses of the base stations yet, so
downstream traffic will be lost.

After you configure a cost for an IPv6 direct route and allow the direct route to restore its default
cost 0 after a delay, when the L3VE interface on AGG1 goes from Down to Up, the cost of the
direct route between the CSG and AGG1 is modified to the configured cost. In this case, RSGs
do not select routes advertised by AGG1 and downstream traffic still travels along LinkB. After
the configured delay expires, the cost of the direct route to the CSG is restored to the default
value 0. Then, RSGs select routes advertised by AGG1 and downstream traffic is switched over
to LinkA. At this time, AGG1 has learned the MAC addresses of the base stations, and
downstream traffic loss will be reduced.
Before you configure an IPv6 direct route to respond to L3VE interface status changes after a
delay, complete the following task:
l Configuring link-layer protocol parameters and IPv6 addresses for interfaces to ensure that
Data Preparation
To configure an IPv6 direct route to respond to L3VE interface status changes after a delay, you
need the following data.
No. Data
2 Delay before the direct route cost is restored to the default value 0
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
NOTE
Step 4 Run:
quit

Step 5 Run:
Step 6 Run:
ipv6 enable
The IPv6 capability is enabled on the interface.
Step 7 Run:
direct-route ipv6 degrade-delay delay-time degrade-cost cost
The direct route is configured to respond to L3VE interface status changes after a delay.
After you run the direct-route ipv6 degrade-delay command on an L3VE interface, and the
L3VE interface goes from Down to Up, the cost of the L3VE interface's direct route to the CSG
is modified to the configured cost. After the configured delay-time expires, the direct route cost
is restored to the default value 0.
NOTE
The direct-route ipv6 degrade-delay command and the direct-route ipv6 track pw-state command
cannot be all configured on one L3VE interface.
----End

If an AGG's L3VE interface goes from Down to Up, run the display ipv6 routing-table vpn-
instance vpn-instance-name [ ipv6-address ] [ verbose ] command on the AGG. The command
output shows that the cost of the L3VE interface's direct route to the CSG is the configured cost.
After the configured delay-time expires, run the display ipv6 routing-table vpn-instance vpn-
instance-name [ ipv6-address ] [ verbose ] command on the AGG. The command output shows
that the cost of the direct route to the L3VE interface is the default value 0.
1.9 Configuring the Association Between the IPv4 Direct

Route and PW Status
As shown in Figure 1-5, PWs are set up between access aggregation gateways (AGGs) and the
cell site gateway (CSG), while BGP VPNv4 peer relationships are set up between AGGs and
radio network controller site gateways (RSGs). Layer 3 Virtual Ethernet (L3VE) interfaces are
configured on AGGs and VPN instances are bound to the L3VE interfaces, so that the CSG can
access the Layer 3 Virtual Private Network (L3VPN). BGP is configured on AGGs to import
direct routes between the CSG and AGGs. These direct routes are converted to BGP VPNv4
routes and advertised to RSGs.

Figure 1-5 Networking of the association between the direct route and PW status
AGG1 RSG1
CSG PW1
Link A
Link B
NodeB RNC
PW2
AGG2 RSG2
L2VPN L3VPN
PW
advertised by AGG1 and traffic travels along Link A. If AGG1 or the CSG-AGG1 link fails,
traffic is switched over to Link B. After AGG1 or the CSG-AGG1 link recovers, the L3VE
interface on AGG1 goes from Down to Up, and AGG1 immediately generates a direct route
destined for the CSG and advertises the route to RSGs. Downstream traffic is then switched over
to Link A. However, AGG1 has not learned the MAC addresses of the base stations yet and PW1
is standing by, so downstream traffic will be lost.
After you configure the association between the direct route and PW status, when the L3VE
interface on AGG1 goes from Down to Up, the cost of the direct route between the CSG and
AGG1 increases. In this case, RSGs do not preferentially select routes advertised by AGG1 and
downstream traffic still travels along Link B. After PW1 between the CSG and AGG1 becomes
the primary PW, the cost of the direct route between the CSG and AGG1 is restored to the default
value 0. Then, RSGs preferentially select routes advertised by AGG1 and downstream traffic is
switched over to Link A. At this time, AGG1 has learned the MAC addresses of the base stations,
downstream traffic loss will be reduced after the configuration.
Before configuring the association between the IPv4 direct route and PW status, complete the
following tasks:
Data Preparation
To configure the association between the IPv4 direct route and PW status, you need the following
data.

No. Data
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
NOTE
The Layer 2 Virtual Private Network (L2VPN) can access the L3VPN only if the Layer 2 Virtual Ethernet
(L2VE) and L3VE interfaces are bound to the same VE group and reside on the same board.
Step 4 Run:
quit
Step 5 Run:
Step 6 Run:
direct-route track pw-state degrade-cost cost
The association between the direct route and PW status is configured.
After you run the direct-route track pw-state command on a L3VE interface, the system will
adjust the cost of the direct route to the L3VE interface based on the PW status. If the PW is
standby, the system modifies the direct route cost to the configured value cost. If the PW is
active, the system restores the direct route cost to the default value 0.
NOTE
The direct-route track pw-state command, the direct-route degrade-delay command, and the direct-
route track vrrp command cannot be simultaneously configured on one L3VE interface.
----End

If a PW has recovered but has not become active, run the display ip routing-table vpn-
instance vpn-instance-name [ ip-address ] [ verbose ] command on an AGG. The command

output shows that the direct route to the L3VE interface has the configured cost. After a PW
becomes active, run the display ip routing-table vpn-instance vpn-instance-name [ ip-
address ] [ verbose ] command on an AGG. The command output shows that the direct route
to the L3VE interface has the default cost 0.

Route and PW Status
As shown in Figure 1-6, PWs are set up between access aggregation gateways (AGGs) and the
cell site gateway (CSG), while BGP Virtual Private Network version 6 (VPNv6) peer
relationships are set up between AGGs and radio network controller site gateways (RSGs). Layer
3 Virtual Ethernet (L3VE) interfaces are configured on AGGs and VPN instances are bound to
the L3VE interfaces, so that the CSG can access the Layer 3 Virtual Private Network (L3VPN).
BGP is configured on AGGs to import IPv6 direct routes between the CSG and AGGs. These
IPv6 direct routes are converted to BGP VPNv6 routes and advertised to RSGs.
Figure 1-6 Networking of the association between the IPv6 direct route and PW status
AGG1 RSG1
CSG PW1
Link A
Link B
NodeB RNC
PW2
AGG2 RSG2
L2VPN BGP/MPLS IPv6 VPN

PW
advertised by AGG1 and traffic travels along LinkA. If AGG1 or the CSG-AGG1 link fails,
traffic is switched over to LinkB. After AGG1 or the CSG-AGG1 link recovers, the L3VE
interface on AGG1 goes from Down to Up, and AGG1 immediately generates an IPv6 direct
route destined for the CSG and advertises the route to RSGs. Downstream traffic is then switched
over to LinkA. However, AGG1 has not learned the MAC addresses of the base stations yet and
PW1 is standing by, so downstream traffic will be lost.

After you configure the association between the IPv6 direct route and PW status, when the L3VE
interface on AGG1 goes from Down to Up, the cost of the IPv6 direct route between the CSG
and AGG1 increases. In this case, RSGs do not preferentially select routes advertised by AGG1
and downstream traffic still travels along LinkB. After PW1 between the CSG and AGG1
becomes the primary PW, the cost of the IPv6 direct route between the CSG and AGG1 is restored
to the default value 0. Then, RSGs preferentially select routes advertised by AGG1 and
downstream traffic is switched over to LinkA. At this time, AGG1 has learned the MAC
addresses of the base stations, downstream traffic loss will be reduced after the configuration.
Before configuring the association between the IPv6 direct route and PW status, complete the
following tasks:
Data Preparation
To configure the association between the IPv6 direct route and PW status, you need the following
data.
No. Data
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
NOTE
The Layer 2 Virtual Private Network (L2VPN) can access the L3VPN only if the Layer 2 Virtual Ethernet
(L2VE) and L3VE interfaces are bound to the same VE group and reside on the same board.
Step 4 Run:
quit

Step 5 Run:

Step 6 Run:
ipv6 enable
The IPv6 capability is enabled on the interface.
Step 7 Run:
direct-route ipv6 track pw-state degrade-cost cost
The association between the IPv6 direct route and PW status is configured.
After you run the direct-route ipv6 track pw-state command on a L3VE interface, the system
will adjust the cost of the IPv6 direct route to the L3VE interface based on the PW status. If the
PW is standby, the system modifies the IPv6 direct route cost to the configured value cost. If
the PW is active, the system restores the IPv6 direct route cost to the default value 0.
NOTE
The direct-route ipv6 track pw-state command and the direct-route ipv6 degrade-delay command
cannot be simultaneously configured on one L3VE interface.
----End

If a PW has recovered but has not become active, run the display ipv6 routing-table vpn-
instance vpn-instance-name [ ipv6-address ] [ verbose ] command on an AGG. The command
output shows that the IPv6 direct route to the L3VE interface has the configured cost. After a
PW becomes active, run the display ipv6 routing-table vpn-instance vpn-instance-name
[ ipv6-address ] [ verbose ] command on an AGG. The command output shows that the IPv6
direct route to the L3VE interface has the default cost 0.

Routes and IPSec Instance Status
The association between IPv4 direct routes and IP security (IPSec) instance status ensures that
data encrypted using IPSec can be transmitted to the correct radio network controller site gateway
(RSG).
Usage Scenario
In an IP radio access network (IPRAN) scenario, some services require high security. To meet
such requirements, cell site gateways (CSGs) encrypt data of these services using IPSec. After
the data flows to RSGs (IPSec gateways) through an IPSec tunnel, the RSGs decrypt the data.
In most cases, carriers deploy master and backup RSGs and configure the same IP address for
the IPSec tunnel interfaces of the master and backup RSGs to improve network reliability.
Without the association between IPv4 direct routes and IPSec instance status, IPv4 direct routes
with the same prefix generated on the IPSec tunnel interfaces of the master and backup RSGs
share the same default cost (0). As a result, after receiving these routes from the master and
backup RSGs, CSGs cannot select an optimal one based on the cost.
With the association between IPv4 direct routes and IPSec instance status:

l If the IPSec instance status is master on an IPSec tunnel interface, the cost of the IPv4 direct
routes generated on the interface is 0.
l If the IPSec instance status is backup on an IPSec tunnel interface or the system cannot
detect the IPSec instance status, the cost of the IPv4 direct routes generated on the interface
is the cost configured on the interface.
After receiving the IPv4 direct routes with the same prefix from the master and backup RSGs,
CSGs can select an optimal one based on the cost. Therefore, the CSGs can transmit data
encrypted using IPSec to the correct RSG.
Before configuring the association between IPv4 direct routes and IPSec instance status,
configure link layer protocol parameters and IP addresses for interfaces and ensure that the link
layer protocol of each interface is Up.
Data Preparation
To complete the configuration, you need the following data:
No. Data
1 Cost for IPv4 direct routes generated on each IPSec tunnel interface
Procedure
Step 1 Run:
system-view
Step 2 Run:
interface tunnel interface-number
A tunnel interface is created, and the tunnel interface view is displayed.
Step 3 Run:
tunnel-protocol ipsec
The encapsulation protocol is set to IPSec on the tunnel interface.
Step 4 Run:
direct-route track ipsec-instance degrade-cost cost
The association between IPv4 direct routes and IPSec instance status is configured.
NOTE
If the IPSec tunnel interface uses the IP address of another interface, the association between the cost of
IPv4 direct routes and the IPSec instance status cannot be configured on this IPSec tunnel interface.
The cost of local IPv4 direct routes that are not to be advertised cannot be associated with the IPSec instance
status.
----End


After configuring association between IPv4 direct routes and IPSec instance status, run the
display ip routing-table vpn-instance vpn-instance-name [ ip-address ] [ verbose ] command
on the RSG to check the information about the IP routing table of the VPN instance or run the
display ip routing-table [ ip-address [ mask | mask-length ] [ verbose ] ] command to check
the information about the IP routing table of the public network instance.
l If the IPSec instance status is master on an IPSec tunnel interface, the cost of the IPv4 direct
routes generated on the interface is 0.
l If the IPSec instance status is backup on an IPSec tunnel interface or the system cannot
detect the IPSec instance status, the cost of the IPv4 direct routes generated on the interface
is the cost configured on the interface.
1.12 Configuring a Device to Deactivate the IPv4 Network

Segment Route That Corresponds to an L3VE Sub-interface
wire (PW).
To speed up end-to-end traffic switchovers when a primary PW fails in a Layer 2 virtual private
network (L2VPN) that accesses a Layer 3 virtual private network (L3VPN), the system keeps
the L3VE sub-interface of the secondary PW Up. This mechanism spares the L3VE sub-interface
from negotiation of the Up state during the primary/secondary PW switchover, reducing traffic
loss and accelerating route convergence, especially when many L3VE sub-interfaces exist.
However, when the L3VE sub-interface is Up, the system generates a network segment route
that corresponds to the L3VE sub-interface. The network segment route will be selected, because
a direct route has the highest priority. Because the connected PW is the secondary PW, the
network segment route becomes a black-hole route, and traffic cannot be forwarded between
the CSGs. To address this problem, configure the device to deactivate the IPv4 network segment
route that corresponds to the L3VE sub-interface.
As shown in Figure 1-7, PWs are set up between the access aggregation gateways (AGGs) and
CSGs, while Border Gateway Protocol (BGP) virtual private network version 4 (VPNv4) peer
relationships are set up between the AGGs and radio network controller site gateways (RSGs).
L3VE sub-interfaces are configured on the AGGs, and VPN instances are bound to the L3VE
sub-interfaces so that the CSGs can access the L3VPN. BGP is configured on the AGGs to import
direct routes between the CSGs and AGGs. These direct routes are converted to BGP VPNv4
routes and advertised to the RSGs.

Figure 1-7 Networking of L2VPN accessing the L3VPN

CSG1 AGG1 RSG1
PW1
NodeB PW2
BGP/MPLS IP VPN
PW4
RNC
PW3
NodeB CSG2 AGG2 RSG2
Primary PW Data flow
Secondary PW ARP request packet
ARP reply packet
In most cases, if CSG1 needs to communicate with CSG2, CSG1 forwards data to AGG1 through
the primary PW (PW1). PW4 on AGG1 is the secondary PW, but the L3VE sub-interface is Up.
AGG1 generates and selects a network segment route because a direct route has a higher priority
than a BGP VPNv4 route learned from AGG2. However, AGG1 is not the master device of
CSG2 and does not have the Media Access Control (MAC) addresses stored on CSG2. To
forward the data, AGG1 sends an Address Resolution Protocol (ARP) request packet to CSG2.
CSG2 sends an ARP reply packet through the primary PW (PW3) because CSG2 does not
support the ARP dual sending function. The ARP reply packet reaches AGG2, instead of AGG1.
If the AGGs do not support ARP two-node hot backup, AGG2 does not back up its ARP entries
to AGG1 so that AGG1 cannot learn the MAC addresses stored on CSG2. The network segment
route from AGG1 to CSG2 becomes a black-hole route.
To address this problem, deactivate the network segment route that corresponds to the L3VE
sub-interface of the secondary PW by running the direct-route track pw-state deactive-
standby command on the L3VE sub-interface on AGG1 connecting to CSG2. When PW4 is the
secondary PW, AGG1 cannot generate the network segment route from CSG2 to its L3VE sub-
interface. In this situation, AGG1 selects the BGP VPNv4 route sent by AGG2. If CSG1 forwards
data to AGG1 through the primary PW (PW1), AGG1 forwards the data directly to AGG2.
AGG2 forwards the data to CSG2 through PW3. In this situation, no black-hole route exists.
If PW1 fails, PW2 becomes the primary PW of CSG1. If CSG1 needs to communicate with
CSG2, CSG1 forwards data to AGG2 through PW2. AGG2 then forwards the data to CSG2
through PW3. CSG2 forwards data destined for CSG1 to AGG2 through PW3. AGG2 forwards
the data to CSG1 through the primary PW (PW2). In this situation, data can be forwarded
between CSG1 and CSG2.

NOTE
Do not configure the direct-route track pw-state deactive-standby command, if the network meets one
of the following conditions where no black-hole route exists:
l The CSGs support the ARP dual sending function. CSG2 can reply to AGG1's ARP request packet
through PW3 and PW4. AGG1 can then learn the MAC addresses stored on CSG2 and forward data
to CSG2.
l The AGGs support ARP two-node hot backup. AGG1 can learn the MAC addresses stored on CSG2
from AGG2 and forward data to CSG2.
Before configuring a device to deactivate the IPv4 network segment route that corresponds to
an L3VE sub-interface, configure link-layer protocol parameters and IPv4 addresses for
interfaces to ensure that the link layer protocol of each interface is Up.
Data Preparation
None
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
NOTE
Step 4 Run:
quit
Step 5 Run:
Step 6 Run:
direct-route track pw-state deactive-standby
The device is configured to deactivate the IPv4 network segment route that corresponds to the
L3VE sub-interface of the secondary PW.

NOTE
The direct-route track pw-state deactive-standby command cannot be configured together with the
direct-route track pw-state degrade-cost, direct-route degrade-delay, or direct-route track vrrp
command on one L3VE sub-interface. If you configure any two of these commands, the latest configuration
overrides the previous one.
----End

Before you configure the direct-route track pw-state deactive-standby command on an AGG,
run the display ip routing-table vpn-instance vpn-instance-name command on the AGG. The
command output shows the IPv4 network segment route that corresponds to the L3VE sub-
interface of the secondary PW.
<HUAWEI> display ip routing-table vpn-instance vrf1
------------------------------------------------------------------------------
Routing Tables: vrf1
Destinations : 4 Routes : 4
Destination/Mask Proto Pre Cost Flags NextHop Interface
100.1.1.0/24 Direct 0 0 D 100.1.1.1 Virtual-

Ethernet1/0/1.1
100.1.1.1/32 Direct 0 0 D 127.0.0.1 Virtual-
Ethernet1/0/1.1
100.1.1.255/32 Direct 0 0 D 127.0.0.1 Virtual-
Ethernet1/0/1.1
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
After you configure the direct-route track pw-state deactive-standby command on an L3VE
sub-interface of the secondary PW, run the display ip routing-table vpn-instance command
on the AGG. The command output shows no IPv4 network segment route that corresponds to
the L3VE sub-interface of the secondary PW.
<HUAWEI> display ip routing-table vpn-instance vrf1
------------------------------------------------------------------------------
Routing Tables: vrf1
100.1.1.1/32 Direct 0 0 D 127.0.0.1 Virtual-

Ethernet1/0/1.1
100.1.1.255/32 Direct 0 0 D 127.0.0.1 Virtual-
Ethernet1/0/1.1
1.13 Configuring a Device to Deactivate the IPv6 Network

Segment Route That Corresponds to an L3VE Sub-interface
wire (PW).

To speed up end-to-end traffic switchovers when a primary PW fails in a Layer 2 virtual private
network (L2VPN) that accesses a Layer 3 virtual private network (L3VPN), the system keeps
the L3VE sub-interface of the secondary PW Up. This mechanism spares the L3VE sub-interface
from negotiation of the Up state during the primary/secondary PW switchover, reducing traffic
loss and accelerating route convergence, especially when many L3VE sub-interfaces exist.
However, when the L3VE sub-interface is Up, the system generates a network segment route.
The network segment route will be selected, because a direct route has the highest priority.
Because the connected PW is the secondary PW, the network segment route becomes a black-
hole route, and traffic cannot be forwarded between the CSGs. To address this problem,
configure the device to deactivate the IPv6 network segment route that corresponds to the L3VE
sub-interface.
As shown in Figure 1-8, PWs are set up between the access aggregation gateways (AGGs) and
CSGs, while Border Gateway Protocol (BGP) virtual private network version 6 (VPNv6) peer
relationships are set up between the AGGs and radio network controller site gateways (RSGs).
L3VE sub-interfaces are configured on the AGGs, and VPN instances are bound to the L3VE
sub-interfaces so that the CSGs can access the L3VPN. BGP is configured on the AGGs to import
direct routes between the CSGs and AGGs. These direct routes are converted to BGP VPNv6
routes and advertised to the RSGs.
Figure 1-8 Networking of L2VPN accessing the L3VPN
CSG1 AGG1 RSG1

PW1
NodeB PW2
BGP/MPLS IPv6 VPN
PW4
RNC
PW3
NodeB CSG2 AGG2 RSG2
Primary PW Data flow
Secondary PW NS packet
NA packet
In most cases, if CSG1 needs to communicate with CSG2, CSG1 forwards data to AGG1 through
the primary PW (PW1). PW4 on AGG1 is the secondary PW, but the L3VE sub-interface is Up.
AGG1 generates and selects a network segment route because a direct route has a higher priority
than a BGP VPNv6 route learned from AGG2. However, AGG1 is not the master device of
CSG2 and does not have the Media Access Control (MAC) addresses stored on CSG2. To
forward the data, AGG1 sends a Neighbor Solicitation (NS) packet to CSG2. CSG2 sends a
Neighbor Advertisement (NA) packet through the primary PW (PW3). The NA packet reaches
AGG2, instead of AGG1. AGG1 cannot learn the MAC addresses stored on CSG2 or forward
traffic to CSG2. The network segment route from AGG1 to CSG2 becomes a black-hole route.

To address this problem, deactivate the network segment route that corresponds to the L3VE
sub-interface of the secondary PW by running the direct-route ipv6 track pw-state deactive-
standby command on the L3VE sub-interface on AGG1 connecting to CSG2. When PW4 is the
secondary PW, AGG1 cannot generate the network segment route from CSG2 to its L3VE sub-
interface. In this situation, AGG1 selects the BGP VPNv6 route sent by AGG2. If CSG1 forwards
data to AGG1 through the primary PW (PW1), AGG1 forwards the data directly to AGG2.
AGG2 forwards the data to CSG2 through PW3. In this situation, no black-hole route exists.
If PW1 fails, PW2 becomes the primary PW of CSG1. If CSG1 needs to communicate with
CSG2, CSG1 forwards data to AGG2 through PW2. AGG2 then forwards the data to CSG2
through PW3. CSG2 forwards data destined for CSG1 to AGG2 through PW3. AGG2 forwards
the data to CSG1 through the primary PW (PW2). In this situation, data can be forwarded
between CSG1 and CSG2.
Before configuring a device to deactivate the IPv6 network segment route that corresponds to
an L3VE sub-interface, configure link-layer protocol parameters and IPv6 addresses for
interfaces to ensure that the link layer protocol of each interface is Up.
Data Preparation
None
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
NOTE
Step 4 Run:
quit
Step 5 Run:
Step 6 Run:

direct-route ipv6 track pw-state deactive-standby
The device is configured to deactivate the IPv6 network segment route that corresponds to the
L3VE sub-interface of the secondary PW.
NOTE
The direct-route ipv6 track pw-state deactive-standby command cannot be configured together with
the direct-route ipv6 track pw-state or direct-route ipv6 degrade-delay command on one L3VE sub-
interface. If you configure any two of these commands, the latest configuration overrides the previous one.
----End

Before you configure the direct-route ipv6 track pw-state deactive-standby command on an
AGG, run the display ipv6 routing-table vpn-instance vpn-instance-name command on the
AGG. The command output shows the IPv6 network segment route that corresponds to the L3VE
sub-interface of the secondary PW.
<HUAWEI> display ipv6 routing-table vpn-instance vrf1
Routing Table : vrf1
Destination : 2001:db8:: PrefixLength : 64

NextHop : 2001:db8::1:1 Preference : 0
Cost : 0 Protocol : Direct
Interface : Virtual-Ethernet1/0/1.1 Flags : D
Destination : 2001:db8::1:1 PrefixLength : 128

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

NextHop : :: Preference : 0
Interface : NULL0 Flags : D
After you configure the direct-route ipv6 track pw-state deactive-standby command on an
L3VE sub-interface of the secondary PW, run the display ipv6 routing-table vpn-instance
command on the AGG. The command output shows no IPv6 network segment route that
corresponds to the L3VE sub-interface of the secondary PW.
<HUAWEI> display ipv6 routing-table vpn-instance vrf1
Routing Table : vrf1
Destination : 2001:db8::1:1 PrefixLength : 128



1.14 Configuring AGGs to Load-Balance RNC-to-CSG

Traffic
This section describes how to configure access aggregation gateways (AGGs) to load-balance
radio network controller (RNC)-to-cell site gateway (CSG) traffic. The load balancing
configuration can improve network resource usage and reliability.
Usage Scenario
Figure 1-9 shows a typical networking for a Layer 2 Virtual Private Network (L2VPN) accessing
an Layer 3 Virtual Private Network (L3VPN). An L2VPN connection is set up between each
AGG and CSG, while a Border Gateway Protocol (BGP) VPNv4 peer relationship is set up
between each AGG and RNC site gateway (RSG) on the L3VPN; Layer 3 Virtual Ethernet
(L3VE) sub-interfaces are configured on each AGG, each L3VE sub-interface is bound to one
VPN instance, and the CSGs access the L3VPN through the L3VE sub-interfaces. To improve
network resource usage and reliability, carriers expect that AGG1 transmits RNC-to-CSG1 and
RNC-to-CSG2 traffic and that AGG2 transmits RNC-to-CSG3 and RNC-to-CSG4 traffic.
Figure 1-9 Networking for an L2VPN accessing an L3VPN
CSG1
NodeB
AGG1
RSG1
CSG2
NodeB
BGP/MPLS IP VPN
NodeB RNC
CSG3
RSG2
AGG2
NodeB
CSG4
Primary PW L2VE Sub-interface
Secondary PW L3VE Sub-interface
To meet the preceding requirements, perform the following steps on each AGG:
1. Configure the AGG to advertise Address Resolution Protocol (ARP) Vlink direct routes.
2. Configure a cost for ARP Vlink direct routes and routes to the directly connected network
segment on the L3VE sub-interface of the secondary pseudo wire (PW).
3. Configure a static route to each NodeB and allow the static route to inherit the cost of the
route to which the static route is iterated.

NOTE
After this configuration is complete, each static route is iterated to an ARP Vlink direct route that is
generated on an L3VE sub-interface, and the static route inherits the cost of the ARP Vlink direct route.
Because no cost is configured for ARP Vlink direct routes on the L3VE sub-interface of the primary PW,
the default cost 0 takes effect on these routes, and static routes inherit the cost 0 after they are iterated to
the ARP Vlink direct routes.
4. Import the static routes to the BGP routing table.
NOTE
After a static route is imported to the BGP routing table, the cost is changed to the BGP route Multi-Exit
discrimination (MED), but the value remains unchanged. The cost of the static route to one NodeB varies
with the AGG, so does the BGP route MED.
After the preceding configurations are complete, each AGG advertises the route destined for
each NodeB to its BGP VPNv4 peers (RSGs). The RSGs can receive two routes with the same
prefix (destined for the same NodeB) and select an optimal route with a smaller MED value
from the two routes. Consequently, RSGs select routes advertised by AGG1 as the primary routes
to CSG1 and CSG2 and routes advertised by AGG2 as the primary routes to CSG3 and CSG4.
The AGGs therefore load-balance RNC-to-CSG traffic.
Before configuring AGGs to load-balance RNC-to-CSG traffic, configure link-layer protocol
parameters and IP addresses for interfaces and ensure that the link layer protocol on each
interface is Up.
Data Preparation
No. Data
1 Cost for ARP Vlink direct routes and routes to the directly connected network segment
on the L3VE sub-interface of the secondary PW
Procedure
Step 1 Configure the AGGs to advertise ARP Vlink direct routes.
1. Run:
system-view

2. Run:
ip vpn-instance vpn-instance
The VPN instance view is displayed.

3. Run:
arp vlink-direct-route advertise
The AGG is configured to advertise ARP Vlink direct routes.

4. Run:

quit
Step 2 Configure a cost for ARP Vlink direct routes and routes to the directly connected network
segment on the L3VE sub-interface of the secondary PW.
1. Run:
A VE interface is created, and the VE interface view is displayed.

2. Run:
The VE interface is configured as an L3VE interface that accesses a BGP/Multiprotocol

Label Switching (MPLS) IP VPN and bound to a VE group.
NOTE
The L2VPN can access the L3VPN only if the Layer 2 Virtual Ethernet (L2VE) and L3VE interfaces
are bound to the same VE group and reside on the same board.
3. Run:
quit

4. Run:
A VE sub-interface is created, and the VE sub-interface view is displayed.

5. Run:
direct-route cost cost
A cost is configured for ARP Vlink direct routes and routes to the directly connected
network segment on the L3VE sub-interface of the secondary PW.
By default, the cost of ARP Vlink direct routes and routes to the directly connected network
segment on L3VE sub-interfaces is 0.

NOTE
l If both the direct-route cost and direct-route track pw-state commands are run, the cost of
routes to the directly connected network segment is calculated according to the following rules:
l If the PW is active, the cost is the value configured using the direct-route cost command.
l If the PW is standby or Down, the cost is the value configured using the direct-route cost
command plus that configured using the direct-route track pw-state command. If the
calculated cost is greater than the maximum value (4294967295), 4294967295 takes effect.
l If both the direct-route cost and direct-route track vrrp commands are run, the cost of routes
to the directly connected network segment is calculated according to the following rules:
l If the device is the master of the VRRP backup group, the cost is the value configured using
the direct-route cost command.
l If the device is a backup device of the VRRP backup group, the cost is the value configured
using the direct-route cost command plus that configured using the direct-route track
vrrp command. If the calculated cost is greater than the maximum value (4294967295),
4294967295 takes effect.
l If both the direct-route cost and direct-route track eth-trunk commands are run, the cost of
routes to the directly connected network segment is calculated according to the following rules:
l If the Eth-Trunk interface is master or the system cannot query the state of the Eth-Trunk
interface, the cost is the value configured using the direct-route cost command.
l If the Eth-Trunk interface is a backup interface, the cost is the value configured using the
direct-route cost command plus that configured using the direct-route track eth-trunk
command. If the calculated cost is greater than the maximum value (4294967295),
4294967295 takes effect.
l If both the direct-route cost and direct-route degrade-delay commands are run and the L3VE
sub-interface goes from Down to Up, the cost of routes to the directly connected network segment
is calculated according to the following rules:
l After the delay expires, the cost is the value configured using the direct-route cost command.
l Before the delay expires, the cost is the value configured using the direct-route cost
command plus that configured using the direct-route degrade-delay command. If the
calculated cost is greater than the maximum value (4294967295), 4294967295 takes effect.
6. Run:
quit
Step 3 Run:
ip route-static vpn-instance vpn-source-name destination-address { mask | mask-
length } nexthop-address [ preference preference | tag tag ] * inherit-cost
[ description text ]
A static route is configured for a specified VPN instance and allowed to inherit the cost of the
route to which the static route is iterated.
vpn-source-name specifies the VPN instance that is bound to the L3VE sub-interface, and
nexthop-address specifies the destination address of the route to which the static route is iterated.
Step 4 Run either of the following commands:

l To import static routes to the BGP routing table automatically, run the import-route
static command.
l To import static routes to the BGP routing table manually, run the network command.

If you run the import-route static command, some unneeded static routes may be imported to
the BGP routing table. To import a static route with a specific prefix and mask to the BGP routing
table, run the network command.
----End

If an AGG's L3VE sub-interface is Up, run the display ip routing-table vpn-instance vpn-
instance-name [ ip-address ] [ verbose ] command on the AGG. The command output shows
that the cost of ARP Vlink direct routes and routes to the directly connected network segment
on the L3VE sub-interface is the configured value.
1.15 Configuring the Advertisement of IPv4 ARP Vlink

Direct Routes on the Public Network
Advertising IPv4 ARP Vlink direct routes on the public network allows precise control of data
traffic.

Before advertising IPv4 ARP Vlink direct routes on the public network, familiarize yourself
with the usage scenario, and complete the pre-configuration tasks, and obtain the data required
for the configuration.
IP packets are forwarded through a specified physical interface, but cannot be forwarded through
a VLANIF interface. If packets reach a VLANIF interface, the device obtains information about
the physical interfaces using IPv4 ARP and generates relevant routing entries. The routes
recorded by the routing entries are called IPv4 ARP Vlink direct routes.
In most cases, IPv4 ARP Vlink direct routes are used only to guide local traffic forwarding and
are not advertised. In this manner, the scale and stability of the routing table can be controlled.
In certain situations, however, different operations have to be performed on specific routes of
VLAN users (for example, different traffic export policies have to be applied to the specific
routes to direct remote traffic). IPv4 ARP Vlink direct routes need to be imported to the dynamic
routing protocol and advertised to the remote end.
As shown in Figure 1-10, Router D uses VLANIF interfaces to connect to Routers A, B, and C
at three sites. Router E only needs to communicate with Router B, but not with Router A or
Router C. You can configure Router D to advertise IPv4 ARP Vlink direct routes and configure
a route-policy on Router D to filter out routes to the network segment of the VLAN for which
the VLANIF interfaces are configured and filter out routes to Router A and Router C.

Figure 1-10 Networking diagram of advertising IPv4 ARP Vlink direct routes on the public
network
192.168.0.3/24
RouterA
192.168.0.4/24 SwitchA RouterD

BGP
RouterB VLANIF10 VLANIF10

192.168.0.2/24 192.168.0.1/24 RouterE
192.168.0.5/24
RouterC
Before advertising IPv4 ARP Vlink direct routes on the public network, complete the following
task:
l Configuring parameters of a link layer protocol and assigning an IP address to each interface
to ensure that the link layer protocol on the interfaces is Up
Data Preparation
To advertise IPv4 ARP Vlink direct routes on the public network, you need the following data.
No. Data
1 (Optional) Route-policy name and node ID
1.15.2 Enabling the Advertisement of IPv4 ARP Vlink Direct Routes

IPv4 ARP Vlink direct routes can be imported to and advertised by a dynamic protocol only if
advertising IPv4 ARP Vlink direct routes is enabled. Advertising IPv4 ARP Vlink direct routes
allows the remote device to precisely control traffic.
Context
Before IPv4 ARP Vlink direct routes are advertised, a route-policy can be configured to filter
the advertised routes and only routes that match the route-policy can be advertised. In this
manner, data traffic can be precisely controlled.
Perform the following steps on the router on which IPv4 ARP Vlink direct routes need to be
advertised:

Procedure
Step 1 Run:
system-view

Step 2 Run:
arp vlink-direct-route advertise [ route-policy route-policy-name ]
Advertising IPv4 ARP Vlink direct routes is enabled.

By default, IPv4 ARP Vlink direct routes cannot be advertised.
If IPv4 ARP Vlink direct routes have to be advertised, you can specify the parameter route-
policy route-policy-name in the arp vlink-direct-route advertise command to filter the
advertised IPv4 ARP Vlink direct routes.
NOTE
At present, apply clauses cannot be used to set routing attributes for routes that match the filtering rules.
----End
Follow-up Procedure
After advertising IPv4 ARP Vlink direct routes is enabled, IPv4 ARP Vlink direct routes can be
advertised only if they are imported to a dynamic routing protocol. Perform the following steps
on the router based on the type of the dynamic routing protocol:
l If RIP is used, run the import-route direct [ cost cost | route-policy route-policy-name ]
* command to import IPv4 ARP Vlink direct routes to RIP.
l If OSPF is used, run the import-route direct [ cost cost | route-policy route-policy-
name | tag tag | type type ] * command to import IPv4 ARP Vlink direct routes to OSPF.
l If IS-IS is used, run the import-route direct [ cost-type { external | internal } | cost
cost | tag tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ] * command
to import IPv4 ARP Vlink direct routes to IS-IS.
l If BGP is used, run the import-route direct [ med med | route-policy route-policy-
name ] * command to import IPv4 ARP Vlink direct routes to BGP.

After the advertisement of IPv4 ARP Vlink direct routes has been configured successfully, view
information about advertised IPv4 ARP Vlink direct routes on the public network.
Prerequisites
The advertisement of IPv4 ARP Vlink direct routes on the public network has been configured.
Procedure
l Run the display ip routing-table ip-address [ mask | mask-length ] [ longer-match ]
[ verbose ] command to check information about advertised IPv4 ARP Vlink direct routes
----End

Example
# Run the display ip routing-table ip-address mask-length verbose command to view detailed
information about the IPv4 ARP Vlink direct route 10.1.1.4/32.
<HUAWEI> display ip routing-table 10.1.1.4 32 verbose
------------------------------------------------------------------------------
Summary Count : 1
Protocol: Direct Process ID: 0
Tag: 0 Priority: high
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: Vlanif10
The command output shows that the route status is Active Adv, indicating that the route is active
and can be advertised.
1.16 Configuring the Advertisement of IPv6 NDP Vlink

Direct Routes on the Public Network
On an IPv6 public network, advertising IPv6 neighbor discover protocol (NDP) Vlink direct
routes allows precise control of data traffic.

Before advertising IPv6 NDP Vlink direct routes on the public network, familiarize yourself
with the usage scenario, complete the pre-configuration tasks, and obtain the data required for
the configuration.
IP packets are forwarded through a specified physical interface, but cannot be forwarded through
a VLANIF interface. If packets reach a VLANIF interface, the device obtains information about
the physical interfaces using IPv6 NDP and generates relevant routing entries. The routes
recorded by the routing entries are called IPv6 NDP Vlink direct routes.
In most cases, IPv6 NDP Vlink direct routes are used only to guide local traffic forwarding and
are not advertised. In this manner, the scale and stability of the routing table can be controlled.
In certain situations, however, different operations have to be performed on specific routes of
VLAN users (for example, different traffic export policies have to be applied to the specific
routes to direct remote traffic). In this case, some IPv6 NDP Vlink direct routes need to be
imported to the dynamic routing protocols and advertised to the remote end.
As shown in Figure 1-11, Router D uses VLANIF interfaces to connect to Routers A, B, and C
at three sites. Router E only needs to communicate with Router B, but not with Router A and
Router C. You can configure Router D to advertise IPv6 NDP Vlink direct routes and configure
a route-policy on Router D to filter out routes to the network segment of the VLAN for which
the VLANIF interfaces are configured and filter out routes to Router A and Router C.

Figure 1-11 Networking diagram of advertising IPv6 NDP Vlink direct routes on the public
network
RouterA
2001::3/64
RouterB SwitchA RouterD

BGP
2001::4/64 VLANIF10 VLANIF10

2001::2/64 2001::1/64 RouterE
RouterC
2001::5/64
Before advertising IPv6 NDP Vlink direct routes on the public network, complete the following
task:
l Configuring parameters of a link layer protocol and assigning an IP address to each interface
to ensure that the link layer protocol on the interfaces is Up
Data Preparation
To advertise IPv6 NDP Vlink direct routes on the public network, you need the following data.
No. Data
1 (Optional) Route-policy name and node ID
1.16.2 Enabling the Advertisement of IPv6 NDP Vlink Direct

Routes
IPv6 NDP Vlink direct routes can be imported to dynamic routing protocols and advertised only
if the function of advertising IPv6 NDP Vlink direct routes is enabled. Advertising IPv6 NDP
Vlink direct routes allows the remote device to precisely control traffic.
Context
Before IPv6 NDP Vlink direct routes are advertised, a route-policy can be used to filter the
advertised routes and only routes that pass the filtering can be advertised. In this manner, data
traffic can be precisely controlled.

Perform the following steps on the router on which IPv6 NDP Vlink direct routes need to be
advertised:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 nd vlink-direct-route advertise [ route-policy route-policy-name ]
Advertising IPv6 NDP Vlink direct routes is enabled.
By default, IPv6 NDP Vlink direct routes cannot be advertised.
If IPv6 NDP Vlink direct routes have to be advertised, you can specify the parameter route-
policy route-policy-name in the ipv6 nd vlink-direct-route advertise command to filter IPv4
ARP Vlink direct routes.
NOTE
At present, apply clauses cannot be used to set routing attributes for routes that match the filtering rules.
----End
Follow-up Procedure
After advertising IPv6 NDP Vlink direct routes is enabled, IPv6 NDP Vlink direct routes can
be advertised only if they are imported to dynamic routing protocols. Perform the following
steps on the router based on the type of the dynamic routing protocol:
l If RIPng is used, run the import-route direct [ cost cost | route-policy route-policy-
name ] * command to import IPv6 NDP Vlink direct routes to RIPng.
l If OSPFv3 is used, run the import-route direct [ cost cost | inherit-cost | route-policy
route-policy-name | tag tag | type type ] * command to import IPv6 NDP Vlink direct routes
to OSPFv3.
l If IS-IS is used, run the import-route direct [ cost-type { external | internal } | cost
cost | tag tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ] * command
to import IPv6 NDP Vlink direct routes to IS-IS.
l If BGP4+ is used, run the import-route direct [ med med | route-policy route-policy-
name ] * command to import IPv6 NDP Vlink direct routes to BGP4+.

After the advertisement of IPv6 NDP Vlink direct routes has been configured successfully, view
information about advertised IPv6 NDP Vlink direct routes on the public network.
Prerequisites
All configurations relevant to the advertisement of IPv6 NDP Vlink direct routes has been
configured.

Procedure
l Run the display ipv6 routing-table ipv6-address [ prefix-length ] [ longer-match ]
[ verbose ] command to check information about advertised IPv6 NDP Vlink direct routes
----End
Example
# Run the display ipv6 routing-table ipv6-address [ mask | mask-length ] verbose command
to view detailed information about the IPv6 NDP Vlink direct route 2001:db8:2000::4/128.
<HUAWEI> display ipv6 routing-table 2001:db8:2000::4 128 verbose
Routing Table :
Summary Count : 1

NextHop : 2001:db8:2000::4 Preference : 0
Neighbour : :: ProcessID : 0
Label : NULL Protocol : Direct
Entry ID : 266288988 EntryFlags : 0xa0010050
Priority : high Age : 15sec
IndirectID : 0x0
Interface : Vlanif10 Flags : D
The command output shows that the route status is Active Adv, indicating that the route is active
and can be advertised.
1.17 Maintaining the Route Management Module

The operations of Route Management (RM) maintenance include configuring thresholds for the
number of route prefixes on a device and configuring a limit on the number of public route
prefixes.
1.17.1 Configuring Thresholds for the Number of IPv4 Route

Prefixes
This section describes how to configure thresholds (one alarm threshold and one clear alarm
threshold) for the number of IPv4 route prefixes on a device. After the thresholds are configured,
an alarm is generated when the number of IPv4 route prefixes on the device exceeds the alarm
threshold, and the alarm is cleared when the number of IPv4 route prefixes falls below the clear
alarm threshold. Configuring these thresholds facilitates maintenance.
Context
The number of IPv4 route prefixes that can be added to a routing table is limited. If the number
exceeds the limit, new prefixes cannot be added to the routing table, which may interrupt
services. To address this problem, configure an alarm threshold for the number of IPv4 route
prefixes.
An alarm is generated when the following conditions are met:

l The alarm function is enabled for the routing management (RM) module using the snmp-
agent trap enable feature-name rm command.
l The number of IPv4 route prefixes on the device exceeds the alarm threshold.
The alarm informs users that an abnormality may exist and to take corrective actions.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip prefix-limit system threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value
Two thresholds (one alarm threshold and one clear alarm threshold) are configured for the
number of IPv4 route prefixes on the device.
By default, the alarm threshold for IPv4 route prefixes is 80%, and the clear alarm threshold for
IPv4 route prefixes is 70%.
NOTE
When you configure upper-limit-value and lower-limit-value, note the following suggestions:
l Set a value less than or equal to 95 for upper-limit-value.
l lower-limit-value must be less than upper-limit-value. Set lower-limit-value to a value at least 10 less
than upper-limit-value to prevent alarms from being frequently generated and cleared due to route
flapping.
----End
1.17.2 Configuring Thresholds for the Number of IPv6 Route

Prefixes
This section describes how to configure thresholds (one alarm threshold and one clear alarm
threshold) for the number of IPv6 route prefixes on a device. After the thresholds are configured,
an alarm is generated when the number of IPv6 route prefixes on the device exceeds the alarm
threshold, and the alarm is cleared when the number of IPv6 route prefixes falls below the clear
alarm threshold. Configuring these thresholds facilitates maintenance.
Context
The number of IPv6 route prefixes that can be added to a routing table is limited. If the number
exceeds the limit, new prefixes cannot be added to the routing table, which may interrupt
services. To address this problem, configure an alarm threshold for the number of IPv6 route
prefixes.
An alarm is generated when the following conditions are met:
l The alarm function is enabled for the routing management (RM) module using the snmp-
agent trap enable feature-name rm command.
l The number of IPv6 route prefixes on the device exceeds the alarm threshold.
The alarm informs users that an abnormality may exist and to take corrective actions.

Procedure
Step 1 Run:
system-view

Step 2 Run:
ipv6 prefix-limit system threshold-alarm upper-limit upper-limit-value lower-limit
lower-limit-value
Two thresholds (one alarm threshold and one clear alarm threshold) are configured for the
number of IPv6 route prefixes on the device.
By default, the alarm threshold for IPv6 route prefixes is 80%, and the clear alarm threshold for
IPv6 route prefixes is 70%.
NOTE
When you configure upper-limit-value and lower-limit-value, note the following suggestions:
l Set a value less than or equal to 95 for upper-limit-value.
l lower-limit-value must be less than upper-limit-value. Set lower-limit-value to a value at least 10 less
than upper-limit-value to prevent alarms from being frequently generated and cleared due to route
flapping.
----End
1.17.3 Configuring a Limit on the Number of IPv4 Public Route

Prefixes
This section describes how to configure a limit on the number of IPv4 public route prefixes to
improve system security and reliability.
Context
If the router imports a large number of routes, system performance may be affected when
processing services because the routes consume a lot of system resources. To improve system
security and reliability, configure a limit on the number of IPv4 public route prefixes. When the
number of IPv4 public route prefixes exceeds the limit, an alarm is generated, prompting you to
check whether unneeded IPv4 public route prefixes exist.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip prefix-limit number { alert-percent [ route-unchanged ] | simply-alert }
A limit is configured on the number of IPv4 public route prefixes.

alert-percent indicates the percentage of the maximum number of IPv4 public route prefixes
that is supported. If you specify alert-percent in the command, when the number of IPv4 public
route prefixes exceeds the value calculated by number x alert-percent/100, an alarm is generated.

Additional IPv4 public route prefixes can still be added to the routing table until the number of
IPv4 public route prefixes reaches number. Subsequent route prefixes are discarded.
If you specify simply-alert in the command, additional IPv4 public route prefixes can still be
added to the routing table and only an alarm is generated after the number of IPv4 public route
prefixes exceeds 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
IPv4 public route prefixes are discarded.
If you decrease alert-percent after the number of IPv4 public route prefixes exceeds number,
whether the routing table remains unchanged is determined by route-unchanged.
l If you specify route-unchanged in the command, the routing table remains unchanged.
l If you do not specify route-unchanged in the command, the system deletes the routes from
the routing table and re-adds routes.
By default, the system deletes the routes from the routing table and re-adds routes.
NOTE
After the number of IPv4 public route prefixes exceeds the limit, note the following rules:
l If you run the ip prefix-limit command to increase number or the undo ip prefix-limit command to
delete the limit, the router relearns IPv4 public route prefixes.
l Direct and static routes can still be added to the IP routing table.
l The snmp-agent trap enable feature-name rm command must have been run so that alarms can be
generated.

ip prefix-limit log-interval interval
An interval is specified for the system to generate logs after the number of IPv4 public route
prefixes exceeds the limit.
By default, the system generates logs at an interval of 5s after the number of IPv4 public route
You can run the command to set a larger value for the interval to decrease the frequency at which
these logs are generated.
----End
1.17.4 Configuring a Limit on the Number of IPv6 Public Route

Prefixes
This section describes how to configure a limit on the number of IPv6 public route prefixes to
improve system security and reliability.
Context
If the router imports a large number of routes, system performance may be affected when
processing services because the routes consume a lot of system resources. To improve system
security and reliability, configure a limit on the number of IPv6 public route prefixes. When the
number of IPv6 public route prefixes exceeds the limit, an alarm is generated, prompting you to
check whether unneeded IPv6 public route prefixes exist.

Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 prefix-limit number { alert-percent [ route-unchanged ] | simply-alert }
A limit is configured on the number of IPv6 public route prefixes.
alert-percent indicates the percentage of the maximum number of IPv6 public route prefixes
that is supported. If you specify alert-percent in the command, when the number of IPv6 public
route prefixes exceeds the value calculated by number x alert-percent/100, an alarm is generated.
Additional IPv6 public route prefixes can still be added to the routing table until the number of
IPv6 public route prefixes reaches number. Subsequent route prefixes are discarded.
If you specify simply-alert in the command, additional IPv6 public route prefixes can still be
added to the routing table and only an alarm is generated after the number of IPv6 public route
prefixes exceeds 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
IPv6 public route prefixes are discarded.
If you decrease alert-percent after the number of IPv6 public route prefixes exceeds number,
whether the routing table remains unchanged is determined by route-unchanged.
l If you specify route-unchanged in the command, the routing table remains unchanged.
l If you do not specify route-unchanged in the command, the system deletes the routes from
the routing table and re-adds routes.
By default, the system deletes the routes from the routing table and re-adds routes.
NOTE
After the number of IPv6 public route prefixes exceeds the limit, note the following rules:
l If you run the ipv6 prefix-limit command to increase number or the undo ipv6 prefix-limit command
to delete the limit, the router relearns IPv6 public route prefixes.
l Direct and static routes can still be added to the IPv6 routing table.
l The snmp-agent trap enable feature-name rm command must have been run so that alarms can be
generated.

ipv6 prefix-limit log-interval interval
An interval is specified for the system to generate logs after the number of IPv6 public route
By default, the system generates logs at an interval of 5s after the number of IPv6 public route
You can run the command to set a larger value for the interval to decrease the frequency at which
these logs are generated.
----End

1.18 Configuration Example

IP routing configuration examples provide networking requirements, networking diagrams,
NOTE
Examples in this document use interface numbers and link types of the NE40E-X8. In real world situations,
the interface numbers and link types may be different from those used in this document.
1.18.1 Example for Configuring Public Network IP FRR

After public network IP FRR is configured, traffic can be rapidly switched to the backup link if
the primary link becomes faulty.
Networking Requirements
As shown in Figure 1-12, it is required that link B functions as the backup of link A. In this
manner, if a fault occurs on link A, traffic can be rapidly switched to link B.
Figure 1-12 Networking for configuring Public network IP FRR

GE1/0/0 GE2/0/0
192.167.10.2/24 192.167.11.2/24
GE2/0/0 GE2/0/0
RouterA
192.167.10.1/24 192.167.11.1/24
GE1/0/0 Link A GE1/0/0
172.18.1.1/24 172.17.1.1/24
RouterT RouterC
GE3/0/0 Link B GE3/0/0
192.167.20.1/24 192.167.21.1/24
GE1/0/0 GE2/0/0
192.167.20.2/24 192.167.21.2/24
RouterB
Configuration Roadmap
The configuration roadmap is as follows:
1. Enable basic OSPF functions on each router to allow them to learn routes from each other.
2. Set a greater cost for GE 3/0/0 of Router T and Router C so that OSPF prefers link A.
3. Configure a route-policy on Router T, configure the backup outbound interface and backup
next hop, and enable public network IP FRR to ensure that link B functions as the backup
of link A
Data Preparation

l Cost (100) of an OSPF interface

l Name of the route-policy and number of the node
l Backup outbound interface (GE 3/0/0) and backup next hop (192.167.20.2)
Configuration procedure
1. Configure an IP address for each interface.
The configuration details are not described here.
2. Configure OSPF on Router T, Router A, Router B, and Router C.
3. Set a cost on an OSPF interface.
# Set a cost on Gigabit Ethernet 3/0/0 of Router T so that OSPF prefers link A.
[RouterT] interface gigabitethernet 3/0/0
[RouterT-GigabitEthernet3/0/0] ospf cost 100
[RouterT-GigabitEthernet3/0/0] quit
# Set a greater cost on Gigabit Ethernet 3/0/0 of Router C so that OSPF prefers link A.
[RouterC] interface gigabitethernet 3/0/0
[RouterC-GigabitEthernet3/0/0] ospf cost 100
[RouterC-GigabitEthernet3/0/0] quit
4. Configure a route-policy.
# Configure a route-policy on Router T, configure the backup outbound interface and
backup next hop, and configure an if-match clause to limit the application scope.
[RouterT] ip ip-prefix frr1 permit 172.17.1.1 24
[RouterT] route-policy ip_frr_rp permit node 10
[RouterT-route-policy] if-match ip-prefix frr1
[RouterT-route-policy] apply backup-nexthop 192.167.20.2
[RouterT-route-policy] apply backup-interface gigabitethernet3/0/0
[RouterT-route-policy] quit
5. Enable public network IP FRR.

[RouterT] ip frr route-policy ip_frr_rp
# Check information about the backup outbound interface and backup next hop on Router
T.
[RouterT] display ip routing-table 172.17.1.0 verbose
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x0
BkNextHop: 192.167.20.2 BkInterface: GigabitEthernet3/0/0
BkIndirectID: 0x0
6. If IP FRR is not required, run the undo ip frr command to disable IP FRR.
[RouterT] undo ip frr

# After IP FRR is disabled, check information about the backup outbound interface and
backup next hop.
[RouterT] display ip routing-table 172.17.1.0 verbose
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x0
Configuration Files
l Configuration file of Router T
#
sysname RouterT
#
ip frr route-policy ip_frr_rp
#
interface GigabitEthernet2/0/0
ip address 192.167.10.1 255.255.255.0
#
ip address 192.167.20.1 255.255.255.0
ospf cost 100
#
ip address 172.18.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.167.10.0 0.0.0.255
network 192.167.20.0 0.0.0.255
area 0.0.0.1
network 172.18.1.0 0.0.0.255
#
ip ip-prefix frr1 index 10 permit 172.17.1.0 24
#
route-policy ip_frr_rp permit node 10
if-match ip-prefix frrl
apply backup-nexthop 192.167.20.2
apply backup-interface GigabitEthernet3/0/0
#
return
l Configuration file of Router A

#
sysname RouterA
#
ip address 192.167.10.2 255.255.255.0
#
ip address 192.167.11.2 255.255.255.0
#
ospf 1
area 0.0.0.0

network 192.167.10.0 0.0.0.255

network 192.167.11.0 0.0.0.255
#
return
l Configuration file of Router B

#
sysname RouterB
#
ip address 192.167.20.2 255.255.255.0
#
ip address 192.167.21.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.167.20.0 0.0.0.255
network 192.167.21.0 0.0.0.255
#
return
l Configuration file of Router C

#
sysname RouterC
#
ip address 172.17.1.1 255.255.255.0
#
ip address 192.167.11.1 255.255.255.0
#
ip address 192.167.21.1 255.255.255.0
ospf cost 100
#
ospf 1
area 0.0.0.0
network 192.167.11.0 0.0.0.255
network 192.167.21.0 0.0.0.255
area 0.0.0.2
network 172.17.1.0 0.0.0.255
#
return
1.18.2 Example for Configuring Public Network IPv6 FRR

After public network IPv6 FRR is configured, traffic can be switched to the backup link
immediately after the active link becomes faulty.
As networks develop, services such as audio, online video, and finance have more requirements
for real-time transmission. Generally, both active and backup links are deployed to ensure service
stability. However, in traditional forwarding modes, link switchover depends on route
convergence, which takes a longer time and cannot meet service requirements. IPv6 FRR can
solve this problem.
As shown in Figure 1-13, two links are configured between Router T and the network
2001:db8:2::2/128 to back up each other. The carrier requires that link B function as the backup
of link A. In this way, after link A becomes faulty, traffic can be switched to link B immediately.
The requirement can be met by configuring IPv6 FRR on Router T.

Figure 1-13 Networking diagram for configuring public network IPv6 FRR
GE1/0/0 GE2/0/0
2001:db8:2000::2/64 2001:db8:2002::1/64
RouterA GE2/0/0
GE1/0/0 2001:db8:2002::2/64
2001:db8:2000::1/64 Link A Loopback1
2001:db8:2::2/128
RouterT
RouterC
GE2/0/0 Link B GE1/0/0
2001:db8:2001::1/64 2001:db8:2003::2/64
GE2/0/0 GE1/0/0
2001:db8:2001::2/64 2001:db8:2003::1/64
RouterB
1. Configure dynamic routing protocols on each router so that they can learn routes from each
other. OSPFv3 is used in this example.
2. Set the costs for GE 2/0/0 on Router T and GE 1/0/0 on Router C to be greater than those
for GE 1/0/0 on Router T and GE 2/0/0 on Router C so that OSPFv3 preferentially selects
link A.
3. Configure a route policy on Router T, configure a backup next hop and a backup outbound
interface, and enable IPv6 FRR on the public network to allow link B to function as the
backup link for link A.
Data Preparation
l Router ID of Router T (1.1.1.1), router ID of Router A (2.2.2.2), router ID of Router B

(3.3.3.3), and router ID of Router C (4.4.4.4)
l Cost (100) of GE 2/0/0 on Router T and GE 1/0/0 on Router C
l Name of the route policy (ipv6_frr_rp), node number (10), and IPv6 address prefix list
(frr1) used by if-match clauses
l Backup next hop (2001:db8:2001::2) and backup outbound interface (GE 2/0/0) for the
route to the network 2001:db8:2::2/128
Procedure
Step 1 Assign an IPv6 address for each interface.
Assign an IPv6 address for each interface according to Figure 1-13. For details, see configuration
files.
Step 2 Configure OSPFv3 on Router T, Router A, Router B, and Router C.

# Configure Router T.
<RouterT> system-view
[RouterT] ospfv3 1
[RouterT-ospfv3-1] router-id 1.1.1.1
[RouterT-ospfv3-1] quit
[RouterT] interface GigabitEthernet 1/0/0
[RouterT-GigabitEthernet1/0/0] ospfv3 1 area 0
[RouterT] interface GigabitEthernet 2/0/0
[RouterT-GigabitEthernet2/0/0] ospfv3 1 area 0
# Configure Router A.
<RouterA> system-view
[RouterA] ospfv3 1
[RouterA-ospfv3-1] router-id 2.2.2.2
[RouterA-ospfv3-1] quit
[RouterA] interface GigabitEthernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ospfv3 1 area 0
[RouterA-GigabitEthernet1/0/0] quit
# Configure Router B.
<RouterB> system-view
[RouterB] ospfv3 1
[RouterB-ospfv3-1] router-id 3.3.3.3
[RouterB-ospfv3-1] quit
[RouterB] interface GigabitEthernet 1/0/0
[RouterB-GigabitEthernet1/0/0] ospfv3 1 area 0
[RouterB-GigabitEthernet1/0/0] quit
# Configure Router C.
<RouterC> system-view
[RouterC] ospfv3 1
[RouterC-ospfv3-1] router-id 3.3.3.3
[RouterC-ospfv3-1] quit
[RouterC] interface GigabitEthernet 1/0/0
[RouterC-GigabitEthernet1/0/0] ospfv3 1 area 0
[RouterC] interface LoopBack 1
[RouterC-LoopBack1] ospfv3 1 area 0
[RouterC-LoopBack1] quit
Step 3 Set the cost for the OSPFv3 interface.

# Set the cost for GE 2/0/0 on Router T to 100.
[RouterT] interface gigabitethernet 2/0/0
[RouterT-GigabitEthernet2/0/0] ospfv3 cost 100
# Set the cost for GE 1/0/0 on Router C to 100.

[RouterC-GigabitEthernet1/0/0] ospfv3 cost 100

The cost for GE 1/0/0 on Router T and GE 2/0/0 on Router C use the default cost value 1 so that
OSPFv3 prefers Link A.
Step 4 Configure a route-policy.
# Configure a route-policy on Router T and configure a backup next hop and a backup outbound
interface. Configure an if-match clause.
[RouterT] ip ipv6-prefix frr1 permit 2001:db8:2::2 128
[RouterT] route-policy ipv6_frr_rp permit node 10
[RouterT-route-policy] if-match ipv6 address prefix-list frr1
[RouterT-route-policy] apply ipv6 backup-nexthop 2001:db8:2001::2
[RouterT-route-policy] apply ipv6 backup-interface GigabitEthernet2/0/0
[RouterT-route-policy] quit
Step 5 Enable IPv6 FRR on the public network.

[RouterT] ipv6 frr route-policy ipv6_frr_rp
# View information about the backup outbound interface and the backup next hop on Router T.
[RouterT] display ipv6 routing-table 2001:db8:2::2 verbose
Routing Table :
Summary Count : 1

IndirectID : 0x0
BkNextHop : 2001:db8:2001::2 BkInterface : GigabitEthernet2/0/0
BkLabel : NULL BkTunnelID : 0x0
BkPETunnelID : 0x0 BkIndirectID : 0x0
Step 6 If IPv6 FRR is not required, run the undo ipv6 frr command to disable the function.
[RouterT] undo ipv6 frr
# After IPv6 FRR is disabled, check information about the backup outbound interface and the
backup next hop.
[RouterT] display ipv6 routing-table 2001:db8:2::2 verbose
Routing Table :
Summary Count : 1

IndirectID : 0x0
----End

Configuration Files
l Configuration file of Router T
#
sysname RouterT
#
ipv6
#
ipv6 frr route-policy ipv6_frr_rp
#
ospfv3 1
router-id 1.1.1.1
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2000::1/64
ospfv3 1 area 0.0.0.0
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2001::1/64
ospfv3 cost 100
#
route-policy ipv6_frr_rp permit node 10
if-match ipv6 address prefix-list frr1
apply ipv6 backup-nexthop 2001:db8:2001::2
apply ipv6 backup-interface GigabitEthernet2/0/0
#
ip ipv6-prefix frr1 index 10 permit 2001:db8:2::2 128
#
return

#
sysname RouterA
#
ipv6
#
ospfv3 1
router-id 2.2.2.2
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2000::2/64
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2002::1/64
#
return

#
sysname RouterB
#
ipv6
#
ospfv3 1

router-id 3.3.3.3
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2003::1/64
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2001::2/64
#
return

#
sysname RouterC
#
ipv6
#
ospfv3 1
router-id 4.4.4.4
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2003::2/64
ospfv3 cost 100
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:2002::2/64
#
interface LoopBack1
ipv6 enable
ipv6 address 2001:db8:2::2/128
#
return
1.18.3 Example for Configuring VRRP for Direct Routes

If VRRP for direct routes is configured, the master UPE's interface adjusts the direct route's cost
based on the VRRP status. This allows the master UPE to perform a traffic switchback if
recovering from a fault.
On the IP RAN shown in Figure 1-14, if UPE1 recovers from a fault, its interface connected to
the RSG goes Up and then a direct route is generated, allowing a traffic switchback. As UPE1
has not learned the RSG's MAC address, UPE1 fails to switch back some packets. To help prevent
the problem, the direct route has to be generated after the VRRP status changes to Master.
Devices run OSPF to communicate with each other. UPE1 and UPE2 form a VRRP backup
group, which functions as a default gateway for the RSG. UPE1 functions as the master and
UPE2 functions as the backup. UPE2 takes over services from UPE1 if UPE1 fails. UPE1's

interface connected to the RSG is associated with the VRRP backup group, enabling the cost of
the direct route to the network segment where the interface resides to change based on the VRRP
status. VRRP for direct routes works as follows:
l If the VRRP status becomes Backup, the direct route's cost increases, lowering the direct
route's priority level. The direct route will no longer be an optimal route.
l If the VRRP status becomes Master, the direct route's cost is set to 0, allowing the direct
route's priority to be the highest. The direct route will be an optimal route.
Figure 1-14 Networking for configuring VRRP for direct routes
UPE1
GE1/0/0 GE2/0/0
GE1/0/0 GE1/0/0
VRRP RSG
CSG
GE2/0/0 GE2/0/0
NodeB RNC
GE1/0/0 GE2/0/0
UPE2
L2VPN L3VPN
Device Interface IP Address Device Interface IP Address
CSG GE 1/0/0 20.1.1.1/24 UPE2 GE 1/0/0 20.1.2.2/24
GE 2/0/0 20.1.2.1/24 GE 2/0/0 20.1.3.2/24
Loopback0 1.1.1.1/32 Loopback0 3.3.3.3/32
UPE1 GE 1/0/0 20.1.1.2/24 RSG Loopback0 4.4.4.4/32
GE 2/0/0 20.1.3.1/24
Loopback0 2.2.2.2/32
1. Configure OSPF on the CSG, UPE1, UPE2, and the RSG.

2. Create backup group 1 on GE 2/0/0 of UPE1, and assign a priority higher than the default
one to UPE1 so that UPE1 will function as the master.
3. Create backup group 1 on GE 2/0/0 of UPE2, and set the default priority for UPE2 so that
UPE2 will function as the backup.
4. Associate GE 2/0/0 on UPE1 with backup group 1, enabling the cost of the direct route to
the network segment where GE 2/0/0 resides to change based on the VRRP status.

Data Preparation
l VLAN ID
l ID and virtual IP address of a VRRP backup group
l Priority level of each device in a VRRP backup group
l Link cost of an interface associated with a VRRP backup group
Procedure
Step 1 Assign IP addresses to interfaces.
# Create VLAN 10 on the RSG and add GE 1/0/0 and GE 2/0/0 to VLAN 10.
<RSG> system-view
[RSG] interface gigabitethernet 1/0/0
[RSG-GigabitEthernet1/0/0] portswitch
[RSG-GigabitEthernet1/0/0] quit
[RSG] interface gigabitethernet 2/0/0
[RSG-GigabitEthernet2/0/0] portswitch
[RSG-GigabitEthernet2/0/0] quit
[RSG] vlan 10
[RSG-vlan10] port gigabitethernet 1/0/0
[RSG-vlan10] port gigabitethernet 2/0/0
# Assign IP addresses to physical interfaces. For detailed configurations, see configuration files
in this example.
Step 2 Configure OSPF to enable devices to communicate with each other. The details are not provided
here.
Step 3 Configure a VRRP backup group.
# Create backup group 1 on UPE1 and set the priority level of UPE1 to 120 so that UPE1 functions
as the master.
<UPE1> system-view
[UPE1] interface gigabitethernet 2/0/0
[UPE1-GigabitEthernet2/0/0] vrrp vrid 1 virtual-ip 20.1.3.111
[UPE1-GigabitEthernet2/0/0] vrrp vrid 1 priority 120
[UPE1-GigabitEthernet2/0/0] vrrp vrid 1 timer advertise 10
[UPE1-GigabitEthernet2/0/0] quit
# Create backup group 1 on UPE2 and set the priority level of UPE2 to 100 (the default value)
so that UPE2 functions as the backup.
<UPE2> system-view
[UPE2-GigabitEthernet2/0/0] vrrp vrid 1 virtual-ip 20.1.3.111
Step 4 Verify the configuration.
# After the preceding configuration, run the display vrrp command on UPE1 and UPE2. You
can view that the VRRP status of UPE1 is Master and the VRRP status of UPE2 is Backup. The
command output on UPE1 and UPE2 is as follows:
[UPE1] display vrrp
State : Master

Virtual IP : 20.1.3.111
PriorityRun : 120
Preempt : YES Delay Time : 0
TimerRun : 10 s
TimerConfig : 10 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0102
Check TTL : YES
Create time : 2010-08-16 12:02:57
Last change time : 2010-08-17 10:27:11
[UPE2] display vrrp
State : Backup
Virtual IP : 20.1.3.111
PriorityRun : 100
TimerRun : 10 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0102
Check TTL : YES
Create time : 2010-08-16 12:26:05
Last change time : 2010-08-17 10:24:09
# Run the display ip routing-table command on UPE1 and UPE2. You can view that a direct
route to the virtual IP address of the VRRP backup group exists in the UPE1's routing table and
an OSPF route to the virtual IP address of the VRRP backup group exists in the UPE2's routing
table. The command output on UPE1 and UPE2 is as follows:
[UPE1] display ip routing-table
------------------------------------------------------------------------------
Routing Tables: Public
20.1.1.0/24 Direct 0 0 D 20.1.1.2

20.1.1.2/32 Direct 0 0 D 127.0.0.1
20.1.2.0/24 OSPF 10 2 D 20.1.1.1
OSPF 10 2 D 20.1.3.2
20.1.3.0/24 Direct 0 0 D 20.1.3.1
20.1.3.1/32 Direct 0 0 D 127.0.0.1
------------------------------------------------------------------------------

20.1.1.0/24 OSPF 10 2 D 20.1.2.1

OSPF 10 2 D 20.1.3.1
20.1.2.0/24 Direct 0 0 D 20.1.2.2
20.1.2.2/32 Direct 0 0 D 127.0.0.1
20.1.3.0/24 Direct 0 0 D 20.1.3.2
20.1.3.2/32 Direct 0 0 D 127.0.0.1
20.1.3.111/32 OSPF 10 2 D 20.1.3.1
Step 5 Associate an interface with the VRRP backup group.

# Associate UPE1's GE 2/0/0 with backup group 1.
[UPE1-GigabitEthernet2/0/0] direct-route track vrrp vrid 1 degrade-cost 10203040
Step 6 Verify that UPE2 becomes the master if UPE1 fails and UPE1 preempts the master after it
recovers.
# Run the shutdown command on UPE1's GE 2/0/0 to simulate a fault.
[UPE1-GigabitEthernet2/0/0] shutdown
# Run the display vrrp command on UPE2. You can view that the VRRP status is Master. This
indicates that after UPE1 fails, UPE2 is able to become the master.
[UPE2] display vrrp
State : Master
Virtual IP : 20.1.3.111
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0102
Check TTL : YES
Create time : 2010-08-16 12:26:05
Last change time : 2010-08-17 12:02:07
# Run the undo shutdown and display vrrp commands on UPE1's GE 2/0/0. You can view that
the VRRP status of UPE1 is Backup.
[UPE1] display vrrp
State : Backup
Virtual IP : 20.1.3.111
PriorityRun : 120
MasterPriority : 0


TimerRun : 10 s
TimerConfig : 10 s
Auth Type : NONE
Virtual Mac : 0000-5e00-0102
Check TTL : YES
Create time : 2010-08-16 12:02:57
Last change time : 2010-08-17 12:05:02
# Run the display ip routing-table command on UPE1 to view routing information. The cost
of the direct route to 20.1.3.0/24 is 10203040. 20.1.3.0/24 is the network segment where GE
2/0/0 resides.
------------------------------------------------------------------------------
20.1.1.0/24 Direct 0 0 D 20.1.1.2

20.1.1.2/32 Direct 0 0 D 127.0.0.1
20.1.2.0/24 OSPF 10 2 D 20.1.1.1
20.1.3.0/24 Direct 0 10203040 D 20.1.3.1
20.1.3.1/32 Direct 0 0 D 127.0.0.1

# Wait 10 seconds for UPE1 to become the master; run the display ip routing-table command
on UPE1 to view the routing information. The cost of the direct route to 20.1.3.0/24 becomes
0. 20.1.3.0/24 is the network segment where GE 2/0/0 resides.
------------------------------------------------------------------------------
20.1.1.0/24 Direct 0 0 D 20.1.1.2

20.1.1.2/32 Direct 0 0 D 127.0.0.1
20.1.2.0/24 OSPF 10 2 D 20.1.1.1
OSPF 10 2 D 20.1.3.2
20.1.3.0/24 Direct 0 0 D 20.1.3.1
20.1.3.1/32 Direct 0 0 D 127.0.0.1
20.1.3.111/32 Direct 0 0 D 127.0.0.1
----End

Configuration Files
l Configuration file of the CSG
#
sysname CSG
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
#
undo shutdown
ip address 20.1.2.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 20.1.2.0 0.0.0.255
#
return
l Configuration file of UPE1

#
sysname UPE1
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
#
undo shutdown
ip address 20.1.3.1 255.255.255.0
vrrp vrid 1 virtual-ip 20.1.3.111
vrrp vrid 1 priority 120
vrrp vrid 1 timer advertise 10
direct-route track vrrp vrid 2 degrade-cost 10203040
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 20.1.3.0 0.0.0.255
#
return
l Configuration file of UPE2

#
sysname UPE2
#
undo shutdown
ip address 20.1.3.2 255.255.255.0
vrrp vrid 1 virtual-ip 20.1.3.111
#
undo shutdown
ip address 20.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 1

area 0.0.0.0
network 20.1.2.0 0.0.0.255
network 20.1.3.0 0.0.0.255
#
return
l Configuration file of the RSG

#
sysname RSG
#
vlan batch 10
#
portswitch
undo shutdown
port default vlan 10
#
portswitch
undo shutdown
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
return
1.18.4 Example for Importing IPv4 ARP Vlink Direct Routes to BGP
By importing IPv4 ARP Vlink direct routes to BGP, you can enable the remote device to obtain
information about detailed routes in the VLAN, allowing precise control of data traffic.
As networks develop, the VLAN technology is widely used. If a user outside a VLAN needs to
communicate with users within the VLAN, advertising routes destined for the network segment
of the VLAN can achieve this purpose. When users outside the VLAN need to know the IPv4
ARP Vlink direct routes of the VLAN, and apply different traffic policies to routes of the VLAN
users, advertising the routes destined for the network segment of the VLAN cannot meet this
requirement. In this case, you can enable the function of IPv4 ARP Vlink direct route
advertisement.
As shown in Figure 1-15, Router C is connected to two VLAN sites through VLANIF interfaces.
Router D communicates with Router B, but not with Router A. To meet the communication
requirement, you can enable the function of IPv4 ARP Vlink direct route advertisement on
Router C, and use a route-policy to filter out the routes to the network segment of the VLAN
and the route to Router A.

Figure 1-15 Networking diagram of importing IPv4 ARP Vlink direct routes to BGP
GE1/0/0
20.1.1.3/24 AS100
RouterA
SwitchA RouterC RouterD
GE1/0/0 GE2/0/0 GE1/0/0 BGP
GE3/0/0 VLANIF10 VLANIF10 GE2/0/0 GE1/0/0

RouterB 20.1.1.2/24 20.1.1.1/24 20.2.1.1/24 20.2.1.2/24
GE1/0/0
20.1.1.4/24
1. Create VLANIF interfaces on Switch A and Router C and assign IP addresses to the
VLANIF interfaces, and ensure that Router A, Router B, Switch A, and Router C can
communicate with each other.
2. Enable BGP on Router C and Router D, ensuring that Router C and Router D are able to
advertise IP routes to each other.
3. Enable the function of IPv4 ARP Vlink direct route advertisement on Router C.
4. Configure a route-policy on Router C, allowing routes only from Router B to pass through.
5. Enable BGP on Router C to import direct routes, and use the route-policy to import routes
only from Router B.
6. Associate BGP with the route-policy on Router C to filter out the network segment route
of the VLAN so that Router D cannot learn the network segment route and can communicate
with VLAN users only based on IPv4 ARP Vlink direct routes.
Data Preparation
l ID of the VLAN in which Switch A and Router C reside (the VLAN ID is 10 in this example)
l Router IDs and AS numbers of Routers C and D (router ID of Router C is 3.3.3.3 and router
ID of Router D is 4.4.4.4, and Routers C and D are in AS 100 in this example)
l Route-policy used to filter direct routes (the route-policy is policy1 in this example)
l Route-policy used to advertise BGP routes on Router C (the route-policy is policy2 in this
example)
Procedure
Step 1 Configure an IP address for each interface.
<HUAWEI> system-view

[HUAWEI] sysname RouterA

[RouterA-GigabitEthernet1/0/0] undo shutdown
[RouterA-GigabitEthernet1/0/0] ip address 20.1.1.3 24
[HUAWEI] sysname RouterB
[RouterB-GigabitEthernet1/0/0] undo shutdown
[RouterB-GigabitEthernet1/0/0] ip address 20.1.1.4 24
[HUAWEI] sysname RouterC
[RouterC-GigabitEthernet2/0/0] undo shutdown
[RouterC-GigabitEthernet2/0/0] ip address 20.2.1.1 24
# Configure Router D.
[HUAWEI] sysname RouterD
[RouterD] interface GigabitEthernet 1/0/0
[RouterD-GigabitEthernet1/0/0] undo shutdown
[RouterD-GigabitEthernet1/0/0] ip address 20.2.1.2 24
[RouterD-GigabitEthernet1/0/0] quit
Step 2 Configure basic VLAN functions. Create VLANIF 10 on Switch A and Router C and assign IP
addresses to the VLANIF interfaces.
# Configure Switch A.
[HUAWEI] sysname SwitchA
[SwitchA] vlan 10
[SwitchA-vlan10] quit
[SwitchA] interface GigabitEthernet 1/0/0
[SwitchA-GigabitEthernet1/0/0] portswitch
[SwitchA-GigabitEthernet1/0/0] undo shutdown
[SwitchA-GigabitEthernet1/0/0] port link-type access
[SwitchA-GigabitEthernet1/0/0] port default vlan 10
[SwitchA-GigabitEthernet1/0/0] quit
[SwitchA] interface Vlanif 10
[SwitchA-Vlanif10] ip address 20.1.1.2 24
[SwitchA-Vlanif10] quit

[RouterC] vlan 10
[RouterC-vlan10] quit
[RouterC-GigabitEthernet1/0/0] portswitch
[RouterC-GigabitEthernet1/0/0] port link-type access
[RouterC-GigabitEthernet1/0/0] port default vlan 10
[RouterC] interface Vlanif 10
[RouterC-Vlanif10] ip address 20.1.1.1 24
[RouterC-Vlanif10] quit
Step 3 Configure BGP between Router C and Router D.
[RouterC] bgp 100
[RouterC-bgp] peer 20.2.1.2 as-number 100
[RouterC-bgp] quit
[RouterD] bgp 100
[RouterD-bgp] peer 20.2.1.1 as-number 100
[RouterD-bgp] quit
Step 4 Configure BGP on Router C and import direct routes to BGP. Then view the routing tables of
Routers C and D.
[RouterC] bgp 100
[RouterC-bgp] import-route direct
[RouterC-bgp] quit
# Display the BGP routing table of Router C.

[RouterC] display bgp routing-table
BGP Local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 9

Network NextHop MED LocPrf PrefVal Path/Ogn
*> 20.1.1.0/24 0.0.0.0 0 0 ?

*> 20.1.1.1/32 0.0.0.0 0 0 ?
*> 20.1.1.2/32 0.0.0.0 0 0 ?
*> 20.1.1.3/32 0.0.0.0 0 0 ?
*> 20.1.1.4/32 0.0.0.0 0 0 ?
*> 20.2.1.0/24 0.0.0.0 0 0 ?
*> 20.2.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 ?
# Display the BGP routing table of Router D.

[RouterD] display bgp routing-table



*>i 20.1.1.0/24 20.2.1.1 0 100 0 ?

i 20.2.1.0/24 20.2.1.1 0 100 0 ?
You can see that Router D has not learned the two IPv4 ARP Vlink direct routes 20.1.1.3/32
and 20.1.1.4/32.
Step 5 Enable the function of IPv4 ARP Vlink direct route advertisement on Router C and configure
the route-policy policy1 to filter out the routes to the network segment of the VLAN and the
IPv4 ARP Vlink direct route from Router A, 20.1.1.3/32.
[RouterC] ip ip-prefix prefix1 permit 20.1.1.4 32
[RouterC] route-policy policy1 permit node 10
[RouterC-route-policy] if-match ip-prefix prefix1
[RouterC-route-policy] quit
[RouterC] arp vlink-direct-route advertise route-policy policy1
# Display the BGP routing table of Router C.



*> 20.1.1.0/24 0.0.0.0 0 0 ?

*> 20.1.1.1/32 0.0.0.0 0 0 ?
*> 20.1.1.2/32 0.0.0.0 0 0 ?
*> 20.1.1.3/32 0.0.0.0 0 0 ?
*> 20.1.1.4/32 0.0.0.0 0 0 ?
*> 20.2.1.0/24 0.0.0.0 0 0 ?
*> 20.2.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 ?



*>i 20.1.1.0/24 20.2.1.1 0 100 0 ?

*>i 20.1.1.4/32 20.2.1.1 0 100 0 ?
i 20.2.1.0/24 20.2.1.1 0 100 0 ?
You can see that Router D has learned the IPv4 ARP Vlink direct route 20.1.1.4/32, whereas
the route 20.1.1.3/32 has been filtered out.
Step 6 Use the route-policy policy2 to filter out the network segment route 20.1.1.0/24 on Router C
when BGP routes are advertised.

[RouterC] ip ip-prefix prefix2 index 10 deny 20.1.1.0 24
[RouterC] ip ip-prefix prefix2 index 20 permit 0.0.0.0 0 less-equal 32
[RouterC-route-policy] if-match ip-prefix prefix2
[RouterC] bgp 100
[RouterC-bgp] peer 20.2.1.2 route-policy policy2 export
[RouterC-bgp] quit
[RouterC] quit
<RouterC> refresh bgp all export


*>i 20.1.1.4/32 20.2.1.1 0 100 0 ?

i 20.2.1.0/24 20.2.1.1 0 100 0 ?
You can find that the route 20.1.1.0/24 does not exist in the BGP routing table of Router D. As
a result, Router D can communicate with Router B, but cannot communicate with Router A.
----End
Configuration Files
l Configuration file of Switch A
# sysname switchA # vlan batch 10 # interface Vlanif10 ip address 20.1.1.2
255.255.255.0 # interface GigabitEthernet1/0/0 portswitch undo shutdown port
link-type access port default vlan 10 # interface GigabitEthernet2/0/0
portswitch undo shutdown port link-type access port default vlan 10 # interface
GigabitEthernet3/0/0 portswitch undo shutdown port link-type access port
default vlan 10 # return

#
sysname switchA
#
vlan batch 10
#
interface Vlanif10
ip address 20.1.1.2 255.255.255.0
#
portswitch
undo shutdown
port link-type access
#
portswitch
undo shutdown
#
portswitch

undo shutdown
#
return

#
sysname RouterA
#
undo shutdown
ip address 20.1.1.3 255.255.255.0
#
return

#
sysname RouterB
#
undo shutdown
ip address 20.1.1.4 255.255.255.0
#
return
l Configuration file of Router D

#
sysname RouterC
#
arp vlink-direct-route advertise route-policy policy1
#
vlan batch 10
#
interface Vlanif10
ip address 20.1.1.1 255.255.255.0
#
portswitch
undo shutdown
#
undo shutdown
ip address 20.2.1.1 255.255.255.0
#
bgp 100
router-id 3.3.3.3
peer 20.2.1.2 as-number 100
#
ipv4-family unicast
undo synchronization
import-route direct
peer 20.2.1.2 enable
peer 20.2.1.2 route-policy policy2 export
#
route-policy policy1 permit node 10
if-match ip-prefix prefix1
#
#
ip ip-prefix prefix1 index 10 permit 20.1.1.4 32
ip ip-prefix prefix2 index 10 deny 20.1.1.0 24
ip ip-prefix prefix2 index 20 permit 0.0.0.0 0 less-equal 32

#
return
1.18.5 Example for Importing IPv6 NDP Vlink Direct Routes to

BGP4+
By importing IPv6 NDP Vlink direct routes to BGP4+, you can enable the remote device to
obtain information about detailed routes in the VLAN, allowing precise control of data traffic.
As networks develop, the VLAN technology is widely used. If a user outside a VLAN needs to
communicate with users within the VLAN, advertising routes destined for the network segment
of the VLAN can achieve this purpose. When users outside the VLAN need to know the IPv6
NDP Vlink direct routes of the VLAN, and apply different traffic policies to routes of the VLAN
users, advertising the routes destined for the network segment of the VLAN cannot meet this
requirement. In this case, you can enable the function of IPv6 NDP Vlink direct route
advertisement.
As shown in Figure 1-16, Router C is connected to two VLAN sites through VLANIF interfaces.
Router D communicates with Router B, but not with Router A. You can enable the function of
IPv6 NDP Vlink direct route advertisement on Router C, and use a route-policy to filter out the
routes to the network segment of the VLAN and the route to Router A.
Figure 1-16 Networking diagram of importing IPv6 NDP Vlink direct routes to BGP4+
GE1/0/0
2001:db8:1::3/64 AS100
RouterA
SwitchA RouterC RouterD
GE1/0/0 GE2/0/0 GE1/0/0 BGP
GE2/0/0
GE3/0/0 GE1/0/0
VLANIF10 2001:db8:2::1/24
RouterB VLANIF10 2001:db8:2::2/24
2001:db8:1::2/64
2001:db8:1::1/64
GE1/0/0
2001:db8:1::4/24
1. Create VLANIF interfaces on Switch A and Router C and assign IPv6 addresses to the
VLANIF interfaces, and ensure that Router A, Router B, Switch A, and Router C can
2. Enable BGP4+ on Router C and Router D, ensuring that Router C and Router D are able
to advertise IPv6 routes to each other.
3. Enable the function of IPv6 NDP Vlink direct route advertisement on Router C.

4. Configure a route-policy on Router C, allowing IPv6 routes only from Router B to pass
through.
5. Enable BGP4+ on Router C and import IPv6 direct routes to BGP4+, and use the route-
policy to import IPv6 routes only from Router B to BGP4+.
6. Associate BGP4+ with the route-policy on Router C to filter out the network segment route
of the VLAN so that Router D cannot learn the network segment route and can communicate
with VLAN users only based on IPv6 NDP Vlink direct routes.
Data Preparation
l ID of the VLAN in which Switch A and Router C reside (the VLAN ID is 10 in this example)
l Router IDs and AS numbers of Routers C and D (router ID of Router C is 1.1.1.1 and router
ID of Router D is 2.2.2.2, and Routers C and D are in AS 100 in this example)
l Route-policy used to filter direct routes (the route-policy is policy1 in this example)
l Route-policy used to advertise BGP4+ routes on Router C (the route-policy is policy2 in
this example)
Procedure
[RouterA] ipv6
[RouterA-GigabitEthernet1/0/0] undo shutdown
[RouterA-GigabitEthernet1/0/0] ipv6 enable
[RouterA-GigabitEthernet1/0/0] ipv6 address 2001:db8:1::3 64
[RouterB] ipv6
[RouterB-GigabitEthernet1/0/0] undo shutdown
[RouterB-GigabitEthernet1/0/0] ipv6 enable
[RouterB-GigabitEthernet1/0/0] ipv6 address 2001:db8:1::4 64
[RouterC] ipv6
[RouterC-GigabitEthernet2/0/0] ipv6 enable
[RouterC-GigabitEthernet2/0/0] ipv6 address 2001:db8:2::1 64

[HUAWEI] sysname RouterD

[RouterD] ipv6
[RouterD-GigabitEthernet1/0/0] undo shutdown
[RouterD-GigabitEthernet1/0/0] ipv6 enable
[RouterD-GigabitEthernet1/0/0] ipv6 address 2001:db8:2::2 64
Step 2 Configure basic VLAN functions. Create VLANIF 10 on Switch A and Router C and assign IP
addresses to the VLANIF interfaces.
# Configure Switch A.
[HUAWEI] sysname SwitchA
[SwitchA] ipv6
[SwitchA] vlan 10
[SwitchA-vlan10] quit
[SwitchA] interface Vlanif 10
[SwitchA-Vlanif10] ipv6 enable
[SwitchA-Vlanif10] ipv6 address 2001:db8:1::2 64
[SwitchA-Vlanif10] quit
[RouterC] ipv6
[RouterC] vlan 10
[RouterC-vlan10] quit
[RouterC-GigabitEthernet1/0/0] portswitch
[RouterC-GigabitEthernet1/0/0] port link-type access
[RouterC-GigabitEthernet1/0/0] port default vlan 10
[RouterC] interface Vlanif 10
[RouterC-Vlanif10] ipv6 enable
[RouterC-Vlanif10] ipv6 address 2001:db8:1::1 64
[RouterC-Vlanif10] quit
Step 3 Configure BGP4+ between Router C and Router D.
[RouterC] bgp 100
[RouterC-bgp] router-id 1.1.1.1
[RouterC-bgp] peer 2001:db8:2::2 as-number 100
[RouterC-bgp] ipv6-family unicast

[RouterC-bgp-af-ipv6] peer 2001:db8:2::2 enable

[RouterC-bgp-af-ipv6] quit
[RouterC-bgp] quit
[RouterD] bgp 100
[RouterD-bgp] router-id 2.2.2.2
[RouterD-bgp] peer 2001:db8:2::1 as-number 100
[RouterD-bgp] ipv6-family unicast
[RouterD-bgp-af-ipv6] peer 2001:db8:2::1 enable
[RouterD-bgp-af-ipv6] quit
[RouterD-bgp] quit
After the configuration is complete, run the display bgp ipv6 peer command to view statuses
of IPv6 IBGP peer relationships. The command output shows that the IBGP peer relationship
has been established between Router C and Router D. Use the display on Router D as an example.
[RouterD] display bgp ipv6 peer
BGP local router ID : 2.2.2.2

Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
2001:db8:2::1 4 100 64 59 0 00:52:15 Established

0
Step 4 Configure BGP4+ on Router C and import direct routes to BGP4+. Then view the routing tables
of Routers C and D.
[RouterC] bgp 100
[RouterC-bgp-af-ipv6] import-route direct
[RouterC-bgp] quit
# Display the BGP4+ routing table of Router C.

[RouterC] display bgp ipv6 routing-table


*> Network : ::1 PrefixLen : 128
NextHop : :: LocPrf :
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : 2001:db8:1:: PrefixLen : 64
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : 2001:db8:1::1 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?


MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : FE80:: PrefixLen : 10
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : FE80::2E0:39FF:FE18:8300 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : FE80::2E0:91FF:FE4F:8100 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : FE80::2E0:9BFF:FE7E:7800 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
# Display the BGP4+ routing table of Router D.

[RouterD] display bgp ipv6 routing-table


*>i Network : 2001:db8:1:: PrefixLen : 64
NextHop : 2001:db8:2::1 LocPrf : 100
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
i Network : 2001:db8:2:: PrefixLen : 64
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?

You can see that Router D haven't learned the two IPv6 NDP Vlink direct routes
2001:db8:1::3/128 and 2001:db8:1::4/128.
Step 5 Enable the function of IPv6 NDP Vlink direct route advertisement on Router C and configure
the route-policy policy1 to filter out the routes to the network segment of the VLAN and the
IPv6 NDP Vlink direct route from Router A, 2001:db8:1::3/128.
[RouterC] ip ipv6-prefix prefix1 permit 2001:db8:1::4 128
[RouterC-route-policy] if-match ipv6 address prefix-list prefix1
[RouterC] ipv6 nd vlink-direct-route advertise route-policy policy1
# Display the BGP4+ routing table of Router C.

[RouterC] display bgp ipv6 routing-table


MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?


MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : FE80::2E0:39FF:FE18:8300 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : FE80::2E0:91FF:FE4F:8100 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*> Network : FE80::2E0:9BFF:FE7E:7800 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?



MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
*>i Network : 2001:db8:1::4 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
You can see that Router D has learned the IPv6 NDP Vlink direct route 2001:db8:1::4/128,
whereas the route 2001:db8:1::3/128 has been filtered out.
Step 6 Use the route-policy policy2 to filter out the network segment route 2001:db8:1::/64 on
Router C when BGP4+ routes are advertised.
[RouterC] ip ipv6-prefix prefix2 index 10 deny 2001:db8:1:: 64
[RouterC] ip ip-prefix prefix2 index 20 permit :: 0 less-equal 128
[RouterC-route-policy] if-match ipv6 address prefix-list prefix2
[RouterC] bgp 100
[RouterC-bgp-af-ipv6] peer 2001:db8:2::2 route-policy policy2 export
[RouterC-bgp] quit
[RouterC] quit

<RouterC> refresh bgp all export



*>i Network : 2001:db8:1::4 PrefixLen : 128
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
You can see that the route 2001:db8:1::/64 does not exist in the BGP4+ routing table of
Router D. As a result, Router D can communicate with Router B, but cannot communicate with
Router A.
----End
Configuration Files
l Configuration file of Switch A
#
sysname switchA
#
ipv6
#
vlan batch 10
#
interface Vlanif10
ipv6 enable
#
portswitch
undo shutdown
#
portswitch
undo shutdown
#
portswitch
undo shutdown
#
return

#
sysname RouterA
#
ipv6
#
undo shutdown
ipv6 enable
#
return

#
sysname RouterB
#
ipv6
#
undo shutdown
ipv6 enable
#
return

#
sysname RouterC
#
ipv6
#
ipv6 nd vlink-direct-route advertise route-policy policy1
#
vlan batch 10
#
interface Vlanif10
ipv6 enable
#
portswitch
undo shutdown
#
undo shutdown
ipv6 enable
#
bgp 100
router-id 1.1.1.1
peer 2001:db8:2::2 as-number 100
#
ipv4-family unicast
#
ipv6-family unicast
import-route direct
peer 2001:db8:2::2 enable
peer 2001:db8:2::2 route-policy policy2 export
#
if-match ipv6 address prefix-list prefix1
#


if-match ipv6 address prefix-list prefix2
#
ip ipv6-prefix prefix1 index 10 permit 2001:db8:1::4 128
ip ipv6-prefix prefix2 index 10 deny 2001:db8:1:: 64
ip ipv6-prefix prefix2 index 20 permit :: 0 less-equal 128
#
return

#
sysname RouterD
#
ipv6
#
undo shutdown
ipv6 enable
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
#
return

Configuration Guide - IP Routing 2 IP Static Route Configuration
2 IP Static Route Configuration
About This Chapter
Static routes are commonly used on simple networks. Properly configuring and using static
routes improves network performance and ensures that enough bandwidth is available for
important services.
2.1 Introduction
On a simple network, you only need to configure static routes for the network to run properly.
2.2 Configuring an IPv4 Static Route

On an IPv4 network, you can accurately control route selection by configuring IPv4 static routes.

2.4 Configuring BFD for IPv4 Static Routes on the Public Network
On an IPv4 network, configuring BFD for IPv4 static routes on the public network can speed
up route convergence and improve network reliability.
2.5 Configuring BFD for IPv6 Static Routes on the Public Network
On an IPv6 network, you can configure BFD for IPv6 static route on the public network to speed
2.6 Configuring NQA for IPv4 Static Routes

On an IPv4 network, if Bidirectional Forwarding Detection (BFD) for static IPv4 routes on the
public network cannot be configured because one of the communicating devices does not support
BFD, Network Quality Analysis (NQA) for static IPv4 routes can be configured to detect faults
in links. An NQA test instance is used to detect the link status to allow a fast link switchover
after a fault occurs in a link. This switchover helps prevent prolonged service interruptions.

On an IPv6 network, if interconnected devices do not support BFD, BFD for IPv6 static routes
cannot be configured. You can configure network quality analysis (NQA) for IPv6 static routes
instead. An NQA test instance is used to detect the link status to allow a fast link switchover
after a link fault occurs. This prevents long-time service interruption.
2.8 Configuring IPv4 Static Routes to Inherit the Costs of Iterated Routes

This section describes how to configure IPv4 static routes to inherit the costs of iterated routes
and associate the priority of static routes with link status to improve network reliability.
2.9 Configuring IPv6 Static Routes to Inherit the Costs of Iterated Routes
and associate the priority of IPv6 static routes with link status to improve network reliability.
2.10 Configuration Examples

Static route configuration examples explain networking requirements, networking diagrams,

2.1 Introduction
On a simple network, you only need to configure static routes for the network to run properly.
2.1.1 Static Route

Static routes are special routes that are configured manually by network administrators.
On a simple network topology, you only need to configure static routes so that the network can
run properly. Properly using static routes improves the network performance and provides the
guaranteed bandwidth for important applications.
The disadvantage of static routes is that if a fault occurs on the network or the network topology
changes, static routes must be changed manually by the administrator.
2.1.2 Static Routing Features Supported by the NE80E/40E

The system supports various static route features, including IPv4 static routes, IPv6 static
routes, default routes, BFD for static routes, NQA for static routes, and permanent advertisement
of static routes.
IPv4 Static Route

IPv4 static routes need to be manually configured by the administrator. IPv4 static routes are
applicable to simple IPv4 networks.
An IPv4 static route is an IPv4 default route if its destination address is 0.0.0.0 and the mask
length is 0.
If the destination address of an IPv4 packet fails to match any entry in the routing table, the
router uses the IPv4 default route to forward the IPv4 packet.
The NE80E/40E supports ordinary static routes and the static routes associated with VPN
instances. The static routes associated with VPN instances are used to manage VPN routes . For
details of VPN instances, see the HUAWEI NetEngine80E/40E Router Feature Description -
VPN.
IPv6 Static Route

Similar to IPv4 static routes, IPv6 static routes need to be manually configured by the
administrator. IPv6 static routes are applicable to simple IPv6 networks.
If the destination address of an IPv6 static route is ::/0 with the mask length being 0, this IPv6
static route is an IPv6 default route.
If the destination address of an IPv6 packet fails to match any entry in the routing table, the
router uses the IPv6 default route to forward the IPv6 packet.
NOTE
The main differences between IPv6 static routes and IPv4 static routes are their destination addresses and
next-hop addresses. The next-hop address of an IPv6 static route is an IPv6 address, whereas the next-hop
address of an IPv4 static route is an IPv4 address.

Default Route
Default routes are a special type of routes that are usually configured by network administrators.
Default routes can also be generated by dynamic routing protocols such as Open Shortest Path
First (OSPF) or Intermediate System-to-Intermediate System (IS-IS).
Default routes are used only when packets to be forwarded fail to match any entry in the routing
table. You can run the display ip routing-table command to check whether the default route is
configured.
If the destination address of a packet does not match any entry in the routing table, the router
uses the default route to forward the packet. If no default route exists, the packet is discarded,
and an Internet Control Message Protocol (ICMP) packet is sent to inform the originating host
that the destination host or network is unreachable.
BFD for Static Route

Unlike dynamic routing, static routing does not have a detection mechanism. If a fault occurs
on the network, administrator involvement is required. Bidirectional Forwarding Detection
(BFD) for static route is used to bind BFD sessions to static routes on the public network. The
BFD sessions are used to detect the link status of a static route. The system then uses the detection
results to determine whether to add static routes to its IP routing table.
After BFD for static route is configured, each static route can be bound to a BFD session.
l When the BFD session on the link of a static route detects that the link changes from Up
to Down, BFD reports the fault to the RM module, and then the RM module sets the route
to inactive. Subsequently, the route becomes unavailable and is deleted from the routing
table.
l When a BFD session is established on the link of a static route (the link changes from Down
to Up), BFD reports the success to the RM module, and then the RM module sets the route
to active. Subsequently, the route becomes available and is added to the IP routing table.
NQA for Static Route

NQA for static routes refers to the association between a static route and an NQA test instance.
The system can use the NQA test instance to check the link status. Then, according to the NQA
test result, the system can determine an optimal route in time to prevent communication
interruption and ensure service quality. NQA for static routes functions as follows:
l If NQA detects a fault in the link, the system sets the static route to inactive. The route
becomes unavailable and is deleted from the IP routing table.
l If NQA finds that the link recovers, the system sets the static route to active. The route
becomes available and is added to the IP routing table.
Permanent Advertisement of Static Routes

Permanent advertisement of static routes provides a simple link detection mechanism to monitor
services, which improves compatibility between Huawei devices and non-Huawei devices. If
service traffic needs to be forwarded along a specified path, you can detect links by pinging the
destination addresses of static routes.



Before configuring an IPv4 static route, familiarize yourself with the usage scenario, complete
the pre-configuration tasks, and obtain the data required for the configuration.
When configuring an IPv4 static route, note the following:
l Destination address and mask

In the ip route-static command, the IPv4 destination address is in dotted decimal notation,
and the mask can be either expressed in dotted decimal notation or replaced by the mask
length (namely, the number of consecutive 1s in the mask).
l Outbound interface and next-hop address
When configuring a static route, you can specify either interface-type interface-number or
nexthop-address depending on which parameter is better suited to your situation.
In real-world situations, each routing entry requires a next-hop address. When sending a
packet, the router first searches for the matched route in the routing table against the
destination address. The link layer cannot find the associated link layer address to forward
the packet unless the next-hop address of the packet is specified.
For example, in some cases, the link layer is encapsulated with PPP, you can also specify
outbound interfaces when configuring the router even if the remote address is not known.
In this manner, it is unnecessary to modify the router configuration if the remote address
changes.
When specifying the outbound interface, note the following:
– For a Point-to-Point (P2P) interface, the next-hop address is specified after the outbound
interface is specified. That is, the address of the remote interface (interface on the peer
device) connected to this interface is the next-hop address.
– Non-Broadcast Multiple-Access (NBMA) interfaces (such as ATM interfaces) are
applicable to Point-to-Multipoint (P2MP) networks. Therefore, you need to configure
IP routes and the mappings between IP addresses and link layer addresses. In this case,
a next-hop IP address needs to be configured.
– When a static route is being configured, specifying an Ethernet interface as the outbound
interface is not recommended. This is because the Ethernet interface is a broadcast
interface. Therefore, if the Ethernet interface is specified as the outbound interface,
multiple next hops exist and the system cannot decide which next hop is to be used. In
practice, when specifying a broadcast interface (such as an Ethernet interface) or Non-
Broadcast Multiple-Access (NBMA) interfaces as the outbound interface, you must
specify the associated next-hop address.
l Other attributes
Setting different preferences for static routes helps flexibly apply routing policies. For
example, when configuring multiple routes to the same destination address, you can set the

same preference for these routes to implement load balancing. You can also set different
preferences to implement routing redundancy.
When the ip route-static command is run to configure a static route, a default route is
configured if the destination address and the mask are set to all 0s (0.0.0.0 0.0.0.0).
Before configuring an IPv4 static route, complete the following task:
l Configuring link layer protocol parameters and IP addresses for interfaces to ensure that
the link layer protocol status of the interfaces is Up
Data Preparation
To configure an IPv4 static route, you need the following data.
No. Data
1 Destination address and mask
2 Outbound interface or next-hop IPv4 address
3 Preference of the IPv4 static route
2.2.2 Configuring an IPv4 Static Route on the Public Network

When configuring an IPv4 static route, configure its destination address, outbound interface,
and next hop.
Context
Perform the following steps on the router to be configured with a static route:
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 } [ preference preference | tag tag ] * [ description text ]
An IPv4 static route is configured.
By default, no IPv4 static route is configured.
----End

2.2.3 (Optional) Setting the Default Preference for IPv4 Static

Routes
Setting the default preference for IPv4 static routes can affect route selection.
Context
Perform the following steps on the routers that need to be configured with static routes and
change the default preference for static routes:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route-static default-preference preference
The default preference is set for static routes.
By default, the preference of static routes is 60.
When a static route is configured, the default preference is used if no preference is explicitly
specified for the static route. After a default preference is specified, the new default preference
is valid for subsequent rather than existing IPv4 static routes.
----End
2.2.4 (Optional) Configuring Static Route Selection Based on Relay

Depth
After static route selection based on relay depths is configured, the static route module selects
the static route with the smallest relay depth as the active route and delivers it to the FIB table.
The other routes become inactive.
Context
After static routes are configured, multiple static routes with the same prefix and preference but
different relay depths exist. After static route selection based on relay depths is configured, the
static route module selects the route with the smallest relay depth as the active route and delivers
it to the Forwarding Information Base (FIB) table. The other routes become inactive.
Perform the following steps on the router to be configured with static routes:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip route-static selection-rule relay-depth
Static route selection based on relay depths is configured.
By default, static routes are not selected according to relay depths.
----End
2.2.5 (Optional) Configuring Permanent Advertisement of IPv4

Static Routes
Permanent advertisement of static routes provides a low-cost and simple link detection
mechanism and improves the compatibility between Huawei devices and non-Huawei devices.
Context
Link connectivity directly affects the stability and availability of a network. Consequently,
detecting link status is an important part of network maintenance. If service traffic needs to be
forwarded along a specified path, you can detect the status of the path using a ping operation.
In this manner, you can monitor services at a very low cost.
With permanent advertisement of static routes, you can detect link connectivity by pinging the
destination addresses of static routes. After permanent advertisement of static routes is
configured, static routes always take effect regardless of the outbound interface status. In this
case, the system forwards ping packets along a specified path only, which helps detect the link
status of the specified path.
Perform the following steps on the router where IPv4 static routes need to be configured.
Procedure
Step 1 Run:
system-view
Step 2 Run:
address } permanent
Permanent advertisement of IPv4 static routes is configured.
By default, permanent advertisement of IPv4 static routes is not configured.
----End
2.2.6 Configuring Static IPv4 Routes in a Topology Instance

By properly configuring static IPv4 routes in a simple topology instance, you can improve the
network performance and provide the guaranteed bandwidth for important services.

Context
Before configuring multi-topology on a network, you need to create a topology instance. By
properly configuring static IPv4 routes in a simple topology instance, you can improve the
Perform the following steps on the router where static IPv4 routes need to be configured:
Procedure
Step 1 Run:
system-view
Step 2 Run either of the following commands as required:

l Run:
type interface-number [ nexthop-address ] | vpn-instance vpn-instance-name
nexthop-address } [ preference preference | tag tag ] * [ description text ]
Static IPv4 routes are configured in a base topology instance.

l Run:
ip route-static topology topology-name ip-address { mask | mask-length }
{ nexthop-address | interface-type interface-number [ nexthop-address ] }
[ preference preference | tag tag ] * [ description text ]
Static IPv4 routes are configured in another topology instance.
By default, no static IPv4 routes are configured in a topology instance.
----End

After an IPv4 static route is configured, you can check detailed information about the configured
IPv4 static route.
Prerequisites
An IPv4 static route has been configured.
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



Before configuring an IPv6 static route, familiarize yourself with the usage scenario, complete
On a small IPv6 network, you can implement network interconnection by configuring IPv6 static
routes. Compared with using dynamic routes, using static routes saves the bandwidth.
Before configuring an IPv6 static route, complete the following task:
Data Preparation
To configure an IPv6 static route, you need the following data.
No. Data
3 Preference of the IPv6 static route
2.3.2 Configuring an IPv6 Static Route on the Public Network

When configuring an IPv6 static route, you need to correctly configure its destination address,
outbound interface, and next hop.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 route-static dest-ipv6-address prefix-length { interface-type interface-
number | nexthop-ipv6-address } [ preference preference | tag tag ] *

When configuring a static route, you need to specify either the outbound interface or the next-
hop address according to the actual situation. If the outbound interface is a Point-to-Point (P2P)
interface, you can simply specify the outbound interface. If the outbound interface is a non-P2P
interface, you must also specify the next-hop address in addition to specifying the outbound
interface.
If preference is not specified, the default preference is 60.
----End
2.3.3 (Optional) Setting the Default Preference for IPv6 Static

Routes
By setting the default preference for an IPv6 static route, you can change the preference of the
static route.
Context
Perform the following steps on the router that needs to be configured with IPv6 static routes and
change the default priority for IPv6 static routes:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipv6 route-static default-preference preference
The default preference of IPv6 static routes is set.

By default, the preference of IPv6 static routes is 60.
When an IPv6 static route is configured, the default preference is used if the preference of the
static route is not explicitly specified. After the default preference is specified, the default
preference is valid for subsequent rather than existing IPv6 static routes.
----End
2.3.4 Configuring Static IPv6 Routes in a Topology Instance

By properly configuring static IPv6 routes in a simple topology instance, you can improve the
Context
Before configuring multi-topology on a network, you need to create a topology instance. By
properly configuring static IPv6 routes in a simple topology instance, you can improve the
Perform the following steps on the router where static IPv6 routes need to be configured:

Procedure
Step 1 Run:
system-view
Step 2 Run either of the following commands as required:

l Run:
number [ nexthop-ipv6-address ] | nexthop-ipv6-address } [ preference
preference | tag tag ] * [ description text ]
Static IPv6 routes are configured in a base topology instance.

l Run:
ipv6 route-static topology topology-name dest-ipv6-address prefix-length
{ interface-type interface-number [ nexthop-ipv6-address ] | nexthop-ipv6-
Static IPv6 routes are configured in another topology instance.
By default, no static IPv6 routes are configured in a topology instance.
----End

After an IPv6 static route is configured, you can check detailed information about the configured
route.
Prerequisites
An IPv6 static route has been configured.
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
2.4 Configuring BFD for IPv4 Static Routes on the Public

Network
On an IPv4 network, configuring BFD for IPv4 static routes on the public network can speed

Before configuring BFD for static routes, familiarize yourself with the usage scenario, complete

BFD can quickly detect IPv4 forwarding failures, ensuring QoS for voice, video, and other video-
on-demand (VoD) services on an IPv4 network. With BFD, service providers can provide voice
over IP (VoIP) and other real-time services with high availability and scalability.
By binding IPv4 static routes to BFD sessions, you can use BFD sessions to provide link
detection for IPv4 static routes on the public network. A static route can be bound to a BFD
session.
Before configuring BFD for IPv4 static routes on the public network, complete the following
task:
Data Preparation
To configure BFD for IPv4 static routes on the public network, you need the following data.
No. Data
3 IP address of the peer detected by BFD
4 Local discriminator and remote discriminator of a BFD session
2.4.2 Configuring an IPv4 static route

When configuring an IPv4 static route, configure its destination address, outbound interface,
and next hop.
Context
Perform the following steps on the router to be configured with a static route:
Procedure
Step 1 Run:
system-view
Step 2 Run:

----End
2.4.3 Configuring a BFD Session

BFD sessions are used to quickly detect and monitor the connectivity of links on a network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
BFD is enabled globally and the BFD view is displayed.
Step 3 Run:
quit
Step 4 Run the bfd bfd-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ] [ interface
interface-type interface-number ] [ source-ip source-ip ] command to configure a BFD session.
l When a BFD session is set up for the first time, you need to bind the peer IP address to it.
After the BFD session is set up, you cannot modify it.
l When the BFD configuration items are created, the system checks only the format of the IP
address rather than the correctness. The BFD session cannot be established if incorrect peer
IP address or source IP address is bound.
l When the IP address of the peer and the local interface are both specified, a single-hop link
is monitored. BFD monitors the route with the outbound interface specified and peer-ip as
the next-hop IP address specified. When only the IP address of the peer is specified, multi-
hop routes are monitored.
l When the BFD and URPF are used together, URPF checks the source IP address of the
received packets. Therefore, when creating a BFD binding, you need to specify the source
IP address of the BFD packet in case the BFD packet is incorrectly discarded.
Step 5 Configure the discriminators.

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

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

NOTE
The local discriminator of the local device corresponds to the remote discriminator of the remote device,
and the remote discriminator of the local device corresponds to the local discriminator of the remote device.
The local discriminator of the local device must be the same as the remote discriminator of the remote
device. Otherwise, the session cannot be correctly set up. After the local and remote discriminators are
configured, they cannot be modified.
Step 6 Run:
commit
The configurations are committed.
NOTE
When setting up a BFD session, you must run the commit command after configuring necessary
parameters, such as local and remote discriminators; otherwise, the session cannot be set up.
----End
2.4.4 Binding a Static Route to a BFD Session

When binding a static route to a BFD session, ensure that the static route resides on the same
link as the BFD session.
Context
Perform the following steps on the router to bind a static route to a BFD session:
Procedure
Step 1 Run:
system-view
Step 2 Run:
type interface-number [ nexthop-address ] } [ preference preference | tag tag ] *
track bfd-session bfd-name [ description text ]
A BFD session is bound to the IPv4 static route on the public network.
NOTE
When binding a static route to a BFD session, ensure that the static route resides on the same link as the
BFD session.
----End

After BFD for static route is configured, you can check information about BFD sessions and
BFD for static route.
Prerequisites
BFD configurations for IPv4 static routes are complete.

Procedure
l Run the display bfd session { all | discriminator discr-value } [ verbose ] [ slot slot-
id ] command to check BFD session information.
l Run the display current-configuration | include bfd command to check the configuration
of BFD for static routes.
You can check information about a BFD session only after parameters for the BFD session
are set and the BFD session is established.
If BFD session negotiation succeeds, the status of the BFD session is displayed as Up. You
can also check that the BFD session is bound to the static route by running the display
current-configuration | include bfd command in the system view.
----End
2.5 Configuring BFD for IPv6 Static Routes on the Public

Network
On an IPv6 network, you can configure BFD for IPv6 static route on the public network to speed

Before configuring BFD for static route, familiarize yourself with the usage scenario, complete
the pre-configuration tasks, and obtain the data required the configuration.
IPv6 BFD can rapidly detect IPv6 forwarding failures, ensuring QoS for voice, video, and other
video-on-demand (VoD) services on an IPv6 network. With IPv6 BFD, service providers can
provide voice over IP (VoIP) and other real-time services with high availability and scalability.
By binding IPv6 static routes to BFD sessions, you can use BFD sessions to provide link
detection for IPv6 static routes on the public network. A static route can be bound to a BFD
session.
Before configuring BFD for IPv6 static routes on the public network, complete the following
task:
l Configuring link layer protocol parameters and IPv6 addresses for interfaces to ensure that
Data Preparation
To configure BFD for IPv6 static routes on the public network, you need the following data.

No. Data
1 Destination address and prefix
3 Peer IPv6 address to be detected by BFD
4 Local discriminator and remote discriminator of a BFD session
2.5.2 Configuring an IPv6 static route

When configuring an IPv6 static route, you need to correctly configure its destination address,
outbound interface, and next hop.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
number | nexthop-ipv6-address } [ preference preference | tag tag ] *
When configuring a static route, you need to specify either the outbound interface or the next-
hop address according to the actual situation. If the outbound interface is a Point-to-Point (P2P)
interface, you can simply specify the outbound interface. If the outbound interface is a non-P2P
interface, you must also specify the next-hop address in addition to specifying the outbound
interface.
If preference is not specified, the default preference is 60.
----End
2.5.3 Configuring a BFD Session

BFD sessions are used to rapidly detect and monitor the connectivity of links on a network.
Procedure
Step 1 Run:
system-view


Step 2 Run:
bfd
BFD is enabled globally and the BFD view is displayed.

Step 3 Run:
quit

Step 4 Run the bfd bfd-name bind peer-ipv6 peer-ipv6 [ vpn-instance vpn-instance-name ]
[ interface interface-type interface-number ] [ source-ipv6 source-ipv6 ] command to configure
a BFD6 session.
l When setting up a BFD6 session for the first time, you need to bind the peer IPv6 address to
the session. The binding cannot be modified once the BFD6 session is set up.
l If the specified peer IPv6 address is a link-local address, the outbound interface should also
be specified, that is, only the single-hop BFD6 session can be set up; otherwise, an error
prompt is displayed.
l When configuring the BFD6 session, the system checks only the validity of the format of the
IPv6 address rather than the correctness of the IPv6 address. The BFD6 session cannot be
set up if incorrect peer IPv6 address or source IPv6 address is bound.
Step 5 Configure the discriminators.
l Run:
The local discriminator is configured.

l Run:
The remote discriminator is configured.

NOTE
The local discriminator of the local device corresponds to the remote discriminator of the remote device,
and the remote discriminator of the local device corresponds to the local discriminator of the remote device.
The local discriminator of the local device must be the same as the remote discriminator of the remote
device. Otherwise, the session cannot be correctly set up. After the local and remote discriminators are
configured, they cannot be modified.
Step 6 Run:
commit
The configurations are committed.
NOTE
When setting up a BFD session, you must run the commit command after configuring necessary
parameters, such as local and remote discriminators; otherwise, the session cannot be set up.
----End
2.5.4 Binding a Static Route to a BFD Session

When binding a static route to a BFD session, ensure that the static route resides on the same
link as the BFD session.

Context
Perform the following steps on the router to bind a static route to a BFD session:
Procedure
Step 1 Run:
system-view
Step 2 Run:
number [ nexthop-ipv6-address ] | nexthop-ipv6-address } [ preference preference ]
[ tag tag ] * [ track bfd-session bfd-name ] [ description text ]
The IPv6 static route on the public network is bound to a BFD session.
NOTE
When binding a static route to a BFD session, ensure that the static route resides on the same link as the
BFD session.
----End

After BFD for static route is configured, you can check BFD session information and information
about BFD for static route.
Prerequisites
BFD for IPv6 static routes on the public network has been configured.
Procedure
l Run the display bfd session { all | discriminator discr-value } [ verbose ] [ slot slot-
id ] command to check BFD session information.
l Run the display current-configuration | include bfd command to check the configuration
of BFD for static routes.
You can view BFD session information only after BFD session parameters are set and a
BFD session is established.
If BFD session negotiation succeeds, you can view that the status of the BFD session is
Up. You can also view that static routes are bound to BFD sessions by running the display
current-configuration | include bfd command in the system view.
----End

On an IPv4 network, if Bidirectional Forwarding Detection (BFD) for static IPv4 routes on the
public network cannot be configured because one of the communicating devices does not support
BFD, Network Quality Analysis (NQA) for static IPv4 routes can be configured to detect faults

in links. An NQA test instance is used to detect the link status to allow a fast link switchover
after a fault occurs in a link. This switchover helps prevent prolonged service interruptions.

Before configuring NQA for static IPv4 routes, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the required data.
In real world situations, the link status is monitored for network stability. If an active link fails,
traffic switches to a standby link to ensure non-stop traffic forwarding. The Address Resolution
Protocol (ARP) probe function and BFD are usually used to detect link faults. In addition, Interior
Gateway Protocol (IGP) convergence helps reveal link faults. In certain situations, the preceding
methods are unsuitable. For example:
l If only one link, not every link, on the network needs to be monitored, the ARP detection
is unsuitable.
l If any device on the network does not support BFD, BFD is unavailable.
l If either end of a link is a Layer 2 device, dynamic routing protocols cannot be deployed.
As a result, no IGP convergence occurs.
In these situations, NQA for static IPv4 routes can be configured to detect link faults. It can be
used to detect faults in links where Layer 2 devices reside and take effect even if only one of the
two communicating devices supports NQA.
If a fault occurs, an NQA test instance can immediately detect the fault and instruct the system
to delete the associated static route from the IP routing table. Traffic is then forwarded along
another path.
Before configuring NQA for static IPv4 routes, complete the following task:
the link layer protocol on the interfaces is Up
Data Preparation
To configure NQA for static IPv4 routes, you need the following data.
No. Data
1 Administrator name and name of an NQA test instance
2 Destination IP address of the NQA test instance
3 Destination network address and mask
4 Next hop IPv4 address or outbound interface for a static route

2.6.2 Configuring an ICMP Type NQA Test Instance

NQA is an effective tool for locating and diagnosing network faults.
Context
NQA measures the performance of different protocols running on a network. With NQA, carriers
can collect the operation indicators of networks in real time. These indicators include total delay
of the Hypertext Transfer Protocol (HTTP), delay in the Transfer Control Protocol (TCP)
connection, delay in Domain Name Server (DNS) resolution, file transmission rate, delay in the
File Transfer Protocol (FTP) connection, and DNS resolution error ratio. To check these
performance indexes, you can create NQA test instances.
An NQA test is performed between a client and a server. The client is responsible for initiating
an NQA test. After test instances are configured on the client, NQA places these test instances
into test instance queues according to their operation types. After the test instances are started,
the data information about the protocol-related running status can be collected based on
information about the return packets.
An Internet Control Messages Protocol (ICMP) NQA test instance checks whether a route from
the NQA client to the destination is reachable. The ICMP NQA test performs a function similar
to the ping command but provides more detailed output:
l By default, the output contains the five most recent tests.

l The test result contains information including the average delay, packet loss ratio, and time
when the last packet was correctly received.
The minimum interval at which an ICMP NQA test instance sends packets is once per second,
which ensures that NQA reports the test results to the system when a link fault is detected and
when the link fault is rectified. For details about NQA, see the chapter "NQA Configuration" in
the HUAWEI NetEngine80E/40E Router Configuration Guide - System Management.
Perform the following steps on the NQA client:
Procedure
Step 1 Run:
system-view
Step 2 Run:
nqa test-instance admin-name test-name
An NQA test instance is created, and the test instance view is displayed.
Step 3 Run:
test-type icmp
The test type is set to ICMP.
Step 4 Run:
destination-address ipv4 ip-address
The destination address is specified for the NQA test instance.


frequency interval
The interval for automatically performing an NQA test is set. By default, no interval is set, and
only one test is performed.

probe-count number
The number of probes to be sent each time is set for the NQA test instance. By default, three
probes are sent each time.
After probes are sent multiple times for the NQA test instance, you can estimate the network
quality more accurately based on the collected statistics.
Step 7 Run:
start
The NQA test instance is started.
Run one of the following commands in different situations:
l To start an NQA test immediately, run the start now [ end { at [ yyyy/mm/dd ] hh:mm:ss |
delay { seconds second | hh:mm:ss } | lifetime { seconds second | hh:mm:ss } } ] command.
l To start an NQA test at a specified time, run the 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 } } ] command.
l To start an NQA test after a certain period of time, run the 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 } } ] command.
----End
2.6.3 Binding an IPv4 Static Route to an NQA Test Instance

If a static IPv4 route is associated with an NQA test instance, NQA tests the link status
periodically. After NQA detects a fault in the link related to the associated static route, the static
route is deleted and traffic diverts to another path.
Context
On a network with a simple topology, configuring static routes is usually adequate enough to
ensure the network is able to operate correctly. Static routes can also be configured on a router
that cannot run dynamic routing protocols to generate routes to the destination. Unlike dynamic
routing protocols, static routes do not have a dedicated detection mechanism. Static routes cannot
detect faults in the network, which means that traffic loss will likely occur at some point.
The NQA for static IPv4 routes feature allows static IPv4 routes to be associated with NQA test
instances. The ping function of NQA test instances is used to check the status of links through
which static routes pass. If a fault occurs in the link for a static route, the system deletes the static
route to force traffic transmitted based on this route to divert to another path.
Perform the following steps on the router that requires NQA for static IPv4 routes:

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 ] } [ preference preference | tag tag ] *
track nqa admin-name test-name [ description text ]
A static IPv4 route is associated with an NQA test instance.
NOTE
The destination address of an NQA test instance cannot be the destination address of an associated static
route.
If the static route associated with one NQA test instance is associated with another NQA test instance, the
association between the static route and the former NQA test instance is automatically removed.
----End

After associating an NQA test instance with a static route, you can check NQA test results and
information about the association between the static route and the NQA test instance.
Prerequisites
NQA configurations for static IPv4 routes have been configured.
NOTE
NQA test results cannot be displayed automatically on the terminal. To check NQA test results, run the
display nqa results command. By default, the command output shows the results of the five most recent
tests.
Procedure
Step 1 Run the display current-configuration | include nqa command to check NQA configurations
for static IPv4 routes.
Step 2 Run the display nqa results [ test-instance admin-name test-name ] command to check NQA
test results.
----End
Example
After associating a static route to an NQA test instance, run the display current-
configuration | include nqa command in the system view to check whether the static route has
been associated with the NQA test instance. For example:
<HUAWEI> display current-configuration | include nqa
ip route-static 172.16.1.3 255.255.255.255 GigabitEthernet1/0/0 track nqa admin
icmp
nqa test-instance admin icmp

Run the display nqa results command. The test records are successfully queried if the following
information is displayed:
l testflag is active
l testtype is icmp
l The test is finished
l Completion:success
For example:
<HUAWEI> display nqa results test-instance admin icmp
NQA entry(admin, icmp) :testflag is active ,testtype is icmp
1 . Test 206 result The test is finished
Send operation times: 15 Receive response times: 15
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 Stats errors number:0
Destination ip address:172.16.1.2
Min/Max/Average Completion Time: 30/50/35
Sum/Square-Sum Completion Time: 530/19900
Last Good Probe Time: 2010-10-25 15:39:57.1
Lost packet ratio: 0 %
For an ICMP NQA test, the minimum, maximum, and average time for receiving ICMP Echo-
Reply packets are displayed as Min/Max/Average Completion Time. In addition, the NQA
test packet loss ratio is displayed, which helps provide a clear indication of the link status. In
the preceding example, the packet loss ratio is 0, indicating that the link works properly.
NOTE
If the frequency interval command is configured for an NQA test instance, testflag is active is displayed.
If the frequency interval command is not configured for an NQA test instance, the NQA test is performed
only once and testflag is inactive is displayed.

On an IPv6 network, if interconnected devices do not support BFD, BFD for IPv6 static routes
cannot be configured. You can configure network quality analysis (NQA) for IPv6 static routes
instead. An NQA test instance is used to detect the link status to allow a fast link switchover
after a link fault occurs. This prevents long-time service interruption.

Before configuring NQA for static IPv6 routes, familiarize yourself with the usage scenario,
On a live IPv6 network, link status must be detected in real time so that a link switchover can
be performed immediately after a link fault occurs. ARP and BFD are usually used to detect link
faults. In addition, IGP convergence helps reveal link faults. However, the preceding solutions
are not applicable to certain scenarios.
l If only one link, not links of every user, on the network needs to be monitored, ARP
detection is not applicable.

l If any device on the network does not support BFD, BFD detection is not applicable.
l If either end of a link is a Layer 2 device, dynamic routing protocols cannot be deployed,
and therefore IGP convergence cannot be implemented.
NQA for static routes only requires one end to support NQA and can be used even if there are
Layer 2 devices.
When a link becomes faulty, an NQA test instance can immediately detect this fault and then
the static route associated with the NQA test instance is deleted from the IPv6 routing table.
Traffic is then forwarded through another link.
Before configuring NQA for IPv6 static routes, complete the following task:
l Configuring link layer protocol parameters and assigning IPv6 addresses to interfaces to
ensure that the status of the link layer protocol of the interfaces is Up
Data Preparation
Before configuring NQA for static IPv6 routes, you need the following data.
No. Data
1 Administrator name and name of an NQA test instance
2 Peer IPv6 address to be tested by the NQA instance
3 Destination network address and mask
4 IPv6 address or outbound interface for the static route next hop
2.7.2 Configuring an ICMP NQA Test Instance

NQA is an effective tool for diagnosing and locating network faults.
Context
NQA measures the performance of different protocols running on a network. With NQA, carriers
can collect the operation indexes of networks in real time, for example, total delay of Hypertext
Transfer Protocol (HTTP), delay in Transfer Control Protocol (TCP) connections, delay in
Domain Name Server (DNS) resolution, file transmission rate, delay in File Transfer Protocol
(FTP) connections, and DNS resolution error ratio. To check these performance indexes, you
can create NQA test instances.
The two ends of an NQA test are called the NQA client and NQA server. The NQA client is
responsible for initiating an NQA test. After test instances are configured on the NQA client,
NQA schedules these test instances into test instance queues according to their operation types.
After the test instances are started, the data information about the protocol-related running status
can be collected according to the return packet.

An ICMP NQA test instance is used to check whether a route from the NQA client to the
destination is reachable. The ICMP test provides functions similar to the ping command except
that more information is output.
l By default, the output contains the results of the latest five tests.
l The output includes the average delay, the packet loss ratio, and the time the last packet is
correctly received.
An Internet Control Messages Protocol (ICMP) NQA test instance sends packets at a minimum
interval of 1 second. This ensures that NQA reports the test results to the system when a link
fault is detected and when the link fault is rectified. For details about NQA configurations, see
the section "NQA Configuration" in HUAWEI NetEngine80E/40E Router Configuration Guide
- SystemManagement.
Perform the following steps on the NQA client:
Procedure
Step 1 Run:
system-view

Step 2 Run:
nqa test-instance admin-name test-name
An NQA test instance is created, and the test instance view is displayed.
Step 3 Run:
test-type icmp
The test type is set to ICMP.

Step 4 Run:
destination-address ipv6 ipv6-address
The destination address is set.

In an NQA test instance, you can specify an NQA server by running the destination-address
command to specify a destination address for an NQA test instance.
frequency interval
The interval for automatically performing an NQA test is set. By default, no automatic test
interval is set. The system performs the test only once.
probe-count number
The number of probes to be sent each time is set for the NQA test instance. By default, the
number is 3.
By sending probes multiple times for an NQA test instance, you can estimate the network quality
more accurately based on the collected statistics.
Step 7 Run:
start

The NQA test instance is started.
An NQA test instance can be started immediately, at a specified time, or after a specified delay.
l Run the start now [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { seconds second |
hh:mm:ss } | lifetime { seconds second | hh:mm:ss } } ] command to start the test instance
immediately.
l Run the 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 } } ] command to start
the test instance at a specified time.
l Run the 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 } } ] command
to start the test instance after a specified delay.
----End
2.7.3 Associating a IPv6 Static Route with an NQA Test Instance

If an IPv6 static route is associated with an NQA test instance, NQA tests the link status
periodically. After NQA detects a fault in the link along the associated static route, the static
route is deleted and traffic diverts to another route.
Context
On a network with a simple topology, configuring static routes allows the network to work
properly. When the router fails to set up a route by using the dynamic routing protocol, you can
configure a static route. Unlike dynamic routing protocols, static routes do not have a dedicated
detection mechanism. Static routes cannot detect faults on the network, which probably causes
traffic loss.
NQA for IPv6 static routes enables a static route to be associated with an NQA test instance.
You can use the ping function of an NQA test instance to detect the status of links of the static
route. Then you can determine whether the associated static route is active and whether traffic
is interrupted.
Perform the following steps on the router:
Procedure
Step 1 Run:
system-view
Step 2 Run:
number [ nexthop-ipv6-address ] | nexthop-ipv6-address } [ preference preference |
tag tag ] * track nqa admin-name test-name [ description text ]
An IPv6 static route is associated with an NQA test instance.

NOTE
The destination address of an NQA test instance cannot be the destination address of an associated static
route.
If the static route associated with one NQA test instance is associated with another NQA test instance, the
association between the static route and the former NQA test instance is removed.
----End

After NQA for static IPv6 routes is configured, you can view the NQA test result and
configurations about NQA for static IPv6 routes.
Prerequisites
NQA for static IPv6 routes has been configured.
NOTE
The NQA test result cannot be displayed automatically. You need to run the display nqa results command
to view the NQA test result. By default, the command output shows the results of the latest five tests.
Procedure
Step 1 Run the display current-configuration | include nqa command to check the configurations
about NQA for static IPv6 routes.
Step 2 Run the display nqa results [ test-instance admin-name test-name ] command to check the
NQA test result.
----End
Example
After configurations are complete, run the display current-configuration | include nqa
command in the system view to check whether a static IPv6 route is associated with the NQA
test instance. An example command output is as follows:
<HUAWEI> display current-configuration | include nqa
ipv6 route-static 2001:db8:3::4 128 2001:db8:3::3 track nqa admin1 test1
nqa test-instance admin1 test1
Run the display nqa results command. If the test is successful, the following information is
displayed:
l testflag is active
l testtype is icmp
l The test is finished
l Completion:success
An example command output is as follows:
<HUAWEI> display nqa results test-instance admin1 test1
NQA entry(admin1, test1) :testflag is active ,testtype is icmp



Operation sequence errors number:0 RTT Stats errors number:0
Destination ip address:3::3
For an ICMP NQA test, the minimum, maximum, and average time for receiving ICMP Echo-
Reply packets is displayed, that is, Min/Max/Average Completion Time. Lost packet ratio
is displayed, showing the link status. In this example, the packet loss ratio is 0%, indicating that
the link is running normally.
NOTE
If the frequency interval command is configured for an NQA test instance, testflag is active is displayed.
If the frequency interval command is not configured for an NQA test instance, the NQA test is performed
only once and testflag is inactive is displayed.
2.8 Configuring IPv4 Static Routes to Inherit the Costs of

Iterated Routes
and associate the priority of static routes with link status to improve network reliability.
Static routes inheriting the costs of iterated routes mainly apply to a scenario in which the Layer
2 Virtual Private Network (L2VPN) accesses the Layer 3 Virtual Private Network (L3VPN). In
such a scenario, the direct route cost is usually controlled by Configuring an IPv4 direct route
to respond to L3VE interface status changes after a delay or by Configuring the association
between the IPv4 direct route and PW status. This will reduce downstream traffic loss during
the traffic switchback after the primary pseudo wire (PW) recovers.
However, on the network shown in Figure 2-1, the cell site gateway (CSG) is connected to
multiple base stations. These base stations usually use logical IP addresses to communicate with
access aggregation gateways (AGGs), so direct routes between base stations and AGGs cannot
be used to forward packets. In addition, AGGs do not have routes to the logical IP addresses of
the base stations. To address this problem, you must configure static routes on AGGs to forward
downstream traffic. As network administrators usually configure consecutive logical IP
addresses for base stations based on IP address planning, you must configure static routes to
specific base stations on AGGs. As shown in Figure 2-1, if the CSG-AGG1 link that bears the
primary PW recovers, AGG1 immediately advertises its static routes to radio network controller
site gateways (RSGs). RSGs then select these routes and downstream traffic is switched over to
Link A. However, AGG1 has not learned the MAC addresses of the base stations yet and the
primary PW is unavailable, so packets are dropped during the traffic switchback.

Figure 2-1 Networking of configuring static routes to inherit costs of iterated routes
Loopback0
1.1.1.1/32 AGG1 RSG1
NodeB
CSG PW1
Loopback0 Link A
1.1.1.2/32
Link B
NodeB RNC
PW2
Loopback0 AGG2 RSG2

1.1.1.3/32
NodeB L2VPN L3VPN
PW
To solve this problem, you can configure static routes to inherit costs of iterated routes. Because
static routes are iterated to direct routes and costs of direct routes are determined by PW status,
this configuration implements the association between static routes and PW status. On the
network shown in Figure 2-1, you can configure statics routes on AGG1 to inherit costs of
iterated routes. When the link that bears PW1 recovers:
l If PW1 is still standby, the direct route between AGG1 and CSG has a high cost. Because
the static routes on AGG1 inherit the direct route cost, the static routes also have high costs.
In this case, even if AGG1 advertises static routes to RSGs, RSGs do not preferentially
select these routes and downstream traffic still travels along Link B.
l If PW1 becomes active, the direct route between AGG1 and the CSG has the default cost
0. Because the static routes on AGG1 inherit the direct route cost, the static routes also have
the cost value 0. In this case, after AGG1 advertises static routes to RSGs, RSGs select
these routes and downstream traffic is switched over to Link A. At this time, AGG1 has
learned the MAC addresses of the base stations, and downstream traffic loss will be reduced.
Before configuring IPv4 static routes to inherit costs of iterated routes, complete the following
task:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ip route-static vpn-instance vpn-source-name destination-address { mask | mask-
length } nexthop-address [ recursive-lookup host-route ] [ preference preference |
tag tag ] * inherit-cost [ description text ]
A static route is configured for a specified VPN instance and the static route is configured to
inherit the iterated route cost.
vpn-source-name specifies the VPN instance that is bound to the Layer 3 Virtual Ethernet
(L3VE) interface. nexthop-address specifies the IP address of Node B interface connected to
the AGG.
NOTE
In an IP RAN scenario, you can configure static routes to inherit iterated route costs after Configuring an
IPv4 direct route to respond to L3VE interface status changes after a delay or Configuring the
association between the IPv4 direct route and PW status.

ip route recursive-lookup arp vlink-direct-route protocol static
The device is configured to iterate static routes to ARP Vlink routes.

In a scenario in which an L2VPN accesses an L3VPN, if both the primary PW and the link
between the master and backup AGGs fail, the static route on the master AGG becomes a black-
hole route. To prevent this problem, specify recursive-lookup host-route when you configure
the static route on the AGG so that the static route is iterated to host routes and then run the ip
route recursive-lookup arp vlink-direct-route command to iterate the static route only to ARP
Vlink routes. If the primary PW fails, the master AGG deletes its ARP Vlink route. Without the
ARP Vlink route, the static route cannot be iterated. Therefore, the master AGG deletes the static
route as well. Then, RSGs select the routes advertised by the backup AGG and forwards RNC-
to-NodeB traffic through the backup AGG.
----End

After the configuration is complete, run the display ip routing-table vpn-instance vpn-
instance-name [ ip-address ] [ verbose ] command on an AGG. The command output shows
that the static route has inherited the iterated route cost. The cost of the static route has changed
with the cost of the L3VE interface's direct route to the CSG.
2.9 Configuring IPv6 Static Routes to Inherit the Costs of

Iterated Routes
and associate the priority of IPv6 static routes with link status to improve network reliability.
IPv6 Static routes inheriting the costs of iterated routes mainly apply to a scenario in which the
Layer 2 Virtual Private Network (L2VPN) accesses the Layer 3 Virtual Private Network
(L3VPN). In such a scenario, the IPv6 direct route cost is usually controlled by Configuring an
IPv6 direct route to respond to L3VE interface status changes after a delay or by

Configuring the association between the IPv6 direct route and PW status. This will reduce
downstream traffic loss during the traffic switchback after the primary pseudo wire (PW)
recovers.
However, on the network shown in Figure 2-2, the cell site gateway (CSG) is connected to
multiple base stations. These base stations usually use logical IP addresses to communicate with
access aggregation gateways (AGGs), so IPv6 direct routes between base stations and AGGs
cannot be used to forward packets. In addition, AGGs do not have routes to the logical IP
addresses of the base stations. To address this problem, you must configure IPv6 static routes
on AGGs to forward downstream traffic. As network administrators usually configure
consecutive logical IP addresses for base stations based on IP address planning, you must
configure IPv6 static routes to specific base stations on AGGs. As shown in Figure 2-2, if the
CSG-AGG1 link that bears the primary PW recovers, AGG1 immediately advertises its IPv6
static routes to radio network controller site gateways (RSGs). RSGs then select these routes
and downstream traffic is switched over to LinkA. However, AGG1 has not learned the MAC
addresses of the base stations yet and the primary PW is unavailable, so packets are dropped
during the traffic switchback.
Figure 2-2 Networking of configuring IPv6 static routes to inherit costs of iterated routes
Loopback0
1::1/128 AGG1 RSG1
NodeB
CSG PW1
Link A
Loopback0
1::2/128 Link B
NodeB RNC
PW2
Loopback0 AGG2 RSG2

1::3/128
NodeB L2VPN BGP/MPLS IPv6 VPN
PW
To solve this problem, you can configure IPv6 static routes to inherit costs of iterated routes.
Because IPv6 static routes are iterated to IPv6 direct routes and costs of IPv6 direct routes are
determined by PW status, this configuration implements the association between IPv6 static
routes and PW status. On the network shown in Figure 2-2, you can configure IPv6 statics routes
on AGG1 to inherit costs of iterated routes. When the link that bears PW1 recovers:
l If PW1 is still standby, the IPv6 direct route between AGG1 and CSG has a high cost.
Because the IPv6 static routes on AGG1 inherit the direct route cost, the IPv6 static routes
also have high costs. In this case, even if AGG1 advertises IPv6 static routes to RSGs,
RSGs do not preferentially select these routes and downstream traffic still travels along
LinkB.

l If PW1 becomes active, the IPv6 direct route between AGG1 and the CSG has the default
cost 0. Because the IPv6 static routes on AGG1 inherit the direct route cost, the IPv6 static
routes also have the cost value 0. In this case, after AGG1 advertises IPv6 static routes to
RSGs, RSGs select these routes and downstream traffic is switched over to LinkA. At this
time, AGG1 has learned the MAC addresses of the base stations, and downstream traffic
loss will be reduced.
Before configuring IPv6 static routes to inherit costs of iterated routes, complete the following
task:
l Configuring link-layer protocol parameters and IPv6 addresses for interfaces to ensure that
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 route-static vpn-instance vpn-source-name destination-address { mask | mask-
length } nexthop-address [ preference preference | tag tag ] * inherit-cost
An IPv6 static route is configured for a specified VPN instance and the IPv6 static route is
configured to inherit the iterated route cost.
vpn-source-name specifies the VPN instance that is bound to the Layer 3 Virtual Ethernet
(L3VE) interface. nexthop-address specifies the IP address of NodeB interface connected to the
AGG.
NOTE
In an IP RAN scenario, you can configure IPv6 static routes to inherit iterated route costs after Configuring
an IPv6 direct route to respond to L3VE interface status changes after a delay or Configuring the
association between the IPv6 direct route and PW status.
----End

After the configuration is complete, run the display ipv6 routing-table vpn-instance vpn-
instance-name [ ipv6-address ] [ verbose ] command on an AGG. The command output shows
that the IPv6 static route has inherited the iterated route cost. The cost of the IPv6 static route
has changed with the cost of the L3VE interface's direct route to the CSG.

Static route configuration examples explain networking requirements, networking diagrams,

NOTE
2.10.1 Example for Configuring IPv4 Static Routes

You can configure IPv4 static routes to interconnect any two devices on an IPv4 network.
Figure 2-3 shows IP addresses and masks of interfaces and hosts. It is required to interconnect
any two hosts in Figure 2-3.
Figure 2-3 Networking diagram for configuring IPv4 static routes
PC2
1.1.2.2/24
GE3/0/0
1.1.2.1/24
POS1/0/0 POS2/0/0
1.1.4.2/30 1.1.4.5/30
RouterB
RouterA RouterC
POS1/0/0 POS1/0/0
1.1.4.1/30 1.1.4.6/30
GE2/0/0 GE2/0/0
1.1.1.1/24 1.1.3.1/24
PC1 PC3
1.1.1.2/24 1.1.3.2/24
Because dynamic routing protocols cannot be configured on PC1, PC2 and PC3 in Figure 2-3,
so we configure static routes on the routers in this example.
1. Configure an IPv4 address for each interface on each router for interworking.
2. Configure an IPv4 static route and a default route to the destination address on each
router.
3. Configure an IPv4 default gateway on each host to make any two hosts communicate.
Data Preparation

l Default route with the next hop being 1.1.4.2 of Router A

l Static route with the destination address and next hop being 1.1.1.0 and 1.1.4.1 respectively
of Router B
l Static route with the destination address and next hop being 1.1.3.0, and 1.1.4.6 respectively
of Router B
l Default route with the next hop being 1.1.4.5 of Router C
l Default gateway addresses of PC1, PC2, and PC3 being 1.1.1.1, 1.1.2.1, and 1.1.3.1
respectively
Procedure
Step 2 Configure static routes.
# Configure an IPv4 default route on Router A.
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.4.2
# Configure two IPv4 static routes on Router B.

[RouterB] ip route-static 1.1.1.0 255.255.255.0 1.1.4.1
[RouterB] ip route-static 1.1.3.0 255.255.255.0 1.1.4.6
# Configure an IPv4 default route on Router C.

[RouterC] ip route-static 0.0.0.0 0.0.0.0 1.1.4.5
Step 3 Configure hosts.

Set default gateway addresses of PC1, PC2, and PC3 to 1.1.1.1, 1.1.2.1, and 1.1.3.1 respectively.
# Check the IP routing table of Router A.
[RouterA] display ip routing-table
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 RD 1.1.4.2 Pos1/0/0
1.1.1.0/24 Direct 0 0 D 1.1.1.1 GigabitEthernet2/0/0
1.1.4.0/30 Direct 0 0 D 1.1.4.1 Pos1/0/0
1.1.4.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
1.1.4.2/32 Direct 0 0 D 1.1.4.2 Pos1/0/0
# Run the ping command on Router A to verify the connectivity.

[RouterA] ping 1.1.3.1
PING 1.1.3.1: 56 data bytes, press CTRL_C to break
Reply from 1.1.3.1: bytes=56 Sequence=1 ttl=254 time=62 ms

--- 1.1.3.1 ping statistics ---

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

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

#
sysname RouterB
#
ip address 1.1.2.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
ip address 1.1.4.2 255.255.255.252
#
interface Pos2/0/0
link-protocol ppp
ip address 1.1.4.5 255.255.255.252
#
ip route-static 1.1.1.0 255.255.255.0 1.1.4.1
ip route-static 1.1.3.0 255.255.255.0 1.1.4.6
#
return

#
sysname RouterC
#
ip address 1.1.3.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
ip address 1.1.4.6 255.255.255.252
#
ip route-static 0.0.0.0 0.0.0.0 1.1.4.5
#

return
2.10.2 Example for Configuring IPv6 Static Routes

You can configure IPv6 static routes to interconnect any two devices on an IPv6 network.
As shown in Figure 2-4, the mask length of all the IPv6 addresses is 64 bits. It is required that
every two hosts or routers be interconnected.
Figure 2-4 Networking diagram for configuring IPv6 static routes
PC2
2001:db8:2::2/64
GE3/0/0
2001:db8:2::1/64
POS1/0/0 POS2/0/0
RouterB
RouterA RouterC
POS1/0/0 POS1/0/0
GE2/0/0 GE2/0/0
2001:db8:1::1/64 2001:db8:3::1/64
PC1 PC3
2001:db8:1::2/64 2001:db8:3::2/64
Because dynamic routing protocols cannot be configured on PC1, PC2 and PC3 in Figure 2-4,
so we configure static routes on the routers in this example. Addresses of POS interfaces on the
routers are IPv6 link-local addresses.
1. Configure an IPv6 address for each GE interface on each router for interworking.
2. Configure an IPv6 static route and a default route to the destination address on each
router.
3. Configure an IPv6 default gateway on each host to make any two hosts communicate.
Data Preparation
l Default route with the outbound interface being POS 1/0/0 of Router A

l Static route with the destination address and outbound interface being 2001:db8:1:: 64 and
POS 1/0/0 respectively of Router B
l Static route with the destination address and outbound interface being 2001:db8:3:: 64 and
POS 2/0/0 respectively of Router B
l Default route with the outbound interface being POS 1/0/0 of Router C
l Default gateway addresses of PC1, PC2, and PC3 being 2001:db8:1::1, 2001:db8:2::1, and
2001:db8:3::1 respectively
Procedure
Step 1 Configure an IPv6 address for each interface.
Step 2 Configure IPv6 static routes.
# Configure an IPv6 default route on Router A.

[RouterA] ipv6 route-static :: 0 pos 1/0/0
# Configure two IPv6 static routes on Router B.

[RouterB] ipv6 route-static 2001:db8:1:: 64 pos 1/0/0
[RouterB] ipv6 route-static 2001:db8:3:: 64 pos 2/0/0
# Configure an IPv6 default route on Router C.

[RouterC] ipv6 route-static :: 0 pos 1/0/0
Step 3 Configure host addresses and gateways.
Configure IPv6 addresses for hosts according to the networking diagram, and set default gateway
addresses of PC1, PC2, and PC3 to 2001:db8:1::1, 2001:db8:2::1, and 2001:db8:3::1
respectively.
# Check the IPv6 routing table of Router A.

[RouterA] display ipv6 routing-table
Destination : :: PrefixLength : 0
NextHop : FE80::E0:FCD5:A2BF:401 Preference : 60
Cost : 0 Protocol : Static
Interface : Pos1/0/0 Flags : D
Destination : ::1 PrefixLength : 128

Interface : InLoopBack0 Flags : D
Destination : 2001:db8:1:: PrefixLength : 64




# Run the ping command on Router A to verify the connectivity.

[RouterA] ping ipv6 2001:db8:3::1
PING 2001:db8:3::1 : 56 data bytes, press CTRL_C to break
Reply from 2001:db8:3::1
bytes=56 Sequence=1 hop limit=254 time = 63 ms
--- 2001:db8:3::1 ping statistics ---
0.00% packet loss
# Run the tracert command on Router A to verify the connectivity.

[RouterA] tracert ipv6 2001:db8:3::1
traceroute to 2001:db8:3::1 30 hops max,60 bytes packet
1 FE80::E0:FCD5:86D4:401 11 ms 3 ms 4 ms
2 2001:db8:3::1 4 ms 3 ms 3 ms
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
ipv6 address auto link-local
#
ipv6 route-static :: 0 Pos 1/0/0
#
return

#
sysname RouterB
#
ipv6

#
ipv6 enable
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
#
ipv6 route-static 2001:db8:1:: 64 Pos1/0/0
ipv6 route-static 2001:db8:3:: 64 Pos1/0/1
#
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
ipv6 route-static :: 0 Pos1/0/0
#
return
2.10.3 Example for Configuring BFD for IPv4 Static Routes

To improve network reliability, you can configure BFD for static route to rapidly detect link
faults and speed up route convergence.
As shown in Figure 2-5:
l Router A is connected to Router B through Switch C.
l It is required that Router A can communicate with other routers and the network.
l a BFD session is configured between Router A and Router B to detect the link between the
two devices.
Figure 2-5 Networking diagram for configuring BFD for IPv4 static routes
GE1/0/0 GE1/0/0 Pos2/0/0

1.1.1.1/24 1.1.1.2/24 2.2.2.2/24 Internet
RouterA SwitchC RouterB

Because the network topology is very simple, static routes can be configured to make RouterA
communicate with other Routers and the network. By binding BFD sessions to static routes,
BFD sessions can detect the link status, which provides the detection mechanism for static routes.
1. Configure a BFD session between Router A and Router B to detect the link between the
two devices.
2. Configure a default static route from Router A to the external network and bind the default
static route to the BFD session.
Data Preparation
l Peer IP address to be detected by BFD

l Local discriminator and remote discriminator of a BFD session
l Default values of BFD parameters, including minimum intervals for sending and receiving
BFD control packets and local detection multiplier
Procedure
Step 2 Configure a BFD session between Router A and Router B.
# On Router A, configure a BFD session with Router B.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd aa bind peer-ip 1.1.1.2
[RouterA-bfd-session-aa] discriminator local 10
[RouterA-bfd-session-aa] discriminator remote 20
[RouterA-bfd-session-aa] commit
[RouterA-bfd-session-aa] quit
# On Router B, configure a BFD session with Router A.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd bb bind peer-ip 1.1.1.1
[RouterB-bfd-session-bb] discriminator local 20
[RouterB-bfd-session-bb] discriminator remote 10
[RouterB-bfd-session-bb] commit
[RouterB-bfd-session-bb] quit
Step 3 Configure a default static route and bind it to a BFD session.
# On Router A, configure a default static route to the external network and bind it to a BFD
session named aa.

[RouterA] ip route-static 0.0.0.0 0 1.1.1.2 track bfd-session aa

# After the configuration, run the display bfd session all command on Router A and Router B.
The command output shows that a BFD session has been established and is in the Up state. Then,
run the display current-configuration | include bfd command in the system view. The
command output shows that the default static route has been bound to the BFD session.
Take the display on Router A as an example.
[RouterA] display bfd session all
--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
10 20 1.1.1.2 Up S_IP_PEER -
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
[RouterA] display current-configuration | include bfd
bfd
bfd aa bind peer-ip 1.1.1.2
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 track bfd-session aa
# Check the IP routing table of Router A. The command output shows that the static route exists
in the routing table.
------------------------------------------------------------------------------
0.0.0.0/0 Static 60 0 RD 1.1.1.2 GigabitEthernet1/0/0
# Run the shutdown command on GE 1/0/0 of Router B to simulate a link fault.

[RouterB-GigabitEthernet1/0/0] shutdown
# Check the IP routing table of Router A. The command output shows that default route 0.0.0.0/0
does not exist. This is because the default static route is bound to a BFD session. When BFD
detects a link fault, BFD rapidly notifies that the bound static route becomes unavailable. If the
static route is not bound to a BFD session, the default route 0.0.0.0/0 will always exist in IP
routing table, this may cause traffic loss.
------------------------------------------------------------------------------
----End
Configuration Files
#
sysname RouterA
#

bfd
#
ip address 1.1.1.1 255.255.255.0
#
bfd aa bind peer-ip 1.1.1.2
discriminator local 10
discriminator remote 20
commit
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 track bfd-session aa
#
return

sysname RouterB
#
bfd
#
ip address 1.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 2.2.2.2 255.255.255.0
#
bfd bb bind peer-ip 1.1.1.1
commit
#
return
2.10.4 Example for Configuring BFD for IPv6 Static Routes

To improve IPv6 network reliability, you can configure BFD for IPv6 static route to rapidly
detect link faults and speed up route convergence.
l Router A is connected to Router B through Switch C.
l It is required that Router A can communicate with other routers and the network.
l a BFD session is configured between Router A and Router B to detect the link between the
two devices.
Figure 2-6 Networking diagram for configuring BFD for IPv6 static routes
GE1/0/0 GE1/0/0 Pos2/0/0

2001:db8:1::1/64 2001:db8:1::2/64 2001:db8:2::1/64 Internet
RouterA SwitchC RouterB

Because the network topology is very simple, static routes can be configured to make RouterA
communicate with other Routers and the network. By binding BFD sessions to static routes,
BFD sessions can detect the link status, which provides the detection mechanism for static routes.
1. Configure a BFD session on Router A and Router B to detect the link between the two
devices.
2. Configure a default static route from Router A to the external network and bind the default
static route to a BFD session.
Data Preparation
l Peer IPv6 address to be detected by BFD

l Local discriminator and remote discriminator of a BFD session
l Default values of BFD parameters, including minimum intervals for sending and receiving
BFD control packets and local detection multiplier
Procedure
Step 2 Configure a BFD session between Router A and Router B.
# On Router A, configure a BFD session with Router B.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd aa bind peer-ipv6 2001:db8:1::2
[RouterA-bfd-session-aa] discriminator local 10
[RouterA-bfd-session-aa] discriminator remote 20
[RouterA-bfd-session-aa] commit
[RouterA-bfd-session-aa] quit
# On Router B, configure a BFD session with Router A.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd bb bind peer-ipv6 2001:db8:1::1
[RouterB-bfd-session-bb] discriminator local 20
[RouterB-bfd-session-bb] discriminator remote 10
[RouterB-bfd-session-bb] commit
[RouterB-bfd-session-bb] quit
Step 3 Configure a default static route and bind it to a BFD session.
# On Router A, configure a default static route to the external network and bind it to a BFD
session named aa.
[RouterA] ipv6 route-static 0::0 0 2001:db8:1::2 track bfd-session aa


# After the configuration, run the display bfd session all command on Router A and Router B.
The command output shows that a BFD session has been established and is in the Up state. Then,
run the display current-configuration | include bfd command in the system view. The
command output shows that the default static route has been bound to the BFD session.
Take the display on Router A as an example.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
10 20 2001:db8:1::2
Up S_IP_PEER -
--------------------------------------------------------------------------------
[RouterA] display current-configuration | include bfd
bfd
bfd aa bind peer-ipv6 2001:db8:1::2
ipv6 route-static :: 0 2001:db8:1::2 track bfd-session aa
# Check the IP routing table of Router A. The command output shows that the static route exists
Interface : GigabitEthernet 1/0/0 Flags : RD


Interface : GigabitEthernet 1/0/0 Flags : D


# Run the shutdown command on GE 1/0/0 of Router B to simulate a link fault.

# Check the IP routing table of Router A. The command output shows that default route 0::0/0
does not exist. This is because the default static route is bound to a BFD session. When BFD

detects a link fault, BFD rapidly notifies that the bound static route becomes unavailable. If the
static route is not bound to a BFD session, the default route 0.0.0.0/0 will always exist in IP
routing table, this may cause traffic loss.

----End
Configuration Files
#
sysname RouterA
#
ipv6
#
bfd
#
interface GigabitEthernet 1/0/0
undo shutdown
ipv6 enable
#
bfd aa bind peer-ipv6 2001:db8:1::2
commit
#
ipv6 route-static :: 0 2001:db8:1::2 track bfd-session aa
#
return

#
sysname RouterB
#
ipv6
#
bfd
#
undo shutdown
shutdown
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
#
bfd bb bind peer-ipv6 2001:db8:1::1
commit
#
return

2.10.5 Example for Configuring NQA for IPv4 Static Routes

Configuring NQA for static IPv4 routes helps detect network faults rapidly, control the
advertisement of static routes, and switch traffic to available paths.
Static routes can be configured on networks with simple topologies or for Routers that cannot
generate routes to the destination through dynamic routing protocols. Unlike dynamic routing
protocols, static routes do not have a dedicated detection mechanism. After a fault occurs, the
corresponding static route cannot be automatically deleted from the IP routing table. The network
administrator must delete the corresponding static route to allow traffic to switch to an available
path. This dependence on the administrator delays the link switchover which is likely to interrupt
services for a comparatively long time. BFD for static routes can be deployed to monitor the
status of a link, but it requires that both ends of the link support BFD. If either end of the link
does not support BFD, you can configure NQA for static IPv4 routes to monitor the link status.
On the IP MAN shown in Figure 2-7, redundant links are used and the following requirements
are met:
l Router B and Router C are configured with static routes to the clients. Router B is the master
and Router C is the backup.
l Normally, traffic travels along the active link of Router B → Switch A.
l If a fault occurs in the active link, traffic switches to the standby link of Router C → Switch
B.

Figure 2-7 Networking diagram for configuring NQA for static IPv4
IP Network
RouterA
GE2/0/0
GE1/0/0 172.16.4.1/24
172.16.3.1/24
GE2/0/0 GE2/0/0
172.16.3.2/24 172.16.4.2/24
RouterB RouterC
/0
GE1/0/0 3/0 /24 GE1/0/0
172.16.1.1/24 17 GE3 GE 6.6.1 172.16.2.1/24
2.1 /0/ 2.1
6.5 0 17 VL
.1/ 17 AN
24 2.1 IF
6.5 20
VLANIF10 2 0 .2/ VLANIF10
IF /24 24
172.16.1.2/24 N
A .6. 2 172.16.2.2/24
L
V 16
2. ......
VLANIF30 17 VLANIF30
172.16.7.1/24 SwitchA SwitchB 172.16.8.1/24
...... ......
Client1 Client10 Client91 Client100
NOTE
In this example, Switch A and Switch B provide access services for users. On live networks, Optical Line
Terminals (OLTs), Digital Subscriber Line Access Multiplexers (DSLAMs), Multi-service Access Nodes
(MSANs), or x Digital Subscriber Line (xDSL) devices can also be used to provide access services for
users. The configuration is similar on Router A, Router B and Router C.
1. Establish an ICMP NQA test instance for the NQA client Router B and the tested device
Switch A to test whether the active link of Router B → Switch A works properly.
2. Configure static routes on Router B and Router C, and associate the static route on
Router B with the NQA test instance. If the NQA test instance detects a link fault, the
system deletes the static route from the IP routing table.
3. Configure a dynamic routing protocol on Router A, Router B, and Router C to allow them
to learn routes from each other.
4. Configure OSPF on Router B and Router C to import static routes, and set a higher cost
for the static route imported to Router C than that imported to Router B. After Router A

learns routes from Router B and Router C to the same destination, it prefers the route with
a lower cost along the path of Router B → Switch A.
Data Preparation
l IP address of each interface
l Test type, administrator name, and name of an NQA test instance
l Test period and packet sending interval of the NQA test instance
l OSPF area ID (Area 0) where Router A, Router B, and Router C reside
Procedure
Step 1 Configure IP addresses. This example assumes that you know how to configure IP addresses so
that the configuration is not described here.
Step 2 Configure an NQA test instance on Router B to test the link between Router B and Switch A.
[RouterB] nqa test-instance aa bb
[RouterB-nqa-aa-bb] test-type icmp
[RouterB-nqa-aa-bb] destination-address ipv4 172.16.1.2
[RouterB-nqa-aa-bb] frequency 3
[RouterB-nqa-aa-bb] probe-count 1
[RouterB-nqa-aa-bb] start now
[RouterB-nqa-aa-bb] quit
Step 3 Configure a static route.

# Configure a static route on Router B and associate the static route with an NQA test instance.
[RouterB] ip route-static 172.16.7.0 255.255.255.0 GigabitEthernet 1/0/0
172.16.1.2 track nqa aa bb
# Configure a static route on Router C.

[RouterC] ip route-static 172.16.7.0 255.255.255.0 GigabitEthernet 3/0/0 172.16.6.2
Step 4 Configure a dynamic routing protocol on Router A, Router B, and Router C. This example uses
OSPF. For detailed instructions on configuring OSPF, see 5 OSPF Configuration.
Step 5 Configure OSPF on Router B and Router C to import static routes.
# Configure OSPF on Router B to import static routes, and set the cost of each imported static
route to 10.
[RouterB] ospf 1
[RouterB-ospf-1] import-route static cost 10
[RouterB-ospf-1] quit
# Configure OSPF on Router C to import static routes, and set the cost of each imported static
route to 20.
[RouterC] ospf 1
[RouterC-ospf-1] import-route static cost 20
[RouterC-ospf-1] quit

After completing the configuration, run the display current-configuration | include nqa
command in the system view on Router B to check whether the static route has been associated

with the NQA test instance. Then run the display nqa results command to check whether the
NQA test instance has been established.
# Check the configuration of NQA for static IPv4 routes.

[RouterB] display current-configuration | include nqa
ip route-static 172.16.7.0 255.255.255.0 GigabitEthernet 1/0/0 172.16.1.2 track
nqa aa bb
nqa test-instance aa bb
# Check the NQA test results.

[RouterB] display nqa results test-instance aa bb
NQA entry(aa, bb) :testflag is active ,testtype is icmp

Operation sequence errors number:0 RTT Status errors number:0
In this example, the information "Lost packet ratio: 0 %" is displayed, indicating that the link
works properly.
# Check the routing table on Router B. The routing table contains this static route.
[RouterB] display ip routing-table
------------------------------------------------------------------------------

172.16.1.0/24 Direct 0 0 D 172.16.1.1
172.16.1.1/32 Direct 0 0 D 127.0.0.1
172.16.1.2/32 Direct 0 0 D 172.16.1.2
172.16.3.0/24 Direct 0 0 D 172.16.3.2
172.16.3.1/32 Direct 0 0 D 172.16.3.1
172.16.3.2/32 Direct 0 0 D 127.0.0.1
172.16.4.0/24 OSPF 10 2 D 172.16.3.1
172.16.5.0/24 Direct 0 0 D 172.16.5.1
172.16.5.1/32 Direct 0 0 D 127.0.0.1
172.16.5.2/32 Direct 0 0 D 172.16.5.2
172.16.7.0/24 Static 60 0 D 172.16.1.2

# Check the routing table on Router A.

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

172.16.3.0/24 Direct 0 0 D 172.16.3.1
172.16.3.1/32 Direct 0 0 D 127.0.0.1
172.16.3.2/32 Direct 0 0 D 172.16.3.2
172.16.4.0/24 Direct 0 0 D 172.16.4.1
172.16.4.1/32 Direct 0 0 D 127.0.0.1
172.16.4.2/32 Direct 0 0 D 172.16.4.2
172.16.7.0/24 O_ASE 150 10 D 172.16.3.2
The routing table contains a route destined for 172.16.1.3/32 with the next hop of 172.16.3.2
and the cost of 10. Therefore, traffic travels along the path Router B → Switch A.
# Shut down GigabitEthernet 1/0/0 on Router B to simulate a link fault.

# Check the NQA test results.

[RouterB] display nqa results test-instance aa bb
NQA entry(aa, bb) :testflag is active ,testtype is icmp

Completion:failed RTD OverThresholds number: 0
The information "Lost packet ratio: 100 %" is displayed, indicating that the link fails.
# Check the routing table on Router B. The static route disappears.

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


172.16.3.0/24 Direct 0 0 D 172.16.3.2
172.16.3.1/32 Direct 0 0 D 172.16.3.1
172.16.3.2/32 Direct 0 0 D 127.0.0.1
172.16.4.0/24 OSPF 10 2 D 172.16.3.1
172.16.5.0/24 Direct 0 0 D 172.16.5.1
172.16.5.1/32 Direct 0 0 D 127.0.0.1
172.16.5.2/32 Direct 0 0 D 172.16.5.2
172.16.7.0/24 O_ASE 150 20 D 172.16.3.1

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

172.16.3.0/24 Direct 0 0 D 172.16.3.1
172.16.3.1/32 Direct 0 0 D 127.0.0.1
172.16.3.2/32 Direct 0 0 D 172.16.3.2
172.16.4.0/24 Direct 0 0 D 172.16.4.1
172.16.4.1/32 Direct 0 0 D 127.0.0.1
172.16.4.2/32 Direct 0 0 D 172.16.4.2
172.16.7.0/24 O_ASE 150 20 D 172.16.4.2
Because the static route is associated with the NQA test instance on Router B, after NQA detects
the link fault, it immediately notifies Router B that the associated static route is unavailable.
Router A cannot learn the route destined for 172.16.7.0/24 from Router B. Router A, however,
can learn another route destined for 172.16.7.0/24 from Router C. The next hop of the route is
172.16.4.2, and the cost is 20. Traffic switches to the link of Router C → Switch B.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
undo shutdown

ip address 172.16.3.1 255.255.255.0

#
undo shutdown
ip address 172.16.4.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 172.16.3.0 0.0.0.255
network 172.16.4.0 0.0.0.255
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
undo shutdown
ip address 172.16.3.2 255.255.255.0
#
undo shutdown
ip address 172.16.5.1 255.255.255.0
#
ospf 1
import-route static cost 10
area 0.0.0.0
network 172.16.3.0 0.0.0.255
#
ip route-static 172.16.7.0 255.255.255.0 GigabitEthernet1/0/0 172.16.1.2 track
nqa aa bb
#
nqa test-instance aa bb
test-type icmp
destination-address ipv4 172.16.1.2
frequency 3
probe-count 1
start now
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
undo shutdown
ip address 172.16.2.1 255.255.255.0
#
undo shutdown
ip address 172.16.4.2 255.255.255.0
#
undo shutdown
ip address 172.16.6.1 255.255.255.0
#
ospf 1


area 0.0.0.0
network 172.16.4.0 0.0.0.255
#
ip route-static 172.16.7.0 255.255.255.0 GigabitEthernet3/0/0 172.16.6.2
#
return
2.10.6 Example for Configuring NQA for IPv6 Static Routes

NQA for IPv6 static routes can quickly detect network faults and control advertisement of static
routes.
On a simple network or when the route to the destination cannot be established using dynamic
routing protocols, you can configure static routes. Unlike dynamic routing protocols, static routes
do not have a dedicated detection mechanism. After a fault occurs, static routes cannot detect
the fault, and the network administrator must delete the corresponding static route. This delays
the link switchover and probably interrupts services for a comparatively long time.
BFD for static routes is adaptable to link changes but both ends of the link must support BFD.
If either end of the link does not support BFD, you can configure NQA for IPv6 static routes.
When an NQA test instance detects a link fault, the static route associated with the NQA test
instance will be deleted from the IP routing table and the traffic is switched to a normal route to
prevent long-time service interruption.
As shown in Figure 2-8, the IP MAN of a company is configured with redundant backup links.
l Router B and Router C are configured with static routes. Router B is the master Router and
Router C is the backup Router.
l Normally, traffic is forwarded through the active link Router B→Switch A.
l When the active link becomes faulty, traffic is switched to the backup link Router C→
Switch B.

Figure 2-8 Networking for configuring NQA for static IPv6 routes
IP Network
RouterA
GE1/0/0 GE2/0/0
2001:db8:1::1/64 2001:db8:2::1/64
GE2/0/0
2001:db8:1::2/64
GE2/0/0
2001:db8:2::2/64
RouterB RouterC
GE1/0/0 GE GE3/0/0 GE1/0/0

3
2001:db8:3::1/64 200 /0/0 2001:db8:6::1/64 2001:db8:4::1/64
1 :d
b8
:5 ::1
/64 20
0 1 : d VL A
b 8 N IF
:5:
VLANIF10 :2 / 2 0 VLANIF10
2001:db8:3::2/64 0 /6 4 64 2001:db8:4::2/64
I F2 :6::2
AN 8
VL 01:db ......
VALNIF30 20 VLANIF30
SwitchA SwitchB
2001:db8:7::1/64 2001:db8:8::1/64
...... ......
Client1 Client10 Client91 Client100
NOTE
In this diagram, Switch A and Switch B provide the access service for subscribers. In actual networking,
Optical Line Terminals (OLTs), Digital Subscriber Line Access Multiplexers (DSLAMs), Multi-service
Access Nodes (MSANs), or x Digital Subscriber Line (xDSL) can be used for user access. The
configurations on Router A, Router B, and Router C are the same.
1. Configure an ICMP NQA test instance on the NQA client Router B to test whether the
active link Router B→Switch A runs properly.
2. Configure static routes on Router B and Router C and associate the static route of Router
B with the configured NQA test instance. When a fault is detected on the link, the static
route associated with Router B is deleted from the IPv6 routing table.
3. Configure a dynamic routing protocol on Router A, Router B, and Router C so that they
can learn routes from each other.
4. Configure OSPFv3 on Router B and Router C to import static routes and set the cost to the
static route imported by Router C to be larger than the cost of the static route imported by

Router B. Router A learns the route to the same destination from Router B and Router C
and the link Router B→Switch A with lower cost will be selected.
Data Preparation
l IPv6 address of each interface

l Administrator name (admin1) and name of an ICMP NQA test instance (test1)
l Test period (3s) and the number (1) of test probes of the NQA test instance
l OSPFv3 backbone area (Area 0) of Router A, Router B and Router C, and their router IDs
(1.1.1.1, 2.2.2.2, and 3.3.3.3)
Procedure
Step 1 Configure IPv6 addresses.
Configure IPv6 addresses for interfaces according to Figure 2-8. For details, see configuration
files.
Step 2 Configure an NQA test instance on Router B to test the link between Router B and Switch A.
[RouterB] nqa test-instance admin1 test1
[RouterB-nqa-admin1-test1] test-type icmp
[RouterB-nqa-admin1-test1] destination-address ipv6 2001:db8:3::2
[RouterB-nqa-admin1-test1] frequency 3
[RouterB-nqa-admin1-test1] probe-count 1
[RouterB-nqa-admin1-test1] start now
[RouterB-nqa-admin1-test1] quit
Step 3 Configure IPv6 static routes.
Configure a static IPv6 route on Router B and associate the static route with the configured NQA
test instance.
[RouterB] ipv6 route-static 2001:db8:7:: 64 GigabitEthernet 1/0/0 FE80:1::1 track
nqa admin1 test1
Configure a static route on Router C.

[RouterC] ipv6 route-static 2001:db8:7:: 64 GigabitEthernet 3/0/0 FE80:2::2
NOTE
The next hop address of the static IPv6 route configured on the local end should be the link-local address
of the peer end. Run the display ipv6 interface [ interface-type interface-number ] command to obtain the
address of the peer end of the link.
Step 4 Configure a dynamic routing protocol on Router A, Router B, and Router C. OSPFv3 is used in
this example. For details, see 6.2 Configuring Basic OSPFv3 Functions.
Step 5 Configure OSPFv3 on Router B and Router C to import a static route.
# Configure OSPFv3 on Router B to import static routes and set the route cost to 10.
[RouterB] ospfv3 1
[RouterB-ospfv3-1] import-route static cost 10
# Configure OSPFv3 on Router C to import static routes and set the route cost to 20.

[RouterC] ospfv3 1
[RouterC-ospfv3-1] import-route static cost 20
After the configuration is complete, run the display current-configuration | include nqa
command on Router B in the system view. The command output shows that the static IPv6 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 the configurations of NQA for static IPv6 routes.

[RouterB] display current-configuration | include nqa
ipv6 route-static 2001:db8:7:: 64 GigabitEthernet1/0/0 FE80:1::1 track nqa admin1
test1
# Display the NQA test results.

[RouterB] display nqa results test-instance admin1 test1

Destination ip address:2001:db8:3::2
The command output shows "Lost packet ratio 0 %", indicating that the link status is normal.
# Display the routing table of Router B. The static route exists in the routing table.
[RouterB] display ipv6 routing-table 2001:db8:7::
Routing Table :
Summary Count : 1

# View the routing table of Router A.

[RouterA] display ipv6 routing-table 2001:db8:7::
Routing Table :
Summary Count : 1

NextHop : FE80::D16A:0:7086:1 Preference : 150
Cost : 10 Protocol : OSPFv3ASE
A route to 2001:db8:7::/64 exists in the routing table, with the outbound interface GE 1/0/0 and
the cost 10. Traffic will be forwarded through the link Router B→Switch A.

# Shut down GE 2/0/0 on Router B to simulate a link fault.

# Display the NQA test results.

[RouterB] display nqa results test-instance admin1 test1

Completion:failed RTD OverThresholds number: 0
Destination ip address:2001:db8:3::2
The command output shows "Lost packet ratio is 100%", indicating that the link is faulty.
# Display the routing table of Router B. The static route is deleted. The route is an OSPFv3 route
learned from router A.
[RouterB] display ipv6 routing-table 2001:db8:7::
Routing Table :
Summary Count : 1

NextHop : FE80::9574:0:DA4F:1 Preference : 150
# Display the routing table of Router A.

[RouterA] display ipv6 routing-table 2001:db8:7::
Routing Table :
Summary Count : 1

NextHop : FE80::740F:0:D240:3 Preference : 150
The static route is associated with the NQA test instance on Router B. After detecting a link
fault, NQA rapidly notifies Router B that the associated static route is unavailable. Router A
cannot learn the route to 2001:db8:7::/64 from Router B. However, Router A can learn the route
to 2001:db8:7::/64 from Router C. The outbound interface to 2001:db8:7::/64 is changed to GE
2/0/0 and the cost is 20. Traffic will be switched to Router C→Switch B.
----End
Configuration Files

#
sysname RouterA
#
ipv6
#
ospfv3 1
router-id 1.1.1.1
#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
#
return

#
sysname RouterB
#
ipv6
#
ospfv3 1
router-id 2.2.2.2
#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
#
ipv6 route-static 2001:db8:7:: 64 GigabitEthernet1/0/0 FE80:1::1 track nqa
admin1 test1
#
test-type icmp
destination-address ipv6 2001:db8:3::2
frequency 3
probe-count 1
start now
#
return

#
sysname RouterC
#
ipv6

#
ospfv3 1
router-id 3.3.3.3
#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
#
ipv6 route-static 2001:db8:7:: 64 GigabitEthernet3/0/0 FE80:2::2
#
return
2.10.7 Example for Configuring Permanent Advertisement of IPv4

Static Routes
By configuring permanent advertisement of static routes, you can determine the forwarding path
of service traffic and provide a low-cost and simple link detection mechanism.
If service traffic needs to be forwarded along a specified path, you can detect links of the
forwarding path by pinging the destination addresses of static routes. In this manner, you can
monitor services at a very low cost.
As shown in Figure 2-9, EBGP peer relationships are established between Router A and
Router B, and between Router A and Router C by using static routes. There are two links (Link
A and Link B) between Router A and Router B. By configuring permanent advertisement of
static routes, you can make traffic be forwarded along only Link A regardless of the outbound
interface status and detect the status of Link A by periodically pinging the interface address of
Router B through the network monitoring system. This detects the status of BGP services.

Figure 2-9 Networking for configuring permanent advertisement of IPv4 static routes
Loopback0
2.2.2.2/32
POS1/0/0
40.1.1.2/24 RouterB
POS1/0/0
40.1.1.1/24 POS2/0/0
A
Link 30.1.1.1/24
RouterA
LinkB
POS2/0/0
POS2/0/0
30.1.1.2/24
AS100 20.1.1.1/24
POS1/0/0 RouterC
20.1.1.2/24
AS20
0
1. Configure OSPF on devices in AS 200 to ensure that routes to the address of Loopback0
on Router B are advertised to Router C.
2. Establish EBGP peer relationships between Router A and Router B, and between Router
A and Router C.
3. On Router A, configure a static route whose destination address is the address of Loopback0
on Router B and outbound interface is POS 1/0/0 on Router A.
4. On Router A, configure permanent advertisement of the static route to the address of
Loopback0 on Router B. In this manner, when POS 1/0/0 on Router A becomes faulty, the
static route to the address of Loopback0 on Router B still takes effect.
Data Preparation
l OSPF process IDs of Router B and Router C

l Router IDs and AS numbers of all routers
Procedure
Step 1 Configure an IP address for each interface. This example assumes that you know the
configuration method and no details are provided here.

Step 2 Configure basic OSPF functions on devices in AS 200.

[RouterB] ospf 1
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterC] ospf 1
[RouterC-ospf-1] area 0
[RouterC-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
# After the preceding configurations, check the routing table of Router C.

[RouterC] display ip routing-table
------------------------------------------------------------------------------
2.2.2.2/32 OSPF 10 1 D 30.1.1.1 Pos2/0/0

20.1.1.0/24 Direct 0 0 D 20.1.1.2 Pos1/0/0
20.1.1.1/32 Direct 0 0 D 20.1.1.1 Pos1/0/0
20.1.1.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
30.1.1.0/24 Direct 0 0 D 30.1.1.2 Pos2/0/0
30.1.1.1/32 Direct 0 0 D 30.1.1.1 Pos2/0/0
30.1.1.2/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
The preceding display shows that Router C has learned the OSPF route to 2.2.2.2/32.
Step 3 Configure EBGP connections and establish EBGP peer relationships between Router A and
Router B, and between Router A and Router C.
[RouterA] bgp 100
[RouterA-bgp] peer 40.1.1.2 as-number 200
[RouterA-bgp] quit
[RouterB] bgp 200
[RouterB-bgp] peer 40.1.1.1 as-number 100
[RouterB-bgp] quit
[RouterC] bgp 200
[RouterC-bgp] network 20.1.1.0 255.255.255.0
[RouterC-bgp] import-route ospf 1
[RouterC-bgp] quit
# After the preceding configurations, check the EBGP connection status of Router A.

[RouterA] display bgp peer

BGP local Router ID : 40.1.1.1

PrefRcv
40.1.1.2 4 200 2 2 0 00:00:28 Established 0

20.1.1.2 4 200 2 2 0 00:00:01 Established 0
The preceding display shows that the status of BGP connections between Router A and
Router B, and between Router A and Router C is Established. This indicates that EBGP peer
relationships have been established.
# After the preceding configurations, check the routing table of Router A.

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

2.2.2.2/32 EBGP 255 1 D 20.1.1.2 Pos2/0/0
40.1.1.0/24 Direct 0 0 D 40.1.1.1 Pos1/0/0
40.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
40.1.1.2/32 Direct 0 0 D 40.1.1.2 Pos1/0/0
20.1.1.0/24 Direct 0 0 D 20.1.1.1 Pos2/0/0
20.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
20.1.1.2/32 Direct 0 0 D 20.1.1.2 Pos2/0/0
30.1.1.0/24 EBGP 255 0 D 20.1.1.2 Pos2/0/0
The preceding display shows that Router A has learned the BGP route to 2.2.2.2/32.
Step 4 On Router A, configure a static route whose destination address is 2.2.2.2/32 and outbound
interface is POS 1/0/0.
[RouterA] ip route-static 2.2.2.2 32 pos1/0/0 40.1.1.2

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

2.2.2.2/32 Static 60 0 D 40.1.1.2 Pos1/0/0
40.1.1.0/24 Direct 0 0 D 40.1.1.1 Pos1/0/0
40.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
40.1.1.2/32 Direct 0 0 D 40.1.1.2 Pos1/0/0
20.1.1.0/24 Direct 0 0 D 20.1.1.1 Pos2/0/0
20.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
20.1.1.2/32 Direct 0 0 D 20.1.1.2 Pos2/0/0
30.1.1.0/24 EBGP 255 0 D 40.1.1.2 Pos1/0/0

The preceding display shows that the static route to 2.2.2.2/32 is preferred because the priority
of a static route is higher than that of a BGP route.
# Run the shutdown command on POS 1/0/0 of Router A to simulate a link fault.
[RouterA] interface pos 1/0/0
[RouterA-Pos1/0/0] shutdown
[RouterA-Pos1/0/0] quit
# After the preceding configurations, run the tracert command on Router A to check the
forwarding path of ping packets.
[RouterA] tracert 2.2.2.2
traceroute to 2.2.2.2(2.2.2.2), max hops: 30 ,packet length: 40,press CTRL_C t o
break
1 20.1.1.2 50 ms 30 ms 30 ms
2 30.1.1.1 < AS=200 > 50 ms 60 ms 60 ms
The command output shows that ping packets detour around Link B after Link A becomes faulty.
This indicates that the EBGP route to 2.2.2.2/32 is preferred after the static route to 2.2.2.2/32
becomes inactive. In this case, the status of Link A cannot be detected through a ping operation.
# Configure permanent advertisement of static routes on Router A.

[RouterA] ip route-static 2.2.2.2 32 pos1/0/0 40.1.1.2 permanent

------------------------------------------------------------------------------
1.1.1.1/32 Direct 0 0 D 127.0.0.1 LoopBack0

2.2.2.2/32 Static 60 0 D 40.1.1.2 Pos1/0/0
20.1.1.0/24 Direct 0 0 D 20.1.1.1 Pos2/0/0
20.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
20.1.1.2/32 Direct 0 0 D 20.1.1.2 Pos2/0/0
30.1.1.0/24 EBGP 255 0 D 20.1.1.2 Pos2/0/0
The preceding display shows that the static route to 2.2.2.2/32 is still valid and the EBGP route
to 2.2.2.2/32 is not preferred after the outbound interface of the static route becomes faulty.
# Run the ping command on Router A to check whether Router A can ping successfully
2.2.2.2/32.
[RouterA] ping 2.2.2.2
Request time out
Request time out
Request time out
Request time out
Request time out

100.00% packet loss

The preceding command output shows that after permanent advertisement of static routes is
configured, ping packets are still forwarded along Link A but not Link B when Link A becomes
faulty, and the connectivity of Link A can be detected through a ping operation.
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
shutdown
ip address 40.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
#
ip route-static 2.2.2.2 255.255.255.255 Pos1/0/0 40.1.1.2 permanent
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 40.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 30.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 200
#
ipv4-family unicast
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return


#
sysname RouterC
#
interface Pos1/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 30.1.1.2 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 20.1.1.0 255.255.255.0
import-route ospf 1
#
ospf 1
import-route direct
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return

Configuration Guide - IP Routing 3 RIP Configuration
3 RIP Configuration
About This Chapter
RIP can advertise and receive routes to affect the selection of data forwarding paths, and can
provide the network management function. RIP is commonly used on small-scale networks.
3.1 Introduction
RIP is a dynamic routing protocol used on small-scale networks. It is an Interior Gateway
Protocol (IGP) and uses the distance-vector routing algorithm.
3.2 Configuring Basic RIP Functions

To implement RIP features, configure basic RIP functions including enabling RIP, specifying
the network segment in which RIP runs, and setting the RIP version.
3.3 Configuring RIP Route Attributes

By setting RIP route attributes, you can change RIP routing policies to meet the requirements
of complex networks.
3.4 Configuring RIP to Import External Routes

RIP can import external routes to enrich routing information.
3.5 Controlling the Advertising of RIP Routing Information

To meet the requirements of complex networks, accurately controlling the advertising of RIP
routing information is essential.
3.6 Controlling the Receiving of RIP Routing Information

To meet the requirements of complex networks, accurately controlling the receiving of RIP
3.7 Configuring RIP-2 Features

Different from RIP-1, RIP-2 supports VLSM, CIDR, and authentication to ensure higher
security.
3.8 Optimizing a RIP Network

You can adjust and optimize the RIP network performance by configuring RIP functions in
special network environments, such as configuring RIP timers, setting the interval for sending
packets, and setting the maximum number of packets to be sent.
3.9 Configuring RIP GR

This section describes how to configure RIP GR to avoid incorrect route calculation and packet
loss after a RIP router restarts.
3.10 Configuring BFD for RIP

On a network that runs high-rate data services, BFD for RIP can be configured to quickly detect
and respond to network faults.
3.11 Configuring Static BFD for RIP

BFD provides link failure detection featuring light load and high speed. Static BFD for RIP is
a mode to implement the BFD function.
3.12 Configuring the Network Management Function in RIP

By binding RIP to MIBs, you can view and configure RIP through the NMS.
3.13 Maintaining RIP

This section describes how to reset RIP connections and clear RIP information.

In actual networking, RIP versions and whether to import external routes will affect which routes
can be learned.

3.1 Introduction
RIP is a dynamic routing protocol used on small-scale networks. It is an Interior Gateway
Protocol (IGP) and uses the distance-vector routing algorithm.
3.1.1 Overview of RIP

RIP is widely used on small-scale network because it is simple to deploy and easier to configure
and maintain than OSPF and IS-IS.
The Routing Information Protocol (RIP) is a simple Interior Gateway Protocol (IGP). RIP is
mainly used on small-scale networks such as campus networks and simple regional networks.
RIP uses the distance-vector routing algorithm and exchanges routing information by using User
Datagram Protocol (UDP) packets through port 520.
RIP uses the hop count to measure the distance to the destination. The distance is called the
routing metric. In RIP, the hop count from a router to its directly connected network is 0, and
the hop count from a router to a network, which can be reached through another router, is 1. To
speed up route convergence, RIP defines the cost as an integer that ranges from 0 to 15. If the
hop count is equal to or exceeds 16, the destination network or host is unreachable because the
path is considered to have an infinite metric. It is this limitation to the hop count that makes RIP
inapplicable to large-scale networks.
To improve network performance and prevent routing loops, RIP supports both split horizon
and poison reverse.
l Split horizon is a method of preventing routing loops in a network and reducing bandwidth
consumption. The basic principle is simple: Information about the routing for a particular
packet is never sent back in the direction from which it was received.
l Poison reverse is that RIP sets the cost of the route learnt from an interface of a neighbor
to 16 (specifying the route as unreachable) and then sends the route from the interface back
to the neighbor. In this way, RIP can delete useless routes from the routing table of the
neighbor.
RIP has two versions:
l RIPv1
l RIPv2
RIPv1 is a classful routing protocol, whereas RIPv2 is a classless routing protocol. In RIPv2,
address 224.0.0.9 is the multicast address of a RIP router.
Compared with RIPv1, RIPv2 has the following advantages:

l Supports route tag and can flexibly control routes on the basis of the tag in the routing
policy.
l Provides packets that contain mask information and supports route aggregation 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 Uses multicast routes to send update packets. Only RIPv2 routers can receive protocol
packets. This reduces the resource consumption.
l Provides three authentication modes to enhance security: plain-text authentication, MD5
authentication and HMAC-SHA256 authentication.
3.1.2 RIP Features Supported by the NE80E/40E

The RIP features supported by the NE80E/40E include RIPv1, RIPv2, split horizon, poison
reverse, and multi-instance.
The NE80E/40E supports the following RIP features:
l RIPv1 and RIPv2

l RIP multi-instance, which functions as an internal routing protocol for VPNs and runs
between CEs and PEs in MPLS L3VPN networks
NOTE
For detailed configuration of a VPN instance, see the chapter "BGP MPLS IP VPN Configuration" in the
NE80E/40E Router Configuration Guide - VPN.
3.2 Configuring Basic RIP Functions

To implement RIP features, configure basic RIP functions including enabling RIP, specifying
the network segment in which RIP runs, and setting the RIP version.

Before configuring basic RIP functions, familiarize yourself with the usage scenario, complete
Configuring basic RIP functions allows you to enjoy certain RIP features.
Before configuring basic RIP functions, complete the following tasks:
l Configuring the link layer protocol

l Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer
Data Preparation
To configure basic RIP functions, you need the following data.
No. Data
1 RIP process ID

No. Data
2 Network segment in which the RIP interface resides
3 RIP version number
3.2.2 Enabling RIP

Creating RIP processes is the prerequisite to performing RIP configurations.
Context
If you run RIP-related commands in the interface view before enabling RIP, the configurations
take effect only after RIP is enabled.
Perform the following steps on the router to be enabled with RIP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
The RIP is enabled and the RIP view is displayed.
RIP supports multi-instance. To associate RIP processes with VPN instances, you can run the
rip [ process-id ] vpn-instance vpn-instance-name command.
NOTE
For easy management and effective control, RIP supports multi-process and multi-instance. The multi-
process feature allows a set of interfaces to be associated with a specific RIP process and an interface can
be associated with only one RIP process. This ensures that the specific RIP process performs all the protocol
operations only on this set of interfaces. Therefore, multiple RIP processes can work on a single router and
each process is responsible for a unique set of interfaces. In addition, the routing data is independent
between RIP processes; however, routes can be imported between processes.
For the routers that support the VPN, each RIP process is associated with a specific VPN instance. In this
case, all the interfaces attached to the RIP process should be associated with the RIP-process-related VPN
instance.

description
Descriptions for RIP processes are configured.
----End

3.2.3 Enabling RIP on the Specified Network Segment

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.
Context
By default, after RIP is enabled, it is disabled on all interfaces.
Perform the following steps on the router to be enabled with RIP.
Procedure
Step 1 Run:
system-view

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

Step 3 Run:
network network-address
RIP is enabled in the specified network segment.

network-address specifies the address of a natural network segment.
NOTE
An interface can be associated with only one RIP process.

If any network segment in which an interface configured with multiple sub-interface IP addresses resides
is associated with a RIP process, the interface cannot be associated with any other RIP processes.
----End
3.2.4 Configuring RIP Version Number

RIP versions include RIPv1 and RIPv2. The two versions have different functions.
Context
Perform the following steps on the RIP router.
Procedure
l Configuring the Global RIP Version Number
1. Run:
system-view

2. Run:
rip [ process-id ]


3. Run:
version { 1 | 2 }
The global RIP version number is specified.
The RIP-1 protocol poses a security risk, and therefore the RIP-2 protocol is
recommended.
l Configuring the RIP Version Number for an Interface
1. Run:
system-view

2. Run:

3. Run:
rip version { 1 | 2 [ broadcast | multicast ] }
The RIP version number of the packets received by the interface is specified.
NOTE
By default, an interface receives both RIPv1 and RIPv2 packets but sends only RIPv1 packets.
When configuring RIPv2 on an interface, you can specify the mode in which the interface sends
packets. 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.
The RIP-1 protocol poses a security risk, and therefore the RIP-2 protocol is recommended.
----End

After basic RIP functions are successfully configured, you can view the current running status,
configuration, and routing information of RIP.
Prerequisites
Basic RIP functions has been configured.
Procedure
l Run display rip [ process-id | vpn-instance vpn-instance-name ] command to check the
running status and configuration of RIP.
l Run display rip process-id route command to check all the RIP routes that are learned
from other routers.
l Run display default-parameter rip command to check the default RIP configuration.
l Run the display rip process-id statistics interface { all | interface-type interface-
number [ verbose | neighbor neighbor-ip-address ] } command to check statistics about
RIP interfaces.
----End

Example
Run the display rip [ process-id | vpn-instance vpn-instance-name ] command, and you can
view the running status and configuration of the enabled RIP process. The command output
shows that two VPN instances are running. The first VPN instance is a public network instance;
the second VPN instance is named VPN-Instance-1.
<HUAWEI> display rip
Public VPN-instance
RIP process : 1
RIP version : 1
Preference : 100
Checkzero : Enabled
Default-cost : 0
Summary : Enabled
Host-route : Enabled
Maximum number of balanced paths : 32
Update time : 30 sec Age time : 180 sec
Garbage-collect time : 120 sec
Graceful restart : Disabled
BFD : Disabled
Silent interfaces : None
Verify-source : Enabled
Networks :
172.4.0.0
Configured peers : None
Number of routes in database : 4
Number of interfaces enabled : 3
Triggered updates sent : 3
Number of route changes : 6
Number of replies to queries : 1
Number of routes in ADV DB : 6
Private VPN-instance name : VPN-Instance-1
RIP process : 2
RIP version : 1
Preference : 100
Checkzero : Enabled
Default-cost : 0
Summary : Enabled
BFD : Disabled
Silent interfaces : None
Default-route : Disabled
Networks :
192.4.5.0
Configured peers : None
Triggered updates sent : 0
Number of route changes : 0
Number of replies to queries : 0
Number of routes in ADV DB : 6
Total count for 2 process :
Number of routes sendable in a periodic update : 6
Number of routes sent in last periodic update : 4
Run the display rip process-id route command, and you can view all activated and inactivated
routes of the specified RIP process.

<HUAWEI> display rip 1 route

Route Flags: R - RIP
A - Aging, G - Garbage-collect
----------------------------------------------------------------------------
Peer 192.168.5.1 on Pos3/0/1
Destination/Mask Nexthop Cost Tag Flags Sec
172.16.0.0/16 192.168.5.1 1 0 RA 15
192.168.14.0/24 192.168.5.1 2 0 RA 15
192.168.5.0/24 192.168.5.1 1 0 RA 15
Run the display default-parameter rip command, and you can view the default RIP
configuration.
<HUAWEI> display default-parameter rip
--------------------------------------------
Protocol Level Default Configurations
--------------------------------------------
RIP version : 1
Preference : 100
Checkzero : Enabled
Default-cost : 0
Auto Summary : Enabled
Maximum Balanced Paths : 32
Default-route : Disabled
--------------------------------------------
Interface Level Default Configurations
--------------------------------------------
Metricin : 0
Metricout : 1
Input Packet Processing : Enabled
Output Packet Processing: Enabled
Poison Reverse : Disabled
Replay Protect : Disabled
Split Horizon
For Broadcast and P2P Interfaces : Enabled
For NBMA Interfaces : Disabled
Packet Transmit Interval : 200 msecs
Packet Transmit Number : 50
RIP Protocol Version : RIPv1 Compatible (Non-Standard)
Run the display rip process-id statistics interface { all | interface-type interface-number
[ verbose | neighbor neighbor-ip-address ] } command, and you can view statistics about the
specified RIP interface.
<HUAWEI> display rip 1 statistics interface gigabitethernet1/0/0
GigabitEthernet1/0/0(10.0.0.11)
Statistical information Last min Last 5 min Total
------------------------------------------------------------------
Periodic updates sent 5 23 259
Triggered updates sent 5 30 408
Response packet sent 10 34 434
Response packet received 15 38 467
Response packet ignored 0 0 0
Request packet sent 1 3 8
Request packet received 4 20 40
Request packet ignored 0 0 0
Bad packets received 0 0 0
Routes received 0 0 0
Routes sent 0 0 0
Bad routes received 0 0 0
Packet authentication failed 0 0 0
Packet send failed 0 0 0

3.3 Configuring RIP Route Attributes

By setting RIP route attributes, you can change RIP routing policies to meet the requirements
of complex networks.

RIP route attributes include the RIP preference, additional metrics of an interface, and maximum
number of equal-cost routes.
For complex networks, you can set RIP route attributes to change RIP routing policies. After
performing the configuration procedures in this section, you can:
l Affect route selection by changing the additional metric of a RIP interface.

l Change the matching order by configuring the RIP preference when multiple routing
protocols discover routes to the same destination.
l Implement load balancing among multiple equal-cost routes.
Before configuring RIP route attributes, complete the following tasks:
the network layer
l Configuring Basic RIP Functions
Data Preparation
To configure RIP route attributes, you need the following data.
No. Data
1 Additional metric of the interface
2 RIP preference
3 Maximum number of equal-cost routes
3.3.2 Configuring Additional Metrics of an Interface

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.
Context
The additional metric is added to the original metric of the RIP route.

l The rip metricin command is used to add an additional metric to an incoming route. After
this route is added to the routing table, its metric in the routing table changes.Running this
command affects route selection on the local device and other devices on the network.
l The rip metricout command is used to add an additional metric to an outgoing route. When
this route is advertised, an additional metric is added to this route, but the metric of the
route in the routing table does not change. Running this command does not affect route
selection on the local device or other devices on the network.
Perform the following steps on the RIP router:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run any of the following commands as required:

l Based on the basic ACL:
1. Run rip metricin { value | { acl-number | acl-name acl-name } value1 }, the metric
added to an incoming route is set.
2. Run quit, return to the system view.
3. Run acl { [ number ] acl-number1 | name acl-name basic [ number acl-number2 ] }
[ match-order { auto | config } ], the basic ACL view is displayed.
4. Run rule [ rule-id ] { deny | permit } [ fragment-type fragment-type-name | source
{ source-ip-address source-wildcard | any } | time-range time-name | vpn-instance
vpn-instance-name ] *, a rule is configured for the basic ACL.
l Based on the named advanced ACL:
1. Run rip metricin { value | acl-name acl-name value1 }, the metric added to an incoming
route is set.
3. Run acl name acl-name advance [ number acl-number2 ] [ match-order { auto |
config } ], the basic ACL view is displayed.
4. Run rule [ rule-id ] { deny | permit } protocol [ source { source-ip-address source-
wildcard | any } | time-range time-name ] *, a rule is configured for the basic ACL.
l Based on the IP prefix: rip metricin { value | ip-prefix ip-prefix-name value1 }
NOTE
You can specify the value of the metricin to be added to the RIP route that passes the filtering policy by
specifying value1 through an ACL or an IP prefix list. If a RIP route does not pass the filtering, its metric
is not incremented.


1. Run rip metricout { value | { acl-number | acl-name acl-name } value1 }, the metric
added to an outgoing route is set.
1. Run rip metricout { value | acl-name acl-name value1 }, the metric added to an
outgoing route is set.
l Based on the IP prefix: rip metricout { value | ip-prefix ip-prefix-name value1 }
NOTE
You can specify the value of the metricout to be added to the RIP route that passes the filtering policy by
specifying value1 through an ACL or an IP prefix list. If a RIP route does not pass the filtering, its metric
is increased by 1.
----End
3.3.3 Configuring RIP Preference

When there are routes discovered by multiple routing protocols on the same Router, you can set
RIP preferences to instruct the Router to prefer certain RIP routes over others.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
preference { preference | route-policy route-policy-name } *
The RIP preference is set.

By default, the RIP preference is 100.
----End
3.3.4 Setting the Maximum Number of Equal-Cost Routes

By setting the maximum number of equal-cost RIP routes, you can change the number of routes
for load balancing.
Context
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.
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. Interface index: If routes have the same priorities, routes with higher interface index values are selected
for load balancing.
2. Next hop IP address: If routes have the same priorities and interface index values, routes with larger
IP address are selected for load balancing.
----End

After RIP route attributes are successfully set, you can view the current running status,
configuration, and routing information about RIP.
Prerequisites
RIP route attributes has been configured.
Procedure
l Run display rip [ process-id | vpn-instance vpn-instance-name ] command to check the
running status and configuration of RIP.

l Run display rip process-id database command to check all activated routes in the RIP
database.
l Run display rip process-id route command to check all the RIP routes that are learned
from other routers.
----End
Example
Run the display rip process-id database command, and you can view information about the
database of the specified RIP process.
<HUAWEI> display rip 100 database
---------------------------------------------------
Advertisement State : [A] - Advertised
[I] - Not Advertised/Withdraw
---------------------------------------------------
10.0.0.0/8, cost 0, ClassfulSumm
10.1.1.0/24, cost 0, [A], Imported
10.10.10.0/24, cost 0, [A], Rip-interface
10.137.220.0/23, cost 1, [A], nexthop 10.10.10.2
3.4 Configuring RIP to Import External Routes

RIP can import external routes to enrich routing information.
Context
To access a device running a non-RIP protocol, an RIP-capable device needs to import routes
of the non-RIP protocol into the RIP network.
All the following commands can set the cost of the imported route, which are listed in descending
order of priorities.
l Run the apply cost command to set the cost of a route.

l Run the import-route (RIP)command to set the cost of the imported route.
l Run the default-cost (RIP) command to set the cost of the default route.
Before configuring RIP to import external routes, complete the following tasks:
the network layer
Data Preparation
To configure RIP to import external routes, you need the following data.
No. Data
1 Protocol name and process ID of the external route to be imported

Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]

default-cost cost
The default cost of imported routes is set.
If no cost is specified, this command can be used to set the default cost for the external routes
imported by RIP from other routing protocols.
Step 4 Run:
import-route bgp [ permit-ibgp ] [ cost { cost | transparent } | route-policy route-
policy-name ] * or import-route { { static | direct } | { { rip | ospf | isis }
[ process-id ] } } [ cost cost | route-policy route-policy-name ] *
NOTE
Import of IBGP routes in RIP process can lead to routing loops. Administrator should take care of routing
loops before configuring permit-ibgp.
----End
3.5 Controlling the Advertising of RIP Routing Information

To meet the requirements of complex networks, accurately controlling the advertising of RIP

RIP routing information can be advertised through default routes and Update packets.
To meet the requirements of a network, you need to control the advertising of RIP routing
information accurately. After performing the configuration procedures in this section, you can:
l Advertise default routes to neighbors.

l Suppress interfaces from sending RIP Update packets.
l Filter the routes to be advertised.

Before configuring the router to control the advertising of RIP routing information, complete
the following tasks:
the network layer
Data Preparation
To control the advertising of RIP routing information, you need the following data.
No. Data
1 Metric of the default route to be advertised
2 Number of the interface that is suppressed from sending RIP Update packets
3.5.2 Configuring RIP to Advertise Default Routes

A default route is a route destined for 0.0.0.0. By default, RIP does not advertise default routes
to its neighbors.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
rip [ process-id ]

Step 3 Run:
default-route originate [ cost cost | tag tag | { match default | route-policy
route-policy-name [ advertise-tag ] } [ avoid-learning ] ] *
RIP is configured to generate a default route only if route permitted by the route policy is present
as active in the routing table.
----End
3.5.3 Disabling an Interface from Sending RIP Update Packets

Disabling interfaces from sending RIP Update packets is a method of preventing routing loops
and can be implemented in two ways.

Context
Procedure
l Disable an interface from sending RIP Update packets in a RIP process (with a high
priority).
1. Run:
system-view

2. Run:
rip [ process-id ]
The RIP process is enabled, and the RIP view is displayed.

3. Run:
silent-interface interface-type interface-number
A specified interface is disabled from sending RIP Update packets.
You can configure an interface as a silent interface so that it only receives RIP Update
packets to update its routing table.
NOTE
You can run the silent-interface all command to disable all RIP interfaces from sending RIP
Update packets.
The silent-interface command takes precedence over the rip output command configured in
the interface view. By default, an interface can both send and receive RIP Update packets.
l Disable an interface from sending RIP Update packets in the interface view (with a low
priority).
1. Run:
system-view

2. Run:

3. Run:
undo rip output
The interface is disabled from sending RIP Update packets.
By running this command, you can specify whether to send RIP Update packets on
an interface. The silent-interface command takes precedence over the undo rip
output command. By default, an interface is allowed to send RIP Update packets.
----End

3.5.4 Configuring RIP to Filter the Routes to be Sent

After configuring RIP to filter the routes to be sent, the device advertises only routes matching
the filtering policy to its neighbors.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]

1. Run filter-policy { acl-number | acl-name acl-name } export [ protocol [ process-
id ]| interface-type interface-number ], the imported routes are filtered when being
advertised.
When a filtering policy of a routing protocol is used to filter routes:
– If the action specified in an ACL rule is permit, a route that matches the rule will
be received or advertised by the system.
– If the action specified in an ACL rule is deny, a route that matches the rule will not
– If a route has not matched any ACL rules, the route will not be received or advertised
by the system.
– If an ACL does not contain any rules, all routes matching the route-policy that
references the ACL will not be received or advertised by the system.
– If the ACL referenced by the route-policy does not exist, all routes matching the
route-policy will be received or advertised by the system.
– In the configuration order, the system first matches a route with a rule that has a
smaller number and then matches the route with a rule with a larger number. Routes
can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller number and specify
the action deny in this rule to filter out the unwanted routes. Then, configure another
rule with a larger number in the same ACL and specify the action permit in this rule
to receive or advertise the other routes.
Route filtering using a whitelist: Configure a rule with a smaller number and specify
the action permit in this rule to permit the routes to be received or advertised by the

system. Then, configure another rule with a larger number in the same ACL and
specify the action deny in this rule to filter out unwanted routes.
1. Run filter-policy acl-name acl-name export [ protocol [ process-id ]| interface-type
interface-number ], the imported routes are filtered when being advertised.
by the system.
l Based on the IP prefix: filter-policy ip-prefix ip-prefix-name export [ protocol [ process-
id ]| interface-type interface-number ]
If the routing information to be advertised by RIP contains the routes imported from other routing
protocols, you can specify protocol to filter the specified routes. If protocol is not specified, all
the routing information to be advertised will be filtered, including the imported routes and local
RIP routes (directly connected routes).
NOTE
The Tag field in RIP is 16 bits in length, whereas the Tag field in other routing protocols is 32 bits in length.
If the routes of other routing protocols are imported and the tag is used in the routing policy, ensure that
the tag value does not exceed 65535. Otherwise, the routing policy becomes invalid or the matching result
is incorrect.
----End


After the function of controlling the advertising of RIP routing information is successfully
configured, you can view the current running status, configuration, and routing information
about RIP.
Prerequisites
Controlling the advertising of RIP routing information has been configured.
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 command to check all activated routes in the RIP
database.
l Run the display rip process-id route command to check all the RIP routes that are learned
from other routers..
----End
Example
database of the specified RIP process.
---------------------------------------------------
---------------------------------------------------
10.1.1.0/24, cost 0, [A], Imported
10.137.220.0/23, cost 1, [A], nexthop 10.10.10.2
3.6 Controlling the Receiving of RIP Routing Information

To meet the requirements of complex networks, accurately controlling the receiving of RIP

You can obtain RIP routing information by receiving Update packets and host routes.
In practice, to meet the requirements of a complex network, it is required to control the receiving
of RIP routing information accurately. After performing configuration procedures in this section,
you can:
l Disable an interface from receiving RIP Update packets.

l Filter the received routing information.

l Import external routes from various routing protocols and filter the imported routes.
Before configuring a router to control the receiving of RIP routing information, complete the
following tasks:
the network layer
Data Preparation
To control the receiving of RIP routing information, you need the following data.
No. Data
1 ACL used to filter the routing information
3.6.2 Disabling an Interface from Receiving RIP Update Packets

Disabling interfaces from receiving Update packets is a method of preventing routing loops.
Context
By default, an interface is allowed to receive RIP Update packets.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
undo rip input
The interface is disabled from receiving RIP Update packets.
----End
3.6.3 Disabling RIP from Receiving Host Routes

When you disable RIP from receiving host routes on a router, the router rejects to receive host
routes. This prevents the router from receiving a large number of unnecessary routes and
therefore avoiding wasting network resources.

Context
In certain situations, a router may receive a large number of host routes from the same network
segment. These routes are not required in route addressing, but consume many network
resources. You can configure the router to refuse to accept host routes by disabling RIP from
accepting host routes.
By default, host routes are added to the routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
undo host-route
RIP is disabled from adding host routes to the routing table.
NOTE
undo host-route command will not be effective in RIP version 2. By default, RIP version 2 always supports
host-route.
----End
3.6.4 Configuring RIP to Filter the Received Routes

By specifying ACLs and IP prefix lists, you can configure the inbound policy to filter the routes
to be received. You can also configure a router to receive only RIP packets from a specified
neighbor.
Context
The router can filter routing information. To filter the imported and advertised routes, you can
configure inbound and outbound routing policies by specifying ACLs and IP prefix lists.
You can also configure the router to receive RIP packets only from a specified neighbor.
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:
1. Run filter-policy { acl-number | acl-name acl-name } import, the learned routing
information is filtered based on an ACL.
by the system.
1. Run filter-policy acl-name acl-name import, the learned routing information is filtered
based on an ACL.


by the system.
l Based on the IP prefix:
– Run filter-policy gateway ip-prefix-name import, the routing information advertised by
neighbors is filtered based on the IP prefix list.
– 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

After the receiving of RIP routing information is successfully controlled, you can view the
current running status, configuration, and routing information about RIP.
Procedure
l Run the display rip process-id database [ verbose ] command to check all activated RIP
routes in the database.
l Run the display rip process-id interface [ interface-type interface-number ] [ verbose ]
command to check information about the RIP interface.

l Run the display rip process-id neighbor [ verbose ] command to check information about
RIP neighbors.
from other routers.
----End
Example
database of the specified RIP process. For example:
---------------------------------------------------
---------------------------------------------------
10.1.1.0/24, cost 0, [A], Imported
10.137.220.0/23, cost 1, [A], nexthop 10.10.10.2
3.7 Configuring RIP-2 Features

Different from RIP-1, RIP-2 supports VLSM, CIDR, and authentication to ensure higher
security.

Before configuring RIP-2 features, familiarize yourself with the usage scenario, complete the
pre-configuration tasks, and obtain the data required for the configuration.
RIP-2 is a type of classless routing protocol. A RIP-2 packet carries subnet mask information.
Deploying a RIP-2 network saves IP addresses. For a network on which the IP addresses of
devices are not consecutive, only RIP-2 can be deployed, whereas RIP-1 cannot be deployed.
RIP-2 features include:
l RIP-2 route summarization

l RIP-2 authentication mode
Before configuring RIP-2 features, complete the following tasks:
l Configuring the link layer protocol

the network layer
Data Preparation
To configure RIP-2 features, you need the following data.

No. Data
1 RIP-2 process ID
2 Network segment where the RIP-2 interface resides
3.7.2 Configuring RIP-2 Route Summarization

RIP-2 route summarization can reduce the size of a routing table and improve network efficiency.
By default, RIP-2 route summarization is enabled. To broadcast all subnet routes, you can disable
RIP-2 route summarization.
Context
Route summarization indicates that multiple subnet routes on the same natural network segment
are summarized into one route with the natural mask when being advertised to other network
segments. Therefore, route summarization reduces the network traffic and the size of the routing
table.
Route summarization is enabled for RIP-2 by default, but is invalid for RIP-1. To broadcast all
subnet routes, you can disable RIP-2 automatic route summarization.
NOTE
Route summarization is invalid when poison reverse is configured. When the summarized routes are sent
outside the natural network boundary, poison reverse in related views needs to be disabled.
Procedure
l Enable RIP-2 automatic route summarization
1. Run:
system-view

2. Run:
rip [ process-id ]

3. Run:
version 2
RIP-2 is configured.
4. Run:
summary [ always ]
Route summarization is enabled.
– Enable the RIP-2 automatic route summarization when split horizon is disabled,
there is no need to configure always.

– Enable the RIP-2 automatic route summarization irrespective of split horizon

configuration, always must be configured.
NOTE
The summary command is used in the RIP view to enable classful network-based route
summarization.
l Configure RIP-2 to advertise the summary address
1. Run:
system-view

2. Run:

3. Run:
rip summary-address ip-address mask [ avoid-feedback ]
The local summary address of RIP-2 is advertised.
NOTE
The rip summary-address ip-address mask [ avoid-feedback ] command is run in the

interface view to enable classless network-based route summarization.
----End
3.7.3 Configuring Packet Authentication of RIP-2

RIP-2 supports the ability to authenticate protocol packets. By default, authentication is not
configured for RIP. Configuring authentication is recommended to ensure system security.
Context
RIP-2 supports the following authentication modes:
l Simple authentication
l MD5 authentication
l HMAC-SHA256 authentication
l Keychain authentication
In simple authentication mode, the unencrypted authentication key is sent in every RIP-2 packet.
Therefore, simple authentication does not guarantee security, and cannot meet the requirements
for high security.
NOTICE
When configuring an authentication password, select the ciphertext mode becasue the password
is saved in configuration files in plaintext if you select plaintext mode, which has a high risk.
To ensure device security, change the password periodically.
Perform the following steps on the RIP router.

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

l Run:
rip authentication-mode simple { plain plain-text | [ cipher ] password-key }
Simple authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode md5 usual { plain plain-text | [ cipher ] password-key }
MD5 usual authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode md5 nonstandard { keychain keychain-name | { { plain
plain-text | [ cipher ] password-key } key-id } }
MD5 nonstandard authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode hmac-sha256 { plain plain-text | [ cipher ] password-
key } key-id
hmac-sha256 authentication is configured for RIP-2 packets.

l Run:
rip authentication-mode keychain keychain-name
Keychain authentication is configured for RIP-2 packets.

NOTE
The MD5 type must be specified if MD5 authentication is configured. The usual type supports private
standard authentication packets, and the nonstandard type supports IETF standard authentication packets.
----End
Result
The following section describes the changes in RIP neighbor relationships and data traffic
volume during the upgrade from RIP-1 to RIP-2 with authentication.
Scenario 1: Consider the security upgrade is required in the topology mentioned in Figure
3-1 which contains one P2P link. Security upgrade between Router A and Router B are
configured with default version.
Figure 3-1 RIP on P2P link
interface1
interface2
Router A Router B

With default configuration the behavior of send and receive packets on the P2P link is similar.
interface1 on Router A: (Default version or version 1 compatible)
Send: Version 1
Receive: Version 1
Version 2 broadcast and multicast
interface2 on Router B: (Default version or version 1 compatible)

Send: Version 1
Receive: Version 1 and Version 2 broadcast and multicast
l Step1: Configure authentication on interface1 of Router A

Send: Version 1
Receive: Version 1
Version 2 broadcast and multicast with authentication

Send: Version 1
Receive: Version 1
The packet exchange between Router A and Router B is still version 1, so as above
configuration there will be no impact on packet flow.
l Step2: Configure same authentication on interface2 of Router B
Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1
The packet exchange between Router A and Router B is still version 1, so as above
configuration there will be no impact on packet flow.
l Step3: Configure version 2 broadcast on interface1 of Router A
interface1 on Router A: (Version 2 broadcast)
Send: Version 2 broadcast with authentication
Receive: Version 1

Send: Version 1
Receive: Version 1
The packet exchange from Router A to Router B is version 2 broadcast with authentication.
Authentication was already configured on Router B also, so Router B will accept the packets
from Router A. The exchange from Router B to Router A is still version 1 (no
authentication). Router A is allowed to receive version 1 packets even in version 2 broadcast
mode.
l Step4: Configure version 2 broadcast on interface2 of Router B
interface1 on Router A: (Version 2 broadcast)
Receive: Version 1
interface2 on Router B: (Version 2 broadcast)

Receive: Version 1

The packet exchange between Router A to Router B is version 2 broadcast with

authentication. Authentication was already configured on both Router A and Router B and
both are allowed to receive version 2 broadcasts, so there will be no impact on packet flow.
l Step5: Configure version 2 on interface1 of Router A
interface1 on Router A: (Version 2)
Send: Version 2 multicast with authentication
Receive: Version 2 broadcast and multicast with authentication
interface2 on Router B:
Receive: Version 1
The packet exchange from Router A to Router B is version 2 multicast with authentication.
Authentication was already configured on Router B also, so Router B will accept the packets
from Router A. The exchange from Router B to Router A is version 2 broadcast with
authentication. Router A is allowed to receive version 2 broadcast packets even in version
2 mode.
l Step6: Configure version 2 on interface2 of Router B
interface2 on Router B: (Version 2)

The packet exchange between Router A to Router B is version 2 multicast with

authentication. Authentication was already configured on both Router A and Router B and
both are allowed to receive version 2 multicast, so there will be no impact on packet flow.
NOTE
On network, multicast protocol packets are advisable, since broadcast packets will be reached to
normal hosts also in that network.
Scenario2: Consider the security upgrade is required in the topology mentioned in Figure 3-2
which contains broadcast link with version 1 and version 1 compatible devices.
Figure 3-2 RIP on broadcast link
interface1 interface2
Router A Router B
interface3
Router C

Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1

interface3 on Router C: (Version 1)

Send: Version 1
Receive: Version 1
NOTE
Assumed that there is no version is configured at process and all version configurations at interface level.
l Step1: Configure authentication on Router A

Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1
If we configure authentication on version 1 interface, there will be no impact for sending

version 1 packets.
l Step2: Configure authentication on Router C
Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1
If we configure authentication on version 1 interface, there will be no impact for sending

version 1 and receiving packets.
l Step3: Configure authentication on Router B
Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1
If we configure authentication on default version supported interface, there will be no

impact for sending version 1 and receiving packets. If version 2 packets are received, they
must be authenticated.
l Step4: Undo rip version at Router A
Send: Version 1
Receive: Version 1

Send: Version 1

Receive: Version 1

Send: Version 1
Receive: Version 1
At Router B, if undo rip version 1, then the version on that interface is default version or
version 1 compatible. The packets exchanged between devices are still version 1 packets,
then there may not have any issue.
l Step5: Undo rip version at Router C
Send: Version 1
Receive: Version 1

Send: Version 1
Receive: Version 1
interface3 on Router C: (Default version or version 1 compatible)

Send: Version 1
Receive: Version 1
At Router C, if undo rip version 1, then the version on that interface is default version, or
version 1 compatible. The packets exchanged between devices are still version 1 packets,
and then there may not have any issue.
l Step6: Configure rip version 2 broadcast at Router A
Send: Version 1
Receive: Version 1
interface1 on Router A: (version 2 brooadcast)

Receive: Version 1
interface3 on Router C: (Default version or version 1 compatible)

Send: Version 1
Receive: Version 1
At Router A, if we configure rip version 2 broadcast, then the send version on that interface
is version 2 broadcast with authentication. Authentication on other devices was already
configured, so they will be able to receive version 2 broadcast updates from Router A. Other
devices will send version 1 updates (no authentication). Router A can receive these updates.
l Step7: Configure rip version 2 broadcast at Router C
Send: Version 1
Receive: Version 1

Receive: Version 1
interface3 on Router C: (version 2 brooadcast)

Receive: Version 1

At Router C, if we configure rip version 2 broadcast, then the send version on that interface
configured, so they will be able to receive version 2 broadcast updates from Router C.
Router B will send version 1 updates (no authentication). Router A and Router C can receive
these updates.
l Step8: Configure rip version 2 broadcast at Router B
interface2 on Router B: (version 2 brooadcast)
Receive: Version 1

Receive: Version 1

Receive: Version 1
At Router B, if we configure rip version 2 broadcast, then the send version on that interface
configured, so they will be able to receive version 2 broadcast update from Router B. Other
devices also will send version 2 broadcast with authentication, so each device can receive
packets from other devices.
l Step9: Configure rip version 2 at Router A
Receive: Version 1
interface1 on Router A: (version 2)


Receive: Version 1
At Router A, if we configure rip version 2, then the send version on that interface is version
2 multicast with authentication. Authentication on other devices are already configured, so
they will be able to receive version 2 multicast updates from Router A. Other devices also
will send version 2 broadcast packets with authentication, so each device can receive
packets from other devices.
l Step10: Configure rip version 2 at Router C
Receive: Version 1

interface3 on Router C: (version 2)

At Router C, if we configure rip version 2, then the send version on that interface is version
2 multicast with authentication. Authentication on other devices was already configured,

so they will be able to receive version 2 multicast updates from Router C. Router B will
send version 2 broadcast with authentication and Router A will send version 2 multicast
with authentication. So each device can receive packets from other devices.
l Step11: Configure rip version 2 at Router B
interface2 on Router B: (version 2)

interface3 on Router C: (version 2)

At Router B, if we configure rip version 2, then the send version on that interface is version
2 multicast with authentication. Authentication on other devices was already configured,
so they will be able to receive version 2 multicast updates from Router B. Other devices
also will send version 2 multicast with authentication. So each device can receive packets
from other devices.
Scenario 3: Version 2 or Version 2 broadcast is enabled on all devices.
In this scenario, if we configure authentication on every device, this may cause protocol packets
drop if periodic update got triggered during authentication configuration in following cases.
1. RIP authenticated packet is received on non-authenticated interface.

2. RIP non-authenticated packet is received on authenticated interface.
In next periodic update, all RIP packets can be authenticated and received by all devices on
authenticated interfaces. There will be no traffic loss, since RIP will wait for 6 periodic updates
to consider the route as invalid. (With default timers are configured)

After RIP-2 features are successfully configured, you can view the current running status,
configuration, and routing information of RIP.
Prerequisites
RIP-2 features have been configured.
Procedure
from other routers.
----End

3.8 Optimizing a RIP Network

You can adjust and optimize the RIP network performance by configuring RIP functions in
special network environments, such as configuring RIP timers, setting the interval for sending
packets, and setting the maximum number of packets to be sent.

Before adjusting and optimizing the RIP network performance, familiarize yourself with the
usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
On certain networks, you need to configure RIP features and optimize the performance of a RIP
network. After performing configuration procedures in this section, you can:
l Change the convergence speed of the RIP network by adjusting the values of RIP timers.
l Reduce the consumption of device resources and network bandwidth by adjusting the
number of packets to be sent by interfaces and the interval at which packets are sent.
l Configure split horizon or poison reverse to prevent routing loops.
l After the replay-protect function is enabled, neighbors can communicate after a RIP process
is restarted.
l Check the validity of packets and authenticate packets on a network demanding high
security.
l Run RIP on a link that does not support broadcast or multicast packets.
Before optimizing a RIP network, complete the following tasks:
the network layer
Data Preparation
To optimize a RIP network, you need the following data.
No. Data
1 Values of timers
2 Number of Update packets that an interface sends each time and interval for sending
an Update packet
4 Packet authentication mode and password

No. Data
5 IP addresses of RIP neighbors
3.8.2 Configuring RIP Timers

RIP has three timers: Update timer, Age timer and Garbage-collect timer. Changing the values
of the three timers affects the RIP convergence speed.
Context
RIP has three timers: Update timer, Age timer and Garbage-collect timer. Changing the values
of the three timers affects the RIP convergence speed. For details on timers, see corresponding
description in the chapter "RIP" in the HUAWEI NetEngine80E/40E Router Feature Description
- IP Routing.
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 times are set improperly. The relationship between the values
is as follows: update must be smaller than age and update must be smaller than garbage-collect. For
example, if the update time is longer than the aging time, and a RIP route changes within the update
time, the router cannot inform its neighbors of the change on time.
l You must configure RIP timers based on the network performance and uniformly on all the routers
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
3.8.3 Setting the Interval for Sending Packets and the Maximum
Number of the Sent Packets
By setting the interval for sending RIP Update packets and the maximum number of Update
packets to be sent each time, you can effectively control the memory used by a Router to process
RIP Update packets.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
rip pkt-transmit { interval interval | number pkt-count } *
The interval for sending Update packets and the maximum number of packets sent each time
are set on the interface.
----End
3.8.4 Configuring Split Horizon and Poison Reverse

You can configure split horizon and poison reverse to prevent routing loops.
Context
If both split horizon and poison reverse are configured, only poison reverse takes effect.
On Non-Broadcast Multi-Access (NBMA) networks such as frame relay (FR) and X.25
networks, if no sub-interface is configured, split horizon needs to be disabled to ensure that
routing information is transmitted correctly.
Procedure
Step 1 Run:
system-view

Step 2 Run:

l Run:
rip split-horizon
Split horizon is enabled.

l Run:
rip poison-reverse
Poison reverse is enabled.
----End
3.8.5 Enabling replay-protect Function

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.
Context
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:
Step 3 Run:
l rip authentication-mode md5 nonstandard

RIPv2 is configured to use MD5 authentication, and authentication packets use the
nonstandard packet format.
l rip authentication-mode hmac-sha256 { plain plain-text | [ cipher ] password-
key } key-id
RIPv2 is configured to use HMAC-SHA256 authentication.

l Run:
rip authentication-mode keychain keychain-name
Keychain authentication is configured for RIP-2 packets.

NOTE
Before running the rip replay-protect command, run the rip authentication-mode md5 nonstandard
command or the rip authentication-mode hmac-sha256 { plain plain-text | [ cipher ] password-key }
key-id in the RIP interface view to configure cryptographic authentication packets .
Step 4 Run:
rip replay-protect
The replay-protect function is enabled.
NOTE
l For details of the Identification field in an IP packet, see Feature Description - IP Services.
l If you run the rip replay-protect command in the same view multiple times, only the last configuration
takes effect.
----End
3.8.6 Configuring RIP to Check the Validity of Update Packets

The check on RIP Update packets includes the check on zero fields in RIPv1 packets and the
check on source addresses of RIP Update packets. The two types of check have different
functions and applications.
Context
Procedure
l Configuring the Zero Field Check for RIPv1 Packets
1. Run:
system-view

2. Run:
rip [ process-id ]

3. Run:
checkzero
The zero field check is configured for RIPv1 packets.

Certain fields in a RIPv1 packet must be 0s, and these fields are called zero fields.
RIPv1 checks the zero fields on receiving a packet. If the value of any zero field in a
RIPv1 packet is not 0, this packet is not processed.
As a RIPv2 packet does not contain any zero field, configuring the zero field check
is invalid in RIPv2.
l Configuring the Source Address Check for RIP Update Packets
1. Run:
system-view

2. Run:
rip [ process-id ]

3. Run:
verify-source
The source address check is configured for RIP Update packets.
When receiving a packet, RIP checks the source address of the packet. If the packet
fails in the check, it is not processed.
By default, the source address check is enabled.
----End
3.8.7 Configuring RIP Neighbors

Generally, RIP sends packets by using broadcast or multicast addresses. To run RIP on the links
that do not support the forwarding of broadcast or multicast packets, you need to specify RIP
neighbors.
Context
Generally, RIP sends packets by using broadcast or multicast addresses. If RIP needs to run on
the links that do not support the forwarding of broadcast or multicast packets, you need to
configure the devices at both ends of the link as each other's neighbor.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
Step 3 Run:
peer ip-address

The RIP neighbor is configured.
----End
3.8.8 Configuring the RIP GTSM Functions

The GTSM defends against attacks by checking the TTL value.
Context
In a network demanding higher security, you can enable GTSM to improve the security of the
RIP network. GTSM defends against attacks by checking the TTL value. If an attacker simulates
RIP unicast packets and keeps sending them to a router, an interface board on the router receives
the packets and directly sends them to the main control board for RIP processing, without
checking the validity of the packets. In this case, the router is busy processing these packets,
causing high usage of the CPU. GTSM protects the routers and enhances the system security by
checking whether the TTL value in the IP packet header is in a pre-defined range.
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip valid-ttl-hops valid-ttl-hops-value [ vpn-instance vpn-instance-name ]
RIP GTSM functions are configured.
NOTE
The valid TTL range of the detected packets is [ 255 -valid-ttl-hops-value + 1, 255 ].
----End

After the function of adjusting and optimizing the RIP network performance is successfully
configured, you can view the current running status, routing information, neighbor information,
and interface information of RIP.
Prerequisites
The RIP network optimization has been configured.
Procedure
l Run the display rip process-id interface [ interface-type interface-number ] [ verbose ]
command to check information about the RIP interface.

l Run the display rip process-id neighbor [ verbose ] command to check information about
RIP neighbors.
from other routers.
----End
Example
Run the display rip process-id interface [ interface-type interface-number ] [ verbose ]
command, and you can view RIP information about the specified interface. The command output
shows that the interface status is Up.
<HUAWEI> display rip 1 interface GigabitEthernet1/0/0
------------------------------------------------------------------
Interface IP Address State Protocol MTU
------------------------------------------------------------------
GE 1/0/0 1.1.1.2 UP RIPv1 Compatible 500
3.9 Configuring RIP GR

This section describes how to configure RIP GR to avoid incorrect route calculation and packet
loss after a RIP router restarts.

In practice, you can configure RIP GR on the device with two main control boards to prevent
service forwarding from being affected by the fault on one main control board.
To avoid traffic interruption and route flapping caused by master/slave switchover, you can
enable RIP graceful restart (GR). GR is a technology used to ensure normal traffic forwarding
and non-stop forwarding of key services during the restart of routing protocols.
After a RIP process is restarted through GR, the Restarter and the Helper re-establish the
neighbor relationship and update the routing table and forwarding table. This ensures non-stop
traffic forwarding and stabilizes the network topology. During RIP GR, except the neighbor of
the device where master/slave switchover occurs, other routers do not detect the route change.
NOTE
In practice, you can configure RIP GR on the device with two main control boards to prevent service
forwarding from being affected by the fault on one main control board.
Before configuring RIP GR, complete the following tasks:
the network layer
l Configuring basic RIP functions, establish the neighbor relationship successfully

Data Preparation
To configure RIP GR, you need the following data
No. Data
1 RIP process ID
2 Parameters for establishing a GR session
3.9.2 Enabling RIP GR

To avoid traffic interruption and route flapping caused by master/slave switchover, you can
enable RIP GR.
Context
Perform the following steps on the router to be enabled with GR:
Procedure
Step 1 Run:
system-view

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

Step 3 Run:
graceful-restart [ period period | wait-time time | planned-only time ] *
RIP GR is enabled.
When most routers on a network do not support RIP GR, setting wait-time time to a larger value
is recommended. This ensures that the Restarter has enough time to learn correct routes.
----End
Follow-up Procedure
If the Restarter finishes GR within the GR period specified by period period, the Restarter
automatically exits from GR. Otherwise, the Restarter is forced to exit from GR.

After RIP GR is configured, you can check the RIP GR status.
Prerequisites
RIP GR has been configured.

Procedure
l Run the display rip process-id graceful-restart [ verbose ] command to check the status
of RIP GR.
----End
Example
Run the display rip 1 graceful-restart command, and you can view the GR configuration of
RIP process 1.
<HUAWEI> display rip 1 graceful-restart
Restart mode : Restarting
Restart status : In Progress - Waiting for updates
Last complete reason : None
Update progress summary:
------------------------
Restart capable peers : 0
Completed: 0 Inprogress: 0
Restart incapable peers: 1
Completed: 0 Inprogress: 1
Update period finishes in 293 seconds
3.10 Configuring BFD for RIP

On a network that runs high-rate data services, BFD for RIP can be configured to quickly detect
and respond to network faults.
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.
In BFD for RIP, BFD session establishment is triggered by RIP. When establishing a neighbor
relationship, RIP will send detection parameters of the neighbor to BFD. Then, a BFD session
will be established based on these detection parameters. If a link fault occurs, the local RIP
process will receive a neighbor unreachable message within seconds. Then, the local RIP device
will delete routing entries in which the neighbor relationship is Down and use the backup path
to transmit messages.
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.

Before configuring BFD for RIP, complete the following tasks:
l Assigning an IP address to each interface to ensure reachability between neighboring nodes
at the network layer
Data Preparation
To complete the configuration, you need the following data.
No. Data
1 ID of a RIP process to be enabled with BFD
2 Type and number of an interface to be enabled with BFD
3 (Optional) BFD session parameter values

NOTE
Default BFD session parameter values are recommended.
Procedure
l Enable BFD in a RIP process.
1. Run:
system-view

2. Run:
bfd
BFD is enabled globally.

3. Run:
quit

4. Run:
rip process-id
The RIP view is displayed.

5. Run:
bfd all-interfaces enable
BFD is enabled in the RIP process to establish a BFD session.

If BFD is enabled globally, RIP will use default BFD parameters to establish BFD
sessions on all the interfaces where RIP neighbor relationships are in the Up state.
6. (Optional) Run:
bfd all-interfaces { min-rx-interval min-receive-value | min-tx-interval
min-transmit-value | detect-multiplier detect-multiplier-value } *
The values of BFD parameters used to establish the BFD session are set.

BFD parameter values are determined by the actual network situation and network
reliability requirement.
– If links have a high reliability requirement, reduce the interval at which BFD
packets are sent.
– If links have a low reliability requirement, increase the interval at which BFD
packets are sent.
Running the bfd all-interfaces command changes BFD session parameters on all RIP
interfaces. The default detection multiplier and interval at which BFD packets are sent
are recommended.
7. (Optional) Perform the following operations to prevent an interface in the RIP process
from establishing a BFD session:
– Run the quit command to return to the system view.
– Run the interface interface-type interface-number command to enter the view of
a specified interface.
– Run the rip bfd block command to prevent the interface from establishing a BFD
session.
l Enable BFD on RIP interfaces.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

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

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

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

After enabling BFD for RIP at both ends of a link, run the display rip bfd session { interface
interface-type interface-number | neighbor-id | all } command. You can see that the BFDState
field value on the local router is displayed Up. For example:

<HUAWEI> display rip 1 bfd session all

LocalIp :10.1.0.1 RemoteIp :10.1.0.2 BFDState :Up
TX :1000 RX :1000 Multiplier:3
BFD Local Dis:8192 Interface :GigabitEthernet0/0/0
DiagnosticInfo: No diagnostic information
3.11 Configuring Static BFD for RIP

BFD provides link failure detection featuring light load and high speed. Static BFD for RIP is
a mode to implement the BFD function.
Context
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 and session parameters are also set using
commands.
Before configuring static BFD for RIP, complete the following tasks:
l Assigning an IP address to each interface to ensure IP connectivity
l Configuring basic RIP functions
Data Preparation
No. Data
1 ID of a RIP process
2 Type and number of the interface to be enabled with BFD
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 bfd-name bind peer-ip peer-ip interface interface-type interface-number
one-arm-echo
BFD is enabled between the specified interface and peer router.
If a peer IP address and a local interface are specified, BFD detects only a single-hop link,
that is, a route with the interface specified in the bfd command as the outbound interface
and with the peer IP address specified in the peer-ip command as the next-hop address.
2. Run:
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 bfd-name bind peer-ip ip-address [ interface interface-type interface-
number ]
BFD binding is created.
If a peer IP address and a local interface are specified, BFD detects only a single-hop link,
that is, a route with the interface specified in the bfd command as the outbound interface
and with the peer IP address specified in the peer-ip command as the next-hop address.
2. Set discriminators.
l Run:

The local discriminator is set.

l Run:
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. Run:
rip bfd static
Static BFD is enabled on the interface.

3. Run:
quit
----End

After configuring static BFD for RIP, run the display rip process-id command to check BFD
for RIP configurations on the specified interface. interface [ interface-type interface-number ]
verbose
Run the display rip process-id interface interface-type interface-number verbosecommand.

The command output shows that static BFD has been enabled on GigabitEthernet1/0/0. For
example:
<HUAWEI> display rip 1 interface gigabitethernet1/0/0 verbose
GigabitEthernet1/0/0 (172.16.1.1)
State : UP MTU : 500
Metricin : 0
Metricout : 1
Input : Enabled Output : Enabled
Protocol : RIPv1 Compatible (Non-Standard)

Send : RIPv1 Packets

Receive : RIPv1 Packets, RIPv2 Multicast and Broadcast Packets
Poison-reverse : Disabled
Split-Horizon : Enabled
Authentication type : None
Replay Protection : Disabled
BFD : Enabled (Static)
Summary Address (es):
10.1.0.0/16
3.12 Configuring the Network Management Function in RIP

By binding RIP to MIBs, you can view and configure RIP through the NMS.

Before binding RIP to MIBs, familiarize yourself with the usage scenario, complete the pre-
configuration tasks, and obtain the data required for the configuration.
After performing configuration procedures in this section, you can bind RIP to a MIB.
Before configuring the network management function in RIP, complete the following tasks:
the network layer
Data Preparation
None.
3.12.2 Binding RIP to MIBs

Before binding RIP to MIBs, you need to specify the RIP process ID.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip mib-binding process-id
RIP is bound to MIBs.

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

After RIP and MIBs are successfully bound, you can view binding information in the current
RIP configuration.
Prerequisites
The network management function in RIP has been configured.
Procedure
Step 1 Run the display current-configuration command to check the parameters that take effect on
the router.
----End
3.13 Maintaining RIP

This section describes how to reset RIP connections and clear RIP information.
3.13.1 Resetting RIP

Restarting RIP can reset 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
parameters of the specified RIP process. When the RIP process starts, all parameters use
default values.
----End
3.13.2 Clearing RIP

This section describes how to clear statistics about RIP counters.

Context
NOTICE
RIP information cannot be restored after it is cleared. Exercise caution when running the
commands.
To clear RIP information, run the following reset command 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 statistics about the
counter that is maintained by a specified RIP process.
----End

In actual networking, RIP versions and whether to import external routes will affect which routes
can be learned.
NOTE
3.14.1 Example for Configuring RIP Version

Before using RIP, you need to configure basic RIP functions and specify a RIP version. You
can run commands to view the configuration results.
As shown in Figure 3-3, it is required that RIP be enabled on all interfaces of Router A, Router
B, Router C, and Router D and the routers interconnect with each other by using RIP-2.
Figure 3-3 Networking diagram for configuring the RIP version number
RouterC
POS2/0/0
172.16.1.2/24
POS2/0/0
POS1/0/0 172.16.1.1/24 POS3/0/0
192.168.1.1/24 10.1.1.2/24
POS1/0/0 POS3/0/0
RouterA 192.168.1.2/24 RouterB 10.1.1.1/24 RouterD

1. Configure an IP address for each interface to ensure that neighboring nodes are reachable
at the network layer.
2. Enable RIP on each router and configure basic RIP functions.
3. Configure RIP-2 on each router and check information about classless routes.
Data Preparation
l Network segment (192.168.1.0) to be enabled with RIP on Router A
l Network segments (192.168.1.0, 172.16.0.0, and 10.0.0.0) to be enabled with RIP on Router
B
l Network segment (172.16.0.0) to be enabled with RIP on Router C
l Network segment (10.0.0.0) to be enabled with RIP on Router D
l RIP-2 on Router A, Router B, Router C, and Router D
Procedure
Step 2 Configure basic RIP functions.
[RouterA] rip
[RouterA-rip-1] network 192.168.1.0
[RouterA-rip-1] quit
[RouterB] rip
[RouterB-rip-1] network 192.168.1.0
[RouterB-rip-1] quit
[RouterC] rip
[RouterC-rip-1] network 172.16.0.0
[RouterC-rip-1] quit
[RouterD] rip
[RouterD-rip-1] network 10.0.0.0
[RouterD-rip-1] quit
# Check the RIP routing table of Router A.

[RouterA] display rip 1 route

Route Flags: R - RIP, T - TRIP

-------------------------------------------------------------------------
Peer 192.168.1.2 on Pos1/0/0
172.16.0.0/16 192.168.1.2 1 0 RA 16
10.0.0.0/8 192.168.1.2 1 0 RA 16
The preceding display shows that the routes advertised by RIP-1 carry natural masks.
Step 3 Configure the RIP version number.
# Configure RIP-2 on Router A.

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

[RouterB] rip
[RouterB-rip-1] version 2
# Configure RIP-2 on Router C.

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

[RouterD] rip
[RouterD-rip-1] version 2
# Check the RIP routing table of Router A.

[RouterA] display rip 1 route
Route Flags: R - RIP
-------------------------------------------------------------------------
Peer 192.168.1.2 on Pos1/0/0
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
The preceding display shows that the routes advertised by RIPv2 carry subnet masks.
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
rip 1
version 2

network 192.168.1.0
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
undo shutdown
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 RouterC
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 172.16.1.2 255.255.255.0
#
rip 1
version 2
network 172.16.0.0
#
return

#
sysname RouterD
#
interface Pos3/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
rip 1
version 2
network 10.0.0.0
#
return
3.14.2 Example for Configuring RIP to Import External Routes

To obtain more RIP routing information, you can configure RIP to import external routes. You
can run commands to view the configuration results.

As shown in Figure 3-4, two RIP processes, RIP 100 and RIP 200, run on Router B. Router B
exchanges routing information with Router A and Router C through RIP 100 and RIP 200
respectively.
It is required that the two RIP processes of Router B import RIP routes from each other. The
cost of the routes imported from RIP 200 defaults to 3.
In addition, a filtering policy needs to be configured on Router B to filter out the route
192.168.4.0/24 imported from RIP 200 and prevent it from being advertised to Router A.
Figure 3-4 Networking diagram for configuring RIP to import external routes
GE2/0/0
192.168.0.1/24
POS1/0/0 POS1/0/0 GE2/0/0
192.168.1.1/24 192.168.2.2/24 192.168.3.1/24
POS1/0/0 POS2/0/0 GE3/0/0
RouterA 192.168.1.2/24 192.168.2.1/24 RouterC 192.168.4.1/24
RIP 100 RouterB RIP 200
1. Enable RIP 100 and RIP 200 on each router and specify network segments.
2. Configure the two RIP processes on Router B to import routes from each other and set the
default cost of the routes imported from RIP 200 to 3.
3. Configure an ACL on Router B to filter the routes imported from RIP 200.
Data Preparation
l RIP 100 and network segments (192.168.1.0 and 192.168.0.0) on Router A

l RIP 100, RIP 200, and network segments (192.168.1.0 and 192.168.2.0) on Router B
l RIP 200 and network segments (192.168.2.0, 192.168.3.0, and 192.168.4.0) on Router C
l Default cost of the routes imported by Router B from RIP 200, which is 3
l ACL 2000 that is used to deny the route with the source network segment being 192.168.4.0
Procedure


# Enable RIP process 100 on Router A.
[RouterA] rip 100
# Enable two RIP processes, RIP 100 and RIP 200, on Router B.
[RouterB] rip 100
[RouterB] rip 200
# Enable RIP process 200 on Router C.

[RouterC] rip 200
# Check the routing table of Router A.

------------------------------------------------------------------------------
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Pos1/0/0
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
Step 3 Configure RIP to import external routes.

# Set the default route cost of RIP 200 routes imported by RIP 100 to 3 on Router B and configure
the two RIP processes to import routes from each other.
[RouterB] rip 100
[RouterB-rip-100] default-cost 3
[RouterB-rip-100] import-route rip 200
[RouterB] rip 200
[RouterB-rip-200] import-route rip 100
# Check the routing table of Router A after the routes are imported. The routes to network
segments 192.168.2.0/24, 192.168.3.0/24, and 192.168.4.0/24 are imported to RIP.
------------------------------------------------------------------------------


192.168.1.0/24 Direct 0 0 D 192.168.1.1 Pos1/0/0
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
192.168.2.0/24 RIP 100 4 D 192.168.1.2 Pos1/0/0
192.168.3.0/24 RIP 100 4 D 192.168.1.2 Pos1/0/0
192.168.4.0/24 RIP 100 4 D 192.168.1.2 Pos1/0/0
Step 4 Configure RIP to filter the imported routes.
# Configure an ACL on Router B and set a rule to deny the packets with the source address being
192.168.4.0/24.
[RouterB] acl 2000
[RouterB-acl-basic-2000] rule deny source 192.168.4.0 0.0.0.255
[RouterB-acl-basic-2000] rule permit
[RouterB-acl-basic-2000] quit
# Filter out the route 192.168.4.0/24 imported from RIP 200 on Router B according to the ACL
rule.
[RouterB] rip 100
[RouterB-rip-100] filter-policy 2000 export
# Check the routing table of Router A after the filtering. The route to 192.168.4.0/24 does not
exist in the routing table. This means that the route is filtered out.
------------------------------------------------------------------------------
192.168.1.0/24 Direct 0 0 D 192.168.1.1 Pos1/0/0
192.168.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
192.168.2.0/24 RIP 100 4 D 192.168.1.2 Pos1/0/0
192.168.3.0/24 RIP 100 4 D 192.168.1.2 Pos1/0/0
----End
Configuration Files
#
sysname RouterA
#
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown

ip address 192.168.1.1 255.255.255.0

#
rip 100
network 192.168.0.0
network 192.168.1.0
#
return

#
sysname RouterB
#
acl number 2000
rule 5 deny source 192.168.4.0 0.0.0.255
rule 10 permit
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
rip 100
default-cost 3
network 192.168.1.0
filter-policy 2000 export
import-route rip 200
#
rip 200
network 192.168.2.0
import-route rip 100
#
return

#
sysname RouterC
#
undo shutdown
ip address 192.168.3.1 255.255.255.0
#
undo shutdown
ip address 192.168.4.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
rip 200
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
#
return
3.14.3 Example for Configuring One-Arm Static BFD for RIP

RIP detects neighbor status by sending Update packets periodically. By default, if receiving no
Update packets from its neighbor within six update intervals (180s), RIP considers its neighbor
Down. That is, RIP needs to take 180s to detect a link fault.
With the development of technologies, voice, video, and other VOD services are widely used.
These services are quite sensitive to packet loss and delay. Long-time fault detection will cause
packet loss. This cannot meet high reliability requirements of the carrier-class network. BFD
for RIP is used to resolve the problem. After BFD for RIP is configured, the link status can be
rapidly detected and fault detection can be completed in milliseconds. This speeds up RIP
convergence when the link status changes.
Because some devices on the network do not support BFD, One-Arm static BFD becomes very
important. One-Arm static BFD enables a device supporting BFD to create a BFD session with
another device that does not support BFD. It detects link faults quickly and accelerates network
convergence.
Use Figure 3-5 as an example.
l RIP is running between Router A, Router B, Router C, and Router D.

l Service traffic travels through the primary link Router A → Router B → Router D.
l One-Arm static BFD is enabled on the interface connecting Router A and Router B. When
the primary link fails, BFD can detect the fault quickly and notify the RIP module of the
fault. Service traffic is then switched to a secondary link.
Figure 3-5 Networking for One-Arm static BFD for RIP
RouterA GE1/0/0 RouterB GE3/0/0 RouterD

2.2.2.1/24 172.16.1.1/24
GE1/0/0 GE1/0/0
GE2/0/0 2.2.2.2/24 GE2/0/0 172.16.1.2/24
3.3.3.1/24 4.4.4.1/24
GE2/0/0 GE1/0/0
3.3.3.2/24 4.4.4.2/24
RouterC
1. Configure basic RIP functions on each router to set up RIP neighbor relationships.
2. Enable global BFD on Router A. Enable One-Arm static BFD on the interface connecting
Router A and Router B.
Data Preparation

l On Router A: RIP process ID (1), RIP version number (2), IP address of GE 1/0/0
(2.2.2.1/24), and IP address of GE 2/0/0 (3.3.3.1/24)
l On Router B: RIP process ID (1), RIP version number (2), IP address of GE 1/0/0
(2.2.2.2/24), IP address of GE 2/0/0 (4.4.4.1/24), IP address of GE3/0/0 3/0/0
(172.16.1.1/24)
l On Router C: RIP process ID (1), RIP version number (2), IP address of GE 1/0/0
(4.4.4.2/24), and IP address of GE 2/0/0 (3.3.3.2/24)
l On Router D: RIP process ID (1), RIP version number (2), and IP address of GE 1/0/0
(172.16.1.2/24)
l Local BFD discriminator on Router A (local1)
l Minimum interval at which Router A receives BFD control packets from Router B
Procedure
Configure IP addresses according to Figure 3-5 and Data Preparation. For details about the
configuration, see the configuration file.
Step 2 Configuring basic RIP functions.
[RouterA] rip 1
[RouterB] rip 1
[RouterC] rip 1
<RouterD> system-view
[RouterD] rip 1
# After the configurations are complete, run the display rip neighbor command, and you can
see that RIP neighbor relationships among Router A, Router B, and Router C have been
established. Take the display on Router A as an example.

[RouterA] display rip 1 neighbor

---------------------------------------------------------------------
IP Address Interface Type Last-Heard-Time

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

2.2.2.1/32 Direct 0 0 D 127.0.0.1
3.3.3.0/24 Direct 0 0 D 3.3.3.1
3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 2.2.2.2
RIP 100 1 D 3.3.3.2
172.16.0.0/16 RIP 100 1 D 2.2.2.2
The routing table shows that the next-hop IP address of the route destined for 172.16.0.0/16 is
2.2.2.2, the outbound interface is GigabitEthernet 1/0/0, and traffic is transmitted along the
primary link Router A →Router B.
Step 3 Configure One-Arm static BFD on Router A.
# Configure one-arm BFD on Router A.

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

[RouterA] interface gigabitEthernet 1/0/0
[RouterA-GigabitEthernet1/0/0] rip bfd static
# After the configurations are completed, run the display bfd sessionall command on Router A
and you can see that a static BFD session is set up.
----------------------------------------------------------------------------------
---------


----------------------------------------------------------------------------------
---------
1 - 2.2.2.2 Up S_IP_IF GigabitEthernet1/0/0
----------------------------------------------------------------------------------
---------

# Run the shutdown command on GE 1/0/0 of Router B to simulate a fault on the primary link.
NOTE
Fault simulation is for configuration verification. In actual application, it is not required.

[RouterB] interface gigabitEthernet1/0/0

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

3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 3.3.3.2
172.16.0.0/16 RIP 100 2 D 3.3.3.2
The routing table shows that the secondary link Router A → Router C → Router B starts to be
used after the primary link fails. The next-hop IP address of the route destined for 172.16.0.0/16
is 3.3.3.2 and the outbound interface is GE 2/0/0.
----End
Configuration files
#
sysname RouterA
#
bfd
#
interface gigabitethernet1/0/0
undo shutdown
ip address 2.2.2.1 255.255.255.0
rip bfd static
#
undo shutdown
ip address 3.3.3.1 255.255.255.0
#
rip 1
version 2
network 2.0.0.0

network 3.0.0.0
#
bfd 1 bind peer-ip 2.2.2.2 interface gigabitethernet1/0/0 one-arm-echo
min-echo-rx-interval 200
commit
#
return

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

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

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

3.14.4 Example for Configuring BFD for RIP

This section provides an example showing how to configure BFD on a RIP network to rapidly
detect and notify link faults.
A RIP device periodically sends Update packets to a neighbor to detect neighbor reachability.
By default, if a RIP device does not receive an Update packet from a neighbor within six Update
periods (180s), the RIP device will consider that the neighbor goes Down. This means that RIP
can detect a link fault only after 180s.
As technologies develop, voice, video, and other video on demand (VoD) services are widely
applied. These services are quite sensitive to packet loss and delay. Long-time fault detection
will cause a large amount of data to be lost. As a result, the requirement of carrier-class networks
for high reliability cannot be met. BFD for RIP can be deployed to address this problem. After
BFD for RIP is configured, link fault detection can be completed in milliseconds. This speeds
up RIP convergence when the link status changes.
On the network shown in Figure 3-6, active/standby links are deployed. Link Router A-
>Router B functions as the active link and link Router A->Router C->Router B functions as the
standby link. Normally, service traffic is transmitted along the active link. It is required that
faults in the active link be quickly detected and services be rapidly switched to the standby link.
BFD for RIP can be configured. BFD is used to detect the RIP neighbor relationship between
Router A and Router B. When the link between Router A and Router B fails, BFD can rapidly
detect the failure and report it to RIP. This allows service traffic to be quickly switched to the
standby link.
Figure 3-6 Networking diagram for configuring BFD for RIP
RouterA GE1/0/0 RouterB GE3/0/0 RouterD

2.2.2.1/24 172.16.1.1/24
GE1/0/0 GE1/0/0
GE2/0/0 2.2.2.2/24 GE2/0/0 172.16.1.2/24
3.3.3.1/24 4.4.4.1/24
GE2/0/0 GE1/0/0
3.3.3.2/24 4.4.4.2/24
RouterC
1. Configure basic RIP functions on each router to ensure that RIP neighbor relationships are
properly established.
2. Enable BFD globally.
3. Configure BFD on interfaces at both ends of the link between Routers A and B.

Data Preparation
l Router A: RIP process ID (1), RIP version (2), IP address of GE 1/0/0 (2.2.2.1/24), and IP
address of GE 2/0/0 (3.3.3.1/24)
l Router B: RIP process ID (1), RIP version (2), IP address (2.2.2.2/24) of GE 1/0/0, IP
address (4.4.4.1/24) of GE 2/0/0, and IP address (172.16.1.1/24) of GE 3/0/0
l Router C: RIP process ID (1), RIP version (2), IP address (4.4.4.2/24) of GE 1/0/0, and IP
address (3.3.3.2/24) of GE 2/0/0
l Router D: RIP process ID (1), RIP version (2), and IP address (172.16.1.2/24) of GE 1/0/0
l Routers A and B: minimum interval (100 ms) at which BFD packets are sent or received
and local detection multiplier (10)
Procedure
As shown in Figure 3-6, configure an IP address for each interface based on Data
Preparation. For configuration details, see configuration files.
[RouterA] rip 1
[RouterB] rip 1
[RouterC] rip 1
[RouterD] rip 1
# After completing the preceding operations, run the display rip neighbor command. The
command output shows that Routers A, B, and C have established neighbor relationships with
each other. In the following example, the display on Router A is used.

[RouterA] display rip 1 neighbor

---------------------------------------------------------------------
IP Address Interface Type Last-Heard-Time

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

2.2.2.1/32 Direct 0 0 D 127.0.0.1
3.3.3.0/24 Direct 0 0 D 3.3.3.1
3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 2.2.2.2
RIP 100 1 D 3.3.3.2
172.16.0.0/16 RIP 100 1 D 2.2.2.2
The preceding command output shows that the next-hop address and outbound interface of the
route to destination 172.16.0.0/16 are 2.2.2.2 and GE 1/0/0 respectively, and traffic is transmitted
over the active link Router A->Router B.
Step 3 Configure BFD in RIP processes.
# Configure BFD on all interfaces of Router A.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] rip 1
[RouterA-rip-1] bfd all-interfaces enable
[RouterA-rip-1] bfd all-interfaces min-rx-interval 100 min-tx-interval 100 detect-
multiplier 10
The configuration of Router B is similar to that of Router A, and is not provided here.
# After completing the preceding operations, run the display rip bfd session command on
router A. The command output shows that routers A and B have established a BFD session and
the BFDState field value is displayed as Up. In the following example, the display on Router A
is used.
[RouterA] display rip 1 bfd session all

LocalIp :3.3.3.1 RemoteIp :3.3.3.2 BFDState :Down

BFD Local Dis :8200 Interface :GigabitEthernet2/0/0
Diagnostic Info:No diagnostic information

# Run the shutdown command on GE 1/0/0 of Router B to simulate a fault in the active link.
NOTE
The link fault is simulated to check the configurations. In actual situations, the operation is not required.
[RouterB] interface gigabitethernet1/0/0
# Check the information about the BFD session on Router A. The command output shows that
there is no BFD session between Routers A and B.
[RouterA] display rip 1 bfd session all
LocalIp :3.3.3.1 RemoteIp :3.3.3.2 BFDState :Down

BFD Local Dis :8200 Interface :GigabitEthernet2/0/0
Diagnostic Info:No diagnostic information

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

3.3.3.1/32 Direct 0 0 D 127.0.0.1
4.0.0.0/8 RIP 100 1 D 3.3.3.2
172.16.0.0/16 RIP 100 2 D 3.3.3.2
The preceding command output shows that the standby link Router A->Router C->Router B is
used after the active link fails, and the next-hop address and outbound interface of the route to
destination 172.16.0.0/16 are 3.3.3.2 and GE 2/0/0 respectively.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
undo shutdown
ip address 2.2.2.1 255.255.255.0
#

undo shutdown
ip address 3.3.3.1 255.255.255.0
#
rip 1
version 2
network 2.0.0.0
network 3.0.0.0
bfd all-interfaces min-tx-interval 100 min-rx-interval 100 detect-multiplier
10
#
return

#
sysname RouterB
#
bfd
#
undo shutdown
ip address 2.2.2.2 255.255.255.0
#
undo shutdown
ip address 4.4.4.1 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
rip 1
version 2
network 2.0.0.0
network 4.0.0.0
network 172.16.0.0
bfd all-interfaces min-tx-interval 100 min-rx-interval 100 detect-multiplier
10
#
return

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

#
sysname RouterD
#

undo shutdown
ip address 172.16.1.2 255.255.255.0
#
rip 1
version 2
network 172.16.0.0
#
return

Configuration Guide - IP Routing 4 RIPng Configuration
4 RIPng Configuration
About This Chapter
RIPng is an extension of RIP for support of IPv6.
4.1 Introduction
RIPng is the extension of RIPv2 on IPv4 networks. Most RIP concepts apply to RIPng.
4.2 Configuring Basic RIPng Functions

To implement RIPng features, you need to configure basic RIPng functions, including creating
RIPng processes and enabling RIPng on interfaces.
4.3 Configuring RIPng Route Attributes

By setting RIPng route attributes, you can change RIPng routing policies.
4.4 Configuring RIPng Route Summarization

By configuring a RIPng router to advertise the summarized IPv6 address on an interface, you
can save the space used by RIPng routes in the routing table. You can also set parameters to
prevent an interface from learning the same summarized route.
4.5 Configuring RIPng to Import External Routes

Similar to RIP, RIPng can import external routes to enrich routing information.
4.6 Controlling the Advertising of RIPng Routing Information

To meet the requirements of complex networks, it is required to accurately control the advertising
of RIPng routing information.
4.7 Controlling the Receiving of RIPng Routing Information

To meet the requirements of complex networks, it is required to accurately control the receiving
4.8 Optimizing a RIPng Network

You can adjust and optimize the RIPng network performance by configuring RIPng timers, split
horizon, poison reverse, and zero field check.
4.9 Configuring IPSec Authentication for RIPng

Configuring IPSec authentication for RIPng can improve security of a RIPng network.

In actual networking, different RIPng features have different applications.

4.1 Introduction
RIPng is the extension of RIPv2 on IPv4 networks. Most RIP concepts apply to RIPng.
4.1.1 RIPng Overview

RIPng is a distance-vector routing protocol, which measures the distance to the destination host
by the hop count.
The Routing Information Protocol Next Generation (RIPng) protocol is an extension of RIPv2
that is applied to IPv4 networks. Most RIP-related concepts are applicable to RIPng.
Extension of RIP
For IPv6 applications, RIPng extends RIP as follows:
l UDP port number: In RIPng, UDP port number 521 is used to send and receive routing
information.
l Multicast group address: In RIPng, FF02::9 is used as the multicast group address of RIPng
routers.
l Prefix length: In RIPng, the prefix length of a destination address is 128 bits (the mask
length).
l Next-hop address: In RIPng, a next-hop address is a 128-bit IPv6 address.
l Source address: In RIPng, link-local address is used as the source address to send RIPng
Update packets.
Operation Principle of RIPng

RIPng is a distance-vector routing protocol. It exchanges routing information by using User
Datagram Protocol (UDP) packets through the port 521.
RIPng employs the hop count to measure the distance to the destination. The distance is called
the routing metric. In RIPng, the hop count from the router to its directly connected network is
0, and the hop count from the router to a network, which can be reached through another
router, is 1. The hop count that is equal to or exceeds 16 is defined as infinity, indicating that
the destination network or host is unreachable.
By default, RIPng sends an Update packet every 30 seconds. If no Update packet is received
from a neighbor in 180 seconds, RIPng marks all the routes learned from the neighbor as
unreachable. If no Update packet is received from a neighbor in 300 seconds, RIPng deletes the
routes of the neighbor from the routing table.
To prevent routing loops, RIPng supports split horizon and poison reverse. In addition, RIPng
can import routes from other routing protocols.
Each router running RIPng manages a routing database, which contains routing entries to all
accessible destinations on a network. These routing entries contain the following information:
l Destination address: indicates the IPv6 address of a host or network.

l Next-hop address: indicates the address of the next router to the destination.

l Interface: indicates the interface through which an IP packet is forwarded.

l Cost: indicates the hop count to the destination. The value is an integer that ranges from 0
to 16. If the value is 16, it indicates that the destination host or network is unreachable.
l Timer: indicates the time since a routing entry is last updated. The timer is reset to 0 when
a routing entry is updated.
l Route tag: indicates a label that differentiates routes of interior routing protocols and those
of exterior routing protocols.
4.1.2 RIPng Features Supported by the NE80E/40E

The RIPng features supported by the NE80E/40E include split horizon and poison reverse.
In the NE80E/40E, you can modify the routing policy of RIPng by configuring RIPng route
attributes. You can also control the advertising and receiving of RIPng routing information to
meet the requirements of a complex network. On certain networks, you can configure RIPng
features to optimize the RIPng network performance.
4.2 Configuring Basic RIPng Functions

To implement RIPng features, you need to configure basic RIPng functions, including creating
RIPng processes and enabling RIPng on interfaces.

To make a Router learn the routes to the network segment of an interface, ensure that the link
status of the interface is Up.
The configuration of basic RIPng functions involves the configuration of basic RIPng features.
After the configuration, the RIPng features are available.
During the RIPng configuration, you must enable RIPng in the system view first. If you run
RIPng-related commands in the interface view, these commands take effect only after RIPng is
enabled in the system view.
Before configuring basic RIPng functions, complete the following tasks:
l Enabling IPv6 on the router

l Configuring IPv6 addresses for interfaces to ensure that neighboring nodes are reachable
Data Preparation
To configure basic RIPng functions, you need the following data.

No. Data
1 RIPng process ID
2 Interface to be enabled with RIPng
4.2.2 Enabling RIPng and Entering the RIPng View

Creating RIPng processes is the prerequisite to performing RIPng configurations. When creating
RIPng processes, you can also enter the RIPng view to perform configurations.
Context
Perform the following steps on the router to be enabled with RIPng:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ripng [ process-id ]
The RIPng process is enabled and the RIPng view is displayed.

When only one RIPng process runs, process-id does not need to be specified. That is, process-
id defaults to 1.
After the RIPng process is cancelled, the ripng process-id enable command needs to be
reconfigured on an interface.
description
Descriptions for RIPng processes are configured.
----End
4.2.3 Enabling RIPng in the Interface View

After an interface is associated with a RIPng process, routing information on this interface can
be exchanged through RIPng.
Context
Perform the following steps on the router to be enabled with RIPng:
Procedure
Step 1 Run:
system-view


Step 2 Run:

The interface is at the network side of the router. That is, the router is connected to other devices
through this interface. To enable the router to learn routes to the network segment where the
interface resides, ensure that the link status of the interface is Up.
Step 3 Run:
ripng process-id enable
RIPng is enabled on the specified interface.
NOTE
In the interface view, this command cannot be executed if IPv6 is not enabled.
This command is inapplicable to ATM interfaces.
If the router connects to other devices through multiple interfaces, repeatedly perform Step 2
and Step 3.
----End

After basic RIPng functions are successfully configured, you can view the configuration and
routing information of RIPng.
Prerequisites
Basic RIPng functions has been configurede.
Procedure
l Run the display ripng [ process-id | vpn-instance vpn-instance-name ] command to check
the configuration of the RIPng process.
l Run the display ripng process-id route command to check all the RIPng routes that are
learned from other routers.
l Run the display default-parameter ripng command to check the default RIPng
configuration.
l Run the display ripng process-id statistics interface { all | interface-type interface-
number [ verbose | neighbor neighbor-ipv6-address ] } command to check statistics about
RIPng interfaces.
----End
Example
Run the display ripng [ process-id | vpn-instance vpn-instance-name ] command, and you can
view the configuration of the specified RIPng process.
<HUAWEI> display ripng 100
Public vpn-instance

RIPng process : 100

Preference : 100
Checkzero : Enabled
Default-cost : 0
Number of periodic updates sent : 0
Number of trigger updates sent : 1
Total number of routes : 0
Total number of routes in ADV DB is : 0
Total count for 1 process :
Number of routes sendable in a periodic update : 0
Number of routes sent in last periodic update : 0
Run the display ripng process-id route command, and you can view all activated and inactivated
RIPng routes of the specified RIPng process.
<HUAWEI> display ripng 100 route
Route Flags: R - RIPng
----------------------------------------------------------------
Peer FE80::200:5EFF:FE04:3302 on GigabitEthernet6/0/0

Dest 2001:DB8:1::/32,
via FE80::200:5EFF:FE04:3302, cost 2, tag 0, RA, 6 Sec
Dest 2001:DB8:4:1::/64,
Dest 2001:DB8:4:2::/64,
Dest 2001:DB8:4:3::/64,
Run the display default-parameter ripng command, and you can view the default configuration
of the specified RIPng process.
<Router > display default-parameter ripng
--------------------------------------------------
Protocol Level Default Configurations
--------------------------------------------------
Preference : 100
Checkzero : Enabled
Default-cost : 0
Maximum Balanced Paths : 32
Garbage-Collect time : 120 sec
--------------------------------------------------
Interface Level Default Configurations
--------------------------------------------------
Metricin : 0
Metricout : 1
Split Horizon
For Broadcast and P2P Interfaces : Enabled
For NBMA Interfaces and LoopBack : Disabled
Default Route : Disabled
Packet Transmit Interval : 200 msecs
Packet Transmit Number : 30
Run the display ripng process-id statistics interface command, and you can view statistics
about the specified RIPng interface.
<HUAWEI> display ripng 1 statistics interface gigabitethernet 1/0/0

GigabitEthernet1/0/0(FE80::2E0:B9FF:FE7F:1A01)
------------------------------------------------------------------
4.3 Configuring RIPng Route Attributes

By setting RIPng route attributes, you can change RIPng routing policies.

RIPng route attributes include the RIPng preference and interface metric.
To meet the requirements of a complex network, you can change RIPng routing policies by
configuring RIPng route attributes. After performing configuration procedures in this section,
you can:
l Change the matching order of routing protocols by configuring the RIPng preference when
multiple routing protocols discover routes to the same destination.
l Affect route selection by changing the additional metric of a RIPng interface.
l Implement load balancing among multiple equal-cost routes.
Before configuring RIPng route attributes, complete the following tasks:
l 3.2 Configuring Basic RIP Functions
Data Preparation
To configure RIPng route attributes, you need the following data.
No. Data
1 RIPng preference
2 Additional metric of the interface

4.3.2 Configuring the RIPng Preference

When there are routes discovered by multiple routing protocols on the same router, you can
make the router prefer RIPng routes by setting the RIPng preference.
Context
Each routing protocol has its preference, according to which a routing policy selects the optimal
route. The RIPng preference can be set manually. The greater the value is, the lower the
preference is.
Perform the following steps on the RIPng router:
Procedure
Step 1 Run:
system-view
Step 2 Run:
The RIPng process is enabled and the RIPng view is displayed.
Step 3 Run:
preference { preference | route-policy route-policy-name } *
The RIPng preference is set.
----End
4.3.3 Configuring Additional Metrics of an Interface

You can set additional metrics for received and sent RIPng routes by using different commands.
Context
The additional route metric is the metric (hop count) to be added to the original metric of a RIPng
route.
l The ripng metricin command is used to configure a device to add an additional metric to
a received route before the device adds the route to its routing table, causing the metric of
the route in the routing table to change. Running this command affects route selection on
the device and other devices.
l The ripng metricout command is used to configure a device to add an additional metric
to a route before the device advertises the route, keeping the metric of the route in the
routing table unchanged. Running this command does not affect route selection on the local
device but will affect route selection of other devices.
You can specify the value of the metric to be added to the RIPng route that passes the filtering
policy by specifying value1 through an IPv6 ACL or an IPv6 prefix list. If a RIPng route does
not pass the filtering, its metric is increased by 1.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng metricin value
The metric added to a received route is set.
Step 4 Run:
ripng metricout { value | { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-
prefix-name } value1 }
The metric added to a sent route is set.
NOTE
If the router connects to other RIPng routers through multiple interfaces, repeatedly perform Step 2 to Step
4 until metrics of all links are set.
----End
4.3.4 Configuring the Maximum Number of Equal-Cost Routes

By setting the maximum number of equal-cost RIPng routes, you can change the number of
routes for load balancing.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
The RIPng view is displayed.
Step 3 Run:

NOTE
The range and default value of the maximum number of equal-cost routes may vary according to products
and protocols. You can change the range and default value after purchasing the license.
----End

After RIPng route attributes are successfully set, you can view the configuration and routing
information of RIPng.
Prerequisites
RIPng route attributes has been configured.
Procedure
the running status and configuration of RIPng.
l Run the display ripng process-id database command to check all activated routes in the
RIPng database.
----End
Example
# Display all the activated routes in the RIPng database.
<HUAWEI> display ripng 100 database
2001:DB8:8::8/128,
NULL0 cost 0, Imported
2001:DB8:10::/64,
via FE80::2E0:E6FF:FE1B:8242, Ethernet0/0/0, cost 1
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:12::/64,
Ethernet0/0/0 cost 0, RIPng-interface
# Display all the RIPng routes that are learned from other routers.
----------------------------------------------------------------

Dest 2001:DB8:1::/32,
Dest 2001:DB8:4:1::/64,
Dest 2001:DB8:4:2::/64,
Dest 2001:DB8:4:3::/64,

4.4 Configuring RIPng Route Summarization

By configuring a RIPng router to advertise the summarized IPv6 address on an interface, you
can save the space used by RIPng routes in the routing table. You can also set parameters to
prevent an interface from learning the same summarized route.
Context
This configuration is to configure the RIPng router to advertise the summarized IPv6 prefix
rather than specific routes on an interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng summary-address ipv6-address prefix-length [ avoid-feedback ]
RIPng route summarization is configured.
----End
4.5 Configuring RIPng to Import External Routes

Similar to RIP, RIPng can import external routes to enrich routing information.
Context
To access a device running a non-RIPng protocol, an RIPng-capable device needs to import
routes of the non-RIPng protocol into the RIPng network.
All the following commands can set the cost of the imported route, which are listed in descending
order of priorities.

l Run the import-route (RIPng)command to set the cost of the imported route.
l Run the default-cost (RIPng) command to set the cost of the default route.
Procedure
Step 1 Run:
system-view

Step 2 Run:

default-cost cost
The default cost is set for the external routes imported by RIPng.
If no cost is specified, this command can be used to set the default cost for the external routes
imported by RIPng from other routing protocols.
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.
NOTE
Import of IBGP routes in RIPng process can lead to routing loops. Administrator should take care of routing
loops before configuring permit-ibgp.
----End
4.6 Controlling the Advertising of RIPng Routing

Information
To meet the requirements of complex networks, it is required to accurately control the advertising

RIPng routing information can be advertised through route summarization, default routes, and
imported external routes.
To meet the requirements of a complex network, you need to control the advertising of RIPng
routing information accurately. After performing configuration procedures in this section, you
can:
l Advertise default routes to neighbors.

l Disable interfaces from sending RIPng Update packets.
l Filter routes to be advertised.
Before configuring the router to control the advertising of RIPng routing information, complete

l 3.2 Configuring Basic RIP Functions
Data Preparation
To control the advertising of RIPng routing information, you need the following data.
No. Data
1 Metric of the default route to be advertised
4.6.2 Configuring RIPng to Advertise the Default Routes

There are two methods of advertising RIPng default routes. You can configure a router to
advertise RIPng default routes according to the actual networking. Additionally, you can specify
the cost of the default routes to be advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng default-route { only | originate } [ cost cost ]
RIPng is configured to advertise a default route.
You can configure RIPng to advertise default routes as required:
l only: advertises only IPv6 default routes (::/0) and suppresses the advertising of other routes.
l originate: advertises IPv6 default routes (::/0) and does not affect the advertising of other
routes.
A RIPng default route is forcibly advertised by using an Update packet through a specified
interface, regardless of whether this route exists in the IPv6 routing table.
----End
4.6.3 Disabling Sending of RIPng Packets on an Interface

Disabling an interface from sending RIPng packets is a method of preventing routing loops.

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:
Step 3 Run:
undo ripng output
The interface is disabled from sending RIPng packets.
By default, an interface is allowed to send RIPng packets.
----End
4.6.4 Configuring RIPng to Filter the Routes to be Sent

You can configure RIPng to filter the routes to be sent.
Procedure
Step 1 Run:
system-view
Step 2 Run:

l filter-policy { acl6-number | acl6-name acl6-name } export [ protocol [ process-id ] ]
RIPng is configured to filter the routes based on the ACL.
Run any of the following commands as required:
– Configure a basic ACL:
1. Run:
quit
Return to the RIPng view.

2. Run:
quit


3. Run
acl ipv6 { [ number ] acl6-number1 | name acl-name [ number acl-
number2 ] } [ match-order { auto | config } ]
The basic ACL view is displayed.

4. Run
rule [ rule-id ] { deny | permit } [ fragment | source { source-ipv6-
address prefix-length | source-ipv6-address/prefix-length | any } | time-
range time-name | vpn-instance vpn-instance-name ] *
A rule is configured for the basic ACL.

When the rule command is run to configure rules for a named ACL, only the source
address range specified by source and the time period specified by time-range are
valid as the rules.
– If the action specified in an ACL rule is permit, a route that matches the rule
will be received or advertised by the system.
– If the action specified in an ACL rule is deny, a route that matches the rule will
not be received or advertised by the system.
– If a route has not matched any ACL rules, the route will not be received or
advertised by the system.
smaller number and then matches the route with a rule with a larger number.
Routes can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller number and
specify the action deny in this rule to filter out the unwanted routes. Then,
configure another rule with a larger number in the same ACL and specify the
action permit in this rule to receive or advertise the other routes.
Route filtering using a whitelist: Configure a rule with a smaller number and
specify the action permit in this rule to permit the routes to be received or
advertised by the system. Then, configure another rule with a larger number in
the same ACL and specify the action deny in this rule to filter out unwanted
routes.
– Configure an advanced ACL:
1. Run:
quit

2. Run:
quit

3. Run
acl ipv6 name acl-name [ number acl-number2 ] [ match-order { auto |
config } ]


4. Run
rule [ rule-id ] { deny | permit } protocol [ source { source-ipv6-
range time-name ] *
A rule is configured for the advanced ACL.

routes.
l filter-policy ipv6-prefix ipv6-prefix-name export [ protocol [ process-id ] ]
RIPng is configured to filter the routes based on the prefix list.
l filter-policy route-policy route-policy-name export [ protocol [ process-id ] ]
RIPng is configured to filter the routes based on the route policy.
RIPng can filter the routes to be sent based on an IPv6 ACL, route-policy or an IPv6 prefix list.
Only the routes that meet the match conditions are advertised to neighbors. If protocol is not
specified in the command, all the routing information to be advertised will be filtered, including
the imported routes and local RIPng routes (directly connected routes).
----End

After the function of controlling the advertising of RIPng routing information is successfully
configured, you can view RIPng routing information.
Prerequisites
Controlling the advertising of RIPng routing information has been configured.

Procedure
RIPng database.
----End
Example
2001:DB8:8::8/128,
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:12::/64,
----------------------------------------------------------------

Dest 2001:DB8:1::/32,
Dest 2001:DB8:4:1::/64,
Dest 2001:DB8:4:2::/64,
Dest 2001:DB8:4:3::/64,
4.7 Controlling the Receiving of RIPng Routing Information

To meet the requirements of complex networks, it is required to accurately control the receiving

Before controlling the receiving of RIPng routes, familiarize yourself with the usage scenario,
To meet the requirements of a complicated networking environment, you need to control the
receiving of RIPng routing information accurately. After performing configuration procedures
in this section, you can:

l Disable an interface from receiving RIPng Update packets.

l Filter the received routing information.
l Import external routes from various routing protocols and filter the imported routes.
Before configuring the router to control the receiving of RIPng routing information, complete
l Configuring Basic RIPng Functions
Data Preparation
To control the receiving of RIPng routing information, you need the following data.
No. Data
1 ACL used to filter routing information
4.7.2 Disabling Receiving of RIPng Packets on an Interface

Disabling interfaces from receiving RIPng packets is a method of preventing routing loops.
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:
Step 3 Run:
undo ripng input
The interface is disabled from receiving RIPng packets.
By default, an interface is allowed to receive RIPng packets.
----End

4.7.3 Configuring RIPng to Filter the Received Routes

You can configure a router to selectively receive routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
l filter-policy { acl6-number | acl6-name acl6-name | } import
The imported routes are filtered based on the ACL.
1. Run:
quit

2. Run:
quit

3. Run

4. Run

valid as the rules.

routes.
1. Run:
quit

2. Run:
quit

3. Run
config } ]

4. Run
range time-name ] *


routes.
l filter-policy ipv6-prefix ipv6-prefix-name import
The imported routes are filtered based on the prefix list.
l filter-policy route-policy route-policy-name import
The imported routes are filtered based on the route-policy.
RIPng can filter the received routes based on an IPv6 ACL, route-policy or an IPv6 prefix list.
Only the routes that meet the match conditions are added in the RIPng routing table.
----End

After the function of controlling the receiving of RIPng routing information is successfully
configured, you can view RIPng routing information.
Prerequisites
Controlling the receiving of RIPng routing information has been configured.
Procedure
RIPng database.
----End
Example
2001:DB8:8::8/128,
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:10::/64,
2001:DB8:12::/64,


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

Dest 2001:DB8:1::/32,
Dest 2001:DB8:4:1::/64,
Dest 2001:DB8:4:2::/64,
Dest 2001:DB8:4:3::/64,
4.8 Optimizing a RIPng Network

You can adjust and optimize the RIPng network performance by configuring RIPng timers, split
horizon, poison reverse, and zero field check.

Before adjusting and optimizing the RIPng network performance, familiarize yourself with the
usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
On certain networks, you need to configure RIPng features and optimize the performance of a
RIPng network. After performing configuration procedures in this section, you can:
l Change the convergence speed of the RIPng network by adjusting RIPng timers.
l Configure split horizon and poison reverse to prevent routing loops.
Before optimizing a RIPng network, complete the following tasks:
l Configuring Basic RIPng Functions
Data Preparation
To optimize a RIPng network, you need the following data.
No. Data
1 Values of timers

4.8.2 Configuring RIPng Timers

RIPng has three timers: Update timer, Age timer and Garbage-collect timer. If the three RIPng
timers are configured improperly, routes become unstable.
Context
NOTE
Route flapping occurs if the values of the four RIPng timers are set improperly. The relationship between
the values is as follows: update < age, update < garbage-collect. For example, if the update time is longer
than the aging time, and a RIPng route changes within the update time, the router cannot inform its neighbors
of the change on time.
By default, the Update timer is 30s; the Age timer is 180s; the Garbage-collect timer is 120s.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
timers ripng update age garbage-collect
RIPng timers are configured.
----End
4.8.3 Setting the Interval for Sending Update Packets and the
Maximum Number of Packets Sent Each Time
By setting the interval for sending packets and the maximum number of packets to be sent each
time, you can optimize the RIPng performance.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:


Step 3 Run:
ripng pkt-transmit { interval interval | number pkt-count }*
The interval for sending RIPng Update packets and the maximum number of packets sent each
time are set on the specified interface.
----End
4.8.4 Configuring Split Horizon and Poison Reverse

You can configure split horizon and poison reverse to prevent routing loops.
Context
Split horizon is a method of preventing routing loops by preventing the router from advertising
a route back onto the interface from which the route is learned. On NBMA networks such as FR
networks and X.25 networks, if no sub-interface is configured, split horizon must be disabled
to ensure that routes are advertised correctly.
Poison reverse is another method of preventing routing loops by enabling the router to advertise
a route as unreachable back through the interface from which the route is learned.
If both split horizon and poison reverse are configured, only poison reverse takes effect.
Procedure
Step 1 Run:
system-view

Step 2 Run:
interface interface-type vlan-id

l Run:
ripng split-horizon
Split horizon is enabled.

l Run:
ripng poison-reverse
Poison reverse is enabled.
----End
4.8.5 Enabling the Zero Field Check for RIPng Packets

In a RIPng packet, there are certain fields whose values must be 0. These fields are called zero
fields. If the values of these zero fields in some RIPng packets are not 0s, these RIPng packets
are ignored.

Context
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
checkzero
The zero field check is configured for RIPng packets.
----End

After the function of adjusting and optimizing the RIPng network performance is successfully
configured, you can view routing information, neighbor information, and interface information
of RIPng.
Prerequisites
Adjusting and optimizing the RIPng network performance has been configured.
Procedure
the configuration of the RIPng process.
l Run the display ripng process-id database [ verbose ] command to check all activated
routes in the RIPng database.
l Run the display ripng process-id interface [ interface-type interface-number ]
[ verbose ] command to check information about the RIPng interface.
l Run the display ripng process-id neighbor [ verbose ] command to check information
about RIPng neighbors.
----End
4.9 Configuring IPSec Authentication for RIPng

Configuring IPSec authentication for RIPng can improve security of a RIPng network.


RIPng supports IPSec authentication. Before configuring IPSec authentication for RIPng,
familiarize yourself with basic IPSec configurations.
As networks develop rapidly, network security has become a major concern. If IPSec
authentication is configured on a RIPng network, the sent and received RIPng packets will be
authenticated, and those cannot pass authentication will be discarded. This can improve the
security of the RIPng network.
There are two methods of configuring IPSec authentication for RIPng:

l One method is to configure IPSec authentication in RIPng processes. If IPSec
authentication is enabled in a RIPng process, this configuration takes effect on all interfaces
in this RIPng process. This method is recommended if IPSec authentication needs to be
applied to all interfaces in a RIPng process.
l The other method is to configure IPSec authentication on RIPng interfaces. This method
is recommended if IPSec authentication needs to be applied only to some interfaces in a
RIPng process.
Before configuring IPSec authentication for RIPng, complete the following tasks:
l Configuring basic IPSec functions

l Configuring basic RIPng functions
Data Preparation
To configure IPSec authentication for RIPng, you need the following data.
No. Data
1 Name of a security association (SA)
4.9.2 Configuring IPSec Authentication in a RIPng Process

Configuring IPSec authentication in the RIPng view is one of the methods used to configure
IPSec authentication for RIPng.
Context
If IPSec authentication is enabled in the RIPng view, all interfaces in the RIPng process will
perform IPSec authentication on the RIPng packets received or sent by the interfaces.
Procedure
Step 1 Run:

system-view
Step 2 Run:
Step 3 Run:
ipsec sa sa-name
IPSec authentication is enabled, and the name of an SA is specified.
----End
4.9.3 Configuring IPSec Authentication on a RIPng Interface

Configuring IPSec authentication in the interface view is the other method used to configure
IPSec authentication for RIPng.
Context
This method is recommended if not all the interfaces in a RIPng process need to perform IPSec
authentication on packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ripng ipsec sa sa-name
IPSec authentication is enabled on the interface, and the name of an SA is specified.
NOTE
The ripng ipsec sa command takes precedence over the ipsec sa command. If both commands are run in
respective views and different SA names are specified, only the configuration of the ripng ipsec sa
command takes effect.
----End

After IPSec authentication for RIPng is configured, you can check the SA used in IPSec
authentication and statistics on the RIPng packets that failed authentication.

Prerequisites
After IPSec authentication is enabled in a RIPng process or on a RIPng interface, the
configuration takes effect immediately. There is no need to restart the RIPng process.
Procedure
l Run the display ripng process-id interface [ interface-type interface-number ]
[ verbose ] command to check the SA used in IPSec authentication.
l Run the display ripng process-id statistics interface { all | interface-type interface-
number [ verbose | neighbor neighbor-ipv6-address ] } command to check the number of
RIPng packets that failed authentication.
----End
Example
Run the display ripng interface command, and you can view the name of an SA used in IPSec
authentication on a RIPng interface.
<Router > display ripng 1 interface GigabitEthernet1/0/0 verbose
FE80::A0A:200:1
State : UP, Protocol : RIPNG, MTU : 1440
Metricin : 0
Metricout : 1
Default Route : Disabled
Split Horizon : Enabled
Authentication : IPSEC (SA - sa1)
Run the display ripng statistics interface command, and you can view the number of RIPng
packets that failed authentication.
<Router > display ripng 1 statistics interface gigabitethernet 1/0/0
GigabitEthernet1/0/0(FE80::2E0:64FF:FE10:8142)
------------------------------------------------------------------
Bad packets received 0 0 0
Routes received 0 0 0
Routes sent 0 0 0
Bad routes received 0 0 0
Packet send failed 0 0 0
Packet IPSEC6 Auth failed 0 0 2

In actual networking, different RIPng features have different applications.
NOTE

4.10.1 Example for Configuring RIPng to Filter the Received Routes

By configuring basic RIPng functions and ACLs, you can enable RIPng to filter received routes.
You can run commands to view the configuration results.
As shown in Figure 4-1, the prefix length of all the IPv6 addresses is 64, and neighboring
routers are connected by using IPv6 link-local addresses.
It is required that all routers learn IPv6 routing information on the network through RIPng. In
addition, Router B is required to filter out the route imported from Router C (at 2001:DB8:3::/64)
so that this route is neither added to the routing table of Router B nor advertised to Router A.
Figure 4-1 Networking diagram for configuring RIPng to filter the received routes
GE2/0/0
2001:db8:1::1/64 GE2/0/0
POS1/0/0 POS2/0/0 2001:db8:2::1/64
POS1/0/0 POS1/0/0
RouterA RouterB RouterC GE3/0/0
2001:db8:3::1/64
1. Configure basic RIPng functions on each router to ensure that the routers communicate
with each other.
2. Configure an ACL on Router B to filter the imported routes.
Data Preparation
l RIPng process 1 to be enabled on each router
l ACL6 2000 to be configured on Router B to deny routes from network segment
2001:DB8:3::/64
Procedure
The configurations details are not described here.
Step 2 Configure basic RIPng functions.
[RouterA] ripng 1
[RouterA-ripng-1] quit

[RouterA] interface gigabitethernet 2/0/0

[RouterA-GigabitEthernet2/0/0] ripng 1 enable
[RouterA-Pos1/0/0] ripng 1 enable
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterB] interface pos 1/0/0
[RouterB-Pos1/0/0] ripng 1 enable
[RouterB-Pos1/0/0] quit
[RouterB-Pos2/0/0] ripng 1 enable
[RouterC] ripng 1
[RouterC-ripng-1] quit
[RouterC] interface pos 1/0/0
[RouterC-Pos1/0/0] ripng 1 enable
[RouterC-Pos1/0/0] quit
[RouterC-GigabitEthernet2/0/0] ripng 1 enable
[RouterC-GigabitEthernet3/0/0] ripng 1 enable
# Check the RIPng routing table of Router B.

[RouterB] display ripng 1 route
Route Flags: A - Aging, G - Garbage-collect
----------------------------------------------------------------
Peer FE80::F54C:0:9FDB:1 on Pos2/0/0
Dest 2001:DB8:2::/64,
via FE80::F54C:0:9FDB:1, cost 1, tag 0, A, 3 Sec
Dest 2001:DB8:3::/64,
Peer FE80::D472:0:3C23:1 on Pos1/0/0
Dest 2001:DB8:1::/64,
via FE80::D472:0:3C23:1, cost 1, tag 0, A, 4 Sec
# Check the RIPng routing table of Router A.

[RouterA] display ripng 1 route
----------------------------------------------------------------
Peer FE80::476:0:3624:1 on Pos1/0/0
Dest 2001:DB8:2::/64,
via FE80::476:0:3624:1, cost 2, tag 0, A, 21 Sec
Dest 2001:DB8:3::/64,
Step 3 Configure Router B to filter the imported routes.

[RouterB] acl ipv6 number 2000
[RouterB-acl6-basic-2000] rule deny source 2001:DB8:3::/64
[RouterB-acl6-basic-2000] rule permit
[RouterB-acl6-basic-2000] quit
[RouterB] ripng 1
[RouterB-ripng-1] filter-policy 2000 import
[RouterB-ripng-1] quit

# Check the RIPng routing table of Router B. The command output shows that the RIPng routing
table does not contain the route from network segment 2001:DB8:3::/64.
[RouterB] display ripng 1 route
----------------------------------------------------------------
Peer FE80::F54C:0:9FDB:1 on Pos2/0/0
Dest 2001:DB8:2::/64,
Peer FE80::D472:0:3C23:1 on Pos1/0/0
Dest 2001:DB8:1::/64,
via FE80::D472:0:3C23:1, cost 1, tag 0, A, 25 Sec
[RouterA] display ripng 1 route
----------------------------------------------------------------
Peer FE80::476:0:3624:1 on Pos1/0/0
Dest 2001:DB8:2::/64,
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:1::1/64
ripng 1 enable
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
ripng 1 enable
#
ripng 1
#
return

#
sysname RouterB
#
ipv6
#
acl ipv6 number 2000
rule 0 deny source 2001:DB8:3::/64
rule 1 permit
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
ripng 1 enable
#
interface Pos2/0/0
link-protocol ppp
undo shutdown

ipv6 enable
ripng 1 enable
#
ripng 1
filter-policy 2000 import
#
return

#
sysname RouterC
#
ipv6
#
undo shutdown
ipv6 enable
ripng 1 enable
#
undo shutdown
ipv6 enable
ripng 1 enable
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
ripng 1 enable
#
ripng 1
#
return

Configuration Guide - IP Routing 5 OSPF Configuration
5 OSPF Configuration
About This Chapter
OSPF, which is developed by the IETF, is a link-state IGP. OSPF is widely used in access
networks and MANs.
5.1 Introduction
By building OSPF networks, you can enable OSPF to discover and calculate routes in ASs.
OSPF is applicable to a large-scale network that consists of hundreds of routers.
5.2 Configuring Basic OSPF Functions
This section describes how to configure basic OSPF functions.
5.3 Configuring OSPF on the NBMA or P2MP Network
This section describes how to configure OSPF and modify attributes on the NBMA or point-to-
multipoint (P2MP) network to flexibly construct the OSPF network.
5.4 Configuring an OSPF Route Selection Rule
You can configure an OSPF route selection rule to meet requirements of complex networks.
5.5 Controlling OSPF Routing Information
You can control the advertising and receiving of OSPF routing information and import routes
of other protocols.
5.6 Configuring an OSPF Dynamic Hostname
Compared with router IDs, Open Shortest Path First (OSPF) dynamic hostnames are easier to
memorize. Therefore, using dynamic hostnames to identify routers can facilitate network
management.
5.7 Configuring an OSPF Stub Area
Configuring a non-backbone area as a stub area can reduce routing entries in the area in an AS
does not transmit routes learned from other areas in the AS or AS external routes. This reduces
bandwidth and storage resource consumption.
5.8 Configuring an NSSA
Configuring a non-backbone area on the border of an AS as an NSSA does not transmit routes
learned from other areas in the AS but external routes imported. This reduces bandwidth and
storage resource consumption on the router.
5.9 Configuring Local MT

By configuring local multicast topology (MT), you can create a proper routing table for multicast
traffic when multicast and an MPLS TE tunnel are configured on a network.
5.10 Configuring BFD for OSPF

After BFD for OSPF is enabled, when a link fails, the router rapidly detects the failure, notifies
the OSPF process or interface of the fault, and instructs OSPF to recalculate routes. This speeds
up OSPF network convergence.
5.11 Configuring OSPF IP FRR

With OSPF IP FRR, devices can rapidly switch traffic from faulty links to backup links without
interrupting traffic. This protects traffic and greatly improves the reliability of OSPF networks.
5.12 Configuring OSPF GR

This section describes how to configure OSPF GR to avoid traffic interruption and route flapping
caused by the active/standby switchover.
5.13 Improving Security of an OSPF Network

On a network demanding high security, you can adopt the GTSM mechanism and configure
OSPF authentication to improve the security of the OSPF network.
5.14 Configuring the Network Management Function of OSPF

OSPF supports the network management function. You can bind the OSPF MIB to a certain
OSPF process, and configure the trap function and log function.
5.15 Maintaining OSPF

Maintaining OSPF involves resetting OSPF and clearing OSPF statistics.

This section provides several configuration examples of OSPF together with the Networking
diagram. The configuration examples explain networking requirements, configuration notes,
and configuration roadmap.

5.1 Introduction
By building OSPF networks, you can enable OSPF to discover and calculate routes in ASs.
OSPF is applicable to a large-scale network that consists of hundreds of routers.
5.1.1 OSPF Overview

OSPF is a link-state IGP. At present, OSPFv2 is intended for IPv4.
Defined by the Internet Engineering Task Force (IETF), the Open Shortest Path First (OSPF)
protocol is an Interior Gateway Protocol (IGP) implemented on the basis of the link status.
NOTE
In this chapter, OSPF refers to OSPFv2, unless otherwise specified.
OSPF Features
OSPF has the following features:
l Wide applications
OSPF is applicable to networks of various sizes and even to the network consisting of
hundreds of routers.
l Fast convergence
Once the network topology changes, Update packets are transmitted to synchronize the link
state databases (LSDBs) of all the routers within the Autonomous System (AS).
l Loop-free
According to the collected link status, OSPF calculates routes with the shortest path tree
algorithm. This algorithm ensures the generation of loop-free routes.
l Area division
An AS can be divided into different areas to facilitate AS management. After the area
partition, an LSDB stores routing information only of the local area. The reduce of LSDB
size dramatically reduces memory and CPU usage. In addition, less bandwidth is consumed
because of the decrease in routing information transmitted within the AS.
l Equal-cost routes
OSPF supports multiple equal-cost routes to the same destination.
l Routing hierarchy
Four types of routing are available. They are listed in the descending order of priority: intra-
area routes, inter-area routes, Type 1 external routes, and Type 2 external routes.
l Authentication
Area-based and interface-based packet authentication guarantees the security of packet
interaction.
l Multicast
Multicast packets are transmitted only on certain types of links to reduce the interference
for some devices.

Process of OSPF Route Calculation

The process of calculating OSPF routes is as follows:
1. Based on the surrounding network topology, each OSPF device originates a Link State
Advertisement (LSA). The router then transmits Update packets containing the LSAs to
other OSPF devices.
2. Each OSPF device collects the LSAs from other devices, and all these LSAs compose the
LSDB. An LSA describes the network topology around a router, whereas an LSDB
describes the network topology of the whole AS.
3. OSPF devices transform the LSDB into a weighted directed map. The weighted directed
map reflects the topology of the entire network. All routers in the same area have the same
map.
4. According to the directed map, each router uses the Shortest Path First (SPF) algorithm to
calculate the shortest path tree, regarding itself as the root. The tree displays the routes to
each node in the AS.
Area Division
The number of routers increases with the unceasing expansion of the network scale. This leads
to a large LSDB on each router. As a result, the load of each router is very heavy. OSPF solves
this problem by dividing an AS into different areas. An area is regarded as a device group
logically. Each group is identified by an area ID. On the border of an area resides a router rather
than a link. A network segment (or a link) belongs to only one area. That is, the area to which
each OSPF interface belongs must be specified, as shown in Figure 5-1.
Figure 5-1 OSPF area division
Area1 Area4
Area0
Area2 Area3
After area division, route aggregation can be performed on border routers to reduce the number
of LSAs advertised to other areas. Route aggregation also minimizes the influence caused by
changes in the topology.

Router Type
Routers are classified into the following types according to their locations in the AS:
l Internal routers
l Area border routers (ABRs)
l Backbone routers
l AS boundary routers (ASBRs)
Figure 5-2 Types of routers

ASBR
Area1 Area4
Backbone
Internal Area0 Router
Router
Area2 ABR Area3
OSPF Network Types

OSPF classifies networks into four types according to the link layer protocol:
l Broadcast: If the link layer protocol is Ethernet or FDDI, OSPF defaults the network type
to broadcast. In this type of networks, the following situations occur.
– Hello packets and packets from the Designated Router (DR) are sent in multicast mode
(224.0.0.5: indicates the reserved IP multicast addresses for OSPF devices).
– Link State Update (LSU) packets are sent to the DR in multicast mode (224.0.0.6:
indicates the reserved IP multicast address for the OSPF DR), and the DR forwards the
LSU packets to destination 224.0.0.5.
– Database Description (DD) packets, Link State Request (LSR) packets, and all
retransmission packets are sent in unicast mode.
– Link State Acknowledgement (LSAck) packets are usually sent in multicast mode
(224.0.0.5). When a router receives repeated LSAs, or the LSAs are deleted due to the
timeout of the maximum lifetime, LSAck packets are sent in unicast mode.
l Non-Broadcast Multi-Access (NBMA): If the link layer protocol is Frame Relay, ATM, or
X.25, OSPF defaults the network type to NBMA. In this type of networks, protocol packets,
such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packet, are
transmitted in unicast mode.
l Point-to-Multipoint (P2MP): A P2MP network must be forcibly changed from other
network types. In this type of networks, Hello packets are transmitted in multicast mode

(224.0.0.5); DD packets, LSR packets, LSU packets, and LSAck packets are transmitted
in unicast mode.
l Point-to-Point (P2P): If the link layer protocol is PPP, HDLC, or LAPB, OSPF defaults the
network type to P2P. In this type of networks, protocol packets, such as Hello packets, DD
packets, LSR packets, LSU packets, and LSAck packets, are transmitted in multicast mode
(224.0.0.5).
5.1.2 OSPF Features Supported by the NE80E/40E

The NE80E/40E supports various OSPF features, including multi-process, authentication, hot
standby, Smart-discover, local MT, GR, TE, VPN multi-instance, sham link, BFD, IGP Shortcut,
forwarding adjacency, OSPF-BGP association, and GTSM.
Multi-process
OSPF supports multi-process. More than one OSPF process can run on the same router because
processes are mutually independent. Route interaction between different OSPF processes is
similar to the interaction between different routing protocols.
An interface of a router belongs to only a certain OSPF process.
A typical application of OSPF multi-process is to run OSPF between PEs and CEs in the VPN
where OSPF is also adopted in the backbone network. On the PEs, the two OSPF processes are
independent of each other.
Authentication
OSPF supports packet authentication. Only the OSPF packets that pass the authentication can
be received. If the packets fail to pass the authentication, the neighbor relationship cannot be
established.
The NE80E/40E supports two authentication modes:
l Area authentication mode

l Interface authentication mode
If both modes are available, the latter is preferred.
Hot Backup and GR

The router with a distributed structure supports OSPF hot standby (HSB). OSPF backs up
necessary information from the active main board (AMB) to the standby main board (SMB).
When the AMB fails, the SMB replaces it to ensure the normal operation of OSPF.
OSPF supports two types of HSB:
l Backing up all OSPF data: After the switchover between the AMB and the SMB, OSPF
restores its normal work immediately.
l Backing up only the OSPF configuration: After the switchover between the AMB and the
SMB, OSPF performs graceful restart (GR), obtains the adjacency relationship from
neighbors, and synchronizes the LSDBs.

Smart-discover
Generally, routers periodically send Hello packets through interfaces that run OSPF, routers set
up and maintain the neighbor relationship, and elect the DR and the Backup Designated Router
(BDR) on the multi-access network (broadcast or NBMA) by exchanging Hello packets. When
establishing the neighbor relationship or electing the DR and the BDR on the multi-access
network, interfaces can send Hello packets only when the Hello timer expires. This affects the
speed for establishing the neighbor relationship and electing the DR and the BDR.
NOTE
l The interval for sending Hello packets on an interface depends on the interval for sending Hello packets
set on the interface.
l The default value of the interval for sending Hello packets varies with the network type.
The Smart-discover function can solve the preceding problem.
l In broadcast and NBMA networks, the neighbor relationship can be established rapidly and
a DR and a BDR on the networks can be elected rapidly.
When the neighbor status becomes 2-way for the first time, or it returns to Init from the 2-
way or higher state as shown in Figure 5-3, the interface enabled with the Smart-discover
function sends Hello packets to the neighbor without waiting for the timeout of the Hello
timer when the interface finds that the status of the neighbor changes.
When the interface status of the DR and the BDR in the multi-access network changes, the
interface enabled with the Smart-discover function sends Hello packets to the network
segment and takes part in the DR or BDR election.
Figure 5-3 Changes of the neighbor state machine
Down Init 2-way Exstart Exchange Loading Full
Attempt
(NBMA)
l On P2P and P2MP networks, the adjacency relationship can be established rapidly. The
principle is the same as that in broadcast and NBMA networks.
Local MT
When multicast and a MultiProtocol Label Switching (MPLS) Traffic Engineering (TE) tunnel
are deployed in a network simultaneously, services become unavailable because the multicast
function may be affected by the TE tunnel. This is because after the TE tunnel is enabled with
IGP Shortcut, the outgoing interface of the route calculated by IGP 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 Join message through a TE tunnel interface. Routers spanned by the TE tunnel
cannot sense the Join message, and therefore 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 TE tunnel through related physical interfaces. The routers, however,
do not have multicast forwarding entries. As a result, the multicast data packets are discarded.
Services therefore become unavailable.

When a network runs the OSPF protocol, you can enable OSPF local Multicast-Topology (MT)
to solve the problem of multicast traffic interruption caused by the conflict between multicast
and the TE tunnel. After local MT is enabled, multicast packets can be correctly forwarded. If
the outgoing interface of the calculated route is a TE tunnel interface of IGP-Shortcut type, a
router adds a route of the physical outgoing interface to the MIGP routing table. Multicast uses
routes in the MIGP routing table to forward packets.
NOTE
For details of local MT, refer to the chapter "IP Multicast Overview" in the HUAWEI NetEngine80E/
40E Router Feature Description - IP Multicast.
OSPF GR
When a router restarts or performs the active/standby switchover, it directly ages all routing
entries in the Forward Information Base (FIB) table. This results in route interruption. In
addition, neighboring routers remove this router from the neighbor list, and notify other
routers. This causes the re-calculation of SPF. If this router recovers within a few seconds, the
neighbor relationship becomes unstable. This results in route flapping.
After being enabled with OSPF Graceful Restart (GR), a router can ensure continuous packet
forwarding if it restarts just for abnormities. In such a case, route flapping is avoided during the
short restart of the router.
NOTE
Unless otherwise specified, "protocol restart" in this document refers to restarting OSPF in GR mode.
When a router restarts OSPF, the GR Restarter does not age the forwarding information. At the
same time, the GR Helper keeps the topology information or routes obtained from the GR
Restarter for a period. This ensures that traffic forwarding is not interrupted when protocol restart
occurs.
OSPF and DS-TE

OSPF TE supports the establishing and maintaining of the Label Switch Path (LSP) of the TE.
When constructing constraint-based routed LSP (CR LSP), MPLS needs information about the
traffic attributes of all the links in the area. With the help of the OSPF, MPLS obtains traffic
engineering information about the links.
OSPF supports a new type of LSAs called opaque LSA. The opaque LSA can carry TE
information. You can use the related commands to configure OSPF to support or not support
the originating and handling of the opaque LSA that carries TE information.
Difference service aware TE (DS-TE) is primarily used to optimize and assign network
transmission resources, classify the traffic, and specify the percentage of each traffic to the link
bandwidth. Traffic engineering is implemented based on each divided class (aggregated class
with fine granularity) instead of an aggregated class (aggregated class with coarse granularity).
This enhances the performance and utility of the bandwidth.
To support DS-TE in MPLS, OSPF supports Local Overbooking Multiplier TLV and bandwidth
constraint (BC) TLV.
NOTE
For details of OSPF TE configurations, refer to the HUAWEI NetEngine80E/40E Router Configuration
Guide - MPLS.

IGP Shortcut and Forwarding Adjacency

OSPF TE supports either IGP shortcut aor Forwarding Adjacency (FA). This two features allow
OSPF TE to establish an LSP to reach a specified destination. Without the two features, OSPF
cannot use the LSP as an outgoing interface even if the LSP to the destination exists.
The differences between IGP Shortcut and forwarding adjacency are as follows:
l If only forwarding adjacency is enabled, OSPF can reach the destination by using the LSP.
l If only IGP Shortcut is enabled, only the router enabled with IGP Shortcut can use the LSP.
NOTE
For detailed configuration of this feature, refer to the HUAWEI NetEngine80E/40E Router Configuration
Guide - MPLS.
OSPF VPN Multi-instance

OSPF supports multi-instance, which can run between PEs and CEs in VPN networks.
In BGP MPLS VPN, many sites of one VPN can use OSPF as the internal routing protocol. The
sites, however, are handled as being from different ASs. In this way, the OSPF routes learned
on one site are transmitted as external routes to another site. This causes a heavy OSPF traffic
and some avoidable network management problems.
In the NE80E/40E implementation, you can configure domain IDs on a PE to differentiate the
VPNs where different sites reside. Different sites in one VPN consider each other as if they were
connected directly. Therefore, PEs exchange OSPF routing information as if they were directly
connected through a leased line. This improves network management and enhances the validity
of the OSPF application.
NOTE
For detailed configuration of this feature, refer to the HUAWEI NetEngine80E/40E Router Configuration
Guide - VPN.
OSPF Sham Links

OSPF sham links are unnumbered P2P links between two PEs over an MPLS VPN backbone
network.
Generally, BGP extended community attributes carry routing information over the MPLS VPN
backbone between BGP peers. OSPF running on the remote PE uses this information to generate
Type3 summary LSAs from PE to CE. These routes are considered as inter-area routes.
If a router, however, connects to PEs in its own area and establishes an intra-area route to a
particular destination, the VPN traffic always traverses the route rather than the backbone route.
This is because OSPF intra-area routes in the routing table have relatively higher priorities. To
prevent this, an unnumbered P2P sham link is configured between the PEs. This provides an
intra-area path with a lower cost to the PE.
NOTE
For configurations of OSPF sham links, refer to the HUAWEI NetEngine80E/40E Router Configuration
Guide - VPN.

BFD for OSPF

By default, in broadcast networks, the interval for OSPF to send Hello packets is 10 seconds; in
NBMA networks, the interval for sending Hello packets is 30 seconds, and the period for
advertising that the neighbor is Down is four times the interval for sending Hello packets. If the
router does not receive the Hello packet from the neighbor before the neighboring router becomes
invalid, it deletes the neighbor. That is, the router detects the neighbor faults in seconds. This
leads to the loss of a large number of packets in a high-speed network.
To solve the preceding problem in the current detection mechanism, Bidirectional Forwarding
Detection (BFD) is developed. BFD can implement detection at the millisecond level. Instead
of replacing the Hello mechanism of OSPF, BFD works with OSPF to fast detect the adjacency
fault. BFD is used to notify OSPF of recalculating routes. This can correctly guide the packet
forwarding.
Routing Management (RM) module exchanges routing information with the BFD module.
Through RM, OSPF notifies BFD of dynamically setting up or deleting BFD sessions. The Event
message of BFD is delivered to OSPF through RM.
The process of establishing and deleting a BFD session is as follows:
l Process of establishing a BFD session: If BFD feature is globally configured, BFD is
enabled on an interface or a process, and the status of the OSPF neighbor is Full, OSPF
uses RM to notify the BFD module of establishing the BFD session and negotiate related
parameters of BFD.
l Process of deleting a BFD session: When BFD detects a link fault, BFD generates a Down
event and notifies the upper protocol of the fault through RM. OSPF then responds to the
event and immediately deletes the adjacency relationship on the link. At this time, the status
of the neighbor is not Full. This does not meet the requirements of establishing a BFD
session. OSPF then uses RM to notify the BFD module of deleting the BFD session.
OSPF supports dynamically establishing or deleting a BFD session on broadcast, P2P, P2MP,
and NBMA links.
Configure BFD according to the actual network environment. If time parameters are set
incorrectly, network flapping occurs.
OSPF-BGP
When a new router is connected to the network, or a router restarts, the network traffic may be
lost during BGP convergence. This is because the IGP route convergence is quicker than the
BGP route convergence.
If the backup link exists, OSPF-BGP linkage makes a router that restarts or a router that is
connected to the network start the stub router timer during the OSPF-BGP linkage. During the
set linkage period, the router acts as the stub router by increasing the metrics of the links in the
LSA generated by the router to 65535. Other OSPF devices are notified of not using the stub
router to forward data. This ensures that the router is not used as the spanned router. This avoids
traffic loss during traffic switchback because route convergence speed is slower than that of
OSPF.
GTSM
The Generalized TTL Security Mechanism (GTSM) refers to the generic TTL security protection
mechanism. GTSM protects services of the upper layer over the IP layer by checking whether

the TTL value in the IP header is in a pre-defined range. In applications, GTSM is designed to
protect the TCP/IP-based control plane (like routing protocols) from CPU-utilization attacks,
such as CPU overload attacks.
5.2 Configuring Basic OSPF Functions

This section describes how to configure basic OSPF functions.

Before configuring basic OSPF functions, enable OSPF, specify the OSPF process and area, and
establish OSPF neighbor relationships.
When OSPF is configured on multiple routers in the same area, most configuration data, such
as the timer, filter, and aggregation, must be planned uniformly in the area. Incorrect
configurations may cause neighboring routers to fail to send messages to each other or even
causing routing information congestion and self-loops.
The OSPF-relevant commands that are configured in the interface view take effect regardless
of whether OSPF is enabled. After OSPF is disabled, the OSPF-relevant commands also exist
on interfaces.
Before configuring basic OSPF functions, complete the following tasks:
l Configuring a link layer protocol

l Configuring IP addresses for interfaces to ensure that neighboring routers are reachable at
the network layer
Data Preparation
To configure basic OSPF functions, you need the following data.
No. Data
1 Router ID
2 OSPF process ID
3 VPN instance name (if OSPF multi-instance is configured)
4 ID of the area to which an interface belongs
5 IP address of the network segment where an interface resides

5.2.2 Enabling OSPF

Create an OSPF process and specify a router ID to enable OSPF. After enabling OSPF, specify
an interface on which the OSPF protocol is running and the area to which the interface belongs.
After that, routes can be discovered and calculated in the AS.
Context
Before running OSPF on the router, specify a router ID for the router. The router ID is a 32-bit
unsigned integer, which identifies the router in the AS. To ensure OSPF stability, manually set
the router ID of each router during network planning.
This causes the link state database (LSDB) to unexpectedly grow. OSPF resolves this problem
by partitioning an AS into different areas. The area is regarded as a logical group and each group
is identified by an area ID. At the border of an area resides the router instead of a link. A network
segment (or a link) belongs to only one area. The area to which each OSPF interface belongs
must be specified.
There are two methods for enabling OSPF: creating an OSPF process and enabling OSPF on an
interface.
Procedure
l Create an OSPF process.
1. Run:
system-view

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

The NE80E/40E supports OSPF multi-process. If you wan to configure OSPF in the
VPN instance view, run the ospf [ process-id | router-id router-id | vpn-instance
vpn-instance-name ] * command.
– The parameter process-id specifies the ID of an OSPF process. The default value
is 1.
The NE80E/40E supports OSPF multi-process. You can create different processes
for services of different types. The OSPF process ID is valid in the local area,
without affecting packet exchange with other Routers. Therefore, different
Routers can also exchange packets even though they have different process IDs.
– The parameter router-id router-id specifies the router ID of the Router.
By default, the system automatically selects an IP address of the interface as the
router ID. Assign a unique router ID for each device in an AS. Generally, you can
set the router ID to be the same as an interface IP address.
NOTE
The router ID of each OSPF process must be unique on the entire network. Otherwise,
routers cannot establish OSPF neighbor relationships, and the routing information is
incorrect.
If a router ID conflict occurs, perform either of the following operations:

– Run the ospf router-id router-id command to reconfigure a router ID.

– Run the undo ospf router-id auto-recover disable command to enable the
router ID automatic recovery function. After the function is enabled, the system
automatically allocates a new router ID.
NOTE
l If the automatic recovery function is enabled and a router ID conflict occurs between
indirectly connected routers in one OSPF area, the system replaces the conflicted router
ID with a newly calculated one. The automatic recovery function takes effect on both
configured and automatically generated router IDs.
l The system can replace a router ID in a maximum of three attempts in case the router
ID conflict persists.
If the router ID is changed, a new router ID will take affect after the reset ospf
[ process-id ]process command is run.
– The parameter vpn-instance vpn-instance-name specifies the name of a virtual
private network (VPN) instance.
If a VPN instance is specified, the OSPF process belongs to the specified VPN
instance. Otherwise, the OSPF process belongs to public network instances.
The description of an OSPF process helps identify special processes by the

description command.
3. Run:
area area-id
The OSPF area view is displayed.
The OSPF areas can be classified into a backbone area with the area ID of 0 and non-
backbone areas. The backbone area is responsible for forwarding inter-area routing
information. The routing information between the non-backbone areas must be
forwarded through the backbone area.
The description of an OSPF area helps identify special processes by the description
command.
4. Run:
network ip-address wildcard-mask [ description text ]
The network segments are configured to belong to the area. description is used to
configure a description for the specified OSPF network segment.
OSPF can run on an interface properly only when the following conditions are met:
– The mask length of the IP address of an interface is greater than or equal to that
specified by the network command.
NOTE
When the wildcard-mask parameter in the network command is specified as 0, if the IP
address of the interface and the IP address that is configured by the network address
command are the same, OSPF is enabled on the interface.
– The primary IP address of an interface is on the network segment specified by the
network command.
By default, OSPF uses a 32-bit host route to advertise the IP address of a 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 for OSPF Interfaces.
l Enable OSPF on an interface.
1. Run:
system-view

2. Run:

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 format of IPv4 address.
----End
5.2.3 (Optional) Creating OSPF Virtual Links

This section describes how to create logical links between backbone areas to ensure the OSPF
network connectivity.
Context
After OSPF areas are defined, OSPF route updates between non-backbone areas are transmitted
through a backbone area. Therefore, OSPF requires that all non-backbone areas maintain the
connectivity with the backbone area and the backbone areas in different OSPF areas maintain
the connectivity with each other. In real world situations, this requirement may not be met
because of some restrictions. To resolve this problem, you can configure OSPF virtual links.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run:
area area-id
Step 4 Run:
vlink-peer router-id [ dead dead-interval | hello hello-interval | retransmit
retransmit-interval | smart-discover | trans-delay trans-delay-interval | [ simple
[ plain plain-text | [ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-sha256 }

[ key-id { plain plain-text | [ cipher ] cipher-text } ] | authentication-null |

keychain keychain-name ] ] *
A virtual link is created.

This command must also be configured on the neighboring router.
----End
Follow-up Procedure
After virtual links are created, different default MTUs may be used on devices provided by
different vendors. To ensure consistency, the MTU is set to 0 by default when the interface sends
DD packets. For details, see Configuring an Interface to Fill in the DD Packet with the Actual
MTU.
5.2.4 (Optional) Configuring a Route Selection Rule on the router

You can configure the router to comply with the route selection rule defined in RFC 1583 or
RFC 2328.
Context
RFC 2328 and RFC 1583 define the route selection rule differently. After OSPF is enabled on
the router, specify a route selection rule based on the router configuration. The router complies
with the route selection rule defined in RFC 1583 by default. If the neighboring router complies
with the route selection rule defined in RFC 2328, configure the local router to comply with that
defined in RFC 2328. This allows all routers in the OSPF area to comply with the same route
selection rule.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
undo rfc1583 compatible
The router is configured to comply with the route selection rule defined in RFC 2328, not RFC
1583.
By default, the router complies with route selection rule defined in RFC 1583.
----End
5.2.5 (Optional) Setting the OSPF Priority

When multiple routing protocols are used to select routes, you can set the OSPF priority to
maneuver route selection.

Context
The routing protocols may share and select the routing information because the router may run
multiple dynamic routing protocols at the same time. The system sets a priority for each routing
protocol. When multiple routing protocols are used to select routes, the route selected by the
routing protocol with a higher priority takes effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
preference [ ase ] { preference | route-policy route-policy-name } *
The OSPF priority is set.
l ase: sets the priority of the AS-External route.

l preference: sets the priority for OSPF. The smaller the value, the higher the priority.
l route-policy-name: sets the priority for specified routes in the routing policy.
The default OSPF priority value is 10. When an ASE is specified, the default OSPF priority
value is 150.
----End
5.2.6 (Optional) Restricting the Flooding of LSA Update Packets

When a large number of LSA update packets are flooded, the neighboring router may be busy
processing LSA update packets and has to discard the Hello packets that are used to maintain
neighbor relationships. This causes neighbor relationships to be interrupted. To resolve this
problem, you can restrict the flooding of LSA update packets to maintain neighbor relationships.
Context
When multiple neighboring routers are configured or a large number of LSA update packets are
flooded, the neighboring router may receive a large number of LSA update packets in a short
period. This keeps the neighboring router busy processing a burst of LSA update packets and
causes the neighboring router to unexpectedly discard Hello packets that are used to maintain
the OSPF neighbor relationships. As a result, the neighbor relationships are interrupted. After
the neighbor relationships are reestablished, more packets are to be exchanged. This intensifies
neighbor relationship interruption. To resolve this problem, you can restrict the flooding of LSA
update packets to maintain neighbor relationships.

Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
flooding-control [ number transmit-number | timer-interval transmit-interval ] *
The flooding of LSA update packets is restricted.
By default, the number of LSA update packets to be flooded each time is 50, and the interval at
which LSA update packets are flooded is 30s.
After the flooding-control command is run, the flooding of LSA update packets is immediately
restricted.
If the flooding-control command is not run, the function of restricting the flooding of LSA
update packets automatically takes effect when the number of neighboring routers exceeds 256.
----End
5.2.7 (Optional) Configuring the Maximum Number of Packet

Retransmission Attempts
When no response to DD packets, LSU packets, or LSR packets is received, the retransmission
mechanism is used and the maximum number of packet retransmission attempts is set.
Context
If no response is received when the maximum number of packet retransmission attempts is
reached, the neighbor relationship will be interrupted. By default, the retransmission mechanism
is disabled.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
retransmission-limit [ max-number ]
The maximum number of OSPF packet retransmission attempts is set.

max-number specifies the maximum number of packet retransmission attempts and is 30 by

default.
----End
5.2.8 (Optional) Setting an Interval at Which an LSA Packet Is

Retransmitted to the Neighboring router
You can control packet retransmission and improve the convergence rate by setting an interval
at which an LSA packet is retransmitted to the neighboring router.
Context
After sending an LSA packet to the neighboring router, the router waits for a response. If no
response is received within the set interval, the router retransmits the LSA packet to the
neighboring router.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ospf timer retransmit interval
An interval at which an LSA packet is retransmitted to the neighboring router is set.

Setting the interval to a proper value is recommended. A rather small interval will cause
unnecessary retransmission. The interval is generally longer than a round trip of one packet
transmitted between two routers.
The default retransmission interval is 5s and is widely used.
----End
5.2.9 (Optional) Configuring an Interface to Fill in a DD Packet with

the Interface MTU
You can configure an interface to fill in the Interface MTU field of a DD packet with the interface
MTU.
Context
The default maximum transmission unit (MTU) is 0.
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.

NOTICE
Setting the MTU in a DD packet will have the neighbor relationship reestablished.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ospf mtu-enable
The interface is configured to fill in a DD packet with the interface MTU and check whether the
MTU in the DD packet from the neighboring router exceeds the MTU of the local router.
----End

After basic OSPF functions are successfully configured, you can check information about the
LSDB, neighbors in each area, and routing table.
Prerequisites
Basic OSPF functions have been configured.
Procedure
l Run the display ospf [ process-id ] peer command to check OSPF neighbor information.
l Run the display ospf [ process-id ] routing command to check OSPF routing table
information.
l Run the display ospf [ process-id ] lsdb command to check OSPF LSDB information.
----End
Example
Run the display ospf peer command. If the OSPF neighbor relationship is in the Full state, the
configuration succeeds.
<HUAWEI> display ospf peer
OSPF Process 1 with Router ID 10.1.1.2
Neighbors
Area 0.0.0.0 interface 10.1.1.2(GigabitEthernet1/0/0)'s neighbors

Router ID: 10.1.1.1 Address: 10.1.1.1 GR State: Normal

State: Full Mode:Nbr is Slave Priority: 1
DR: 10.1.1.1 BDR: None MTU: 0
Dead timer due in 35 sec
Retrans timer interval: 5
Neighbor is up for 00:00:05
Authentication Sequence: [ 0 ]
Run the display ospf routing command to view OSPF routing table information.
<HUAWEI> display ospf routing
Routing Tables
Routing for Network

Destination Cost Type NextHop AdvRouter Area
172.16.1.0/24 4 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
172.17.1.0/24 1 Transit 172.17.1.1 4.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.2.0/24 1 Stub 192.168.2.2 4.4.4.4 0.0.0.2
Routing for ASEs

Destination Cost Type Tag NextHop AdvRouter
10.0.0.0/8 1 Type2 1 192.168.2.1 1.1.1.1
Total Nets: 6
Intra Area: 2 Inter Area: 3 ASE: 1 NSSA: 0
5.3 Configuring OSPF on the NBMA or P2MP Network

This section describes how to configure OSPF and modify attributes on the NBMA or point-to-
multipoint (P2MP) network to flexibly construct the OSPF network.

To implement OSPF functions, configure OSPF on the NBMA or P2MP network.
As shown in Table 5-1, OSPF classifies networks into four types based on the types of link layer
protocols.
NOTE
Differentiated OSPF configurations that are applicable to the NBMA network and P2MP network are
provided in this section. The OSPF configurations not provided here are applicable to the four types of
networks.
Table 5-1 Network types supported by OSPF
Network Type Characteristic Default Configuration
Broadcast On the broadcast network, Hello If the link layer protocol is

packets, LSU packets, and LSAck Ethernet or Fiber Distributed Data
packets are multicasted; DD Interface (FDDI), OSPF regards
packets and LSR packets are the network as a broadcast
unicasted. network by default.

Network Type Characteristic Default Configuration
Non-broadcast On an NBMA network, Hello If the link layer protocol is ATM,

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

multipoint (P2MP) packets are multicasted; DD a P2MP network by default
packets, LSR packets, LSU regardless of any link layer
packets, and LSAck packets are protocol. A P2MP network is
unicasted. forcibly changed from the network
The mask lengths of the routers on of another type.
the P2MP network must be the
same.
As shown in Table 5-1, OSPF sends packets in different manners on networks of different types.
Therefore, the difference between OSPF configurations on the networks lies in the packet
sending configurations.
Before configuring OSPF on the NBMA or P2MP network, complete the following tasks:
the network layer
l Configuring Basic OSPF Functions
Data Preparation
To configure OSPF on the NBMA or P2MP network, you need the following data.
No. Data
1 Number of the interface running OSPF
2 Network type
3 DR priority of an interface

No. Data
4 IP address of a neighbor on an NBMA network
5 Interval at which Hello packets are sent on an NBMA network
5.3.2 Configuring Network Types for OSPF Interfaces

OSPF classifies networks into four types based on the types of link layer protocols. You can
configure the network type for an OSPF interface to forcibly change its original network type.
Context
By default, the physical interface type determines the network type.
l The network type of an Ethernet interface is Broadcast.

l The network type of a serial interface or a POS interface running PPP or HDLC is P2P.
l The network type of an ATM interface or a Frame Relay (FR) interface is NBMA.
NOTE
A P2MP network is forcibly changed from another other type of network.
The network types of the interfaces on both ends of a link must be the same; otherwise, the OSPF
neighbor relationship cannot be established. Only when the network type of one OSPF interface
is broadcast and the network type of the other OSPF interface is P2P, the two interfaces can still
set up the neighbor relationship; but cannot learn the OSPF routing information each other.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf network-type { broadcast | nbma | p2mp | p2p [ peer-ip-ignore ] }
The network type of the OSPF interface is configured.
When the network type is configured for an interface, the original network type of the interface
is replaced.
The network type can be configured based on the real world situations.
l On an interface with the broadcast network type, if a router that does not support the multicast
address exists, change the network type of the interface to NBMA.

l On an interface with the NBMA network type, if the network is fully meshed or any two
routers are directly connected, change the network type of the interface to broadcast and do
not configure neighboring router information on the interface.
l On an interface with the NBMA network type, if the network is not fully meshed, change
the network type of the interface to P2MP. After that, two indirectly connected routers can
communicate through one router that can directly reach both the two routers. After the
network type of the interface is changed to P2MP, configuring neighboring router
information on the interface is unnecessary.
l If only two routers run OSPF on the same network segment, changing the network type of
the interface to P2P is recommended.
peer-ip-ignore is used to disable network segment check when IP address unnumbering is not
configured for a P2P interface changed from a broadcast interface and the interface tries to
establish an OSPF neighbor relationship. By default, if peer-ip-ignore is not specified in the
command, OSPF checks the network segment of the two ends during which an OSPF neighbor
relationship is to be established. Specifically, OSPF performs an AND operation on the local
subnet mask and the local IP address and on the local subnet mask and the remote IP address.
An OSPF neighbor relationship can be established only when the results on the two ends are the
same.
NOTE
OSPF cannot be configured on a null interface.
----End
5.3.3 Configuring NBMA Network Attributes

To implement OSPF functions, configure NBMA network attributes.
Procedure
Step 1 (Optional) Set the network type to NBMA.
The NBMA network must be fully meshed. Any two routers on the NBMA network must be
directly reachable. In most cases, however, this requirement cannot be met. To resolve this
problem, run specific commands to forcibly change the network type to NBMA. For details, see
Configuring Network Types for OSPF Interfaces.
1. Run:
system-view

2. Run:

3. Run:
ospf network-type nbma
The network type of the OSPF interface is set to NBMA.

ospf timer poll interval

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

2. Run:
ospf [ process-id ]

3. Run:
peer ip-address [ dr-priority priority ]
A neighboring router is configured.
----End
5.3.4 Configuring P2MP Network Attributes

To implement OSPF functions, configure P2MP network attributes.
Procedure
Step 1 Disable OSPF from checking the network mask.
The OSPF neighbor relationship cannot be established between the routers with different mask
lengths on the P2MP network. After OSPF is disabled from checking the network mask, the
OSPF neighbor relationship can be properly established.
1. Run:
system-view

2. Run:

3. Run:
ospf network-type p2mp
The network type of the OSPF interface is configured.
A P2MP network is forcibly changed from another other type of network. For details, see
Configuring Network Types for OSPF Interfaces.

4. Run:
ospf p2mp-mask-ignore
OSPF is disabled from checking the network mask on the P2MP network.
Step 2 (Optional) Configure the router to filter the LSA packets to be sent.
When multiple links exist between two routers, you can configure the local router to filter the
LSA packets to be sent. This can reduce unnecessary LSA retransmission attempts and save
bandwidth resources.
1. Run:
quit
Exit from the interface view.

2. Run:
ospf [ process-id ]

3. Run any of the following commands as required:
a. Run:
filter-lsa-out peer ip-address { all | { summary [ acl { acl-number |
acl-name } ] | ase [ acl{ acl-number | acl-name } ] | nssa [ acl{ acl-
number | acl-name } ] } * }
The local router is configured to filter the LSA packets to be sent on the P2MP
network.
b. Run:
quit

c. Run:
acl { [ number ] acl-number1 | name acl-name basic [ number acl-

d. Run:
rule [ rule-id ] { deny | permit } [ fragment-type fragment-type-name
| source { source-ip-address source-wildcard | any } | time-range time-
name | vpn-instance vpn-instance-name ] *
The rule for the basic ACL is configured.


– If the ACL referenced by the route-policy does not exist, all routes matching
the route-policy will be received or advertised by the system.
– In the configuration order, the system first matches a route with a rule that has
a smaller number and then matches the route with a rule with a larger number.
routes.
l Based on the advanced ACL:
a. filter-lsa-out peer ip-address { all | { summary acl acl-name | ase
acl acl-name | nssa acl acl-name } * }
The local router is configured to filter the LSA packets to be sent on the P2MP
network.
b. Run:
quit

c. Run:
Run acl name acl-name advance [ number acl-number2 ] [ match-order
{ auto | config } ]

d. Run:
rule [ rule-id ] { deny | permit } protocol [ source { source-ip-address
source-wildcard | any } | time-range time-name ] *
The rule for the advanced ACL is configured.

– If the ACL referenced by the route-policy does not exist, all routes matching
the route-policy will be received or advertised by the system.
– In the configuration order, the system first matches a route with a rule that has
a smaller number and then matches the route with a rule with a larger number.

routes.
By default, the LSA packets to be sent are not filtered.
----End

After OSPF attributes on the NBMA network and P2MP network are set, you can check OSPF
statistics, LSDB information, neighbor information, and interface information.
Prerequisites
OSPF attributes on the NBMA network and P2MP network have been configured.
Procedure
l Run the either of the following command to check LSDB information.
– display ospf [ process-id ] lsdb [ brief ]
– display ospf [ process-id ] lsdb [ router | network | summary | asbr | ase | nssa |
opaque-link | opaque-area | opaque-as ] [ link-state-id ] [ originate-router
[ advertising-router-id ] | self-originate ] [ age { min-value min-age-value | max-
value max-age-value } * ]
l Run the display ospf [ process-id ] peer [ [ interface-type interface-number ] neighbor-
id | brief | last-nbr-down ] command to view neighbor information.
l Run the display ospf [ process-id ] nexthop command to check next hop information.
l Run the either of the following command to check routing table information.
– display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ] [ interface
interface-type interface-number ] [ nexthop nexthop-address ]
– display ospf [ process-id ] routing router-id [ router-id ]
l Run the display ospf [ process-id ] interface [ all | interface-typeinterface-number ]
[ verbose ] command to check interface information.
----End
Example
Run the display ospf interface command to view the network type of the interface and the
priority of the interface for DR election.
<HUAWEI> display ospf interface GigabitEthernet2/0/0
Interfaces

Interface: 10.1.1.1 (GigabitEthernet2/0/0)

Cost: 1 State: BDR Type: Broadcast MTU: 1500
Priority: 1
Designated Router: 10.1.1.2
Backup Designated Router: 10.1.1.1
Timers: Hello 10 , Dead 40 , Poll 120 , Retransmit 5 , Transmit Delay 1
5.4 Configuring an OSPF Route Selection Rule

You can configure an OSPF route selection rule to meet requirements of complex networks.

Before configuring an OSPF route selection rule, familiarize yourself with the usage scenario,
In real world situations, you can configure an OSPF route selection rule by setting OSPF route
attributes to meet the requirements of complex networks.
l Set the cost of an interface. The link connected to the interface with a smaller cost value
preferentially transmits routing information.
l Configure equal-cost routes to implement load balancing.
l Configure a stub router during the maintenance operations such as upgrade to ensure stable
data transmission through key routes.
l Suppress interfaces from sending or receiving packets to help select the optimal route.
l Configuring an OSPF interface to automatically adjust the link cost based on link quality
facilitates route selection control and improves network reliability.
Before configuring an OSPF route selection rule, complete the following tasks:
the network layer
Data Preparation
To configure an OSPF route selection rule, you need the following data.
No. Data
1 Interface cost
3 Equal-cost route preference
4 Link cost adjustment value

5.4.2 Setting the Interface Cost

You can adjust and optimize route selection by setting the OSPF interface cost.
Context
After the OSPF interface costs are set, the interface with a smaller cost value preferentially
transmits routing information. This helps select the optimal route.
The OSPF interface cost can be set manually or calculated based on the interface bandwidth.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf cost cost
The OSPF interface cost is set.
The router generally transmits routing information using the link connected to the interface with
a smaller cost value.
If no interface cost is configured, the system automatically calculates the interface cost based
on 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. By default, the
bandwidth reference value is 100, in Mbit/s. Changing the bandwidth reference value can change
the cost of an interface.
Perform the following steps to change the bandwidth reference value:
1. Run:
system-view

2. Run:
ospf [ process-id ]

3. Run:
bandwidth-reference value
The bandwidth reference value is set.
----End

5.4.3 Configuring Equal-Cost Routes

You can set the number of OSPF equal-cost routes and route preference to implement load
balancing and adjust route selection.
Context
If the destinations and costs of the multiple routes discovered by one routing protocol are the
same, load balancing can be implemented among the routes.
As shown in Figure 5-4, three routes between router A and router B that run OSPF have the
same costs. The three routes are equal-cost routes for load balancing.
Figure 5-4 Networking diagram of equal-cost routes
IP Network
cos
=5 t=1
c os t 0
cost=10 cost=5
IP Network
RouterA RouterB
cos
t=8 t=7
cos
IP Network
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
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 preferences are selected for load balancing. For details
about route preference configuration, see Step 4.
2. Interface index: If routes have the same priorities, routes with higher interface index values
are selected for load balancing.

3. Next hop IP address: If routes have the same priorities and interface index values, routes
with larger IP address are selected for load balancing.
NOTE
The maximum number of equal-cost routes is 32, by default, it is 32. The value range and default value of
the maximum number of equal-cost routes may vary according to the product. You can change the
maximum number and default number by purchasing a license.

nexthop ip-address weight value
The route preferences are configured for load balancing.
When the number of equal-cost routes on the live network is greater than that specified in the
maximum load-balancing command, valid routes are randomly selected for load balancing. To
specify valid routes for load balancing, run the nexthop command to set the route preference.
Ensure that the preferences of valid routes to be used must be high.
The smaller the weight value, the higher the preference of the route. The default weight value
is 255, which indicates that load balancing is implemented regardless of the route preferences.
----End
5.4.4 Configuring a Stub Router

To ensure that a route is not interrupted during flapping-triggering maintenance operations such
as upgrade, you can configure a router as a stub router to allow traffic to bypass the route on the
stub router.
Context
After a stub router is configured, the route on the stub router will not be preferentially selected.
After the route cost is set to the maximum value 65535, traffic generally bypasses the router.
This ensures an uninterrupted route on the router during maintenance operations such as upgrade.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
stub-router [ on-startup [ interval ] ]
A stub router is configured.
By default, no router is configured as a stub router.
If a router is configured as a stub router, the router keeps functioning as a stub router for 500s.

NOTE
The stub router configured in this manner is irrelevant to the router in the stub area.
----End
5.4.5 Suppressing an Interface from Receiving and Sending OSPF

Packets
After an interface is suppressed from receiving and sending OSPF packets, routing information
can bypass a specific router and the local router can reject routing information advertised by
another router.
Context
Suppressing an interface from receiving and sending OSPF packets helps routing information
to bypass a specific router and enables the local router to reject routing information advertised
by another router. This ensures that an optimal route is provided.
For example, there are three routes between router A and router B, as shown in Figure 5-5. To
configure the route with the outbound interface of 1/0/1 to be the optimal route, suppress 1/0/0
and 1/0/2 from receiving and sending OSPF packets.
Figure 5-5 Networking diagram of suppressing an interface from receiving and sending OSPF
packets
IP Network
0
1 / 0/
P OS
POS1/0/1
IP Network
PO
S1
RouterA /0/ RouterB
2
IP Network
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
silent-interface { all | interface-typeinterface-number }

An interface is suppressed from receiving and sending OSPF packets.
The same interface in different processes can be suppressed from sending and receiving OSPF
packets, but the silent-interface command is valid only for the OSPF interface in the local
process.
After an OSPF interface is configured to be in the silent state, the interface can still advertise its
direct routes. Hello packets on the interface, however, cannot be forwarded. Therefore, no
neighbor relationship can be established on the interface. This can enhance the networking
adaptability of OSPF and reduce system resource consumption.
----End
5.4.6 Configuring an OSPF Interface to Automatically Adjust the

Link Cost
Configuring an OSPF interface to automatically adjust the link cost based on link quality
Context
A bit error refers to the deviation between a bit that is sent and the bit that is received. The bit
error rate (BER) refers to the number of bit errors divided by the total number of bits transferred
during a studied time interval. During data transmission, a high BER will degrade or even
interrupt services in extreme cases.
To prevent this problem, configure OSPF interfaces to automatically adjust link costs based on
link quality, so that unreliable links are not used by the optimal routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospf enable [ process-id ] area area-id
OSPF is enabled on the interface.
Step 4 Run:
link-quality low bit-error-threshold error-ratio trigger-coefficient trigger-power
resume-ratio recovery-coefficient recovery-power
The upper and lower thresholds for triggering link quality changes are set on the OSPF interface.
After you run this command, if the BER of the OSPF interface reaches or exceeds the upper
threshold, the link quality changes from good to low; if the BER of the OSPF interface reaches
or falls below the lower threshold, the link quality changes from low to good.

Step 5 Run:
ospf link-quality low incr-cost { cost | max-reachable }
The OSPF interface is configured to automatically adjust the link cost based on link quality.
By default, an OSPF interface does not have this function.
NOTE
The cost parameter specifies the link cost adjustment value. After this parameter is specified:
l If the link quality changes from good to low, the link cost equals the original link cost plus the adjustment
value. The maximum link cost allowed is 65535.
l If the link quality changes from low to good, the orginal link cost applies.
----End

After an OSPF route selection rule is configured, you can check information about the OSPF
routing table, interface, and next hop.
Prerequisites
All OSPF route selection configurations have been configured.
Procedure
l Run the display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ]
[ interface interface-type interface-number ] [ nexthop nexthop-address ] command to
check the OSPF routing table information.
l Run the display ospf [ process-id ] interface [ all | interface-type interface-number ]
[ verbose ] command to check OSPF interface information.
----End
Example
Run the display ospf [ process-id ] routing ip-address command to view the route convergence
priority.
<HUAWEI> display ospf routing 10.1.1.1
Destination : 10.1.1.0/24
AdverRouter : 10.1.1.2 Area : 0.0.0.0
Cost : 1 Type : Transit
NextHop : 10.1.1.2 Interface : Ethernet1/0/0
Priority : Low Age : 00h02m43s
5.5 Controlling OSPF Routing Information

of other protocols.


Before controlling OSPF routing information, familiarize yourself with the usage scenario,
of other protocols.
Before controlling OSPF routing information, complete the following tasks:
the network layer
Data Preparation
To control OSPF routing information, you need the following data.
No. Data
1 Link cost
2 ACL for route filtering
3 Name of the imported routing protocol, OSPF process ID, and default parameters
5.5.2 Configuring OSPF to Import External Routes

Importing the routes discovered by other routing protocols can enrich OSPF routing information.
Context
To access a router running a non-OSPF protocol, an OSPF-capable router needs to import routes
of the non-OSPF protocol into the OSPF network.
OSPF provides loop-free intra-area routes and inter-area routes; however, OSPF cannot prevent
external routing loops. Therefore, exercise caution when configuring OSPF to import external
routes. For details, see "OSPF VPN" in the HUAWEI NetEngine80E/40E Router Feature
Description - IP Routing.
Perform the following steps on the ASBR running OSPF.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
Step 3 Run:
import-route { limit limit-number | { bgp [ permit-ibgp ] | direct | unr | rip
[ process-id-rip ] | static | isis [ process-id-isis ] | ospf [ process-id-ospf ] }
[ cost cost | type type | tag tag | route-policy route-policy-name ] * }
Routes are imported from another protocol.

default { cost { cost | inherit-metric } | limit limit | tag tag | type type } *
The default values of parameters (the cost, number of routes, tag, and type) are set for imported
routes.
When OSPF imports external routes, you can set default values for some additional parameters,
such as the cost, number of routes to be imported, route tag, and route type. The route tag is used
to identify the protocol-related information. For example, it can be used to differentiate AS
numbers carried in BGP routes imported by OSPF.
By default, the cost of the external routes imported by OSPF is 1; a maximum of 2147483647
routes can be imported each time; the type of the imported external routes is Type 2; the default
tag value of the imported routes is 1.
NOTE
You can run one of the following commands to set the cost of the imported route. The following commands
are listed in descending order of priorities.
l Run the 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.
Step 5 (Optional) Run any of the following commands as required:

filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-
policy route-policy-name } export [ protocol [ process-id ] ]

1. Run:
filter-policy { acl-number | acl-name acl-name } export [ protocol [ process-
id ] ]
Routes imported using Step 3 can be advertised only when meeting filtering conditions.
2. Run:
quit

3. Run:
acl { [ number ] acl-number1 | name acl-name basic [ number acl-number2 ] }
[ match-order { auto | config } ]

4. Run:

rule [ rule-id ] { deny | permit } [ fragment-type fragment-type-name |

source { source-ip-address source-wildcard | any } | time-range time-name |
vpn-instance vpn-instance-name ] *

by the system.
1. Run:
filter-policy acl-name acl-name export [ protocol [ process-id ] ]
2. Run:
quit

3. Run:
Run acl name acl-name advance [ number acl-number2 ] [ match-order { auto |
config } ]

4. Run:


by the system.
Run:
filter-policy ip-prefix ip-prefix-name export [ protocol [ process-id ] ]
l Based on the Route-Policy:
Run:
filter-policy route-policy route-policy-name export [ protocol [ process-id ] ]
OSPF filters the imported routes. OSPF uses Type 5 LSAs to carry routes that meet the filtering
conditions and advertises these Type 5 LSAs.
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
imported routes.
The import-route command cannot be used to import the default route from another AS.
----End
5.5.3 Configuring OSPF to Import a Default Route

The default route is widely applied on the OSPF network to reduce routing entries in the routing
table and filter specific routing information.
Context
On the area border and AS border of an OSPF network generally reside multiple routers for next-
hop backup or traffic load balancing. A default route can be configured to reduce routing entries
and improve resource usage on the OSPF network.

The default route is generally applied to the following scenarios:

1. An ABR in an area advertises Type 3 LSAs carrying the default route within the area.
routers in the area use the received default route to forward inter-area packets.
2. An ASBR in an AS advertises Type 5 or Type 7 LSAs carrying the default route within the
AS. routers in the AS use the received default route to forward AS external packets.
When no exactly matched route is discovered, the router can forward packets through the default
route.
The preference of the default route in Type 3 LSAs is higher than that of the route in Type 5 or
Type 7 LSAs.
The advertising mode of the default route is determined by the type of the area to which the
default route is imported, as shown in Table 5-2.
Table 5-2 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
Automatically ABR Type 3 LSA NSSA
Totally Automatically ABR Type 3 LSA NSSA

NSSA
Perform the following steps on the ASBR running OSPF.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
default-route-advertise [ [ always | permit-calculate-other ] | cost cost | type
type | route-policy route-policy-name ] *
The default route is imported into the OSPF process.

To configure the parameter cost to specify the default cost of Type-3 summary LSAs, enable
VPN first.
Before advertising a default route, OSPF compares the preferences of default routes. Therefore,
if a static default route is configured on an OSPF device, 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.
For details about how to configure the default route in the NSSA, see Configuring an NSSA.
----End
5.5.4 Configuring Route Summarization

When a large-scale OSPF network is deployed, you can configure route summarization to reduce
routing entries. Otherwise, a large number of routing entries are generated and consume system
resources unexpectedly.
Context
Route summarization on a large-scale OSPF network efficiently reduces routing entries. This
minimizes system resource consumption and maintains the system performance. In addition, if
a specific link frequently alternates between Up and Down, the links not involved in the route
summarization will not be affected. This prevents route flapping and improves the network
stability.
Procedure
l Configure ABR route summarization.
1. Run:
system-view

2. Run:
ospf [ process-id ]

3. Run:
area area-id

4. Run:
ip-address mask [ [ advertise | not-advertise ] | cost { cost | inherit-
minimum } ] *
abr-summary ip-address mask [ [ cost { cost | inherit-minimum } |
[ advertise [ generate-null0-route ] | not-advertise | generate-null0-
route [ advertise ] ] ] * ]
ABR route summarization is configured.
You can specify to generate a black-hole route in the RM module by using generate-
null0-route, which is used to prevent routing loops.
l Configure ASBR route summarization.

1. Run:
system-view

2. Run:
ospf [ process-id ]

3. (Optional) Run:
asbr-summary type nssa-trans-type-reference [ cost nssa-trans-cost-
reference ]
OSPF is configured to refer to Type 5 LSAs that are translated from Type 7 LSAs
when it sets types and costs for summary routes on ASBRs.
If the asbr-summary type nssa-trans-type-reference cost nssa-trans-cost-

reference is not run, when OSPF set types and costs for summary routes on ASBRs,
OSPF does not refer to Type 5 LSAs that are translated from Type 7 LSAs.
4. Run:
asbr-summary ip-address mask [ not-advertise[ not-advertise | generate-
null0-route ] | tag tag | cost cost | distribute-delay interval ] *
ASBR route summarization is configured.
You can specify to generate a black-hole route in the RM module by using generate-
null0-route, which is used to prevent routing loops.
NOTE
After route summarization is configured, the routing table on the local OSPF router remains the same.
The routing table on another OSPF router, however, contains only one summarized route, no specific
route. This summarized route is not removed until all specific routes are interrupted.
----End
5.5.5 Configuring OSPF to Filter Routes Received by OSPF

By configuring filtering conditions for the received routes, you can allow only the routes that
meet the filtering conditions to be added to the routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]

1. Run:
filter-policy { acl-number | acl-name acl-name } import

Routes received by OSPF are filtered.

2. Run:
quit

3. Run:

4. Run:

by the system.
1. Run:
filter-policy { acl-name acl-name } import

2. Run:
quit

3. Run:
config } ]


4. Run:

by the system.
Run:
filter-policy { ip-prefix ip-prefix-name } import

l Based on the Route-Policy:
Run:
filter-policy { route-policy route-policy-name [ secondary ] } import

OSPF is a dynamic routing protocol based on the link state, and routing information is carried
in LSAs. The filter-policy import command cannot be used to filter the advertised and received
LSAs. Actually, this command is used to filter the routes calculated by OSPF. Only the routes
that meet the filtering conditions are added to the routing table.
----End
5.5.6 Configuring the router to Filter LSAs to Be Sent

Filtering the LSAs to be sent on the local router can prevent unnecessary LSA transmission.
This reduces the size of the LSDB on the neighboring router and speeds up network convergence.

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

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

2. Run:
quit

3. Run:

4. Run:

by the system.

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

2. Run:
quit

3. Run:
config } ]

4. Run:

by the system.

By default, the LSAs to be sent are not filtered.
----End
5.5.7 (Optional) Configuring OSPF to Filter LSAs in an Area

Filtering LSAs in an area can prevent unnecessary LSA transmission. This reduces the size of
the LSDB on the neighboring router and speeds up network convergence.
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 Filter incoming or outgoing Type 3 LSAs in the area.

l Filter outgoing Type 3 LSAs in the area, run any of the following commands as required:
– Based on the basic ACL:
1. Run:
filter { acl-number | acl-name acl-name } export
The filter outgoing Type 3 LSAs in the area are filtered.

2. Run:
quit

3. Run:

4. Run:


source { source-ip-address source-wildcard | any } | time-range time-

routes.
– Based on the advanced ACL:
1. Run:
filter acl-name acl-name export

2. Run:
quit

3. Run:
{ auto | config } ]

4. Run:


routes.
– Based on the IP prefix:
Run:
filter ip-prefix ip-prefix-name export

– Based on the Route-Policy:
Run:
filter route-policy route-policy-name export

l Filter incoming Type 3 LSAs in the area, run any of the following commands as required:
1. Run:
filter { acl-number | acl-name acl-name } import
The filter incoming Type 3 LSAs in the area are filtered.

2. Run:
quit
3. Run:

4. Run:
source { source-ip-address source-wildcard | any } | time-range time-


routes.
1. Run:
filter acl-name acl-name import

2. Run:
quit

3. Run:
{ auto | config } ]

4. Run:


routes.
Run:
filter ip-prefix ip-prefix-name import

Run:
filter route-policy route-policy-name import
----End
5.5.8 (Optional) Enabling the Mesh-Group Function

The mesh-group function is used to prevent repeated flooding and save system resources.
Context
When concurrent links exist between two routers, you can enable the mesh-group function to
reduce the load on the links.
The neighboring router ID identifies each mesh group. Several concurrent links are added to a
mesh group. Flooding is implemented once in the group. You can add interfaces that meet the
following conditions to the same mesh group.
l The interfaces belong to the same area and OSPF process.

l The interfaces begin to exchange DD packets.
l The interfaces are connected to the same neighboring router.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
Step 3 Run:
mesh-group enable
The mesh-group function is enabled.
By default, the mesh-group function is disabled.
----End
5.5.9 Setting the Maximum Number of External LSAs in the LSDB

You can set the maximum number of external LSAs in the LDSB to keep a proper number of
external LSAs.
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

After controlling OSPF routing information, you can check information about the OSPF routing
table, interface, and ASBR summarization.
Prerequisites
Controlling OSPF routing information has been configured.
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 ]

l Run the display ospf [ process-id ] asbr-summary [ ip-address mask ] command to check
OSPF ASBR summarization information.
----End
Example
Run the display ospf interface command to view the OSPF interface information.
<HUAWEI> display ospf interface GigabitEthernet2/0/0

Interfaces
Interface: 10.1.1.1 (GigabitEthernet2/0/0)

Cost: 1 State: BDR Type: Broadcast MTU: 1500
Priority: 1
Designated Router: 1.1.1.2
Backup Designated Router: 1.1.1.1
Timers: Hello 10 , Dead 40 , Poll 120 , Retransmit 5 , Transmit Delay 1
Run the display ospf asbr-summary command to view summarization information about routes
imported by the local router.
<HUAWEI> display ospf asbr-summary

Summary Addresses
Total summary address count: 1
Summary Address
net : 10.0.0.0
mask : 255.0.0.0
tag : 10
status : Advertise
Cost : 0 (Not Configured)
Delay : 30 (Configured)
The Count of Route is : 2
Destination Net Mask Proto Process Type Metric
10.1.0.0 255.255.0.0 Static 1 2 10
10.2.0.0 255.255.0.0 Static 1 2 10
5.6 Configuring an OSPF Dynamic Hostname

Compared with router IDs, Open Shortest Path First (OSPF) dynamic hostnames are easier to
memorize. Therefore, using dynamic hostnames to identify routers can facilitate network
management.
To facilitate network management, configure dynamic hostnames to identify routers. If you
configure a dynamic hostname for a router, the router generates a router information (RI) Opaque
LSA, from which you can check the mapping between the router ID and the dynamic hostname.
Before configuring a dynamic hostname, 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.
l Configure basic OSPF functions.
l Enable the Opaque LSA capability.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
opaque-capability enable
The Opaque LSA capability is enabled.
Step 4 Run:
hostname hostname
An OSPF dynamic hostname is configured.
NOTE
If you specify hostname in this command, hostname is advertised as the dynamic hostname. If no
hostname is specified in this command, the device name specified in the sysname command is advertised
as the dynamic hostname.
----End

Run either of the following commands to check OSPF hostname information:
l display ospf hostname-table

l display ospf [ process-id ] peer [ interface-type interface-number | interface-name ]
hostname hostname
l display ospf [ process-id ] lsdb [ { router | network | summary | asbr | ase | nssa | opaque-
link | opaque-area | opaque-as } [ link-state-id ] ] hostname hostname [ age { min-
value min-age-value | max-value max-age-value } * ]
l display ospf [ process-id ] lsdb [ { brief | [ { 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 } * ] [ resolve-hostname ] } ]
Run the display ospf hostname-table command to check information about OSPF dynamic
hostnames.
<HUAWEI> display ospf hostname-table
Hostname table information

Area: 0.0.0.1
Router ID Hostname
1.2.3.4 RTR_BLR
10.1.1.1 RTR_SHANGHAI
255.255.255.254 RTR_BJI
Area: 0.0.0.2
Router ID Hostname
1.2.3.4 RTR_BLR
10.3.1.1 RTR_DELHI
AS-Scope
Router ID Hostname
10.2.1.1 RTR_SHENZHEN
255.255.255.254 RTR_BJI
5.7 Configuring an OSPF Stub Area

Configuring a non-backbone area as a stub area can reduce routing entries in the area in an AS
does not transmit routes learned from other areas in the AS or AS external routes. This reduces
bandwidth and storage resource consumption.
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. A stub area generally resides on the border of an AS. For
example, a non-backbone area with only one ABR can be configured as a stub area. In a stub
area, the number of entries in the routing table and the amount of routing information to be
transmitted greatly decrease.
Note the following points when configuring a stub area:
l The backbone area (Area 0) cannot be configured as a stub area.
l If an area needs to be configured as a stub area, all the routers in this area must be configured
with stub attributes using the stub command.
l An ASBR cannot exist in a stub area. External routes are not transmitted in the stub area.
l Virtual links cannot exist in the stub area.
Before configuring a stub area, complete the following tasks:
the network layer
Data Preparation
To configure a stub area, you need the following data.

No. Data
1 (Optional) Cost of the default route to the stub area

NOTE
By default, the cost of the default route to the stub area is 1.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
stub
The specified area is configured as a stub area.
NOTE
l All routers in a stub area must be configured with stub attributes using the stub command.
l Configuring or deleting stub attributes will update routing information in the area. Stub attributes can
be deleted or configured again only after the routing update is complete.

stub [ no-summary ]
The ABR is prevented from sending Type 3 LSAs to the stub area.

default-cost cost
The cost of the default route to the stub area is set.
To ensure the reachability of AS external routes, the ABR in the stub area generates a default
route and advertises the route to the non-ABR routers in the stub area.
By default, the cost of the default route to the stub area is 1.
----End

Run either of the following commands to check LSDB information.
l display ospf [ process-id ] lsdb [ brief ]

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

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

An NSSA is configured in the scenario where AS external routes are to be imported but not
forwarded to save system resources.
The NSSA is a new type of OSPF area. Neither the NSSA nor the stub area transmits routes
learned from other areas in the AS it resides. The stub area does not allow AS external routes to
be imported, whereas the NSSA allows AS external routes to be imported and forwarded in the
entire AS.
Type 7 LSAs are used to carry imported AS external routing information in the NSSA. Type 7
LSAs are generated by the ASBRs of NSSAs and flooded only in the NSSAs where ASBRs
reside. The ABR in an NSSA selects certain Type 7 LSAs from the received ones and translates
them into Type 5 LSAs to advertise AS external routing information to the other areas over the
OSPF network.
To configure an area as an NSSA, configure NSSA attributes on all the routers in this area.
Before configuring an NSSA, complete the following tasks:
the network layer
Data Preparation
To configure an NSSA, you need the following data.

No. Data
1 (Optional) Cost of the default route to the NSSA

NOTE
By default, the cost of the default route to the NSSA is 1.
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 | 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 All routers in the NSSA must be configured with NSSA attributes using the nssa command.
l Configuring or deleting NSSA attributes may trigger routing update in the area. A second configuration
of NSSA attributes can be implemented or canceled only after routing update is complete.
The nssa command is applicable to the following scenarios:
l The parameter default-route-advertise is used to advertise Type 7 LSAs carrying the default
route on the ABR or ASBR to the NSSA.
Type 7 LSAs carrying the default route will be generated regardless of whether the default
route 0.0.0.0 exists in the routing table on the ABR. On the ASBR, however, the default Type
7 LSA is generated only when the default route 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 routers in the area where LSAs are flooded will be reserved. These LSAs will be
deleted only when the aging time reaches 3600s. The router performance is affected because
the forwarding of a large number of LSAs consumes the memory resources. To resolve such
a problem, you can set the parameter flush-waiting-timer to the maximum value 3600s for
Type 5 LSAs so that the invalid Type 5 LSAs from other routers can be deleted in time.

NOTE
l When the LS age field value (aging time) in the header of an LSA reaches 3600s, the LSA is deleted.
l If an ASBR also functions as an ABR, flush-waiting-timer does not take effect. This prevents
Type 5 LSAs in the non-NSSAs from being deleted.
l If an ASBR also functions as an ABR, set the parameter no-import-route to prevent external
routes imported using the import-route command from being advertised to the NSSA.
l To reduce the number of LSAs that are transmitted to the NSSA, set the parameter no-
summary on an ABR. This prevents the ABR from transmitting Type 3 LSAs to the NSSA.
l After the parameter set-n-bit is configured, the router re-establishes neighbor relationships
with the neighboring routers in the NSSA.
l If multiple ABRs are deployed in the NSSA, the system automatically selects an ABR
(generally the router with the largest router ID) as a translator to translate Type 7 LSAs into
Type 5 LSAs. You can also configure the parameter translator-always on an ABR to specify
the ABR as an all-the-time translator. To specify two ABRs for load balancing, configure
the parameter translator-always on two ABRs to specify the ABRs as all-the-time
translators. This prevents LSA flooding caused by translator role changes.
l The parameter translator-interval is used to ensure uninterrupted services when translator
roles change. The interval-value value must be greater than the flooding period.
Step 5 (Optional)Run:
default-cost cost
The cost of the default route to the NSSA is set.
To ensure the reachability of AS external routes, the ABR in the NSSA generates a default route
and advertises the route to the other routers in the NSSA.
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 is 1.
----End

Run either of the following commands to check LSDB information.
l display ospf [ process-id ] lsdb [ brief ]

l display ospf [ process-id ] lsdb [ router | network | summary | asbr | ase | nssa | opaque-
link | opaque-area | opaque-as ] [ link-state-id ] [ originate-router [ advertising-router-
id ] | self-originate ]
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 ]



By configuring local multicast topology (MT), you can create a proper routing table for multicast
traffic when multicast and an MPLS TE tunnel are configured on a network.
When multicast and an MPLS TE tunnel are configured and the TE tunnel is configured with
IGP Shortcut, the outbound interface of the route calculated by an IGP is not a physical interface
but a TE tunnel interface. The router uses the TE tunnel interface to send multicast Join messages
through a unicast route to the multicast source address. The router through which the TE tunnel
passes, however, cannot detect the multicast Join messages. As a result, multicast forwarding
entries will not be created.
To resolve this problem, enable local MT. After local MT is enabled, if the outbound interface
of the calculated route is a TE tunnel interface of the IGP Shortcut type, the route management
(RM) module creates a separate MIGP routing table for the multicast protocol, calculates the
physical outbound interface for the route, and adds the physical interface to the MIGP routing
table for multicast forwarding.
Configuring filtering conditions for local MT controls the number of routing entries in an MIGP
routing table and speeds up the MIGP routing table lookup.
Before configuring local MT, complete the following tasks:
the network layer
l Configuring a TE tunnel for the OSPF process
Data Preparation
To configure local MT, you need the following data.
No. Data
1 (Optional) Filtering list used to filter MIGP routing information
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]

Step 3 Run:
local-mt enable
Local MT is enabled.
NOTE
l Local MT is applicable only to the OSPF process of a public network instance.

l Local MT does not support Forwarding Adjacency (FA).

1. Run:
local-mt filter-policy acl { acl-number | acl-name }
Configure a filtering policy for Local MT.

2. Run:
quit

3. Run:

4. Run:

1. Run:
local-mt filter-policy acl acl-name

2. Run:
quit

3. Run:
config } ]

4. Run:

Run:
local-mt filter-policy ip-prefix ip-prefix-name

After an MIGP routing table is created, OSPF calculates routes. When an IGP Shortcut-capable
TE tunnel interface is calculated as the outbound interface, the router saves the physical interface
on which the tunnel interface is configured as the outbound interface in the MIGP routing table
for multicast packet forwarding.
To control the number of entries in the MIGP routing table and speed up the MIGP routing table
search, configure filtering conditions to allow only the matching routes to the multicast source
address to be added to the MIGP routing table.
Multiple routes to a non-multicast source address may be added to a MIGP routing table, causing
the number of entries to exceed the upper limit. Therefore, configure a routing policy before
enabling local MT is recommended.
----End

l Run the display ospf [ process-id ] migp-routing [ ip-address [ mask | mask-length ] ]
[ interface interface-type interface-number ] [ nexthop nexthop-address ] command to
check the MIGP routing table information.
l Run the display ospf [ process-id ] routing command to check OSPF routing table
information.
l Run the display ospf [ process-id ] brief command to check brief OSPF information.
Run the following command to view information about the physical interface in the MIGP
routing table.
<HUAWEI> display ospf migp-routing
MIGP Routing Tables
Routing for Network

192.168.3.0/24 4 Stub 10.0.4.1 2.2.2.2 0.0.0.0
10.0.1.0/24 3 Stub 10.0.4.1 1.1.1.1 0.0.0.0
10.0.2.0/24 4 Stub 10.0.4.1 2.2.2.2 0.0.0.0
10.0.3.0/24 3 Transit 10.0.4.1 2.2.2.2 0.0.0.0
Total Nets: 4
5.10 Configuring BFD for OSPF

After BFD for OSPF is enabled, when a link fails, the router rapidly detects the failure, notifies
the OSPF process or interface of the fault, and instructs OSPF to recalculate routes. This speeds
up OSPF network convergence.

Before configuring BFD for OSPF, familiarize yourself with the usage scenario, complete the

OSPF enables the router to periodically send Hello packets to a neighboring router for fault
detection. Detecting a fault takes more than 1s. As technologies develop, voice, video, and other
VOD services are widely used. These services are quite sensitive to packet loss and delays. When
traffic is transmitted at gigabit rates, long-time fault detection will cause packet loss. This cannot
meet high reliability requirements of the carrier-class network.
BFD for OSPF is introduced to resolve this problem. After BFD for OSPF is configured in a
specified process or on a specified interface, the link status can be rapidly detected and fault
detection can be completed in milliseconds. This speeds up OSPF convergence when the link
status changes.
Before configuring BFD for OSPF, complete the following task:
the network layer
Data Preparation
To configure BFD for OSPF, you need the following data.
No. Data
1 Number of the OSPF process to be enabled with BFD for OSPF
2 Type and number of the interface to be enabled with BFD for OSPF
3 (Optional) Values of BFD session parameters

NOTE
The default parameter values are recommended.
5.10.2 Configuring BFD for OSPF in a Specified Process

Configuring BFD for OSPF in a specified process helps the system to rapidly detect the link
status and speeds up OSPF convergence in the case of a link failure.
Context
After BFD for OSPF is configured, when detecting a link fault, BFD rapidly notifies the
routers on both ends of the link of the fault, triggering rapid OSPF convergence. When the OSPF
neighbor relationship goes Down, the BFD session will be dynamically deleted.
Before configuring BFD for OSPF, enable BFD globally.
Perform the following steps on the routers between which a BFD session is to be created.

Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
BFD is globally configured.
Step 3 Run:
quit
Step 4 Run:
ospf [ process-id ]
Step 5 Run:
BFD for OSPF is configured. The default parameter values are used to create a 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 all the
interfaces in the process.

bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value | frr-binding } *
BFD session parameters are modified.
You can skip this step. The default interval at which BFD packets are transmitted and the default
detection multiplier are recommended.
The parameters are configured based on the network status and network reliability requirements.
A short interval at which BFD packets are transmitted can be configured for a link that has a
higher requirement for reliability. A long interval at which BFD packets are transmitted can be
configured for a link that has a lower requirement for reliability.

NOTE
l Actual interval at which BFD packets are transmitted on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local router, configured interval receive-
interval at which BFD packets are received on the peer router }
l Actual interval at which BFD packets are received on the local router = Max { configured interval transmit-
interval at which BFD packets are transmitted on the peer router, configured interval receive-interval at
which BFD packets are received on the local router }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
router x Configured detection multiplier multiplier-value on the peer router
For example:
l On the local router, the configured interval at which BFD packets are transmitted is 200 ms; the configured
interval at which BFD packets are received is 300 ms; the detection multiplier is 4.
l On the peer router, the configured interval at which BFD packets are transmitted is 100 ms; the interval at
which BFD packets are received is 600 ms; the detection multiplier is 5.
Then:
l On the local router, the actual interval at which BFD packets are transmitted is 600 ms calculated by using
the formula max {200 ms, 600 ms}; the interval at which BFD packets are received is 300 ms calculated by
using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by multiplying 300
ms by 5.
l On the peer router, the actual interval at which BFD packets are transmitted is 300 ms calculated by using
the formula max {100 ms, 300 ms}, the actual interval at which BFD packets are received is 600 ms calculated
by using the formula max {200 ms, 600 ms}, and the detection period is 2400 ms calculated by multiplying
600 ms by 4.
Step 7 (Optional) Prevent an interface from dynamically creating a BFD session.

After BFD for OSPF is configured, all interfaces on which neighbor relationships are Full in the
OSPF process will create BFD sessions. To prevent specific interfaces from being enabled with
BFD, disable these interfaces from dynamically creating BFD sessions.
1. Run:
quit

2. Run:

3. Run:
ospf bfd block
An interface is prevented from dynamically creating a BFD session.
----End
5.10.3 Configuring BFD for OSPF on a Specified Interface

Configuring BFD for OSPF on a specified interface helps speed up OSPF convergence in the
case of an interface failure.
Context
After BFD for OSPF is configured on a specified interface and the interface becomes faulty, the
router rapidly detects the fault and instructs OSPF to recalculate routes. This speeds up OSPF

convergence. When the OSPF neighbor relationship goes Down, the BFD session between OSPF
neighbors is dynamically deleted.
Before configuring BFD for OSPF, enable BFD globally.
Perform the following steps on the router:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Step 3 Run:
quit
Step 4 Run:
Step 5 Run:
ospf bfd enable
BFD for OSPF is configured. The default parameter values are used to create a 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.

ospf bfd { min-rx-interval receive-interval | min-tx-interval transmit-interval |
detect-multiplier multiplier-value | frr-binding } *

NOTE
l Actual interval at which BFD packets are transmitted on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local router, configured interval receive-
interval at which BFD packets are received on the peer router }
l Actual interval at which BFD packets are received on the local router = Max { configured interval transmit-
interval at which BFD packets are transmitted on the peer router, configured interval receive-interval at
which BFD packets are received on the local router }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
router x Configured detection multiplier multiplier-value on the peer router
For example:
l On the local router, the configured interval at which BFD packets are transmitted is 200 ms; the configured
interval at which BFD packets are received is 300 ms; the detection multiplier is 4.
l On the peer router, the configured interval at which BFD packets are transmitted is 100 ms; the interval at
which BFD packets are received is 600 ms; the detection multiplier is 5.
Then:
l On the local router, the actual interval at which BFD packets are transmitted is 600 ms calculated by using
the formula max {200 ms, 600 ms}; the interval at which BFD packets are received is 300 ms calculated by
using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by multiplying 300
ms by 5.
l On the peer router, the actual interval at which BFD packets are transmitted is 300 ms calculated by using
the formula max {100 ms, 300 ms}, the actual interval at which BFD packets are received is 600 ms calculated
by using the formula max {200 ms, 600 ms}, and the detection period is 2400 ms calculated by multiplying
600 ms by 4.
----End

After configuring BFD for OSPF, you can view information about the BFD session between
two OSPF neighbors.
Prerequisites
All BFD for OSPF configurations have been configured.
Procedure
l Run the display ospf [ process-id ] bfd session interface-type interface-number [ router-
id ] or display ospf [ process-id ] bfd session { router-id | all } command to check
information about the BFD session between two OSPF neighbors.
----End
Example
If the BFD session is successfully created, information about BFD for OSPF shows that the BFD
session is Up on the local router.
<HUAWEI> display ospf bfd session all
NeighborId:2.2.2.2 AreaId:0.0.0.0 Interface:Pos1/0/0

BFDState:up rx :1000 tx :100

Multiplier:3 BFD Local Dis:8194 LocalIpAdd:10.2.1.2

RemoteIpAdd:10.2.1.1 Diagnostic Info: Init
5.11 Configuring OSPF IP FRR

With OSPF IP FRR, devices can rapidly switch traffic from faulty links to backup links without
interrupting traffic. This protects traffic and greatly improves the reliability of OSPF networks.

Before configuring OSPF IP FRR, familiarize yourself with the usage scenario, complete the
With the development of networks, Voice over IP (VoIP) and on-line video services require
high-quality real-time transmission. Nevertheless, if an OSPF fault occurs, traffic can be
switched to a new link only after the following processes: fault detection at the millisecond level,
notifying the fault to the routing control plane at the millisecond level, generating and flooding
new topology information at the tens of milliseconds level, triggering SPF calculation at the tens
of milliseconds level, and notifying and installing a new route at the hundreds-of-milliseconds
level. As a result, it takes much more than 50 ms to recovery the link from the fault, which cannot
meet the requirement for real-time services on the network.
With OSPF IP FRR that calculates a backup link in advance, devices can fast switch traffic to
the backup link without interrupting traffic when the primary link becomes faulty. This protects
traffic and therefore greatly improves the reliability of OSPF networks.
OSPF IP FRR is applicable to the services that are sensitive to packet delay and packet loss.
Before configuring OSPF IP FRR, complete the following tasks:
the network layer
Data Preparation
To configure OSPF IP FRR, you need the following data.
No. Data
1 OSPF process ID
2 (Optional) Cost of the interface
3 (Optional) BFD parameters
4 (Optional) Name of the route policy

5.11.2 Enabling OSPF IP FRR

This section describes how to enable OSPF IP FRR to generate a loop-free backup link. If the
primary link fails, OSPF can fast switch traffic to the backup link.
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 started, and the OSPF view is displayed.
Step 3 Run:
frr
The OSPF IP FRR view is displayed.
Step 4 Run:
loop-free-alternate
OSPF IP FRR is enabled to generate a loop-free backup link.
NOTE
OSPF can generate the loop-free backup link only when the OSPF IP FRR traffic protection inequality is
met.

frr-priority static low
The Loop-Free Alternates (LFA) algorithm is used to calculate the nexthop and outbound
interface for a backup link.
The nexthop and outbound interface of an OSPF loop-free backup link can be obtained using
either of the following methods:
l For a static backup link, after IP FRR is enabled using the ip frr command in the system
view or VPN instance view, configure a nexthop and an outbound interface for the static
backup link.
l For a dynamic backup link, after OSPF IP FRR is enabled using the loop-free-alternate
command, enable the device to use the LFA algorithm to calculate the nexthop and outbound
interface for the dynamic backup link.
By default, static backup links take preference over dynamic backup links during route selection.
However, static backup links are less flexible than dynamic backup links. If a link failure occurs,
static backup links cannot update automatically, but dynamic backup links can. Therefore, to
ensure automatic link updates, run the frr-priority static low command to enable dynamic
backup links to take preference over static backup links so that the LFA algorithm is used to
calculate the nexthop and outbound interface.

frr-policy route route-policy route-policy-name

OSPF IP FRR filtering policies are configured.
After OSPF IP FRR filtering policies are configured, only the OSPF backup routes that match
the filtering conditions can be delivered to the forwarding table. To protect the traffic over a
specific OSPF route, you can configure a filtering policy that matches the OSPF route to ensure
that the route can be added to the forwarding table. If this route fails, OSPF can fast switch the
traffic to a backup link.
----End
5.11.3 (Optional) Binding OSPF IP FRR and BFD

This section describes how to bind OSPF IP FRR and BFD so that link faults can be detected
rapidly. This ensures that traffic is rapidly switched to the backup link in the case of link failures.
Context
During the configuration of OSPF IP FRR, the lower layer needs to fast respond to the link
change so that traffic can be rapidly switched to the backup link in the case of a link failure.
Bind BFD to the link status so that link faults can be detected rapidly. This ensures that traffic
is rapidly switched to the backup link in the case of link failures.
Binding OSPF IP FRR and BFD can configure in a specified process or on a specified interface.
The priority of BFD configured on an interface is higher than that of BFD configured in an OSPF
process. If BFD is enabled on an interface, a BFD session is established according to the BFD
parameters set on the interface.
Procedure
l Binding OSPF IP FRR and BFD in a specified process .
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

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

5. Run:
BFD is enabled in an OSPF process.

6. Run:
bfd all-interfaces frr-binding

IP FRR is bound to BFD in an OSPF process.

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

2. Run:
bfd

3. Run:
quit

4. Run:

5. Run:
ospf bfd enable
The BFD on the specified interface is enabled with OSPF.

6. Run:
ospf bfd frr-binding
IP FRR is bound to BFD on the OSPF interface.
----End
5.11.4 (Optional) Disabling OSPF IP FRR on an Interface

OSPF IP FRR can be disabled on an interface of a specific device that is running important
services and resides on an FRR backup link. This setting prevents the device connected to this
interface from being a part of a backup link and being burdened after FRR switches traffic to
the backup link.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the OSPF IP FRR-enabled interface is displayed.
Step 3 Run:
ospf frr block
The OSPF IP FRR function is disabled on the specified interface.
----End


After configuring OSPF IP FRR, you can view route information.
Prerequisites
All OSPF IP FRR configurations have been configured.
Procedure
l Run the display ospf [ process-id ] routing command to check information about the
primary and backup links after OSPF IP FRR is enabled.
----End
Example
View the routes to the specified OSPF device.
<HUAWEI> display ospf routing router-id 2.2.2.2
Destination : 2.2.2.2 Route Type : Intra-area

Area : 0.0.0.0 AdvRouter : 2.2.2.2
Type : Normal Age : 17h03m33s
URT Cost : 1
NextHop : 10.0.0.2 Interface : GigabitEthernet0/3/1
Backup NextHop : 10.0.0.3 Backup Interface : GigabitEthernet0/3/0
Backup Type : LFA LINK-NODE
The preceding display shows that a backup route is generated on Router, including information
about the backup next hop: Backup NextHop is address of the backup next hop, Backup
Interface is outbound interface of the backup next hop, Backup Type is type of the backup next
hop.
5.12 Configuring OSPF GR

This section describes how to configure OSPF GR to avoid traffic interruption and route flapping
caused by the active/standby switchover.

Before configuring OSPF GR, familiarize yourself with the usage scenario, complete the pre-
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 Graceful Restart (GR), the Restarter and the Helper
reestablish the neighbor relationship, exchange routing information, synchronize the LSDB, and
update the routing table and forwarding table. These operations ensure the fast convergence of
OSPF and the stability the network topology.

NOTE
In practical applications, you can configure OSPF GR on the dual main control boards to avoid service
forwarding from being affected by the fault occurred on the main control board.
Before configuring OSPF GR, complete the following tasks:
the network layer
Data Preparation
To configure OSPF GR, you need the following data.
No. Data
1 OSPF process number
2 (Optional) Parameters for establishing GR sessions

NOTE
The default parameter values are recommended.
5.12.2 Enabling OSPF GR

Enabling OSPF GR to ensure the fast convergence of OSPF and the stability the network
topology.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
The OSPF view is displayed.

Step 3 Run:
The opaque-LSA function is enabled.

Opaque LSAs provide a generic mechanism for OSPF extension:
l OSPF supports GR using Type 9 LSAs.
l OSPF supports TE using Type 10 LSAs.
Before configuring OSPF GR, you must enable opaque LSA capability running the opaque-
capability enable command.

NOTE
When enabling or disabling the opaque LSA function, OSPF process will go down in order to renegotiate
the new capability, which means that the traffic will be affected for few seconds.
Step 4 Run:
graceful-restart
The OSPF GR feature is enabled.
After the graceful-restart command is run to enable GR for a router, the Helper function is also
enabled.
NOTE
ATN device can only be used as a GR Helper and not be used as a GR Restarter.
----End
5.12.3 (Optional) Configuring the GR Session Parameters on the

Restarter
This part describes how to set GR session parameters (including GR period, planned GR, and
totally GR) 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 are 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 the planned GR. By default, the Restarter
supports both the planned GR and unplanned GR.
l Set partial, the Restarter supports the partial GR. By default, the Restarter supports the totally
GR.
----End
5.12.4 (Optional) Configuring GR Session Parameters on the Helper

This part describes how to set GR session parameters (including the filtering policies, checks
the LSAs outside the AS, and Planned GR) on the Helper.

Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]

1. Run:
graceful-restart [ { period period } | partial | planned-only ] * helper-
role { { { acl-number acl-number | acl-name acl-name } | ignore-external-
lsa | planned-only } * | never }

2. Run:
quit

3. Run:

4. Run:

1. Run:
graceful-restart [ { period period } | partial | planned-only ] * helper-
role { { acl-name acl-name | ignore-external-lsa | planned-only } * |
never }

2. Run:
quit

3. Run:
config } ]

4. Run:


Run:
graceful-restart [ { period period } | partial | planned-only ] * helper-role
{ { ip-prefix ip-prefix-name | ignore-external-lsa | planned-only } * | never }

NOTE
l Set ignore-external-lsa, the Helper does not check the LSAs outside the AS (AS-external LSA). By
default, the Helper checks the LSAs outside the AS.
l Set planned-only, the Helper supports only the planned GR. By default, the Helper supports both the
planned GR and unplanned GR.
l Set never, the router does not support the Helper mode.
----End

After configuring OSPF GR, check the OSPF GR status.
Prerequisites
The OSPF GR has been configured.
Procedure
l Run the display ospf [ process-id ] graceful-restart [ verbose ] command to check the
restart status of OSPF GR.
----End
Example
Run the display ospf graceful-restart command. If the OSPF GR configuration is displayed,
it means that the configuration succeeds. For example:
<HUAWEI> 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 : successful exit
On Helper : none

5.13 Improving Security of an OSPF Network

On a network demanding high security, you can adopt the GTSM mechanism and configure
OSPF authentication to improve the security of the OSPF network.

Before improving the security of an OSPF network, familiarize yourself with the usage scenario,
complete pre-configuration tasks, and obtain the required data. This can help you complete the
In a network demanding high security, you can configure OSPF authentication and adopt the
GTSM mechanism to improve the security of the OSPF network.
The GTSM mechanism defends against attacks by checking the TTL value. If an attacker keeps
sending packets to a router by simulating real OSPF unicast packets, the router finds itself is the
destination of the packets after the interface board receives these packets. The router directly
sends the packets to the control plane for OSPF processing without checking the validity of the
packets. The router busies itself with processing these "valid" packets. As a result, the system
is busy, and the CPU is highly occupied.
The GTSM mechanism protects a router by checking whether the TTL value in the IP packet
header is in a pre-defined range to enhance the system security.
NOTE
l NE80E/40E supports IPv4 OSPF GTSM.

l 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:
l Configuring IP addresses for interfaces to make neighboring nodes reachable

Data Preparation
To improve the security of an OSPF network, you need the following data.
No. Data
1 OSPF process ID
2 (Optional) Names of VPN instances of OSPF
3 (Optional) TTL value to be checked
4 ID of an OSPF area that needs to be configured with authentication

No. Data
5 Number of an OSPF interface that needs to be configured with authentication
6 Authentication mode and password
5.13.2 Configuring the OSPF GTSM Functions

The GTSM defends against attacks by checking the TTL value.
Context
To apply GTSM functions, enable GTSM on the two ends of the OSPF connection.
The valid TTL range of the detected packets is [255 -hops + 1, 255].
GTSM checks the TTL value of only the packet that matches the GTSM policy. For the packets
that do not match the GTSM policy, you can set them as "pass" or "drop". If the GTSM default
action performed on the packet is set as "drop", you need to configure all the router connections
for GTSM. If the packets sent from a router do not match the GTSM policy, they are dropped.
The connection therefore cannot be established. This ensures security but reduces the ease of
use.
You can enable the log function to record the information that the packets are dropped. This is
convenient for fault location.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf valid-ttl-hops hops [ vpn-instance vpn-instance-name ]
OSPF GTSM functions are configured.
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.
Therefore, if the private network policy or the public network policy is configured only, it is recommended
to set the default action performed on the packets that do not match the GTSM policy as pass. This prevents
the OSPF packets of other processes from being discarded incorrectly.
The parameter vpn-instance is valid only for the latter function.
Therefore, if the private network policy or the public network policy is configured only, it is
recommended to set the default action performed on the packets that do not match the GTSM

policy as pass. This prevents the OSPF packets of other processes from being discarded
incorrectly.

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

gtsm log drop-packet { slot-id | all }
The log function is enabled on the specified board in the system view. The information that
GTSM drops packets is recorded in the log.
----End
5.13.3 Configuring the Authentication Mode

OSPF supports packet authentication. Only the packets that pass the authentication can be
received. If packets fail to pass the authentication, the neighbor relationship cannot be
established.
Context
In area authentication, all the routers in an area must use the same area authentication mode and
password. For example, the authentication mode of all devices in Area 0 is simple authentication
and the password is abc.
The interface authentication mode is used among neighbor routers to set the authentication mode
and password. Its priority is higher than that of the area authentication mode.
NOTE
By default, authentication is not configured for OSPF area or interface. Configuring area authentication is
recommended to ensure system security.
Procedure
l Configuring the Area Authentication Mode
1. Run:
system-view

2. Run:
ospf [ process-id ]

3. Run:
area area-id

4. Run the following commands to configure the authentication mode of the OSPF area
as required:
– Run:
authentication-mode simple [ plain plain-text | [ cipher ] cipher-
text ]
The simple authentication is configured for the OSPF area.

– Run:
authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain
plain-text | [ cipher ] cipher-text } ]
The MD5 authentication is configured for the OSPF area.

OSPF supports packet authentication. Only the OSPF packets passing the
authentication can be received; otherwise, the neighbor relationship cannot be
established normally.
All the routers in an area must agree on the same area authentication mode and
password. For example, the authentication mode of all routers in area 0 is simple
authentication, and the password is abc.
– Run:
authentication-mode keychain keychain-name
The Keychain authentication is configured for the OSPF area.

NOTE
Before using the Keychain authentication, you must run the keychain command to create
a keychain. Then, run the key-id, key-string, and algorithm commands to configure a key
ID, a password, and an authentication algorithm for this keychain. Otherwise, the OSPF
authentication will fail.
l Configuring the Interface Authentication Mode
1. Run:
system-view

2. Run:

3. Run the following commands to configure the interface authentication mode as
required:
– Run:
ospf authentication-mode simple [ plain plain-text | [ cipher ] cipher-
text ]
The simple authentication is configured for the OSPF interface.

– Run:
ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id
{ plain plain-text | [ cipher ] cipher-text } ]
The MD5 authentication is configured for the OSPF interface.

– Run:
ospf authentication-mode null
The non-authentication mode is configured for the OSPF interface.

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

NOTE
Before using the Keychain authentication, you must run the keychain command to create
a keychain. Then, run the key-id, key-string, and algorithm commands to configure a key
ID, a password, and an authentication algorithm for this keychain. Otherwise, the OSPF
authentication will fail.
The authentication mode and password of interfaces in the same network segment
must be consistent except the Keychain authentication mode. If the interfaces are in
different network segments, the authentication mode and password of the interfaces
can be different.
----End

After configuring OSPF features, check GTSM statistics and brief statistics.
Prerequisites
Improving Security of an OSPF Network has been configured.
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
Example
Run the display gtsm statistics command. If the GTSM statistics on each slot, including the
total number of OSPF packets, the number of passed packets, and the number of dropped packets,
are displayed, it means that the configuration succeeds. For example:
<HUAWEI> display gtsm statistics all
GTSM Statistics Table
----------------------------------------------------------------
SlotId Protocol Total Counters Drop Counters Pass Counters
----------------------------------------------------------------
0 BGP 0 0 0
0 BGPv6 0 0 0
0 OSPF 0 0 0
0 LDP 0 0 0
0 OSPFv3 0 0 0
0 RIP 0 0 0
----------------------------------------------------------------

5.14 Configuring the Network Management Function of

OSPF
OSPF supports the network management function. You can bind the OSPF MIB to a certain
OSPF process, and configure the trap function and log function.

Before configuring the network management function for OSPF, familiarize yourself with the
usage scenario, complete pre-configuration tasks, and obtain the required data. This can help
you complete the configuration task quickly and accurately.
OSPF supports the network management function. You can bind OSPF MIB and a certain OSPF
process. In addition, OSPF also supports the trap function and the log function.
Before configuring the network management function of OSPF, complete the following tasks:

Data Preparation
To configure the network management function of OSPF, you need the following data.
No. Data
1 OSPF process ID
5.14.2 Configuring OSPF MIB Binding

The MIB is a virtual database of the device status maintained by the managed devices.
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.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf mib-binding process-id
OSPF MIB binding is configured.
----End
5.14.3 Configuring OSPF Trap

Traps are the notifications sent from a router to inform the NMS of the fault detected by the
system.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable feature-name ospf { non-excessive all | [ trap-name
{ hwospfv2intraareadripaddressconflict | hwospfv2intraarearouteridconflict |
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 all non-excessive traps of OSPF module, you can run the non-excessiveall command;
to enable the traps of one or more events, you can specify type-name.
----End
5.14.4 Configuring OSPF Log

Logs record the operations (such as configuring commands) and specific events (such as the
network connection failure) on routers.
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

After the network management function is configured for OSPF, you can check the contents of
the information channel, information recorded in the information center, log buffer, and trap
buffer.
Prerequisites
The network management function of OSPF has been configured.
Procedure
l Run the display ospf [ process-id ] brief command to view information about the binding
of OSPF MIBs and OSPF processes.
l Run the display snmp-agent trap feature-name ospf all command to view all trap
messages of the OSPF module.
----End
5.15 Maintaining OSPF

Maintaining OSPF involves resetting OSPF and clearing OSPF statistics.
5.15.1 Resetting OSPF

Restarting OSPF can reset OSPF. In addition, you can reset OSPF through GR.
Context
NOTICE
The OSPF neighbor relationship is deleted after you reset OSPF connections with the reset
ospf command. Exercise caution when running this command.
To reset OSPF connections, run the following reset ospf commands in the user view.
Procedure
l Run the reset ospf process command to Restart the OSPF process.
After the reset ospf process command is used to restart OSPF, the following situations
may occur:
– If the router ID is changed, a new router ID will take affect after the reset ospf
process command is run.

– Re-elect DR and BDR after the reset ospf process command is run.
l Run the reset ospf process flush-waiting-timer time command to clear invalid LSAs
within the set time before LSAs time out.
l Run the reset ospf [ process-id ] process [ graceful-restart ] command to Restart the OSPF
process in GR mode.
----End
5.15.2 Clearing OSPF

This section describes how to clear OSPF statistics, including OSPF counters, imported
routes, and GTSM statistics on the board.
Context
NOTICE
OSPF information cannot be restored after being cleared. Exercise caution when running this
command.
To clear the OSPF information, run the following reset ospf commands in the user view.
Procedure
l Run the reset ospf [ process-id ] counters [ neighbor [ interface-type interface-number ]
[ router-id ] ] command in the user view to clear OSPF counters.
l Run the reset ospf [ process-id ] redistribution command in the user view to clear the
routes imported by OSPF.
l Run the reset gtsm statistics { slot-id | all } command in the user view to clear the GTSM
statistics on the board.
----End

This section provides several configuration examples of OSPF together with the Networking
Follow-up Procedure
NOTE
This document takes interface numbers and link types of the NE40E-X8 as an example. In working
situations, the actual interface numbers and link types may be different from those used in this document.
5.16.1 Example for Configuring Basic OSPF Functions

This section provides an example for configuring basic OSPF functions. Detailed operations
include enabling OSPF on each router and specifying network segments in different areas.

As shown in Figure 5-6, all routers run OSPF, and the entire AS is partitioned into three areas.
Router A and Router B function as ABRs to forward routing information between areas.
After the configuration is complete, each router must learn the routes to all network segments
in the AS.
Figure 5-6 Networking diagram of configuring basic OSPF functions
Area0
POS1/0/0
192.168.0.2/24
RouterA POS1/0/0 RouterB
POS2/0/0 192.168.0.1/24 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 Area2
1. Enable OSPF on each router.

2. Specify network segments in different areas.
Data Preparation
l Router ID 1.1.1.1 of Router A; OSPF process ID 1; network segment 192.168.0.0/24 of

Area 0; network segment 192.168.1.0/24 of Area 1
l Router ID 2.2.2.2 of Router B; OSPF process ID 1; network segment 192.168.0.0/24 of
l Router ID 3.3.3.3 of Router C; OSPF process ID 1; network segments 192.168.1.0/24 and
172.16.1.0/24 of Area 1
l Router ID 4.4.4.4 of Router D; OSPF process ID 1; network segments 192.168.2.0/24 and
172.17.1.0/24 of Area 2
l Router ID 5.5.5.5 of Router E; OSPF process ID 1; network segment 172.16.1.0/24 of Area
1

l Router ID 6.6.6.6 of Router F; OSPF process ID 1; network segment 172.17.1.0/24 of Area

2
Procedure
Step 1 Configure an IP address for each interface. The configuration details are not provided here.
Step 2 Configure basic OSPF functions.
[RouterA] router id 1.1.1.1
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterB] router id 2.2.2.2
[RouterB] ospf
[RouterC] router id 3.3.3.3
[RouterC] ospf
[RouterD] router id 4.4.4.4
[RouterD] ospf
[RouterD-ospf-1] area 2
[RouterD-ospf-1-area-0.0.0.2] network 192.168.2.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.2] quit
# Configure Router E.
[RouterE] router id 5.5.5.5
[RouterE] ospf
[RouterE-ospf-1] area 1
[RouterE-ospf-1-area-0.0.0.1] network 172.16.1.0 0.0.0.255
[RouterE-ospf-1-area-0.0.0.1] quit
# Configure Router F.
[RouterF] router id 6.6.6.6
[RouterF] ospf
[RouterF-ospf-1] area 2
[RouterF-ospf-1-area-0.0.0.2] network 172.17.1.0 0.0.0.255
[RouterF-ospf-1-area-0.0.0.2] quit


# Check information about OSPF neighbors of Router A.
[RouterA] display ospf peer
Neighbors
Area 0.0.0.0 interface 192.168.0.1(Pos1/0/0)'s neighbors
Router ID: 2.2.2.2 Address: 192.168.0.2
State: Full Mode:Nbr is Master Priority: 1
DR: None BDR: None MTU: 0
Neighbors
# Check the OSPF routes on Router A.

[RouterA] display ospf routing
Routing Tables
Routing for Network
172.16.1.0/24 2 Transit 192.168.1.2 3.3.3.3 0.0.0.1
172.17.1.0/24 3 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
192.168.0.0/24 1 Stub 192.168.0.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Stub 192.168.1.1 1.1.1.1 0.0.0.1
192.168.2.0/24 2 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
Total Nets: 5
# Check the LSDB on Router A.

[RouterA] display ospf lsdb
Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 2.2.2.2 2.2.2.2 317 48 80000003 1
Router 1.1.1.1 1.1.1.1 316 48 80000002 1
Sum-Net 172.16.1.0 1.1.1.1 250 28 80000001 2
Sum-Net 172.17.1.0 2.2.2.2 203 28 80000001 2
Sum-Net 192.168.2.0 2.2.2.2 237 28 80000002 1
Sum-Net 192.168.1.0 1.1.1.1 295 28 80000002 1
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 5.5.5.5 5.5.5.5 214 36 80000004 1
Router 3.3.3.3 3.3.3.3 217 60 80000008 1
Router 1.1.1.1 1.1.1.1 289 48 80000002 1
Network 172.16.1.1 3.3.3.3 670 32 80000001 0
Sum-Net 172.17.1.0 1.1.1.1 202 28 80000001 3
Sum-Net 192.168.2.0 1.1.1.1 242 28 80000001 2
Sum-Net 192.168.0.0 1.1.1.1 300 28 80000001 1
# Check the routing table on Router D and perform the ping operation to test the connectivity.
[RouterD] display ospf routing
Routing Tables

Routing for Network

172.16.1.0/24 4 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
172.17.1.0/24 1 Transit 172.17.1.1 4.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.2.0/24 1 Stub 192.168.2.2 4.4.4.4 0.0.0.2
Total Nets: 5
[RouterD] ping 172.16.1.1
0.00% packet loss
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
#

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

#
sysname RouterC
#
router id 3.3.3.3
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
undo shutdown
ip address 172.17.1.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
return
l Configuration file of Router E

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

l Configuration file of Router F

#
sysname RouterF
#
router id 6.6.6.6
#
undo shutdown
ip address 172.17.1.2 255.255.255.0
#
ospf 1
area 0.0.0.2
network 172.17.1.0 0.0.0.255
#
return
5.16.2 Example for Configuring OSPF Virtual Links

This section provides an example for configuring virtual links to connect a non-backbone area
to the backbone area.
As shown in Figure 5-7, Area 2 is not directly connected to the backbone area Area 0. Area 1
serves as a transit area to connect Area 2 and Area 0. A virtual link is configured between
Router A and Router B.
Figure 5-7 Networking diagram of configuring OSPF virtual links
Area1
POS1/0/0 POS1/0/0
RouterA 192.168.1.1/24 192.168.1.2/24 RouterB
GE2/0/0 Virtual Link GE2/0/0

10.1.1.1/8 172.16.1.1/16
GE2/0/0 GE2/0/0
10.1.1.2/8 172.16.1.2/16
RouterC RouterD
Area0 Area2
1. Configure basic OSPF functions on each router.
2. Configure a virtual link between Router A and Router B to connect a non-backbone area
to the backbone area.
Data Preparation


l Router ID 3.3.3.3 of Router C; OSPF process ID 1; network segment 10.0.0.0/8 of Area 0
l Router ID 4.4.4.4 of Router D; OSPF process ID 1; network segment 172.16.0.0/16 of Area
2
Procedure
Step 1 Assign an IP address to each interface.
For details about the configuration, see the configuration files.
Configuring Basic OSPF Functionsshows how to configure basic OSPF functions. For details
about the configuration, see the configuration files.
Step 3 Check the routing table on Router A.

Routing Tables
Routing for Network

10.0.0.0/8 1 Transit 10.1.1.1 3.3.3.3 0.0.0.0
192.168.1.0/24 1 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 2
The routing table on Router A contains no route in Area 2 because Area 2 is not directly
connected to Area 0.
Step 4 Configure a virtual link.
[RouterA] ospf 1
[RouterA-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[RouterB] ospf 1
[RouterB-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1


Routing Tables
Routing for Network

172.16.0.0/16 2 Inter-area 192.168.1.2 2.2.2.2 0.0.0.2
10.0.0.0/8 1 Transit 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 3
After the virtual link is configured, the routing table on Router A contains routes in Area 2.
----End
Configuration Files
#
sysname RouterA
#
undo shutdown
ip address 10.1.1.1 255.0.0.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1 router-id 1.1.1.1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 2.2.2.2
#
return

#
sysname RouterB
#
undo shutdown
ip address 172.16.1.1 255.255.0.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 1.1.1.1
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
return

#
sysname RouterC
#

undo shutdown
ip address 10.1.1.2 255.0.0.0
#
area 0.0.0.0
network 10.0.0.0 0.255.255.255
#
return

#
sysname RouterD
#
undo shutdown
ip address 172.16.1.2 255.255.0.0
#
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
return
5.16.3 Example for Configuring DR Election of OSPF

This part provides an example for setting the DR priority on an interface for DR election on a
broadcast network.
As shown in Figure 5-8, Router A has the highest priority (100) in the network and therefore is
elected as the DR. Router C has the second highest priority, and is elected as the BDR. The
priority of Router B is 0, and therefore Router B cannot be elected as the DR or BDR. The priority
of Router D is not configured and its default value is 1.
Figure 5-8 Configuring DR election of OSPF

RouterA RouterB
GE1/0/0 GE1/0/0
192.168.1.1/24 192.168.1.2/24
GE1/0/0 GE1/0/0
192.168.1.3/24 192.168.1.4/24
RouterC RouterD
1. Configure the router ID on each router, enable OSPF, and specify the network segment.
2. Check the DR/BDR status of each router with the default priority.

3. Configure the DR priority of the interface and check the DR/BDR status.
Data Preparation
l The router ID of Router A is 1.1.1.1 and the DR priority is 100.
l The router ID of Router B is 2.2.2.2 and the DR priority is 0.
l The router ID of Router C is 3.3.3.3 and the DR priority is 2.
l The router ID of Router D is 4.4.4.4 and the DR priority is 1.
Procedure
This example assumes that you know the configuration method and no details are provided here.
[RouterA] ospf
[RouterB] ospf
[RouterC] ospf
[RouterD] ospf
# View the DR/BDR status.

[RouterA] display ospf peer
Neighbors
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

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

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

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

Step 4 Restart OSPF processes.
In the user view of each router, run the reset ospf1process command to restart the OSPF process.
Step 5 View the configuration.
# View the status of OSPF neighbors.

[RouterD] display ospf peer
Neighbors
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
# View the status of the OSPF interface.

[RouterA] display ospf interface

Interfaces
Area: 0.0.0.0 (MPLS TE not enabled)

IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 100 192.168.1.1 192.168.1.3
[RouterB] display ospf interface

Interfaces
Area: 0.0.0.0 (MPLS TE not enabled)

IP Address Type State Cost Pri DR BDR
192.168.1.2 Broadcast DROther 1 0 192.168.1.1 192.168.1.3
If all neighbors are in the Full state, it indicates that Router A establishes the neighbor
relationship with its neighbor. If the neighbor stays "2-Way", it indicates both of them are not
the DR or BDR. Therefore, they need not exchange LSAs.
If the status of the OSPF interface is DROther, it indicates that it is neither DR nor BDR.
----End

Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
ospf dr-priority 100
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

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

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

#
sysname RouterD
#
router id 4.4.4.4
#
undo shutdown
ip address 192.168.1.4 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255

#
return
5.16.4 Example for Configuring OSPF Load Balancing

This part provides an example for configuring OSPF load balancing. Detailed operations include
enabling load balancing, setting the priority for equal-cost routes, and configuring the load
balancing mode.
l Router A, Router B, Router C, Router D, and Router E are interconnected to each other
through OSPF.
l Router A, Router B, Router C, Router D, and Router E belong to Area 0.
l Load balancing is required to transmit the traffic of Router A to Router E through Router
C and Router D.
Figure 5-9 Networking diagram of configuring OSPF load balancing
Area0
POS1/0/0 POS2/0/0
RouterB
POS1/0/0 POS1/0/0
GE4/0/0 POS2/0/0 POS2/0/0 GE4/0/0
RouterA POS1/0/0 POS2/0/0 RouterE
POS3/0/0 RouterC POS3/0/0
POS1/0/0 POS2/0/0
RouterD
RouterA POS1/0/0 10.1.1.1/24 RouterC POS1/0/0 10.1.2.2/24
POS2/0/0 10.1.2.1/24 POS2/0/0 192.168.1.1/

24
POS3/0/0 10.1.3.1/24 RouterD POS1/0/0 10.1.3.2/24
GE4/0/0 172.16.1.1./ POS2/0/0 192.168.2.1/

24 24
RouterB POS1/0/0 10.1.1.2/24 RouterE POS1/0/0 192.168.0.2/

24

POS2/0/0 192.168.1.2/
24
POS2/0/0 192.168.0.1/ POS3/0/0 192.168.2.2/

24 24
GE4/0/0 172.17.1.1/2
4
1. Enable basic OSPF functions on each router.

2. Configure load balancing on Router A.
3. Configure the priority for equal-cost routes on Router A.
Data Preparation
l For Router A, the router ID is 1.1.1.1, the OSPF process number is 1, and the network
segment of Area 0 is 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, and 172.16.1.0/24.
l For Router B, the router ID is 2.2.2.2, the OSPF process number is 1, and the network
segment of Area 0 is 10.1.1.0/8 and 192.168.0.0/8.
l For Router C, the router ID is 3.3.3.3, the OSPF process number is 1, and the network
l For Router D, the router ID is 4.4.4.4, the OSPF process number is 1, and the network
l For Router E, the router ID is 5.5.5.5, the OSPF process number is 1, and the network
segment of Area 0 is 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, and 172.17.1.0/24.
l The number of load balancing paths on Router A is 2.
l The weight values of the next hop routes from Router A to Router B, Router C, and Router
D are 2, 1, and 1 respectively.
Procedure
Step 2 Configure basic OSPF functions. This example assumes that you know the configuration method
and no details are provided here.
Step 3 View the routing table of Router A.

As displayed in the routing table, Router A has three valid next hops: 10.1.1.2 (Router B),
10.1.2.2 (Router C), and 10.1.3.2 (RouterD). This is because the default maximum number of
equal-cost routes is 6.
<RouterA> display ip routing-table
----------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/24 Direct 0 0 D 10.1.2.1 Pos3/0/0
10.1.3.2/32 Direct 0 0 D 10.1.2.2 Pos3/0/0
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Pos2/0/0
192.168.2.0/24 OSPF 10 2 D 10.1.2.2 Pos3/0/0
172.17.1.0/24 OSPF 10 3 D 10.1.1.2 Pos1/0/0
OSPF 10 3 D 10.1.2.2 Pos2/0/0
OSPF 10 3 D 10.1.3.2 Pos3/0/0
NOTE
The maximum number of equal-cost routes varies with products and protocols. You can adjust the
maximum number by purchasing the License.
Step 4 Configure a maximum of two routes on Router A to perform load balancing.

[RouterA] ospf 1
[RouterA-ospf-1] maximum load-balancing 2
[RouterA-ospf-1] quit
# View the routing table of Router A. As shown in the routing table, Router A has only two valid
next hops, 10.1.1.2 (Router B) and 10.1.2.2 (Router C). This is because the maximum number
of equal-cost routes is set to 2.
----------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/24 Direct 0 0 D 10.1.2.1 Pos3/0/0
10.1.3.2/32 Direct 0 0 D 10.1.2.2 Pos3/0/0
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Pos2/0/0
192.168.2.0/24 OSPF 10 2 D 10.1.2.2 Pos3/0/0
172.17.1.0/24 OSPF 10 3 D 10.1.1.2 Pos1/0/0
OSPF 10 3 D 10.1.2.2 Pos2/0/0
Step 5 Configure the priority for equal-cost routes on Router A.

[RouterA] ospf 1
[RouterA-ospf-1] nexthop 10.1.1.2 weight 2

# View the OSPF routing table of Router A.

----------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/24 Direct 0 0 D 10.1.2.1 Pos3/0/0
10.1.3.2/32 Direct 0 0 D 10.1.2.2 Pos3/0/0
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Pos1/0/0
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Pos2/0/0
192.168.2.0/24 OSPF 10 2 D 10.1.2.2 Pos3/0/0
172.17.1.0/24 OSPF 10 3 D 10.1.2.2 Pos2/0/0
OSPF 10 3 D 10.1.3.2 Pos3/0/0
As shown in the display, the priority of the route with the next hops being 10.1.2.2 and 10.1.3.2
is higher than that of the route with the next hop being 10.1.1.2. Therefore, Router A has only
two valid next hops, 10.1.2.2 (Router C) and 10.1.3.2 (Router D).
----End
Configuration Files
#
sysname RouterA
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
interface pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.1.2.1 255.255.255.0
#
interface pos3/0/0
link-protocol ppp
undo shutdown
ip address 10.1.3.1 255.255.255.0
#
maximum load-balancing 2
nexthop 10.1.1.2 weight 2
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return


sysname RouterB
#
interface pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.0
#
interface pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
area 0.0.0.0
network 10.1.1.0 0.255.255.255
network 192.168.0.0 0.255.255.255
#
return

#
sysname RouterC
#
interface pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.2.2 255.255.255.0
#
interface pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
area 0.0.0.0
network 10.1.2.0 0.255.255.255
network 192.168.1.0 0.0.255.255
#
Return

#
sysname RouterD
#
interface pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.3.2 255.255.255.0
#
interface pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
area 0.0.0.0
network 10.1.3.0 0.255.255.255
network 192.168.2.0 0.0.255.255
#
return

#
sysname RouterE
#

undo shutdown
ip address 172.17.1.1 255.255.255.0
#
interface pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.2 255.255.255.0
#
interface pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface pos3/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
area 0.0.0.0
network 192.168.0.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
return
5.16.5 Example for Configuring an OSPF Stub Area

This section provides an example for configuring an OSPF stub area.
A stub area does not allow AS external routes to be transmitted. This reduces bandwidth and
As shown in Figure 5-10, OSPF is enabled on all routers and the entire AS is partitioned into
three areas. Router A and Router B function as ABRs to forward inter-area routes; Router D
functions as an ASBR to import the external static route 200.0.0.0/8. To reduce the number of
LSAs advertised to Area 1 without affecting the route reachability, configure Area 1 as a stub
area and prevent Type 3 LSAs from being advertised to the stub area.
Figure 5-10 Configuring an OSPF stub area
Area0
POS1/0/0
192.168.0.1/24
RouterA POS1/0/0 RouterB
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
ASBR
Stub
Area1 Area2

1. Enable OSPF and configure basic OSPF functions on each router.
2. Configure Router D to import the static route 200.0.0.0/8.
3. Configure Area 1 as a stub area.
4. Disable Router A from advertising Type 3 LSAs to the stub area.
Data Preparation
l Router ID 3.3.3.3 of Router C; OSPF process ID 1; network segment 192.168.1.0/24 of
Area 1
l Router ID 4.4.4.4 of Router D; OSPF process ID 1; network segment 192.168.2.0/24 of
Area 2
Procedure
5.2 Configuring Basic OSPF Functions shows how to configure basic OSPF functions. For
details about the configuration, see the configuration files.
Step 3 Configure Router D to import the static route 200.0.0.0/8.
[RouterD] ip route-static 200.0.0.0 8 null 0
[RouterD] ospf
[RouterD-ospf-1] import-route static
[RouterD-ospf-1] quit
# Check the OSPF routing table on Router C.

[RouterC] display ospf routing

Routing Tables
Routing for Network
192.168.0.0/24 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.1.0/24 1 Stub 192.168.1.2 3.3.3.3 0.0.0.1
192.168.2.0/24 3 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
Routing for ASEs

200.0.0.0/8 4 Type1 1 192.168.1.1 4.4.4.4

Total Nets: 4
As Area 1 where Router C resides is a common area, you can find information about AS external
routes in the routing table.
Step 4 Configure Area 1 as a stub area.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub
[RouterC] ospf
[RouterC-ospf-1-area-0.0.0.1] stub
NOTE
All routers in a stub area must be configured with stub attributes using the stub command.

Routing Tables
Routing for Network

0.0.0.0/0 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 1.1.1.1
0.0.0.1
192.168.1.0/24 1 Stub 192.168.1.2 3.3.3.3
0.0.0.1
192.168.2.0/24 3 Inter-area 192.168.1.1 1.1.1.1
0.0.0.1
Total Nets: 4
After Area 1 where Router C resides is configured as a stub area, a default route, not an AS
external route, exists in the routing table.
Step 5 Prevent Type 3 LSAs from being advertised to the stub area.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub no-summary

# View the OSPF routing table on Router C.

Routing Tables
Routing for Network

0.0.0.0/0 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.1.0/24 1 Stub 192.168.1.2 3.3.3.3 0.0.0.1

Total Nets: 2
After Type 3 LSAs are prevented from being advertised to the stub area, the number of routing
entries on the router in the stub area is further reduced, and only the default route to somewhere
outside the stub area is reserved.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub no-summary
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
return

#
sysname RouterC
#
router id 3.3.3.3

#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
ospf 1
import-route static
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
ip route-static 200.0.0.0 255.0.0.0 NULL0
#
return
5.16.6 Example for Configuring an OSPF NSSA

This section provides an example for configuring an OSPF NSSA.
As shown in Figure 5-11, OSPF is enabled on all routers and the entire AS is partitioned into
three areas. Router A and Router B function as ABRs to forward inter-area routes; Router D
functions as an ASBR to import the external static route 10.0.0.0/8. To import AS external routes
but reduce the number of LSAs advertised to Area 1 without affecting the route reachability,
configure Area 1 as an NSSA and configure Router A as an LSA translator in the NSSA.

Figure 5-11 Networking diagram of configuring an OSPF NSSA
RouterA
POS2/0/0 POS1/0/0
192.168.3.1/24 192.168.0.1/24
POS1/0/0
192.168.3.2/24 POS3/0/0 POS1/0/0
192.168.1.1/24 192.168.0.2/24
RouterD RouterC
ASBR
POS1/0/0
192.168.1.2/24 POS2/0/0
POS2/0/0 192.168.2.2/24
192.168.4.1/24
POS3/0/0 POS2/0/0
Area1 192.168.4.2/24
NSSA 192.168.2.1/24 Area0
RouterB

2. Configure Area 1 as an NSSA.
3. Configure Router D to import the static route 10.0.0.0/8.
4. Configure Router A in the NSSA as an LSA translator.
Data Preparation

Area 0; network segments 192.168.1.0/24 and 192.168.3.0/24 of Area 1
Area 0; network segments 192.168.1.0/24 and 192.168.4.0/24 of Area 1
192.168.2.0/24 of Area 0
l Router ID 4.4.4.4 of Router D; OSPF process ID 1; network segments 192.168.3.0/24 and
192.168.4.0/24 of Area 1
Procedure
[RouterA] ospf 1


[RouterB] ospf 1
[RouterC] ospf 1
[RouterD] ospf 1
# View the OSPF routing table on Router D.

Routing Tables
Routing for Network

192.168.3.0/24 1 Transit 192.168.3.2 4.4.4.4 0.0.0.1
192.168.4.0/24 1 Transit 192.168.4.1 4.4.4.4 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.3.1 1.1.1.1 0.0.0.1
192.168.1.0/24 2 Transit 192.168.4.2 1.1.1.1 0.0.0.1
192.168.1.0/24 2 Transit 192.168.3.1 1.1.1.1 0.0.0.1
192.168.2.0/24 2 Inter-area 192.168.4.2 2.2.2.2 0.0.0.1
Total Nets: 6
Step 3 Configure Area 1 as an NSSA.
[RouterA] ospf 1
[RouterA-ospf-1-area-0.0.0.1] nssa
[RouterB] ospf 1

[RouterB-ospf-1-area-0.0.0.1] nssa
[RouterD] ospf 1
[RouterD-ospf-1-area-0.0.0.1] nssa
NOTE
All routers in the NSSA must be configured with NSSA attributes using the nssa command.
# View the OSPF routing table on Router D.


Routing Tables
Routing for Network

192.168.3.0/24 1 Transit 192.168.3.2 4.4.4.4 0.0.0.1
192.168.4.0/24 1 Transit 192.168.4.1 4.4.4.4 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.3.1 1.1.1.1 0.0.0.1
192.168.1.0/24 2 Transit 192.168.4.2 2.2.2.2 0.0.0.1
192.168.1.0/24 2 Transit 192.168.3.1 2.2.2.2 0.0.0.1
192.168.2.0/24 2 Inter-area 192.168.4.2 2.2.2.2 0.0.0.1
Routing for NSSAs

0.0.0.0/0 1 Type2 1 192.168.4.2 2.2.2.2
0.0.0.0/0 1 Type2 1 192.168.3.1 1.1.1.1
Total Nets: 8
Step 4 Configure Router D to import the static route 10.0.0.0/8.

[RouterD] ip route-static 10.0.0.0 8 null 0
[RouterD] ospf


Routing Tables
Routing for Network

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

10.0.0.0/8 1 Type2 1 192.168.0.1 2.2.2.2
Total Nets: 7
The command output shows that Router C has imported the AS external route and the router
with the router ID of 2.2.2.2 will advertise LSAs carrying information about the imported AS

external route in the NSSA. Router B functions as the LSA translator. OSPF selects the ABR
with a larger router ID as an LSA translator.
Step 5 Configure Router A as an LSA translator.

[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary translator-
always


Routing Tables
Routing for Network

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

10.0.0.0/8 1 Type2 1 192.168.0.1 1.1.1.1
Total Nets: 7
The command output shows that Router C has imported the AS external route and the router
with the router ID of 1.1.1.1 will advertise LSAs carrying information about the imported AS
external route in the NSSA. Router A functions as an LSA translator.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.3.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0

#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
nssa default-route-advertise no-summary translator-always
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
undo shutdown
ip address 192.168.4.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
nssa
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.0.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.3.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.4.1 255.255.255.0
#
ospf 1
import-route static
area 0.0.0.1
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
nssa
#
#
return
5.16.7 Example for Configuring Local OSPF MT

This section provides an example for configuring local OSPF MT, including networking
requirements, configuration roadmap, configuration procedure, and configuration files.
When multicast and an MPLS TE tunnel are configured and the TE tunnel is configured with
IGP Shortcut, the outbound interface of the route calculated by an IGP is not a physical interface
but a TE tunnel interface. The router uses the TE tunnel interface to send multicast Join messages
through a unicast route to the multicast source address. The router through which the TE tunnel
passes, however, cannot detect the multicast Join messages. As a result, multicast forwarding
entries will not be created.
As shown in Figure 5-12, Router A, Router B, Router C, Router D, and Router E are running
OSPF. Router B and Router D set up an MPLS TE tunnel with the tunnel interface Tunnel 1/0/0,
and Router B is configured with IGP Shortcut. The outbound interface calculated by Router B
may be the TE tunnel interface, not the physical interface GE 2/0/0. Router B uses Tunnel 1/0/0
to send multicast Join messages through the unicast route to the multicast source address.
Therefore, Router C through which the TE tunnel passes cannot detect the multicast Join
messages, and generates no multicast forwarding entries.
To resolve the problem, enable local OSPF MT on Router B. After local OSPF MT is enabled,
if the outbound interface of the calculated route is a TE tunnel interface of the IGP Shortcut type,
the RM module creates a separate MIGP routing table for the multicast protocol, calculates the
physical outbound interface for the route, and adds the physical interface to the MIGP routing
table for multicast forwarding.

Figure 5-12 Configuring local OSPF MT
Client Server
172.16.1.2/24 192.168.3.2/24
GE1/0/0 GE2/0/0
172.16.1.1/24 192.168.3.1/24
RouterA RouterE
GE2/0/0 GE1/0/0
10.0.0.1/24 10.0.3.2/24
GE1/0/0 GE1/0/0
10.0.0.2/24 GE1/0/0 GE2/0/0 10.0.3.1/24
10.0.1.1/24 10.0.2.2/24
RouterB RouterD
GE2/0/0 GE2/0/0
10.0.1.2/24 RouterC 10.0.2.1/24
Tunnel1/0/0

2. Enable PIM-SM on each router.
3. Configure an MPLS RSVP-TE tunnel.
4. Configure an MPLS TE tunnel and enable IGP Shortcut for it on Router B.
5. Enable local OSPF MT on Router B.
Data Preparation
l IP address of each interface on each router, as shown in Table 5-3
Table 5-3 IP address of each interface
router IP Address of Loopback 0
Router A 1.1.1.1/32
Router B 2.2.2.2/32
Router C 3.3.3.3/32
Router D 4.4.4.4/32
Router E 5.5.5.5/32

l The TE tunnel interface Tunnel 1/0/0 uses the IP address of Loopback 0 and runs the MPLS
TE protocol. The destination address of the TE tunnel is 4.4.4.4; the tunnel ID is 100; RSVP-
TE is used as a signaling protocol on the TE tunnel.
Procedure
Step 3 Configure PIM-SM.
# Enable PIM-SM on Router A.
[RouterA] multicast routing-enable
[RouterA] interface Gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] pim sm
NOTE
Enable PIM-SM on each router. The configurations on Router B, Router C, Router D, and Router E are similar
to those on Router A. The detailed configurations are not provided here.
# Enable IGMP on Ethernet 1/0/0 of Router A.

[RouterA-GigabitEthernet1/0/0] igmp enable
[RouterA-GigabitEthernet1/0/0] igmp version 3
# Configure a C-BSR and a C-RP. Configure a C-BSR and a C-RP on Router D.

[RouterD] pim
[RouterD-pim] c-bsr Gigabitethernet 1/0/0
[RouterD-pim] c-rp Gigabitethernet 1/0/0
[RouterD-pim] quit
# View the multicast routing table on Router C.

[RouterC] display multicast routing-table
Multicast routing table of VPN-Instance: public net
Total 3 entries
00001. (192.168.3.8, 224.31.31.31)

Uptime: 15:03:04
Upstream Interface: GigabitEthernet2/0/0
List of 1 downstream interface
1: GigabitEthernet1/0/0
00002. (192.168.3.9, 224.31.31.31)

Uptime: 15:03:04
00003. (192.168.3.10, 224.31.31.31)

Uptime: 15:03:04


The preceding command output shows information about the multicast routing table on
Router C.
Step 4 Configure an MPLS RSVP-TE tunnel.
[RouterB] mpls lsr-id 2.2.2.2
[RouterB] mpls
[RouterB-mpls] mpls te
[RouterB-mpls] mpls rsvp-te
[RouterB-mpls] mpls te cspf
[RouterB-mpls] quit
[RouterB] interface Gigabitethernet 2/0/0
[RouterB-GigabitEthernet2/0/0] mpls
[RouterB-GigabitEthernet2/0/0] mpls te
[RouterB-GigabitEthernet2/0/0] mpls rsvp-te
[RouterB] ospf 1
[RouterB-ospf-1] enable traffic-adjustment
[RouterB-ospf-1] opaque-capability enable
[RouterB-ospf-1] area 0.0.0.0
[RouterB-ospf-1-area-0.0.0.0] mpls-te enable
[RouterC] mpls lsr-id 3.3.3.3
[RouterC] mpls
[RouterC-mpls] mpls te
[RouterC-mpls] mpls rsvp-te
[RouterC-mpls] quit
[RouterC] interface Gigabitethernet 1/0/0
[RouterC-GigabitEthernet1/0/0] mpls
[RouterC-GigabitEthernet1/0/0] mpls te
[RouterC-GigabitEthernet1/0/0] mpls rsvp-te
[RouterC] interface Gigabitethernet 2/0/0
[RouterC] ospf 1
[RouterC-ospf-1] opaque-capability enable
[RouterC-ospf-1] area 0.0.0.0
[RouterC-ospf-1-area-0.0.0.0] mpls-te enable
[RouterD] mpls lsr-id 4.4.4.4
[RouterD] mpls
[RouterD-mpls] mpls te
[RouterD-mpls] mpls rsvp-te
[RouterD-mpls] quit
[RouterD] interface Gigabitethernet 1/0/0
[RouterD-GigabitEthernet1/0/0] mpls
[RouterD-GigabitEthernet1/0/0] mpls te
[RouterD-GigabitEthernet1/0/0] mpls rsvp-te
[RouterD] ospf 1
[RouterD-ospf-1] opaque-capability enable
[RouterD-ospf-1] area 0.0.0.0

[RouterD-ospf-1-area-0.0.0.0] mpls-te enable

Step 5 Configure an MPLS TE tunnel and enable IGP Shortcut.
# Configure an MPLS TE tunnel and enable IGP Shortcut for it on Router B.

[RouterB] interface tunnel 1/0/0
[RouterB-Tunnel1/0/0] ip address unnumbered interface loopback 0
[RouterB-Tunnel1/0/0] tunnel-protocol mpls te
[RouterB-Tunnel1/0/0] destination 4.4.4.4
[RouterB-Tunnel1/0/0] mpls te tunnel-id 100
[RouterB-Tunnel1/0/0] mpls te commit
[RouterB-Tunnel1/0/0] mpls te igp shortcut ospf
[RouterB-Tunnel1/0/0] mpls te igp metric relative -10
[RouterB-Tunnel1/0/0] quit
# Check the OSPF routing table on Router B. Information shows that an MPLS TE tunnel has
been set up.

3.3.3.3/32 OSPF 10 1 D 10.0.1.1
4.4.4.4/32 OSPF 10 1 D 2.2.2.2 Tunnel1/0/0
5.5.5.5/32 OSPF 10 2 D 2.2.2.2 Tunnel1/0/0
10.0.0.0/24 Direct 0 0 D 10.0.0.2
10.0.1.0/24 Direct 0 0 D 10.0.1.2
10.0.2.0/24 OSPF 10 2 D 10.0.1.1
OSPF 10 2 D 10.0.1.1 Tunnel1/0/0
10.0.3.0/24 OSPF 10 2 D 2.2.2.2 Tunnel1/0/0
172.16.1.0/24 OSPF 10 2 D 10.0.0.1
192.168.3.0/24 OSPF 10 3 D 2.2.2.2 Tunnel1/0/0
# Check the multicast routing table on Router C.

No multicast routing entry is displayed in the multicast routing table on Router C, indicating
that multicast packets have been dropped.
Step 6 Configure local OSPF MT.
# Enable local OSPF MT on Router B.

[RouterB] ospf
[RouterB-ospf-1] local-mt enable
# Check the multicast routing table on Router C.



Total 3 entries
00001. (192.168.3.8, 224.31.31.31)

Uptime: 00:00:19
00002. (192.168.3.9, 224.31.31.31)

Uptime: 00:00:19
00003. (192.168.3.10, 224.31.31.31)

Uptime: 00:00:19
The preceding command output shows information about the multicast routing table on
Router C.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
multicast routing-enable
#
undo shutdown
ip address 10.0.0.1 255.255.255.0
pim sm
igmp version 3
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
pim sm
igmp enable
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 10.0.0.0 0.0.0.255
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
#

mpls lsr-id 2.2.2.2

mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ospf 1
enable traffic-adjustment
local-mt enable
area 0.0.0.0
network 10.0.0.0 0.0.0.255
network 10.0.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
mpls-te enable
#
undo shutdown
ip address 10.0.0.2 255.255.255.0
pim sm
#
undo shutdown
ip address 10.0.1.2 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
interface Tunnel1/0/0
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 4.4.4.4
mpls te tunnel-id 100
mpls te igp shortcut ospf
mpls te igp metric relative -10
mpls te commit
#
pim
C-BSR LoopBack0
C-RP LoopBack0
#
return

#
sysname RouterC
#
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
ospf 1
area 0.0.0.0
network 10.0.1.0 0.0.0.255
network 10.0.2.0 0.0.0.255
network 3.3.3.3 0.0.0.0
mpls-te enable
#

undo shutdown
ip address 10.0.1.1 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.0.2.2 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
undo shutdown
ip address 3.3.3.3 255.255.255.255
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.0.3.1 255.255.255.0
pim sm
#
undo shutdown
ip address 10.0.2.1 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.0.2.0 0.0.0.255
network 10.0.3.0 0.0.0.255
network 4.4.4.4 0.0.0.0
mpls-te enable
#
pim
C-BSR GigabitEthernet1/0/0
C-RP GigabitEthernet1/0/0
#
return

#
sysname RouterE
#
router id 5.5.5.5
#
#
undo shutdown
ip address 10.0.3.2 255.255.255.0
pim sm
#
undo shutdown
ip address 192.168.3.1 255.255.255.0
pim sm
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 10.0.3.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 5.5.5.5 0.0.0.0
#
return
5.16.8 Example for Configuring BFD for OSPF

This section provides an example for configuring BFD for OSPF, including networking
requirements, configuration roadmap, configuration procedure, and configuration files.
OSPF enables the router to periodically send Hello packets to a neighboring router for fault
detection. Detecting a fault takes more than 1s. With the development of technologies, voice,
video, and other VOD services are widely used. These services are quite sensitive to packet loss
and delays. When traffic is transmitted at gigabit rates, long-time fault detection will cause packet
loss. This cannot meet high reliability requirements of the carrier-class network. BFD for OSPF
is used to resolve the problem. After BFD for OSPF is configured, 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.
For example, as shown in Figure 5-13, the primary link Router A -> Router B and the secondary
link Router A -> Router C -> Router B are deployed on the network. Traffic is transmitted on
the primary link normally. When the primary link becomes faulty, the Router is expected to
rapidly detect the fault and switch traffic to the secondary link.
You can configure BFD for OSPF to detect the OSPF neighbor relationship between Router A
and Router B. When the link between Router A and Router B fails, BFD can rapidly detect the
failure and report it to OSPF. Traffic is then switched to the secondary link.

Figure 5-13 Configuring BFD for OSPF

RouterA RouterB GE3/0/0
172.16.1.1/24
GE2/0/0 GE2/0/0
GE1/0/0 3.3.3.1/24 3.3.3.2/24 GE1/0/0
1.1.1.1/24 2.2.2.2/24
GE1/0/0 GE2/0/0
1.1.1.2/24 2.2.2.1/24
RouterC

2. Enable BFD for OSPF on Router A and Router B.
Data Preparation
l Router ID 1.1.1.1 of Router A; OSPF process ID 1; network segments 3.3.3.0/24 and

1.1.1.0/24 of Area 0
l Router ID 2.2.2.2 of Router B; OSPF process ID 1; network segments 3.3.3.0/24, 2.2.2.0/24,
and 172.16.1.0/24 of Area 0
2.2.2.0/24 of Area 0
l Minimum intervals at which BFD packets are sent and received and the local detection
multiplier on Router A and Router B.
Procedure
Figure 5-13 shows how to assign an IP address to each interface. For details about the
configuration, see the configuration files.
# Check the OSPF neighbor relationships on Router A.

<RouterA> display ospf peer

Neighbors


DR: 1.1.1.1 BDR: 1.1.1.2 MTU: 0
Neighbors

DR: 3.3.3.1 BDR: 3.3.3.2 MTU: 0
The preceding command output shows that Router A, Router B, and Router C have established
OSPF neighbor relationships.
# Check the OSPF routing table on Router A.

<RouterA> display ospf routing

Routing Tables
Routing for Network

172.16.1.0/24 2 Stub 3.3.3.2 2.2.2.2 0.0.0.0
3.3.3.0/24 1 Transit 3.3.3.1 1.1.1.1 0.0.0.0
2.2.2.0/24 2 Transit 3.3.3.2 3.3.3.3 0.0.0.0
2.2.2.0/24 2 Transit 1.1.1.2 3.3.3.3 0.0.0.0
1.1.1.0/24 1 Transit 1.1.1.1 1.1.1.1 0.0.0.0
Total Nets: 5
The preceding command output shows that the next hop address of the route to 172.16.1.0/24
is 3.3.3.2, and service traffic is transmitted on the primary link from Router A to Router B.
Step 3 Configure BFD for OSPF, and set the intervals at which BFD packets are sent and received and
the local detection multiplier.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] ospf
[RouterA-ospf-1] bfd all-interfaces enable
[RouterA-ospf-1] bfd all-interfaces min-tx-interval 500 min-rx-interval 500 detect-
multiplier 4
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] ospf
[RouterB-ospf-1] bfd all-interfaces enable
[RouterB-ospf-1] bfd all-interfaces min-tx-interval 500 min-rx-interval 500 detect-
multiplier 4

Check the BFD session information on Router A.

[RouterA] display ospf bfd session all
Area 0.0.0.0 interface 1.1.1.1(GigabitEthernet1/0/0)'s BFD Sessions
NeighborId:3.3.3.3 AreaId:0.0.0.0
Interface:GigabitEthernet1/0/0

RemoteIpAdd:1.1.1.2 Diagnostic Info:No diagnostic information
Area 0.0.0.0 interface 3.3.3.1(GigabitEthernet2/0/0)'s BFD Sessions
NeighborId:2.2.2.2 AreaId:0.0.0.0
Interface:GigabitEthernet2/0/0
RemoteIpAdd:3.3.3.2 Diagnostic Info:No diagnostic information
The preceding command output shows that the BFD session is Up.
# Run the shutdown command on GE 2/0/0 of Router B to simulate the primary link fault.
[RouterB] interface gigabitethernet 2/0/0

<RouterA> display ospf routing

Routing Tables
Routing for Network

172.16.1.0/24 2 Stub 1.1.1.2 2.2.2.2 0.0.0.0
3.3.3.0/24 1 Stub 3.3.3.1 1.1.1.1 0.0.0.0
2.2.2.0/24 2 Transit 1.1.1.2 3.3.3.3 0.0.0.0
1.1.1.0/24 1 Transit 1.1.1.1 1.1.1.1 0.0.0.0
Total Nets: 4
The preceding command output shows that the secondary link of Router A -> Router C ->
Router B takes effect after the primary link fails, and the next hop address of the route to
172.16.1.0/24 is 1.1.1.2.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
bfd
#
undo shutdown

ip address 1.1.1.1 255.255.255.0

#
ospf 1
bfd all-interface enable
bfd all-interface min-tx-interval 500 min-rx-interval 500 detect-multiplier 4
area 0.0.0.0
network 3.3.3.0 0.0.0.255
network 1.1.1.0 0.0.0.255
#
return

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

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

5.16.9 Example for Configuring OSPF IP FRR
When a fault occurs on the network, OSPF IP FRR can fast switch traffic to the backup link
without waiting for route convergence. This ensures uninterrupted traffic transmission.
l OSPF runs on the four routers in the same area.

l If the link between Router A and Router C becomes faulty, the traffic forwarded by
Router A is rapidly switched to the backup link and forwarded through Router B.
Figure 5-14 Networking diagram for configuring OSPF IP FRR

RouterB
GE1/0/1 GE1/0/2
10.1.1.2/24 10.3.1.1/24
co
st
=
9
5
=
GE1/0/1 GE1/0/3
st
co
10.1.1.1/24 10.3.1.2/24
cost = 4 cost = 55
GE1/0/2 GE1/0/1 GE1/0/2 GE1/0/1
RouterA 10.2.1.1/24 10.2.1.2/24 RouterC 10.4.1.1/24 10.4.1.2/24 RouterD
1. Configure basic OSPF functions on each router.

2. Set the cost to ensure that the link from Router A to Router C is preferred.
3. Enable OSPF IP FRR on Router A to protect the traffic forwarded by Router A.
Data Preparation
l Router ID (1.1.1.1), OSPF process ID (1), network segment addresses in Area 1 (10.1.1.0
and 10.2.1.0), and interface cost (as shown in Figure 5-14) of Router A
l Router ID (2.2.2.2), OSPF process ID (1), network segment addresses in Area 1 (10.1.1.0
and 10.3.1.0), and interface cost (as shown in Figure 5-14) of Router B
l Router ID (3.3.3.3), OSPF process ID (1), network segment addresses of Area 1 (10.2.1.0,
10.3.1.0, and 10.4.1.0), and interface cost (as shown in Figure 5-14) of Router C
l Router ID (4.4.4.4), OSPF process ID (1), network segment address in Area 1
(10.4.1.0),interface cost (as shown in Figure 5-14), and destination address of the imported
static route (172.16.1.1/32) of Router D

Procedure
Step 1 Configure an IP address and the cost for each interface. This example assumes that you know
the configuration method and no details are provided here.
[RouterA] ospf
[RouterB] ospf
[RouterC] ospf
[RouterD] ip route-static 172.16.1.1 255.255.255.255 NULL0
[RouterD] ospf
Step 3 Enable OSPF IP FRR on Router A.
# Enable OSPF IP FRR on Router A.

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

Area : 0.0.0.1 AdvRouter : 4.4.4.4
Type : ASBR Age : 00h31m27s
URT Cost : 59
NextHop : 10.2.1.2 Interface : GigabitEthernet1/0/2
Backup Nexthop : 10.1.1.2 Backup Interface : GigabitEthernet1/0/1
Backup Type : LFA LINK

The preceding display shows that a backup route is generated on Router A.
----End
Configuration Files
#
sysname RouterA
#
router-id 1.1.1.1
#
undo shutdown
ip address 10.1.1.1 255.255.255.0
ospf cost 9
#
undo shutdown
ip address 10.2.1.1 255.255.255.0
ospf cost 4
#
ospf 1
frr
frr-policy route route-policy abc
loop-free-alternate
area 0.0.0.1
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return

#
sysname RouterB
#
router-id 2.2.2.2
#
undo shutdown
ip address 10.1.1.2 255.255.255.0
ospf cost 9
#
undo shutdown
ip address 10.3.1.1 255.255.255.0
ospf cost 5
#
ospf 1
area 0.0.0.1
network 10.3.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return

#
sysname RouterC
#
router-id 3.3.3.3
#
undo shutdown
ip address 10.2.1.2 255.255.255.0
ospf cost 4
#

undo shutdown
ip address 10.4.1.1 255.255.255.0
ospf cost 55
#
undo shutdown
ip address 10.3.1.2 255.255.255.0
ospf cost 5
#
ospf 1
area 0.0.0.1
network 10.3.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
return

#
sysname RouterD
#
router-id 4.4.4.4
#
undo shutdown
ip address 10.4.1.2 255.255.255.0
ospf cost 55
#
ospf 1
import-route static
area 0.0.0.1
network 10.4.1.0 0.0.0.255
#
#
return
5.16.10 Example for Configuring OSPF GR

This part provides an example for configuring OSPF GR to ensure nonstop forwarding when an
OSPF process restarts through GR or the active/standby switchover is performed.
As shown in Figure 5-15, Router A, Router B, and Router D are installed with the AMB and
SMB that back up each other. The routers interconnect by means of OSPF, and are enabled with
GR.
It is required that service forwarding be not interrupted when Router A restarts the OSPF process
in GR mode or performs the active/standby switchover.

Figure 5-15 Networking diagram of configuring OSPF GR
RouterA POS2/0/0 POS2/0/0 RouterB

10.1.2.1/24 10.1.2.2/24
POS1/0/0 POS1/0/0
10.1.1.2/24 10.1.3.2/24
Area0
Area1 Area2
POS1/0/0 POS1/0/0
10.1.1.1/24 RouterD RouterC 10.1.3.1/24
GE2/0/0
192.168.2.1/24
GE2/0/0
192.168.1.1/24
1. Enable OSPF to interconnect all routers.

2. Configure GR on RouterA, RouterB and RouterD.
Data Preparation
l IP address of each interface on the routers

l OSPF process number
Procedure
For configuration details, see "Configuration Files" in this section.
Step 3 (Optional) Enable forcible active/standby switchover on Router A and configure the SMB to
automatically synchronize information on the AMB.
By default, the forcible active/standby switchover is enabled.

[RouterA] slave switchover enable

[RouterA] slave auto-update config
Step 4 Enable OSPF GR on Router A, Router B, and Router D.

# Configure Router A. The configurations of Router B and Router D are the same as that of
Router A, and are not mentioned here.
[RouterA] ospf 1
[RouterA-ospf-1] opaque-capability enable
[RouterA-ospf-1] graceful-restart

# Run the display ospf graceful-restart command on Router A, Router B, and Router D to
check the OSPF GR status. Take the display of Router A as an example. You can find that the
value of Graceful-restart capability is enabled. This indicates that OSPF GR is enabled on Router
A.
<RouterA> display ospf 1 graceful-restart

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
S
# In the user view, run the reset ospf process graceful-restart command on Router A to restart
OSPF process 1. Run the display ospf peer command on Router D to check the OSPF neighbor
relationship between Router D and Router A. If the status of the OSPF neighbor relationship is
Full, it indicates that the relationship is not interrupted when Router A restarts the OSPF process
through GR.
<RouterA> reset ospf 1 process graceful-restart
<RouterD> display ospf 1 peer

Neighbors

Router ID: 10.1.1.2 Address: 10.1.1.2 GR State: Doing GR
# Perform the active/standby switchover on Router A. During the switchover, Router C can ping
through Router D, which indicates that service forwarding is not interrupted.Run the display
ospf peer command on Router D and Router B to check the OSPF neighbor relationship with
Router A. The statuses of the OSPF neighbor relationship are displayed as Full.

[RouterA] slave switchover

<RouterB> display ospf 1 peer

Neighbors

Neighbors

<RouterC> ping 192.168.1.1

0.00% packet loss
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.2.1 255.255.255.0
#
ospf 1
graceful-restart
area 0.0.0.0
network 10.1.2.0 0.0.0.255
area 0.0.0.1
network 10.1.1.0 0.0.0.255
#
return


#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.3.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
#
ospf 1
graceful-restart
area 0.0.0.0
network 10.1.2.0 0.0.0.255
area 0.0.0.2
network 10.1.3.0 0.0.0.255
#
return

#
sysname RouterC
#
ip address 192.168.2.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.3.1 255.255.255.0
#
ospf 1
area 0.0.0.2
network 10.1.3.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return

#
sysname RouterD
#
ip address 192.168.1.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
#
ospf 1
graceful-restart
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return
5.16.11 Example for Configuring OSPF-BGP

This part provides an example for configuring OSPF-BGP association to prevent network traffic
from being interrupted after router are restarted.

Network Requirements
As shown in Figure 5-16, all routers run BGP. An EBGP connection is established between
Router D and Router E. IBGP full connections are established between partial routers in AS 10,
and OSPF is used as an IGP protocol.
It is required to enable OSPF-BGP linkage on Router B so that the traffic from Router A to AS
20 is not interrupted after Router B restarts.
Figure 5-16 Networking diagram of configuring OSPF-BGP linkage
RouterC AS 20
POS2/0/0 POS1/0/0 RouterF
10.1.2.2/30 10.1.4.1/30
POS1/0/0
POS1/0/0 10.3.1.2/30
POS2/0/0
10.1.2.1/30 10.1.4.2/30 POS2/0/0
10.3.1.1/30
RouterA RouterD EBGP
POS3/0/0
RouterE
POS1/0/0 10.2.1.1/30
POS2/0/0 POS1/0/0
10.1.1.1/30 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
RouterB AS 10
1. Enable OSPF on Router A, Router B, Router C, and Router D (except 10.2.1.1/30) and
specify the same area for all OSPF interfaces.
2. Establish IBGP full connections between Router A, Router B, Router C, and Router D
(except 10.2.1.1/30).
3. Set the OSPF cost on Router C.
4. Establish the EBGP connection between Router D and Router E.
5. Configure the OSPF routes and configure BGP to import directly connected routes on
Router D.
6. Configure BGP on Router E.
Data Preparation
l The router ID of Router A is 1.1.1.1, the AS number is 10, the OSPF process number is 1,
and the network segments in Area 0 are 10.1.1.0/30 and 10.1.2.0/30.

l The router ID of Router B is 2.2.2.2, the AS number is 10, the OSPF process number is 1,
l The router ID of Router C is 3.3.3.3, the AS number is 10, the OSPF process number is 1,
l The router ID of Router D is 4.4.4.4, the AS number is 10, the OSPF process number is 1,
l The router ID of Router E is 5.5.5.5, and the AS number is 20.
Procedure
Step 3 Configure an IBGP full connection.
[RouterA] interface LoopBack 0
[RouterA-LoopBack0] ip address 1.1.1.1 32
[RouterA-LoopBack0] quit
[RouterA] bgp 10
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 2.2.2.2 connect-interface LoopBack 0
[RouterA-bgp] quit
[RouterB] interface LoopBack 0
[RouterB-LoopBack0] ip address 2.2.2.2 32
[RouterB-LoopBack0] quit
[RouterB] bgp 10
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 1.1.1.1 connect-interface LoopBack 0
[RouterB-bgp] quit
[RouterC] interface LoopBack 0
[RouterC-LoopBack0] ip address 3.3.3.3 32
[RouterC-LoopBack0] quit
[RouterC] bgp 10
[RouterC-bgp] peer 1.1.1.1 connect-interface LoopBack 0


[RouterC-bgp] quit
[RouterD] interface LoopBack 0
[RouterD-LoopBack0] ip address 4.4.4.4 32
[RouterD-LoopBack0] quit
[RouterD] bgp 10
[RouterD-bgp] peer 1.1.1.1 connect-interface LoopBack 0
[RouterD-bgp] quit
Step 4 Configure an EBGP connection.
[RouterD] bgp 10
[RouterD-bgp] import-route direct
[RouterD-bgp] import-route ospf 1
[RouterD-bgp] quit
[RouterE] bgp 20
[RouterE-bgp] peer 10.2.1.1 as-number 10
[RouterE-bgp] ipv4-family unicast
[RouterE-bgp-af-ipv4] network 10.3.1.0 30
[RouterE-bgp-af-ipv4] quit
Step 5 Set the cost of OSPF on Router C.

[RouterC-Pos1/0/0] ospf cost 2
[RouterC-Pos2/0/0] ospf cost 2
NOTE
After the cost of OSPF on Router C is set to 2, Router A chooses only Router B as the intermediate router
to the network segment 10.2.1.0. Router C becomes the backup router of Router B.
# View the routing table of Router A. As shown in the routing table, the route to the network
segment 10.3.1.0 can be learned through BGP, and the outgoing interface is POS 1/0/0.
Route Flags: R - relied, D - download to fib
------------------------------------------------------------------------------
2.2.2.2/32 OSPF 10 3 D 10.1.1.2 Pos1/0/0
4.4.4.0/24 IBGP 255 0 RD 4.4.4.4 Pos1/0/0
4.4.4.4/32 OSPF 10 3 D 10.1.1.2 Pos1/0/0
5.5.5.0/24 EBGP 255 0 RD 10.2.1.2 Pos1/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0


10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/30 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/30 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.1.3.1/32 IBGP 255 0 RD 4.4.4.4 Pos1/0/0
10.1.4.0/30 OSPF 10 3 D 10.1.1.2 Pos1/0/0
OSPF 10 3 D 10.1.2.2 Pos2/0/0
10.1.4.1/32 IBGP 255 0 RD 4.4.4.4 Pos1/0/0
10.2.1.0/30 EBGP 255 0 RD 4.4.4.4 Pos1/0/0
10.2.1.2/32 EBGP 255 0 RD 4.4.4.4 Pos1/0/0
10.3.1.0/30 EBGP 255 0 RD 4.4.4.4 Pos1/0/0
# View the routing table of Router B.

------------------------------------------------------------------------------
1.1.1.1/32 OSPF 10 2 D 10.1.1.1 Pos1/0/0
4.4.4.0/24 IBGP 255 0 RD 10.1.3.2 Pos2/0/0
4.4.4.4/32 OSPF 10 2 D 10.1.3.2 Pos2/0/0
5.5.5.0/24 EBGP 255 0 RD 10.2.1.2 Pos2/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.2.0/30 OSPF 10 2 D 10.1.1.1 Pos1/0/0
10.1.3.0/30 Direct 0 0 D 10.1.3.1 Pos2/0/0
10.1.3.2/32 Direct 0 0 D 10.1.3.2 Pos2/0/0
10.1.4.0/30 OSPF 10 2 D 10.1.3.2 Pos2/0/0
10.1.4.1/32 IBGP 255 0 RD 10.1.3.2 Pos2/0/0
10.2.1.0/30 EBGP 255 0 RD 10.1.3.2 Pos2/0/0
10.2.1.2/32 EBGP 255 0 RD 10.1.3.2 Pos2/0/0
10.3.1.0/30 EBGP 255 0 RD 10.1.3.2 Pos2/0/0
As shown in the routing table, Router B learns the route to the network segment 10.3.1.0 through
BGP, and the outgoing interface is POS 2/0/0. The routes to the network segments 10.1.2.0 and
10.1.4.0 respectively can be learned through OSPF. The costs of the two routes are 2.
Step 6 Enable OSPF-BGP linkage on Router B.
[RouterB] ospf 1
[RouterB-ospf-1] stub-router on-startup
[RouterB] quit

# Restart Router B.
NOTE
Confirm the action before you use the command because the command leads to the breakdown of the
network in a short time. In addition, when restarting a router, ensure that the configuration file of the
router is saved.
<RouterB> reboot
System will reboot! Continue?[Y/N] y
# View the routing table of Router A. As shown in the routing table, the route to the network
10.3.1.0 can be learned through BGP, and the outgoing interface is POS 2/0/0.


------------------------------------------------------------------------------
2.2.2.2/32 OSPF 10 4 D 10.1.2.2 Pos2/0/0
4.4.4.0/24 IBGP 255 0 RD 4.4.4.4 Pos2/0/0
4.4.4.4/32 OSPF 10 4 D 10.1.2.2 Pos2/0/0
5.5.5.0/24 EBGP 255 0 RD 10.2.1.2 Pos2/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.2.0/30 Direct 0 0 D 10.1.2.1 Pos2/0/0
10.1.2.2/32 Direct 0 0 D 10.1.2.2 Pos2/0/0
10.1.3.0/30 OSPF 10 2 D 10.1.1.2 Pos1/0/0
10.1.3.1/32 IBGP 255 0 RD 4.4.4.4 Pos2/0/0
10.1.4.0/30 OSPF 10 3 D 10.1.2.2 Pos2/0/0
10.1.4.1/32 IBGP 255 0 RD 4.4.4.4 Pos2/0/0
10.2.1.0/30 EBGP 255 0 RD 4.4.4.4 Pos2/0/0
10.2.1.2/32 EBGP 255 0 RD 4.4.4.4 Pos2/0/0
10.3.1.0/30 EBGP 255 0 RD 4.4.4.4 Pos2/0/0
# View the routing table of Router B. As shown in the routing table, only OSPF routes exist in
the routing table temporarily and their costs are equal to or greater than 65535. This is because
IGP route convergence is faster than BGP route convergence.
------------------------------------------------------------------------------
1.1.1.1/32 OSPF 10 65536 D 10.1.1.1 Pos1/0/0
4.4.4.4/32 OSPF 10 65536 D 10.1.3.2 Pos2/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.2.0/30 OSPF 10 65536 D 10.1.1.1 Pos1/0/0
10.1.3.0/30 Direct 0 0 D 10.1.3.1 Pos2/0/0
10.1.3.2/32 Direct 0 0 D 10.1.3.2 Pos2/0/0
10.1.4.0/30 OSPF 10 65536 D 10.1.3.2 Pos2/0/0

------------------------------------------------------------------------------
1.1.1.1/32 OSPF 10 2 D 10.1.1.1 Pos1/0/0
4.4.4.0/24 IBGP 255 0 RD 10.1.3.2 Pos2/0/0
4.4.4.4/32 OSPF 10 2 D 10.1.3.2 Pos2/0/0
5.5.5.0/24 EBGP 255 0 RD 10.2.1.2 Pos2/0/0
10.1.1.0/30 Direct 0 0 D 10.1.1.2 Pos1/0/0
10.1.1.1/32 Direct 0 0 D 10.1.1.1 Pos1/0/0
10.1.2.0/30 OSPF 10 2 D 10.1.1.1 Pos1/0/0
10.1.3.0/30 Direct 0 0 D 10.1.3.1 Pos2/0/0

10.1.3.2/32 Direct 0 0 D 10.1.3.2 Pos2/0/0

10.1.4.0/30 OSPF 10 2 D 10.1.3.2 Pos2/0/0
10.1.4.1/32 BGP 255 0 RD 10.1.3.2 Pos2/0/0
10.2.1.0/30 BGP 255 0 RD 10.1.3.2 Pos2/0/0
10.2.1.2/32 BGP 255 0 RD 10.1.3.2 Pos2/0/0
10.3.1.0/30 BGP 255 0 RD 10.1.3.2 Pos2/0/0
As shown in the routing table, after BGP route convergence on Router B is complete, the contents
of the routing information are the same as those before the router restarts.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.1 255.255.255.252
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.1.2.1 255.255.255.252
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 10
router-id 1.1.1.1
peer 2.2.2.2 connect-interface LoopBack 0
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.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 RouterB
#
router id 2.2.2.2
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.1.2 255.255.255.252

#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.1.3.1 255.255.255.252
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 10
router-id 2.2.2.2
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.1.3.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.4.1 255.255.255.252
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.1.2.2 255.255.255.252
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 10
router-id 3.3.3.3
#
ipv4-family unicast
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ospf 1

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

#
sysname RouterD
#
router id 4.4.4.4
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 10.1.4.2 255.255.255.252
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.1.3.2 255.255.255.252
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 10.2.1.1 255.255.255.252
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 10
router-id 4.4.4.4
#
ipv4-family unicast
import-route direct
import-route ospf 1
peer 2.2.2.2 enable
peer 1.1.1.1 enable
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.1.3.0 0.0.0.3
network 10.1.4.0 0.0.0.3
#
return

#
sysname RouterE
#
router id 5.5.5.5
#
interface Pos1/0/0
link-protocol ppp
undo shutdown

ip address 10.2.1.2 255.255.255.252

#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 10.3.1.1 255.255.255.252
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
#
bgp 20
router-id 5.5.5.5
#
ipv4-family unicast
network 10.3.1.0 255.255.255.252
#
return
5.16.12 Example for Configuring OSPF GTSM

This part provides an example for configuring OSPF GTSM. Detailed operations include
enabling GTSM on each router and specifying the valid TTL range of packets.
As shown on the network shown in Figure 5-17,routers run OSPF and GTSM is enabled on
Router A, Router B, and Router C.
Figure 5-17 Networking diagram of OSPF GTSM
RouterB
Virtual Link
POS1/0/0
192.168.1.2/24
GE1/0/0 GE3/0/0 POS1/0/0

10.1.1.2/8 10.1.1.1/8 192.168.1.1/24
Network POS2/0/0
192.168.2.1/24
RouterD RouterA
POS2/0/0
Area0 192.168.2.2/24
Virtual Link
RouterC
Area1
1. Configure OSPF.

2. Enable GTSM on each router and specify a valid TTL range for packets.
Data Preparation
l OSPF process ID on each router

l Valid TTL range on each router
Procedure
Step 1 Configure an IP address for each interface. This example assumes that you know the
configuration method and no details are provided here.
Step 3 Configure OSPF GTSM.
# On Router A, set the maximum valid TTL range for packets from Router A to other routers is
255 to 255.
[RouterA] ospf valid-ttl-hops 1
# On Router B, set the maximum valid TTL range for packets from Router B to other routers is
254 to 255.
[RouterB] ospf valid-ttl-hops 2
# On Router C, set the maximum valid TTL range for packets from Router C to other routers is
254 to 255.
[RouterC] ospf valid-ttl-hops 2
# Check whether OSPF neighbor relationships between routers are successfully established.
Take the display on Router C as an example. The neighbor relationship is Full, indicating that
the neighbor relationship is successfully established.
[RouterC] display ospf peer

Neighbors

# On Router C, run the display gtsm statistics all command. You can view GTSM statistics on
Router C. The default behavior is pass, no illegal packets exist, and the number of discarded
packets is 0.
<RouterC> display gtsm statistics all


----------------------------------------------------------------
----------------------------------------------------------------
1 BGP 0 0 0
1 BGPv6 0 0 0
1 OSPF 0 0 0
1 LDP 0 0 0
1 OSPFv3 0 0 0
1 RIP 0 0 0
2 BGP 0 0 0
2 BGPv6 0 0 0
2 OSPF 0 0 0
2 LDP 0 0 0
2 OSPFv3 0 0 0
2 RIP 0 0 0
3 BGP 0 0 0
3 BGPv6 0 0 0
3 OSPF 0 0 0
3 LDP 0 0 0
3 OSPFv3 0 0 0
3 RIP 0 0 0
4 BGP 0 0 0
4 BGPv6 0 0 0
4 OSPF 0 0 0
4 LDP 0 0 0
4 OSPFv3 0 0 0
4 RIP 0 0 0
5 BGP 0 0 0
5 BGPv6 0 0 0
5 OSPF 0 0 0
5 LDP 0 0 0
5 OSPFv3 0 0 0
5 RIP 0 0 0
7 BGP 0 0 0
7 BGPv6 0 0 0
7 OSPF 0 0 0
7 LDP 0 0 0
7 OSPFv3 0 0 0
7 RIP 0 0 0
----------------------------------------------------------------
----End
Configuration files
#
sysname RouterA
#
router id 1.1.1.1
#
undo shutdown
ip address 10.1.1.1 255.0.0.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.1 255.255.255.0
#

ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
vlink-peer 2.2.2.2
vlink-peer 3.3.3.3
#
ospf valid-ttl-hops 1
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 1.1.1.1
#
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.2.0 0.0.0.255
vlink-peer 1.1.1.1
#
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
undo shutdown
ip address 10.1.1.2 255.0.0.0
#
ospf 1
area 0.0.0.0
network 10.1.1.2 0.0.0.255
#

#
return

Configuration Guide - IP Routing 6 OSPFv3 Configuration
6 OSPFv3 Configuration
About This Chapter
By building Open Shortest Path First Version 3 (OSPFv3) networks, you can enable OSPFv3
to discover and calculate routes in ASs. OSPFv3 is applicable to a large-scale network that
consists of hundreds of routers.
6.1 Introduction
The OSPFv3 protocol, which is a link-state IGP, runs on IPv6 networks.
6.2 Configuring Basic OSPFv3 Functions

Before building OSPFv3 networks, you need to configure basic OSPFv3 functions.
6.3 Establishing or Maintaining OSPFv3 Neighbor Relationship

By establishing and maintaining OSPFv3 neighbor relationships or adjacencies, you can build
OSPFv3 networks.
6.4 Configuring OSPFv3 Areas

OSPFv3 supports stub areas and virtual links, the principle and usage scenario of which are
similar to those in OSPFv2.
6.5 Configuring OSPFv3 NSSA Areas

learned from other areas in the AS but imports AS external routes. This reduces bandwidth and
6.6 Configuring OSPFv3 Route Attributes

By setting OSPFv3 route attributes, you can change OSPFv3 routing policies to meet the
requirements of complex networks.
6.7 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.
6.8 Optimizing an OSPFv3 Network

By configuring OSPFv3 functions in special network environments, you can adjust and optimize
the OSPFv3 network performance.
6.9 Configuration OSPFv3 GR

By configuring OSPFv3 GR, you can avoid inaccurate route calculation and packet loss after
an OSPFv3 device restarts.
6.10 Configuring BFD for OSPFv3

If there are high requirements for data transmission, and OSPFv3 convergence needs to be
speeded up when the link status changes, you can configure BFD on OSPFv3 links. After
detecting a link failure, BFD notifies the routing protocol of the failure, which triggers fast
convergence. When the neighbor relationship is Down, the BFD session is deleted dynamically.
6.11 Configuring OSPFv3 IP FRR

With OSPFv3 IP FRR, devices can rapidly switch traffic from faulty links to backup links
without interrupting traffic. This protects traffic and greatly improves the reliability of OSPFv3
networks.
6.12 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.
6.13 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.
6.14 Configuring the Network Management Function of OSPFv3

OSPFv3 supports the network management function. You can bind the OSPFv3 MIB to a certain
OSPFv3 process.
6.15 Maintaining OSPFv3

Maintaining OSPFv3 and Debugging OSPFv3 involve resetting OSPFv3.

This section provides several configuration examples of OSPFv3 together with the Networking

6.1 Introduction
The OSPFv3 protocol, which is a link-state IGP, runs on IPv6 networks.
6.1.1 OSPFv3 Overview

OSPFv3 uses the same implementation mechanism as OSPFv2 but is not compatible with
OSPFv2.
The Open Shortest Path First Version 3.0 (OSPFv3) supports the version 6 of the Internet
Protocol (IPv6). OSPFv3 conforms to RFC 2740 (OSPF for IPv6).
OSPFv3 and OSPFv2 have the following in common:
l 32-bit Router ID, Area ID, and Link State Advertisement (LSA) link-state ID
l Five types of packets such as Hello, Database Description (DD), Link State Request (LSR),
Link State Update (LSU), and Link State Acknowledgement (LSAck) packets
l Neighbor discovery and adjacency establishment mechanisms
l Flooding and aging mechanisms of LSAs
l LSA types
OSPFv3 and OSPFv2 differ as follows:
l OSPFv3 runs based on a link; OSPFv2 runs based on a network segment.

l OSPFv3 can run multiple instances on the same link.
l The topology of OSPFv3 is independent of IPv6 address prefixes.
l OSPFv3 identifies its neighbors with the IPv6 link-local addresses.
l OSPFv3 has three new types of LSA flooding scopes.
6.1.2 OSPFv3 Features Supported by NE80E/40E

The NE80E/40E supports various OSPFv3 features, including multi-process and GR.
The NE80E/40E supports the following OSPFv3 features:
l Basic features stipulated in RFC 2740

l OSPFv3 stub areas
l OSPFv3 multi-process
l Multiple OSPFv3 processes can run on a router.
l OSPFv3 GR
– If a router restarts or performs the active/standby switchover, it directly ages all the
entries in the Forward Information Base (FIB). This interrupts the routing. The
neighboring routers remove the router from the neighbor list and inform other routers
of the router failure. Then, SPF needs to be calculated again. If the router recovers after
a short period of time, the neighbor relationship becomes unstable. This results in route
flapping.

– If a router restarts because of abnormalities, you can enable OSPFv3 Graceful Restart
(GR) to avoid service interruption during the restart of the router.
6.2 Configuring Basic OSPFv3 Functions

Before building OSPFv3 networks, you need to configure basic OSPFv3 functions.

You need to enable OSPFv3 and specify interfaces and area IDs before configuring other
functions.
Enable the OSPFv3 process and specify its router ID before configuring OSPFv3; otherwise,
other functions cannot take effect.
You must enable OSPFv3 and specify the interface and area ID before configuring other
functions. OSPFv3 configurations, however, are independent of interface-related features.
Before configuring basic OSPFv3 functions, complete the following tasks:
l Making the network layers of the adjacent nodes accessible

l Enabling IPv6 capabilities
Data Preparation
To configure basic OSPFv3 functions, you need the following data.
No. Data
1 Router ID
2 OSPFv3 process ID
3 Interfaces on which OSPFv3 needs to be enabled and their areas
6.2.2 Enabling OSPFv3

Creating an OSPFv3 process is a prerequisite for configuring all OSPFv3 features. By creating
an OSPFv3 process, you can manually specify the router ID for a router.
Context
OSPFv3 supports multiple processes. Multiple OSPFv3 processes running on one router are
differentiated by process IDs. OSPFv3 process ID is set when OSPFv3 is enabled and is only
locally valid. It does not affect the packet exchange with other routers.

In the format of an IPv4 address, a router ID is a 32-bit unsigned integer that uniquely identifies
a router within an AS. The router ID of OSPFv3 must be manually set. If no router ID is set,
OSPFv3 fails to run normally.
When manually setting the router ID, ensure that the router IDs of any two routers in an AS are
different. When multiple processes are enabled on a router, it is necessary to specify a unique
route ID for each process.
To ensure the stable running of OSPFv3, you need to allocate router IDs and set them in network
planning.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 [ process-id ] [ vpn-instance vpn-instance-name ]
OSPFv3 is enabled and the OSPFv3 view is displayed.
Step 3 Run:
router-id router-id
A Router ID is set.
----End
6.2.3 Enabling OSPFv3 on an Interface

For an interface with multiple instances, you need to specify which instance of the interface is
enabled in the OSPFv3 process when enabling OSPFv3 on the interface.
Context
After enabling OSPFv3 in the system view, you need to enable OSPFv3 on the interface. Because
an interface has multiple instances, you need to specify which instance of the interface is enabled
in the OSPFv3 process when OSPFv3 is enabled on the interface. If no instance ID is specified,
the value defaults to 0. The same instance must be enabled on the interfaces between which the
neighbor relationship is set up.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:

ospfv3 process-id area area-id [ instance instance-id ]
OSPFv3 is enabled on the interface.
The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the IPv4
address format.
Step 4 (Optional) Run the ospfv3 network-type { broadcast | nbma | p2mp [ non-broadcast ] |
p2p } [ instance instance-id ] command to configure the network type of an interface.
When an interface supports multi-instances, you must specify the value of instance-id when
enabling OSPFv3 on the interface. If the value of instance-id is not specified, the default value
0 is adopted. In this case, the configured network type of an interface mismatches the actual
network type of the interface. This step is mandatory in such a case.
----End
6.2.4 Entering the OSPFv3 Area View

By dividing an AS into different areas, specifying OSPFv3 interfaces, and specifying areas to
which these interfaces belong, OSPFv3 can discover and calculate routes in an AS.
Context
You must configure the devices in the same area based on the area. Otherwise, the neighbor
devices cannot exchange information with each other. The congestion of routing information or
routing loop is therefore caused.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 [ process-id ]
The OSPFv3 view is displayed.
Step 3 Run:
area area-id
The OSPFv3 area view is displayed.
The area ID can be a decimal integer or in the IPv4 address format, but it is displayed in the IPv4
address format.
An OSPFv3 area cannot be deleted directly. Only after all the configurations in the area view
are removed and the status of the related interfaces in this area become Down, this area is
automatically removed.
----End


After basic OSPFv3 functions are configured, you can check OSPFv3 brief information, LSDB
information, neighbor information, and OSPFv3 routing table.
Prerequisites
The Basic OSPFv3 Functions has been configured.
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 [ abr-routes | asbr-routes | statistics
[ uninstalled ] | ipv6-address prefix-length | intra-routes | inter-routes | ase-routes |
nssa-routes ]
l Run the display ospfv3 [ process-id ] path command to check the paths to a destination
address.
l Run the display default-parameter ospfv3 command to check the default OSPFv3
configuration.
----End
6.3 Establishing or Maintaining OSPFv3 Neighbor

Relationship
By establishing and maintaining OSPFv3 neighbor relationships or adjacencies, you can build
OSPFv3 networks.

When setting parameters on an interface, ensure that these parameters are consistent with those
on the adjacent router.

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 Enabling IPv6 capability

l Configuring Basic OSPFv3 Functions
Data Preparation
To establish or maintain the OSPFv3 neighbor relationship, you need the following data.
No. Data
1 Interval for sending Hello packets
2 Dead time of the neighbor relationship
3 Interval for retransmitting LSAs to adjacent routers
4 Delay in sending LSAs
6.3.2 Configuring the Interval for Sending Hello Packets

By adjusting the Hello interval set on OSPFv3 neighbors, you can change the speed of
establishing the neighbor relationship, therefore changing the speed of network convergence.
Context
Hello packets are periodically sent to the neighbor router to detect and maintain the neighbor
relationship and to elect the DR and the BDR. RFC 2328 requires that the Hello timer values of
neighbors be consistent. The value of the Hello timer is inversely proportional to the route
convergence speed and network load.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 timer hello interval [ instance instance-id ]
The interval for sending Hello packets is set on the interface.
----End
6.3.3 Configuring Dead Time of Neighbor Relationship

If a router does not receive a Hello packet from its neighbor within the Holddown time, the router
considers the neighbor relationship invalid.
Context
If a router does not receive any Hello packet from its neighbor during a specified period, the
neighbor router is considered invalid. The specified period is called the dead time of the neighbor
relationship. The dead time must be at least four times the Hello interval on an interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 timer dead interval [ instance instance-id ]
The dead time of the neighbor relationship is specified.
----End
6.3.4 Configuring the Interval for Retransmitting LSAs to

Neighboring Routers
After a router sends an LSA to its neighbor, the router expects to receive an LSAck packet from
its neighbor. If the router does not receive an LSAck packet within the LSA retransmission
interval, it retransmits the LSA to the neighbor.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 timer retransmit interval [ instance instance-id ]
The interval for retransmitting LSAs to the adjacent routers is set.
The value of seconds must be greater than the time taken to transmit a packet between two
routers.
NOTE
Do not set a value which is too small, for the interval between LSA retransmissions. Otherwise, unnecessary
retransmissions may occur.
----End
6.3.5 Configuring the Delay for Transmitting LSAs on the Interface

It takes time to transmit OSPFv3 packets on a link. Therefore, a certain delay is added to the
aging time of an LSA before the LSA is sent.
Context
The LSA ages out in the LSDB of a local router instead of in the transmission process. You need
to set the delay for an LSA before sending it. For a low-speed network, this configuration is
necessary.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 trans-delay interval [ instance instance-id ]
The delay in transmitting LSAs on the interface is set.
----End


After OSPFv3 neighbor relationships or adjacencies are stable, you can check OSPFv3 interface
information and neighbor information.
Prerequisites
The Establishing or Maintaining OSPFv3 Neighbor Relationship has been configured.
Procedure
l Run the display ospfv3 [ process-id ] interface [ area area-id ] [ interface-type interface-
----End
6.4 Configuring OSPFv3 Areas

OSPFv3 supports stub areas and virtual links, the principle and usage scenario of which are
similar to those in OSPFv2.

Configuring a stub area is optional. Not all areas can be configured as stub areas. Generally, a
stub area, which is located at the AS boundary, is a non-backbone area with only one ABR.
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.
The current NE80E/40E version does not support OSPFv3 NSSA areas.
Before configuring OSPFv3 area attributes, complete the following tasks:

Data Preparation
To configure OSPFv3 area attributes, you need the following data.
No. Data
1 Areas to be defined as stub areas
2 Metrics of default routes sent to stub areas

6.4.2 Configuring OSPFv3 Stub Areas

A stub area is a special area in which ABRs do not flood the received AS external routes.
Therefore, the number of LSAs is greatly reduced.
Context
Perform the following steps on each router 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 routers in the
stub area.
The parameter no-summary takes effect only when the stub command is configured on the
ABR. If this parameter is configured, the ABR only sends the summary-LSA of a default route
to the stub area without originating other summary-LSAs. The stub area without AS-external-
LSAs or Summary-LSAs is called a totally stub area.
----End
6.4.3 Configuring OSPFv3 Virtual Links

You can establish the logical connectivity between backbone areas and the non-backbone areas
that are not physically connected to the backbone area.
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 neighbor-id [ hello hello-interval | retransmit retransmit-interval |
trans-delay trans-delay-interval | dead dead-interval | { ipsec sa sa-name |
authentication-mode { hmac-sha256 key-id key-id { plain plain-text | [ cipher ]
cipher-text } | keychain keychain-name } } | instance instance-id ] *
A virtual link is created and configured.
----End

After OSPFv3 area attributes are configured, you can check the OSPFv3 LSDB, routing table,
and virtual links.
Prerequisites
The OSPFv3 Areas has been configured.
Procedure


nssa-routes ]
l Run the display ospfv3 [ process-id ] vlink command to check the information about
OSPFv3 virtual links.
----End
6.5 Configuring OSPFv3 NSSA Areas

learned from other areas in the AS but imports AS external routes. This reduces bandwidth and

Before configuring OSPFv3 NSSA areas, familiarize yourself with the usage scenario, complete
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:

l Configuring basic OSPFv3 functions
Data Preparation
To configure an OSPFv3 NSSA, you need the following data.
No. Data
1 Cost of the default route sent to an NSSA
6.5.2 Defining the Current Area to Be an NSSA Area

Derived from a stub area, an NSSA allows AS external routes to be imported; an ASBR
advertises Type 7 NSSA LSAs in the local NSSA.
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
To connect routers to an NSSA, you need to run the nssa command to configure NSSA attributes
for the area to which the routers belong.
The area may be updated after NSSA attributes are configured or deleted. Therefore, the NSSA
attributes can be re-configured or deleted only after the last update of NSSA attributes is
complete.

After OSPFv3 NSSAs are configured, you can check OSPFv3 routing table information.
Prerequisites
OSPFv3 NSSAs has been configured.
Procedure
l Run the display ospfv3 area command to check information about OSPFv3 areas.
l Run the commands as follow to check the OSPFv3 routing table.
nssa-routes ]
----End
6.6 Configuring OSPFv3 Route Attributes

By setting OSPFv3 route attributes, you can change OSPFv3 routing policies to meet the
requirements of complex networks.


Before configuring OSPFv3 route attributes, familiarize yourself with the usage scenario,
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:

Data Preparation
To configure OSPFv3 route attributes, you need the following data.
No. Data
1 Link cost
6.6.2 Setting the Cost of the OSPFv3 Interface

OSPFv3 can automatically calculate the link cost for an interface according to the interface
bandwidth. You can also set the link cost for the interface by using the related command.
Context
You can control route calculation by setting the link cost of OSPFv3 on different interfaces.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
ospfv3 cost cost [ instance instance-id ]
The cost is set on the OSPFv3 interface.
By default, the link cost on an OSPFv3 interface is 1.
----End
6.6.3 Setting the Maximum Number of Equal-Cost Routes

If the destinations and costs of the multiple routes discovered by one routing protocol are the
same, load balancing can be performed among these routes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
about route preference configuration, see Step 4.

The route preferences are configured for load balancing.
To specify valid routes for load balancing, run the nexthop command to set the route preference.
Ensure that the preferences of valid routes to be used must be high.
The smaller the weight value, the higher the preference of the route. The default weight value
is 255, which indicates that load balancing is implemented regardless of the route preferences.
----End


After OSPFv3 route attributes are configured, you can check the OSPFv3 interface, LSDB, and
routing table.
Prerequisites
The OSPFv3 Route Attributes has been configured.
Procedure
l Run the display ospfv3[ process-id ] interface [ area area-id ] [ interface-type interface-
nssa-routes ]
----End
6.7 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.

Before controlling OSPFv3 routing information, familiarize yourself with the usage scenario,
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:

Data Preparation
To control OSPFv3 routing information, you need the following data.
No. Data
1 Prefix of IPv6 routes after aggregation
2 Filtering list or name used to filter routing information
3 Link cost on an OSPFv3 interface
5 Name, process ID, and metric of external routes to be imported
6.7.2 Configuring OSPFv3 Route Aggregation

An ABR can summarize routes with the same prefix into one LSA and advertise the summarized
route in other areas. An ASBR can also summarize imported routes with the same prefix into
one LSA and then advertise the summarized route to other areas. This can reduce the size of the
LSDB in other areas.
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, therefore reducing the LSDB size of other areas.
When a large number of routes are imported, use the asbr-summary command to summarize
the imported routes and set the delay for advertising the summarized route. In this manner, the
summarized route advertised each time contains more valid routing information, and network
flapping caused by incorrect routing information is avoided.
Procedure
l Configure route summarization on an ABR.
Perform the following steps on the ABR that runs OSPFv3:
1. Run:
system-view

2. Run:

3. Run:
area area-id


4. Run:
abr-summary ipv6-address prefix-length [ cost cost | not-advertise ]*
Route summarization is configured in the OSPFv3 area.
cost cost set the cost of a summarized route. By default, the cost of a summarized
route is the maximum cost among those of routes that are summarized. The value
ranges from 1 to 16777214.
If not-advertise is set, no routing information of the network segment is advertised.

l Configure route summarization on an ASBR.
Perform the following steps on the ASBR that runs OSPFv3:
1. Run:
system-view

2. Run:

3. Run:
asbr-summary ipv6-address prefix-length [ cost cost | tag tag | not-
advertise | distribute-delay interval ] *
Route summarization is configured on the ASBR.
cost cost specifies the cost of a summarized route. By default, the cost of a summarized
route is the maximum cost among those of routes that are summarized. The value
ranges from 1 to 16777214.
tag tag specifies the tag used to control route advertisement. The value of this
parameter ranges from 1 to 4294967295.
If not-advertise is specified in the command, the summarized IPv6 route that matches
a specified IPv6 prefix or prefix length is not advertised.
distribute-delay interval specifies the delay for advertising a summarized route.
----End
6.7.3 Configuring OSPFv3 to Filter the Received Routes

By configuring filtering conditions for routing information, you can allow only the routes that
pass the filtering to be received or advertised.
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:

l Configure a basic ACL:
1. Run:
filter-policy { acl6-number | acl6-name acl6-name } import
OSPFv3 is configured to filter the imported routes.

2. Run:
quit

3. Run
acl ipv6 { [ number ] acl6-number1 | name acl-name [ number acl-number2 ] }

4. Run

address range specified by source and the time period specified by time-range are valid
as the rules.
by the system.

l Configure an advanced ACL:
1. Run:
filter-policy acl6-name acl6-name import

2. Run:
quit

3. Run
config } ]

4. Run
rule [ rule-id ] { deny | permit } protocol [ source { source-ipv6-address
prefix-length | source-ipv6-address/prefix-length | any } | time-range time-
name ] *

by the system.

Run:
filter-policy ipv6-prefix ipv6-prefix-name import
Using the filter-policy command, you can only filter the routes calculated by OSPFv3. Routes
that do not pass the filtering are neither added to the OSPFv3 routing table nor advertised.
----End
6.7.4 Configuring OSPFv3 to Import External Routes

Importing the routes discovered by other routing protocols can enrich OSPFv3 routing
information.
Context
Because OSPFv3 is a link state-based routing protocol and cannot directly filter the advertised
LSAs, OSPFv3 must filter the routes when importing them. Then, only the routes that pass the
filtering can be advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
default { cost cost | tag tag | type type } *
The default cost of the imported route is set.
Step 4 Run:
import-route protocol [ process-id ] [ { cost cost | inherit-cost } | type type |
tag tag | route-policy route-policy-name ] *
External routes are imported.

import-route bgp [ permit-ibgp ] [ { cost cost | inherit-cost } | type type | tag
tag | route-policy route-policy-name ] *
IBGP routes are imported in OSPFv3 process.
NOTE
Importing IBGP routes in OSPFv3 process can lead to routing loops.

default-route-advertise [ always | cost cost | type type | tag tag | route-policy
route-policy-name [ match-any ] ] *

Default routes are advertised to the OSPFv3 route area.

1. Run:
filter-policy { acl6-number | acl6-name acl6-name } export [ protocol
[ process-id ] ]
The imported external routes are filtered.

2. Run:
quit

3. Run

4. Run

as the rules.
by the system.

1. Run:
filter-policy acl6-name acl6-name export [ protocol [ process-id ] ]

2. Run:
quit

3. Run
config } ]

4. Run
name ] *

by the system.
Run:
filter-policy ipv6-prefix ipv6-prefix-name export [ protocol [ process-id ] ]

s
After you run the import-route command on an OSPFv3 device to import external routes, the
router becomes an ASBR.

You can configure OSPFv3 to filter a certain type of routing information by specifying the
protocol. If protocol is not specified, OSPFv3 filters all the imported routes.
NOTE
The filter-policy command takes effect only on the routes imported through the import-route command
by the ASBR, that is, filters the imported routes. The routes that are filtered out do not generate LSAs and
cannot be advertised by OSPFv3. If the import-route command is not configured to import other external
routes (including OSPFv3 devices in different processes), the filter-policy command does not takes effect.
----End
6.7.5 (Optional) Configuring OSPFv3 to Filter LSAs in an Area

Filtering LSAs in an area can prevent unnecessary LSA transmission. This reduces the size of
the LSDB on the neighboring router and speeds up network convergence.
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 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 any of the following commands as required:
1. Run:
filter { acl6-number | acl6-name acl6-name } import

2. Run:
quit
Return to the OSPFv3 view.

3. Run:
quit


4. Run

5. Run

valid as the rules.
routes.
1. Run:
filter acl6-name acl6-name import

2. Run:
quit

3. Run:
quit


4. Run
config } ]

5. Run
range time-name ] *

routes.
Run:
filter ipv6-prefix ipv6-prefix-name import

Run:
filter route-policy route-policy-name import

l Filter outgoing Type 3 LSAs in the area, run any of the following commands as required:
1. Run:
filter { acl6-number | acl6-name acl6-name } export


2. Run:
quit

3. Run:
quit

4. Run

5. Run

valid as the rules.
routes.
1. Run:
filter acl6-name acl6-name export


2. Run:
quit

3. Run:
quit

4. Run
config } ]

5. Run
range time-name ] *

routes.
Run:
filter ipv6-prefix ipv6-prefix-name export

Run:

filter route-policy route-policy-name export
----End

After OSPFv3 route attributes are configured, you can check the OSPFv3 interface, LSDB, and
routing table.
Prerequisites
Controlling OSPFv3 Routing Information has been configured.
Procedure
l Run the commands as follow to check the OSPFv3 route aggregation:
– display ospfv3 [ process-id ] abr-summary-list [ ipv6-address prefix-length ]
– display ospfv3 [ process-id ] asbr-summary [ ipv6-address prefix-length ]
[ verbose ]
nssa-routes ]
----End
6.8 Optimizing an OSPFv3 Network

By configuring OSPFv3 functions in special network environments, you can adjust and optimize
the OSPFv3 network performance.

Before optimizing an OSPFv3 network, familiarize yourself with the usage scenario, complete
pre-configuration tasks, and obtain the required data. This can help you complete the
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:

Data Preparation
To optimize an OSPFv3 network, you need the following data.
No. Data
1 Values of OSPFv3 timers
2 Values of SPF timers
3 DR priority of the interface
6.8.2 Configuring the SPF Timer

By setting the interval for SPF calculation, you can reduce resource consumption caused by
frequent network changes.
Context
Whenever the LSDB of OSPFv3 changes, the shortest path should be recalculated. Calculating
the shortest path each time the LSDB changes consumes enormous resources and lowers the
efficiency of a router.
Adjusting the SPF delay and hold interval can suppress frequent network changes to avoid
resource consumption.
Procedure
l Configure an SPF normal timer.
1. Run:
system-view

2. Run:

3. Run:

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

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

2. Run:

3. Run:
spf-schedule-interval { delay-interval hold-interval | intelligent-timer
max-interval start-interval hold-interval-1 }
An SPF intelligent timer is configured.
NOTE
An SPF normal timer and an SPF intelligent timer are mutually exclusive.
----End
6.8.3 Setting the Interval for Receiving LSAs

Setting the interval for receiving LSAs prevents unnecessary LSA updates.
Context
When a network is unstable, control the minimum interval for receiving the same LSA update.
To prevent unnecessary LSA updates caused by network changes, by default, set the interval for
receiving the same LSA update to 1000 ms.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
lsa-arrival-interval arrival-interval
The interval for receiving LSAs is set.
----End
6.8.4 Configuring an Intelligent Timer for Generating LSAs

Configuring an intelligent timer for generating LSAs speeds up network convergence.

Context
Setting the millisecond-level interval for generating the same LSA speeds up network
convergence. When a network becomes unstable, reduce the interval for generating the same
LSA by using an intelligent timer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
lsa-originate-interval intelligent-timer max-interval start-interval hold-interval
The interval for generating the same LSA is set.
l max-interval specifies the maximum interval for updating LSAs.

l start-interval specifies the initial interval for updating LSAs.
l hold-interval specifies the hold interval for updating LSAs.
----End
6.8.5 Suppressing an Interface from Sending and Receiving OSPFv3

Packets
By suppressing the OSPFv3 interface from receiving and sending OSPFv3 packets, you can
prevent routers on a certain network from obtaining OSPFv3 routing information and prevent
the local router from receiving routing information from other routers.
Context
To prevent a router from advertising routes to the router on a certain network and from importing
the routes of other routers, you can suppress the interface on which OSPFv3 is enabled from
receiving and sending OSPFv3 packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
silent-interface interface-type interface-number
The interface is suppressed from sending and receiving OSPFv3 packets.
----End
Follow-up Procedure
Different processes can suppress the same interface from sending and receiving OSPFv3 packets,
but the silent-interface command is valid only for the OSPFv3 interface on which the specified
process is enabled, and does not take effect on the interface of other processes.
After an OSPFv3 interface is set to be silent, the interface can still advertise its direct routes
through the Intra-Area-Prefix-LSA of the same router. No OSPFv3 neighbor relationship can
be set up on the interface. Therefore, the OSPFv3 adaptability is enhanced.
6.8.6 Configuring DR Priority of an Interface

When configuring a broadcast network or an NBMA network, you can specify the DR priority
for each interface to change the results of DR/BDR election on the network.
Context
The DR priority on a router interface qualifies the interface for the Designated Router (DR)
election. If the DR priority is 0, the router cannot be elected as a DR or Backup Designated
Router (BDR).
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 dr-priority priority [ instance instance-id ]
The DR priority of the interface is set.
----End
Follow-up Procedure
After the DR priority is changed, you can re-elect a DR or BDR through the following methods,
which, however, will result in the interruption of the OSPFv3 neighbor relationship between
routers and therefore are used only when necessary.
l Restarting all routers.

l Running the shutdown and undo shutdown commands on the interface on which the
OSPFv3 neighbor relationship is set up.
6.8.7 Configuring Stub Routers

When a router has a heavy load and cannot forward any other packets, you can configure it as
a stub router. After the router is configured as a stub router, other OSPFv3 devices do not use
this router to forward data but they can have a route to this stub router.
Context
A stub router is used to control traffic. It notifies OSPFv3 devices 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 router in the stub
area.
----End
6.8.8 Ignoring MTU Check on DD Packets

By disabling an interface from checking the MTU field in the received DD packet, you can
enable an OSPFv3 device to receive the packet with the MTU field being 0.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ospfv3 mtu-ignore [ instance instance-id ]

The MTU check on DD packets is ignored.
After the command is used, the interface does not check the MTU field of a received DD packet.
----End

After an OSPFv3 network is optimized, you can check the OSPFv3 interface, LSDB, and routing
table.
Prerequisites
Optimizing an OSPFv3 Network has been configured.
Procedure
l Run the display ospfv3[ process-id ] interface [ area area-id ] [ interface-type interface-
nssa-routes ]
----End
6.9 Configuration OSPFv3 GR

By configuring OSPFv3 GR, you can avoid inaccurate route calculation and packet loss after
an OSPFv3 device restarts.

By default, the OSPFv3 GR capability and Helper capability are disabled.
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 therefore realized.

Before configuring OSPFv3 GR, complete the following task:
Data Preparation
To configure OSPFv3 GR, you need the following data.
No. Data
1 OSPFv3 process ID
2 Filtering rule of the helper mode of OSPFv3 peers
6.9.2 Enabling OSPFv3 GR

After an OSPFv3 process restarts 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 help ensure OSPFv3 fast convergence and
stabilize the network topology.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 process-id
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 time period.
----End
6.9.3 Enabling the Helper of OSPFv3 GR

The GR Helper, which is a neighbor of the GR Restarter, can identify GR signaling, maintain
the adjacency with the Restarter during the active/standby switchover of the Restarter, and help
the Restarter to restore the network topology.

Procedure
Step 1 Run:
system-view

Step 2 Run:
ospfv3 process-id

1. Run:
helper-role [ [ acl-number acl-number | acl-name acl-name ] | max-grace-
period period | planned-only | lsa-checking-ignore ] *
The helper of OSPFv3 GR is enabled.

2. Run:
quit

3. Run

4. Run

as the rules.
1. Run:
helper-role [ acl-name acl-name | max-grace-period period | planned-only |
lsa-checking-ignore ] *

2. Run:
quit

3. Run
config } ]

4. Run
name ] *


Run:
helper-role [ ip-prefix ip-prefix-name | max-grace-period period | planned-only
| lsa-checking-ignore ] *
By default, the helper of OSPFv3 GR is disabled.
----End

After OSPFv3 GR is configured, you can check GR information.
Prerequisites
OSPFv3 GR has been configured.
Procedure
l Run the display ospfv3 [ process-id ] graceful-restart-information command to check
the status of OSPFv3 GR.
----End
Example
Run the display ospfv3 graceful-restart-information command, and you can view that the
local router is enabled with GR.
<HUAWEI> display ospfv3 graceful-restart-information
OSPFv3 Router with ID (0.0.0.0) (Process 1)

Graceful-restart support : planned and unplanned, strict lsa check
Grace-Period Configured : 120 Sec
Last Restart-exit Reason : none
Helper capability : enabled

Helper support : planned and unplanned, strict lsa check
Max Grace-Period Configured : 1800 Sec
Last Helper-exit Reason : none
6.10 Configuring BFD for OSPFv3

If there are high requirements for data transmission, and OSPFv3 convergence needs to be
speeded up when the link status changes, you can configure BFD on OSPFv3 links. After
detecting a link failure, BFD notifies the routing protocol of the failure, which triggers fast
convergence. When the neighbor relationship is Down, the BFD session is deleted dynamically.


Before configuring BFD for OSPFv3, familiarize yourself with the usage scenario, complete
To increase the convergence speed of OSPFv3 when the link status changes, you can configure
BFD on OSPFv3 links.
BFD keeps track of liveliness of network links and detects any faults in the links much faster
than the normal keep-alive protocols. When OSPFv3 is associated with BFD sessions, link
failures are notified immediately to OSPFv3 by BFD and OSPFv3 can take actions to perform
route calculation and converge in the new network topology.
Before configuring BFD in OSPFv3, complete the following task:
Data Preparation
To configure BFD for OSPFv3, you need the following data.
No. Data
1 OSPFv3 process ID
2 Minimum Transmission Interval
3 Minimum Receive Interval
4 Detect Multiplier
6.10.2 Enabling BFD for OSPFv3

On the two routers that need to establish a BFD session, you can configure BFD for all the
interfaces in a certain OSPFv3 process.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd

Step 3 Run:
quit
Step 4 Run:
ospfv3 process-id
Step 5 Run:
BFD for OSPFv3 is enabled to establish a BFD session.
By default, BFD is disabled at OSPFv3 process level.
----End
6.10.3 Configuring OSPFv3 BFD Parameters at Process Level

After enabling BFD for OSPFv3, you need to configure BFD parameters in the OSPFv3 process.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospfv3 process-id
Step 3 Run:
bfd all-interfaces { min-transmit-interval min-transmit-value | min-receive-
interval min-receive-value | detect-multiplier detect-multiplier-value } *
OSPFv3 BFD parameters are configured.

NOTE
l Actual interval at which BFD packets are transmitted on the local devices = Max { configured interval
min-transmit-value at which BFD packets are transmitted, configured interval min-receive-value at
which BFD packets are received on the peer device }
l Actual interval at which BFD packets are received on the local devices = Max { configured interval
min-transmit-value at which BFD packets are transmitted on the peer device, configured interval min-
receive-value at which BFD packets are received on the local device }
l Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the
local device x Configured detection multiplier detect-multiplier-value
For example:
l On the local device, 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 device, 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 device, 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 device, 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.10.4 Enabling OSPFv3 BFD at Interface Level

You can configure BFD on a specified interface for fast link failure detection.
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd

Step 3 Run:
quit

Step 4 Run:

Step 5 Run:
ospfv3 bfd enable [ instance instance-id ]
OSPFv3 BFD is enabled on the interface.

By default, OSPFv3 BFD is disabled at interface level.
----End
6.10.5 Configuring OSPFv3 BFD Parameters at Interface Level

After enabling BFD for OSPFv3 on an interface, you need to configure BFD parameters on the
interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 bfd { min-transmit-interval min-transmit-value | min-receive-interval min-
receive-value | detect-multiplier detect-multiplier-value } * [ instance instance-
id ]
OSPFv3 BFD parameters are configured at interface level.

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

After BFD for OSPFv3 is configured, you can check information about the BFD session.
Prerequisites
The BFD is enabled and configured for OSPFv3.
Procedure
l Run the display ospfv3 [ process-id ] bfd session [ interface-type interface-number ]
[ neighbor-id ] [ verbose ] command to check the BFD session information.
----End
6.11 Configuring OSPFv3 IP FRR

With OSPFv3 IP FRR, devices can rapidly switch traffic from faulty links to backup links
without interrupting traffic. This protects traffic and greatly improves the reliability of OSPFv3
networks.

Before configuring OSPFv3 IP FRR, familiarize yourself with the usage scenario, complete the

With the development of networks, Voice over IP (VoIP) and on-line video services require
high-quality real-time transmission. Nevertheless, if an OSPFv3 fault occurs, traffic can be
switched to a new link only after the following processes: fault detection at the millisecond level,
notifying the fault to the routing control plane at the millisecond level, generating and flooding
new topology information at the tens of milliseconds level, triggering SPF calculation at the tens
of milliseconds level, and notifying and installing a new route at the hundreds-of-milliseconds
level. As a result, it takes much more than 50 ms to recovery the link from the fault, which cannot
meet the requirement for real-time services on the network.
With OSPFv3 IP FRR that calculates a backup link in advance, devices can fast switch traffic
to the backup link without interrupting traffic when the primary link becomes faulty. This
protects traffic and therefore greatly improves the reliability of OSPFv3 networks.
OSPFv3 IP FRR is applicable to the services that are sensitive to packet delay and packet loss.
Before configuring OSPFv3 IP FRR, complete the following tasks:
the network layer
Data Preparation
To configure OSPFv3 IP FRR, you need the following data.
No. Data
1 OSPFv3 process ID
2 (Optional) Cost of the interface
3 (Optional) BFD parameters
4 (Optional) Name of the route policy
6.11.2 Enabling OSPFv3 IP FRR

This section describes how to enable OSPFv3 IP FRR to generate a loop-free backup link. When
this route becomes faulty, OSPFv3 can fast switch the traffic to a backup link.
Procedure
Step 1 Run:
system-view
Step 2 Run:

ospfv3 [ process-id ] [ vpn-instance vpn-instance-name ] *
The OSPFv3 process is started, and the OSPFv3 view is displayed.
Step 3 Run:
frr
The OSPFv3 IP FRR view is displayed.
Step 4 Run:
loop-free-alternate
OSPFv3 IP FRR is enabled to generate a loop-free backup link.
NOTE
OSPFv3 can generate the loop-free backup link only when the OSPFv3 IP FRR traffic protection inequality
is met.

OSPFv3 IP FRR filtering policies are configured.
After OSPFv3 IP FRR filtering policies are configured, only the OSPFv3 backup routes that
match the filtering conditions can be delivered to the forwarding table. To protect the traffic
over a specific OSPFv3 route, you can configure a filtering policy that matches the OSPFv3
route to ensure that the route can be added to the forwarding table. When this route becomes
faulty, OSPFv3 can fast switch the traffic to a backup link.
----End
6.11.3 (Optional) Binding OSPFv3 IP FRR and BFD

This section describes how to bind OSPFv3 IP FRR and BFD so that link faults can be detected
rapidly. This ensures that traffic is rapidly switched to the backup link in the case of link failures.
Context
During the configuration of OSPFv3 IP FRR, the lower layer needs to fast respond to the link
change so that traffic can be rapidly switched to the backup link in the case of a link failure.
Bind BFD to the link status so that link faults can be detected rapidly. This ensures that traffic
is rapidly switched to the backup link in the case of link failures.
Binding OSPFv3 IP FRR and BFD can configure in a specified process or on a specified
interface. The priority of BFD configured on an interface is higher than that of BFD configured
in an OSPFv3 process. If BFD is enabled on an interface, a BFD session is established according
to the BFD parameters set on the interface.
Procedure
l Binding OSPFv3 IP FRR and BFD in a specified process .
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:
ospfv3 [ process-id ] [ vpn-instance vpn-instance-name ] *
The OSPFv3 process is enabled, and the OSPFv3 view is displayed.

5. Run:
BFD is enabled in an OSPFv3 process.

6. Run:
bfd all-interfaces frr-binding
IP FRR is bound to BFD in an OSPFv3 process.

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

2. Run:
bfd

3. Run:
quit

4. Run:

5. Run:
ospfv3 bfd enable
The BFD on the specified interface is enabled with OSPFv3.

6. Run:
ospfv3 bfd frr-binding
IP FRR is bound to BFD on the OSPFv3 interface.
----End
6.11.4 (Optional) Disabling OSPFv3 IP FRR on an Interface

OSPFv3 IP FRR can be disabled on an interface of a specific device that is running important
services and resides on an FRR backup link. This setting prevents the device connected to this

interface from being a part of a backup link and being burdened after FRR switches traffic to
the backup link.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of the OSPFv3 IP FRR-enabled interface is displayed.
Step 3 Run:
ospfv3 frr block
The OSPFv3 IP FRR function is disabled on the specified interface.
----End

After configuring OSPFv3 IP FRR, you can view route information.
Prerequisites
All OSPFv3 IP FRR configurations have been configured.
Procedure
l Run the display ospfv3 [ process-id ] routing verbose command to check information
about the primary and backup links after OSPFv3 IP FRR is enabled.
----End
Example
View the routes to the specified OSPFv3 device.
<HUAWEI> display ospfv3 routing verbose
Codes : E2 - Type 2 External, E1 - Type 1 External, IA - Inter-Area,

N - NSSA, U - Uninstalled, D - Denied by Import Policy
Destination : CC:: Prefix Length : 64

Metric : 21 Type : INTRA-AREA
Nexthop : FE80::2E0:50FF:FE79:8242 Nexthop Interface:
Backup Nexthop: FE80::2E0:D0FF:FE02:8142 Backup Interface :
Backup Type : LINK PROTECT Flags : N|U
The preceding display shows that a backup route is generated on device, including information
about the backup next hop: Backup NextHop is address of the backup next hop, Backup
Interface is outbound interface of the backup next hop, Backup Type is type of the backup next
hop.

6.12 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, familiarize yourself with the usage scenario, complete the
OSPFv3 IPSec uses a complete set of IPSec mechanisms to authenticate sent and received
OSPFv3 packets, protecting devices against pseudo OSPFv3 packets.
Before configuring OSPFv3 IPSec, complete the following tasks:
l Configuring an IPSec Proposal

NOTE
OSPFv3 IPSec only support transport packet encapsulation mode.
Data Preparation
To configure OSPFv3 IPSec, you need the following data.
No. Data
1 Security protocol
2 Authentication algorithms used by AH
3 Authentication algorithm used by ESP
4 Encapsulation algorithm used by ESP
5 AH security parameter indexes used for protecting incoming and outgoing traffic
6 ESP security parameter indexes used for protecting incoming and outgoing traffic
7 AH authentication key (in the format of a string) used for protecting incoming and
outgoing traffic
8 ESP authentication key (in the format of a string) used for protecting incoming and
outgoing traffic
9 AH authentication key (in the hexadecimal format) used for protecting incoming and
outgoing traffic

No. Data
10 ESP authentication key (in the hexadecimal format) used for protecting incoming and
outgoing traffic
11 ESP encapsulation key (in the hexadecimal format) used for protecting incoming and
outgoing traffic
6.12.2 Enabling IPSec in an OSPFv3 Process

An SA configured in an OSPFv3 process is used to authenticate packets of the process.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipsec sa sa-name
An 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.
----End
6.12.3 Enabling IPSec in an OSPFv3 Area

An SA configured in an OSPFv3 area is used to authenticate the packets of the area.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
area area-id

Step 4 Run:
ipsec sa sa-name
An SA is configured in the OSPFv3 area.
NOTE
The SA configured on an OSPFv3 area takes precedence over that configured in an OSPFv3 process.
----End
6.12.4 Enabling IPSec on an Interface

An SA configured on an interface is used to authenticate the packets sent and received by the
interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ospfv3 ipsec sa sa-name
An SA is configured on the interface.
NOTE
The SA configured on an OSPFv3 interface takes precedence over that configured in an OSPFv3 process
and an OSPFv3 area.
----End
6.12.5 Enabling IPSec on the Virtual Link

An SA configured on the Virtual Link is used to authenticate the packets sent and received on
the Virtual Link.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:

area area-id

Step 4 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.
----End
6.12.6 Enabling IPSec on the Sham Link

An SA configured on a sham link is used to authenticate the packets sent and received on the
sham link.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospfv3 [ process-id ] vpn-instance [ vpn-instance-name ]

Step 3 Run:
area area-id

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

After configuring OSPFv3 IPSec, you can view the information about SAs configured in an
OSPFv3 process, OSPFv3 area, OSPFv3 interface, OSPFv3 virtual link, and OSPFv3 sham link.
Prerequisites
The OSPFv3 IPSec has been configured.
Perform the following steps on the router that runs OSPFv3.

Procedure
l Run the display ospfv3 [ process-id ] command to view the SA applied in a specified
process.
l Run the display ospfv3 [ process-id ] interface command to view the SA applied on a
specified interface.
l Run the display ospfv3 [ process-id ] area [ area-id ] command to view the SA applied
in a specified area.
l Run the display ospfv3 [ process-id ] vlink command to view the SA applied on the peer
end of a virtual link.
l Run the display ospfv3 [ process-id ] sham-link command to view the SA applied on the
peer end of a sham link.
----End
Example
Run the display ospfv3 command, and you can view the SA configured in an OSPFv3 process.
For example:
<HUAWEI> display ospfv3
Routing Process "OSPFv3 (1)" with ID 0.0.0.0
SPF schedule delay 5 secs, Hold time between SPFs 10 secs
Minimum LSA interval 5 secs, Minimum LSA arrival 1 secs
Stub router capability: enabled
Number of external LSA 0. Checksum Sum 0x0000
Number of AS-Scoped Unknown LSA 0
Number of FULL neighbors 0
Number of Exchange and Loading neighbors 0
Maximum ASE LS ID 1 and Unused list Count 0
Number of LSA originated 0
Number of LSA received 0
SPF Count : 0
Non Refresh LSA : 0
Non Full Nbr Count : 0
Number of areas in this router is 1
IP security association configured: sa1
Run the display ospfv3 area command, and you can view the SA configured in an OSPFv3
area. For example:
<HUAWEI> display ospfv3 area
OSPFv3 Process (1)
Area BACKBONE(0) Status: down
Number of interfaces in this area is 0
SPF algorithm executed 0 times
Number of LSA 0. Checksum Sum 0x0000
Number of Unknown LSA 0
Area Bdr Router count: 0
Area ASBdr Router count: 0
Area 0.0.0.1 Status: up
Number of interfaces in this area is 1
SPF algorithm executed 3 times
Number of LSA 4. Checksum Sum 0x23AC8
Number of Unknown LSA 0
Area Bdr Router count: 0
Area ASBdr Router count: 1

Run the display ospfv3 interface command, and you can view the SA configured in an OSPFv3
interface. For example:
<HUAWEI> display ospfv3 interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 is up, line protocol is up
Interface ID 518
IPv6 Prefixes
FE80::1441:0:E213:1 (Link-Local Address)
2001:DB8:1::1
OSPFv3 Process (1), Area 0.0.0.1, Instance ID 0
Router ID 2.2.2.2, Network Type POINTOPOINT, Cost: 1562
Transmit Delay is 1 sec, State Point-To-Point, Priority 1
No designated router on this link
No backup designated router on this link
Timer interval configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:02
Neighbor Count is 1, Adjacent neighbor count is 1
IP security association applied: sa1
Run the display ospfv3 vlink command, and you can view the SA configured on an OSPFv3
virtual link. For example:
<HUAWEI> display ospfv3 vlink
Virtual Link VLINK1 to router 1.1.1.1 is up
Transit area 0.0.0.1 via interface Pos1/0/0, instance ID 0
Local address 2001:DB8:1::1
Remote address 2001:DB8:1::13
Transmit Delay is 1 sec, State Point-To-Point,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Adjacency state Full
Run the display ospfv3 sham-link command, and you can view the SA configured on an
OSPFv3 sham link. For example:
<HUAWEI> display ospfv3 sham-link
OSPFv3 Process (10)
Sham Link SHAM-LINK1 to router 0.0.0.0 is down
Area 0.0.0.1, via Interface *, Instance ID 0, cost 1
Source address 2001:DB8:1::1
Destination address 2001:DB8:2::2
Interface ID 0x80000002
Sham-Link Interface Events: 0
Sham-Link Interface LsaCount: 0
Sham-Link Interface Lsa Checksum: 0x0
Transmit Delay is 1 sec, State Down
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Adjacency state Down
6.13 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.


Before improving Open Shortest Path First version 3 (OSPFv3) network security, familiarize
yourself with the usage scenario, complete the pre-configuration tasks, and obtain the data
required for the configuration.
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 router. If the packets are destined for the router, 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
router 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.
l Configure basic OSPFv3 functions.
Data Preparation
No. Data
1 OSPFv3 process ID
2 (Optional) OSPFv3 virtual private network (VPN) instance name
3 (Optional) TTL to be checked
4 ID of the OSPFv3 area in which authentication is to be configured
5 Numbers of the OSPFv3 interfaces on which authentication is to be configured
6 Authentication mode and password

6.13.2 Configuring OSPFv3 GTSM

Open Shortest Path First version 3 (OSPFv3) Generalized TTL security mechanism (GTSM)
can be configured to protect the router against potential attacks and improve system security.
Context
GTSM checks the time to live (TTL) values of only the packets that match a GTSM policy. You
can configure the router to allow the unmatched packets to pass through the filter or to be
discarded. If you configure the router to discard the unmatched packets, enable GTSM on
routers with which the router may communicate because the router discards all packets from
GTSM-incapable routers, and as a result, connections cannot be established.
In addition, you can configure the router 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 router 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 router 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.
----End
6.13.3 Configuring an Authentication Mode

Open Shortest Path First version 3 (OSPFv3) supports packet authentication, enabling routers
to receive only the OSPFv3 packets that are authenticated. If packets fail to be authenticated,

OSPFv3 neighbor relationships cannot be established. This section describes how to configure
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.
NOTE
By default, authentication is not configured for OSPF process, area or interface. Configuring authentication
is recommended to ensure system security.
Procedure
l Configure OSPFv3 area authentication.
1. Run:
system-view

2. Run:

3. Run:
area area-id

4. 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
routers in the same area must be the same.
l Configure OSPFv3 process authentication.
1. Run:
system-view

2. Run:

3. 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.
1. Run:
system-view

2. Run:

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

After configuring Open Shortest Path First version 3 (OSPFv3) generalized TTL security
mechanism (GTSM) and an authentication mode, check 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
Example
Run the display gtsm statistics command. The command output shows GTSM statistics on all
boards, including the total number of OSPFv3 packets, number of received OSPFv3 packets,
and number of discarded OSPFv3 packets.
----------------------------------------------------------------
----------------------------------------------------------------
0 BGP 0 0 0
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
----------------------------------------------------------------

6.14 Configuring the Network Management Function of

OSPFv3
OSPFv3 supports the network management function. You can bind the OSPFv3 MIB to a certain
OSPFv3 process.

Before configuring the network management function for OSPFv3, familiarize yourself with the
usage scenario, complete pre-configuration tasks, and obtain the required data. This can help
you complete the configuration task quickly and accurately.
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:
Data Preparation
None.
6.14.2 Configuring OSPFv3 MIB Binding

The MIB is a virtual database of the device status maintained by the managed devices.
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.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospfv3 mib-binding process-id
OSPFv3 MIB binding is configured.
----End

6.14.3 Configuring OSPFv3 Trap

Traps are the notifications sent from a router to inform the NMS of the fault detected by the
system.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable feature-name ospfv3 {non-excessive all | trap-name
{ authenticationsequencenumberwrap | ifconfigerror | ifrxbadpacket | ifstatechange
| lastauthenticationkeyexpiry | nbrrestarthelperstatuschange | nbrstatechange |
nssatranslatorstatuschange | restartstatuschange | virtifconfigerror |
virtifrxbadpacket | virtifstatechange | virtnbrrestarthelperstatuschange |
virtnbrstatechange } }
The trap function for the OSPFv3 module is enabled.
To enable all non-excessive traps of OSPFv3 module, you can run the non-excessive all
command; to enable the traps of one or more events, you can specify type-name.
----End

After the network management function is configured for OSPFv3, you can check the contents
of the information channel, and information recorded in the information center, log buffer, and
trap buffer.
Prerequisites
The Network Management Function of OSPFv3 has been configured.
Procedure
l Run the display current-configuration command to check the configuration parameters
currently validated on the router.
l Run the display snmp-agent trap feature-name ospfv3 all command to view all trap
messages of the OSPFv3 module.
----End
6.15 Maintaining OSPFv3

Maintaining OSPFv3 and Debugging OSPFv3 involve resetting OSPFv3.
6.15.1 Resetting OSPFv3

Restarting OSPFv3 can reset OSPFv3. In addition, you can reset OSPFv3 through GR.

Context
NOTICE
The OSPFv3 adjacency is removed when you reset the OSPFv3 connection by using the reset
ospfv3 command. Exercise caution when running this command.
After modifying the OSPFv3 routing policy or protocol, reset the OSPFv3 connection to validate
the modification. To reset OSPFv3 connections, run the following reset ospfv3 command in the
user view.
Procedure
l To validate the new configuration, run the following commands:
– reset ospfv3 { process-id | all } [ graceful-restart [ extend-period period ] ]
– reset ospfv3 { process-id | all } counters [ neighbor [ interface-type interface-
number ] [ router-id ] ]
----End

This section provides several configuration examples of OSPFv3 together with the Networking
Follow-up Procedure
NOTE
6.16.1 Example for Configuring OSPFv3 Areas

This part provides an example for configuring basic OSPFv3 functions. Detailed operations
include enabling OSPFv3 on each router and specifying network segments in different areas.
As shown in Figure 6-1, all routers run OSPFv3. The entire autonomous system is divided into
three areas. Router B and Router C serve as ABRs to forward the inter-area routes.
It is required that Area 2 be configured as a stub area to decrease the LSAs advertised to this
area, without affecting route reachability.

Figure 6-1 Networking diagram of configuring OSPFv3 areas
Area0
POS1/0/0
RouterB 2001:DB8:1::1/64 RouterC
POS1/0/0
2001:DB8:1::2/64
POS2/0/0 POS2/0/0
2001:DB8:2::1/64 2001:DB8:3::1/64
POS2/0/0 POS2/0/0
2001:DB8:2::2/64 2001:DB8:3::2/64
RouterA RouterD
GE3/0/0
2001:DB8:4::1/64
Area2
Area1 Stub
1. Enable basic OSPFv3 function on each router.
2. Configure Area 2 as a stub area and check the OSPFv3 routing table of Router D.
3. Configure Area 2 as a totally stub area and check the OSPFv3 routing table of Router D.
Data Preparation
l Router ID of Router A as 1.1.1.1 of Area 1
l Router ID of Router B as 2.2.2.2 of Areas 0 and 1
l Router ID of Router C as 3.3.3.3 of Areas 0 and 2
l Router ID of Router D as 4.4.4.4 of Area 2
Procedure
Step 2 Configure basic OSPFv3 functions.
[RouterA] ipv6
[RouterA] ospfv3


[RouterA] interface pos2/0/0
[RouterA-Pos2/0/0] ospfv3 1 area 1
[RouterB] ipv6
[RouterB] ospfv3
[RouterB] interface pos1/0/0
[RouterB-Pos1/0/0] ospfv3 1 area 0
[RouterB] interface pos2/0/0
[RouterC] ipv6
[RouterC] ospfv3
[RouterC-Pos1/0/0] ospfv3 1 area 0
[RouterD] ipv6
[RouterD] ospfv3
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD] interface pos 2/0/0
[RouterD-Pos2/0/0] ospfv3 1 area 2
[RouterD-Pos2/0/0] quit
# Display the OSPFv3 neighbors of Router B.

[RouterB] display ospfv3 peer
OSPFv3 Process (1)
OSPFv3 Area (0.0.0.1)
Neighbor ID Pri State Dead Time Interface Instance ID
1.1.1.1 1 Full/ - 00:00:34 PosS2/0/0 0
3.3.3.3 1 Full/ - 00:00:32 PosS1/0/0 0
# Display OSPFv3 neighbors of Router C.

[RouterC] display ospfv3 peer
OSPFv3 Process (1)
2.2.2.2 1 Full/ - 00:00:37 Pos1/0/0 0
4.4.4.4 1 Full/ - 00:00:33 Pos2/0/0 0
# Display the OSPFv3 routing table of Router D.

[RouterD] display ospfv3 routing


OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA 2001:DB8:1::/64 2
via FE80::1572:0:5EF4:1, Pos2/0/0
IA 2001:DB8:2::/64 3
via FE80::1572:0:5EF4:1, Pos2/0/0
2001:DB8:3::/64 1
directly-connected, Pos2/0/0
IA 2001:DB8:4::/64 4
via FE80::1572:0:5EF4:1, Pos2/0/0
Step 3 Configure stub areas.
# Configure the stub area of Router D.

[RouterD] ospfv3
[RouterD-ospfv3-1] area 2
[RouterD-ospfv3-1-area-0.0.0.2] stub
[RouterD-ospfv3-1-area-0.0.0.2] quit
# Configure the stub area of Router C, and set the cost of the default route advertised to the stub
area to 10.
[RouterC] ospfv3
[RouterC-ospfv3-1] area 2
[RouterC-ospfv3-1-area-0.0.0.2] stub
[RouterC-ospfv3-1-area-0.0.0.2] default-cost 10
[RouterC-ospfv3-1-area-0.0.0.2] quit
# Display the OSPFv3 routing table of Router D, and you can view a new default route in the
routing table. Its cost is the sum of the cost of the directly connected routes and the configured
cost.
OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 11
via FE80::1572:0:5EF4:1, Pos2/0/0
IA 2001:DB8:1::/64 2
via FE80::1572:0:5EF4:1, Pos2/0/0
IA 2001:DB8:2::/64 3
via FE80::1572:0:5EF4:1, Pos2/0/0
2001:DB8:3::/64 1
IA 2001:DB8:4::/64 4
via FE80::1572:0:5EF4:1, Pos2/0/0
Step 4 Configure totally stub areas.
# Configure Router C and configure Area 2 as a totally stub area.

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

# Display the OSPFv3 routing table of Router D, and you can view that the entries in the routing
table decrease; other non-directly connected routes are suppressed; only the default route is
reserved.
OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 11
via FE80::1572:0:5EF4:1, Pos2/0/0
2001:DB8:3::/64 1
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
undo shutdown
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 1.1.1.1
#
return

#
sysname RouterB
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1

router-id 2.2.2.2
#
return

#
sysname RouterC
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 3.3.3.3
area 0.0.0.2
stub no-summary
default-cost 10
#
return

#
sysname RouterD
#
ipv6
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 4.4.4.4
area 0.0.0.2
stub
#
return
6.16.2 Example for Configuring OSPFv3 DR Election

This part provides an example for setting the DR priority on an interface for DR election on a
broadcast network.
In Figure 6-2, Router A has a DR priority of 100, which is the highest in the network, so it is
elected as the DR. Router C has the second highest priority, so it is elected as the BDR. The
priority of Router B is 0 so that it cannot be elected as the DR. Router D does not have a priority
and the priority is 1 by default.

Figure 6-2 Networking diagram of configuring OSPFv3 DR election

RouterA RouterB
GE1/0/0 GE1/0/0
2001:DB8::1/64 2001:DB8::2/64
GE1/0/0 GE1/0/0
2001:DB8::3/64 2001:DB8::4/64
RouterC RouterD
1. Configure the router ID on each router, enable OSPFv3, and specify the network segment.
2. Check the DR/BDR status with the default priority.
3. Configure the DR priority on the interface and check the DR/BDR status.
Data Preparation
l Router ID of Router A as 1.1.1.1; DR priority as 100

l Router ID of Router B as 2.2.2.2; DR priority as 0
l Router ID of Router C as 3.3.3.3; DR priority as 2
l Router ID of Router D as 4.4.4.4; DR priority as 1
Procedure
# Configure Router A, enable OSPFv3, and set its router ID to 1.1.1.1.

[RouterA] ipv6
[RouterA] ospfv3
# Configure Router B, enable OSPFv3, and set its Router ID to 2.2.2.2.

[RouterB] ipv6
[RouterB] ospfv3
# Configure Router C, enable OSPFv3, and set its Router ID to 3.3.3.3.

[RouterC] ipv6
[RouterC] ospfv3
# Configure Router D, enable OSPFv3, and set its Router ID to 4.4.4.4.

[RouterD] ipv6
[RouterD] ospfv3
[RouterD-GigabitEthernet1/0/0] ospfv3 1 area 0
# Display the neighbors of Router A. You can view the DR priority (its default value is 1) and
the neighbor status. Router D is the DR and Router C is the BDR.
NOTE
The router with the greater router ID is the DR when routers have the same priority. If a certain Ethernet
interface of a router becomes a DR, the other broadcast interfaces of the router have the highest priority in
DR election. That is, the DR router is elected as the DR.
[RouterA] display ospfv3 peer
OSPFv3 Process (1)
2.2.2.2 1 2-Way/DROther 00:00:32 GE1/0/0 0
3.3.3.3 1 Full/Backup 00:00:36 GE1/0/0 0
4.4.4.4 1 Full/DR 00:00:38 GE1/0/0 0
# Display the neighbors of Router D, and you can view that all neighbors of Router D are in the
Full state.
[RouterD] display ospfv3 peer
OSPFv3 Process (1)
1.1.1.1 1 Full/DROther 00:00:32 GE1/0/0 0
2.2.2.2 1 Full/DROther 00:00:35 GE1/0/0 0
3.3.3.3 1 Full/Backup 00:00:30 GE1/0/0 0
Step 3 Set the DR priority of the interface.

# Set the DR priority of Router A to 100.
[RouterA-GigabitEthernet1/0/0] ospfv3 dr-priority 100
# Set the DR priority of Router B to 0.

[RouterB-GigabitEthernet1/0/0] ospfv3 dr-priority 0

# Set the DR priority of Router C to 2.

[RouterC-GigabitEthernet1/0/0] ospfv3 dr-priority 2
# Display the neighbors of Router A, and you can view that the DR priority is updated and the
DR and BDR remain unchanged.
OSPFv3 Process (1)
2.2.2.2 0 2-Way/DROther 00:00:34 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:38 GE1/0/0 0
4.4.4.4 1 Full/DR 00:00:31 GE1/0/0 0
# Display the neighbors of Router D, and you can view that Router D remains as the DR.
OSPFv3 Process (1)
1.1.1.1 100 Full/DROther 00:00:36 GE1/0/0 0
2.2.2.2 0 Full/DROther 00:00:30 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:36 GE1/0/0 0
Step 4 Re-elect the DR/BDR.

# Restart all routers (or run the shutdown and undo shutdown commands on the interface that
establishes the OSPFv3 neighbor relationship), and make OSPFv3 re-elect the DR/BDR.
# Display the neighbors of Router A, and you can view that Router C is the BDR.
OSPFv3 Process (1)
2.2.2.2 0 Full/DROther 00:00:31 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:36 GE1/0/0 0
4.4.4.4 1 Full/DROther 00:00:39 GE1/0/0 0
# Display the neighbors of Router D, and you can view that Router A is the DR.
OSPFv3 Process (1)
1.1.1.1 100 Full/DR 00:00:39 GE1/0/0 0
2.2.2.2 0 2-Way/DROther 00:00:35 GE1/0/0 0
3.3.3.3 2 Full/Backup 00:00:39 GE1/0/0 0
----End
Configuration Files
#
sysname RouterA
#
ipv6
#

undo shutdown
ipv6 enable
ipv6 address 2001:DB8::1/64
ospfv3 dr-priority 100
#
ospfv3 1
router-id 1.1.1.1
#
return

#
sysname RouterB
#
ipv6
#
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 2.2.2.2
#
return

#
sysname RouterC
#
ipv6
#
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 3.3.3.3
#
return

#
sysname RouterD
#
ipv6
#
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 4.4.4.4
#
return

6.16.3 Example for Configuring OSPFv3 Virtual Links

This part provides an example for configuring virtual links to connect non-backbone areas to
the backbone area.
As shown in Figure 6-3, all the routers run OSPFv3, and the entire autonomous system is divided
into three areas. Both Router B and Router C serve as ABRs to forward routes between areas.
Area 2 is not connected to the backbone Area 0 directly. Area 1 is the transmit area that connects
Area 0 and Area 2.
It is required to configure a virtual link in Area 1 on Router B and Router C by the virtual link,
making the route from Router A to Router D reachable.
Figure 6-3 Networking diagram of configuring OSPFv3 virtual links
Area1
RouterB POS2/0/0 RouterC
2001:DB8:1::1/64
POS1/0/0
POS1/0/0 2001:DB8:1::2/64 POS2/0/0
2001:DB8:2::1/64 2001:DB8:3::1/64
POS1/0/0 POS1/0/0
2001:DB8:2::2/64 2001:DB8:3::2/64
RouterA RouterD
Area2 Area0
1. Enable basic OSPFv3 functions on each router.

2. Configure virtual links on Router B and Router C to connect backbone networks to other
networks.
Data Preparation
l Router ID of Router A as 1.1.1.1 of Area 2

l Router ID of Router B as 2.2.2.2 of Areas 1 and 2
l Router ID of Router C as 3.3.3.3 of Areas 1 and 0

l Router ID of Router D as 4.4.4.4 of Area 0
Procedure
Step 1 Assign an IP address for each interface.
# Enable OSPFv3 on Router A and set its Router ID to 1.1.1.1.
[RouterA] ipv6
[RouterA] ospfv3
[RouterA] interface Pos 1/0/0
[RouterA-Pos1/0/0] ospfv3 1 area 2
# Enable OSPFv3 on Router B and set its Router ID to 2.2.2.2.

[RouterB] ipv6
[RouterB] ospfv3
[RouterB] interface Pos 1/0/0
# Enable OSPFv3 on Router C and set its Router ID to 3.3.3.3.

[RouterC] ipv6
[RouterC] ospfv3
[RouterC] interface Pos 1/0/0
# Enable OSPFv3 on Router D and set its Router ID to 4.4.4.4.

[RouterD] ipv6
[RouterD] ospfv3
[RouterD] interface Pos 1/0/0
[RouterD-Pos1/0/0] ospfv3 1 area 0
# Display the OSPFv3 routing table of Router C, and you can find that there is no routing
information of Area 2 in the routing table.
[RouterC] display ospfv3 routing
OSPFv3 Process (1)
Destination Metric
Next-hop
2001:DB8:1::/64 1
2001:DB8:3::/64 1

Step 3 Configure a virtual link in Area 1 on Router B and Router C.
[RouterB] ospfv3
[RouterB-ospfv3-1] area 1
[RouterB-ospfv3-1-area-0.0.0.1] vlink-peer 3.3.3.3
[RouterB-ospfv3-1-area-0.0.0.1] quit
[RouterC] ospfv3
[RouterC-ospfv3-1-area-0.0.0.1] vlink-peer 2.2.2.2
# Display the OSPFv3 routing table of Router C.

[RouterC] display ospfv3 routing
OSPFv3 Process (1)
Destination Metric
Next-hop
2001:DB8:1::/64 1
2001:DB8:1::1/128 1
via FE80::4D67:0:EB7D:2, Pos1/0/0
2001:DB8:1::2/128 1
IA 2001:DB8:2::/64 2
via FE80::4D67:0:EB7D:2, Pos1/0/0
2001:DB8:3::/64 1
NOTE
After a virtual link is configured, Area 2 is connected to Area 0 through the virtual link. So the route to
Area 2 is contained in the routing table of Router C.
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 1.1.1.1
#
return

#

sysname RouterB
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 2.2.2.2
area 0.0.0.1
vlink-peer 3.3.3.3
#
return

#
sysname RouterC
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 3.3.3.3
area 0.0.0.1
vlink-peer 2.2.2.2
#
return

#
sysname RouterD
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
#
ospfv3 1
router-id 4.4.4.4

#
return
6.16.4 Example for Configuring OSPFv3 GR

This part provides an example for configuring OSPFv3 GR so that a restarting router can
synchronize routing information with its neighbors through GR.
As shown in Figure 6-4, Router A, Router B, and Router C are in the same OSPFv3 area. They
are interconnected through OSPFv3 and provide GR.
After the OSPFv3 neighbor relationship is set up between Router A, Router B, and Router C,
the three routers exchanges routing information. When OSPFv3 on Router A restarts, Router A
synchronizes routing information with its neighbors through GR.
Figure 6-4 Networking diagram of configuring OSPFv3 GR

POS1/0/0 POS1/0/0
2001:DB8:1::1/64 2001:DB8:2::2/64
POS1/0/0 POS2/0/0
RouterA 2001:DB8:1::2/64 RouterB 2001:DB8:2::1/64 RouterC
1. Enable the OSPFv3 helper in the OSPFv3 view of Router B.

2. Enable OSPFv3 GR in the OSPFv3 view of Router A.
Data Preparation
l IPv6 address of each interface

l OSPFv3 process number
Procedure
Step 3 Enable OSPFv3 GR on Router A.

[RouterA] ospfv3 100
[RouterA-ospfv3-100] graceful-restart

Step 4 Enable OSPFv3 helper on Router B.

[RouterB] ospfv3 100
[RouterB-ospfv3-100] helper-role
# Run the display ipv6 fib 6 command on Router A to display the forwarding information table
(FIB).
<RouterA> display ipv6 fib 1
FIB Table:
Total number of Routes : 2
Destination: 2001:DB8:1:: PrefixLength: 64
NextHop : 2001:DB8:1::1 Flag : U
Label : NULL Tunnel ID : 0
TimeStamp : Date- 25:6:2007, Time- 17:31:46 reference : 1
Interface : Pos1/0/0
Destination: 2001:DB8:2:: PrefixLength: 64
NextHop : FE80::200:1FF:FE00:200 Flag : DGU
# Restart OSPFv3 process 100 on Router A in a non-GR mode.

<RouterA> reset ospfv3 100
# Run the display ipv6 fib 1 command on Router A to view the FIB.
FIB Table:
Destination: 2001:DB8:1:: PrefixLength : 64
From the preceding display, you can find that the FIB on Router A changes and services are
affected.
# Restart OSPFv3 process 100 on Router A in GR mode.

<RouterA> reset ospfv3 100 graceful-restart
# Run the display ipv6 fib 6 command on Router A to view the FIB and check whether GR
works normally. If GR works normally, the FIB does not change and services are not interrupted
when Router A restarts the OSPFv3 process in GR mode.
FIB Table:
Interface : Ethernet3/2/0
NextHop : FE80::200:1FF:FE00:200 Flag : DGU
Interface : Ethernet3/2/0

From the preceding display, you can find that the FIB on Router A does not change and services
are not affected.
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:1:1/64
ospfv3 100 area 0.0.0.0
#
ospfv3 100
router-id 1.1.1.1
graceful-restart
#
return

#
sysname RouterB
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ipv6 enable
ospfv3 100 area 0.0.0.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
ospfv3 100 area 0.0.0.0
#
ospfv3 100
router-id 2.2.2.2
helper-role
#
return

#
ipv6
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ipv6 enable
ospfv3 100 area 0.0.0.0
#
ospfv3 100
router-id 3.3.3.3

#
return
6.16.5 Example for Configuring BFD for OSPFv3

This part provides an example for configuring BFD for OSPFv3. After BFD for OSPFv3 is
configured, BFD can fast detect link faults and report them to OSPFv3 so that service traffic can
be transmitted through the backup link.
As shown in Figure 6-5, it is required as follows:
l Run OSPFv3 between Router A, Router B, and Router C.

l Enable BFD of the OSPFv3 process on Router A, Router B, and Router C.
l Traffic is transmitted on the active link Router A → Router B. The link Router A → Router
C → Router B acts as the standby link.
l When a fault occurs on the link, BFD can quickly detect the fault and notify OSPFv3 of
the fault; therefore, the traffic is transmitted on the standby link.
Figure 6-5 Networking diagram for configuring BFD for OSPFv3

RouterA RouterB
GE1/0/0 GE1/0/2
2001:DB8:1::2/64 2001:DB8:4::1/64
GE1/0/0
GE1/0/1 2001:DB8:1::3/64 GE1/0/1
2001:DB8:3::1/64 2001:DB8:2::1/64
GE1/0/1 GE1/0/0
2001:DB8:3::3/64 2001:DB8:2::2/64
RouterC
1. Enable the basic OSPFv3 functions on each router.

2. Configuring BFD for OSPFv3.
Data Preparation
l Router ID of Router A is 1.1.1.1.

l Router ID of Router B is 2.2.2.2.
l Router ID of Router C is 3.3.3.3.
l Minimum interval for sending the BFD packets, minimum interval for receiving the BFD
packets, and detection multiple on Router A and Router B.

Procedure
Step 1 Assign an IPv6 address to each router interface.
The detailed configuration is not mentioned here.
Step 2 Configure the basic OSPFv3 functions.
[RouterA] ipv6
[RouterA] ospfv3
[RouterA-GigabitEthernet1/0/1] ospfv3 1 area 0.0.0.0
[RouterB] ipv6 enable
[RouterB] ospfv3 1
[RouterB-GigabitEthernet1/0/0] ospfv3 1 area 0.0.0.0
[RouterC] ospfv3 1
[RouterC-GigabitEthernet1/0/0] ospfv3 1 area 0.0.0.0
[RouterC-GigabitEthernet1/0/1] ospfv3 1 area 0.0.0.0
# After the preceding configurations are complete, run the display ospfv3 peer command. You
can view that the neighboring relationship is set up between Router A and Router B, and that
between Router B and Router C. Take the display of Router A as an example:
[RouterA] display ospfv3 peer verbose
OSPFv3 Process (1)
Neighbor 2.2.2.2 is Full, interface address FE80::E0:CE19:8142:1
In the area 0.0.0.0 via interface GE1/0/0
DR Priority is 1 DR is 2.2.2.2 BDR is 1.1.1.1
Options is 0x000013 (-|R|-|-|E|V6)
Dead timer due in 00:00:34
Neighbour is up for 01:30:52

Database Summary Packets List 0

Link State Request List 0
Link State Retransmission List 0
Neighbour Event: 6
Neighbour If Id : 0xe
Neighbor 3.3.3.3 is Full, interface address FE80::E0:9C69:8142:2
In the area 0.0.0.0 via interface GE1/0/1
DR Priority is 1 DR is 3.3.3.3 BDR is 1.1.1.1
Options is 0x000013 (-|R|-|-|E|V6)
Dead timer due in 00:00:37
Neighbour is up for 01:31:18
Database Summary Packets List 0
Link State Request List 0
Link State Retransmission List 0
Neighbour Event: 6
Neighbour If Id : 0x9
# Display the information in the OSPFv3 routing table on Router A. You can view the routing
entries to Router B and Router C.
[RouterA] display ospfv3 routing
OSPFv3 Process (1)
Destination Metric
Next-hop
2001:DB8:1::/64 1
directly connected, GigabitEthernet1/0/0
2001:DB8:2::/64 2
via FE80::E0:9C69:8142:2, GigabitEthernet1/0/1
via FE80::E0:CE19:8142:1, GigabitEthernet1/0/0
2001:DB8:3::/64 1
2001:DB8:4::1/64 1
via FE80::E0:CE19:8142:1, GigabitEthernet1/0/0
As shown in the OSPFv3 routing table, the next hop address of the route to 2001:DB8:4::1/64
is GigabitEthernet1/0/0 and traffic is transmitted on the active link Router A → Router B.
Step 3 Configure OSPFv3 BFD.
# Enable global BFD on Router A.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] ospfv3
[RouterA-ospfv3-1] bfd all-interfaces enable
[RouterA-ospfv3-1] bfd all-interfaces min-transmit-interval 100 min-receive-
interval 100 detect-multiplier 4
# Enable global BFD on Router B.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] ospfv3
[RouterB-ospfv3-1] bfd all-interfaces enable
[RouterB-ospfv3-1] bfd all-interfaces min-transmit-interval 100 min-receive-
# Enable global BFD on Router C.

[RouterC] bfd
[RouterC-bfd] quit
[RouterC] ospfv3
[RouterC-ospfv3-1] bfd all-interfaces enable
[RouterC-ospfv3-1] bfd all-interfaces min-transmit-interval 100 min-receive-

# After the preceding configurations are complete, run the display ospfv3 bfd session command
on Router A or Router B. You can view that the status of the BFD session is Up.
Take the display of Router B as an example:

<RouterB> display ospfv3 bfd session verbose
* - STALE
OSPFv3 Process (1)
Neighbor-Id: 1.1.1.1
BFD Status: Up
Interface: GE1/0/0
IPv6-Local-Address: FE80::E0:CE19:8142:1
IPv6-Remote-Address: FE80::E0:4C3A:143:1
BFD Module preferred timer values
Transmit-Interval(ms): 100
Receive-Interval(ms): 100
Detect-Multiplier: 3
OSPFv3 Module preferred timer values
Configured timer values
Neighbor-Id: 3.3.3.3
BFD Status: Down
Interface: GE1/0/1
IPv6-Local-Address: FE80::E0:CE19:8142:2
IPv6-Remote-Address: FE80::E0:9C69:8142:1
BFD Module preferred timer values
OSPFv3 Module preferred timer values
Configured timer values
# Run the shutdown command on GE 1/0/0 of Router B to simulate the active link failure.
# Display the routing table on Router A. The standby link Router A → Router C → Router B
takes effect after the active link fails. The next hop address of the route to 2001:DB8:4::1/64
becomes GigabitEthernet1/0/1.
<RouterA> display ospfv3 routing
OSPFv3 Process (1)
Destination Metric
Next-hop
2001:DB8:1::/64 1
2001:DB8:2::/64 2
2001:DB8:3::/64 1

2001:DB8:4::1/64 2
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
bfd
#
ospfv3 1
router-id 1.1.1.1
bfd all-interfaces min-transmit-interval 100 min-receive-interval 100 detect-
multiplier 4
#
ipv6 enable
#
ipv6 enable
#
return

#
sysname RouterB
#
ipv6
#
bfd
#
ospfv3 1
router-id 2.2.2.2
multiplier 4
#
ipv6 enable
#
ipv6 enable
#
ipv6 enable
#
return

#

sysname RouterC
#
ipv6
#
ospfv3 1
router-id 3.3.3.3
multiplier 4
#
ipv6 enable
#
ipv6 enable
#
return
6.16.6 Example for Configuring IPSec for OSPFv3

On an OSPFv3 network, you can configure OSPFv3 IPSec on the interfaces setting up OSPFv3
neighbor relationships to protect the devices against forged OSPFv3 protocol packets.
As shown in Figure 6-6, RouterA and RouterB run Open Shortest Path First version 3 (OSPFv3)
and are reachable. If no authentication mechanism is configured, IP packets along the route
between RouterA and RouterB may be modified or faked, causing neighbor relationships
between RouterA and RouterB to be interrupted or incorrect routes to be imported.
To prevent such attacks, IPSec can be configured between RouterA and RouterB to protect
OSPFv3 packets during transmission. ESP is configured as the security protocol, and SHA-1 is
configured as the authentication algorithm.
Figure 6-6 Configuring IPSec
RouterA RouterB
GE1/0/1 GE1/0/1
Internet
2001:DB8:100::1/64 2001:DB8:100::2/64
1. Configure basic OSPFv3 functions on RouterA and RouterB.

2. Configure a security proposal and define the security protocol and authentication algorithm
and encapsulation mode.

3. Configure an SA and apply a proposal to SA, define inbound and outbound parameters
which include SPI and keys.
4. Apply the SA to the OSPFv3 process to protect OSPFv3 packets between RouterA and
RouterB.
Data Preparation
Device Router Proc IPv6 Address SPI Authentication Key

Name ID ess in the String Format
ID
RouterA 1.1.1.1 1 GE1/0/1: 12345 Huawei-123

2001:DB8:100::
1/64
RouterB 2.2.2.2 1 GE1/0/1: 12345 Huawei-123

2001:DB8:100::
2/64
Procedure
Step 1 Configure OSPFv3 on RouterA and RouterB.
# Configure RouterA.
[RouterA] ospfv3 1
[RouterA-ospfv3-1] area 1
[RouterA-ospfv3-1-area-0.0.0.1] quit
# Configure RouterB.
[RouterB] ospfv3 1
[RouterB-ospfv3-1] area 1
[RouterB-ospfv3-1-area-0.0.0.1] quit
Step 2 Configure IPv6 addresses and enable OSPFv3 on interfaces.

[RouterA] interface gigabitethernet1/0/1
[RouterA-GigabitEthernet1/0/1] ipv6 address 2001:DB8:100::1 64
# Configure RouterB.

[RouterB-GigabitEthernet1/0/1] ipv6 address 2001:DB8:100::2 64

Step 3 Configure security proposals on RouterA and RouterB.
# Configure a security proposal on RouterA.

[RouterA] ipsec proposal proposal1
[RouterA-ipsec-proposal-proposal1] encapsulation-mode transport
[RouterA-ipsec-proposal-proposal1] transform esp
[RouterA-ipsec-proposal-proposal1] undo esp encryption-algorithm
[RouterA-ipsec-proposal-proposal1] esp authentication-algorithm sha1
[RouterA-ipsec-proposal-proposal1] quit
# Configure a security proposal on RouterB.

[RouterB] ipsec proposal proposal2
[RouterB-ipsec-proposal-proposal2] encapsulation-mode transport
[RouterB-ipsec-proposal-proposal2] transform esp
[RouterB-ipsec-proposal-proposal2] undo esp encryption-algorithm
[RouterB-ipsec-proposal-proposal2] esp authentication-algorithm sha1
[RouterB-ipsec-proposal-proposal2] quit
# Run the display ipsec proposal command on RouterA and RouterB to view configurations.
Use the display on RouterA as an example.
[RouterA] display ipsec proposal
Total IP security proposal number: 1
IP security proposal name: proposal1
encapsulation mode: transport
transform: esp-new
ESP protocol: authentication MD5-HMAC-96, not use encryption
Step 4 Configure SAs and apply them to RouterA and RouterB.
# Configure an SA and apply it to RouterA.

[RouterA] ipsec sa sa1
[RouterA-ipsec-sa-sa1] proposal proposal1
[RouterA-ipsec-sa-sa1] quit
# Configure an SA and apply it to RouterB.

[RouterB] ipsec sa sa2
[RouterB-ipsec-sa-sa2] proposal proposal2
[RouterB-ipsec-sa-sa2] quit
Step 5 Configure SPIs and authentication keys in the string format on RouterA and RouterB.
# Configure SPIs and authentication keys in the string format on RouterA.

[RouterA] ipsec sa sa1
[RouterA-ipsec-sa-sa1] sa spi inbound esp 12345
[RouterA-ipsec-sa-sa1] sa spi outbound esp 12345
[RouterA-ipsec-sa-sa1] sa string-key inbound esp Huawei-123
[RouterA-ipsec-sa-sa1] sa string-key outbound esp Huawei-123
[RouterA-ipsec-sa-sa1] quit
# Configure SPIs and authentication keys in the string format on RouterB.

[RouterB] ipsec sa sa2
[RouterB-ipsec-sa-sa2] sa spi outbound esp 12345
[RouterB-ipsec-sa-sa2] sa spi inbound esp 12345
[RouterB-ipsec-sa-sa2] sa string-key outbound esp Huawei-123
[RouterB-ipsec-sa-sa2] sa string-key inbound esp Huawei-123
[RouterB-ipsec-sa-sa2] quit

Step 6 Configure SAs for OSPFv3 processes.
# Configure an SA for the OSPFv3 process on RouterA.

[RouterA] ospfv3 1
[RouterA-ospfv3-1] ipsec sa sa1
# Configure an SA for the OSPFv3 process on RouterB.

[RouterB] ospfv3 1
[RouterB-ospfv3-1] ipsec sa sa2
# Run the display ipsec sa command on RouterA and RouterB to view configurations. Use the
display on RouterA as an example.
[RouterA] display ipsec sa
Total IP security association number: 1
IP security association name: sa1
Number of references: 1
proposal name: proposal1
inbound AH setting:
AH spi:
AH string-key:
AH authentication hex key:
inbound ESP setting:
ESP spi: 12345 (0x3039)
ESP string-key: b{br9\zi%X+/Y@:Y>Lw(L\v#
ESP encryption hex key:
ESP authentication hex key:
outbound AH setting:
AH spi:
AH string-key:
AH authentication hex key:
outbound ESP setting:
ESP spi: 12345 (0x3039)
ESP string-key: D0>GQf"}w2@X,k6.E\Z,z\{#
ESP encryption hex key:
ESP authentication hex key:
# Run the display ipsec statistics command to view statistics about incoming and outgoing
packets processed by IPSec and detailed information about dropped packets. If statistics about
incoming and outgoing packets processed by IPSec are displayed, the configuration succeeds.
For example:
[RouterA] display ipsec statistics
IPv6 security packet statistics:
input/output security packets: 184/19
input/output security bytes: 13216/1312
input/output dropped security packets: 0/0
dropped security packet detail:
memory process problem: 0
can't find SA: 0
queue is full: 0
authentication is failed: 0
wrong length: 0
replay packet: 0
too long packet: 0
invalid SA: 0
policy deny: 0
the normal packet statistics:
input/output dropped normal packets: 0/0

IPv4 security packet statistics:

input/output security packets: 0/0
input/output security bytes: 0/0
input/output dropped security packets: 0/0
dropped security packet detail:
memory process problem: 0
can't find SA: 0
queue is full: 0
authentication is failed: 0
wrong length: 0
replay packet: 0
too long packet: 0
invalid SA: 0
policy deny: 0
the normal packet statistics:
input/output dropped normal packets: 0/0
----End
Configuration Files
l Configuration file of RouterA
#
sysname RouterA
#
ipsec proposal proposal1
encapsulation-mode transport
esp authentication-algorithm sha1
undo esp encryption-algorithm
#
ipsec sa sa1
proposal proposal1
sa spi inbound esp 12345
sa string-key inbound esp %@%@%#%#b{br9\zi%X+/Y@:Y>Lw(L\v#%@%@%#%#
sa spi outbound esp 12345
sa string-key outbound esp %@%@%#%#D0>GQf"}w2@X,k6.E\Z,z\{#%@%@%#%#
#
ospfv3 1
router-id 1.1.1.1
ipsec sa sa1
area 0.0.0.1
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:100::1/64
#
l Configuration file of RouterB

#
sysname RouterB
#
ipsec proposal proposal2
encapsulation-mode transport
esp authentication-algorithm sha1
undo esp encryption-algorithm
#
ipsec sa sa2
proposal proposal2
sa spi inbound esp 12345
sa string-key inbound esp %@%@%#%#VlrZ=1vTW":z9:%F`[a=o[t#%@%@%#%#
sa spi outbound esp 12345
sa string-key outbound esp %@%@%#%#)YTP%@nFE7bL^B&WSBiQ1[p#%@%@%#%#
#
ospfv3 1

router-id 2.2.2.2
ipsec sa sa2
area 0.0.0.1
#
undo shutdown
ipv6 enable
ipv6 address 2001:DB8:100::2/64
#

Configuration Guide - IP Routing 7 IS-IS Configuration
7 IS-IS Configuration
About This Chapter
This chapter describes the basic principle of IS-IS and procedures for configuring IS-IS, and
provides configuration examples.
7.1 Introduction
By building IS-IS networks, you can enable IS-IS to discover and calculate routes in ASs.
7.2 Configuring Basic IPv4 IS-IS Functions
This section describes the procedures for configuring basic IPv4 IS-IS functions, including the
procedures for configuring IS-IS processes and interfaces, to implement communication
between nodes on an IPv4 IS-IS network.
7.3 Establishing or Maintaining IS-IS Neighbor Relationships or Adjacencies
This section describes how to configure the parameters that affect the IS-IS neighbor
relationship.
7.4 Configuring IPv4 IS-IS Route Selection
Configuring IS-IS route selection can achieve refined control over route selection.
7.5 Configuring IPv4 IS-IS Route Summarization
To improve the route searching efficiency and simplify route management on a large-scale IS-
IS network, configure IS-IS route summarization to reduce the number of IS-IS routes in a
routing table.
7.6 Configuring IPv4 IS-IS to Interact with Other Routing Protocols
If other routing protocols are configured on an IS-IS network, you need to configure IS-IS to
interact with these protocols to ensure successful communication between them.
7.7 Configuring the IPv4 IS-IS Route Convergence Speed
Accelerating IS-IS route convergence can improve the fault location efficiency and improve the
network reliability.
7.8 Configuring Static BFD for IPv4 IS-IS
BFD can provide link failure detection featuring light load and high speed (at the millisecond
level). Static BFD can be configured to monitor IS-IS links.
7.9 Configuring Dynamic BFD for IPv4 IS-IS
Dynamic BFD for IPv4 IS-IS can accelerate IS-IS route convergence.

7.10 Configuring Multi-Topology for IPv4 IS-IS

By configuring multi-topology on an IS-IS network, you can properly allocate network
resources.
7.11 Configuring IPv4 IS-IS Auto FRR
With IS-IS Auto FRR, traffic on a faulty link can be quickly switched to the backup link of the
faulty link. This ensures that the traffic interruption time is within 50 ms and improves the
reliability of IS-IS networks.
routing table.
7.15 Configuring IPv6 IS-IS to Interact with Other Routing Protocols
If high-speed data services are deployed on an IS-IS network, dynamic BFD for IPv6 IS-IS can
be configured to accelerate the fault detection speed.
resources.
With IPv6 IS-IS Auto FRR, traffic on a faulty link can be quickly switched to the backup link
of the faulty link. This ensures that the traffic interruption time is within 50 ms and improves
the reliability of IS-IS networks.
By configuring local MT, you can enable multicast packets to be forwarded through TE tunnels
on IS-IS networks.
7.21 Configuring IS-IS GR
By configuring IS-IS GR, you can enable Router to restart gracefully and avoid temporary black
holes.
7.22 Improving Security of an IS-IS Network
On a network that requires high security, you can configure IS-IS authentication or optional
checksum to improve the security of the IS-IS network.
7.23 Maintaining IS-IS
Maintaining IS-IS involves resetting IS-IS and clearing IS-IS statistics.


This section provides several configuration examples of IS-IS. The configuration examples
explain networking requirements, configuration notes, and configuration roadmap.

7.1 Introduction
By building IS-IS networks, you can enable IS-IS to discover and calculate routes in ASs.
7.1.1 Basic Concepts of IS-IS

As an IGP, IS-IS is used inside an AS. IS-IS is a link-state protocol. It uses the SPF algorithm
to calculate routes.
The Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol that was
originally created by the International Organization for Standardization (ISO) for its
Connectionless Network Protocol (CLNP).
To support the IP routing, the Internet Engineering Task Force (IETF) extended and modified
IS-IS in RFC 1195. IS-IS can therefore be applied to both TCP/IP and OSI environments. This
type of IS-IS is called the Integrated IS-IS or Dual IS-IS.
As an Interior Gateway Protocol (IGP), IS-IS is used in Autonomous Systems (ASs). IS-IS is a
link-state protocol. It uses the Shortest Path First (SPF) algorithm to calculate routes. It resembles
the Open Shortest Path First (OSPF) protocol.
IS-IS Areas
To support large-scale networks, the IS-IS adopts a two-level structure in a Routing Domain
(RD). A large RD is divided into one or more areas. The intra-area routes are managed by the
Level-1 routers, whereas the inter-area routes are managed by the Level-2 routers.
Figure 7-1 shows an IS-IS network. Its topology is similar to that of a multi-area OSPF network.
Area 1 is a backbone area. All routers in this area are Level-2 routers. The other four areas are
non-backbone areas. They are connected to Area 1 through Level-1-2 routers.
Figure 7-1 IS-IS topology
Area2 Area3
L1 L1/2
L1/2
L2
L2 Area1
L2 L2
Area5
Area4
L1/2
L1/2 L1
L1 L1 L1 L1

Figure 7-2 shows another type of IS-IS topology. The Level-1-2 routers are used to connect the
Level-1 and the Level-2 routers, and are used to establish the backbone network together with
the other Level-2 routers.The IS-IS backbone network does not refer to a specific area, in this
topology, no area is specified as a backbone area. All the Level-2 routers constitute an IS-IS
backbone network. The devices may belong to different areas, but the areas must be successive.
Figure 7-2 IS-IS topology II
Area1
L1
L1
L2
Area2
L1/L2
L1/L2
Area4 L1
L2
L2 Area3
This type of networking shows differences between IS-IS and OSPF. For OSPF, the inter-area
routes are forwarded by the backbone area and the SPF algorithm is used in the same area. For
IS-IS, both Level-1 routers and Level-2 routers use the SPF algorithm to generate Shortest Path
Trees (SPTs).
Network Types
IS-IS supports only two network types, which can classify as follows according to physical links:
l Broadcast links such as Ethernet and Token-Ring.
l Point-to-point links such as PPP and HDLC.
NOTE
For a Non-Broadcast Multi-Access (NBMA) network such as ATM, you need to configure sub-interfaces
for it. The type of subnets cannot be Point-to-Multipoint (P2MP). IS-IS cannot run on P2MP networks.
7.1.2 IS-IS Features Supported by the NE80E/40E

The NE80E/40E supports various Intermediate System-to-Intermediate System (IS-IS) protocol
features, including multi-instance, multi-process, hot standby (HSB), local multicast-topology
(MT), multi-topology, graceful restart (GR), traffic engineering (TE), administrative tags, Link
State Protocol Data Unit (LSP) fragment extension, dynamic host name exchange, route
summarization, load balancing, IS-IS Preference, fast convergence, Bidirectional Forwarding
Detection (BFD), and three-way handshake.
Multi-Instance and Multi-Process

IS-IS supports multi-process and multi-instance, facilitating management and improving control
efficiency of IS-IS.

l Multi-process
Multi-process allows a group of interfaces to be associated with a specific IS-IS process.
This ensures that the specific IS-IS process performs all the protocol-based operations only
on the group of interfaces. Multiple IS-IS processes can run on a single router and each
process is responsible for a unique group of interfaces.
l Multi-instance
After the VPN feature is enabled, multi-instance allows an IS-IS process to be associated
with a specific VPN instance so that all the interfaces of this IS-IS process will be associated
with the VPN instance.
IS-IS HSB
The router of a distributed architecture supports IS-IS HSB. In the IS-IS HSB process, 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. This ensures uninterrupted running of IS-IS.
In the IS-IS HSB process, IS-IS configurations on the AMB and the SMB are consistent. After
a master/slave AMB/SMB switchover, IS-IS on the current AMB performs GR, obtains
adjacencies from its neighbors, and synchronizes its link state database (LSDB) with the LSDB
on the SMB. This prevents service interruption.
Local MT
When multicast and Multi-Protocol Label Switching (MPLS) TE tunnels are deployed on a
network, multicast may be affected by TE tunnels, which causes multicast services to become
unavailable.
This is because the outbound interface of a route calculated by an Interior Gateway Protocol
(IGP) may not be the actual physical interface but a TE tunnel interface after the TE tunnel is
enabled with IGP Shortcut. Based on the unicast route to the multicast source address, a
router sends a Join message through a TE tunnel interface. In this situation, routers spanned by
the TE tunnel cannot detect the Join message, so they do not create any multicast forwarding
entry. A TE tunnel is unidirectional, so multicast data packets sent by the multicast source are
sent to the routers spanned by the tunnel through physical interfaces. These routers discard the
multicast data packets, because they do not have any multicast forwarding entry. As a result,
services become unavailable.
To solve this problem, you can enable local MT to create a separate Multicast IGP (MIGP)
routing table for multicast packets.
NOTE
For details about local MT, see the IS-IS Local MT of "IS-IS" chapter in the HUAWEI NetEngine80E/
40E Router Feature Description-IP Routing.
IS-IS MT
IS-IS MT, a set of independent IP topologies, is an optional mechanism within IS-ISs used today
by many ISPs for IGP routing. This MT extension can be used for a variety of purposes, such
as an in-band management network "on top" of the original IGP topology, maintaining separate
IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a
subset of an address space to follow a different topology. Complying with RFC 5120, IS-IS MT
defines new type-length-values (TLVs) in IS-IS packets to transmit multi-topology information.

A physical network can be divided into different logical topologies as needed. Each logical
topology maintains its own routing table and uses the Shortest Path First (SPF) algorithm to
calculate routes. Traffic of different services (including traffic of different IP topologies) can be
forwarded along different paths. With logical topologies, IS-IS MT can help customers better
utilize network resources and reduce network construction costs.
IS-IS MT has the following functions:

l Separation between IPv4 and IPv6 topologies
IS-IS implements IPv6 using extended TLVs. IS-IS establishes and maintains neighbor
databases and topology databases as defined in ISO 10589 and RFC 1195. IPv4 and IPv6
networks have the same topology. The IPv4 and IPv6 hybrid topology can be regarded as
an integrated topology, which uses the SPF algorithm to calculate routes. It is required that
all IPv4 and IPv6 topology information be the same.
In applications, however, not all devices on the same network support both IPv4 and IPv6.
This may result in inconsistency between IPv4 and IPv6 topology information. In an IPv4
and IPv6 hybrid topology, some routers and links do not support IPv6. Routers supporting
IPv4/IPv6 dual-stack still forward IPv6 packets to them. As a result, these routers and links
discard the IPv6 packets. IPv4 packets also fail to be forwarded if some routers and links
do not support IPv4.
IS-IS MT uses the SPF algorithm on an IPv6 topology, and sets up a routing table on each
device in the IPv6 topology. This solves the problem of inconsistency between IPv4 and
IPv6 topology information.
l Separation between unicast and multicast topologies
If an MPLS TE tunnel is deployed in a unicast topology, the outbound interface of the route
calculated by IS-IS may not be a physical interface but a TE tunnel interface. No multicast
forwarding entry is created on the router that the TE tunnel traverses. The router will discard
packets sent from a multicast source, causing multicast service interruption.
With IS-IS MT, a separate multicast topology can be set up for multicast services, and the
multicast topology is separated from the unicast topology. TE tunnels are excluded from a
multicast topology, ensuring continuity of multicast services.
NOTE
For details about IS-IS MT, see the IS-IS MT of "IS-IS" chapter in the HUAWEI NetEngine80E/
40E Router Feature Description-IP Routing.
IS-IS GR
GR is a function used to restart a router gracefully. It ensures uninterrupted traffic forwarding
during the restart of a router in a short time.
If IS-IS restarts in a non-graceful mode, IS-IS sessions are reset and Link State Protocol Data
Units (LSPs) are regenerated and flooded. This triggers the SPF calculation in the entire area,
which causes route flapping and forwarding interruption in the area. The IETF defines IS-IS GR
in RFC 3847, in which the specifications of protocol restart with FIB tables reserved and
unreserved are stated.
NOTE
For details about IS-IS GR, see the "IS-IS" chapter in the HUAWEI NetEngine80E/40E Router Feature
Description-IP Routing.

IS-IS TE
IS-IS TE supports MPLS to set up and maintain the label switched paths (LSPs).
When establishing constraint-based routed (CR) LSPs, MPLS needs to learn the traffic attributes
of all the links in the local area. CR-LSPs can acquire the TE information of the links using IS-
IS.
NOTE
For details about IS-IS TE, see the HUAWEI NetEngine80E/40E Router Configuration Guide-MPLS.
All the other LSPs referred to in this chapter are link state protocol data units. Differentiate the two
acronyms.
Administrative Tag
The use of administrative tags simplifies management. Administrative tags can advertise IP
address prefixes in the IS-IS area to control routes. The administrative tag carries the
administrative information about an IP address prefix. It is used to control the routes of different
levels and routes imported from different areas, various routing protocols, multiple IS-IS
instances running on a router, and carrying of tags.
Each administrative tag is associated with certain attributes. If the prefix of the reachable IP
address to be advertised by IS-IS has this attribute, IS-IS adds the administrative tag to the
reachability TLV in the prefix. In this manner, the tag is advertised throughout the entire IS-IS
area.
LSP Fragment Extension

When more information is carried in an LSP to be advertised by IS-IS, IS-IS advertises multiple
LSP fragments. Each LSP fragment is identified by the LSP identifier field of an LSP. The LSP
identifier field is 1 byte long. Therefore, the maximum number of fragments that can be generated
by an IS-IS device is 256.
The IS-IS fragment extension feature allows an IS-IS device to generate more LSP fragments.
To implement this feature, you can use the network manager to configure additional system IDs
for the router. Each system ID represents a virtual system, which can generate 256 LSP
fragments. With more additional system IDs (up to 50 virtual systems), an IS-IS device can
generate a maximum of 13056 LSP fragments.
l Related terms are as follows:

– Originating system
In this document, the originating system is the router that actually runs the IS-IS
protocol, and each IS-IS process is regraded as multiple virtual routers to generate LSP
fragments.
– Normal system ID
It is the system ID of the originating system.
– Additional System-ID
An additional system ID, assigned by the network administrator, represents a virtual
system. Each virtual system is allowed to generate up to 256 extended LSP fragments.
Like a normal system ID, an additional system ID must be unique in a routing domain.
– Virtual system

It is a virtual system for generating extended LSP fragments. Each virtual system has a
unique additional system ID, and each extended LSP fragment carries an additional
system ID.
l Operating mode
An IS-IS device can run the LSP fragment extension feature in the following modes:
– Mode 1: The originating system sends a link to each virtual system. Then each virtual
system sends a link to the originating system. The virtual systems function as the
routers that are connected to the originating system on the network. This mode is used
when some routers on the network do not support the LSP fragment extension feature.
In this mode, only the routing information can be advertised in the LSPs of the virtual
systems.
– Mode 2: All the routers on the network can learn that the LSPs generated by the virtual
systems actually belong to the originating system. This mode is used when all the
routers on the network support the LSP fragment extension feature. In this mode, all
link state information can be advertised in the LSPs of the virtual systems.
Dynamic Host Name Exchange Mechanism

The dynamic host name exchange mechanism is introduced to conveniently manage and
maintain IS-IS networks. The mechanism provides a service of mapping host names to system
IDs for the IS-IS devices. The dynamic host name information is advertised in the form of a
dynamic host name TLV in an LSP.
The dynamic host name exchange mechanism also provides a service to associate a host name
with the designated intermediate system (DIS) on a broadcast network. Then LSPs of pseudo
nodes advertise this association in the form of a dynamic host name TLV.
It is easier to identify and memorize the host name than the system ID. After this function is
configured, the host name will display when display command is used.
IS-IS Route Summarization

Route summarization is a function for summarizing routes with the same IP prefix into one route.
On a large-scale IS-IS network, you can configure route summarization to reduce the number
of IS-IS routes in the routing table. This improves the usage of system resources and facilitates
route management.
IP network segments are not affected when a link frequently alternates between Up and Down
on an IP network segment. This prevents route flapping and improves the network stability.
The router supports classless network-based route summarization.
IS-IS Load Balancing

If there are redundant links on an IS-IS network, there may be multiple equal-cost routes.
Configuring IS-IS load balancing can evenly distribute traffic to each link. This increases the
bandwidth usage of each link and prevents network congestion caused by some overloaded links.
IS-IS load balancing, however, may affect traffic management because traffic will be randomly
forwarded in this mode.

IS-IS Preference
If there are redundant links on an IS-IS network, there may be multiple equal-cost routes.
The router allows you to configure preference values for equal-cost IS-IS routes so that only the
route with the highest preference will be used and the others will function as backups.
This facilitates traffic management, improves the network reliability, and avoids configuration
change.
IS-IS Fast Convergence

l Incremental SPF (I-SPF)
I-SPF calculates only changed routes at a time, but not all routes.
ISO-10589 defines Dijkstra as the algorithm to calculate routes. When a node is added to
or removed from a network topology, all routes of all nodes need to be calculated if the
Dijkstra algorithm is adopted. As a result, it takes a long time and occupies excessive
resources, reducing the route convergence speed of the entire network.
I-SPF improves this algorithm. Except for the first time, only changed nodes instead of all
nodes are involved in calculation. The SPT generated at last is the same as that generated
by the Dijkstra algorithm. This decreases the CPU usage and speeds up route convergence.
l Partial route calculation (PRC)
Similar to I-SPF, only changed nodes are involved in PRC. PRC, however, does not
calculate the shortest path but updates leaf 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
calculated using I-SPF changes, PRC calculates all the leaves on only the changed node;
if the SPT calculated using I-SPF does not change, PRC calculates only the changed leaf.
For example, if an interface of a node is enabled with IS-IS, the SPT of the entire network
remains unchanged. In this case, PRC updates the routes on only the interface of this node,
reducing the CPU usage.
PRC working with I-SPF further improves the convergence performance of the network.
As an improvement of the original SPF algorithm, RPC and I-SPF replace the original
algorithm.
NOTE
In real world applications of NE80E/40Es, only I-SPF and PRC are used to calculate IS-IS routes.
l LSP fast flooding
Based on the RFC, when IS-IS receives LSPs from other routers and the LSPs are more
updated than those in its own LSDB, IS-IS uses a timer to flood out the LSPs in the LSDB
at specified intervals. Therefore, the LSDB synchronization is slow.
LSP fast flooding addresses the problem. When a router configured with this feature
receives one or more LSPs, it floods out the LSPs less than the specified number before
route calculation. This accelerates the LSDB synchronization and speeds up network
convergence to the great extent.
l Intelligent timer
Although the route calculation algorithm is improved, the long interval for triggering route
calculation also affects the convergence speed. Using a millisecond timer can shorten the
interval, however, excessive CPU resources will be consumed if the network topology
changes frequently. An SPF intelligent timer can quickly respond to certain emergent events
and also prevent excessive CPU resource consumption.

An IS-IS network running normally is stable. The network seldom changes frequently, and
an IS-IS device does not calculate routes frequently. Therefore, you can set a short interval
(in milliseconds) for triggering the route calculation for the first time. If the network
topology changes frequently, the value of the intelligent timer increases with the calculation
times, and the interval for route calculation becomes longer. This prevents excessive CPU
resource consumption.
The LSP generation intelligent timer is similar to the SPF intelligent timer. In IS-IS, when
the LSP generation timer expires, the system regenerates its own LSP according to the
current topology. In the original implementation mechanism, a timer with a fixed value is
used, which, however, cannot meet the requirements on fast convergence and low CPU
usage. Therefore, the LSP generation timer is designed as an intelligent timer so that it can
respond quickly to some emergent events (such as interface alternation between Up and
Down) to speed up network convergence. In addition, when the network changes
frequently, the value of the intelligent timer becomes greater automatically to prevent
excessive CPU resource consumption.
NOTE
Determine whether to configure intelligent timers based on actual network situations and
specifications of deployed routers.
BFD for IS-IS

The NE80E/40E supports BFD for IS-IS to detect IS-IS neighbor relationships. BFD can fast
detect the faults on links between IS-IS neighbors and reports them to IS-IS. Fast convergence
of IS-IS is then implemented.
NOTE
BFD detects only one-hop links between IS-IS neighbors. This is because IS-IS establishes only one-hop
neighbors.
l Static BFD
To configure static BFD, use command lines to configure single-hop BFD parameters, such
as local and remote discriminators. Then configure the device to send BFD session setup
requests.
A static BFD session can only be established and released manually. A configuration error
will lead to a BFD failure. For example, if the configured local discriminator or remote
discriminator is incorrect, a BFD session will not work properly.
The NE80E/40E supports static IPv4 BFD for IS-IS.
l Dynamic BFD
Dynamic BFD refers to the dynamic establishment of BFD sessions using routing protocols.
When a new IS-IS neighbor relationship is set up, BFD is notified of the parameters of the
neighbor and the detection parameters (including source and destination IP addresses).
Then a BFD session will be established based on the received parameters of the neighbor.
Dynamic BFD is more flexible than static BFD.
Connection status between an IS-IS device and its neighbors can be monitored by
exchanging Hello packets at intervals. The sending interval is usually set to 10s, and a
neighbor is declared Down after at least three intervals (during which no response Hello
packet is received from the neighbor). It takes IS-IS some seconds to sense a Down
neighbor, resulting in loss of a large amount of high-speed data.
Dynamic BFD can provide link failure detection with light load and high speed (at the
millisecond level). Dynamic BFD does not take the place of the Hello mechanism of IS-

IS, but helps IS-IS to detect the faults on neighbors or links more quickly, and instruct IS-
IS to recalculate routes to correctly guide packet forwarding.
The NE80E/40E supports dynamic IPv4 and IPv6 BFD for IS-IS.
NOTE
For details about IS-IS GR, see the "IS-IS" chapter in the HUAWEI NetEngine80E/40E Router
Feature Description-IP Routing.
IS-IS Three-Way Handshake

A reliable link layer protocol is required when IS-IS runs on a point-to-point (P2P) link. Based
on ISO 10589, the two-way handshake mechanism of IS-IS uses Hello packets to set up P2P
adjacencies between neighboring routers. Once the router receives a Hello packet from its peer,
it regards the status of the peer as Up and sets up an adjacency with the peer.
This mechanism has obvious defects. For example, when an adjacency is set up, the unstable
link status causes the loss of Complete Sequence Number Packets (CSNPs). As a result, the
LSDB fails to be synchronized during the update period of an LSP. If two or more links exist
between two routers, an adjacency can still be set up when one link is Down and the other is Up
in the same direction. The parameters of the other link, however, are also used in SPF calculation.
Therouter does not detect any fault of the link that is in the Down state and still tries to forward
packets over this link.
The three-way handshake mechanism addresses the problem on the unreliable P2P link. In three-
way handshake mode, the router regards the neighbor as Up only after confirming that the
neighbor receives the packet that it sends and then sets up an adjacency with the neighbor. In
addition, a 32-bit circuit ID is used in the three-way handshake mechanism, which is an extension
of the local 8-bit circuit ID that defines 255 P2P links.


Before configuring basic IPv4 IS-IS functions, familiarize yourself with the usage scenario,
To deploy IS-IS on an IPv4 network, configure basic IS-IS functions to implement
communication between different nodes on the network.
Other IS-IS functions can be configured only after basic IS-IS functions are configured.
Configuring basic IPv4 IS-IS functions includes the following operations:

1. Create IPv4 IS-IS processes.
2. Configure IPv4 IS-IS interfaces.

Before configuring basic IPv4 IS-IS functions, complete the following tasks:
l Configure a link layer protocol.

l Assign an IP address to each interface to ensure IP connectivity.
Data Preparation
To configure basic IPv4 IS-IS functions, you need the following data.
No. Data
1 IS-IS process ID
2 NTE of an IS-IS process
3 Level of each device and level of each interface
7.2.2 Creating IPv4 IS-IS Processes

Before configuring basic IPv4 IS-IS functions, create IPv4 IS-IS processes and then enable IPv4
IS-IS interfaces.
Context
To create an IPv4 IS-IS process, perform the following operations:
l Create an IS-IS process and configure the NET of a device.
l (Optional) Configure the level of a device.
The level of a device is Level-1-2 by default.
Configure the device level based on the network planning. If no device level is configured,
IS-IS establishes separate neighbor relationships for Level-1 and Level-2 devices and
maintains two identical LSDBs, consuming excessive system resources.
l (Optional) Configure IS-IS host name mapping.
After IS-IS host name mapping is configured, a host name but not the system ID of a device
will display by using display commands. This configuration improves the maintainability
on an IS-IS network.
l (Optional) Enable the output of the IS-IS adjacency status.
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.
l (Optional) Enable IS-IS adjacency strict-check.
If both IPv4 and IPv6 are running on a network, and the IPv6 topology type of this network
is standard or compatible, enable IS-IS adjacency strict-check to ensure that an IS-IS
adjacency is established only when both IPv4 and IPv6 go Up. IS-IS adjacency strict-check
improves network reliability and prevents traffic losses.

Procedure
1. Run:
system-view

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. To associate an IS-IS process with a VPN instance, run the isis process-
id vpn-instance vpn-instance-name command.
3. Run:
network-entity net
or
network-entity area area-id auto-systemid lsr-id
A NET is configured.
NET of IS-IS consists of three parts:

– Part one is the area ID that is variable (1 to 13 bytes), and the area IDs of the devices
in the same area are identical.
– Part two is the system ID (6 bytes) of this device, which must be unique in the
whole area and backbone area.
– Part three is the last byte "SEL", whose value must be "00".
For example, the NET of IS-IS device can be configured as 10.1234.6e9f.0001.00.
NOTICE
l 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.
l The system ID must be unique in the whole area and backbone area.
l A maximum of three area IDs can be configured for an IS-IS process. Therefore,
a maximum of three NETs can be configured. When configuring multiple NETs,
ensure that they share the same system ID.
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.
System ID used in IS-IS can be obtained in the following way: extend each part of the
IP address to 3 bits, add 0 to the front of any part that is shorter than 3 bits, divide the
extended address into three parts, with each part consisting of four decimal digits, and
the reconstructed address is the system ID.

4. (Optional) Run:
description
Descriptions for the IS-IS process are configured.

1. Run:
is-level { level-1 | level-1-2 | level-2 }
The level of the router is configured.

1. Run:
is-name symbolic-name
IS-IS dynamic host name mapping is configured. The system ID of the local device
is mapped to the specified host name.
The value of symbolic-name is contained in LSP packets and advertised to other IS-
IS devices.
On another IS-IS device displays the value of symbolic-name, but not the system ID,
of the local IS-IS device.
2. Run:
is-name map system-id symbolic-name
IS-IS static host name mapping is configured. The system ID of a peer IS-IS device
This command configuration takes effect only on the local IS-IS device. The value of
symbolic-name will not be added to LSP packets.
If dynamic host name mappings is configured on an IS-IS network, the mappings on
the network overwrite the mappings configured on the local router.
1. Run:
log-peer-change
The output of the adjacency status is enabled.

1. Run:
adjacency-strict-check enable
IS-IS adjacency strict-check is enabled.

----End
7.2.3 Configuring IPv4 IS-IS Interfaces

To configure an interface of an IS-IS device to send Hello packets or flood LSPs, enable IS-IS
on this interface first.
Context
The level of an IS-IS device and level of an interface determine the level of a neighbor
relationship. By default, Level-1 and Level-2 neighbor relationships are established between

two Level-1-2 devices. If only one level of neighbor relationships is required, you can configure
the level of an interface to prevent the establishment of the other level of neighbor relationships.
After IS-IS is enabled on an interface, the interface automatically sends Hello packets, attempting
to establish neighbor relationships. If a peer device is not an IS-IS device or an interface is not
expected to send Hello packets, suppress the interface. Then this interface only advertises routes
of the network segment where the interface resides, but does not send Hello packets. This
suppression improves the link bandwidth usage.
Procedure
l Configure an IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
isis enable [ process-id ]
An IS-IS interface is configured.
After this command is run, the IS-IS device uses the specified interface to send Hello
packets and flood LSPs.
NOTE
No neighbor relationship needs to be established between loopback interfaces. If this command

is run on a loopback interface, the routes of the network segment where the loopback interface
resides will be advertised through other IS-IS interfaces.
l (Optional) Configure the level of an IS-IS interface.
1. 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.
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 IS-IS device is not a Level-1-2, the level of the IS-IS device
determines the level of the adjacency to be established.
l (Optional) Suppress an IS-IS interface.
1. Run:
isis silent [ advertise-zero-cost ]
The IS-IS interface is suppressed.
A suppressed IS-IS interface does not send or receive IS-IS packets. The routes of the
network segment where the interface resides, however, can still be advertised to other
routers within the area.

l (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.
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
7.2.4 (Optional) Configuring the IPv4 IS-IS Interfaces

Configuring the IS-IS interface costs can control IS-IS route selection.
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 none of the preceding configurations is performed, the default cost of an IS-IS interface is 10,
and the default cost style is narrow.
Procedure
l Configure the IS-IS cost type.
1. Run:
system-view

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

3. Run:
cost-style { narrow | wide | wide-compatible | { { narrow-compatible |
compatible } [ relax-spf-limit ] } }
The IS-IS cost type is configured.
The cost range of an interface and a route received by the interface vary with the cost type.
– If the cost type is narrow, the cost of an interface ranges from 1 to 63. The maximum
cost of a route received by the interface is 1023.

– 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.
– If relax-spf-limit is not specified, the cost of a route works as follows:
If the cost of a route is not greater than 1023 and the cost of every interface that the
route passes through is smaller than or equal to 63, the cost of the route received by
the interface is the actual cost.
If the cost of a route is not greater than 1023 but the costs of all interfaces that the
route passes through are greater than 63, the IS-IS device can learn only the routes
to the network segment where the interface resides and the routes imported by the
interface. The cost of the route received by the interface is the actual cost. Subsequent
routes forwarded by the interface are discarded.
If the cost of a route is greater than 1023, the IS-IS device can learn only the interface
whose route cost exceeds 1023 for the first time. That is, the cost of each interface
before this interface is not greater than 63. The routes of the network segment where
the interface resides and the routes imported by the interface can all be learned. The
cost of the route is 1023. Subsequent routes forwarded by the interface are discarded.
– If relax-spf-limit is specified, the cost of a route works as follows:
There is no limit on costs of interfaces or route costs. The cost of a route received
by an interface is the actual cost.
– 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.
l Configure the cost of an IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
isis cost { cost | maximum } [ level-1 | level-2 ]
The cost of the IS-IS interface is configured.
You can use the isis cost command to configure the cost of a specified interface.
l 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.
You can use the circuit-cost command to configure the costs of all interfaces at a time.
l Enable IS-IS to automatically calculate interface costs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
bandwidth-reference value
The reference value of the bandwidth is configured. By default, the bandwidth

reference value is 100 Mbit/s.
4. Run:
auto-cost enable
The interface is configured to automatically calculate its cost.
The configuration of the bandwidth reference value takes effect only when the cost type is
wide or wide-compatible. In this case, Cost of each interface = (Value of bandwidth-
reference/Interface bandwidth) x 10.
NOTE
The auto-cost enable command can be run on Eth-Trunk interfaces as same with on physical
interfaces. If the command is run on an Eth-Trunk interface, the bandwidth of the Eth-Trunk interface
is equal to the total bandwidth of all its member interfaces.
If the cost-style is narrow, narrow-compatible, or compatible, the cost of each interface is

based on costs listed in Table 7-1.
Table 7-1 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

s

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

s
10 Interface bandwidth > 2.5 Gbit/s

NOTE
To change the cost of a loopback interface, run the isis cost command only in the loopback interface
view.
----End
7.2.5 (Optional) Configuring IPv4 IS-IS Attributes for Interfaces on

Different Types of Networks
Different IS-IS attributes can be configured for different types of network interfaces.
Context
The establishment modes of IS-IS neighbor relationships are different on a broadcast network
and on a P2P network. Different IS-IS attributes can be configured for interfaces on different
types of networks.
IS-IS is required to select a DIS on a broadcast network. Configure the DIS priorities of IS-IS
interfaces so that the interface with the highest priority will be selected as the DIS.
The network types of the IS-IS interfaces on both ends of a link must be the same; otherwise,
the IS-IS neighbor relationship cannot be established between the two interfaces. For example,
if the type of an interface on a peer device is P2P, you can configure the type of an interface on
the local device to P2P so that an IS-IS neighbor relationship can be established between the
two devices.
IS-IS on a P2P network is not required to select a DIS. Therefore, you do not need to configure
DIS priorities. To ensure the reliability of P2P links, configure IS-IS to use the three-way
handshake mode for IS-IS neighbor relationship establishment so that faults on a unidirectional
link can be detected.
Procedure
l Configure the DIS priority of an IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
isis dis-priority priority [ level-1 | level-2 ]
The DIS priority is configured on the interface. The greater the value, the higher the
priority.
4. (Optional) Run:
isis dis-name symbolic-name
The name of the DIS is configured for easier maintenance and management.
l Configure the network type of an IS-IS interface.

1. Run:
system-view

2. Run:

3. Run:
isis circuit-type p2p
The network type of the interface is set to P2P.
The network type of an interface is determined by the physical type of the interface
by default.
When the network type of an IS-IS interface changes, interface configurations change
accordingly.
– After a broadcast interface is configured as a P2P interface using the isis circuit-
type p2p command, the default settings are restored for the interval for sending
Hello packets, the number of Hello packets that IS-IS fails to receive from a
neighbor before the neighbor is declared Down, interval for retransmitting LSPs
on a P2P link, and various IS-IS authentication modes. Consequently, other
configurations such as the DIS priority, DIS name, and interval for sending CSNPs
on a broadcast network become invalid.
– After the undo isis circuit-type command is run to restore the network type, the
default settings are restored for the interval for sending Hello packets, the number
of Hello packets that IS-IS fails to 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.
l Set the negotiation mode in which P2P neighbor relationships can be set up.
1. Run:
system-view

2. Run:

3. Run:
isis ppp-negotiation { 2-way | 3-way [ only ] }
The negotiation mode is specified on the interface.
By default, the 3-way handshake negotiation mode is adopted.
The isis ppp-negotiation command can only be used for the establishment of the
neighbor relationships on P2P links. In the case of a broadcast link, you can run the
isis circuit-type p2p command to set the link type to P2P, and then run the isis ppp-
negotiation command to set the negotiation mode for the establishment of the
neighbor relationship.

l Configure OSICP negotiation check on PPP interfaces.

1. Run:
system-view

2. Run:

3. Run:
isis ppp-osicp-check
The OSICP negotiation status is checked on a PPP interface.
By default, the OSICP negotiation status of a PPP interface does not affect the status
of an IS-IS interface.
The isis ppp-osicp-check command is applicable only to PPP interfaces. This

command 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 route to the network segment where
the interface resides is not advertised through LSPs.
l Configure the scale of the Hello packets sent on the IS-IS interface.
1. Run:
system-view

2. Run:
NOTE
Step 3 and Step 4 are mutually exclusive. Run the command as needed.
3. Run:
isis small-hello
The Hello packets without the padding field are configured to be sent on the interface.
4. Run:
isis padding-hello
The standard Hello packets without the padding field are configured to be sent on the
interface.
l Configure IS-IS not to check whether the IP addresses of received Hello packets are on the
same network segment.
1. Run:
system-view

2. Run:


3. Run:
isis peer-ip-ignore
IS-IS is configured not to check whether the IP addresses of received Hello packets
are on the same network segment.
----End

After configuring basic IPv4 IS-IS functions, check information about IS-IS neighbors,
interfaces, and routes.
Prerequisites
Basic IPv4 IS-IS functions have been configured.
Procedure
Step 1 Run the display isis name-table [ process-id | vpn-instance vpn-instance-name ] command to
check the mapping from the name of the local device to the system ID.
Step 2 Run the display isis peer [ verbose ] [ process-id | vpn-instance vpn-instance-name ] command
to check information about IS-IS neighbors.
Step 3 Run the display isis interface [ verbose ] [ process-id | vpn-instance vpn-instance-name ]
command to check information about IS-IS interfaces.
Step 4 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.
Step 5 Run the display isis cost interface interface-type interface-number to display costs of an
interface and how they are generated.
----End
Example
Run the display isis name-table command to view the mappings between host names and system
IDs.
<HUAWEI> display isis name-table
Name table information for ISIS(1)
System ID Hostname Type

-------------------------------------------------------------------------------
1111.1111.1111 DeviceA DYNAMIC
2222.2222.2222 DeviceB DYNAMIC
Run the display isis peer command. The command output shows the status of an IS-IS neighbor,
DeviceB. System Id is displayed as DeviceB.
<HUAWEI> display isis peer

Peer information for ISIS(1)
System Id Interface Circuit Id State HoldTime Type PRI

-------------------------------------------------------------------------------
DeviceB GE1/0/0 DeviceB.01 Up 9s L1 64
Total Peer(s): 1
Run the display isis interface verbose command to view information about IS-IS interfaces.
The command output shows that the DIS status of a broadcast interface is Yes, the priority of
the DIS is 20, and the cost of the interface is 30, the configured delay for the IS-IS neighbor
relationship establishment is 100s, and that the delay has not been triggered yet.
<HUAWEI> display isis interface verbose
Interface information for ISIS(1)

---------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
GE1/0/0 001 Up Down 1497 L1/L2 Yes/No
Circuit MT State : Standard
Description : GigabitEthernet1/0/0 Interface
SNPA Address : 00e0-770a-8100
IP Address : 12.1.1.2
IPV6 Link Local Address :
IPV6 Global Address(es) :
Csnp Timer Value : L1 10 L2 10
Hello Timer Value : L1 10 L2 10
DIS Hello Timer Value : L1 3 L2 3
Hello Multiplier Value : L1 3 L2 3
LSP-Throttle Timer : L12 50
Cost : L1 30 L2 30
Ipv6 Cost : L1 10 L2 10
Priority : L1 20 L2 20
Retransmit Timer Value : L12 5
Bandwidth-Value : Low 1000000000 High 0
Static Bfd : NO
Dynamic Bfd : NO
Dynamic IPv6 Bfd : NO
Fast-Sense Rpr : NO
Suppress Base : NO
IPv6 Suppress Base : NO
Delay peer time : Configured 100s Left --
Run the display isis route command to view information about IS-IS routes. The command
output shows a route with the destination network segment of 12.1.1.0/24 and with the next-hop
address of 23.1.1.0/24.
<HUAWEI> display isis route
Route information for ISIS(1)

-----------------------------
ISIS(1) Level-2 Forwarding Table

--------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags

-------------------------------------------------------------------------------
12.1.1.0/24 40 NULL Pos1/0/2 23.1.1.1 A/-/-/-
23.1.1.0/24 10 NULL Pos1/0/2 Direct D/-/L/-
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set

7.3 Establishing or Maintaining IS-IS Neighbor

Relationships or Adjacencies
This section describes how to configure the parameters that affect the IS-IS neighbor
relationship.

Before configuring the parameters that affect the IS-IS neighbor relationship, familiarize
yourself with the usage scenario, complete the pre-configuration tasks, and obtain the required
data. This can help you complete the configuration task quickly and accurately.
This section describes how to establish or maintain the IS-IS neighbor relationship, covering:
l Adjusting timers of various IS-IS packets, including Hello packets, CSNPs, and LSPs
l Adjusting parameters of LSPs
Before establishing or maintaining IS-IS neighbor relationships or adjacencies, complete the
following tasks:
l Configuring IP addresses of interfaces to make neighboring nodes reachable

l 7.2 Configuring Basic IPv4 IS-IS Functions
Data Preparation
To establish or maintain IS-IS neighbor relationships or adjacencies, you need the following
data.
No. Data
1 Parameters of IS-IS timers
2 LSP parameters
7.3.2 Configuring IS-IS Timers for Packets

This part describes how to set the intervals for sending Hello packets, Complete Sequence
Number PDUs (CSNPs), and Link State PDUs (LSPs).
Context
Perform the following steps on the router that runs IS-IS.

Procedure
l Configuring the Interval for Sending Hello Packets
1. Run:
system-view

2. Run:

3. Run:
isis timer hello hello-interval [ level-1 | level-2 ]
The interval for sending the Hello packets is set on an 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 is only one type of Hello
packets. Therefore, neither level-1 nor level-2 is required.
NOTE
Parameters level-1 and level-2 are configured only on a broadcast interface.

l Configuring the Invalid Number of Hello Packets
1. Run:
system-view

2. Run:

3. Run:
isis timer holding-multiplier number [ level-1 | level-2 ]
The invalid number of Hello packets is set.
If no level is specified, both the Level-1 timer and Level-2 timer are configured.
NOTE
level-1 and level-2 can be found only on the broadcast interface.
IS-IS maintains neighbor relationships with neighbors through Hello packets. If the local
router does not receive any Hello packet from a neighbor within holding time, the local
router declares that the neighbor is invalid.
In IS-IS, the period during which the local router and its neighbor keep the neighbor
relationship is determined by the invalid number of Hello packets and the interval for
sending Hello packets.
l Configuring the Interval for Sending CSNPs
1. Run:
system-view


2. Run:

3. Run:
isis timer csnp csnp-interval [ level-1 | level-2 ]
The interval for sending CSNPs is set.
CSNPs are transmitted by the Designated IS (DIS) to synchronize an LSDB in a broadcast

network. If the level is not specified, the timer of the current level is configured.
l Configuring the Interval for Retransmitting LSPs
1. Run:
system-view

2. Run:

3. Run:
isis timer lsp-retransmit retransmit-interval
The interval for retransmitting LSPs on a P2P link is set.
On a P2P link, if the local router does not receive the response within a period of time after
it sends an LSP, it considers that the LSP is lost or dropped. To ensure the reliable
transmission, the local router retransmits the LSP according to the retransmit-interval. By
default, the interval for retransmitting the LSP packet on the P2P link is 5 seconds.
The LSPs sent on a broadcast link do not need any response.

l Configuring the Minimum Interval for Sending LSPs
1. Run:
system-view

2. Run:

3. Run:
isis timer lsp-throttle throttle-interval [ count count ]
The minimum interval for sending LSPs is set.
count: specifies the maximum number of LSP packets to be sent within the period
specified by throttle-interval. The value ranges from 1 to 1000.
You can set the minimum interval for sending LSPs on an IS-IS interface, that is, the delay
between two consecutive LSPs. The value is also the interval for sending fragments of a
CSNP.
----End

7.3.3 Configuring LSP Parameters

By configuring the LSP generation timer, you can adjust the time that an IS-IS network generates
LSPs. Setting the size of the LSP to be generated or received by IS-IS can affect the transmission
of LSPs.
Context
Procedure
l Configure the interval for refreshing LSPs
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-refresh refresh-time
The LSP refreshment period is set.
To synchronize all the LSPs in an area, the routers in the area periodically send all the
current LSPs.
By default, the LSP refreshment period is 900 seconds, and the maximum lifetime of an
LSP is 1200 seconds. When performing configurations, ensure that the LSP refresh interval
is 300 seconds shorter than the maximum LSP Keepalive time. In this way, new LSPs can
reach all routers in an area before existing LSPs expire.
NOTE
It is recommended to adjust the difference between the LSP refresh period and the maximum
Keepalive time of the LSP depending on the network scale.
l Configure the max lifetime of an LSP
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-max-age age-time
The lifetime of an LSP is set.
When a router generates an LSP, it sets the max lifetime for the LSP. After the LSP is
received by other routers, its lifetime decreases as time passes. If a router does not receive

any updated LSP and the lifetime of this LSP decreases to 0, the lifetime of the LSP lasts
60s. If a new LSP is still not received, this LSP is deleted from the LSDB.
l Configure the intelligent timer used to generate LSPs
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
timer lsp-generation max-interval [ init-interval [ incr-interval ] ]
[ level-1 | level-2 ]
The intelligent timer used to generate LSPs is set.

If no level is configured, both Level-1 and Level-2 are configured.
The initial delay for generating the same LSPs (or LSP fragments) is init-interval. The delay
for generating the same LSPs (or LSP fragments) secondly is incr-interval. When the routes
change each time, the delay for generating the same LSPs (or LSP fragments) is twice as
the previous value until the delay is up to max-interval. After the delay reaches max-
interval for three times or reset the IS-IS process, the interval is reduced to init-interval.
When incr-interval is not used and generating the same LSPs (or LSP fragments) for the
first time, init-interval is used as the initial delay. Then, the delay for generating the same
LSPs (or LSP fragments) is max-interval. After the delay reaches max-interval for three
times or the IS-IS process is reset, the interval is reduced to init-interval.
When only max-interval is used, the intelligent timer changes into a normal one-short timer.
l Configure the size of an LSP
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
lsp-length originate max-size
The size of an LSP generated by the system is set.

4. Run:
lsp-length receive max-size
The size of a received LSP is set.

NOTE
When using max-size, ensure that the value of the max-size of the generated LSP packet (or the
forwarded LSP packet) must be smaller than or equal to that of the received LSP packet.
The value of max-size set by using the lsp-length command must meet the following
conditions.

– The MTU value of an Ethernet interface must be greater than or equal to the sum of
max-size and 3.
– The MTU value of a P2P interface must be greater than or equal to the value of max-
size.
l Add an interface to a mesh group
1. Run:
system-view

2. Run:
The VLANIF interface view is displayed.

3. Run:
isis mesh-group { mesh-group-number | mesh-blocked }
The interface is added to a mesh group.
On the Non Broadcast Multiple Access (NBMA) network, after receiving an LSP, the
interface of a router floods the LSP to the other interfaces. In a network with higher
connectivity and multiple P2P links, however, the flooding method causes repeated LSP
flooding and wastes bandwidth.
To avoid the preceding problem, you can configure several interfaces to form a mesh group.
The router in the mesh group does not flood the LSP received from an interface of the group
to the other interfaces of the group, but floods it to interfaces of other groups or interfaces
that do not belong to any 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.
NOTE
In an ATM or FR network, IS-IS routers are connected through Virtual Circuits (VCs), and the
interface here is the logical P2P sub-interface.
l Configure LSP fragments extension
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
lsp-fragments-extend [ [ level-1 | level-2 | level-1-2 ] | [ mode-1 |
mode-2 ] ] *
LSP fragments extension is enabled in an IS-IS process.

4. Run:
virtual-system virtual-system-id

A virtual system is configured.

To configure a router to generate extended LSP fragments, you must configure at least one
virtual system. The ID of the virtual system must be unique in the domain.
An IS-IS process can be configured with up to 50 virtual system IDs.
If neither the mode nor the level is specified when LSP fragments extension is configured,
mode-1 and Level-1-2 are used by default.
----End

After configuring parameters that affect the IS-IS neighbor relationship, you can check
information about the IS-IS interface and statistics about the IS-IS process.
Prerequisites
Establishing or Maintaining IS-IS Neighbor Relationships or Adjacencies has been configured.
Procedure
l Run display isis interface [ [ verbose | traffic-eng ] * | tunnel ] [ process-id | vpn-
instance vpn-instance-name ] command to check information about the interface enabled
with IS-IS.
l Check the statistics of the IS-IS process:
– display isis statistics [ ipv6 ] [ topology topology-name | updated-lsp [ history ] ]
[ level-1 | level-2 | level-1-2 ] [ process-id | vpn-instance vpn-instance-name ]
– display isis statistics packet [ interface interface-type interface-number ]
– display isis process-id statistics [ level-1 | level-2 | level-1-2 | packet ]
----End
Example
On GE 1/0/0, set the interval for sending Hello packets to 15, the invalid number of Hello packets
to 10, the interval for sending Level-1 CSNPs to 123, and the minimum interval for sending
LSPs to 159. Run the display isis interface verbose command. The display is as follows:
---------------------------------
GE 1/0/0 001 Up Down 1497 L1/L2 No/No
SNPA Address : 00e0-095b-4201
Cost : L1 10 L2 10
Ipv6 Cost : L1 10 L2 10

Static Bfd : NO
Dynamic Bfd : NO
Fast-Sense Rpr : NO


Before configuring IPv4 IS-IS route selection, familiarize yourself with the usage scenario,
After basic IPv4 IS-IS functions are configured, IS-IS routes will be generated, enabling
communication between different nodes on a network.
If multiple routes are available, a route discovered by IS-IS may not the optimal route. This does
not meet network planning requirements nor facilitates traffic management. Therefore, configure
IPv4 IS-IS route selection to implement refined control over route selection.
To implement refined control over IPv4 IS-IS route selection, perform the following operations:
l Configuring the IPv4 IS-IS Interfaces.
NOTE
Changing the IS-IS cost for an interface can achieve the function of controlling route selection, but
requires routes on the interface to be recalculated and reconverged when a network topology changes,
especially on a large-scale network. In addition, the configuration result may not meet your
expectation.
Therefore, the configuration of changing IS-IS costs has best to be finished when configuring basic
IS-IS functions.
l Configure IPv4 IS-IS route leaking.
l Configure principles for selecting equal-cost IPv4 IS-IS routes.
l Filter IPv4 IS-IS routes.
l Configure an overload bit for an IPv4 IS-IS device.
l Configuring IS-IS to Generate IPv4 Default Routes
l Configuring an IPv4 IS-IS Interface to Automatically Adjust the Link Cost
Before configuring IPv4 IS-IS route selection, complete the following tasks:
the network layer
l Configuring Basic IPv4 IS-IS Functions

Data Preparation
To configure IPv4 IS-IS route selection, you need the following data.
No. Data
1 ACL for filtering routes, IP prefix list, or routing policy
2 Maximum number of load-balancing equal-cost IS-IS routes
3 Preference of the next hop
4 Time when an IS-IS device enters the overload state
7.4.2 Configuring IPv4 IS-IS Route Leaking

Configuring IS-IS route leaking enables you to optimize IS-IS route selection on a two-level-
area network.
Context
If multiple Level-1-2 devices in a Level-1 area are connected to devices in the Level-2 area, a
Level-1 LSP sent by each Level-1-2 device carries an ATT flag bit of 1. This Level-1 area will
have multiple routes to the Level-2 area and to other Level-1 areas.
By default, routes in a Level-1 area can be leaked into the Level-2 area so that Level-1-2 and
Level-2 devices can learn about the topology of the entire network. Devices in a Level-1 area
are unaware of the entire network topology because they only maintain LSDBs in the local
Level-1 area. Therefore, a device in a Level-1 area can forward traffic to a Level-2 device only
through the nearest Level-1-2 device. The route used may not be the optimal route to the
destination.
To enable a device in a Level-1 area to select the optimal route, configure IPv4 IS-IS route
leaking so that specified routes in the Level-2 area can be leaked into the local Level-1 area.
Routes of services deployed only in the local Level-1 area do not need to be leaked into the
Level-2 area. A policy can be configured to leak only desired routes into the Level-2 area.
Procedure
l Specify routes in the Level-2 area and other Level-1 areas that can be leaked into the local
Level-1 area.
1. Run:
system-view

2. Run:
isis [ process-id ]


a. Run import-route isis level-2 into level-1 [ tag tag | filter-policy { acl-
number | acl-name acl-name } ] *, routes in the Level-2 area and other Level-1
areas that meet the specified conditions are leaked into the local Level-1 area.
b. Run quit, return to the system view.
c. Run acl { [ number ] acl-number1 | name acl-name basic [ number acl-
number2 ] } [ match-order { auto | config } ], the basic ACL view is
displayed.
d. Run rule [ rule-id ] { deny | permit } [ fragment-type fragment-type-
name | source { source-ip-address source-wildcard | any } | time-range time-
name | vpn-instance vpn-instance-name ] *, a rule is configured for the basic
ACL.
– If the action specified in an ACL rule is permit, a route that matches the
rule will be received or advertised by the system.
– If the action specified in an ACL rule is deny, a route that matches the
rule will not be received or advertised by the system.
– If a route has not matched any ACL rules, the route will not be received
or advertised by the system.
– If an ACL does not contain any rules, all routes matching the route-
policy that references the ACL will not be received or advertised by the
system.
– If the ACL referenced by the route-policy does not exist, all routes
matching the route-policy will be received or advertised by the system.
– In the configuration order, the system first matches a route with a rule that
has a smaller number and then matches the route with a rule with a larger
number. Routes can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller number
and specify the action deny in this rule to filter out the unwanted routes.
Then, configure another rule with a larger number in the same ACL and
specify the action permit in this rule to receive or advertise the other
routes.
Route filtering using a whitelist: Configure a rule with a smaller number
and specify the action permit in this rule to permit the routes to be received
or advertised by the system. Then, configure another rule with a larger
number in the same ACL and specify the action deny in this rule to filter
out unwanted routes.
– Based on the named advanced ACL:
a. Run import-route isis level-2 into level-1 [ tag tag | filter-policy acl-
name acl-name ] *, routes in the Level-2 area and other Level-1 areas that
meet the specified conditions are leaked into the local Level-1 area.
c. Run acl name acl-name advance [ number acl-number2 ] [ match-order
{ auto | config } ], the basic ACL view is displayed.

d. Run rule [ rule-id ] { deny | permit } protocol [ source { source-ip-address

source-wildcard | any } | time-range time-name ] *, a rule is configured for
the basic ACL.
system.
routes.
– Based on the IP prefix: import-route isis level-2 into level-1 [ tag tag | filter-
policy ip-prefix ip-prefix-name ] *
– Based on the Route-Policy: import-route isis level-2 into level-1 [ tag tag | filter-
policy route-policy route-policy-name ] *
NOTE
The command is run on the Level-1-2 device that is connected to an external area.
By default, routes in the Level-2 area are not leaked into Level-1 areas. After this command is
run, only routes that meet the specified conditions can be leaked into Level-1 areas.
l Configure routes in Level-1 areas to leak into the Level-2 area.
1. Run:
system-view

2. Run:
isis [ process-id ]


a. Run import-route isis level-1 into level-2 [ tag tag | filter-policy { acl-
number | acl-name acl-name } ] *, routes that meet the specified conditions
in Level-1 areas are leaked into the Level-2 area.
displayed.
ACL.
system.
routes.
a. Run import-route isis level-1 into level-2 [ tag tag | filter-policy acl-
name acl-name ] *, routes that meet the specified conditions in Level-1 areas
are leaked into the Level-2 area.


the basic ACL.
system.
routes.
– Based on the IP prefix: import-route isis level-1 into level-2 [ tag tag | filter-
policy ip-prefix ip-prefix-name ] *
– Based on the Route-Policy: import-route isis level-1 into level-2 [ tag tag | filter-
policy route-policy route-policy-name ] *
NOTE
By default, all routes in a Level-1 area are leaked into the Level-2 area. After this command is
run, only routes that meet the specified conditions can be leaked into the Level-2 area.
----End
7.4.3 Configuring Principles for Using Equal-Cost IPv4 IS-IS

Routes
If multiple equal-cost IS-IS routes are available on a network, configure the equal-cost IS-IS
routes to work in load-balancing mode to increase the bandwidth usage of each link, or configure
preference values for the equal-cost IS-IS routes to facilitate traffic management.

Context
If there are redundant IS-IS links, multiple routes may have an equal cost. Choose either of the
following methods to use these equal-cost IS-IS routes:
l Configure load balancing for equal-cost IS-IS routes so that traffic will be evenly balanced
among these links.
This mechanism increases the link bandwidth usage and prevents network congestion
caused by link overload. However, this mechanism may make traffic management more
difficult because traffic will be randomly forwarded.
l Configure preference values for equal-cost IS-IS routes so that only the route with the
highest preference will be used and the others function as backups.
This configuration facilitates traffic management and improves the network reliability,
without the need to change original configurations.
Procedure
l Configure equal-cost IS-IS routes to work in load-balancing mode.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The maximum number of load-balancing equal-cost IS-IS routes is set.
NOTE
balancing command, valid routes are selected for load balancing based on the following
criteria:
about route preference configuration, see Configure preference values for equal-cost IS-
IS routes.
l Configure preference values for equal-cost IS-IS routes.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
A preference value is configured for an equal-cost IS-IS route.
NOTE
A larger value of the value parameter indicates a higher preference. The default value of the
preference is 255.
----End
7.4.4 Filtering IPv4 IS-IS Routes

If some IS-IS routes are not preferred, configure conditions to filter IS-IS routes. Only IS-IS
routes meeting the specified conditions can be added to an 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 add 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 ]

1. Run filter-policy { acl-number | acl-name acl-name } import, conditions for filtering
IS-IS routes are configured.

by the system.
1. Run filter-policy acl-name acl-name import, conditions for filtering IS-IS routes are
configured.
by the system.

l Based on the IP prefix: filter-policy ip-prefix ip-prefix-name import
l Based on the Route-Policy: filter-policy route-policy route-policy-name import
----End
7.4.5 Configuring an Overload Bit for an IPv4 IS-IS Device

If an IS-IS device needs to be temporarily isolated, configure the IS-IS device to enter the
overload state to prevent other devices from forwarding traffic to this IS-IS device and prevent
blackhole routes.
Context
If an IS (for example, an IS to be upgraded or maintained) needs to be temporarily isolated,
configure the IS to enter the overload state so that no device will forward traffic to this IS.
IS-IS routes converge more quickly than BGP routes. To prevent blackhole routes on a network
where both IS-IS and BGP are configured, set an overload bit to instruct an IS to enter the
overload state during its start or restart. After BGP convergence is complete, cancel the overload
bit.
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 is configured.
----End
7.4.6 Configuring IS-IS to Generate IPv4 Default Routes

This section describes how to configure Intermediate System to Intermediate System (IS-IS) to
generate default routes to control the advertising of IS-IS routing information.
Context
The destination address and mask of a default route are all 0s. If the destination address of a
packet does not match any entry in the routing table of a device, the device sends the packet

along the default route. If neither the default route nor the destination address of the packet exists
in the routing table, the device discards the packet and informs the source end that the destination
address or network is unreachable.
IS-IS can generate default routes using either of the following mode:
l Command-triggered default route generation mode
You can run the default-route-advertise command on a device so that the device adds a
default route to the LSP before sending the LSP to a neighbor. Therefore, the neighbor can
learn this default route.
l ATT bit 1-triggered default route generation mode
IS-IS defines that a Level-1-2 router sets the ATT bit to 1 in the LSP to be advertised to a
Level-1 area if the Level-1-2 router can reach more Level-1 areas through the Level-2 area
than through the Level-1 area. After a Level-1 router in the Level-1 area receives the LSP,
it generates a default route destined for the Level-1-2 router. Based on the network
requirements, you can configure whether the Level-1-2 router sets the ATT bit carried in
the LSP and whether a Level-1 router generates a default route after it receives the LSP
carrying ATT bit 1.
NOTE
This mode applies only to Level-1 routers.
Procedure
l Configure command-triggered default route generation mode.
1. Run:
system-view

2. Run:
isis [ process-id ]

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 generate default routes.

l Configure ATT bit 1-triggered default route generation mode.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run the following command as required:
– To set the ATT bit in the LSPs sent by the Level-1-2 router, 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 router 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 router does not generate a default
route, which reduces the size of a routing table.
– To disable the Level-1 router from generating default routes even though it receives
the LSPs carrying ATT bit 1, run the attached-bit avoid-learning command.
----End
7.4.7 Configuring an IPv4 IS-IS Interface to Automatically Adjust

the Link Cost
Configuring an IS-IS interface to automatically adjust the link cost based on link quality
Context
A bit error refers to the deviation between a bit that is sent and the bit that is received. The bit
error rate (BER) refers to the number of bit errors divided by the total number of bits transferred
during a studied time interval. During data transmission, a high BER will degrade or even
interrupt services in extreme cases.
To prevent this problem, configure IS-IS interfaces to automatically adjust link costs based on
link quality, so that unreliable links are not used by the optimal routes.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
isis enable [ process-id ]
IS-IS is enabled on the interface.

Step 4 Run:
link-quality low bit-error-threshold error-ratio trigger-coefficient trigger-power
resume-ratio recovery-coefficient recovery-power
The upper and lower thresholds for triggering link quality changes are set on the IS-IS interface.
After you run this command, if the BER of the IS-IS interface reaches or exceeds the upper
threshold, the link quality changes from good to low; if the BER of the IS-IS interface reaches
or falls below the lower threshold, the link quality changes from low to good.
Step 5 Run:
isis link-quality low incr-cost { cost | max-reachable }

The IS-IS interface is configured to automatically adjust the link cost based on link quality.
By default, an IS-IS interface does not have this function.
NOTE
The cost parameter specifies the link cost adjustment value. After this parameter is specified:
l If the link quality changes from good to low, the link cost equals the original link cost plus the adjustment
value. If the new link cost exceeds the maximum link cost allowed, the maximum link cost allowed applies:
l The maximum link cost is 63, if the cost type is narrow, narrow-compatible, or compatible.
l The maximum link cost is 16777214, if the cost type is wide or wide-compatible.
l If the link quality changes from low to good, the orginal link cost applies.
----End

After configuring IPv4 IS-IS route selection, run the following commands to verify that the
configurations are correct.
Procedure
l Run the display isis route [ process-id | vpn-instance vpn-instance-name ] [ ipv4 ]
[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * [ | count ] command
to check IS-IS routing information.
l Run the display isis lsdb [ { level-1 | level-2 } | verbose | { local | lsp-id | is-name symbolic-
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check information
in the IS-IS LSDB.
----End
Example
On a Level-1 device, run the display isis route command to check IS-IS routing information.
If the Level-1-2 device is enabled to leak IS-IS routes in the Level-2 area to Level-1 areas, the
output of the display isis route command is similar to the following information. For example,
the route 192.168.1.0/24 in the Level-2 area is displayed, and Up/Down is U.

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

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

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL GE1/0/0 10.1.1.2 A/-/-/-
192.168.1.0/24 30 NULL GE1/0/0 10.1.1.2 A/-/-/U
10.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
20.1.1.0/24 20 NULL GE1/0/0 10.1.1.2 A/-/-/-
U-Up/Down Bit Set
On the Level-1-2 device, run the display isis lsdb verbose command to check whether the
Level-1-2 device has leaked the route 192.168.1.0/24 to Level-1 areas.

<HUAWEI> display isis lsdb verbose
Database information for ISIS(1)

--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL

-------------------------------------------------------------------------------
1111.1111.1111.00-00 0x00000004 0xb05f 962 68 0/0/0
SOURCE 1111.1111.1111.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 10.1.1.1
NBR ID 2222.2222.2222.01 COST: 10
IP-Internal 10.1.1.0 255.255.255.0 COST: 10
2222.2222.2222.00-00* 0x00000008 0x133c 1190 96 1/0/0

SOURCE 2222.2222.2222.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 10.1.1.2
INTF ADDR 20.1.1.1
NBR ID 2222.2222.2222.01 COST: 10
IP-Internal 10.1.1.0 255.255.255.0 COST: 10
IP-Internal 20.1.1.0 255.255.255.0 COST: 10
IP-Internal* 192.168.1.0 255.255.255.0 COST: 10
2222.2222.2222.01-00* 0x00000001 0xdcb2 980 55 0/0/0

SOURCE 2222.2222.2222.01
NLPID IPV4
NBR ID 2222.2222.2222.00 COST: 0
NBR ID 1111.1111.1111.00 COST: 0
Total LSP(s): 3
*(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended),
ATT-Attached, P-Partition, OL-Overload

-------------------------------------------------------------------------------
2222.2222.2222.00-00* 0x00000008 0x1d57 1017 84 0/0/0
SOURCE 2222.2222.2222.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 10.1.1.2
INTF ADDR 20.1.1.1
NBR ID 3333.3333.3333.00 COST: 10
IP-Internal 10.1.1.0 255.255.255.0 COST: 10
IP-Internal 20.1.1.0 255.255.255.0 COST: 10
3333.3333.3333.00-00 0x00000006 0x5c57 1029 84 0/0/0

SOURCE 3333.3333.3333.00
NLPID IPV4
AREA ADDR 20
INTF ADDR 20.1.1.2
INTF ADDR 192.168.1.1
NBR ID 2222.2222.2222.00 COST: 10
IP-Internal 20.1.1.0 255.255.255.0 COST: 10
IP-Internal 192.168.1.0 255.255.255.0 COST: 0
Run the display isis lsdb command to check whether an IS-IS device is in the overload state. If
an IS-IS device is in the overload state, the command output is similar to the following
information.

<HUAWEI> display isis lsdb

--------------------------------
ATTENTION :: System is overloaded

Manual overload set YES OverLoad on Startup NO
System Memory Low NO Memory Allocate Failure NO

-------------------------------------------------------------------------------
1111.1111.1111.00-00* 0x00000005 0xb258 1193 68 0/0/1
2222.2222.2222.00-00 0x0000016317 0xd2fd 1167 84 1/0/0
2222.2222.2222.01-00 0x00000001 0xdcb2 449 55 0/0/0
Total LSP(s): 3
Run the display isis route command to check IS-IS routing information. If equal-cost IS-IS
routes are configured to work in load-balancing mode, multiple next hops will be displayed in
the command output. For example, two next hops, 10.1.1.2 and 10.1.2.2, to the 172.17.1.0/24
network segment are displayed, and their route costs are both 30.
-----------------------------
--------------------------------
---------------------------------------------------------------------------
192.168.1.0/24 20 NULL Pos2/0/0 10.1.2.2 A/-/L/-
172.16.1.0/24 10 NULL GE3/0/0 Direct D/-/L/-
172.17.1.0/24 30 NULL Pos1/0/0 10.1.1.2 A/-/L/-
Pos2/0/0 10.1.2.2
192.168.0.0/24 20 NULL Pos1/0/0 10.1.1.2 A/-/L/-
U-Up/Down Bit Set

routing table.
Context
Route summarization is used to summarize routes with the same IP prefix into one route.
On a large-scale IS-IS network, route summarization can be configured to reduce the number
of IS-IS routes in a routing table. This summarization improves the usage of system resources
and facilitates route management.
If a link on an IP network segment that is summarized frequently alternates between Up and
Down states, IP network segments that are not summarized will not be affected, preventing route
flapping and improving the network stability.

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 an IS, the local routing table still contains all specific routes
before the summarization.
The routing tables on other ISs contain only the summary route, and the summary route is deleted only
after all its specific routes are deleted.
----End

After the route summarization function is configured, perform the following steps to check
whether the route summarization function has taken effect.
l Run the display isis route command to check summary routes in the IS-IS routing table.
l Run the display ip routing-table [ verbose ] command to check summary routes in the IP
routing table.
7.6 Configuring IPv4 IS-IS to Interact with Other Routing

Protocols

Before configuring IPv4 IS-IS to interact with other routing protocols, familiarize yourself with
the usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
If other routing protocols are configured on an IS-IS network, the following issues need to be
considered:
l Preference of IS-IS routes

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. For example, if both OSPF and IS-IS are configured, the route discovered by
OSPF is used because OSPF enjoys a higher preference than IS-IS by default.
Therefore, if you want the route discovered by IS-IS to be used, configure IS-IS to have
the highest preference.
l Communication between an IS-IS area and other areas
If other routing protocols are configured on an IS-IS network, you need to configure IS-IS
to interact with those routing protocols so that IS-IS areas can communicate with non-IS-
IS areas.
NOTE
The LSDBs of different IS-IS processes on a device are independent of each other. Therefore, each
IS-IS process on the device considers routes of the other IS-IS processes as external routes.
To ensure successful traffic forwarding, configure IS-IS to interact with other routing
protocols on a device where external routes are configured, for example, a Level-1-2 IS-
IS router. Available method is configuring IS-IS to import external routes. This mode
enables all devices in IS-IS areas to learn external routes, implementing refined control
over traffic forwarding.
To ensure successful forwarding of traffic destined for IS-IS areas, you must also enable
the other routing protocols to interact with IS-IS.
Before configuring IPv4 IS-IS to interact with other routing protocols, complete the following
tasks:
l Configuring the link layer protocol on interfaces

the network layer
l Configuring basic functions of other routing protocols
Data Preparation
To configure the IPv4 IS-IS route convergence speed, you need the following data.
No. Data
1 ACL for filtering routes, IP prefix list, or routing policy
2 Preference value of IS-IS
7.6.2 Configuring a Preference Value for IPv4 IS-IS

If multiple routes to the same destination are discovered by different routing protocols,
configuring the highest preference value for IS-IS allows a route discovered by IS-IS to be
selected preferentially.

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.
For example, if both OSPF and IS-IS are configured on a network, the route discovered by OSPF
is used because OSPF has a higher preference than IS-IS by default.
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
l Configure the IS-IS preference value.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
preference preference
The IS-IS preference value is configured.
NOTE
A smaller preference value indicates a higher preference.

The default IS-IS preference value is 15.
l Configure preference values for specified IS-IS routes.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
preference preference route-policy route-policy-name
The preference values are configured for the specified IS-IS routes.
NOTE
preference takes effect only for IS-IS routes that match the specified routing policy.
----End
7.6.3 Configuring IPv4 IS-IS to Import External Routes

If devices in an IS-IS routing domain need to learn external routes, configure IS-IS on a Level-1-2
device of this routing domain to import external routes.

Context
If IS-IS is configured on a Level-1-2 device to advertise a default route, all traffic in IS-IS routing
domains will be forwarded by this Level-1-2 device. This will burden this Level-1-2 device
because no external route can be learned on the devices in the IS-IS routing domains.
If multiple Level-1-2 devices are deployed, 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 domains
must learn all or some external routes.
Routing policies can be configured to import or advertise external routes that meet specified
conditions to the IS-IS routing domains.
Procedure
l Configure IS-IS to import external routes.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Configuring IS-IS to Import External Routes
– If you want to set the cost for the imported route, you can run the import-route
{ direct | static | unr | { ospf | rip | isis } [ process-id ] | 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 import the external routes.
– If you want to keep the original cost for the imported route, you can run the import-
route { { ospf | rip | isis } [ process-id ] | bgp [ permit-ibgp ] | direct } inherit-
cost [ tag tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ]
* command to import the external routes. When configuring IS-IS to retain the
original cost value of the imported route, the source routes cannot be static.
NOTE
IS-IS will advertise all imported external routes to an IS-IS routing domain by default.
If only some imported external routes need to be advertised, run the filter-policy export
command to set a filtering policy.
If an IS-IS device has a small routing table capacity, run the import-route limit limit-
number [ threshold-alarm upper-limit upper-limit-value lower-limit lower-limit-value ]
{ level-1 | level-2 | level-1-2 } command to set the maximum number of external routes that
can be imported into an IS-IS routing domain.
l Configure IS-IS to advertise some external routes to an IS-IS routing domain.
1. Run:
system-view

2. Run:
isis [ process-id ]


a. Run filter-policy { acl-number | acl-name acl-name } import, IS-IS is
configured to advertise specified external routes to the IS-IS routing domain.
displayed.
ACL.
system.
routes.
a. Run filter-policy acl-name acl-name import, IS-IS is configured to advertise
specified external routes to the IS-IS routing domain.


the basic ACL.
system.
routes.
– Based on the IP prefix: filter-policy ip-prefix ip-prefix-name import
– Based on the Route-Policy: filter-policy route-policy route-policy-name import
NOTE
After this command is run, only external routes that meet the specified conditions can be
advertised to the IS-IS routing domain.
----End

After IS-IS is enabled to import routes from other protocols, run the following commands to
verify that the configurations are correct.
Procedure
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check IS-IS LSDB
information.


[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * command to check IS-
IS routing information.
l Run the display ip routing-table ip-prefix ip-prefix-name [ verbose ] command to check
the IP routing table.
----End
Example
Run the display isis lsdb verbose command on the device that generates a default route. The
command output shows that IS-IS has advertised a default route.

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

-------------------------------------------------------------------------------
1111.1111.1111.00-00 0x00000004 0xb25b 1123 68 0/0/0
SOURCE 1111.1111.1111.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 10.1.1.1
NBR ID 2222.2222.2222.01 COST: 10
IP-Internal 10.1.1.0 255.255.255.0 COST: 10
2222.2222.2222.00-00* 0x00000007 0xd63a 1165 95 0/0/0

SOURCE 2222.2222.2222.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 10.1.1.2
INTF ADDR 20.1.1.1
NBR ID 2222.2222.2222.01 COST: 10
NBR ID 3333.3333.3333.00 COST: 10
IP-Internal 10.1.1.0 255.255.255.0 COST: 10
IP-Internal 20.1.1.0 255.255.255.0 COST: 10
2222.2222.2222.00-01* 0x00000001 0xc25d 1189 41 0/0/0

SOURCE 2222.2222.2222.00
IP-Internal 0.0.0.0 0.0.0.0 COST: 0
2222.2222.2222.01-00* 0x00000001 0xdcb2 1141 55 0/0/0

SOURCE 2222.2222.2222.01
NLPID IPV4
NBR ID 2222.2222.2222.00 COST: 0
NBR ID 1111.1111.1111.00 COST: 0
3333.3333.3333.00-00 0x00000004 0xac80 1164 68 0/0/0

SOURCE 3333.3333.3333.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 20.1.1.2
NBR ID 2222.2222.2222.00 COST: 10
IP-Internal 20.1.1.0 255.255.255.0 COST: 10
Total LSP(s): 5

Run the display isis route command on the device that receives the default route. The command
output shows that the default route with a next-hop address of 20.1.1.2 has been imported into
the Level-2 IS-IS routing table.

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

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

-------------------------------------------------------------------------------
10.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
U-Up/Down Bit Set

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

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL Pos1/0/1 20.1.1.2 A/-/-/-
10.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
U-Up/Down Bit Set
Run the display isis route command to view the IS-IS routing table. The command output shows
that the direct route 192.168.1.0/24 and OSPF route 14.1.1.1/32 have been imported into the
Level-2 IS-IS routing table.

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

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

-------------------------------------------------------------------------------
10.1.1.0/24 20 NULL Pos1/0/2 20.1.1.1 A/-/-/-
U-Up/Down Bit Set
ISIS(1) Level-2 Redistribute Table

----------------------------------
Type IPV4 Destination IntCost ExtCost Tag

-------------------------------------------------------------------------------
D 192.168.1.0/24 0 20
O 14.1.1.1/32 0 20
Type: D-Direct, I-ISIS, S-Static, O-OSPF, B-BGP, R-RIP
Run the display ip routing-table command to view the IP routing table. The command output
shows that the value of Preference of IPv4 IS-IS has been changed from its default value 15 to
20.

<HUAWEI> display ip routing-table

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

10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
22.2.2.0/24 ISIS-L2 20 10 D 10.1.1.2 Pos1/0/0


Before configuring the IPv4 IS-IS route convergence speed, familiarize yourself with the usage
scenario, complete the pre-configuration tasks, and obtain the data required for the configuration.
The procedure for implementing IS-IS is as follows:
l Establishment of neighboring relationships: establishes neighboring relationships by
exchanging Hello packets between two devices.
l LSP flooding: implements LSDB synchronization between devices in the same area.
l SPF calculation: uses the SPF algorithm to calculate IS-IS routes, and delivers the IS-IS
routes to the routing table.
To accelerate the IS-IS route convergence speed, configure the following parameters:
l Interval for detecting IS-IS neighboring device failures
l Flooding parameters of CSNPs and LSPs
l Interval for SPF calculation
You can also configure convergence priorities for IPv4 IS-IS routes so that key routes can be
converged by preference when a network topology changes. This minimizes adverse impacts on
key services.
Before configuring the IPv4 IS-IS route convergence speed, complete the following tasks:

the network layer

Data Preparation
No. Data
1 Interval at which Hello packets are sent and the holding time of neighboring
devices
2 Flooding time of CSNPs and LSPs
3 Interval for SPF calculation
4 Route convergence priority
7.7.2 Configuring the Interval for Detecting IS-IS Neighboring

Device Failures
To minimize the effects caused by neighboring device failures on an IS-IS network, accelerate
the speed of detecting IS-IS neighboring device failures.
Context
Connection status between an IS-IS device and its neighboring devices can be monitored by
exchanging Hello packets at intervals. An IS-IS neighboring device is considered Down if the
IS-IS device does not receive any Hello packets from the neighboring device within the specified
period (called the holding time). A failure in an IS-IS neighboring device will trigger LSP
flooding and SPF calculation, after which IS-IS routes are reconverged.
To speed up fault detection, use the following methods to accelerate the speed of detecting IS-
IS neighboring device failures:
l Shorten the interval at which Hello packets are sent.
l Shorten the holding time of neighboring devices.
l Configuring Dynamic IPv4 BFD for IS-IS.
NOTE
Configuring IPv4 BFD for IS-IS is recommended because this method provides a faster fault detection
speed than the other two methods.
Procedure
l Set an interval at which Hello packets are sent.
1. Run:
system-view

2. Run:

3. Run:
The interval at which Hello packets are sent is set.
NOTE
A broadcast link can transmit both Level-1 and Level-2 Hello packets. You can set different
sending intervals for these two types of Hello packets. By default, both Level-1 and Level-2
Hello packets are sent.
A P2P link can transmit only one type of Hello packets. Therefore, there is no need to specify
the level-1 or level-2 parameter if a P2P link is used.
l Set the holding multiplier for neighboring devices.
1. Run:
system-view

2. Run:

3. Run:
The holding multiplier of neighboring devices is set.
NOTE
----End
7.7.3 Setting Flooding Parameters of SNPs and LSPs

To speed up LSDB synchronization between devices, set flooding parameters of SNPs and LSPs
to proper values.
Context
SNPs consist of CSNPs and PSNPs. CSNPs carry summaries of all LSPs in LSDBs, ensuring
LSDB synchronization between neighboring routers. SNPs are processed differently on
broadcast links and P2P links.
l On a broadcast link, CSNPs are periodically sent by a DIS device. If a router detects that
its LSDB is not synchronized with that on its neighboring router, the router will send PSNPs
to apply for missing LSPs.
l On a P2P link, CSNPs are sent only during initial establishment of neighboring
relationships. If a request is acknowledged, a neighboring router will send a PSNP in
response to a CSNP. If a router detects that its LSDB is not synchronized with that on its
neighboring router, the router will also send PSNPs to apply for missing LSPs.

To speed up LSDB synchronization, modify the following parameters of SNPs and LSPs on the
NE80E/40E:
l Interval at which CSNPs are sent
l Intelligent timer controlling LSP generation
l Maximum length of LSPs
l Refresh interval of LSPs
l Maximum lifetime of LSPs
l Minimum interval at which LSPs are sent
l LSP fast flooding
l Interval at which LSPs are retransmitted over a P2P link
Procedure
l Set an interval at which CSNPs are sent.
1. Run:
system-view

2. Run:

3. Run:
The interval at which CSNPs are sent is set on the specified interface.
NOTE
Configure Level-1 and Level-2 only when a broadcast interface is specified.

l Configure the intelligent timer controlling LSP generation.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The intelligent timer controlling LSP generation is configured.

If a level is not specified, both level-1 and level-2 are used by default.
The delay in generating an LSP or an LSP fragment for the first time is determined
by init-interval; the delay in generating an LSP or an LSP fragment for the second
time is determined by incr-interval. From the third time on, the delay in generating
an LSP 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.
If incr-interval is not specified, the delay in generating an LSP or LSP fragment for
the first time is determined by init-interval. From the second time on, the delay in
generating an LSP 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.
When only max-interval is specified, the intelligent timer functions as an ordinary

one-time triggering timer.
l Set the maximum length for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The maximum length is set for each LSP to be generated.

4. Run:
The maximum length is set for each LSP to be received.
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 in the lsp-length command must meet the following conditions.
– The MTU of an Ethernet interface must be greater than or equal to the sum of the
value of max-size and 3.
– The MTU of a P2P interface must be greater than or equal to the value of max-
size.
l Set the refresh interval for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
A refresh interval is set for LSPs.

To synchronize all LSPs in the areas, IS-IS regularly transmits all the current LSPs to
neighbors.
By default, the LSP refresh interval is 900s, and the maximum lifetime of an LSP is
1200s. Ensure that the LSP refresh interval is more than 300s shorter than the
maximum LSP lifetime. This allows new LSPs to reach all routers in an area before
existing LSPs expire.
NOTE
The larger a network, the greater the deviation between the LSP refresh interval and the
maximum LSP lifetime.
l Set the maximum lifetime for LSPs.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The maximum lifetime is set for LSPs.
When a router generates the system LSP, it fills in the maximum lifetime for this LSP.
After this LSP is received by other routers, the lifetime of the LSP is reduced gradually.
If the router does not receive any more update LSPs and the lifetime of the LSP is
reduced to 0, the LSP will be deleted from the LSDB 60s later if no more updated
LSPs are received.
l Set the minimum interval at which LSPs are sent.
1. Run:
system-view

2. Run:

3. Run:
The minimum interval at which LSPs are sent is set.
The count parameter specifies the maximum number of LSPs that can be sent within
the interval specified by throttle-interval. The value of count is an integer ranging
from 1 to 1000.
l Enable LSP fast flooding.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
flash-flood [ lsp-count | max-timer-interval interval | [ level-1 |
level-2 ] ] *
The LSP fast flooding is enabled.
The flash-flood command speeds up LSP flooding by flooding newly generated or

received LSPs immediately without waiting for the expiry of the timer set using the
isis timer lsp-throttle command.
You can specify lsp-count to flood a certain number of LSPs and specify interval to
flood LSPs at a certain interval. If the number of LSPs to be flooded exceeds the value
of lsp-count, a maximum of lsp-count number of LSPs are flooded each time in time
sequence at an interval specified by interval until all the LSPs are flooded.
When LSP fast flooding is enabled, Level-1 LSPs and Level-2 LSPs are fast flooded
by default if no level is specified.
l Set an interval at which LSPs are retransmitted over a P2P link.
1. Run:
system-view

2. Run:

3. (Optional) Run:
Emulate a broadcast interface to the P2P interface.

4. Run:
The interval at which LSPs are retransmitted over a P2P link is set.
----End
7.7.4 Setting the SPF Calculation Interval

To improve the fault location efficiency on an IS-IS network and prevent SPF calculation from
consuming excessive system resources, set the SPF calculation interval to a proper value.
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.
The intelligent timer changes as follows:

l The delay for the first SPF calculation is determined by init-interval; the delay for the second
SPF calculation is determined by incr-interval. From the third time on, the delay in SPF
calculation increases twice every time until the delay reaches the value specified by max-
interval. After the delay remains at the value specified by max-interval for three times or the
IS-IS process is restarted, the delay decreases to the value specified by init-interval.
l If incr-interval is not specified, the delay in SPF calculation for the first time is determined
by init-interval. From the second time on, the delay in SPF calculation is determined by max-
l When only max-interval is specified, the intelligent timer functions as an ordinary one-time
triggering timer.

spf-slice-size duration-time
The maximum duration for SPF calculation is configured.
----End
7.7.5 Configuring Convergence Priorities for IPv4 IS-IS Routes

If some IS-IS routes need to be converged by preference to minimize adverse impacts on services,
configure those routes to have the highest convergence priority.
Context
By default, the convergence priority of 32-bit host routes is medium, and the convergence
priority of the other IS-IS routes is low.
The NE80E/40E allows you to configure the highest convergence priority for specific IS-IS
routes so that those IS-IS routes will be converged first when a network topology changes.
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.
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.
l If the route level is not specified, the configuration of the prefix-priority command takes
effect for both Level-1 and Level-2 IS-IS routes.
NOTE
The prefix-priority command is only applicable to the public network.

After the prefix-priority command is run, the convergence priority of 32-bit host routes is low, and the
convergence priorities of the other routes are determined as specified in the prefix-priority command.

quit

ip route prefix-priority-scheduler critical-weight high-weight medium-weight low-
weight
The preference-based scheduling ratio of IPv4 routes is configured.
By default, the preference-based scheduling ratio of IPv4 routes is 8:4:2:1.
----End

After the parameters specifying the IPv4 IS-IS route convergence speed are set, run the following
commands to verify that the configurations are correct.
Procedure
l Run the display isis interface [ [ verbose | traffic-eng ] * | tunnel ] [ process-id | vpn-
instance vpn-instance-name ] command to check IS-IS packet information.


[ topology topology-name ] [ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-
length ] ] * command to check the preference of IS-IS routes.
----End
Example
Run the display isis interface verbose command. The command output shows that GE 6/0/0
sends Hello packets at an interval of 15 s, the holding multiplier of neighboring devices is 10,
the sending interval for Level-1 CSNPs is 123 s, and the minimum sending interval for LSPs is
159 s.
---------------------------------
GE6/0/0 001 Up Down 1497 L1/L2 No/No
Cost : L1 10 L2 10
Ipv6 Cost : L1 10 L2 10
Static Bfd : NO
Dynamic Bfd : NO
Fast-Sense Rpr : NO
Run the display isis route verbose command. The command output shows that the convergence
priority of the route 10.10.10.0/24 imported by IS-IS is Critical.
<HUAWEI> display isis route verbose

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

--------------------------------
IPV4 Dest : 10.10.10.0/24 Int. Cost : 20 Ext. Cost : NULL

Admin Tag : - Src Count : 2 Flags : A/-/-/-
Priority : Critical
NextHop : Interface : ExitIndex :
1.1.1.2 Pos1/0/0 0x80000001

Admin Tag : - Src Count : 2 Flags : D/-/L/-
Priority : Medium
Direct Pos1/0/0 0x00000000

Admin Tag : - Src Count : 2 Flags : A/-/-/-
Priority : Low

1.1.1.2 Pos1/0/0 0x80000001
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut

U-Up/Down Bit Set
7.8 Configuring Static BFD for IPv4 IS-IS

BFD can provide link failure detection featuring light load and high speed (at the millisecond
level). Static BFD can be configured to monitor IS-IS links.
Context
In a static BFD session scenario, you need to configure single-hop BFD parameters, such as
local and remote discriminators and then configure the device to send BFD session setup
requests.
A static BFD session can only be established and released manually. A configuration error will
lead to a BFD failure. For example, if a local or remote discriminator is incorrectly configured,
a BFD session will not work properly.
Before configuring static BFD for IPv4 IS-IS, complete the following tasks:
l Configuring Basic IPv4 IS-IS Functions.
No. Data
Procedure
l Enable BFD globally.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

l Configure a single-hop BFD session.

1. Run:
bfd bfd-name bind peer-ip ip-address [ interface interface-type interface-
number ]
BFD is enabled between the specified interface and peer router.

If a peer IP address and a local interface are specified in the bfd command, BFD
monitors only a single-hop link with the interface specified in the bfd command as
the outbound interface and with the peer IP address specified in the peer-ip command
as the next-hop address.
2. Set discriminators.
– Run:
A local discriminator is set.

– Run:
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 set using the local discr-value command on a device must be the same
as the remote discriminator set using the remote discr-value command on the device of the
other end.
3. Run:
commit
Configurations are committed.

4. Run:
quit

l Enable static BFD on an interface.
1. Run:

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

----End

Information about a BFD session can be viewed only after parameters of the BFD session are
set and the BFD session is established.
Run the display isis interface verbose command. The command output shows that the status
of static BFD for IS-IS process 1 is Yes.


---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/No
SNPA Address : 00e0-c72d-da01
Cost : L1 20 L2 20
Ipv6 Cost : L1 20 L2 20
Static Bfd : YES
Dynamic Bfd : NO

Dynamic BFD for IPv4 IS-IS can accelerate IS-IS route convergence.
Context
Connection status between an IS-IS device and its neighbors can be monitored by exchanging
Hello packets at intervals. The minimum allowable sending interval is 3s, and a neighbor is
declared Down after at least three intervals during which no response Hello packet is received
from the neighbor. IS-IS takes more than one second to detect that a neighbor becomes Down,
resulting in loss of a large amount of high-speed data.
To solve this problem, BFD must be configured for IS-IS. BFD provides millisecond-level fault
detection. After detecting a link or node failure, BFD will notify IS-IS of the failure, accelerating
the IS-IS route convergence speed.
Dynamic BFD for IPv4 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.
Before configuring dynamic BFD for IPv4 IS-IS, complete the following tasks:

No. Data
1 Number of the IS-IS process to be enabled with BFD
3 Parameter values of a BFD session
You can use either of the following methods to enable dynamic BFD for IPv4 IS-IS:
l Enable dynamic BFD for specified IS-IS IPv4 processes. This method is recommended
if you need to enable dynamic BFD for IPv4 IS-IS on a large number of IS-IS interfaces.
l Enable dynamic BFD for specified IPv4 interfaces. This method is recommended if you
need to enable dynamic BFD for IPv4 IS-IS on a small number of IS-IS interfaces.
Procedure
l Enable dynamic BFD for an IS-IS IPv4 process.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:
isis process-id

5. Run:
BFD for IS-IS is enabled.
After BFD is enabled globally and the neighbor status becomes Up, IS-IS adopts
default BFD parameters to establish BFD sessions on all interfaces.
6. (Optional) Run:
bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval
transmit-interval | detect-multiplier multiplier-value | frr-binding } *
The parameters for establishing BFD sessions are set for all interfaces.
The command execution result is applicable to BFD session parameters on all IS-IS
interfaces.
7. Run:
quit

To disable the BFD function on an interface, run the isis bfd block command in the
interface view to disable the interface from establishing BFD sessions.
l Enable dynamic BFD on an IPv4 interface.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:

5. Run:
isis bfd enable
BFD is enabled on the interface.
After BFD is configured globally and the neighbor status is Up (on a broadcast
network, DIS is in the Up state), default BFD parameters will be used to establish
BFD sessions on the specified interface.
6. (Optional) Run:
isis bfd { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value | frr-binding } *
Run this command when BFD session parameters need to be configured for a specified
interface.
NOTE
The 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.
----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.
<HUAWEI> display isis bfd session all
BFD session information for ISIS(1)
-----------------------------------
Peer System ID : 0000.0000.0002 Interface : Pos1/0/0
TX : 1000 BFD State : up Peer IP Address : 1.1.1.2
RX : 1000 LocDis : 8192 Local IP Address: 1.1.1.1

Multiplier : 3 RemDis : 8192 Type : L2

Diag : No diagnostic information
Run the display isis [ process-id ] bfd interface command to view all the interfaces enabled
with BFD and the values of the BFD session parameters on these interfaces.
<HUAWEI> display isis bfd interface
BFD information of interface for ISIS(1)
-----------------------------------------
Interface BFD.State Min-Tx Min-Rx Mul
Pos1/0/0 enable 1000 1000 3
Total interfaces: 1 Total bfd enabled interfaces: 1

resources.

Before configuring multi-topology for IPv4 IS-IS, familiarize yourself with the usage scenario,
In traditional IP networks, there is only one unicast topology and one unicast forwarding table
on each device. In this case, service flows with the same destination IP address share the same
PHB. This means that various end-to-end services (for example, voice services and data services)
share the same physical links. As a result, some links may be heavily congested, whereas some
other links are relatively idle. Different types of services have different QoS requirements, which
cannot be met in the traditional unicast topology.
Multi-topology for IS-IS enables the operation of multiple independent logical topologies in an
IS-IS AS, and sets up an independent multicast topology for multicast services. In this manner,
the multicast topology is separated from the unicast topology.
Configuring multi-topology for IS-IS will help customers construct networks flexibly and reduce
cost for network construction.
Before configuring multi-topology for IPv4 IS-IS, complete the following tasks:
l Assigning an IP address to each interface to ensure IP connectivity

l Configuring multi-topology for IPv4 IS-IS globally
Data Preparation
To configure multi-topology for IPv4 IS-IS, you need the following data.

No. Data
1 Cost style of each IS-IS process running on the router
2 ID of each topology instance
7.10.2 Enabling Multi-Topology for IPv4 IS-IS Processes

Based on service requirements and network planning, you can associate IS-IS processes with
multiple different topology instances. In this manner, an IS-IS AS can be divided into multiple
logical topologies.
Context
After enabling multi-topology for IS-IS, configure parameters, such as interface costs and
protocol priorities, for IS-IS topology instances.
The parameters configured in the IS-IS topology view are valid only for the specified IS-IS
topology instance. This allows you to configure different parameters for different IS-IS topology
instances.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
cost-style { narrow | wide | wide-compatible }
The cost style for the packets received and sent by the router is set to wide or wide-
compatible.
Step 4 Run:
topology topology-name [ topology-id { multicast | topology-id } ]
The specified IS-IS process is associated with the specified topology instance, and the IS-IS
topology view is displayed.
Step 5 (Optional) Run the following commands to configure IS-IS parameters for IPv4 topology
instances.
l auto-cost enable
l bandwidth-reference value
l circuit-cost { cost | maximum } [ level-1 | level-2 ]
l circuit default-tag tag [ level-1 | level-2 ]

l default-route-advertise [ always | match default | route-policy route-policy-name ]

[ [ cost cost ] | [ tag tag ] | [ level-1 | level-1-2 | level-2 ] ] * [ avoid-learning ]
l filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-policy
route-policy-name } export [ protocol [ process-id ] ]
l filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-policy
route-policy-name } import
l frr
l import-route protocol [ process-id ] [ cost-type { external | internal } | cost cost | tag
tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ] *
l import-route { { rip | isis | ospf } [ process-id ] | bgp } inherit-cost [ tag tag | route-
policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ] *
l import-route isis level-1 into level-2 [ filter-policy { acl-number | acl-name acl-name | ip-
prefix ip-prefix-name | route-policy route-policy-name } ] [ tag tag ]
l 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 } ] *
l maximum load-balancing number
l nexthop ip-address weight value
l preference preference route-policy route-policy-name
l prefix-priority [ level-1 | level-2 ] { critical | high | medium } { ip-prefix prefix-name |
tag tag-value }
l set-overload [ on-startup [ timeout1 | start-from-nbr system-id [ timeout1 [ timeout2 ] ] |
wait-for-bgp [ timeout1 ] ] [ send-sa-bit [ timeout3 ] ] ] [ allow { interlevel | external } * ]
l spf-priority priority-value
l summary ip-address mask [ avoid-feedback | generate_null0_route | tag tag | [ level-1 |
level-1-2 | level-2 ] ] *
----End
7.10.3 Enabling Multi-Topology for IPv4 IS-IS Interfaces

After enabling multi-topology for IS-IS, you need to associate a specified interface with an IS-
IS topology instance.
Context
An IS-IS interface can be associated with different topology instances, and the parameters of
this IS-IS interface can vary with the topology instances. The commands for configuring the
parameters are as follows:
l Command that cancels the association between an IS-IS interface and an IPv4 base topology
l Command that suppresses IS-IS to advertise direct routes of an interface in a specified
topology
l Command that configures the cost of an interface in a specified topology instance
l Command that disables an interface from participating in LFA calculation so that the
interface will not be a backup interface
l Command that sets an administrative tag for an interface in a specified topology instance

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
isis topology topology-name
An IS-IS topology instance is associated with the interface.

isis suppress topology base
The association between the IS-IS interface and the IPv6 base topology is canceled.

isis [ ipv6 ] [ topology topology-name ] suppress-reachability [ level-1 |
level-1-2 | level-2 ]
IS-IS is disabled from advertising direct routes of the interface in the specified topology instance.

isis [ topology topology-name ] cost { cost | maximum } [ level-1 | level-2 ]
The cost of the interface in the topology instance is configured.

undo isis lfa-backup [ topology topology-name ] { level-1 | level-2 | level-1-2 }
The interface is disabled from being a backup interface.

isis [ topology topology-name ] tag-value tag [ level-1 | level-2 ]
An administrative tag is set for the interface in the specified topology instance.
----End

After multi-topology for IPv4 IS-IS is configured, you can view information about multi-
topology.
Prerequisites
Multi-topology for IPv4 IS-IS has been configured.
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 route [ process-id | vpn-instance vpn-instance-name ] [ ipv4 ] [

topology topology-name ] [ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-
length ] ] * command to check information about IS-IS routes.
l Run the display isis spf-tree [ systemid systemid | dname dname ] [ [ level-1 | level-2 ] |
ipv6 | verbose ] * [ process-id | vpn-instance vpn-instance-name | ][ topology topology-
name ] command to check information about the SPF tree of IS-IS.
----End
Example
Run the display isis peer verbose command. The command output shows that the neighbor
status in IS-IS topology instance 10 is Up.
<HUAWEI> display isis peer verbose
0000.0000.0003 GE1/0/2 0000.0000.0003.01 Up 7s L2 64
MT IDs supported : 0(UP) 10(UP)

Local MT IDs : 0 10
Area Address(es) : 10
Peer IP Address(es) : 10.1.2.2
Uptime : 00:03:46
Adj Protocol : IPV4
Restart Capable : YES
Suppressed Adj : NO
Peer System Id : 0000.0000.0003
Total Peer(s): 2
Run the display isis route topology Red command. The command output shows the information
about routes of the IS-IS topology instance named Red.
<HUAWEI> display isis route topology Red

-----------------------------
topology Red
------------

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

----------------------------------------------------------------------------
10.1.4.0/24 20 NULL GE1/0/2 10.1.2.2 A/-/-/-
10.1.2.0/24 10 NULL GE1/0/2 Direct D/-/L/-
22.22.22.22/32 20 NULL GE1/0/2 10.1.2.2 A/-/-/-
U-Up/Down Bit Set
Run the display isis spf-tree topology Red command. The command output shows information
about the SPF tree of the IS-IS topology instance named Red.
<HUAWEI> display isis spf-tree topology Red
Shortest Path Tree for ISIS(1)

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

topology Red
------------
Flags: T-System is on SPF TREE R-System is directly reachable

O-System is Overload D-System or Link is to be deleted
C-Neighbor is child P-Neighbor is parent
G-Cost gets greater L-Cost gets lower
H-Nexthop is changed U-Protocol usage is changed
V-Link is involved N-Link is a new path
S-Link is IGP Shortcut *-Relative cost
ISIS(1) Level-2 Shortest Path Tree

----------------------------------
SpfNode NodeFlags NeighbourNode LinkCost LinkFlags

------------------------------------------------------------------------
>0000.0000.0001.00 T/-/-/- 0000.0000.0003.01 10 C/-/-/-/-/-/-
0000.0000.0002.01 -/-/-/- 0000.0000.0002.00 0 -/-/-/-/-/-/-
>0000.0000.0001.00 0 -/-/-/-/-/-/-
0000.0000.0002.02 -/-/-/- 0000.0000.0002.00 0 -/-/-/-/-/-/-
0000.0000.0004.00 0 -/-/-/-/-/-/-
0000.0000.0003.00 T/-/-/- 0000.0000.0003.01 10 P/-/-/-/-/-/-
0000.0000.0003.02 10 C/-/-/-/-/-/-
0000.0000.0003.01 T/R/-/- 0000.0000.0003.00 0 C/-/-/-/-/-/-
>0000.0000.0001.00 0 P/-/-/-/-/-/-
0000.0000.0003.02 T/-/-/- 0000.0000.0003.00 0 P/-/-/-/-/-/-
0000.0000.0004.00 0 C/-/-/-/-/-/-
0000.0000.0004.00 T/-/-/- 0000.0000.0003.02 10 P/-/-/-/-/-/-

With IS-IS Auto FRR, traffic on a faulty link can be quickly switched to the backup link of the
faulty link. This ensures that the traffic interruption time is within 50 ms and improves the
reliability of IS-IS networks.

Before configuring IS-IS Auto FRR, familiarize yourself with the usage scenario, complete the
At present, the VoIP and on-line video services require high-quality real-time transmission.
Nevertheless, if an IS-IS fault occurs, multiple processes, including fault detection, LSP update,
LSP flooding, route calculation, and FIB entry delivery, must be performed to switch the traffic
to a new link. As a result, it takes much more than 50 ms to recover the link from the fault, which
cannot meet the requirement for real-time services on the network.
IS-IS Auto FRR ensures fast switchover of traffic to the backup link before the network
convergence, avoiding traffic interruption. This protects traffic and improves reliability of an
IS-IS network. The NE80E/40E supports IPv4 IS-IS Auto FRR.
IS-IS Auto FRR is suitable for IP services that require a low delay and low packet loss ratio.
Before configuring IS-IS Auto FRR, complete the following tasks:

l Configuring IP addresses for interfaces to make neighboring nodes reachable at the network
layer
l Configuring the link cost to ensure that the backup path is the sub-optimal route.
Data Preparation
To configure IS-IS Auto FRR, you need the following data.
No. Data
1 IS-IS process ID
2 Interface to be enabled with IS-IS Auto FRR
7.11.2 Enabling IPv4 IS-IS Auto FRR

IS-IS can create the loop-free backup route only when the interface cost is in compliance with
the traffic protection inequality of IS-IS Auto FRR.
Context
Perform the following steps on the router that needs the protection for the forwarded traffic:
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ]
The IS-IS process is enabled and the IS-IS view is displayed.

Step 3 Run:
frr
The IS-IS FRR view is displayed.

Backup routes are filtered using a filtering policy. Only backup routes that have passed the
filtering policy are added to the routing table.
Step 5 Run:
loop-free-alternate [ level-1 | level-2 | level-1-2 ]
IS-IS Auto FRR is enabled and the loop-free backup route is created.
If the IS-IS level is not specified, IS-IS Auto FRR is enabled on Level-1 and Level-2 to create
the backup route.

For detailed information about IS-IS Auto FRR, refer to the HUAWEI NetEngine80E/40E
Router Feature Description - IP Routing.
NOTE
For detailed information about IS-IS Auto FRR, refer to the HUAWEI NetEngine80E/40E Router Feature
Description - IP Routing.
IS-IS can create the loop-free backup route only if the interface cost is in compliance with the traffic
protection inequality of IS-IS Auto FRR.
----End
7.11.3 (Optional) Disabling an Interface from Being Involved in

IPv4 LFA Calculation
To facilitate network management and fault location, you can prevent certain interfaces from
participating in the LFA calculation and specify the interfaces that can function as backup
outbound interfaces.
Context
Perform the following steps on the IS-IS interface to be disabled from participating in the Loop-
Free Alternate (LFA) calculation:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo isis lfa-backup [ level-1 | level-2 | level-1-2 ]
The interface is disabled from participating in the LFA calculation.
----End

After configuring IS-IS Auto FRR, you can check the IS-IS backup route and traffic protection
type.
Prerequisites
All IS-IS Auto FRR configurations are complete.

Procedure
[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * command to check
information about the primary link and backup link after IS-IS Auto FRR is enabled.
ipv6 | verbose ] * [ process-id | vpn-instance vpn-instance-name ] command to check the
traffic protection type of IS-IS Auto FRR.
----End
Example
Enable IS-IS Auto FRR, and then check and find information about the backup outbound
interface and the backup next hop of the route with the destination address as 100.1.1.0/24. The
following is the check result:
<HUAWEI> display isis route 100.1.1.1 verbose

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

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

Admin Tag : - Src Count : 1 Flags : A/-/L/-/-
Priority : Low
1.0.0.2 GE1/0/0 0x00000003
(B)2.0.0.2 GE2/0/0 0x00000004

U-Up/Down Bit Set, C-In Computing

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

Admin Tag : - Src Count : 3 Flags : -/-/-/-/-
Priority : Low

U-Up/Down Bit Set, C-In Computing
Enable IS-IS Auto FRR, and then check and find the traffic protection type for the router with
the system ID as 0000.0000.0004. The following is the check result:
<HUAWEI> display isis spf-tree systemid 0000.0000.0004 verbose

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

----------------------------------
0000.0000.0004.00
Distance : 20
Distance-URT : 20
Flags : SPT/V6_Islt
IPv4 Nexthops-URT : 1
(1) 1.0.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00

(B) 2.0.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00 TYPE:LOOP-FREE

PROTECT:LINK-NODE
IPv4 Nexthops-MIGP : 0
IPv6 Nexthops : 0
Neighbors: 2 (Children:1 Parents:1 Others:0)
(1) 0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child

----------------------------------
0000.0000.0004.00
Distance : 20
Distance-URT : 20
Flags : SPT/V6_Islt
(1) 1.0.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00
(B) 2.0.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00 TYPE:LOOP-FREE
PROTECT:LINK-NODE
IPv6 Nexthops : 0
(1) 0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child


Before configuring basic IPv6 IS-IS functions, familiarize yourself with the usage scenario,
To deploy IS-IS on an IPv6 network, configure basic IS-IS functions to implement
communication between different nodes on the network.
Other IS-IS functions can be configured only after basic IS-IS functions are configured.
Configuring basic IPv6 IS-IS functions includes the following operations:

1. Create IPv6 IS-IS processes.
2. Configure IPv6 IS-IS interfaces.

Before configuring basic IPv6 IS-IS functions, complete the following tasks:
l Configure a link layer protocol.

l Assign an IPv6 address to each interface to ensure IP connectivity.
l Enable the IPv6 in system view.
Data Preparation
To configure basic IPv6 IS-IS functions, you need the following data.
No. Data
1 IS-IS process ID
2 NTE of an IS-IS process
3 Level of each device and level of each interface
7.12.2 Creating IPv6 IS-IS Processes

Before configuring basic IPv6 IS-IS functions, create IPv6 IS-IS processes and then enable IPv6
IS-IS interfaces.
Context
To create an IPv6 IS-IS process, perform the following operations:
The level of a device is level-1-2 by default.
Configure the device level based on the network planning. If no device level is configured,
IS-IS establishes separate neighbor relationships for Level-1 and Level-2 devices and
maintains two identical LSDBs, consuming excessive system resources.
After IS-IS host name mapping is configured, a host name but not the system ID of a device
will display by using display commands. This configuration improves the maintainability
on an IS-IS network.
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.
If both IPv4 and IPv6 are running on a network, and the IPv6 topology type of this network
is standard or compatible, enable IS-IS adjacency strict-check to ensure that an IS-IS
adjacency is established only when both IPv4 and IPv6 go Up. IS-IS adjacency strict-check
improves network reliability and prevents traffic losses.

Procedure
l Create an IS-IS process and configure the NET of a device, enable IPv6 for the process.
1. Run:
system-view

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. To associate an IS-IS process with a VPN instance, run the isis process-
id vpn-instance vpn-instance-name command.
3. Run:
network-entity net
or
network-entity area area-id auto-systemid lsr-id
A NET is configured.
NOTICE
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.
System ID used in IS-IS can be obtained in the following way: extend each part of the
IP address to 3 bits, add 0 to the front of any part that is shorter than 3 bits, divide the
extended address into three parts, with each part consisting of four decimal digits, and
the reconstructed address is the system ID.
Area addresses of NETs are checked when Level-1 IS-IS neighbor relationships are
being established, but not checked when Level-2 IS-IS neighbor relationships are
being established. Level-1 IS-IS neighbor relationships can be established only if area
addresses of NETs are the same.
4. Run:
ipv6 enable
The IPv6 of IS-IS process is enabled.

1. Run:
is-level { level-1 | level-1-2 | level-2 }
The level of the router is configured.

1. Run:
is-name symbolic-name

IS-IS dynamic host name mapping is configured. The system ID of the local device
The value of symbolic-name is contained in LSP packets and advertised to other IS-
IS devices.
On another IS-IS device displays the value of symbolic-name, but not the system ID,
of the local IS-IS device.
2. Run:
is-name map system-id symbolic-name
IS-IS static host name mapping is configured. The system ID of a peer IS-IS device
This command configuration takes effect only on the local IS-IS device. The value of
symbolic-name will not be added to LSP packets.
If dynamic host name mappings is configured on an IS-IS network, the mappings on

the network overwrite the mappings configured on the local router.
1. Run:
log-peer-change
The output of the adjacency status is enabled.

1. Run:
adjacency-strict-check enable
IS-IS adjacency strict-check is enabled.
----End
7.12.3 Configuring IPv6 IS-IS Interfaces

To configure an interface on an IS-IS device to send Hello packets or flood LSPs, IS-IS must
be enabled on this interface.
Context
The level of an IS-IS device and level of an interface together determine the level of a neighbor
relationship. By default, Level-1 and Level-2 neighbor relationships will be established between
two Level-1-2 devices. If only one level of neighbor relationships is required, you can configure
the level of an interface to prevent the establishment of the other level of neighbor relationships.
After IS-IS is enabled on an interface, the interface will automatically send Hello packets,
attempting to establish neighbor relationships. If a peer device is not an IS-IS device or if an
interface is not expected to send Hello packets, suppress the interface. Then this interface only
advertises routes of the network segment where the interface resides, but does not send Hello
packets. This suppression improves the link bandwidth usage.
Procedure
l Configure an IS-IS interface.

1. Run:
system-view

2. Run:

3. Run:
ipv6 enable
The IPv6 of interface is enabled.

4. Run:
isis ipv6 enable [ process-id ]
An IS-IS interface is configured.
After this command is run, the IS-IS device uses the specified interface to send Hello
packets and flood LSPs.
NOTE
No neighbor relationship needs to be established between loopback interfaces. Therefore, if

this command is run on a loopback interface, the routes of the network segment where the
loopback interface resides will be advertised through other IS-IS interfaces.
l (Optional) Configure the level of an IS-IS interface.
1. 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.
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 IS-IS device is not a Level-1-2, the level of the IS-IS device
determines the level of the adjacency to be established.
l (Optional) Suppress an IS-IS interface.
1. Run:
isis silent [ advertise-zero-cost ]
The IS-IS interface is suppressed.
A suppressed IS-IS interface does not send or receive IS-IS packets. The routes of the
network segment where the interface resides, however, can still be advertised to other
routers within the area.
----End
7.12.4 (Optional) Configuring the IPv6 IS-IS Interfaces

Configuring the IS-IS interface costs can control IS-IS route selection.

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 none of the preceding configurations is performed, the default cost of an IS-IS interface is 10,
and the default cost style is narrow.
Procedure
l Configure the IS-IS cost type.
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 type is configured.
The cost range of an interface and a route received by the interface vary with the cost type.
– If the cost type is narrow, the cost of an interface ranges from 1 to 63. The maximum
cost of a route received by the interface is 1023.
– 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.
– If relax-spf-limit is not specified, the cost of a route works as follows:
If the cost of a route is not greater than 1023 and the cost of every interface that the
route passes through is smaller than or equal to 63, the cost of the route received by
the interface is the actual cost.
If the cost of a route is not greater than 1023 but the costs of all interfaces that the
route passes through are greater than 63, the IS-IS device can learn only the routes
to the network segment where the interface resides and the routes imported by the
interface. The cost of the route received by the interface is the actual cost. Subsequent
routes forwarded by the interface are discarded.
If the cost of a route is greater than 1023, the IS-IS device can learn only the interface
whose route cost exceeds 1023 for the first time. That is, the cost of each interface
before this interface is not greater than 63. The routes of the network segment where
the interface resides and the routes imported by the interface can all be learned. The
cost of the route is 1023. Subsequent routes forwarded by the interface are discarded.
– If relax-spf-limit is specified, the cost of a route works as follows:

There is no limit on costs of interfaces or route costs. The cost of a route received
by an interface is the actual cost.
– 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.
l Configure the cost of an IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
isis ipv6 cost { cost | maximum } [ level-1 | level-2 ]
The cost of the IS-IS interface is configured.
You can use the isis ipv6 cost command to configure the cost of a specified interface.
l Configure the global IS-IS cost.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
ipv6 circuit-cost { cost | maximum } [ level-1 | level-2 ]
The global IS-IS cost is configured.
You can use the ipv6 circuit-cost command to configure the costs of all interfaces at
a time.
l Enable IS-IS to automatically calculate interface costs.
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
The interface is configured to automatically calculate its cost.

The configuration of the bandwidth reference value takes effect only when the cost type is
wide or wide-compatible. In this case, Cost of each interface = (Value of bandwidth-
reference/Interface bandwidth) x 10.
NOTE
The auto-cost enable command can be run on Eth-Trunk interfaces as same with on physical
interfaces. If the command is run on an Eth-Trunk interface, the bandwidth of the Eth-Trunk interface
is equal to the total bandwidth of all its member interfaces.
If the cost-style is narrow, narrow-compatible, or compatible, the cost of each interface is

based on costs listed in Table 7-2.
Table 7-2 Mapping between IS-IS interface costs and interface bandwidth
Cost Bandwidth Range
60 Interface bandwidth ≤ 10 Mbit/s

s

s

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

s
10 Interface bandwidth > 2.5 Gbit/s
NOTE
To change the cost of a loopback interface, run the isis ipv6 cost command only in the loopback
interface view.
----End
7.12.5 (Optional) Configuring IPv6 IS-IS Attributes for Interfaces

on Different Types of Networks
Different IS-IS attributes can be configured for different types of network interfaces.
Context
The establishment modes of IS-IS neighbor relationships are different on a broadcast network
and on a P2P network. Different IS-IS attributes can be configured for interfaces on different
types of networks.

IS-IS is required to select a DIS on a broadcast network. Configure the DIS priorities of IS-IS
interfaces so that the interface with the highest priority will be selected as the DIS.
The network types of the IS-IS interfaces on both ends of a link must be the same; otherwise,
the IS-IS neighbor relationship cannot be established between the two interfaces. For example,
if the type of an interface on a peer device is P2P, you can configure the type of an interface on
the local device to P2P so that an IS-IS neighbor relationship can be established between the
two devices.
IS-IS on a P2P network is not required to select a DIS. Therefore, you do not need to configure
DIS priorities. To ensure the reliability of P2P links, configure IS-IS to use the three-way
handshake mode for IS-IS neighbor relationship establishment so that faults on a unidirectional
link can be detected.
Procedure
l Configure the DIS priority of an IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
isis dis-priority priority [ level-1 | level-2 ]
The DIS priority is configured on the interface. The greater the value, the higher the
priority.
l Configure the network type of an IS-IS interface.
1. Run:
system-view

2. Run:

3. Run:
The network type of the interface is set to P2P.
The network type of an interface is determined by the physical type of the interface
by default.
When the network type of an IS-IS interface changes, interface configurations change
accordingly.
– After a broadcast interface is configured as a P2P interface using the isis circuit-
type p2p command, the default settings are restored for the interval for sending
Hello packets, the number of Hello packets that IS-IS fails to receive from a
neighbor before the neighbor is declared Down, interval for retransmitting LSPs

on a P2P link, and various IS-IS authentication modes. Consequently, other

configurations such as the DIS priority, DIS name, and interval for sending CSNPs
on a broadcast network become invalid.
– After the undo isis circuit-type command is run to restore the network type, the
default settings are restored for the interval for sending Hello packets, the number
of Hello packets that IS-IS fails to 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.
l Set the negotiation mode in which P2P neighbor relationships can be set up.
1. Run:
system-view

2. Run:

3. Run:
isis ppp-negotiation { 2-way | 3-way [ only ] }
The negotiation mode is specified on the interface.
By default, the 3-way handshake negotiation mode is adopted.
The isis ppp-negotiation command can only be used for the establishment of the
neighbor relationships on P2P links. In the case of a broadcast link, you can run the
isis circuit-type p2p command to set the link type to P2P, and then run the isis ppp-
negotiation command to set the negotiation mode for the establishment of the
neighbor relationship.
l Configure OSICP negotiation check on PPP interfaces.
1. Run:
system-view

2. Run:

3. Run:
isis ppp-osicp-check
The OSICP negotiation status is checked on a PPP interface.
By default, the OSICP negotiation status of a PPP interface does not affect the status
of an IS-IS interface.
The isis ppp-osicp-check command is applicable only to PPP interfaces. This

command 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 route to the network segment where
the interface resides is not advertised through LSPs.
l Configure IS-IS not to check whether the IP addresses of received Hello packets are on the
same network segment.
1. Run:
system-view

2. Run:

3. Run:
isis peer-ip-ignore
IS-IS is configured not to check whether the IP addresses of received Hello packets
are on the same network segment.
----End

After basic IPv6 IS-IS functions are configured, you can view information about IS-IS neighbors,
interfaces, and routes.
Prerequisites
Basic IPv6 IS-IS functions have been configured.
Procedure
Step 1 Run the display isis name-table [ process-id | vpn-instance vpn-instance-name ] command to
check the mapping from the name of the local device to the system ID.
Step 2 Run the display isis peer [ verbose ] [ process-id | vpn-instance vpn-instance-name ] command
to check information about IS-IS neighbors.
Step 3 Run the display isis interface [ [ verbose | traffic-eng ] * | tunnel ] [ process-id | vpn-
instance vpn-instance-name ] command to check information about IS-IS interfaces.
Step 4 Run the display isis route [ process-id | vpn-instance vpn-instance-name ] ipv6 [ topology
topology-name ] [ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ] * [ | count ]
command to check information about IS-IS routes.
----End
Example
Run the display isis name-table command to view the mappings between host names and system
IDs.
<HUAWEI> display isis name-table
Name table information for ISIS(1)

System ID Hostname Type

-------------------------------------------------------------------------------
1111.1111.1111 DeviceA DYNAMIC
2222.2222.2222 DeviceB DYNAMIC
Run the display isis peer command. The command output shows the status of an IS-IS neighbor,
DeviceB. System Id is displayed as DeviceB.
<HUAWEI> display isis peer

-------------------------------------------------------------------------------
DeviceB GE1/0/0 DeviceB.01 Up 9s L1 64
Total Peer(s): 1
Run the display isis interface verbose command to view information about IS-IS interfaces.
The command output shows that the DIS status of a broadcast interface is Yes, the priority of
the DIS is 20, and the cost of the interface is 30.

---------------------------------
GE1/0/0 001 Down Up 1497 L1/L2 Yes/No
IP Address :
IPV6 Link Local Address : FE80::2E0:87FF:FE0B:8100
IPV6 Global Address(es) : 10:1::1/64
Cost : L1 10 L2 10
Ipv6 Cost : L1 30 L2 30
Static Bfd : NO
Dynamic Bfd : NO
Fast-Sense Rpr : NO
Suppress Base : NO
Run the display isis route command to view information about IS-IS IPv6 routes. The command
output shows a route with the destination network segment of 30:1::/64 and with the next-hop
address of 10:1::/64.

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

--------------------------------
IPV6 Dest. ExitInterface NextHop Cost Flags

-------------------------------------------------------------------------------
30:1::/64 Pos1/0/2 Direct 10 D/L/-
10:1::/64 Pos1/0/2 FE80::2002:0:7A20:2 20 A/-/-

U-Up/Down Bit Set


Before configuring IPv6 IS-IS route selection, familiarize yourself with the usage scenario,
After basic IPv6 IS-IS functions are configured, IS-IS routes will be generated, enabling
communication between different nodes on a network.
If multiple routes are available, a route discovered by IS-IS may not the optimal route. This does
not meet network planning requirements nor facilitates traffic management. Therefore, configure
IPv6 IS-IS route selection to implement refined control over route selection.
To implement refined control over IPv6 IS-IS route selection, perform the following operations:
l Configuring the IPv6 IS-IS Interfaces.
NOTE
Changing the IS-IS cost for an interface can achieve the function of controlling route selection, but
requires routes on the interface to be recalculated and reconverged when a network topology changes,
especially on a large-scale network. In addition, the configuration result may not meet your
expectation.
Therefore, the configuration of changing IS-IS costs has best to be finished when configuring basic
IS-IS functions.
l Configure IPv6 IS-IS route leaking.
l Configure principles for using equal-cost IPv6 IS-IS routes.
l Filter IPv6 IS-IS routes.
l Configure an overload bit for an IPv6 IS-IS device.
Before configuring IPv6 IS-IS route selection, complete the following tasks:
l Configuring the link layer protocol on interfaces.
the network layer.
Data Preparation
To configure the IPv6 IS-IS route selection, you need the following data.

No. Data
1 ACL6 for filtering routes, IPv6 prefix list, or routing policy
2 Maximum number of load-balancing equal-cost IS-IS routes
3 Time when an IS-IS device enters the overload state
7.13.2 Configuring IPv6 IS-IS Route Leaking

Configuring IS-IS route leaking enables you to optimize IS-IS route selection on a two-level-
area network.
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 IPv6 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 Configure routes in the Level-2 area to leak into Level-1 area.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
– ipv6 import-route isis level-2 into level-1 [ tag tag | filter-policy { acl6-
number | acl6-name acl6-name } ] *
Routes in the Level-2 area and other Level-1 areas that meet the specified
conditions are leaked into the local Level-1 area based on the ACL.


a. Run:
quit
Return to the BGP view.

b. Run:
quit

c. Run

d. Run
rule [ rule-id ] { deny | permit } [ fragment | source { source-
ipv6-address prefix-length | source-ipv6-address/prefix-length
| any } | time-range time-name | vpn-instance vpn-instance-
name ] *

When the rule command is run to configure rules for a named ACL, only
the source address range specified by source and the time period specified
by time-range are valid as the rules.
– If the action specified in an ACL rule is permit, a route that matches
the rule will be received or advertised by the system.
policy that references the ACL will not be received or advertised by
the system.
matching the route-policy will be received or advertised by the
system.
– In the configuration order, the system first matches a route with a rule
that has a smaller number and then matches the route with a rule with
a larger number. Routes can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller
number and specify the action deny in this rule to filter out the
unwanted routes. Then, configure another rule with a larger number in
the same ACL and specify the action permit in this rule to receive or
advertise the other routes.
Route filtering using a whitelist: Configure a rule with a smaller
number and specify the action permit in this rule to permit the routes
to be received or advertised by the system. Then, configure another
rule with a larger number in the same ACL and specify the action
deny in this rule to filter out unwanted routes.

a. Run
acl ipv6 name acl-name [ number acl-number2 ] [ match-order
{ auto | config } ]

b. Run
rule [ rule-id ] { deny | permit } protocol [ source { source-
| any } | time-range time-name ] *

the system.
system.
– ipv6 import-route isis level-2 into level-1 [ tag tag | filter-policy ipv6-prefix
ipv6-prefix-name ] *
conditions are leaked into the local Level-1 area based on the prefix list.
– ipv6 import-route isis level-2 into level-1 [ tag tag | filter-policy route-policy
route-policy-name ] *
conditions are leaked into the local Level-1 area based on the route policy.

NOTE
By default, routes in the Level-2 area are not leaked into Level-1 areas. After this command is
run, only routes that meet the specified conditions can be leaked into Level-1 areas.
l Configure routes in Level-1 areas to leak into the Level-2 area.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
– ipv6 import-route isis level-1 into level-2 [ tag tag | filter-policy { acl6-
number | acl6-name acl6-name } ] *
Routes that meet the specified conditions in Level-1 areas are leaked into the
Level-2 area based on the ACL.
a. Run:
quit

b. Run:
quit

c. Run

d. Run
name ] *


the system.
system.
a. Run
{ auto | config } ]

b. Run

the system.
system.


– ipv6 import-route isis level-1 into level-2 [ tag tag | filter-policy ipv6-prefix
ipv6-prefix-name ] *
Level-2 area based on the prefix list.
– ipv6 import-route isis level-1 into level-2 [ tag tag | filter-policy route-policy
Level-2 area based on the route policy.
NOTE
By default, all routes in a Level-1 area are leaked into the Level-2 area. After this command is
run, only routes that meet the specified conditions can be leaked into the Level-2 area.
----End
7.13.3 Configuring Principles for Using Equal-Cost IPv6 IS-IS

Routes
If multiple equal-cost IS-IS routes are available on a network, configure the equal-cost IS-IS
routes to work in load-balancing mode to increase the bandwidth usage of each link.
Context
If there are redundant IPv6 IS-IS links, multiple routes may have an equal cost. Configure the
equal-cost IPv6 IS-IS routes to work in load-balancing mode 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
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

Step 3 Run:
ipv6 maximum load-balancing number
The maximum number of load-balancing equal-cost IS-IS routes is set.
NOTE
When the number of equal-cost routes is greater than number specified in the ipv6 maximum load-
1. Route preference: Routes with lower preferences are selected for load balancing.
2. Interface index: If routes have the same priorities, routes with higher interface index values are selected
for load balancing.
3. Next hop IP address: If routes have the same priorities and interface index values, routes with larger
IP address are selected for load balancing.
----End
7.13.4 Filtering IPv6 IS-IS Routes

If some IS-IS routes are not preferred, configure conditions to filter IS-IS routes. Only IS-IS
routes meeting the specified conditions can be added to an 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, IPv6 prefix, and routing policy, to filter routes so that only IS-IS routes that meet the
specified conditions can add 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:
l ipv6 filter-policy { acl6-number | acl6-name acl6-name } import
Conditions for filtering IS-IS routes are configured based on the ACL.
1. Run:
quit

2. Run:

quit

3. Run

4. Run

valid as the rules.
routes.
1. Run
config } ]

2. Run
range time-name ] *


routes.
l ipv6 filter-policy ipv6-prefix ipv6-prefix-name import
Conditions for filtering IS-IS routes are configured based on the prefix list.
l ipv6 filter-policy route-policy route-policy-name import
Conditions for filtering IS-IS routes are configured based on the route policy.
----End
7.13.5 Configuring an Overload Bit for an IPv6 IS-IS Device

If an IS-IS device needs to be temporarily isolated, configure the IS-IS device to enter the
overload state to prevent other devices from forwarding traffic to this IS-IS device and prevent
blackhole routes.
Context
If an IS (for example, an IS to be upgraded or maintained) needs to be temporarily isolated,
configure the IS to enter the overload state so that no device will forward traffic to this IS.
IS-IS routes converge more quickly than BGP routes. To prevent blackhole routes on a network
where both IS-IS and BGP are configured, set an overload bit to instruct an IS to enter the
overload state during its start or restart. After BGP convergence is complete, cancel the overload
bit.

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 is configured.
----End
7.13.6 Configuring IS-IS to Generate IPv6 Default Routes

This section describes how to configure Intermediate System to Intermediate System (IS-IS) to
generate IPv6 default routes to control the advertising of IS-IS routing information.
Context
The destination address and mask of a default route are all 0s. If the destination address of a
packet does not match any entry in the routing table of a device, the device sends the packet
along the default route. If neither the default route nor the destination address of the packet exists
in the routing table, the device discards the packet and informs the source end that the destination
address or network is unreachable.
IS-IS can generate default routes using either of the following mode:
l Command-triggered default route generation mode
You can run the default-route-advertise command on a device so that the device adds a
default route to the LSP before sending the LSP to a neighbor. Therefore, the neighbor can
learn this default route.
l ATT bit 1-triggered default route generation mode
IS-IS defines that a Level-1-2 router sets the ATT bit to 1 in the LSP to be advertised to a
Level-1 area if the Level-1-2 router can reach more Level-1 areas through the Level-2 area
than through the Level-1 area. After a Level-1 router in the Level-1 area receives the LSP,
it generates a default route destined for the Level-1-2 router. Based on the network
requirements, you can configure whether the Level-1-2 router sets the ATT bit carried in
the LSP and whether a Level-1 router generates a default route after it receives the LSP
carrying ATT bit 1.
NOTE
This mode applies only to Level-1 routers.
Procedure
l Configure command-triggered default route generation mode.

1. Run:
system-view

2. Run:
isis [ process-id ]

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 generate default routes.

l Configure ATT bit 1-triggered default route generation mode.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run the following command as required:
– To set the ATT bit in the LSPs sent by the Level-1-2 router, 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 router 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 router does not generate a default
route, which reduces the size of a routing table.
– To disable the Level-1 router from generating default routes even though it receives
the LSPs carrying ATT bit 1, run the attached-bit avoid-learning command.
----End

After configuring IPv6 IS-IS route selection, run the following commands to verify that the
configurations are correct.
Procedure
[ topology topology-name ] [ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ]
* [ | count ] command to check IS-IS routing information.
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check information
in the IS-IS LSDB.
----End

Example
On a Level-1 device, run the display isis route command to check IS-IS routing information.
If the Level-1-2 device is enabled to leak IS-IS routes in the Level-2 area to Level-1 areas, the
output of the display isis route command is similar to the following information. For example,
the route 44:4::/64 in the Level-2 area is displayed, and Up/Down is U.

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

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

-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL

-------------------------------------------------------------------------------
::/0 GE1/0/0 FE80::2E0:51FF:FE52:8100 10 A/-/-
20:1::/64 GE1/0/0 FE80::2E0:51FF:FE52:8100 20 A/-/-
10:1::/64 GE1/0/0 Direct 10 D/L/-
44:4::/64 GE1/0/0 FE80::2E0:51FF:FE52:8100 20 A/-/U

U-Up/Down Bit Set
On the Level-1-2 device, run the display isis lsdb verbose command to check whether the
Level-1-2 device has leaked the route 44:4::/64 to Level-1 areas.

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

-------------------------------------------------------------------------------
1111.1111.1111.00-00 0x00000004 0x7fd7 875 87 0/0/0
SOURCE 1111.1111.1111.00
NLPID IPV4
NLPID IPV6
AREA ADDR 10
INTF ADDR V6 10:1::1
Topology Standard
NBR ID 1111.1111.1111.01 COST: 10
IPV6 10:1::/64 COST: 10
1111.1111.1111.01-00 0x00000001 0x8fd8 875 56 0/0/0

SOURCE 1111.1111.1111.01
NLPID IPV4
NLPID IPV6
NBR ID 1111.1111.1111.00 COST: 0
NBR ID 2222.2222.2222.00 COST: 0
2222.2222.2222.00-00* 0x00000007 0x459e 1194 130 1/0/0

SOURCE 2222.2222.2222.00
NLPID IPV6
AREA ADDR 10
Topology Standard

NBR ID 1111.1111.1111.01 COST: 10

IPV6 10:1::/64 COST: 10
IPV6 20:1::/64 COST: 10
IPV6* 44:4::/64 COST: 10
Total LSP(s): 3

-------------------------------------------------------------------------------
2222.2222.2222.00-00* 0x00000008 0x8eb1 993 116 0/0/0
SOURCE 2222.2222.2222.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 3333.3333.3333.00 COST: 10
IPV6 10:1::/64 COST: 10
IPV6 20:1::/64 COST: 10
3333.3333.3333.00-00 0x00000005 0xe7e3 997 116 0/0/0

SOURCE 3333.3333.3333.00
NLPID IPV6
AREA ADDR 20
Topology Standard
NBR ID 2222.2222.2222.00 COST: 10
IPV6 20:1::/64 COST: 10
IPV6 44:4::/64 COST: 0
Total LSP(s): 2
Run the display isis route command to check IS-IS routing information. If equal-cost IS-IS
routes are configured to work in load-balancing mode, multiple next hops will be displayed in
the command output. For example, two next hops, FE80::2E0:51FF:FE52:8100 and
FE80::2E0:FFFF:FE50:8200, to the 44:4::/64 network segment are displayed, and their route
costs are both 20.

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

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

-------------------------------------------------------------------------------
13:1::/64 GE1/0/1 Direct 10 D/L/-
34:1::/64 GE1/0/1 FE80::2E0:FFFF:FE50:8200 20 A/-/-
20:1::/64 GE1/0/0 FE80::2E0:51FF:FE52:8100 20 A/-/-
10:1::/64 GE1/0/0 Direct 10 D/L/-
44:4::/64 GE1/0/0 FE80::2E0:51FF:FE52:8100 20 A/-/-
GE1/0/1 FE80::2E0:FFFF:FE50:8200

U-Up/Down Bit Set


routing table.
Context
Route summarization is used to summarize routes with the same IP prefix into one route.
On a large-scale IS-IS network, route summarization can be configured to reduce the number
of IS-IS routes in a routing table. This summarization improves the usage of system resources
and facilitates route management.
If a link on an IP network segment that is summarized frequently alternates between Up and

Down states, IP network segments that are not summarized will not be affected, preventing route
flapping and improving the network stability.
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 IS-IS routes are summarized into one IS-IS route.
NOTE
After route summarization is configured on an IS, the local routing table still contains all specific routes
before the summarization.
The routing tables on other ISs contain only the summary route, and the summary route is deleted only
after all its specific routes are deleted.
----End

After the route summarization function is configured, perform the following steps to check
whether the route summarization function has taken effect.
l Run the display isis route command to check summary routes in the IS-IS routing table.
l Run the display ipv6 routing-table [ verbose ] command to check summary routes in the
IP routing table.

7.15 Configuring IPv6 IS-IS to Interact with Other Routing

Protocols

Before configuring IPv6 IS-IS to interact with other routing protocols, familiarize yourself with
the usage scenario, complete the pre-configuration tasks, and obtain the data required for the
configuration.
If other routing protocols are configured on an IS-IS network, the following issues need to be
considered:
l Preference of IS-IS routes
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. For example, if both OSPFv3 and IS-IS are configured, the route discovered
by OSPFv3 is used because OSPFv3 enjoys a higher preference than IS-IS by default.
Therefore, if you want the route discovered by IS-IS to be used, configure IS-IS to have
the highest preference.
l Communication between an IS-IS area and other areas
If other routing protocols are configured on an IS-IS network, you need to configure IS-IS
to interact with those routing protocols so that IS-IS areas can communicate with non-IS-
IS areas.
NOTE
The LSDBs of different IS-IS processes on a device are independent of each other. Therefore, each
IS-IS process on the device considers routes of the other IS-IS processes as external routes.
To ensure successful traffic forwarding, configure IS-IS to interact with other routing
protocols on a device where external routes are configured, for example, a Level-1-2 IS-
IS router. Available method is configuring IS-IS to import external routes. This mode
enables all devices in IS-IS areas to learn external routes, implementing refined control
over traffic forwarding.
To ensure successful forwarding of traffic destined for IS-IS areas, you must also enable
the other routing protocols to interact with IS-IS.
Before configuring IPv6 IS-IS to interact with other routing protocols, complete the following
tasks:

the network layer


l Configuring basic functions of other routing protocols
Data Preparation
To configure the IPv6 IS-IS to interact with other routing protocols, you need the following data.
No. Data
1 ACL6 for filtering routes, IPv6 prefix list, or routing policy
2 Preference value of IS-IS
7.15.2 Configuring a Preference Value for IPv6 IS-IS

If multiple routes to the same destination are discovered by different routing protocols,
configuring the highest preference value for IS-IS allows a route discovered by IS-IS to be
selected preferentially.
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.
For example, if both OSPFv3 and IS-IS are configured on a network, the route discovered by
OSPFv3 is used because OSPFv3 has a higher preference than IS-IS by default.
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
l Configure the IS-IS preference value.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
ipv6 preference preference
The IS-IS preference value is configured.
NOTE
A smaller preference value indicates a higher preference.

The default IS-IS preference value is 15.

l Configure preference values for specified IS-IS routes.

1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
ipv6 preference route-policy route-policy-name preference
The preference values are configured for the specified IS-IS routes.
NOTE
preference takes effect only for IS-IS routes that match the specified routing policy.
----End
7.15.3 Configuring IPv6 IS-IS to Import External Routes

If devices in an IS-IS routing domain need to learn external routes, configure IS-IS on a Level-1-2
device of this routing domain to import external routes.
Context
If IS-IS is configured on a Level-1-2 device to advertise a default route, all traffic in IS-IS routing
domains will be forwarded by this Level-1-2 device. This will burden this Level-1-2 device
because no external route can be learned on the devices in the IS-IS routing domains.
If multiple Level-1-2 devices are deployed, 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 domains
must learn all or some external routes.
Routing policies can be configured to import or advertise external routes that meet specified
conditions to the IS-IS routing domains.
Procedure
l Configure IS-IS to import external routes.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Configuring IS-IS to Import External IPv6 Routes
– If you want to set the cost for the imported route, you can run the ipv6 import-
route { direct | static | { 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 import the external routes.
– If you want to keep the original cost for the imported route, you can run the ipv6
import-route { { ripng | isis | ospfv3 } [ process-id ] | direct | bgp } inherit-
cost [ tag tag | route-policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ]
* command to import the external routes. When configuring IS-IS to retain the
original cost value of the imported route, the source routes cannot be static.
NOTE
IS-IS will advertise all imported external routes to an IS-IS routing domain by default.
If only some imported external routes need to be advertised, run the ipv6 filter-policy
export command to set a filtering policy.
If an IS-IS device has a small routing table capacity, run the ipv6 import-route limit limit-
number [ threshold-alarm upper-limit upper-limit-value lower-limit lower-limit-value ]
{ level-1 | level-2 | level-1-2 } command to set the maximum number of external routes that
can be imported into an IS-IS routing domain.
l (Optional) Configure IS-IS to advertise some external routes to an IS-IS routing domain.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
– ipv6 filter-policy { acl6-number | acl6-name acl6-name } export [ protocol
[ process-id ] ]
IS-IS is configured to advertise specified external routes to the IS-IS routing
domain based on the ACL.
a. Run:
quit

b. Run:
quit

c. Run

d. Run
name ] *

the system.
system.
a. Run
{ auto | config } ]

b. Run


the system.
system.
– ipv6 filter-policy ipv6-prefix ipv6-prefix-name export [ protocol [ process-id ] ]
domain based on the prefix list.
– ipv6 filter-policy route-policy route-policy-name export [ protocol [ process-
id ] ]
domain based on the route policy.
NOTE
After this command is run, only external routes that meet the specified conditions can be
advertised to the IS-IS routing domain.
----End

After IS-IS is enabled to import routes from other protocols, run the following commands to
verify that the configurations are correct.
Procedure
name } ] * [ process-id | vpn-instance vpn-instance-name ] command to check IS-IS LSDB
information.
* [ | count ] command to check IS-IS routing information.
l Run the display ipv6 routing-table ipv6-prefix ipv6-prefix-name [ verbose ] command

to check the IP routing table.
----End

Example
Run the display isis lsdb verbose command on the device that generates a default route. The
command output shows that IS-IS has advertised a default route.

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

-------------------------------------------------------------------------------
1111.1111.1111.00-00 0x0000000a 0xfab7 1120 86 0/0/0
SOURCE 1111.1111.1111.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 2222.2222.2222.01 COST: 10
IPV6 12:1::/64 COST: 10
2222.2222.2222.00-00* 0x0000000f 0xe95c 1138 86 0/0/0

SOURCE 2222.2222.2222.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 2222.2222.2222.01 COST: 10
IPV6 12:1::/64 COST: 10
2222.2222.2222.00-01* 0x00000003 0x7cbc 1195 35 0/0/0

SOURCE 2222.2222.2222.00
IPV6 ::/0 COST: 0
2222.2222.2222.01-00* 0x00000002 0xe1ea 1138 55 0/0/0

SOURCE 2222.2222.2222.01
NLPID IPV6
NBR ID 2222.2222.2222.00 COST: 0
NBR ID 1111.1111.1111.00 COST: 0
3333.3333.3333.00-00 0x00000004 0xac80 231 68 0/0/0

SOURCE 3333.3333.3333.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 20.1.1.2
NBR ID 2222.2222.2222.00 COST: 10
IP-Internal 20.1.1.0 255.255.255.0 COST: 10
Total LSP(s): 5
Run the display isis route command on the device that receives the default route. The command
output shows that the default route ::/0 with a next-hop address of FE80::7D7E:0:22D7:1 has
been imported into the Level-2 IS-IS routing table.

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

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


-------------------------------------------------------------------------------
::/0 Pos1/0/0 FE80::7D7E:0:22D7:1 10 A/-/-
13:1::/64 GE1/0/1 Direct 10 D/L/-
34:1::/64 Pos1/0/0 Direct 10 D/L/-
20:1::/64 Pos1/0/0 FE80::7D7E:0:22D7:1 20 A/-/-
10:1::/64 GE1/0/1 FE80::2E0:BAFF:FE1E:8200 20 A/-/-
44:4::/64 Pos1/0/0 FE80::7D7E:0:22D7:1 10 A/-/-

U-Up/Down Bit Set
Run the display isis route command to view the IS-IS routing table. The command output shows
that the OSPFv3 route 44:4::/64 has been imported into the Level-2 IS-IS routing table.

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

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

-------------------------------------------------------------------------------
13:1::/64 Pos1/0/0 FE80::907D:0:103A:1 20 A/-/-
34:1::/64 Pos1/0/0 Direct 10 D/L/-
20:1::/64 Pos1/0/1 Direct 10 D/L/-
10:1::/64 Pos1/0/1 FE80::DC23:0:FC15:3 20 A/-/-

U-Up/Down Bit Set
ISIS(1) Level-2 Redistribute Table

----------------------------------
Type IPV6 Destination IntCost Tag

-------------------------------------------------------------------------------
O 44:4::/64 20
Type: D-Direct, I-ISIS, S-Static, O-OSPF, B-BGP, R-RIP
Run the display ipv6 routing-table command to view the IP routing table. The command output
shows that the value of Preference of IPv6 IS-IS has been changed from its default value 15 to
20.
<HUAWEI> display ipv6 routing-table
NextHop : FE80::7D7E:0:22D7:1 Preference : 20
Cost : 10 Protocol : ISIS-L2

Destination : 10:1:: PrefixLength : 64

NextHop : FE80::2E0:BAFF:FE1E:8200 Preference : 20


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



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





Before configuring the IPv6 IS-IS route convergence speed, familiarize yourself with the usage
The procedure for implementing IS-IS is as follows:

l Establishment of neighboring relationships: establishes neighboring relationships by

exchanging Hello packets between two devices.
l LSP flooding: implements LSDB synchronization between devices in the same area.
l SPF calculation: uses the SPF algorithm to calculate IS-IS routes, and delivers the IS-IS
routes to the routing table.
To accelerate the IS-IS route convergence speed, configure the following parameters:
l Interval for detecting IS-IS neighboring device failures.
l Flooding parameters of CSNPs and LSPs.
l Interval for SPF calculation.
You can also configure convergence priorities for IPv6 IS-IS routes so that key routes can be
converged by preference when a network topology changes. This minimizes adverse impacts on
key services.
Before configuring the IPv6 IS-IS route convergence speed, complete the following tasks:
l Configuring the link layer protocol on interfaces.

the network layer.
Data Preparation
No. Data
1 Interval at which Hello packets are sent and the holding time of neighboring
devices
2 Flooding time of CSNPs and LSPs
3 Interval for SPF calculation
4 Route convergence priority
7.16.2 Configuring the Interval for Detecting IS-IS Neighboring

Device Failures
To minimize the effects caused by neighboring device failures on an IS-IS network, accelerate
the speed of detecting IS-IS neighboring device failures.
Context
Connection status between an IS-IS device and its neighboring devices can be monitored by
exchanging Hello packets at intervals. An IS-IS neighboring device is considered Down if the

IS-IS device does not receive any Hello packets from the neighboring device within the specified
period (called the holding time). A failure in an IS-IS neighboring device will trigger LSP
flooding and SPF calculation, after which IS-IS routes are reconverged.
To speed up fault detection, use the following methods to accelerate the speed of detecting IS-
IS neighboring device failures:
l Configuring Dynamic IPv6 BFD for IS-IS.
NOTE
Configuring IPv6 BFD for IS-IS is recommended because this method provides a faster fault detection
speed than the other two methods.
Procedure
1. Run:
system-view

2. Run:

3. Run:
The interval at which Hello packets are sent is set.
NOTE
1. Run:
system-view

2. Run:

3. Run:
The holding multiplier of neighboring devices is set.
----End

7.16.3 Setting Flooding Parameters of SNPs and LSPs

To speed up LSDB synchronization between devices, set flooding parameters of SNPs and LSPs
to proper values.
Context
SNPs consist of CSNPs and PSNPs. CSNPs carry summaries of all LSPs in LSDBs, ensuring
LSDB synchronization between neighboring routers. SNPs are processed differently on
broadcast links and P2P links.
l On a broadcast link, CSNPs are periodically sent by a DIS device. If a router detects that
its LSDB is not synchronized with that on its neighboring router, the router will send PSNPs
to apply for missing LSPs.
l On a P2P link, CSNPs are sent only during initial establishment of neighboring
relationships. If a request is acknowledged, a neighboring router will send a PSNP in
response to a CSNP. If a router detects that its LSDB is not synchronized with that on its
neighboring router, the router will also send PSNPs to apply for missing LSPs.
To speed up LSDB synchronization, modify the following parameters of SNPs and LSPs on the
NE80E/40E:
Procedure
1. Run:
system-view

2. Run:

3. Run:
The interval at which CSNPs are sent is set on the specified interface.
NOTE
Configure Level-1 and Level-2 only when a broadcast interface is specified.


1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The intelligent timer controlling LSP generation is configured.

If a level is not specified, both level-1 and level-2 are used by default.
The delay in generating an LSP or an LSP fragment for the first time is determined
by init-interval; the delay in generating an LSP or an LSP fragment for the second
time is determined by incr-interval. From the third time on, the delay in generating
an LSP 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.
If incr-interval is not specified, the delay in generating an LSP or LSP fragment for
the first time is determined by init-interval. From the second time on, the delay in
generating an LSP 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.
When only max-interval is specified, the intelligent timer functions as an ordinary
one-time triggering timer.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The maximum length is set for each LSP to be generated.

4. Run:
The maximum length is set for each LSP to be received.
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 in the lsp-length command must meet the following conditions.

– The MTU of an Ethernet interface must be greater than or equal to the sum of the
value of max-size and 3.
– The MTU of a P2P interface must be greater than or equal to the value of max-
size.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
A refresh interval is set for LSPs.
To synchronize all LSPs in the areas, IS-IS regularly transmits all the current LSPs to
neighbors.
By default, the LSP refresh interval is 900s, and the maximum lifetime of an LSP is
1200s. Ensure that the LSP refresh interval is more than 300s shorter than the
maximum LSP lifetime. This allows new LSPs to reach all routers in an area before
existing LSPs expire.
NOTE
The larger a network, the greater the deviation between the LSP refresh interval and the
maximum LSP lifetime.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
The maximum lifetime is set for LSPs.
When a router generates the system LSP, it fills in the maximum lifetime for this LSP.
After this LSP is received by other routers, the lifetime of the LSP is reduced gradually.
If the router does not receive any more update LSPs and the lifetime of the LSP is
reduced to 0, the LSP will be deleted from the LSDB 60s later if no more updated
LSPs are received.
1. Run:
system-view


2. Run:

3. Run:
The minimum interval at which LSPs are sent is set.
The count parameter specifies the maximum number of LSPs that can be sent within
the interval specified by throttle-interval. The value of count is an integer ranging
from 1 to 1000.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
flash-flood [ lsp-count | max-timer-interval interval | [ level-1 |
level-2 ] ] *
The LSP fast flooding is enabled.
Running the flash-flood command speeds up LSP flooding. 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.
1. Run:
system-view

2. Run:

3. Run:
The interval at which LSPs are retransmitted over a P2P link is set.
----End

7.16.4 Setting the SPF Calculation Interval

To improve the fault location efficiency on an IS-IS network and prevent SPF calculation from
consuming excessive system resources, set the SPF calculation interval to a proper value.
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.
The intelligent timer changes as follows:

l The delay for the first SPF calculation is determined by init-interval; the delay for the second
SPF calculation is determined by incr-interval. From the third time on, the delay in SPF
calculation increases twice every time until the delay reaches the value specified by max-
l If incr-interval is not specified, the delay in SPF calculation for the first time is determined
by init-interval. From the second time on, the delay in SPF calculation is determined by max-
l When only max-interval is specified, the intelligent timer functions as an ordinary one-time
triggering timer.
----End
7.16.5 Configuring Convergence Priorities for IPv6 IS-IS Routes

If some IS-IS routes need to be converged by preference to minimize adverse impacts on services,
configure those routes to have the highest convergence priority.

Context
By default, the convergence priority of 128-bit host routes is medium, and the convergence
priority of the other IS-IS routes is low.
The NE80E/40E allows you to configure the highest convergence priority for specific IS-IS
routes so that those IS-IS routes will be converged first when a network topology changes.
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.
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.
l If the route level is not specified, the configuration of the prefix-priority command takes
effect for both Level-1 and Level-2 IS-IS routes.
NOTE
The ipv6 prefix-priority command is only applicable to the public network.

After the ipv6 prefix-priority command is run, the convergence priority of 32-bit host routes is low, and
the convergence priorities of the other routes are determined as specified in the ipv6 prefix-priority
command.

quit

ipv6 route prefix-priority-scheduler critical-weight high-weight medium-weight low-
weight
The preference-based scheduling ratio of IPv6 routes is configured.

By default, the preference-based scheduling ratio of IPv6 routes is 8:4:2:1.
----End

After the parameters specifying the IPv6 IS-IS route convergence speed are set, run the following
commands to verify that the configurations are correct.
Procedure
l Run the display isis interface [ [ verbose | traffic-eng ] * | tunnel ] [ process-id | vpn-
instance vpn-instance-name ] command to check IS-IS packet information.
l Run the display isis route [ process-id | vpn-instance vpn-instance-name ] ipv6
* command to check the preference of IS-IS routes.
----End
Example
Run the display isis interface verbose command. The command output shows that GE 6/0/0
sends Hello packets at an interval of 15 ms, the number of IS-IS Hello packets sent by the
neighbor before IS-IS should declare the neighbor is invalid is 3, the sending interval for Level-1
CSNPs is 123 ms, and the minimum sending interval for LSPs is 159 ms.

---------------------------------
GE1/0/1 001 Down Up 1497 L1/L2 No/Yes
SNPA Address : 00e0-ff50-8200
IP Address :
IPV6 Link Local Address : FE80::2E0:FFFF:FE50:8200
IPV6 Global Address(es) : 13:1::2/64
Cost : L1 10 L2 10
Ipv6 Cost : L1 10 L2 10
Static Bfd : NO
Dynamic Bfd : NO
Fast-Sense Rpr : NO
Graceful Down : NO
Suppress Base : NO
Run the display isis route verbose command. The command output shows that the convergence
priority of the IS-IS route 13:1::/64 is Critical, and the convergence priority of the other IS-IS
routes is Low.

<HUAWEI> display isis route verbose

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

--------------------------------
IPV6 Dest : 13:1::/64 Cost : 20 Flags: A/-/-

Admin Tag : - Src Count : 2 Priority: Critical
FE80::907D:0:103A:1 Pos1/0/0 0x00000007
IPV6 Dest : 34:1::/64 Cost : 10 Flags: D/L/-

Admin Tag : - Src Count : 2 Priority: -
Direct Pos1/0/0 0x00000000
IPV6 Dest : 20:1::/64 Cost : 10 Flags: D/L/-

Admin Tag : - Src Count : 2 Priority: -
Direct Pos1/0/1 0x00000000
IPV6 Dest : 10:1::/64 Cost : 20 Flags: A/-/-

Admin Tag : - Src Count : 2 Priority: Low
FE80::DC23:0:FC15:3 Pos1/0/1 0x00000003

U-Up/Down Bit Set

If high-speed data services are deployed on an IS-IS network, dynamic BFD for IPv6 IS-IS can
be configured to accelerate the fault detection speed.
Context
The NE80E/40E supports dynamic BFD for IPv6 IS-IS, but not static BFD for IPv6 IS-IS.
Without BFD, connection status between an IS-IS device and its neighbors can be monitored
only by exchanging Hello packets at intervals. The minimum allowable sending interval is 3s,
and a neighbor is declared Down after at least three intervals during which no response Hello
packet is received from the neighbor. IS-IS takes more than one second to detect that a neighbor
becomes Down, resulting in loss of a large amount of high-speed data.
BFD provides millisecond-level fault detection. After detecting a link or node failure, BFD will
notify IS-IS of the failure. Traffic is rapidly switched to the backup link or node.
Before configuring dynamic BFD for IPv6 IS-IS, complete the following tasks:
l Configure IPv6 addresses for interfaces to ensure that neighbor nodes are reachable.
l Configure IPv6 IS-IS functions to ensure that each node is reachable at the network layer.
l Configuring Multi-Topology for IPv6 IS-IS.

No. Data
1 Nodes to be enabled with BFD for IPv6 IS-IS
2 Number of the IS-IS process to be enabled with BFD
3 Type and number of each interface to be enabled with BFD
4 Minimum interval at which BFD packets are sent
5 Minimum interval at which BFD packets are received
6 BFD detection multiplier
You can use either of the following methods to enable BFD for IPv6 IS-IS:
l Enable dynamic BFD for specified IS-IS IPv6 processes. This method is recommended
if you need to enable dynamic BFD for IPv6 IS-IS on a large number of IS-IS interfaces.
l Enable dynamic BFD for specified IPv6 interfaces. This method is recommended if you
need to enable dynamic BFD for IPv6 IS-IS on a small number of IS-IS interfaces.
Procedure
l Enable dynamic BFD for an IS-IS IPv6 process.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:
isis process-id

5. Run:
ipv6 bfd all-interfaces enable
BFD for IS-IS is enabled.
After BFD is enabled globally and the neighbor status is Up, default BFD parameters
will be used to establish BFD sessions on all interfaces.
6. (Optional) Run:

ipv6 bfd all-interfaces { min-rx-interval receive-interval | min-tx-

interval transmit-interval | detect-multiplier multiplier-value | frr-
binding } *
The parameters for establishing BFD sessions are set for all interfaces.
The command execution result is applicable to BFD session parameters on all IS-IS
interfaces.
7. Run:
quit
To disable the BFD function on an interface, run the isis ipv6 bfd block command in
the interface view to disable the interface from establishing BFD sessions.
l Enable dynamic BFD on an IS-IS IPv6 interface.
1. Run:
system-view

2. Run:
bfd

3. Run:
quit

4. Run:

5. Run:
isis ipv6 bfd enable
BFD is enabled on the interface.

6. (Optional) Run:
isis ipv6 bfd { min-rx-interval receive-interval | min-tx-interval
transmit-interval | detect-multiplier multiplier-value | frr-binding } *
Run this command when BFD session parameters need to be configured for a specified
interface.
----End

After configuring dynamic BFD for IPv6 IS-IS, you can check information about the BFD
session and BFD for IPv6 IS-IS on an interface.
l Run the display isis [ process-id | vpn-instance vpn-instance-name ] ipv6 bfd session
{ all | peer ipv6-address | interface interface-type interface-number } command to check
information about an BFD session.

l Run the display isis [ process-id ] ipv6 bfd interface command to check the configurations
of BFD for IPv6 IS-IS on the specified interface.
Run the display isis ipv6 bfd session command to view the status of an BFD session. An example
command output is as follows:
<HUAWEI> display isis 1 ipv6 bfd session all
IPv6 BFD session information for ISIS(1)
-----------------------------------
Peer System ID : 0000.0000.0003 Interface : \GE2/0/0
Type : L2
IPv6 BFD State : up TX : 100 RX : 100 Multiplier : 3
LocDis : 8184 Local IPv6 Address : FE80::1
RemDis : 8192 Peer IPv6 Address : FE80::2
Total IPv6 BFD session(s) : 1
Run the display isis [ process-id ] ipv6 bfd interface command to view all the interfaces enabled
with BFD and the values of the BFD session parameters on these interfaces.
<HUAWEI> display isis 1 ipv6 bfd interface
IPV6 BFD information of interface for ISIS(1)
---------------------------------------------
Interface BFD6.State Min-Tx Min-Rx Mul
Pos1/0/0 enable 1000 1000 10
Total interfaces: 1 Total IPv6 bfd enabled interfaces: 1

resources.

Before configuring multi-topology for IPv6 IS-IS, familiarize yourself with the usage scenario,
In traditional IPv6 networks, there is only one unicast topology and one unicast forwarding table
on each device. In this case, service flows with the same destination IP address share the same
PHB. This means that various end-to-end services (for example, voice services and data services)
share the same physical links. As a result, some links may be heavily congested, whereas some
other links are relatively idle. Different types of services have different QoS requirements, which
cannot be met in the traditional unicast topology.
Multi-topology for IS-IS enables the operation of multiple independent logical topologies in an
IS-IS AS, and sets up an independent multicast topology for multicast services. In this manner,
the multicast topology is separated from the unicast topology.
Configuring multi-topology for IS-IS will help customers construct networks flexibly and reduce
cost for network construction.
Before configuring multi-topology for IPv6 IS-IS, complete the following tasks:

l Assigning an IPv6 address to each interface to ensure IP connectivity

l Configuring multi-topology for IPv6 IS-IS globally
Data Preparation
To configure multi-topology for IPv6 IS-IS, you need the following data.
No. Data
1 Cost style of each IS-IS process running on the router
2 ID of each topology instance
7.18.2 Enabling Multi-Topology for IPv6 IS-IS Processes

Based on service requirements and network planning, you can associate IS-IS processes with
multiple different topology instances. In this manner, an IS-IS AS can be divided into multiple
logical topologies.
Context
After enabling multi-topology for IS-IS, configure parameters, such as interface costs and
protocol priorities, for IS-IS topology instances.
The parameters configured in the IS-IS topology view are valid only for the specified IS-IS
topology instance. This allows you to configure different parameters for different IS-IS topology
instances.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
cost-style { narrow | wide | wide-compatible }
The cost style for the packets received and sent by the router is set to wide or wide-
compatible.
Step 4 Run:
ipv6 topology topology-name [ topology-id { multicast | topology-id } ]
The specified IS-IS process is associated with the specified topology instance, and the IPv6 IS-
IS topology view is displayed.

Step 5 (Optional) Run the following commands to configure IS-IS parameters for IPv6 topology
instances.
l auto-cost enable
l bandwidth-reference value
l circuit-cost { cost | maximum } [ level-1 | level-2 ]
l circuit default-tag tag [ level-1 | level-2 ]
l default-route-advertise [ always | match default | route-policy route-policy-name ]
[ [ cost cost ] | [ tag tag ] | [ level-1 | level-1-2 | level-2 ] ] * [ avoid-learning ]
l filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-
policy route-policy-name } export [ protocol [ process-id ] ]
l filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name | route-
policy route-policy-name } import
l frr
l import-route protocol [ process-id ] [ cost cost ] [ tag tag ] [ route-policy route-policy-
name ] [ level-1 | level-2 | level-1-2 ]
l import-route { { ripng | isis | ospfv3 } [ process-id ] | bgp } inherit-cost [ tag tag | route-
policy route-policy-name | [ level-1 | level-2 | level-1-2 ] ]*
l import-route isis level-1 into level-2 [ filter-policy { acl6-number | acl6-name acl6-
name | ipv6-prefix ipv6-prefix-name | route-policy route-policy-name } ] [ tag tag ]
l 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 } ] *
l maximum load-balancing number
l preference preference route-policy route-policy-name
l set-overload [ on-startup [ timeout1 | start-from-nbr system-id [ timeout1 [ timeout2 ] ] |
wait-for-bgp [ timeout1 ] ] [ send-sa-bit [ timeout3 ] ] ] [ allow { interlevel | external } * ]
l spf-priority priority-value
l summary ipv6-address mask [ avoid-feedback | generate_null0_route | tag tag |
[ level-1 | level-1-2 | level-2 ] ] *
----End
7.18.3 Enabling Multi-Topology for IPv6 IS-IS Interfaces

After enabling multi-topology for IS-IS, you need to associate a specified interface with an IS-
IS topology instance.
Context
An IS-IS interface can be associated with different topology instances, and the parameters of
this IS-IS interface can vary with the topology instances. The commands for configuring the
parameters are as follows:
l Command that cancels the association between an IS-IS interface and an IPv6 base topology
l Command that suppresses IS-IS to advertise direct routes of an interface in a specified
topology
l Command that configures the cost of an interface in a specified topology instance

l Command that disables an interface from participating in LFA calculation so that the
interface will not be a backup interface
l Command that sets an administrative tag for an interface in a specified topology instance
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
isis ipv6 topology topology-name
An IS-IS topology instance is associated with the interface.

isis ipv6 suppress topology base
The association between the IS-IS interface and the IPv6 base topology is canceled.
isis [ ipv6 ] [ topology topology-name ] suppress-reachability [ level-1 |
level-1-2 | level-2 ]
IS-IS is disabled from advertising direct routes of the interface in the specified topology instance.
isis ipv6 [ topology topology-name ] cost { cost | maximum } [ level-1 | level-2 ]
The cost of the interface in the topology instance is configured.

undo isis ipv6 lfa-backup [ topology topology-name ] { level-1 | level-2 |
level-1-2 }
The interface is disabled from being a backup interface.

isis [ ipv6 ] [ topology topology-name ] tag-value tag [ level-1 | level-2 ]
An administrative tag is set for the interface in the specified topology instance.
----End

After multi-topology for IPv6 IS-IS is configured, you can view information about multi-
topology.
Prerequisites
Multi-topology for IPv6 IS-IS has been configured.

Procedure
l Run the display isis peer [ verbose ] [ process-id | vpn-instance vpn-instance-name ]
command to check information about IS-IS neighbors.
* [ | count ] command to check information about IS-IS routes.
ipv6 | verbose ] * [ process-id | vpn-instance vpn-instance-name | ][ topology topology-
name ] command to check information about the SPF tree of IS-IS.
----End
Example
Run the display isis peer verbose command. The command output shows that the neighbor
status in IS-IS topology instance 10 is Up.
<HUAWEI> display isis peer verbose
0000.0000.0003 GE1/0/2 0000.0000.0003.01 Up 7s L2 64
MT IDs supported : 0(UP) 10(UP)

Local MT IDs : 0 10
Peer IPv6 Address(es): FE80::2E0:6CFF:FE57:8300
Uptime : 00:00:29
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0003
Total Peer(s): 2
Run the display isis route ipv6 topology Red command. The command output shows the
information about routes of the IS-IS topology instance named Red.
<HUAWEI> display isis route ipv6 topology Red

-----------------------------
ipv6 topology Red

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

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

----------------------------------------------------------------------------
30:1::/64 GE1/0/2 FE80::2E0:6CFF:FE57:8300 20 A/-/-
10:2::/64 GE1/0/2 Direct 10 D/L/-
10:4::/64 GE1/0/2 FE80::2E0:6CFF:FE57:8300 20 A/-/-

U-Up/Down Bit Set
Run the display isis spf-tree ipv6 topology Red command. The command output shows
information about the SPF tree of the IS-IS topology instance named Red.

<HUAWEI> display isis spf-tree ipv6 topology Red

------------------------------
ipv6 topology Red

-----------------
Flags: T-System is on SPF TREE R-System is directly reachable

O-System is Overload D-System or Link is to be deleted
C-Neighbor is child P-Neighbor is parent
G-Cost gets greater L-Cost gets lower
H-Nexthop is changed U-Protocol usage is changed
V-Link is involved N-Link is a new path
S-Link is IGP Shortcut *-Relative cost

----------------------------------
SpfNode NodeFlags NeighbourNode LinkCost LinkFlags

------------------------------------------------------------------------
>0000.0000.0001.00 T/-/-/- 0000.0000.0003.01 10 C/-/-/-/-/-/-
0000.0000.0002.01 -/-/-/- 0000.0000.0002.00 0 -/-/-/-/-/-/-
>0000.0000.0001.00 0 -/-/-/-/-/-/-
0000.0000.0002.02 -/-/-/- 0000.0000.0002.00 0 -/-/-/-/-/-/-
0000.0000.0004.00 0 -/-/-/-/-/-/-
0000.0000.0003.00 T/-/-/- 0000.0000.0003.02 10 C/-/-/-/-/-/-
0000.0000.0003.01 10 P/-/-/-/-/-/-
0000.0000.0003.01 T/R/-/- 0000.0000.0003.00 0 C/-/-/-/-/-/-
>0000.0000.0001.00 0 P/-/-/-/-/-/-
0000.0000.0003.02 T/-/-/- 0000.0000.0003.00 0 P/-/-/-/-/-/-
0000.0000.0004.00 0 C/-/-/-/-/-/-
0000.0000.0004.00 T/-/-/- 0000.0000.0003.02 10 P/-/-/-/-/-/-

With IPv6 IS-IS Auto FRR, traffic on a faulty link can be quickly switched to the backup link
of the faulty link. This ensures that the traffic interruption time is within 50 ms and improves
the reliability of IS-IS networks.

Before configuring IPv6 IS-IS Auto FRR, familiarize yourself with the usage scenario, complete
As the network keeps developing, services such as Voice over IP (VoIP) and on-line video
services require high-quality real-time transmission. Nevertheless, if an IS-IS fault occurs, traffic
can be switched to a new link only after the following processes: fault detection, LSP update,
LSP flooding, route calculation, and FIB entry delivery. As a result, traffic is interrupted for
much more than 50 ms, which cannot meet the requirement for real-time services on the network.
With IPv6 IS-IS Auto FRR, devices can rapidly switch traffic from faulty links to backup links
without interrupting the traffic. This protects traffic and greatly improves the reliability of IS-
IS networks. The NE80E/40E supports IPv4 IS-IS Auto FRR.
IPv6 IS-IS Auto FRR is applicable to the services that are very sensitive to packet delay and
packet loss.

As shown in Figure 7-3, the link cost satisfies the traffic protection inequality, namely,
Distance_opt(B, D) < Distance_opt(B, A) + Distance_opt(A, D). In this inequality, Distance_opt
(X, Y) specifies the shortest path from node X to node Y. After IPv6 IS-IS Auto FRR is
configured, when the link between Router A and Router C becomes faulty, traffic forwarded by
Router A is rapidly switched to the backup link.
Figure 7-3 Networking diagram for IPv6 IS-IS Auto FRR (IP protecting IP)
RouterC
10 IS
-IS
=
st co
co st
-IS =
IS 10
RouterA RouterD
10
IS
-IS
=
st
co
co
st
-IS
=
IS
30
RouterB
Traffic in normal
Traffic in case of failure
Before configuring IPv6 IS-IS Auto FRR, complete the following tasks:
the network layer
l Configuring IPv6 IS-IS.
l Setting costs for links to ensure that the primary link is the optimal path and the backup
link is the sub-optimal path.
Data Preparation
To configure IPv6 IS-IS Auto FRR, you need the following data.
No. Data
1 IS-IS process ID
2 Interface to be enabled with IPv6 IS-IS Auto FRR

7.19.2 Enabling IPv6 IS-IS Auto FRR

If IPv6 IS-IS Auto FRR is enabled and the traffic protection inequality is satisfied, a backup
route can be generated.
Context
Perform the following steps on the router where traffic to be forwarded needs to be protected:
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
The IS-IS process is enabled and the IS-IS view is displayed.
Step 3 Run:
ipv6 frr
The IPv6 IS-IS FRR view is displayed.
Step 4 Run:
loop-free-alternate [ level-1 | level-2 | level-1-2 ]
IPv6 IS-IS Auto FRR is enabled to generate a loop-free backup link.
If no level is specified, IPv6 IS-IS Auto FRR is enabled in Level-1 and Level-2 areas to generate
backup routes.
For details of IS-IS Auto FRR, see the HUAWEI NetEngine80E/40E Router Feature Description
- IP Routing.
NOTE
IS-IS can generate loop-free backup routes only when the traffic protection inequality of IS-IS Auto FRR
is satisfied.
----End
7.19.3 (Optional) Disabling an Interface from Participating in IPv6

LFA Calculation
To facilitate network management and fault location, you can prevent certain interfaces from
participating in the LFA calculation and specify the interfaces that can function as backup
outbound interfaces.
Context
To disable an interface that is enabled with IPv6 IS-IS from participating in the Loop-Free
Alternate (LFA) calculation, you need to perform the following steps on this interface:

Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
undo isis ipv6 lfa-backup
The interface is disabled from participating in the LFA calculation.
NOTE
By default, an IS-IS interface participates in LFA calculation.
----End

After IPv6 IS-IS Auto FRR is configured, you can check backup route information and traffic
protection types of IS-IS.
Prerequisites
IPv6 IS-IS Auto FRR has been configured.
Procedure
[ verbose | [ level-1 | level-2 ] | ipv6-address [ prefix-length ] ] * command to check
information about the primary and backup links after IPv6 IS-IS Auto FRR is enabled.
ipv6 | verbose ] * [ process-id | vpn-instance vpn-instance-name ] command to check the
traffic protection type of IPv6 IS-IS Auto FRR.
----End
Example
Run the display isis route command, and you can view information about the outbound interface
and next hop of the backup route. The configuration result is as follows:
<HUAWEI> display isis route ipv6 3::3 verbose

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

----------------------------------
IPV6 Dest : 3::3/128 Cost : 10 Flags: A/L/-

Admin Tag : - Src Count : 1 Priority: Medium


FE80::163 GE0/0/1 0x00000005
(B)FE80::536 GE0/0/0 0x00000007

U-Up/Down Bit Set

----------------------------------
IPV6 Dest : 3::3/128 Cost : 10 Flags: -/-/-

Admin Tag : - Src Count : 2 Priority: Medium

U-Up/Down Bit Set
Run the display isis spf-tree command, and you can view the traffic protection type of a specified
device. The configuration result is as follows:
<HUAWEI> display isis spf-tree systemid 0000.0000.0004 verbose ipv6

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

------------------------------------
0000.0000.0004.00
Distance : 10
Distance-URT : 10
Flags : SPT/Direct
(1) 30.0.0.3 IF:GE0/0/1 NBR:0000.0000.0004.00
(2) 50.0.0.2 IF:Pos0/0/0 NBR:0000.0000.0004.00
IPv6 Nexthops : 2
(1) FE80::163 IF:GE0/0/1 NBR:0000.0000.0004.00
(B) FE80::536 IF:Pos0/0/0 NBR:0000.0000.0004.00
TYPE:PRIMARY PROTECT:LINK
(2) FE80::536 IF:Pos0/0/0 NBR:0000.0000.0004.00
(B) FE80::163 IF:GE0/0/1 NBR:0000.0000.0004.00
(1) 0000.0000.0004.02
Cost : 10
Flags : Child
(2) >0000.0000.0001.02
Cost : 10
Flags : Parent
(3) >0000.0000.0001.00
Cost : 10
Flags : Parent

------------------------------------
0000.0000.0004.00
Distance : 10
Distance-URT : 10
Flags : SPT/Direct
(1) 30.0.0.3 IF:GE0/0/1 NBR:0000.0000.0004.00
(2) 50.0.0.2 IF:Pos0/0/0 NBR:0000.0000.0004.00

IPv6 Nexthops : 2
(1) FE80::163 IF:GE0/0/1 NBR:0000.0000.0004.00
(B) FE80::536 IF:Pos0/0/0 NBR:0000.0000.0004.00
(2) FE80::536 IF:Pos0/0/0 NBR:0000.0000.0004.00
(B) FE80::163 IF:GE0/0/1 NBR:0000.0000.0004.00
(1) >0000.0000.0001.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.02
Cost : 10
Flags : Child
(3) >0000.0000.0001.00
Cost : 10
Flags : Parent

By configuring local MT, you can enable multicast packets to be forwarded through TE tunnels
on IS-IS networks.

Before configuring IS-IS local MT, familiarize yourself with the usage scenario, complete the
If multicast and an MPLS TE tunnel are deployed in a network, multicast packets may be
forwarded through the TE tunnel. As a result, the routers spanned by the TE tunnel cannot detect
the transmission of multicast packets, and therefore the routers cannot create any multicast
forwarding entry. You can configure local MT function and enable IGP Shortcut on the TE
tunnel to avoid the preceding problem. In this manner, a correct MIGP routing table can be
created to guide the forwarding of multicast packets.
NOTE
Local MT can be configured only in the IS-IS process of the public network instance. In this case,
Forwarding Advertise cannot be configured.
Before configuring IS-IS local MT, complete the following tasks:
l Configuring IP addresses for interfaces to ensure network connectivity between

neighboring nodes
l Configuring Basic IS-IS Functions

Data Preparation
To configure local MT, you need the following data.
No. Data
1 Filtering list used to filter IS-IS routing information
7.20.2 Enabling Local MT

The nodes along the TE tunnel can detect multicast packets and create multicast forwarding
entries only after local MT is enabled.
Context
Perform the following steps on the router that needs to forward multicast packets and is
configured with the TE tunnel enabled with IGP-Shortcut:
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
cost-style { compatible [ relax-spf-limit ] | wide | wide-compatible }
The cost type is configured.
Step 4 Run:
traffic-eng
TE is configured.
Step 5 Run:
local-mt enable
Local MT is enabled.
----End
7.20.3 Controlling the Scale of the MIGP Routing Table

By configuring the filtering policy based on multicast source addresses, you can configure
routers to add only the routes destined to the specified multicast source address to the MIGP
routing table, therefore controlling the size of the MIGP routing table.

Context
After creating the MIGP routing table by Enabling Local MT, IS-IS performs route calculation.
When the outgoing interface of the next hop calculated is an interface of the TE tunnel enabled
with IGP Shortcut, a router uses the physical interface as the outgoing interface of the next hop
and saves it to the MIGP routing table.
To make the scale of the MIGP routing table reasonable and accelerate the speed for searching
the MIGP routing table, you can configure the filtering policy based on multicast source
addresses. Only the routes to multicast source addresses are added to the MIGP table.
NOTE
You can configure the routing policy before enabling local MT. This prevents the routes that are not sent
to the multicast source address from being added to the MIGP routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Run:
local-mt filter-policy { acl { acl-number | acl-name } | ip-prefix ip-prefix-name }
The local MT routing policy is configured.

1. Run local-mt filter-policy acl { acl-number | acl-name }, the local MT routing policy
is configured.
by the system.

1. Run local-mt filter-policy acl acl-name, the local MT routing policy is configured.
by the system.
l Based on the IP prefix: local-mt filter-policy ip-prefix ip-prefix-name
----End


After configuring local MT, you can check the MIGP routing table, routing information, SPF
tree, and IS-IS statistics.
Prerequisites
Local MT has been configured.
Procedure
l Run display isis [ process-id ] migp-routing [ ip-address [ mask | mask-length ] |
{ level-1 | level-2 } | verbose ] * command to check the IS-IS MIGP routing table.
l Run display isis route [ process-id | vpn-instance vpn-instance-name ] [ ipv4 ]
[ verbose | [ level-1 | level-2 ] | ip-address [ mask | mask-length ] ] * command to check the
IS-IS routing information.
l Run display isis [ process-id ] spf-tree statistics [ [ level-1 | level-2 ] | ipv6 ] * [ vpn-
instance vpn-instance-name ] command to check the SPF tree of IS-IS.
l Check the statistics of the IS-IS process.
– display isis statistics [ level-1 | level-2 | level-1-2 ] [ process-id | vpn-instance vpn-
instance-name ]
– display isis statistics packet [ interface interface-type interface-number ]
– display isis process-id statistics [ level-1 | level-2 | level-1-2 | packet ]
----End
Example
Configure the MIGP routing table to allow only the routes to the destination 192.168.3.0/24 to
pass. Run the display isis migp-routing command. The display is as follows:
<HUAWEI> display isis migp-routing
MIGP Route information for ISIS(1)
----------------------------------
--------------------------------
--------------------------------------------------------------------------------
192.168.3.0/24 40 NULL GE2/0/0 10.0.1.1 A/-
Flags: A-Added to MIGP, U-Up/Down Bit Set
7.21 Configuring IS-IS GR

By configuring IS-IS GR, you can enable Router to restart gracefully and avoid temporary black
holes.

Before configuring IS-IS GR, familiarize yourself with the usage scenario, complete the pre-
configuration tasks, and obtain the required data. This can help you complete the configuration
task quickly and accurately.

The restart of an IS-IS router causes the temporary interruption of the network, because the
adjacency relationship between the router and its neighbor is torn down. The LSPs packets of
the router are deleted, which makes route calculation inaccurate. Packets are therefore lost.
You can configure IS-IS GR to solve this problem. After IS-IS GR is enabled, the router notifies
the neighbor of the restart status, and reestablishes the adjacency relationship with its neighbor
without interrupting the forwarding.
The advantages of IS-IS GR are as follows:
l When IS-IS restarts, the router can resend connection requests to its neighbor. The
adjacency relationship is not torn down.
l Before LSPs packets are generated, GR minimizes the interference caused by waiting for
the database synchronization.
l If the router starts for the first time, the router sets the overload bit in LSPs until the LSDB
synchronization is complete. This avoids route black holes.
Before configuring IS-IS GR, complete the following tasks:
l Configuring IP addresses for interfaces to ensure network connectivity between

neighboring nodes.
l Configuring Basic IS-IS Functions
Data Preparation
To configure IS-IS GR, you need the following data.
No. Data
1 ID of an IS-IS process
2 Interval for reestablishing GR sessions
3 Whether to suppress the advertisement of the adjacency when the GR restarter restarts
7.21.2 Enabling IS-IS GR

Before configuring IS-IS GR, you need to enable the GR capability for IS-IS.
Context
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.
----End
7.21.3 Configuring Parameters of an IS-IS GR Session

By setting Intermediate System to Intermediate System (IS-IS) graceful restart (GR) parameters,
you can avoid temporary black holes on the network.
Context
The router that starts for the first time does not maintain the forwarding status. If the router
restarts, the LSPs generated when the router runs last time may exist in the link state database
(LSDB) of other routers in the network.
The sequence number of an LSP fragment is reinitialized when the router starts. Therefore, the
router considers that the previously advertised LSP stored on other routers is newer than the LSP
generated locally after the router starts. This leads to the temporary black hole in the network,
which lasts until the normal LSDB synchronization process finishes. The router then regenerates
its LSPs and advertises the LSPs with the highest sequence number.
When this router starts, if the neighbor of the router suppresses the advertisement of the
adjacency until this router advertises the updated LSPs, the preceding case can therefore be
avoided.
Perform the following steps on the router that runs IS-IS:
Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 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 t2-interval interval-value
A value is configured for the T2 timer during the IS-IS GR.
The value of the T2 timer indicates the longest time during which the system waits for the LSDB
synchronization. Each Level-1 or Level-2 router maintains a T2 timer and disables it after the
LSDB synchronization among Level-1 or Level-2 routers ends. If LSDBs are not synchronized
yet when the T2 timer expires, the GR fails.
By default, the value of the T2 timer is 60 seconds. Keeping the default value is recommended.

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.
The SA bit determines whether a neighbor (GR helper) advertises the neighbor relationship with
the restarter. The helper suppresses the advertisement of the neighbor relationship with the
restarter until the helper receives a packet in which SA is set to 0. By default, the SA bit is not
suppressed.
----End

After configuring IS-IS GR, you can check the IS-IS GR status and parameters.
Prerequisites
IS-IS GR has been configured.
Procedure
Step 1 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.
----End

Example
Run the display isis graceful-restart status command, and you can find that IS-IS process 1
on the local router is enabled with GR and the default values of all GR parameters are used.
<HUAWEI> display isis graceful-restart status
Restart information for ISIS(1)
-------------------------------
IS-IS(1) Level-1 Restart Status
Restart Interval: 300
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTART COMPLETE
IS-IS(1) Level-2 Restart Status
Restart Interval: 300
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTART COMPLETE
7.22 Improving Security of an IS-IS Network

On a network that requires high security, you can configure IS-IS authentication or optional
checksum to improve the security of the IS-IS network.

Before configuring authentication or optional checksum on an Intermediate System to
Intermediate System (IS-IS) network, familiarize yourself with the usage scenario, complete the
In a network that has a high requirement for security, you can configure IS-IS authentication or
optional checksum to improve security of the IS-IS network.
l IS-IS authentication encapsulates authentication information into Hello packets, Link State
Protocol Data Units (LSPs), and Sequence Number Protocol Data Units (SNPs). After an
IS-IS device receives the packets, it checks whether the encapsulated authentication
information is correct. The IS-IS device only accepts the packets with correct authentication
information. The authentication mechanism enhances IS-IS network security. IS-IS
authentication consists of area authentication, routing domain authentication, and interface
authentication.
IS-IS authentication ensures that the data is correctly transmitted at the network layer.
l IS-IS optional checksum encapsulates checksum Type-Length-Values (TLVs) into SNPs
and Hello packets. After an IS-IS device receives the packets, it checks whether the
checksum TLVs are correct. The IS-IS device only accepts the packets with correct
checksum TLVs. The authentication mechanism enhances IS-IS network security.
IS-IS optional checksum ensures that the data is correctly transmitted at the link layer.
Before configuring IS-IS authentication, complete the following tasks:

l Configure IP addresses of interfaces to make neighboring nodes reachable.

l Configure basic IS-IS functions.
Data Preparation
To configure IS-IS authentication, you need the following data.
No. Data
1 Authentication mode and password used in the authentication
7.22.2 Configuring IS-IS Authentication

After Intermediate System to Intermediate System (IS-IS) authentication is configured,
authentication information can be encapsulated into Link State Protocol Data Units (LSPs) and
Sequence Number Protocol Data Units (SNPs) to ensure the packet transmission security. By
default, authentication is not configured for IS-IS. Configuring authentication is recommended
to ensure system security.
Context
By default, sent IS-IS packets are not encapsulated with authentication information, and received
packets are not authenticated. In order to avoid malicious text attack network, configuring IS-
IS authentication helps to improve the network security. Three IS-IS authentication modes and
the usage scenarios are as follows:
l Area authentication: Authentication passwords are encapsulated into IS-IS packets in
Level-1 areas. The receiver only accepts the packets that have been authenticated.
Therefore, you need to configure IS-IS area authentication to authenticate packets in
Level-1 areas.
l Routing domain authentication: Authentication passwords are encapsulated into IS-IS
packets in Level-2 areas. The receiver only accepts the packets that have been authenticated.
Therefore, you need to configure IS-IS routing domain authentication to authenticate
packets in Level-2 areas.
l Interface authentication: The authentication information is encapsulated into IS-IS Hello
packets. The neighboring can establish a neighbor relationship with the local router after
IS-IS Hello packets can be authenticated. Therefore, you need to configure interface
authentication to ensure validity and correctness of neighbor relationships.
NOTE
In configuring IS-IS authentication, the authentication modes and passwords of all devices in the same area
or routing domain must be consistent. Otherwise, IS-IS packets cannot be normally flooded.
An IS-IS neighbor relationship cannot be established if interface authentication fails. An IS-IS neighbor
relationship can be established regardless of whether IS-IS area or routing domain authentication succeeds.
When configuring an authentication password, select the ciphertext mode becasue the password is saved
in configuration files in plaintext if you select plaintext mode, which has a high risk. To ensure device
security, change the password periodically.

Procedure
l Configure IS-IS area authentication.
1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
area-authentication-mode { simple { [ plain ] plain-text | cipher plain-
cipher-text } | md5 { [ cipher ] plain-cipher-text | plain plain-text } }
[ ip | osi ] [ snp-packet { authentication-avoid | send-only } | all-send-
only ]
or
area-authentication-mode keychain keychain-name [ snp-packet
{ authentication-avoid | send-only } | all-send-only ]
or
area-authentication-mode hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] plain-cipher-text } [ snp-packet { authentication-avoid | send-
only } | all-send-only ]
The area authentication mode is configured.
NOTICE
After the area-authentication-mode command is run, IS-IS does not process the
Level-1 LSPs in the local LSDB that fail to be authenticated or new Level-1 LSPs and
SNPs that fail to be authenticated but discards them after they age.
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.
IS-IS authentication involves the following situations:

– Authentication information is encapsulated in the sent LSPs and SNPs. The
received LSPs and SNPs should pass the authentication, and the ones that do not
pass the authentication are discarded. In this case, snp-packet or all-send-only is
inapplicable.
– Authentication information is encapsulated in the sent LSPs and received LSPs are
checked; however, authentication information is not encapsulated in the sent SNPs
and the received SNPs are not checked. In this case, snp-packet authentication-
avoid needs to be configured.
received LSPs are checked and the received SNPs are not checked. In this case,
snp-packet send-only needs to be configured.
– Authentication information is encapsulated in the sent LSPs and SNPs and the
received LSPs and SNPs are not checked. In this case, all-send-only needs to be
configured.

l Configure IS-IS routing domain authentication.

1. Run:
system-view

2. Run:
isis [ process-id ]

3. Run:
domain-authentication-mode { simple { [ plain ] plain-text | cipher plain-
[ ip | osi ] [ snp-packet { authentication-avoid | send-only } | all-send-
only ]
or
domain-authentication-mode keychain keychain-name [ snp-packet
{ authentication-avoid | send-only } | all-send-only ]
or
domain-authentication-mode hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] plain-cipher-text } [ snp-packet { authentication-avoid | send-
only } | all-send-only ]
The routing domain authentication mode is configured.
NOTICE
After the domain-authentication-mode command is run, IS-IS does not process the
Level-2 LSPs in the local LSDB that fail to be authenticated or new Level-2 LSPs and
SNPs that fail to be authenticated but discards them after they age.
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.
IS-IS authentication involves the following situations:

received LSPs and SNPs should pass the authentication, and the ones that do not
pass the authentication are discarded. In this case, snp-packet or all-send-only is
inapplicable.
– Authentication information is encapsulated in the sent LSPs and received LSPs are
checked; however, authentication information is not encapsulated in the sent SNPs
and the received SNPs are not checked. In this case, snp-packet authentication-
avoid needs to be configured.
received LSPs are checked and the received SNPs are not checked. In this case,
snp-packet send-only needs to be configured.
– Authentication information is encapsulated in the sent LSPs and SNPs and the
received LSPs and SNPs are not checked. In this case, all-send-only needs to be
configured.
l Configure IS-IS interface authentication.

1. Run:
system-view

2. Run:

3. Run:
isis authentication-mode { simple { [ plain ] plain-text | cipher plain-
[ Level-1 areas | level-2 ] [ ip | osi ] [ send-only ]
Or
isis authentication-mode keychain keychain-name [ Level-1 areas |
level-2 ] [ send-only ]
or
isis authentication-mode hmac-sha256 key-id key-id { plain plain-text |
[ cipher ] plain-cipher-text } [ level-1 | level-2 ] [ send-only ]
The IS-IS authentication mode and password are configured on the interface.
When you select parameters, note the following rules:

– If send-only is specified correctly, the router only encapsulates the sent Hello
packets with authentication information rather than checks whether the received
Hello packets pass authentication. The neighbor relationships can be set up when
the authentication is not necessary or packets pass the authentication.
– If send-only is not configured, ensure that passwords of all interfaces with the
same level in the same network are consistent.
– Level-1 areas and level-2 can be set only on Ethernet interfaces.
– When IS-IS interfaces are Level-1-2 interfaces and Level-1 areas or level-2 is not
specified in the command, authentication modes and passwords are configured for
both Level-1 areas and Level-2 Hello packets.
NOTE
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.
----End
7.22.3 Configuring the Optional Checksum

The optional checksum encapsulates optional checksum Type-Length-Values (TLVs) into
Sequence Number Protocol Data Units (SNPs) and Hello packets to ensure packet correctness,
improving network security.
Context
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 devices. 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 devices send Hello packets and SNP packets carrying no checksum TLVs and
verify the checksum of the received packets.
----End

By configuring various IS-IS authentication modes, you can improve the security of the IS-IS
network.
Prerequisites
Improving Security of an IS-IS Network has been configured.
Procedure
Step 1 Run display isis peer [ verbose ] [ process-id | vpn-instance vpn-instance-name ] command to
check information about the IS-IS neighbor.
----End
Example
On GE2/0/0, set the interface authentication mode to simple and password to 123. Neighbor
relationship can be established when authentication information on the two routers is consistent.
Run the display isis 1 peer verbose command. The display is as follows:
<HUAWEI> display isis peer 1 verbose
---------------------------------------------------------------------------------
0000.0000.0040 GE2/0/0 0000.0000.0040.04 Up 7s L1(L1L2) 64
Area Address(es) :10
Peer IP Address(es): 12.40.41.1
Uptime : 00:01:08
Adj Protocol : IPV4
Restart Capable : Yes
Suppressed Adj : NO
MT IDs supported : 0(UP)
Peer System Id : 0000.0000.0040

0000.0000.0040 GE2/0/0 0000.0000.0040.04 Up 8s L2(L1L2) 64

Area Address(es) :10
Peer IP Address(es): 12.40.41.1
Uptime : 00:01:14
Adj Protocol : IPV4
Restart Capable : Yes
Suppressed Adj : NO
Peer System Id : 0000.0000.0040
Total Peer(s): 2
7.23 Maintaining IS-IS

Maintaining IS-IS involves resetting IS-IS and clearing IS-IS statistics.
7.23.1 Resetting IS-IS Data Structure

By restarting IS-IS, you can reset IS-IS. You can also reset IS-IS in GR mode.
Context
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.
To clear the IS-IS data structure, run the following reset command in the user view.
Procedure
Step 1 Run reset isis all [ [ process-id | vpn-instance vpn-instance-name ] | graceful-restart ] *
command to reset the IS-IS data structure.
By default, the IS-IS data structure is not reset.
----End
7.23.2 Resetting a Specific IS-IS Neighbor

By restarting IS-IS neighbors, you can reset the IS-IS neighbor relationship, and therefore make
the new configuration take effect.
Context
NOTICE
The specified IS-IS neighbor relationship is deleted after you reset a specified IS-IS neighbor
by using the reset isis peer command. Exercise caution when running this command.

After the IS-IS routing policy or the protocol changes, you can reset a specific IS-IS neighbor
to validate the new configuration.
To reset a specific IS-IS neighbor, run the following reset command in the user view.
Procedure
Step 1 Run reset isis peer system-id [ process-id | vpn-instance vpn-instance-name ] command to reset
a specific IS-IS neighbor.
----End

This section provides several configuration examples of IS-IS. The configuration examples
explain networking requirements, configuration notes, and configuration roadmap.
NOTE
7.24.1 Example for Configuring Basic IS-IS Functions

This part provides an example for interconnecting IPv4 networks through IS-IS.
l Router A, Router B, Router C, and Router D belong to the same AS. IS-IS is enabled on
the routers to implement interconnection in the IP network.
l The area addresses of Router A, Router B, and Router C are all 10, and the area address of
Router D is 20.
l Router A and Router B are Level-1 routers, Router C is a Level-1-2 router. Router D is a
Level-2 router.
Figure 7-4 Networking diagram for configuring basic IS-IS functions
IS-IS
Area10 IS-IS
Area20
RouterA
L1 POS1/0/0 POS3/0/0 POS1/0/0 GE2/0/0
10.1.1.1/24 192.168.0.1/24 192.168.0.2/24 172.16.1.1/16
172.16.0.0/16
POS1/0/0 RouterC
10.1.1.2/24 POS2/0/0 RouterD
L1/2
10.1.2.1/24 L2
POS1/0/0
RouterB 10.1.2.2/24
L1

1. Enable IS-IS on each router, configure the levels of routers, and specify an NET.
2. Set RouterA and RouterC to authenticate Hello packets in specified mode and with the
specified password.
3. Check the IS-IS database and the routing table of each router.
Data Preparation
l Area addresses of Router A, Router B, Router C and Router D

l Levels of Router A, Router B, Router C, and Router D
Procedure
This example assumes that you know the configuration method and no details are provided here,
for detailed configurations, see configuration files in this example.
Step 2 Configure basic IS-IS functions.
[RouterA] isis 1
[RouterA-isis-1] is-level level-1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA] interface Pos 1/0/0
[RouterA-Pos1/0/0] isis enable 1
[RouterB] isis 1
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB-Pos1/0/0] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC-Pos1/0/0] isis enable 1

[RouterD] isis 1
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] network-entity 20.0000.0000.0004.00
[RouterD-isis-1] quit
[RouterD] interface gigabitethernet 2/0/0
[RouterD-GigabitEthernet2/0/0] isis enable 1
[RouterD] interface Pos 1/0/0
[RouterD-Pos1/0/0] isis enable 1
Step 3 Configure the authentication mode and password for RouterA and RouterC to authenticate Hello
packets.
[RouterA-Pos1/0/0] isis authentication-mode md5 huawei
# Configure RouterC.
[RouterC-Pos1/0/0] isis authentication-mode md5 huawei
# Display the IS-IS LSDB of each router.

[RouterA] display isis lsdb
--------------------------------
-------------------------------------------------------------------------
0000.0000.0001.00-00* 0x00000006 0xbf7d 649 68 0/0/0
0000.0000.0002.00-00 0x00000003 0xef4d 545 68 0/0/0
0000.0000.0003.00-00 0x00000008 0x3340 582 111 1/0/0
Total LSP(s): 3
[RouterB] display isis lsdb
--------------------------------
-------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000006 0xbf7d 642 68 0/0/0
0000.0000.0002.00-00* 0x00000003 0xef4d 538 68 0/0/0
0000.0000.0003.00-00 0x00000008 0x3340 574 111 1/0/0
Total LSP(s): 3
[RouterC] display isis lsdb
--------------------------------
-------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000006 0xbf7d 638 68 0/0/0
0000.0000.0002.00-00 0x00000003 0xef4d 533 68 0/0/0
0000.0000.0003.00-00* 0x00000008 0x3340 569 111 1/0/0
Total LSP(s): 3


-------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000008 0x55bb 650 100 0/0/0
0000.0000.0004.00-00 0x00000005 0x6510 629 84 0/0/0
Total LSP(s): 2
[RouterD] display isis lsdb
--------------------------------
-------------------------------------------------------------------------
0000.0000.0003.00-00 0x00000008 0x55bb 644 100 0/0/0
0000.0000.0004.00-00* 0x00000005 0x6510 624 84 0/0/0
Total LSP(s): 2
# Display the IS-IS routing information of each router. A default route must exist in the Level-1
routing table and the next hop is a Level-1-2 router. A Level-2 router must have all Level-1 and
Level-2 routes.
[RouterA] display isis route
-----------------------------
--------------------------------
-------------------------------------------------------------------------
10.1.1.0/24 10 NULL P1/0/0 Direct D/-/L/-
10.1.2.0/24 20 NULL P1/0/0 10.1.1.1 A/-/-/-
192.168.0.0/24 20 NULL P1/0/0 10.1.1.1 A/-/-/-
0.0.0.0/0 10 NULL P1/0/0 10.1.1.1 A/-/-/-
U-Up/Down Bit Set
[RouterC] display isis route
-----------------------------
--------------------------------
-------------------------------------------------------------------------
10.1.1.0/24 10 NULL P1/0/0 Direct D/-/L/-
10.1.2.0/24 10 NULL P2/0/0 Direct D/-/L/-
192.168.0.0/24 10 NULL P3/0/0 Direct D/-/L/-
U-Up/Down Bit Set
--------------------------------
-------------------------------------------------------------------------
10.1.1.0/24 10 NULL P1/0/0 Direct D/-/L/-
10.1.2.0/24 10 NULL P2/0/0 Direct D/-/L/-
192.168.0.0/24 10 NULL P3/0/0 Direct D/-/L/-
172.16.0.0/16 20 NULL P3/0/0 192.168.0.2 A/-/-/-
U-Up/Down Bit Set
[RouterD] display isis route
-----------------------------
--------------------------------
-------------------------------------------------------------------------

192.168.0.0/24 10 NULL P1/0/0 Direct D/-/L/-

10.1.1.0/24 20 NULL P1/0/0 192.168.0.1 A/-/-/-
10.1.2.0/24 20 NULL P1/0/0 192.168.0.1 A/-/-/-
172.16.0.0/16 10 NULL GE2/0/0 Direct D/-/L/-
U-Up/Down Bit Set
----End
Configuration Files
#
sysname RouterA
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
isis enable 1
isis authentication-mode md5 N`C55QK<`=/Q=^Q`MAF4<1!!
#
return

#
sysname RouterB
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
network-entity 10.0000.0000.0003.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis authentication-mode md5 N`C55QK<`=/Q=^Q`MAF4<1!!
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
interface Pos3/0/0
link-protocol ppp
ip address 192.168.0.1 255.255.255.0
isis enable 1
#

return

#
sysname RouterD
#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
ip address 172.16.1.1 255.255.0.0
isis enable 1
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.0.2 255.255.255.0
isis enable 1
#
return
7.24.2 Example for Configuring IS-IS in an NBMA Network

This part provides an example for interconnecting ATM networks through IS-IS.
l Router A, Router B, and Router C are connected through ATM links. IS-IS runs on the
three routers.
l Router A and Router B belong to area 10. Router C belongs to area 20.
l Router A is a Level-1 device, Router B is a Level-1-2 device, and Router C is a Level-2
device.
Figure 7-5 Diagram of configuring IS-IS in an NBMA network
RouterA RouterB RouterC

L1 ATM1/0/0.1 L1/L2 ATM2/0/0.1 L2
10.1.1.2/24 10.1.2.2/24
ATM1/0/0.1 ATM2/0/0.1
10.1.1.1/24 10.1.2.1/24 Area 20
Area 10
1. Set the type of the sub-interface to P2P when creating an ATM sub-interface, because IS-
IS does not support the NBMA network.

2. Enable IS-IS on each router, configure the level, and specify an NET.
Data Preparation
l Area addresses of Router A, Router B, and Router C

l Levels of Router A, Router B, and Router C
Procedure
Step 1 Configure an ATM network.
[RouterA] interface atm 1/0/0.1 p2p
[RouterA-Atm1/0/0.1] ip address 10.1.1.1 24
[RouterA-Atm1/0/0.1] pvc 2/2
[RouterA-atm-pvc-Atm1/0/0.1-2/2] map ip 10.1.1.2 broadcast
[RouterA-atm-pvc-Atm1/0/0.1-2/2] quit
[RouterA-Atm1/0/0.1] quit
[RouterB] interface atm 1/0/0.1 p2p
[RouterB-Atm1/0/0.1] ip address 10.1.1.2 24
[RouterB-Atm1/0/0.1] pvc 2/2
[RouterB-atm-pvc-Atm1/0/0.1-2/2] map ip 10.1.1.1 broadcast
[RouterB-atm-pvc-Atm1/0/0.1-2/2] quit
[RouterB-Atm1/0/0.1] quit
[RouterB-Atm2/0/0.1] ip address 10.1.2.1 24
[RouterB-Atm2/0/0.1] pvc 2/2
[RouterB-atm-pvc-Atm2/0/0.1-2/2] map ip 10.1.2.2 broadcast
[RouterB-atm-pvc-Atm2/0/0.1-2/2] quit
[RouterC] interface atm 2/0/0.1 p2p
[RouterC-Atm2/0/0.1] ip address 10.1.2.2 24
[RouterC-Atm2/0/0.1] pvc 2/2
[RouterC-atm-pvc-Atm2/0/0.1-2/2] map ip 10.1.2.1 broadcast
[RouterC-atm-pvc-Atm2/0/0.1-2/2] quit
[RouterC-Atm2/0/0.1] quit
[RouterA] isis 1
[RouterA] interface atm 1/0/0.1 p2p
[RouterA-Atm1/0/0.1] isis enable 1
[RouterA-Atm1/0/0.1] quit
[RouterB] isis 1

[RouterB-Atm1/0/0.1] isis enable 1

[RouterB-Atm2/0/0.1] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] is-level level-2
[RouterC] interface atm 2/0/0.1 p2p
[RouterC-Atm2/0/0.1] isis enable 1
[RouterC-Atm2/0/0.1] quit
# Display the IS-IS routing table of each router.

-----------------------------
--------------------------------
-------------------------------------------------------------------------
0.0.0.0/0 10 NULL Atm1/0/0.1 10.1.1.2 A/-/L/-
10.1.1.0/24 10 NULL Atm1/0/0.1 Direct D/-/L/-
10.1.2.0/24 20 NULL Atm1/0/0.1 10.1.1.2 A/-/L/-
U-Up/Down Bit Set
[RouterB] display isis route
-----------------------------
--------------------------------
-------------------------------------------------------------------------
U-Up/Down Bit Set
--------------------------------
-------------------------------------------------------------------------
U-Up/Down Bit Set
[RouterC] display isis route
-----------------------------
--------------------------------
-------------------------------------------------------------------------
10.1.1.0/24 20 NULL Atm2/0/0.1 10.1.2.1 A/-/L/-
U-Up/Down Bit Set
----End

Configuration Files
#
sysname RouterA
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
interface Atm1/0/0
#
interface Atm1/0/0.1 p2p
ip address 10.1.1.1 255.255.255.0
isis enable 1
pvc 2/2
map ip 10.1.1.2 broadcast
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
#
interface Atm1/0/0
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
pvc 2/2
#
interface Atm2/0/0
#
ip address 10.1.2.1 255.255.255.0
isis enable 1
pvc 2/2
#
return

#
sysname RouterC
#
isis 1
is-level level-2
network-entity 20.0000.0000.0003.00
#
interface Atm2/0/0
#
ip address 10.1.2.2 255.255.255.0
isis enable 1
pvc 2/2
#
return
7.24.3 Example for Configuring IS-IS Route Summarization

This section provides an example for configuring IS-IS route summarization.

Figure 7-6 shows a networking example.
l Router A, Router B, and Router C are configured with IS-IS to communicate.

l Router A belongs to area 20. Router B and Router C belong to area 10.
l Router A is a Level-2 device. Router B is a Level-1-2 device. Router C is a Level-1 device.
l Router B maintains both the Level-1 and Level-2 LSDBs. The routes to network segments
172.1.1.0/24, 172.1.2.0/24, and 172.1.3.0/24 in the Level-1 area can be leaked into the
Level-2 area. If the interface with the IP address 172.1.1.1/24 on Router C regularly
alternates between Up and Down states, LSPs in the Level-2 area will be frequently flooded
and Router A will often calculate routes using the SPF algorithm. This burdens the CPU
of Router A and may even cause route flapping on the network.
To solve this problem, configure Router B to summarize routes to the three network
segments into the route 172.1.0.0/16. This summarization reduces the number of routes to
be maintained by Router B and prevents interface-state alteration in the Level-1 area from
affecting router convergence in the Level-2 area.
Figure 7-6 Networking diagram for configuring IS-IS route summarization
Network1
GE2/0/0
172.1.1.0/24
172.1.1.1/24
RouterC RouterB RouterA

L1
GE3/0/0 GE1/0/0 L1/L2 GE2/0/0 L2
172.1.2.1/24 172.1.4.2/24 172.2.1.1/24
Network2
172.1.2.0/24 GE1/0/0 GE2/0/0
172.1.4.1/24 172.2.1.2/24
Area20
GE4/0/0 Area10
Network3 172.1.3.1/24
172.1.3.0/24
1. Enable IS-IS on each router, configure the levels, and specify network entities.
2. Check the IS-IS routing table of Router A.
3. Configure Router B to summarize routes.
Data Preparation


Procedure
Step 2 Configure basic IPv4 IS-IS functions.
[RouterA] isis 1
[RouterA-GigabitEthernet2/0/0] isis enable 1
[RouterB] isis 1
[RouterB-GigabitEthernet2/0/0] isis enable 1
[RouterC] isis 1
[RouterC] interface gigabitEthernet 1/0/0
[RouterC-GigabitEthernet1/0/0] isis enable 1
The configurations of GE 2/0/0, GE 3/0/0, and GE 4/0/0 are similar to those of GE 1/0/0.
Step 3 Run the display isis route command to display the IS-IS routing table of routerRouter A.
-----------------------------
--------------------------------
----------------------------------------------------------------------------
172.1.1.0/24 30 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.1.2.0/24 30 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.1.3.0/24 30 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.1.4.0/24 20 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.2.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
U-Up/Down Bit Set
Step 4 Configure route summarization on routerRouter B.

# Configure Router B to summarize the routes to network segments 172.1.1.0/24, 172.1.2.0/24,
172.1.3.0./24, and 172.1.4.0/24 into the route 172.1.0.0/16.
[RouterB] isis 1

[RouterB-isis-1] summary 172.1.0.0 255.255.0.0 level-1-2


# Run the display isis route command to display the routing table of Router A. The command
output shows that the summary route 172.1.0.0/16 has been generated.
-----------------------------
--------------------------------
----------------------------------------------------------------------------
172.1.0.0/16 20 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.2.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
U-Up/Down Bit Set
----End
Configuration Files
#
sysname RouterA
#
isis 1
is-level level-2
network-entity 20.0000.0000.0001.00
#
ip address 172.2.1.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
summary 172.1.0.0 255.255.0.0 level-1-2
#
ip address 172.2.1.2 255.255.255.0
isis enable 1
#
ip address 172.1.4.2 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
ip address 172.1.4.1 255.255.255.0

isis enable 1
#
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
ip address 172.1.2.1 255.255.255.0
isis enable 1
#
ip address 172.1.3.1 255.255.255.0
isis enable 1
#
return
7.24.4 Example for Configuring the DIS Election of IS-IS

This part provides an example for specifying the DIS on a broadcast network.
l Router A, Router B, Router C, and Router D run IS-IS to implement interconnection in the
network.
l The four routers belong to area 10, and the network type is broadcast (Ethernet).
l Router A and Router B are Level-1-2 routers, Router C is a Level-1 router, and Router D
is a Level-2 router.
l The DIS priority of RouterA is 100.
l You can change the DIS priority of the interface to configure Router A as a Level-1-2 DIS.
Figure 7-7 Configuring the DIS election of IS-IS

RouterA RouterB
L1/L2 L1/L2
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24
GE1/0/0 GE1/0/0
10.1.1.3/24 10.1.1.4/24
RouterC RouterD
L1 L2

1. Enable IS-IS on each router and specify the network entity to implement interconnection.
2. Check information about IS-IS interfaces on each router in the case of the default
preference.
3. Configure the DIS priority of each router.
Data Preparation
l Area addresses of routerA, routerB, routerC and routerD

l Levels of routerA, routerB, routerC and routerD
l DIS priority of RouterA
Procedure
Step 2 Check the MAC address of the GE interface on each router.
# Check the MAC address of GigabitEthernet 1/0/0 on Router A.

[RouterA] display arp interface gigabitethernet 1/0/0
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE VPN-INSTANCE
VLAN PVC
-------------------------------------------------------------------------
10.1.1.1 00e0-fc10-afec I GE1/0/0
-------------------------------------------------------------------------
Total:1 Dynamic:0 Static:0 Interface:1
# Check the MAC address of GigabitEthernet1/0/0 on Router B.

[RouterB] display arp interface gigabitethernet 1/0/0
VLAN PVC
-------------------------------------------------------------------------
10.1.1.2 00e0-fccd-acdf I GE1/0/0
-------------------------------------------------------------------------
# Check the MAC address of GigabitEthernet1/0/0 on Router C.

[RouterC] display arp interface gigabitethernet 1/0/0
VLAN PVC
-------------------------------------------------------------------------
10.1.1.3 00e0-f100-25fe I GE1/0/0
-------------------------------------------------------------------------
# Check the MAC address of GigabitEthernet1/0/0 on Router D.

[RouterD] display arp interface gigabitethernet 1/0/0
VLAN PVC
-------------------------------------------------------------------------
10.1.1.4 00e0-ff1d-305c I GE1/0/0
-------------------------------------------------------------------------

Step 3 Enable IS-IS.

[RouterA] isis 1
[RouterB] isis 1
[RouterC] isis 1
[RouterD] isis 1
# Display the IS-IS neighbors of Router A.

[RouterA] display isis peer
----------------------------
-----------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0002.01 Up 9s L1(L1L2) 64
0000.0000.0003 GE1/0/0 0000.0000.0002.01 Up 27s L1 64
0000.0000.0002 GE1/0/0 0000.0000.0004.01 Up 28s L2(L1L2) 64
0000.0000.0004 GE1/0/0 0000.0000.0004.01 Up 7s L2 64
Total Peer(s): 4
# Display the IS-IS interface of Router A.

[RouterA] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/No
# Display the IS-IS interface on Router B.

[RouterB] display isis interface
---------------------------------

GE1/0/0 001 Up Down 1497 L1/L2 Yes/No
# Display the IS-IS interface of Router D.

[RouterD] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/Yes
NOTE
When the default DIS priority is used, the MAC address of the interface on Router B is the largest one
among those of Level-1 routers. Router B is therefore the DIS of the Level-1 area. The MAC address of
interface on Router D is the largest one among those of Level-2 routers. Router D is the DIS of the Level-2
area. The Level-1 and Level-2 pseudo nodes are 0000.0000.0002.01 and 0000.0000.0004.01 respectively.
Step 4 Configure the DIS priority of Router A.

[RouterA-GigabitEthernet1/0/0] isis dis-priority 100
# Display the IS-IS neighbors of Router A.

----------------------------
-----------------------------------------------------------------------------
0000.0000.0002 GE1/0/0 0000.0000.0001.01 Up 21s L1(L1L2) 64
0000.0000.0003 GE1/0/0 0000.0000.0001.01 Up 27s L1 64
0000.0000.0002 GE1/0/0 0000.0000.0001.01 Up 28s L2(L1L2) 64
0000.0000.0004 GE1/0/0 0000.0000.0001.01 Up 30s L2 64
Total Peer(s): 4

# Display the IS-IS interface of Router A.
[RouterA] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 Yes/Yes
NOTE
After the DIS priority of the IS-IS interface changes, Router A becomes the DIS of the Level-1-2 area
instantly and its pseudo node is 0000.0000.0001.01.
# Display the IS-IS neighbors and IS-IS interfaces of Router B.

[RouterB] display isis peer
----------------------------
-----------------------------------------------------------------------------
0000.0000.0001 GE1/0/0 0000.0000.0001.01 Up 7s L1(L1L2) 100
0000.0000.0003 GE1/0/0 0000.0000.0001.01 Up 25s L1 64
0000.0000.0001 GE1/0/0 0000.0000.0001.01 Up 7s L2(L1L2) 100
0000.0000.0004 GE1/0/0 0000.0000.0001.01 Up 25s L2 64
Total Peer(s): 4
[RouterB] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/No

# Display the IS-IS neighbors and interfaces of Router D.

[RouterD] display isis peer
----------------------------
-----------------------------------------------------------------------------
0000.0000.0001 GE1/0/0 0000.0000.0001.01 Up 9s L2 100
0000.0000.0002 GE1/0/0 0000.0000.0001.01 Up 28s L2 64
Total Peer(s): 2
[RouterD] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2 No/No
----End
Configuration Files
#
sysname RouterA
#
isis 1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis dis-priority 100
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
ip address 10.1.1.3 255.255.255.0
isis enable 1
#
return

#
sysname RouterD
#

isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
#
ip address 10.1.1.4 255.255.255.0
isis enable 1
#
return
7.24.5 Example for Configuring IS-IS Load Balancing

This part provides an example for implementing load balancing through IS-IS.
l Router A, Router B, Router C, and Router D run IS-IS to implement interconnection in

the IP network.
l Router A, Router B, Router C, and Router D are Level-2 routers in area 10.
l Load balancing is required to transmit the traffic of Router A to Router D through Router
B and Router C.
Figure 7-8 Networking diagram of configuring IS-IS load balancing
Area10
POS1/0/0 POS2/0/0
RouterB
POS1/0/0 L2 POS1/0/0
GE3/0/0 GE3/0/0
POS2/0/0 POS2/0/0
RouterA RouterD
L2 L2
POS1/0/0 POS2/0/0
RouterC
L2
Router A GE 3/0/0 172.16.1.1/24 Router C POS 1/0/0 10.1.2.2/24
Router A POS 1/0/0 10.1.1.1/24 Router C POS 2/0/0 192.168.1.1/24
Router A POS 2/0/0 10.1.2.1/24 Router D GE 3/0/0 172.17.1.1/24
Router B POS 1/0/0 10.1.1.2/24 Router D POS 1/0/0 192.168.0.2/24
Router B POS 2/0/0 192.168.0.1/24 Router D POS 2/0/0 192.168.1.2/24

1. Enable basic IS-IS functions on each router to implement interconnection.

2. Cancel load balancing and check the routing table.
3. Configure load balancing on Router A and check the routing table of it.
4. (Optional) Configure the preference for equal-cost routes on Router A.
Data Preparation
l Levels and the area addresses of the four routers.

l Number of load balancing paths on Router A is 1.
l Preference value of equal-cost routes on Router C is 1.
Procedure
Step 1 Assign an IP address for each router.
For details about the configuration of basis IS-IS functions, see 7.24.1 Example for Configuring
Basic IS-IS Functions.
Step 3 Cancel load balancing on Router A.

[RouterA] isis 1
[RouterA-isis-1] maximum load-balancing 1

-----------------------------
--------------------------------
-------------------------------------------------------------------------
192.168.1.0/24 20 NULL P2/0/0 10.1.2.2 A/-/L/-
10.1.1.0/24 10 NULL P1/0/0 Direct D/-/L/-
172.16.1.0/24 10 NULL GE3/0/0 Direct D/-/L/-
172.17.1.0/24 30 NULL P1/0/0 10.1.1.2 A/-/L/-
10.1.2.0/24 10 NULL P2/0/0 Direct D/-/L/-
192.168.0.0/24 20 NULL P1/0/0 10.1.1.2 A/-/L/-
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, the next hop to network segment 172.17.1.0 is 10.1.1.2. This is because the system
ID of Router B is small. IS-IS chooses the route with the next hop being 10.1.1.2 as the unique
optimal route.
Step 4 Restore the default number of load balancing paths on Router A.

[RouterA] isis 1

[RouterA-isis-1] undo maximum load-balancing


-----------------------------
--------------------------------
-------------------------------------------------------------------------
192.168.1.0/24 20 NULL P2/0/0 10.1.2.2 A/-/L/-
10.1.1.0/24 10 NULL P1/0/0 Direct D/-/L/-
172.16.1.0/24 10 NULL GE3/0/0 Direct D/-/L/-
172.17.1.0/24 30 NULL P1/0/0 10.1.1.2 A/-/L/-
P2/0/0 10.1.2.2
10.1.2.0/24 10 NULL P2/0/0 Direct D/-/L/-
192.168.0.0/24 20 NULL P1/0/0 10.1.1.2 A/-/L/-
U-Up/Down Bit Set
As shown in the routing table, the default value is used when load balancing is canceled. The
two next hops of Router A, that is, 10.1.1.2 (that is, Router B) and 10.1.1.2 (that is, Router C),
are valid routes. This is because the default value of the maximum equal-cost routes is 3.
NOTE
For different products and different protocols, the maximum number of equal-cost routes is different. You
can adjust the maximum number by purchasing licenses.
Step 5 (Optional) Configure the preference of equal-cost routes on Router A.
If you do not perform load balancing through Router B and Router C, configure the preference
of the equal-cost routes and specify the next hop.
[RouterA] isis
[RouterA-isis-1] nexthop 10.1.2.2 weight 1

-----------------------------
--------------------------------
--------------------------------------------------------------------------------
192.168.1.0/24 20 NULL P2/0/0 10.1.2.2 A/-/L/-
10.1.1.0/24 10 NULL P1/0/0 Direct D/-/L/-
172.16.1.0/24 10 NULL GE3/0/0 Direct D/-/L/-
172.17.1.0/24 30 NULL P1/0/0 10.1.2.2 A/-/L/-
10.1.2.0/24 10 NULL P2/0/0 Direct D/-/L/-
192.168.0.0/24 20 NULL P1/0/0 10.1.1.2 A/-/L/-
U-Up/Down Bit Set
As shown in the routing table, because the preference (metric is 1) of next hop 10.1.2.2 (that is,
Router C) is higher than that of next hop 10.1.1.2 (that is, Router B), IS-IS chooses the route
with the next hop being 10.1.2.2 as the optimal route.
----End

Configuration Files
#
sysname RouterA
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
#
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterB
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface Pos2/0/0
link-protocol ppp
ip address 192.168.0.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
interface Pos2/0/0
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
isis enable 1
#
return


#
sysname RouterD
#
isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
#
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.0.2 255.255.255.0
isis enable 1
#
interface Pos2/0/0
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
isis enable 1
#
return
7.24.6 Example for Configuring IS-IS to Interact with BGP

This section provides an example for configuring IS-IS and BGP to import routes of each other,
including the networking requirements, configuration roadmap, configuration procedure, and
configuration files.
Figure 7-9 shows a networking example.
l Router A and Router B belong to the same AS, and the IS-IS neighbor relationship is
established between Router A and Router B. Router A is a non-BGP device in the AS.
l An EBGP connection is set up between Router B and Router C.
l IS-IS and BGP import routes of each other to implement interworking between devices in
the two ASs. A routing policy is configured to change the cost of a BGP route imported by
IS-IS so that a desired route will be selected.
Figure 7-9 Networking diagram for configuring IS-IS to interact with BGP
Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32
POS1/0/0 POS1/0/0 POS1/0/0
10.1.1.1/24 10.2.1.1/24 10.2.1.2/24
POS1/0/0
RouterA 10.1.1.2/24 RouterB RouterC
AS65009
AS65008

1. Enable IS-IS and specify network entities on Router A and Router B.

2. Set up an EBGP connection between Router B and Router C.
3. Configure IS-IS and BGP to import routes of each other on Router B. Then check routing
information in routing tables.
Data Preparation
l Area addresses of Router A and Router B

l Router ID and AS number of Router B
l Router ID and AS number of Router C
Procedure
[RouterA] isis 1
[RouterA-Pos1/0/0] isis enable 1
[RouterB] isis 1
[RouterB-Pos1/0/0] isis enable 1
Step 3 Set up an EBGP connection.
[RouterB] bgp 65008
[RouterB-bgp] ipv4-family unicast
[RouterB-bgp-af-ipv4] network 10.2.1.0 255.255.255.0
[RouterC] bgp 65009
[RouterC-bgp-af-ipv4] network 10.2.1.0 255.255.255.0
Step 4 Configure IS-IS to import BGP routes.

# Configure a static route on Router C.

[RouterC] ip route-static 3.3.3.3 32 NULL 0
# On Router C, configure BGP to import the static route.

[RouterC] bgp 65009
[RouterC-bgp] import-route static
# On Router B, configure IS-IS to import BGP routes.

[RouterB] isis 1
[RouterB-isis-1] import-route bgp
# Run the display ip routing-table command to display the routing table of Router A. The
command output shows that IS-IS has imported the BGP route 3.3.3.3/32.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0

10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
3.3.3.3/32 ISIS-L2 15 74 D 10.1.1.2 Pos1/0/0
# On Router B, configure the AS_Path filter, and apply the filter in the RTC routing policy.
[RouterB] ip as-path-filter 1 permit 65009
[RouterB] route-policy RTC permit node 0
[RouterB-route-policy] if-match as-path-filter 1
[RouterB-route-policy] apply cost 20
[RouterB-route-policy] quit
# On Router B, configure IS-IS to import BGP routes.

[RouterB] isis 1
[RouterB-isis-1] import-route bgp route-policy RTC
# Run the display ip routing-table command to display the routing table of Router A. The
command output shows that the AS_Path filter has been applied and the cost of the imported
BGP route 3.3.3.3/32 has been changed from 74 to 94.
------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Pos1/0/0

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
10.1.1.2/32 Direct 0 0 D 10.1.1.2 Pos1/0/0
3.3.3.3/32 ISIS-L2 15 94 D 10.1.1.2 Pos1/0/0

Step 5 Configure BGP to import IS-IS routes.

[RouterC] bgp 65009
[RouterC-bgp] import-route isis 1
[RouterC-bgp] quit
# Run the display ip routing-table command to display the routing table of Router C. The
command output shows that BGP has imported the IS-IS route 10.1.1.0/24.
------------------------------------------------------------------------------
10.1.1.0/24 EBGP 255 0 D 10.2.1.1 Pos1/0/0

10.2.1.0/24 Direct 0 0 D 10.2.1.2 Pos1/0/0
10.2.1.1/32 Direct 0 0 D 10.2.1.1 Pos1/0/0
3.3.3.3/32 Static 60 0 D 0.0.0.0 NULL0
----End
Configuration Files
#
sysname RouterA
#
isis 1
network-entity 10.0000.0000.0001.00
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
import-route bgp route-policy RTC
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
interface Pos2/0/0
link-protocol ppp
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 65008
router-id 1.1.1.1

#
ipv4-family unicast
network 10.2.1.0 255.255.255.0
#
route-policy RTC permit node 0
if-match as-path-filter 1
apply cost 20
#
ip as-path-filter 1 permit 65009
#
return

#
sysname RouterC
#
interface Pos1/0/0
link-protocol ppp
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
network 10.2.1.0 255.255.255.0
import-route static
import-route isis 1
#
#
return
7.24.7 Example for Configuring IS-IS MT

The following example shows how to implement network interconnection using IS-IS on a
network with an IPv4/IPv6 topology.
In real-world situations, an IPv4/IPv6 topology has a shortcoming. When various end-to-end
services, such as voice and data services share the same physical links, either IPv4 or IPv6
packets are discarded on the shablue links, affecting transmission quality. To address this
problem, configure multi-topologies and create separate IPv4 and IPv6 routing tables.
As shown in Figure 7-10, Router A, Router C, and Router D support both IPv4 and IPv6, whereas
Router B supports only IPv4.
Without IS-IS multi-topologies, IPv6 packets cannot be sent from Router A to Loopback 1 on
Router C, because the calculated SPT passes through Router B that does not support IPv6.
To ensure IPv6 packet transmission, enable IS-IS multi-topologies and create separate IPv4 and
IPv6 routing tables.

Figure 7-10 Networking diagram of IS-IS MT
RouterA GE1/0/0 RouterB

192.168.1.1/24
IPv4/IPv6 IPv4
cost=4 GE1/0/0
GE2/0/0 192.168.1.2/24 GE2/0/0
2001:db8:1::1/64 192.168.2.1/24
cost=6 Loopback1 cost=3

2001:db8:3::1/64
GE1/0/0 GE2/0/0
2001:db8:1::2/64 GE2/0/0 192.168.2.2/24
2001:db8:2::1/64
IPv4/IPv6 cost=14 GE1/0/0 IPv4/IPv6
RouterD 2001:db8:2::2/64 RouterC
1. Configure IPv4/IPv6 addresses for the interfaces on routers so that devices in different areas
can communicate.
2. Enable IPv6 as well as global IPv4 and IPv6 topologies on the routers supporting the IPv4/
IPv6 dual stack and enable a global IPv4 topology on Router B.
3. Configure basic IS-IS functions and link costs.
4. Create separate IPv4 and IPv6 topology instances on the routers supporting the IPv4/IPv6
dual stack and create an IPv4 topology instance on router B.
5. Associate the interfaces with specified topology instances.
Data Preparation
l IP addresses of the interfaces on routers as shown in Figure 7-10, area ID (86), system ID
of Router A (0000.0000.0001), system ID of Router B (0000.0000.0002), system ID of
Router C (0000.0000.0003), system ID of Router D (0000.0000.0004), and level of all the
routers (Level-1).
l Cost of the link from Router D to Router A (6), cost of the link from Router A to Router
B (4), cost of the link from Router B to Router C (3), cost of the link from Router D to
Router C (14), default cost of Loopback 1 on Router D (0), and default costs of other links
(10).
l IPv4 topology instance blue for all routers and IPv6 topology instance red for Router A,
Router C, and Router D.
Procedure
Step 1 Configure IP addresses for the interfaces.

Configure an IPv4 address and a mask for each interface on Router B, and configure IPv4 as
well as IPv6 addresses and masks for each interface on Router A, Router C, and Router D based
on Figure 7-10. The detailed configurations are not provided here.
Step 2 Enable IPv6 as well as global IPv4 and IPv6 topologies on the routers supporting the IPv4/IPv6
dual stack and enable a global IPv4 topology on Router B.
# Enable global IPv4 and IPv6 topologies on router A.

[RouterA] ip topology red
[RouterA] ipv6 topology blue
The configurations on Router C and Router D are the same as that on router A.
# Enable the global IPv4 topology on Router B.

[RouterB] ip topology red
Step 3 Configure basic IS-IS functions and link costs.
For details about the configuration of basic IS-IS functions, see Configuring Basic IPv4 IS-IS
Functions.
# Set the cost of the link from Router A to Router B to 4.

[RouterA-GigabitEthernet1/0/0] isis cost 4
The configuration of other link costs is the same as that of the link from Router A to Router B.
Step 4 Create an IPv4 topology instance red for each router and an IPv6 topology instance blue for
Router A, Router C, and Router D.
# Associate an IS-IS process with the IPv4 topology instance red and IPv6 topology instance
blue on Router A.
[RouterA] isis
[RouterA-isis-1] ipv6 enable topology ipv6
[RouterA-isis-1] cost-style wide
[RouterA-isis-1] topology red topology-id 10
[RouterA-isis-1-topology-red] quit
[RouterA-isis-1] ipv6 topology blue topology-id 20
[RouterA-isis-1-topology-blue] quit
The configurations on Router C and Router D are the same as that on Router A.
# Associate an IS-IS process with the IPv4 topology instance red on Router B.
[RouterB] isis
[RouterB-isis-1] cost-style wide
[RouterB-isis-1] topology red topology-id 10
[RouterB-isis-1-topology-red] quit
Step 5 Associate the interfaces with specified topology instances.
# Use the interfaces on Router A as an example.

[RouterA-GigabitEthernet1/0/0] ip topology red enable
[RouterA-GigabitEthernet1/0/0] isis topology red

[RouterA-GigabitEthernet2/0/0] ip topology red enable

[RouterA-GigabitEthernet2/0/0] isis topology red
[RouterA-GigabitEthernet2/0/0] ipv6 topology blue enable
[RouterA-GigabitEthernet2/0/0] isis ipv6 topology blue
Step 6 Verify the configuration
After the configuration is complete, run the display isis route command on the routers to view
information about the learned routes. The following example uses the display on Router D.
# Check the routing information on Router D.

-----------------------------
--------------------------------
--------------------------------------------------------------------------
2008::/64 GE2/0/0 FE80::D11:0:36D4:1 14 A/-/-
2001:db8:2::/64 GE2/0/0 Direct 14 D/L/-
2001:db8:1::/64 GE1/0/0 Direct 6 D/L/-
U-Up/Down Bit Set
IPv6 routes are calculated only on the IPv6 topology. Therefore, the outbound interface of the
route from Router D to 2008::/64 is GE 2/0/0.
# Run the tracert command on Router D.

[RouterD] tracert ipv6 2008::1
traceroute to 2008::1 30 hops max,60 bytes packet
1 2008::1 62 ms 63 ms 31 ms
To make a comparison between the preceding routing information and the routing information
when an IPv4/IPv6 topology is deployed, run the following commands.
[RouterD] isis 1
[RouterD-isis-1] ipv6 enable
Configuration modifications on Router A and Router C are the same as that on Router D.
After the configuration is modified, run the display isis route command on the routers once
again to view information about the learned routes. The following example uses the display on
Router D.
# Check the routing information on Router D.

-----------------------------
--------------------------------
--------------------------------------------------------------------------
2008::/64 GE1/0/0 FE80::200:5EFF:FE01:100 13 A/-/-
2001:db8:2::/64 GE2/0/0 Direct 14 D/L/-
2001:db8:1::/64 GE1/0/0 Direct 6 D/L/-
U-Up/Down Bit Set
The preceding output shows that the outbound interface of the route from Router D to 2008::/64
is GE 1/0/0. This is because in the SPF calculation when an IPv4/IPv6 topology is deployed, the
cost of the link passing through GE 1/0/0 to 2008::1/64 is smaller.

[RouterD] tracert ipv6 2008::1

traceroute to 2008::1 30 hops max,60 bytes packet
1 2001:db8:1::1 31 ms !N 31 ms !N 32 ms !N
However, the tracert command output shows that IPv6 packets cannot reach the destination.
# Check the routing information on Router A.

-----------------------------
--------------------------------
------------------------------------------------------------------------
192.168.2.0/24 7 NULL GE1/0/0 192.168.1.2 A/-/-/-
192.168.1.0/24 4 NULL GE1/0/0 Direct D/-/L/-
----------------------------------------------------------------------------
2001:db8:2::/64 GE1/0/0 FE80::2E0:A9FF:FE47:8302 24 A/-/-
2001:db8:1::/64 GE2/0/0 Direct 10 D/L/-
U-Up/Down Bit Set
The preceding output shows that there is no outbound interface for the route from Router A to
2008::/64. This is because the link between Router A and Router B does not support IPv6 and
IPv6 packets from Router D are discarded.
----End
Configuration Files
#
sysname RouterA
#
ip topology red
#
ipv6 topology blue
#
isis 1
cost-style wide
network-entity 86.0000.0000.0001.00
ipv6 enable topology ipv6
#
topology red topology-id 10
#
ipv6 topology blue topology-id 20
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
isis enable 1
isis cost 4
ip topology red enable
isis topology red
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
ipv6 topology blue enable
isis ipv6 topology blue
#

return

#
#
sysname RouterB
#
ip topology red
#
isis 1
network-entity 86.0000.0000.0002.00
#
#
#
undo shutdown
ip address 192.168.1.2 255.255.255.0
isis enable 1
isis topology red
#
undo shutdown
ip address 192.168.2.1 255.255.255.0
isis enable 1
isis cost 3
isis topology red
#
return

#
sysname RouterC
#
ip topology red
#
ipv6 topology blue
#
isis 1
cost-style wide
network-entity 86.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
isis topology red
#
undo shutdown
ip address 192.168.2.2 255.255.255.0
isis enable 1
isis topology red
#
interface LoopBack1

ipv6 enable
ipv6 address 2008::1/64
isis ipv6 enable 1
#
return

#
sysname RouterD
#
ipv6 topology blue
#
isis 1
is-level level-1
cost-style wide
network-entity 86.0000.0000.0004.00
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
isis cost 6
isis ipv6 cost 6
#
undo shutdown
ipv6 enable
isis ipv6 enable 1
isis cost 14
isis ipv6 cost 14
#
return
7.24.8 Example for Configuring Local MT

This part provides an example for configuring multicast packets to be forwarded through TE
tunnels on IS-IS networks.
l Router A, Router B, Router C, Router D, and Router E run IS-IS, and they are Level-2
routers.
l A TE tunnel is established between Router B and Router D.
l IGP Shortcut is enabled on Router B.

Figure 7-11 Configuring local MT
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
1. Enable basic IS-IS functions on each router.

2. Configure the Protocol Independent Multicast Sparse Mode (PIM-SM).
3. Configure an MPLS Resource Reservation Protocol (RSVP) TE tunnel and enable IGP
Shortcut.
4. Enable local MT.
Data Preparation
l IP address of each router interface is shown in Figure 7-11. The area address is 10, the
originating system ID is 0000.0000.0001 and is incremental, and the routers are Level-2
routers.
l Tunnel interface is TE tunnel 1/0/0, the tunnel interface borrows the IP address of Loopback
0, the tunnel encapsulation protocol is MPLS TE, the destination address is 4.4.4.4, the
tunnel ID is 100, and the tunnel signaling protocol is RSVP-TE.
Procedure
Step 1 Assign an IP address for each interface and enable IS-IS.

As shown in Figure 7-11, assign an IP address and the mask for each interface and enable IS-
IS. This example assumes that you know the configuration method and no details are provided
here.
Step 2 Configure PIM-SM.
# Enable multicast on all routers and enable PIM-SM on all interfaces except GigabitEthernet
1/0/0 on Router A. The configurations on Router B, Router C, Router D, and Router E are similar
to those on Router A and are not mentioned here.
[RouterA] multicast routing-enable
# Enable IGMP on the interface through which Router A is connected to hosts.

[RouterA-GigabitEthernet1/0/0] igmp enable
[RouterA-GigabitEthernet1/0/0] igmp version 3
# Configure a C-BSR and a C-RP. Set the service range of the RP on Router D and specify the
locations of the C-BSR and the C-RP.
[RouterD] pim
[RouterD-pim] c-bsr gigabitethernet 1/0/0
[RouterD-pim] c-rp gigabitethernet 1/0/0
# Run the display multicast routing-table command to view the multicast routing table of a
router. The multicast routing table on Router C is as follows:
Total 1 entry
00001. (192.168.3.2, 224.31.31.31)
Uptime: 15:03:04
Step 3 Configure an MPLS RSVP-TE tunnel.

[RouterB] mpls lsr-id 2.2.2.2
[RouterB] mpls
[RouterB-mpls] mpls te
[RouterB-mpls] mpls rsvp-te
[RouterB-mpls] mpls te cspf
[RouterB-mpls] quit
[RouterB-GigabitEthernet2/0/0] mpls
[RouterB-GigabitEthernet2/0/0] mpls te
[RouterB-GigabitEthernet2/0/0] mpls rsvp-te
[RouterB] isis 1
[RouterB-isis-1] cost-style wide
[RouterB-isis-1] traffic-eng level-2
[RouterC] mpls lsr-id 3.3.3.3
[RouterC] mpls
[RouterC-mpls] mpls te
[RouterC-mpls] mpls rsvp-te

[RouterC-mpls] mpls te cspf

[RouterC-mpls] quit
[RouterC] isis 1
[RouterC-isis-1] cost-style wide
[RouterC-isis-1] traffic-eng level-2
[RouterD] mpls lsr-id 4.4.4.4
[RouterD] mpls
[RouterD-mpls] mpls te
[RouterD-mpls] mpls rsvp-te
[RouterD-mpls] mpls te cspf
[RouterD-mpls] quit
[RouterD-GigabitEthernet1/0/0] mpls
[RouterD-GigabitEthernet1/0/0] mpls te
[RouterD-GigabitEthernet1/0/0] mpls rsvp-te
[RouterD] isis 1
[RouterD-isis-1] cost-style wide
[RouterD-isis-1] traffic-eng level-2
# Configure an MPLS TE tunnel and enable IGP Shortcut.

Configure an MPLS TE tunnel on Router B and enable IGP Shortcut.
[RouterB] interface tunnel 1/0/0
[RouterB-Tunnel1/0/0] ip address unnumbered interface loopback 0
[RouterB-Tunnel1/0/0] tunnel-protocol mpls te
[RouterB-Tunnel1/0/0] destination 4.4.4.4
[RouterB-Tunnel1/0/0] mpls te tunnel-id 100
[RouterB-Tunnel1/0/0] mpls te igp shortcut isis
[RouterB-Tunnel1/0/0] mpls te igp metric relative -10
[RouterB-Tunnel1/0/0] isis enable 1
[RouterB-Tunnel1/0/0] quit
# View the routing table on Router B. You can find that IGP Shortcut is enabled.
[RouterB] display isis route
-----------------------------
--------------------------------
--------------------------------------------------------------------------------
3.3.3.3/32 10 NULL GE2/0/0 10.0.1.1 A/-/-/-
172.16.1.0/24 20 NULL GE1/0/0 10.0.0.1 A/-/-/-
2.2.2.2/32 0 NULL Loop0 Direct D/-/L/-
192.168.3.0/24 25 NULL Tun1/0/0 2.2.2.2 A/S/-/-
5.5.5.5/32 15 NULL Tun1/0/0 2.2.2.2 A/S/-/-
10.0.0.0/24 10 NULL GE1/0/0 Direct D/-/L/-
10.0.1.0/24 10 NULL GE2/0/0 Direct D/-/L/-
4.4.4.4/32 5 NULL Tun1/0/0 2.2.2.2 A/S/-/-

10.0.2.0/24 15 NULL Tun1/0/0 2.2.2.2 A/S/-/-

10.0.3.0/24 15 NULL Tun1/0/0 2.2.2.2 A/S/-/-
U-Up/Down Bit Set
# View the multicast routing table on Router C spanned by the TE tunnel.

No multicast routing entry is displayed. This indicates that the multicast packet is discarded.
Step 4 Configure local MT.
# Enable local MT on Router B.

[RouterB] isis
[RouterB-isis-1] local-mt enable
# View the multicast routing table on Router C again. You can find that multicast routes are
displayed.
Total 1 entry
00001. (192.168.3.2, 224.31.31.31)
Uptime: 00:00:19
# View the MIGP routing table on Router B.

[RouterB] display migp routing-table
------------------------------------------------------------------------------
Routing Tables: MIGP
4.4.4.4/32 ISIS 15 20 10.0.1.1 GE2/0/0
5.5.5.5/32 ISIS 15 30 10.0.1.1 GE2/0/0
10.0.2.0/24 ISIS 15 20 10.0.1.1 GE2/0/0
10.0.3.0/24 ISIS 15 30 10.0.1.1 GE2/0/0
192.168.3.0/24 ISIS 15 40 10.0.1.1 GE2/0/0
The physical outgoing interface of the next hop of the route with the previous outgoing interface
being a TE tunnel interface is found in the MIGP routing table.
----End
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0001.00

#
ip address 10.0.0.1 255.255.255.0
isis enable 1
pim sm
#
ip address 172.16.1.1 255.255.255.0
isis enable 1
igmp enable
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
return

#
sysname RouterB
#
router id 2.2.2.2
#
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0002.00
traffic-eng level-2
local-mt enable
#
ip address 10.0.0.2 255.255.255.0
isis enable 1
pim sm
#
ip address 10.0.1.2 255.255.255.0
isis enable 1
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 1
pim sm
#
destination 4.4.4.4
mpls te igp shortcut isis
mpls te igp metric relative -10
isis enable 1
pim sm
#
pim
C-BSR LoopBack0

C-RP LoopBack0
#
return

#
sysname RouterC
#
router id 3.3.3.3
#
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0003.00
traffic-eng level-2
#
ip address 10.0.1.1 255.255.255.0
isis enable 1
pim sm
mpls
mpls te
mpls rsvp-te
#
ip address 10.0.2.2 255.255.255.0
isis enable 1
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 1
#
return

#
sysname RouterD
#
router id 4.4.4.4
#
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0004.00
traffic-eng level-2
#

ip address 10.0.3.1 255.255.255.0

isis enable 1
pim sm
#
ip address 10.0.2.1 255.255.255.0
isis enable 1
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 1
pim sm
#
return

#
sysname RouterE
#
router id 5.5.5.5
#
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0000.0005.00
#
ip address 10.0.3.3 255.255.255.0
isis enable 1
pim sm
#
interface Ethernet2/0/0
ip address 192.168.3.1 255.255.255.0
isis enable 1
pim sm
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
isis enable 1
pim sm
#
return
7.24.9 Example for Configuring Basic IS-IS IPv6 Functions

This part provides an example for interconnecting IPv6 networks through IS-IS.
l Router A, Router B, Router C, and Router D belong to the same AS. They are interconnected
through IS-IS in the IPv6 network.
l Router A, Router B, and Router C belong to area 10. Router D belongs to area 20.
l Router A and Router B are Level-1 routers. Router C is a Level-1-2 router. Router D is a
Level-2 router.

Figure 7-12 Networking diagram of basic IS-IS IPv6 feature
GE1/0/0
2001:db8:1::2/64 GE2/0/0
2001:db8:4::1/64
RouterA
GE3/0/0
L1
2001:db8:3::1/64
GE1/0/0
2001:db8:1::1/64
GE1/0/0
GE2/0/0 RouterC 2001:db8:3::2/64 RouterD
2001:db8:2::1/64 L1/L2 L2
IS-IS GE1/0/0
Area10 2001:db8:2::2/64
IS-IS
Area20
RouterB
L1
1. Enable the capability of IPv6 forwarding on each router.

2. Configure an IPv6 address for each interface.
3. Enable IS-IS on each router.
4. Configure the level.
5. Specify the network entity.
Data Preparation
l IPv6 address of each interface on Router A, Router B, Router C, and Router D

l Area numbers of Router A, Router B, Router C, and Router D
l Levels of Router A, Router B, Router C, and Router D
Procedure
Step 1 Enable the capability of IPv6 forwarding, and configure IPv6 address for each interface. Take
the display on Router A as an example. The configurations of Router B, Router C and Router
D are similar to that of Router A. The detailed configurations are not mentioned here.
[RouterA] ipv6

[RouterA-Pos1/0/0] ipv6 enable

[RouterA-Pos1/0/0] ipv6 address 2001:db8:1::2/64
Step 2 Configure IS-IS.
[RouterA] isis 1
[RouterA-isis-1] ipv6 enable
[RouterA-Pos1/0/0] isis ipv6 enable 1
[RouterB] isis 1
[RouterB-isis-1] ipv6 enable
[RouterB-Pos1/0/0] isis ipv6 enable 1
[RouterC] isis 1
[RouterC-isis-1] ipv6 enable
[RouterC-Pos1/0/0] isis ipv6 enable 1
[RouterC-Pos3/0/0] isis circuit-level level-2
[RouterD] isis 1
[RouterD] interface pos 1/0/0
[RouterD-Pos1/0/0] isis ipv6 enable 1
[RouterD-GigabitEthernet2/0/0] isis ipv6 enable 1
# Display the IS-IS routing table of Router A.

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


-------------------------------------------------------------------------------
0.0.0.0/0 10 NULL
-------------------------------------------------------------------------------
::/0 Pos1/0/0 FE80::A83E:0:3ED2:1 10 A/-/-
2001:db8:1::/64 Pos1/0/0 Direct 10 D/
L/-
2001:db8:2::/64 Pos1/0/0 FE80::A83E:0:3ED2:1 20 A/-/-
U-Up/Down Bit Set
# Display the IS-IS neighbors of Router C.

[RouterC] display isis peer verbose
----------------------------
0000.0000.0001 Pos1/0/0 0000000001 Up 24s L1 --
Local MT IDs : 0
Peer IPv6 Address(es): FE80::996B:0:9419:1
Uptime : 00:44:43
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0001
0000.0000.0002 Pos2/0/0 0000000001 Up 28s L1 --
Local MT IDs : 0
Peer IPv6 Address(es): FE80::DC40:0:47A9:1
Uptime : 00:46:13
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0002
0000.0000.0004 Pos3/0/0 0000000001 Up 24s L2 --
Local MT IDs : 0
Peer IPv6 Address(es): FE80::F81D:0:1E24:2
Uptime : 00:53:18
Adj Protocol : IPV6
Suppressed Adj : NO
Peer System Id : 0000.0000.0004
Total Peer(s): 3
# Display the IS-IS LSDB of Router C.

[RouterC] display isis lsdb verbose
--------------------------------
----------------------------------------------------------------------------
0000.0000.0001.00-00 0x0000000c 0x4e06 1117 113 0/0/0
SOURCE 0000.0000.0001.00
NLPID IPV6
AREA ADDR 10
INTF ADDR V6 2001:db8:1::2
Topology Standard
NBR ID 0000.0000.0003.00 COST: 10
IPV6 2001:db8:1::/64 COST: 10
0000.0000.0002.00-00 0x00000009 0x738c 1022 83 0/0/0

SOURCE 0000.0000.0002.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 0000.0000.0003.00 COST: 10
IPV6 2001:db8:2::/64 COST: 10
0000.0000.0003.00-00* 0x00000020 0x6b10 771 140 1/0/0
SOURCE 0000.0000.0003.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 0000.0000.0002.00 COST: 10
NBR ID 0000.0000.0001.00 COST: 10
IPV6 2001:db8:2::/64 COST: 10
IPV6 2001:db8:1::/64 COST: 10
Total LSP(s): 5
-------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000017 0x61b4 771 157 0/0/0
SOURCE 0000.0000.0003.00
NLPID IPV6
AREA ADDR 10
Topology Standard
NBR ID 0000.0000.0004.00 COST: 10
IPV6 2001:db8:3::/64 COST: 10
IPV6 2001:db8:2::/64 COST: 10
IPV6 2001:db8:1::/64 COST: 10
0000.0000.0004.00-00 0x0000000b 0x6dfa 1024 124 0/0/0
SOURCE 0000.0000.0004.00
NLPID IPV6
AREA ADDR 20
Topology Standard
NBR ID 0000.0000.0003.00 COST: 10
NBR ID 0000.0000.0005.00 COST: 10
IPV6 2001:db8:3::/64 COST: 10
IPV6 2001:db8:4::/64 COST: 10
Total LSP(s): 3
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#

ipv6 enable topology standard

#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
return

#
sysname RouterB
#
ipv6
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
return

#
sysname RouterC
#
ipv6
#
isis 1
network-entity 10.0000.0000.0003.00
#
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
interface Pos3/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
isis circuit-level level-2
#
return

#
sysname RouterD
#
ipv6

#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
#
ipv6 enable
isis ipv6 enable 1
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
return
7.24.10 Example for Configuring IS-IS Fast Convergence

This part provides an example for implementing fast route convergence by adjusting IS-IS
timers.
l Router A and Router B run IS-IS.

l Router A and Router B belong to area 10. They are Level-2 routers.
l A Layer 2 switch, which need not be configured, connects Router A and Router B.
Figure 7-13 Networking diagram of IS-IS fast convergence

GE1/0/0
10.1.1.2/24
GE1/0/0
RouterA 10.1.1.1/24 RouterB

2. Enable BFD on Router A and Router B.
3. Set the time parameters of fast convergence on Router A and Router B.
Data Preparation
To configure IS-IS fast convergence, you need the following data:
l Levels and area addresses of the two routers

l Time parameters of fast convergence
Procedure
[RouterA] isis 1
[RouterB] isis 1
Step 3 Configure BFD.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd atob bind peer-ip 10.1.1.2 interface gigabitethernet 1/0/0
[RouterA-bfd-session-atob] discriminator local 1
[RouterA-bfd-session-atob] discriminator remote 2
[RouterA-bfd-session-atob] commit
[RouterA-bfd-session-atob] quit
[RouterA-GigabitEthernet1/0/0] isis bfd static
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd btoa bind peer-ip 10.1.1.1 interface gigabitethernet 1/0/0
[RouterB-bfd-session-btoa] discriminator local 2
[RouterB-bfd-session-btoa] discriminator remote 1
[RouterB-bfd-session-btoa] commit
[RouterB-bfd-session-btoa] quit
[RouterB-GigabitEthernet1/0/0] isis bfd static
Step 4 Set the time parameters of fast convergence.

[RouterA] isis 1
[RouterA-isis-1] flash-flood
[RouterA-isis-1] timer spf 1 20 100
[RouterA-isis-1] timer lsp-generation 1 1 120

[RouterB] isis 1
[RouterB-isis-1] flash-flood
[RouterB-isis-1] timer spf 1 20 100
[RouterB-isis-1] timer lsp-generation 1 1 120
NOTE
l In IS-IS, if LSDB changes, routes are calculated and then a new LSP is generated to report this change.
Frequent route calculations consume lots of system resources and degrade the system performance.
Delaying SPF calculation, generating a new LSP time, and LSP fast flooding improves the efficiency
in route calculation and reduces the consumption of system resources.
l Using the flash-flood command, you can enable LSP fast flooding to speed up the convergence of an
IS-IS network.
l Run the timer spf command to set the interval of the SPF calculation. By default, the interval is 5
seconds.
l Run the timer lsp-generation command to set the delay for generating an LSP. By default, the delay
is 2 seconds.

# Run the shutdown command on GE 1/0/0 of Router B to simulate the link in the Down state.
# View the information about neighbors of Router A.

<RouterA> display isis peer
Information about neighbors of Router A does not exist.

When BFD detects that the link goes Down, it notifies the route management (RM) module
immediately. IS-IS then deletes neighbors immediately and triggers the route calculation. This
results in the fast convergence of the network.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
timer lsp-generation 1 1 120 level-1
flash-flood level-1
flash-flood level-2
network-entity 10.0000.0000.0001.00
timer spf 1 20 100
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis bfd static
#

bfd btoa bind peer-ip 10.1.1.2 interface GigabitEthernet1/0/0

commit
#
return

#
sysname RouterB
#
bfd
#
isis 1
is-level level-2
flash-flood level-1
flash-flood level-2
network-entity 10.0000.0000.0002.00
timer spf 1 20 100
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
isis bfd static
#
commit
#
return
7.24.11 Example for Configuring IS-IS Auto FRR (IP protecting IP)
This part provides an example for fast switching services to the backup link in the case of IS-IS
link failures through IS-IS Auto FRR (IP protecting IP).
When a fault occurs on a network, IS-IS Auto FRR fast switches traffic to a backup link before
the route convergence. This prevents traffic interruption.
In Figure 7-14:
l IS-IS runs between four routers.

l The four routers are all Level-1-2 routers.
l If Router C or Link T fails, it is required that the traffic forwarded by Router A is rapidly
switched to the backup link.

Figure 7-14 Networking diagram of configuring IS-IS Auto FRR

RouterC
L12
GE1/0/0 GE2/0/0
10.1.0.2/24 10.4.0.1/24
co
st
GE1/0/0 = RouterD
10
10.1.0.1/24 Link T 10
=
L12 GE3/0/0
st
GE1/0/0
co
RouterA 10.4.0.2/24 10.5.1.1/24
L12 cost = 10
co
st
10
GE2/0/0 = GE2/0/0
=
10.2.0.1/24 30
st
10.3.0.2/24
co
GE1/0/0 GE2/0/0
10.2.0.2/24 10.3.0.1/24
RouterB
L12
2. Set a larger link cost (in compliance with the traffic protection inequality of IS-IS Auto
FRR) on GE 2/0/0 of Router A, and ensure that Link T is preferentially selected.
3. Enable IS-IS Auto FRR on Router A that forwards the protected traffic.
Data Preparation
l IP addresses of interfaces on each router
l NET of each router
l Level of each router
l Costs of interfaces on each router
Procedure
Step 1 Configure IP addresses for interfaces. The details are omitted.
[RouterA] isis 1
[RouterA-isis-1] is-level level-1-2


[RouterB] isis 1
[RouterB-isis-1] is-level level-1-2
[RouterC] isis 1
[RouterC-isis-1] is-level level-1-2
[RouterD] isis 1
[RouterD-isis-1] is-level level-1-2
Step 3 Set the cost of Gigabit Ethernet 2/0/0 on RouterA to 30, and then check routing information.
# Configure the cost of GE 2/0/0 on Router A to 30.
# Check information about the link from Router A to Router D. Link T has a lower cost, and
thereby IS-IS optimally selects Link T to send traffic that is forwarded by Router A.
<RouterA> display isis route 10.5.1.1 verbose

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

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

Admin Tag : - Src Count : 1 Flags : A/-/L/-
Priority : Low
10.1.0.2 GE1/0/0 0x00000003


U-Up/Down Bit Set

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

Admin Tag : - Src Count : 3 Flags : -/-/-/-
Priority : Low

U-Up/Down Bit Set
# Run the display fib 10.5.1.1 verbose command on Router A to check the forwarding entry
from Router A to Router D.
<RouterA> display fib 10.5.1.1 verbose
Route Entry Count: 1

Destination: 10.5.1.0 Mask : 255.255.255.0
Nexthop : 10.1.0.2 OutIf : GigabitEthernet1/0/0
LocalAddr : 10.1.0.1 LocalMask: 0.0.0.0
Flags : DGU Age : 26sec
ATIndex : 0 Slot : 0
LspFwdFlag : 0 LspToken : 0x0
InLabel : NULL OriginAs : 0
BGPNextHop : 0.0.0.0 PeerAs : 0
QosInfo : 0x0 OriginQos: 0x0
NexthopBak : 0.0.0.0 OutIfBak : [No Intf]
LspTokenBak: 0x0 InLabelBak : NULL
LspToken_ForInLabelBak : 0x0
EntryRefCount : 0
rt_ulVlanId : 0x0
LspType : 0 Label_ForLspTokenBak : 0
MplsMtu : 0 Gateway_ForLspTokenBak : 0
NextToken : 0 IfIndex_ForLspTokenBak : 0
Label_NextToken : 0 Label : 0
LspBfdState : 0
As shown in the command output, the traffic from Router A to Router D is only forwarded
through Link T.
Step 4 Enable IS-IS Auto FRR on Router A, and then check the routing information.
# Enable IS-IS Auto FRR on Router A.
[RouterA] isis
[RouterA-isis-1] frr
[RouterA-isis-1-frr]loop-free-alternate
# Check information about the link from Router A to Router D. You can find that IS-IS creates
a backup link because IS-IS Auto FRR is enabled.
<RouterA> display isis route 10.5.1.1 verbose

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

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

Admin Tag : - Src Count : 1 Flags : A/-/L/-
Priority : Low

10.1.0.2 GE1/0/0 0x00000003

(B)10.2.0.2 GE2/0/0 0x00000004

U-Up/Down Bit Set

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

Admin Tag : - Src Count : 3 Flags : -/-/-/-
Priority : Low

U-Up/Down Bit Set
# Check the protection type for the traffic from Router A to Router D.
<RouterA> display isis spf-tree systemid 0000.0000.0004 verbose

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

----------------------------------
0000.0000.0004.00
Distance : 20
Distance-URT : 20
Flags : SPT/V6_Islt
(1) 10.1.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00
(B) 10.2.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00
TYPE:LOOP-FREE PROTECT:LINK-NODE
IPv6 Nexthops : 0
(1) 0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child

----------------------------------
0000.0000.0004.00
Distance : 20
Distance-URT : 20
Flags : SPT/V6_Islt
(1) 10.1.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00
(B) 10.2.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00
TYPE:LOOP-FREE PROTECT:LINK-NODE
IPv6 Nexthops : 0
(1) 0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child

As shown in the preceding command output, link-node dual protection is enabled from Router
A to Router D.
# Run the display fib 10.5.1.1 verbose command on Router A to check the backup forwarding
entry from Router A to Router D.
NexthopBak : 10.2.0.2 OutIfBak : GigabitEthernet2/0/0
EntryRefCount : 0
VlanId : 0x0
LspBfdState : 0
As shown in the command output, the master link from Router A to Router D is Link T, the
relevant backup link follows the route with GE 2/0/0 as the outbound interface and 10.2.0.2 as
the next hop.
# Run the shutdown command on GE 2/0/0 of Router C to make the link down.
[RouterC-GigabitEthernet2/0/0] shutdown
# Run the display fib 10.5.1.1 verbose command immediately on Router A to check information
about the route from Router A to Router D.
EntryRefCount : 0
VlanId : 0x0
LspBfdState : 0

As shown in the command output, the traffic forwarded by the Router A is switched to the backup
link, with GE 2/0/0 as the outbound interface and 10.2.0.2 as the next hop.
----End
Configuration Files
#
sysname RouterA
#
isis 1
frr
loop-free-alternate level-1
network-entity 10.0000.0000.0001.00
#
interface gigabitethernet 1/0/0
ip address 10.1.0.1 255.255.255.0
isis enable 1
#
ip address 10.2.0.1 255.255.255.0
isis enable 1
isis cost 30
#
return

#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 10.2.0.2 255.255.255.0
isis enable 1
#
ip address 10.3.0.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1
network-entity 10.0000.0000.0003.00
#
ip address 10.1.0.2 255.255.255.0
isis enable 1
#
shutdown
ip address 10.4.0.1 255.255.255.0
isis enable 1
#
return

#

sysname RouterD
#
isis 1
network-entity 10.0000.0000.0004.00
#
ip address 10.4.0.2 255.255.255.0
isis enable 1
#
ip address 10.3.0.2 255.255.255.0
isis enable 1
#
ip address 10.5.1.1 255.255.255.0
isis enable 1
#
return
7.24.12 Example for Configuring IS-IS Auto FRR (TE protecting IP)
This part provides an example for fast switching services to the backup link in the case of IS-IS
link failures through IS-IS Auto FRR (TE protecting IP).
Figure 7-15 Networking diagram of configuring IS-IS Auto FRR
PE1 P1 P3 PE3
P5
Plane A
P2 P4
P6
Plane B Traffic in normal
Traffic in case of failure
Figure 7-15 is the simplified networking diagram of MPLS VPN double planes, and PEs are
dual-homed to the two planes. It is required that:
l IS-IS should be configured to implement IP connectivity between nodes.
l Traffic between P nodes at the core layer should be transmitted through the direct link when
no link fault occurs.
l The MPLS TE tunnel should be configured as the backup path so that traffic between P
nodes can be switched to the other plane when the link between P nodes fails.

l IS-IS Auto FRR should be configured so that service traffic between P nodes can be rapidly
switched to the TE tunnel when the direct link fails.
l Traffic between P nodes should be transmitted only between the P nodes at the core layer
to prevent traffic between P nodes from going back to PE nodes.
NOTE
In this configuration example, PE1 and PE3 are used for illustration, only three P nodes of each plane at
the core layer are illustrated, and only the MPLS TE tunnel between P1 and P3 is illustrated. In real-world
situations, there are far more PE nodes, P nodes, and MPLS TE tunnels.
1. Assign IP addresses to interfaces on each node, configure the loopback addresses that are
used as LSR IDs, and configure IS-IS to implement IP connectivity.
2. Configure an MPLS TE tunnel between P nodes as the backup path in Loop-Free Alternate
(LFA) calculation.
3. Enable forwarding adjacency and configure LDP over TE.
4. Enable IS-IS Auto FRR so that traffic can be rapidly switched in the case of a link fault.
5. Run the undo isis lfa-backup command on the interfaces that connect P nodes to PE nodes
to disable these interfaces from becoming the backup interfaces in LFA calculation and
prevent traffic between P nodes from going back to PE nodes.
Data Preparation
Table 7-3 IP addresses of physical interfaces
Device Name Interface and IP Remote IP Remote Device

Address Address
P1 GE 1/0/0 GE 1/0/0 P2
10.1.1.1/30 10.1.1.2/30
P1 GE 2/0/0 GE 2/0/0 P3
10.1.2.1/30 10.1.2.2/30
P1 GE 3/0/0 GE 2/0/0 P5
10.1.3.1/30 10.1.3.2/30
P2 GE 2/0/0 GE 2/0/0 P4
10.1.4.1/30 10.1.4.2/30
P2 GE 3/0/0 GE 2/0/0 P6
10.1.5.1/30 10.1.5.2/30
P3 GE 1/0/0 GE 1/0/0 P4
10.1.6.1/30 10.1.6.2/30

Device Name Interface and IP Remote IP Remote Device

Address Address
P3 GE 3/0/0 GE 3/0/0 P5
10.1.7.1/30 10.1.7.2/30
P4 GE 3/0/0 GE 3/0/0 P6
10.1.8.1/30 10.1.8.2/30
P5 GE 1/0/0 GE 1/0/0 P6
10.1.9.1/30 10.1.9.2/30
PE1 GE 1/0/0 GE 3/1/0 P1

10.1.10.1/30 10.1.10.2/30
PE1 GE 2/0/0 GE 3/1/0 P2

10.1.11.1/30 10.1.11.2/30
PE3 GE 1/0/0 GE 3/1/0 P3

10.1.12.1/30 10.1.12.2/30
PE3 GE 2/0/0 GE 3/1/0 P4

10.1.13.1/30 10.1.13.2/30
Table 7-4 IP address of Loopback 0
Device Name IP Address of Loopback 0
P1 1.1.1.1/32
P2 2.2.2.2/32
P3 3.3.3.3/32
P4 4.4.4.4/32
P5 5.5.5.5/32
P6 6.6.6.6/32
PE1 7.7.7.7/32
PE3 8.8.8.8/32
Table 7-5 IS-IS parameters
Parameter Value
Router ID IP address of Loopback 0

Parameter Value
IS-IS process ID 64
Level 2
NET In the format of Area-ID.System-ID.00

l Area-ID: 86.0010
l System-ID: is based on the expansion of
the IP address of Loopback 0. For
example, if the IP address of Loopback 0
is 1.1.1.1, the system ID becomes
0010.0100.1001.
IS-IS name Same as the device name
Metric type Wide
Metric value Physical interface: 5

Tunnel interface: 6
Other parameters Default values
Table 7-6 MPLS parameter
Parameter Value
LSR ID IP address of Loopback 0
Tunnel interface number Number of the physical outbound interface of

the tunnel
Tunnel interface description to_destination node
Tunnel interface address IP address of Loopback 0
Tunnel ID 100
Name of the explicit path Tunnel description
Tunnel metric value Smaller than the metric value of the primary
path and greater than the metric values of
other paths so that the tunnel can become the
backup path and LDP over TE can be
implemented
Tunnel bandwidth 200 Mbit/s
Name of the LDP peer to_destination node
Other parameters Default values

Procedure
Step 1 Configure IP addresses for interfaces.
Configure the IP address and mask for each interface according to Table 7-3 and Table 7-4.
Configure IS-IS on all the PE and P nodes, and configure P1 and PE1. The configurations of
other nodes are similar to the configurations of P1 and PE1 and therefore are not mentioned here.
# Configure P1.
[P1] router id 1.1.1.1
[P1] isis 64
[P1-isis-64] network-entity 86.0010.0010.0100.1001.00
[P1-isis-64] is-level level-2
[P1-isis-64] cost-style wide
[P1-isis-64] is-name P1
[P1-isis-64] quit
[P1] interface loopback 0
[P1-LoopBack0] isis enable 64
[P1-LoopBack0] quit
[P1] interface gigabitethernet 1/0/0
[P1-GigabitEthernet1/0/0] isis enable 64
[P1-GigabitEthernet1/0/0] isis cost 5
[P1-GigabitEthernet1/0/0] quit
# Configure PE1.
[PE1] router id 7.7.7.7
[PE1] isis 64
[PE1-isis-64] network-entity 86.0010.0070.0700.7007.00
[PE1-isis-64] is-level level-2
[PE1-isis-64] cost-style wide
[PE1-isis-64] is-name PE1
[PE1-isis-64] quit
[PE1] interface loopback 0
[PE1-LoopBack0] isis enable 64
[PE1-LoopBack0] quit
[PE1] interface gigabitethernet 1/0/0
[PE1-GigabitEthernet1/0/0] isis enable 64
[PE1-GigabitEthernet1/0/0] isis cost 5
[PE1-GigabitEthernet1/0/0] quit
[PE1-GigabitEthernet2/0/0] isis enable 64
[PE1-GigabitEthernet2/0/0] isis cost 5
After the preceding configurations, run the display ip routing-table command on each node.
The command output shows that the nodes have learned routes from each other. For example,
when checking whether there are routes to the IP address of Loopback 0 on PE1, you can find
the following information:

[PE1] display ip routing-table 1.1.1.1 32

------------------------------------------------------------------------------
Summary Count : 1
1.1.1.1/32 ISIS-L2 15 5 D 10.1.10.2

Step 3 Configure an MPLS TE tunnel.
Enable MPLS, MPLS TE, and RSVP-TE on the interfaces of P1, P2, P3, and P4, and enable
CSPF on the ingress of the tunnel.
Configure P1 and P2. The configuration of P3 is similar to that of P1, and the configuration of
P4 is similar to that of P2.
# Configure P1.
[P1] mpls lsr-id 1.1.1.1
[P1] mpls
[P1-mpls] mpls te
[P1-mpls] mpls rsvp-te
[P1-mpls] mpls te cspf
[P1-mpls] quit
[P1-GigabitEthernet1/0/0] mpls
[P1-GigabitEthernet1/0/0] mpls te
[P1-GigabitEthernet1/0/0] mpls rsvp-te
[P1-GigabitEthernet1/0/0] mpls te bandwidth max-reservable-bandwidth 200000
[P1-GigabitEthernet1/0/0] mpls te bandwidth bc0 200000
# Configure P2.
[P2] mpls
[P2-mpls] mpls te
[P2-mpls] mpls rsvp-te
[P2-mpls] quit
# On P1, configure an explicit path for the TE tunnel. The configuration of P3 is similar to that
of P1 and is not mentioned here.
[P1] explicit-path to_P3
[P1-explicit-path-to_p3] next hop 10.1.1.2
[P1-explicit-path-to_p3] quit

# Configure a tunnel interface on P1. The configuration of P3 is similar to that of P1 and is not
mentioned here.
[P1] interface Tunnel1/0/0
[P1-Tunnel1/0/0] to_P3
[P1-Tunnel1/0/0] ip address unnumbered interface LoopBack0
[P1-Tunnel1/0/0] tunnel-protocol mpls te
[P1-Tunnel1/0/0] destination 3.3.3.3
[P1-Tunnel1/0/0] mpls te tunnel-id 100
[P1-Tunnel1/0/0] mpls te bandwidth ct0 200000
[P1-Tunnel1/0/0] mpls te path explicit-path to_P3
[P1-Tunnel1/0/0] mpls te commit
After the preceding configurations, run the display interface tunnel 1/0/0 command on P1 and
P3. The command output shows that the status of the tunnel interface is Up.
[P1] display interface tunnel 1/0/0
Tunnel1/0/0 current state : UP
Line protocol current state : UP
Last up time: 2009-09-29, 16:35:10
Description : to_P3
Step 4 Configure LDP over TE.

Enable MPLS LDP, and configure PE1, P1, P3, and P5. The configurations of other nodes are
similar to the configurations of PE1, P1, P3, and P5 and therefore are not mentioned here.
# Configure PE1.
[PE1] mpls lsr-id 7.7.7.7
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-GigabitEthernet1/0/0] mpls
[PE1-GigabitEthernet1/0/0] mpls ldp
# Configure P1.
[P1] mpls ldp
[P1-GigabitEthernet2/0/0] mpls ldp
[P1] mpls ldp remote-peer to_P3
[P1-mpls-ldp-remote-to_P3] remote-ip 3.3.3.3
[P1-mpls-ldp-remote-to_P3] quit
# Configure P3.
[P3] mpls ldp

[P3] mpls ldp remote-peer to_P1

[P3-mpls-ldp-remote-to_P1] remote-ip 1.1.1.1
[P3-mpls-ldp-remote-to_P1] quit
# Configure P5.
[P5] mpls
[P5-mpls] quit
[P5] mpls ldp
[P5-mpls-ldp] quit
# On the tunnel interface, enable forwarding adjacency and the IS-IS process, and adjust the
metric of the tunnel interface so that the tunnel interface can become the outbound interface of
the second best IS-IS route. Take the configuration of P1 as an example. The configuration of
P3 is similar to that of P1 and is not mentioned here.
[P1] interface tunnel 1/0/0
[P1-Tunnel1/0/0] mpls te igp advertise
[P1-Tunnel1/0/0] mpls te igp metric absolute 6
[P1-Tunnel1/0/0] mpls te commit
[P1-Tunnel1/0/0] isis enable 1
After the preceding configuration, run the display mpls ldp lsp command on PE1. The command
output shows that an LDP LSP is established. Take the display on PE1 as an example.
[PE1] display mpls ldp lsp 8.8.8.8 32
LDP LSP Information

-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
-------------------------------------------------------------------------------
8.8.8.8/32 NULL/3 - 10.1.10.2 GE1/0/0
8.8.8.8/32 1024/3 1.1.1.1 10.1.10.2 GE1/0/0
-------------------------------------------------------------------------------
TOTAL: 2 Normal LSP(s) Found.
TOTAL: 0 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is in GR state
A '*' before a DS means the session is in GR state
A '*' before a NextHop means the LSP is FRR LSP
Step 5 Configure IS-IS Auto FRR.
Enable IS-IS Auto FRR on P1 and P3, and disable the interfaces that connect P nodes to PE
nodes from becoming IS-IS LFA backup interfaces.
# Configure P1.
[P1] isis 64
[P1-isis-64] frr
[P1-isis-64-frr] loop-free-alternate level-2
[P1-isis-64-frr] quit
[P1-isis-64] quit
[P1] interface gigabitethernet3/1/0
[P1-GigabitEthernet3/1/0] undo isis lfa-backup

# Configure P3.
[P3] isis 64
[P3-isis-64] frr
[P3-isis-64-frr] loop-free-alternate level-2
[P3-isis-64-frr] quit
[P3-isis-64] quit
[P3] interface gigabitethernet3/1/0
[P3-GigabitEthernet3/1/0] undo isis lfa-backup
# Run the display fib 3.3.3.3 32 verbose command on P1 to view the FIB entry to P3.
[P1] display fib 3.3.3.3 32 verbose
Nexthop : 10.1.2.2 OutIf : GE2/0/0
NexthopBak : 10.1.1.2 OutIfBak : Tunnel1/0/0
EntryRefCount : 0
VlanId : 0x0
LspBfdState : 0
# Run the shutdown command on GE 2/0/0 of P1 or P3 to simulate a link fault. Take the
configuration of P1 as an example.
[P1-GigabitEthernet2/0/0] shutdown
# Run the display fib 3.3.3.3 32 verbose command on P1 to view the FIB entry to P3.
[P1] display fib 3.3.3.3 32 verbose
Nexthop : 10.1.1.2 OutIf : Tunnel1/0/0
EntryRefCount : 0
VlanId : 0x0

LspBfdState : 0
The command output shows that traffic from P1 to P3 has been switched to the backup link with
the outbound interface being Tunnel 1/0/0.
----End
Configuration Files
l Configuration file of P1
#
sysname P1
#
router id 1.1.1.1
#
mpls lsr-id 1.1.1.1
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path to_p3
next hop 10.1.1.2
next hop 10.1.4.2
next hop 10.1.6.1
next hop 3.3.3.3
#
mpls ldp
#
mpls ldp remote-peer to_p3
remote-ip 3.3.3.3
undo remote-ip pwe3
#
isis 64
frr
is-level level-2
cost-style wide
network-entity 86.0010.0010.0100.1001.00
is-name P1
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 64
#
description toP3
destination 3.3.3.3
mpls te bandwidth ct0 200000
mpls te path explicit-path to_p3
mpls te igp advertise
mpls te igp metric absolute 6
mpls te commit
isis enable 64
#
undo shutdown
ip address 10.1.1.1 255.255.255.252
isis enable 64
isis cost 5
mpls

mpls te
mpls rsvp-te
mpls te bandwidth max-reservable-bandwidth 200000
mpls te bandwidth bc0 200000
#
undo shutdown
ip address 10.1.2.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.3.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.10.2 255.255.255.252
isis enable 64
isis cost 5
undo isis lfa-backup
mpls
mpls ldp
#
return
#
sysname P2
#
router id 2.2.2.2
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0020.0200.2002.00
is-name P2
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
isis enable 64
#
undo shutdown
ip address 10.1.1.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls rsvp-te
#

undo shutdown
ip address 10.1.4.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls ldp
#
undo shutdown
ip address 10.1.5.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.11.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
#
sysname P3
#
router id 3.3.3.3
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path to_p3
next hop 10.1.6.2
next hop 10.1.4.1
next hop 10.1.1.1
next hop 1.1.1.1
#
mpls ldp
#
mpls ldp remote-peer to_p1
remote-ip 1.1.1.1
undo remote-ip pwe3
#
isis 64
frr
is-level level-2
cost-style wide
network-entity 86.0010.0030.0300.3003.00
is-name P3
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
isis enable 64
#
description toP1

destination 1.1.1.1
mpls te bandwidth ct0 200000
mpls te path explicit-path to_p1
mpls te igp advertise
mpls te igp metric absolute 6
mpls te commit
isis enable 64
#
undo shutdown
ip address 10.1.6.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.2.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.7.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.12.2 255.255.255.252
isis enable 64
isis cost 5
undo isis lfa-backup
mpls
mpls ldp
#
return
#
sysname P4
#
router id 4.4.4.4
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0040.0400.4004.00
is-name P4
#

interface LoopBack0
ip address 4.4.4.4 255.255.255.255
isis enable 64
#
undo shutdown
ip address 10.1.6.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 10.1.4.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls te
mpls ldp
#
undo shutdown
ip address 10.1.8.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.13.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
#
sysname P5
#
router id 5.5.5.5
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0050.0500.5005.00
is-name P5
#
interface LoopBack0
ip address 5.5.5.5 255.255.255.255
isis enable 64
#
undo shutdown

ip address 10.1.9.1 255.255.255.252

isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.3.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.7.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
#
sysname P6
#
router id 6.6.6.6
#
mpls lsr-id 6.6.6.6
mpls
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0060.0600.6006.00
is-name P6
#
interface LoopBack0
ip address 6.6.6.6 255.255.255.255
isis enable 64
#
undo shutdown
ip address 10.1.9.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.5.2 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.8.2 255.255.255.252
isis enable 64
isis cost 5
mpls

mpls ldp
#
return
l Configuration file of PE1

#
sysname PE1
#
router id 7.7.7.7
#
mpls lsr-id 7.7.7.7
mpls
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0070.0700.7007.00
is-name PE1
#
interface LoopBack0
ip address 7.7.7.7 255.255.255.255
isis enable 64
#
undo shutdown
ip address 10.1.10.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.11.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return

#
sysname PE3
#
router id 8.8.8.8
#
mpls lsr-id 8.8.8.8
mpls
#
mpls ldp
#
isis 64
is-level level-2
cost-style wide
network-entity 86.0010.0080.0800.8008.00
is-name PE3
#
interface LoopBack0
ip address 8.8.8.8 255.255.255.255
isis enable 64
#
undo shutdown
ip address 10.1.12.1 255.255.255.252

isis enable 64
isis cost 5
mpls
mpls ldp
#
undo shutdown
ip address 10.1.13.1 255.255.255.252
isis enable 64
isis cost 5
mpls
mpls ldp
#
return
7.24.13 Example for Configuring IS-IS GR

This part provides an example for implementing nonstop packet forwarding when master-slave
switchover occurs on the device that runs IS-IS.
In the network shown in Figure 7-16, Router A, Router B, and Router C belong to the same AS.
Network interconnection is implemented through IS-IS and the GR mechanism is provided.
After IS-IS adjacencies are set up between Router A, Router B, and Router C, the three routers
start to exchange routing information. When IS-IS on Router A restarts, Router A resends
connection requests to neighbors to synchronize the LSDB.
Figure 7-16 Networking diagram for configuring IS-IS GR
GE1/0/0 GE1/0/0 GE2/0/0

10.1.1.1/24 10.1.1.2/24 10.2.1.1/24
GE1/0/0
RouterA RouterB 10.2.1.2/24 RouterC
1. Configure GR in the IS-IS views of all the routers.

2. Set the same restart interval in the IS-IS views of all the routers.
Data Preparation
l IS-IS process number

l Restart interval

Procedure
Step 2 Configure the basic IS-IS functions.
Step 3 Configure IS-IS GR.
# Enable IS-IS GR on Router A and set the restart interval. The configurations of Router B and
Router C are the same as the configuration of Router A. Take the configuration of Router A as
an example.
[RouterA] isis 1
[RouterA-isis-1] graceful-restart
[RouterA-isis-1] graceful-restart interval 150
# Run the display fib command on Router A to view the Forwarding Information Base (FIB)
table.
<RouterA> display fib
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] GE1/0/0 0x0
10.1.1.2/32 10.1.1.2 HU t[20678] GE1/0/0 0x0
10.2.1.0/24 10.1.1.2 DGU t[79388] GE1/0/0 0x0
# Restart the IS-IS process on Router A in GR mode.

<RouterA> reset isis all graceful-restart
NOTE
A router restarts an IS-IS process in GR mode only when GR is enabled in the IS-IS process.
# Run the display fib command on Router A, 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 Router A restarts the IS-IS process in GR mode.
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] GE1/0/0 0x0
10.1.1.2/32 10.1.1.2 HU t[20678] GE1/0/0 0x0
10.2.1.0/24 10.1.1.2 DGU t[79388] GE1/0/0 0x0
As shown in the display, the FIB table on Router A does not change and the forwarding service
is not affected.
# Disable IS-IS GR on Router A.

[RouterA] isis 1

[RouterA-isis-1] undo graceful-restart
# Restart the IS-IS process on Router A not in GR mode.

<RouterA> reset isis all
# Run the display fib command on Router A immediately to view the FIB table.
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] GE1/0/0 0x0
10.1.1.2/32 10.1.1.2 HU t[20678] GE1/0/0 0x0
As shown in the display, Router A does not restart the IS-IS process in GR mode; the FIB table
changes; compared with the IS-IS process in GR mode, the route to network segment 10.2.1.0
does not exist; service forwarding is affected.
----End
Configuration Files
#
sysname RouterA
#
isis 1
graceful-restart
graceful-restart interval 150
is-level level-1
network-entity 10.0000.0000.0001.00
#
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterB
#
isis 1
graceful-restart
is-level level-2
network-entity 10.0000.0000.0002.00
#
link-protocol ppp
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
isis 1

graceful-restart
network-entity 10.0000.0000.0003.00
#
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
link-protocol ppp
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
return
7.24.14 Example for Configuring Static BFD for IS-IS

This part provides an example for configuring static BFD for IS-IS to fast detect faults and report
them to IS-IS. In this manner, the fast switchover of service traffic is triggered.
As show in Figure 7-17:
l A Layer 2 switch exists between Router A and Router B.

l Router A, Router B and Router C run IS-IS.
l BFD is configured to detect the IS-IS neighbor relationship between Router A and Router
B. When the link between Router A and Router B is faulty, BFD can fast detect the default
and report it to IS-IS.
Figure 7-17 Networking diagram of configuring static BFD for IS-IS
GE1/0/0 GE1/0/0 GE2/0/0

10.1.1.1/24 10.1.1.2/24 10.2.1.1/24
GE1/0/0
NOTE
BFD for IS-IS cannot be used to detect the multi-hops link between Router A and Router C, because the
IS-IS neighbor relationship cannot be established between Router A and Router C.

Data Preparation

l IS-IS process ID
l Name of the BFD session set up between Router A and Router B and the peer IP address
to be detected
l Local and remote discriminators of the BFD session set up between Router A and Router
B
Procedure
Step 2 Configuration basic IS-IS functions.
[RouterA] isis 1
[RouterA-isis-1] network-entity aa.1111.1111.1111.00
[RouterB] isis 1
[RouterB-isis-1] network-entity aa.2222.2222.2222.00
[RouterB-gigabitethernet2/0/0] isis enable 1
[RouterB-gigabitethernet2/0/0] quit
[RouterC] isis 1
[RouterC-isis-1] network-entity aa.3333.3333.3333.00
[RouterC-gigabitethernet1/0/0] isis enable 1
[RouterC-gigabitethernet1/0/0] quit
After the preceding configurations, you can view that the neighbor relationship is established
between Router A and Router B.
----------------------------
2222.2222.2222 GE1/0/0 2222.2222.2222.00 Up 23s L2
64
The IS-IS routing table of Router A has entries to Router B and Router C.


-----------------------------
--------------------------------
-------------------------------------------------------------------------
10.1.1.0/24 10 NULL GGE1/0/0 Direct D/-/L/-
10.2.1.0/24 20 NULL GE1/0/0 10.1.1.2 A/-/L/-
U-Up/Down Bit Set
Step 3 Configure BFD.
# Enable BFD on Router A and configure a BFD session.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd atob bind peer-ip 10.1.1.2 interface gigabitethernet 1/0/0
[RouterA-bfd-session-atob] discriminator local 1
[RouterA-bfd-session-atob] discriminator remote 2
[RouterA-bfd-session-atob] commit
[RouterA-bfd-session-atob] quit
# Enable BFD on Router B and configure a BFD session.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd btoa bind peer-ip 10.1.1.1 interface gigabitethernet 1/0/0
[RouterB-bfd-session-btoa] discriminator local 2
[RouterB-bfd-session-btoa] discriminator remote 1
[RouterB-bfd-session-btoa] commit
[RouterB-bfd-session-btoa] quit
After the preceding configurations, you can view that the status of the static BFD is YES when
the display isis interface verbose command is used on Router A or Router B.
The display on Router A is as follows:

[RouterA] display isis interface verbose

---------------------------------
Interface Id IPV4.State IPV6.State MTU Type
DIS
GE1/0/0 001 Up Down 1500 L2
--
Description : HUAWEI, GigabitEthernet1/0/0 Interface
SNPA Address : 00e0-7e47-8142
Csnp Timer Value : L12 10
Hello Timer Value : 10
DIS Hello Timer Value :
Hello Multiplier Value : 3
Cost : L1 10 L2 10
Static Bfd : YES
Dynamic Bfd : NO
Fast-Sense Rpr : NO
Suppress Base : NO
Ipv6 Suppress Base : NO
Ipv4 MT 1000 : red
Ipv4 MT 1000 Cost : L1 10 L2 10

Ipv4 MT 1000 Tag : L1 10 L2 10

Ipv4 MT 1000 Suppress-Reach : L1 YES L2 NO
Extended-Circuit-Id Value : 0000000001
Link quality adjust cost : YES
Link quality : 0x0(GOOD)
Delay peer time : Configured 100s Left --
Step 4 Enable IS-IS fast sense.

[RouterA-GigabitEthernet1/0/0] isis bfd static
[RouterB-GigabitEthernet1/0/0] isis bfd static

# Enable the terminal log information on Router A.
<RouterA> terminal logging
<RouterA> terminal monitor
# Run the shutdown command on GigabitEthernet1/0/0 of Router B to simulate a link fault.

# On Router A, the following log information and debugging information are displayed. It
indicates that IS-IS deletes the neighbor relationship with Router B according to the fault
reported by BFD.
ISIS/4/PEER_DOWN_BFDDOWN/1880166931 UL/R "ISIS 1 neighbor
2222.2222.2222 is down on the interface GE1/0/0 because BFD node is Down.
ISIS/4/PEER_DOWN_BFDDOWN/1880166931 UL/R "ISIS 1 neighbor
2222.2222.2222 was Down on interface GE1/0/0
because the BFD node was down. The Hello packet was received at 11:32:10 last
time; the maximum interval for sending Hello packets was 9247;the local router sent
426 Hello
packets and received 61 packets;the type of the Hello packet was Lan Level-2."
Run the display isis route command or the display isis peer command on Router A, no
information is displayed. This indicates that the IS-IS neighbor relationship between Router A
and Router B is deleted.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
network-entity aa.1111.1111.1111.00
#
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 GigabitEthernet1/0/0
commit
#
return

#
sysname RouterB
#
bfd
#
isis 1
is-level level-2
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
isis bfd static
#
ip address 10.2.1.1 255.255.255.0
isis enable 1
#
commit
#
return

#
sysname RouterC
#
isis 1
is-level level-2
#
ip address 10.2.1.2 255.255.255.0
isis enable 1
#
return
7.24.15 Example for Configuring Dynamic BFD for IS-IS

This part provides an example for configuring dynamic BFD for IS-IS to fast detect faults and
report them to IS-IS. In this manner, the fast switchover of service traffic is triggered.
As shown in Figure 7-18, it is required as follows:
l Run IS-IS on Router A, Router B, and Router C.

l Enable BFD of the IS-IS process on Router A, Router B, and Router C.

B → Router C acts as the standby link.
l Enable BFD of the interface on the link between Router A and Router B. When the link
between Router A and Router B fails, BFD can quickly detect the fault and notify IS-IS of
the fault; therefore, the traffic is transmitted on the standby link.
Figure 7-18 Networking diagram of configuring the dynamic BFD

RouterA GE2/0/0 GE2/0/0 RouterB GE3/0/0
3.3.3.1/24 3.3.3.2/24 172.16.1.1/24
GE1/0/0 GE1/0/0
1.1.1.1/24 2.2.2.2/24
GE1/0/0 GE2/0/0
1.1.1.2/24 2.2.2.1/24
RouterC
1. Enable IS-IS on each router and ensure the connectivity of the routers
2. Set the interface cost of IS-IS to control the route selection of the routers.
3. Enable global BFD.
4. Enable the BFD detection mechanism of the IS-IS process on Router A, Router B, and
Router C.
5. Enable the BFD detection mechanism of the interfaces on Router A and Router B.
Data Preparation
l Process ID of IS-IS
l Area numbers of Router A, Router B, and Router C
l Interface cost of Router A, Router B and Router C
l Interface number and type number of BFD enabled on Router A and Router B
l Minimum interval for sending the BFD packets, minimum interval for receiving the BFD
packets, and local detection multiple on Router A and Router B
Procedure


Step 2 Configure the basic IS-IS functions.
[RouterA] isis
[RouterB] isis
[RouterC] isis
# After the preceding configurations are complete, use the display isis peer command. You can
view that the neighboring relationship is set up between Router A and Router B, and that between
Router A and Router C. Take the configuration on Router A as an example:
----------------------------
0000.0000.0002 GE2/0/0 0000.0000.0002.01 Up 9s L2 64
0000.0000.0003 GE1/0/0 0000.0000.0001.02 Up 21s L2 64
Total Peer(s): 2
# The routers have learnt routes of each other. Take the routing table of Router A as an example:
------------------------------------------------------------------------------


2.2.2.0/24 ISIS-L2 15 20 D 1.1.1.2 GigabitEthernet1/0/0
As shown in the routing table, the next hop address of the route to 172.16.1.0/24 is 3.3.3.2 and
traffic is transmitted on the active link from Router A to Router B.
Step 3 Set the interface cost.
[RouterB-GigabitEthernet1/0/0] isis cost 5
Step 4 Configure BFD of the IS-IS process.
# Enable BFD of the IS-IS process on Router A.

[RouterA] bfd
[RouterA-bfd] quit
[RouterA] isis
[RouterA-isis-1] bfd all-interfaces enable
# Enable BFD of the IS-IS process on Router B.

[RouterB] bfd
[RouterB-bfd] quit
[RouterB] isis
[RouterB-isis-1] bfd all-interfaces enable
# Enable BFD of the IS-IS process on Router C.

[RouterC] bfd
[RouterC-bfd] quit
[RouterC] isis
[RouterC-isis-1] bfd all-interfaces enable
# After the preceding configurations are complete, run the display isis bfd session all command
on Router A, Router B, or Router C. You can view that the status of BFD is Up.
Take the display of Router A as an example:

[RouterA] display isis bfd session all
-----------------------------------
Peer System ID : 0000.0000.0002 Interface : GE2/0/0


Total BFD session(s): 2
From the preceding display, you can view that the status of the BFD session between Router A
and Router B and that between Router A and Router C are Up.
Step 5 Configure BFD of the interfaces.
# Configure BFD on GE 2/0/0 of Router A, set the minimum interval for sending the packets
and the minimum interval for receiving the packets to 100 ms, and set the local detection time
multiple to 4.
[RouterA-GigabitEthernet2/0/0] isis bfd enable
[RouterA-GigabitEthernet2/0/0] isis bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
# Configure BFD on GE 2/0/0 of Router B, set the minimum interval for sending the packets
and the minimum interval for receiving the packets to 100 ms, and set the local detection time
multiple to 4.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB-GigabitEthernet2/0/0] isis bfd enable
[RouterB-GigabitEthernet2/0/0] isis bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
# After the preceding configurations are complete, run the display isis bfd session all command
on Router A or Router B. You can view that the parameters of the BFD have taken effect. Take
the display of Router B as an example:
[RouterB] display isis bfd session all
-----------------------------------
Step 7 # Display the routing table on Router A.

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


As shown in the routing table, the standby link Router A → Router C → Router B takes effect
after the active link fails. The next hop address of the route to 172.16.1.0/24 becomes 1.1.1.2.
# Run the display isis bfd session all command on Router A. You can view the status of the
BFD session is Up between Router A and Router C.
[RouterA] display isis bfd session all
-----------------------------------
----End
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
#
undo shutdown
ip address 1.1.1.1 255.255.255.0
isis enable 1
#
undo shutdown
ip address 3.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 RouterB
#
bfd
#
isis 1

is-level level-2
network-entity 10.0000.0000.0002.00
#
undo shutdown
ip address 2.2.2.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 3.3.3.2 255.255.255.0
isis enable 1
isis cost 5
isis bfd enable
isis bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
return

#
sysname RouterC
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00
#
undo shutdown
ip address 1.1.1.2 255.255.255.0
isis enable 1
#
undo shutdown
ip address 2.2.2.1 255.255.255.0
isis enable 1
#
return
7.24.16 Example for Configuring Dynamic BFD for IPv6 IS-IS

This part provides an example for configuring dynamic BFD for fast failure detection to trigger
fast switchover of service traffic on IS-IS IPv6 networks.
Figure 7-19 shows an IS-IS IPv6 network. The primary path of traffic between Router S and
Router D is Router S-->Switch-->Router D, and the backup path is Router S-->Router N--
>Router D.

Figure 7-19 Networking diagram of dynamic BFD for IPv6 IS-IS

Router S GE1/0/0 Switch GE1/0/0 Router DGE3/0/0
2001:db8:1::1/64 2001:db8:1::2/64 2001:db8:4::1/64
GE
Primary path
20 2/0/ 0
01 0 /0 /
:db Backup path G E2 /64
8:2 :2
::1 8 :3:
/64 b
/64 :d
20
01 / 0 /0 :3::1 2001
:db GE1 2
GE 1:db
8
8:2 /0/ 0
::2 0 0
/64 Router N 2
It is required to configure BFD for IPv6 IS-IS so that traffic between Router S and Router D can
be rapidly switched to the backup path when the primary path or Switch fails.
1. Configure basic IS-IS IPv6 functions on each router to ensure the IPv6 connectivity.
2. Adjust the IS-IS cost values of interfaces on each router so that the path Router S-->Switch--
>Router D becomes the primary path, and the path Router S-->Router N-->Router D
becomes the backup path.
3. Configure BFD globally on each router.
4. Enable BFD for IPv6 IS-IS in the IS-IS view of each router.
Data Preparation
l IS-IS process ID
l IS-IS network entity title (NET)
l Level of each Router
l IS-IS cost value of each interface
l Interface to be enabled with BFD for IPv6 IS-IS
l Minimum interval for sending BFD packets, minimum interval for receiving BFD packets,
and local BFD detection multiplier
Procedure
Step 1 Enable IPv6 forwarding capability and configure an IPv6 address for each interface.
# The configurations of Router S are taken as an example. The configurations of other routers
are as the same as those of Router S and thus are not mentioned here.
[HUAWEI] sysname RouterS
[RouterS] ipv6

[RouterS] interface gigabitethernet 1/0/0

[RouterS-GigabitEthernet1/0/0] ipv6 enable
[RouterS-GigabitEthernet1/0/0] ipv6 address 2001:db8:1::1/120
# Configure Router S.
[RouterS] isis 10
[RouterS-isis-10] is-level level-2
[RouterS-isis-10] network-entity 10.0000.0000.0001.00
[RouterS-isis-10] ipv6 enable
[RouterS-isis-10] quit
[RouterS-GigabitEthernet1/0/0] isis ipv6 enable 10
[RouterS-GigabitEthernet1/0/0] quit
[RouterS-GigabitEthernet2/0/0] isis ipv6 enable 10
# Configure Router N.
[RouterN] isis 10
[RouterN-isis-10] is-level level-2
[RouterN-isis-10] network-entity 10.0000.0000.0002.00
[RouterN-isis-10] ipv6 enable
[RouterN-isis-10] quit
[RouterN] interface gigabitethernet 1/0/0
[RouterN-GigabitEthernet1/0/0] isis ipv6 enable 10
[RouterN-GigabitEthernet1/0/0] quit
[RouterN-GigabitEthernet2/0/0] isis ipv6 enable 10
[RouterD] isis 10
# After the preceding configurations, run the display ipv6 routing-table command. You can
view that routers have learned IPv6 routes from each other.
Step 3 Set the IS-IS cost value of each interface.
[RouterS-GigabitEthernet1/0/0] isis ipv6 cost 1 level-2
[RouterS-GigabitEthernet2/0/0] isis ipv6 cost 10 level-2
[RouterN-GigabitEthernet1/0/0] isis ipv6 cost 10 level-2


[RouterN-GigabitEthernet2/0/0] isis ipv6 cost 10 level-2
[RouterD-GigabitEthernet1/0/0] isis ipv6 cost 1 level-2
[RouterD-GigabitEthernet2/0/0] isis ipv6 cost 10 level-2
Step 4 Configure BFD for IPv6 IS-IS.
# On the Router S, Router N, and Router D, enable BFD for IPv6 IS-IS globally, set the minimum
interval for sending BFD packets to 150 ms and the minimum interval for receiving BFD packets
to 150 ms, and specify the local detection multiplier to 3.
[RouterS] bfd
[RouterS-bfd] quit
[RouterS] isis 10
[RouterS-isis-10] ipv6 bfd all-interfaces enable
[RouterS-isis-10] ipv6 bfd all-interfaces min-tx-interval 150 min-rx-interval 150
[RouterS-isis-10] quit
[RouterN] bfd
[RouterN-bfd] quit
[RouterN] isis 10
[RouterN-isis-10] ipv6 bfd all-interfaces enable
[RouterN-isis-10] ipv6 bfd all-interfaces min-tx-interval 150 min-rx-interval 150
[RouterN-isis-10] quit
[RouterD] bfd
[RouterD-bfd] quit
[RouterD] isis 10
[RouterD-isis-10] ipv6 bfd all-interfaces enable
[RouterD-isis-10] ipv6 bfd all-interfaces min-tx-interval 150 min-rx-interval 150
# After the preceding configurations, run the display isis ipv6 bfd session all command on
Router S or Router D, and you can view that BFD detection parameters already take effect. Take
the display on Router S as an example.
[RouterS] display isis 10 ipv6 bfd session all
-----------------------------------
Peer System ID : 0000.0000.0003 Interface : GE1/0/0 Type : L2
LocDis : 8184 Local IPv6 Address : FE80::E0:2F47:B107:1
RemDis : 8192 Peer IPv6 Address : FE80::E0:2F47:B103:1

LocDis : 8184 Local IPv6 Address : FE80::C964:0:B8B6:1
RemDis : 8192 Peer IPv6 Address : FE80::C964:0:B203:1


# Run the display ipv6 routing-table 2001:db8:4::1 120 command on Router S to check the
IPv6 routing table. You can view that the next hop address is 2001:2 and the outbound interface
is Gigabit Ethernet 1/0/0.
[RouterS] display ipv6 routing-table 2001:db8:4::1 120
Summary Count 1
Destination: 2001:db8:4:: PrefixLength : 120

NextHop: 2001:2 Preference : 15
Interface : GigabitEthernet1/0/0 Protocol : ISIS
State: Active Adv Cost : 20
Tunnel ID : 0x0 Label : NULL
Age : 93sec
# Run the shutdown command on Gigabit Ethernet 1/0/0 on Router D to simulate a primary
path failure.
[RouterD-GigabitEthernet1/0/0] shutdown
# Run the display ipv6 routing-table 2001:db8:4::1 120 command on Router S to view the
IPv6 routing table.
[RouterS] display ipv6 routing-table 2001:db8:4::1 120
Summary Count 1
Destination: 2001:db8:4:: PrefixLength : 120

NextHop: 2001:db8:2::2 Preference : 15
Interface : GigabitEthernet2/0/0 Protocol : ISIS
State: Active Adv Cost : 20
Tunnel ID : 0x0 Label : NULL
Age : 93sec
As shown in the IPv6 routing table, after the primary path fails, the backup path takes effect; the
next hop address of the route to 2001:db8:4::/120 becomes 2001:db8:2::2; the outbound interface
becomes Gigabit Ethernet 2/0/0; the route cost may also change.
# Run the display isis ipv6 bfd session all command on Router S, and you can view that there
is only one BFD session in the Up state between Router S and Router N.
[RouterS] display isis 10 ipv6 bfd session all
-----------------------------------
LocDis : 8184 Local IPv6 Address : FE80::C964:0:B8B6:1
RemDis : 8192 Peer IPv6 Address : FE80::C964:0:B203:1
----End
Configuration Files
l Configuration file of Router S
#
sysname RouterS
#
bfd

#
isis 10
is-level level-2
ipv6 bfd all-interfaces min-tx-interval 150 min-rx-interval 150
network-entity 10.0000.0000.0001.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
isis ipv6 cost 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
isis ipv6 cost 10
#
return
l Configuration file of Router N

#
sysname RouterN
#
bfd
#
isis 10
is-level level-2
network-entity 10.0000.0000.0002.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
isis ipv6 cost 10
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
isis ipv6 cost 10
#
return

#
sysname RouterD
#
bfd
#
isis 10
is-level level-2

network-entity 10.0000.0000.0003.00
#
#
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
isis ipv6 cost 1
#
undo shutdown
ipv6 enable
isis ipv6 enable 10
isis ipv6 cost 10
#
return
l Configuration file of Switch

Configuration file of Switch is not mentioned here.

Configuration Guide - IP Routing 8 BGP Configuration
8 BGP Configuration
About This Chapter
BGP is used between ASs to transmit routing information on large-scale and complex networks.
8.1 Introduction
BGP is a dynamic routing protocol used between ASs.
8.2 Configuring the Format of BGP 4-Byte AS Numbers

You can change the format of Border Gateway Protocol (BGP) 4-byte autonomous system (AS)
numbers to your desired format.
8.3 Configuring Basic BGP Functions

Configuring basic BGP functions is the prerequisite to building a BGP network.
8.4 Configuring BGP Route Attributes

BGP has many route attributes. Configuring route attributes can change route selection results.
8.5 Configuring BGP to Advertise Routes

BGP is used to transmit routing information. BGP advertises only the wanted routes after filtering
routes to be advertised, and modifies route attributes to direct network traffic.
8.6 Configuring BGP to Receive Routes

BGP is used to transmit routing information. BGP can filter received routes to accept only the
expected routes, and can modify route attributes to direct network traffic.
8.7 Configuring a Device to Advertise BGP Supernet Unicast Routes to BGP Peers
This section describes how to configure a Border Gateway Protocol (BGP) device to advertise
BGP supernet unicast routes to BGP peers.
8.8 Configuring BGP Route Aggregation

Configuring BGP Route Aggregation on a device can reduce the sizes of routing tables on the
peers of the device.
8.9 Configuring BGP Peer Groups

Configuring BGP peer groups simplifies the BGP network configuration and improves the route
advertisement efficiency.
8.10 Configuring BGP Route Reflectors

Deploying BGP RRs allows IBGP peers to communicate without establishing full-mesh
connections between them. Using BGP RRs simplifies network configurations and improves
route advertisement efficiency.
8.11 Configuring a BGP Confederation
BGP confederations can be configured on a large BGP network to reduce the number of IBGP
connections and simplify routing policy management, increasing route advertisement efficiency.
8.12 Configuring BGP Community Attributes
Community attributes are used to simplify routing policy management.
8.13 Configuring Prefix-based BGP ORF
Prefix-based BGP outbound route filtering (ORF) is used to enable a BGP device to send to its
BGP peer a set of routing policies that can be used by its peer to filter out unwanted routes during
route advertisement.
8.14 Configuring to Adjust the BGP Network Convergence Speed
You can adjust the BGP network convergence speed by adjusting BGP peer connection
parameters to adapt to changes on large-scale networks.
8.15 Configuring BGP Route Dampening
BGP route dampening can be configured to suppress unstable routes.
8.16 Configuring a BGP Device to Send a Default Route to Its Peer
After a BGP device is configured to send a default route to its peer, the BGP device sends a
default route with the local address as the next-hop address to a specified peer, regardless of
whether there are default routes in the local routing table. This greatly reduces the number of
routes on the network.
8.17 Configuring BGP Load Balancing
Configuring BGP load balancing better utilizes network resources and reduces network
congestion.
8.18 Configuring Path MTU Auto Discovery
Path MTU auto discovery allows BGP to discover the smallest MTU value on a path to ensure
that BGP messages satisfy the path MTU requirement. This function improves transmission
efficiency and BGP performance.
8.19 Configuring the BGP Next Hop Delayed Response
Configuring the BGP next hop delayed response can minimize traffic loss during route changes.
8.20 Configuring BFD for BGP
BFD for BGP speeds up fault detection and therefore increases the route convergence speed.
8.21 Configuring BGP Auto FRR
Border Gateway Protocol (BGP) Auto fast reroute (FRR), a protection measure against link
faults, applies to the network topology with both primary and backup links. It can be configured
for services that are sensitive to packet loss and delay.
8.22 Configuring BGP GR
BGP GR can be configured to avoid traffic interruption due to protocol restart.
8.23 Configuring BGP Security
Authentication can be implemented during the establishment of a TCP connection to enhance
BGP security.
8.24 Disabling the BGP-IPv4 Unicast Address Family

If you do not need to use BGP to transmit public IPv4 unicast routes, you can disable the BGP-
IPv4 unicast address family to reduce the consumption of system resources.
8.25 Applying BGP AS_Path Regular Expressions
8.26 Maintaining BGP

Maintaining BGP involves resetting a BGP connection and clearing BGP statistics.
8.27 BGP Route Selection Rules

BGP configuration examples explain networking requirements, networking diagram,
configuration notes, configuration roadmap, and configuration procedure.

8.1 Introduction
BGP is a dynamic routing protocol used between ASs.
8.1.1 BGP Overview

The Border Gateway Protocol (BGP) advertises and maintains a large number of routes between
autonomous systems (ASs).
Background
When Internal Gateway Protocol (IGP) was first deployed, it was able to meet network
deployment requirements because networks were not as large as they now are. However,
increasing numbers of routes on large modern networks impose tough challenges on the
performance of devices. To solve this problem, ASs were introduced. One IGP runs within an
AS, and one Exterior Gateway Protocol (EGP) runs between ASs.
EGP, however, has the following shortcomings: It forwards routes without selecting optimal
routes and therefore cannot avoid loops. Therefore, EGP was replaced with BGP.
BGP overcomes these shortcomings and can advertise and maintain a large number of routes
more efficiently. BGP is deployed between ASs that may be under different technical
administrations. Therefore, BGP must have powerful routing control capabilities and can be
easily extended so that network security can be ensured.
BGP-1 (defined in RFC 1105), BGP-2 (defined in RFC 1163), and BGP-3 (defined in RFC 1267)
are three earlier-released versions of BGP. The current BGP version is BGP-4 defined in RFC
4271. As an exterior routing protocol on the Internet, BGP is widely used among Internet Service
Providers (ISPs).
NOTE
This document refers to BGP-4, unless stated otherwise.
BGP Characteristics
Characteristics of BGP are as follows:
l Different from IGPs such as the Open Shortest Path First (OSPF) and Routing Information
Protocol (RIP), BGP is an EGP, which controls route advertisement and selects the optimal
route between ASs rather than discover or calculate routes.
l BGP uses the Transport Control Protocol (TCP) with port number 179 as the transport layer
protocol. The reliability of BGP is therefore enhanced.
l BGP supports Classless Inter-Domain Routing (CIDR).
l BGP transmits only the updated routes, saving the bandwidth used for route distribution.
Therefore, BGP is applicable to the Internet where a large number of routes are transmitted.
l BGP eliminates routing loops by adding AS_Path information to BGP routes.
l BGP provides multiple routing policies for flexible route selection and filtering.
l BGP can be easily extended and can adapt to the development of networks.

Related Terms
BGP is an inter-AS dynamic routing protocol and can be classified into IBGP and EBGP when
running on the router.
l AS: Planned by a technical administration, an AS accommodates a series of routers. The

AS number is allocated by a dedicated institute.
l IBGP (Internal BGP): When BGP runs within an AS, it is called IBGP.
l EBGP (External BGP): When BGP runs between ASs, it is called EBGP.
Figure 8-1 shows the relationships among AS, IBGP, and EBGP.
Figure 8-1 AS, IBGP, and EBGP
EBGP
AS65001
IBGP
EBGP
AS65002
IBGP
EBGP
EBGP
AS65003
8.1.2 BGP Features Supported by the NE80E/40E

This section describes BGP features supported by the NE80E/40E from the perspective of BGP
configurations.
BGP enables routes to be transmitted between ASs more efficiently and flexibly. Table 8-1
shows the BGP configuration outline.
Table 8-1 BGP configuration outline
Configuration Configuration Procedure Note

Objective
To transmit BGP l 8.3 Configuring Basic BGP The configuration is mandatory.

routes. Functions NOTE
This configuration enables basic
BGP functions and is a prerequisite
for the following configurations.


Objective
To control the l 8.4 Configuring BGP Route These configurations are

advertising and Attributes optional.
receiving of BGP l 8.5 Configuring BGP to Before the configuration,
routes. Advertise Routes familiarize yourself with the
l 8.6 Configuring BGP to following:
Receive Routes l Route Attributes
l 8.16 Configuring a BGP l Principles of Route
Device to Send a Default Selection
Route to Its Peer l Principles for BGP Route
Advertisement
To use network l 8.17 Configuring BGP The configuration is optional.

resources efficiently Load Balancing Before the configuration,
and reduce network familiarize yourself with the
congestion. following:
l Routing Selection
Principles for Load
Balancing
To simplify the l 8.9 Configuring BGP Peer These configurations are

configuration and Groups optional.
management of a l 8.10 Configuring BGP Before the configuration,
large-scale BGP Route Reflectors familiarize yourself with the
network. following:
l 8.11 Configuring a BGP
Confederation l Configuring and Managing
l 8.12 Configuring BGP a Large-Scale BGP
Community Attributes Network
To suppress route l 8.15 Configuring BGP These configurations are

flapping and improve Route Dampening optional.
route transmission l 8.8 Configuring BGP Route Before the configuration,
efficiency. Aggregation familiarize yourself with the
l 8.13 Configuring Prefix- following:
based BGP ORF l Suppressing Route
l 8.18 Configuring Path Flapping and Improving
MTU Auto Discovery the Efficiency of Route
Transmission


Objective
To adjust BGP route l Modifying values of BGP These configurations are

convergence. timers optional.
1. 8.14.2 Configuring a Before the configuration,
BGP ConnectRetry familiarize yourself with the
Timer following:
2. 8.14.3 Configuring BGP l Adjusting BGP Route
Keepalive and Hold Convergence Speed
Timers
3. 8.14.4 Configuring a
MinRouteAdvertise-
mentIntervalTimer
l 8.14.7 Enabling BGP Peer
Tracking
l 8.14.6 Disabling Fast Reset
of EBGP Connections
l 8.19 Configuring the BGP
Next Hop Delayed
Response
To improve BGP l 8.20 Configuring BFD for These configurations are

network reliability. BGP optional.
l 8.21 Configuring BGP Before the configuration,
Auto FRR familiarize yourself with the
l 8.22 Configuring BGP GR following:
l NSR l Improving BGP Network

Reliability
To improve BGP l Message Digest 5 (MD5) and These configurations are

network security. keychain authentication optional.
1. 8.23.2 Configuring MD5 Before the configuration,
Authentication familiarize yourself with the
2. 8.23.3 Configuring following:
Keychain l Improving BGP Network
Authentication Security
l 8.23.4 Configuring BGP
GTSM
l Limit the number of the
routes received from a peer
or peer group
l Set the maximum number
of AS numbers in the
AS_Path attribute

Route Attributes
Based on route attributes, BGP routes are selected and the network administrator deploys routing
policies. Table 8-2 shows the main route attributes.
Table 8-2 Main route attributes
Attribute Description Reference Chapter
PrefVal Huawei-specific attribute, valid See 8.4.3 Configuring

only on the device where it is Preferred Values for BGP
configured. Routes.
Local_Pref Determines the optimal route for See 8.4.4 Configuring a Default
the traffic that leaves an AS. Local_Pref Attribute for a
When the device running BGP Device.
receives multiple routes to the
same destination address but
with different next hops from
different IBGP peers, the route
with the highest Local_Pref is
selected as the optimal route.
Multi-Exit Determines the optimal route for See 8.4.5 Configuring MED
Discriminator (MED) the traffic that enters an AS. It is Attributes for BGP Routes.
similar to the metric used by an
IGP.
When the device running BGP
receives multiple routes to the
same destination address but
with different next hops from
different EBGP peers, the route
with the lowest MED is selected
as the optimal route.
Next_Hop BGP discards the route with an See 8.4.6 Configuring

unreachable next hop address. Next_Hop Attributes for
Routes.
AS_Path Records all ASs that a route See 8.4.7 Configuring AS_Path
passes through from the local Attributes for Routes.
end to the destination in the
distance-vector (DV) order.
AS_Path has the following
functions:
l Prevents routing loops
among ASs.
l Determines the selection of
the optimal route. (The BGP
route with the shortest
AS_Path is selected as the
optimal route.)

Principles of Route Selection

On the NE80E/40E, when there are multiple active routes to the same destination, BGP selects
routes according to the following principles:
NOTE
BGP selects routes by comparing the route attributes in the following sequence. When the optimal route
is selected based on the first route attribute, the subsequent attributes will be ignored.
1. Prefers the route with the highest PreVal.

PrefVal is a Huawei-specific attribute, valid only on the Huawei device where it is
configured.
2. Prefers the route with the highest Local_Pref.
If a route carries no Local_Pref, 100 or the value set using the default local-preference
command is considered as its default Local_Pref value.
3. Prefers a locally originated route. A locally originated route takes precedence over a route
learned from a peer.
Locally originated routes include routes imported using the network command or the
import-route command, manually summarized routes, and automatically summarized
routes.
a. A summarized route is preferred, and takes precedence over a non-summarized route.
b. A route obtained using the aggregate command is preferred over a route obtained
using the summary automatic command.
c. A route imported using the network command is preferred over a route imported using
the import-route command.
4. Prefers a route that carries the Accumulated Interior Gateway Protocol Metric (AIGP)
attribute.
l The priority of a route that carries the AIGP attribute is higher than the priority of a
route that does not carry the AIGP attribute.
l If two routes both carry the AIGP attribute, the route with a smaller AIGP attribute value
plus IGP metric of the iterated next hop is preferred over the other route.
5. Prefers the route with the shortest AS_Path.
l The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the
AS_Path length.
l An AS_SET counts as 1, regardless of how many ASs are in the set.
l After the bestroute as-path-ignore command is run, the AS_Path attributes of routes
are not compared in the route selection process.
6. Prefers the route with the highest Origin type. IGP is higher than EGP, and EGP is higher
than Incomplete.
7. Prefers the route with the lowest Multi—Exit Discriminator (MED).
l The MEDs of routes only from the same AS (but not a confederation sub-AS) are
compared. MEDs of two routes are compared only when the first AS number in the
AS_SEQUENCE (excluding AS_CONFED_SEQUENCE) is the same for the two
routes.

l A route without MED is assigned a MED of 0, unless the bestroute med-none-as-

maximum command is run. If the bestroute med-none-as-maximum command is run,
the route is assigned the highest MED of 4294967295.
l After compare-different-as-med command is run, the MEDs in routes received from
peers in different ASs are compared. If this command is run without first confirming
that different ASs use the same IGP and route selection mode, a loop may occur.
l If the bestroute med-confederation command is run, MEDs are compared for routes
that consist only of AS_CONFED_SEQUENCE. The first AS number in the
AS_CONFED_SEQUENCE must be the same for the routes.
l After the deterministic-med command is run, routes are not selected in the sequence
in which routes are received.
8. Prefers EBGP routes over IBGP routes.
EBGP is higher than IBGP, IBGP is higher than LocalCross, and LocalCross is higher than
RemoteCross.
If the export route target (ERT) of a Virtual Private Network version 4 (VPNv4) route in
the routing table of a VPN instance on a provider edge (PE) matches the import route target
(IRT) of another VPN instance on the PE, the VPNv4 route will be added to the routing
table of the second VPN instance. This is called LocalCross. If the ERT of a VPNv4 route
from a remote PE is learned by the local PE and matches the IRT of a VPN instance on the
local PE, the VPNv4 route will be added to the routing table of that VPN instance. This is
called RemoteCross.
9. Prefers the route with the lowest IGP metric to the BGP next hop.
After the bestroute igp-metric-ignore command is run, the IGP metrics are not compared
for routes during route selection.
NOTE
Assume that load balancing is configured. If the preceding rules are the same and there are multiple
external routes with the same AS_Path, load balancing will be performed based on the number of
configured routes.
10. 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.
11. Prefers the route advertised by the device with the smallest router ID.
NOTE
If routes carry the Originator_ID, the originator ID is substituted for the router ID during route
selection. The route with the smallest Originator_ID is preferred.
12. Prefers the route learned from the peer with the smallest address if the IP addresses of peers
are compared in the route selection process.
Principles for BGP Route Advertisement

On the NE80E/40E, BGP advertises routes based on the following principles:
l When there are multiple active routes, the BGP speaker advertises only the optimal route
to its peer.
l The BGP speaker advertises only the preferred routes to its peer.

l The BGP speaker advertises the routes learned from EBGP peers to all BGP peers
(including EBGP and IBGP peers) except the peers that advertise these routes.
l The BGP speaker does not advertise the routes learned from IBGP peers to its IBGP peers.
l The BGP speaker advertises the routes learned from IBGP peers to its EBGP peers.
l The BGP speaker advertises all preferred BGP routes to the new peers when peer
relationships are established.
Routing Selection Principles for Load Balancing

In BGP, the next-hop address of a generated route may not be the address of the peer that is
directly connected to the local device. One common scenario is that the next hop is not changed
when a route is advertised between IBGP peers. Therefore, before forwarding a packet, the
device must find a directly reachable address, through which the packet can reach the next hop
specified in the routing table. In this process, the route to the directly reachable address is called
a dependent route. BGP routes depend on these dependent routes for packet forwarding. The
process of finding a dependent route based on the next-hop address is called route iteration.
The NE80E/40E supports iteration-based BGP load balancing. If load balancing is configured
for a dependent route (assume that there are three next-hop addresses), BGP generates the same
number of next-hop addresses to forward packets. BGP load balancing based on iteration does
not need to be configured by using commands. This feature is permanently enabled on the
NE80E/40E.
BGP load balancing is different from IGP load balancing in the following implementation
methods:
l In IGPs, if there are different routes to the same destination address, an IGP calculates
metrics of these routes based on its own routing algorithm and performs load balancing
among the routes with the same metric.
l BGP does not have a routing algorithm, and therefore cannot determine whether to perform
load balancing among routes based on explicit metrics. However, BGP contains many route
attributes, which have different priorities in route selection principles. As a result, BGP
performs load balancing according to route selection principles. Specifically, load
balancing is performed according to the configured maximum number of equal-cost routes
only when all the routes have the same high preference.
NOTE
l By default, BGP performs load balancing only among the routes with the same AS_Path attribute. You
can use the bestroute as-path-ignore
command to configure BGP not to compare the AS_Path attribute of routes when performing load
balancing.
l BGP load balancing is also applicable between ASs in a confederation.
Configuring and Managing a Large-Scale BGP Network

The configuration and maintenance of a large-scale BGP network is difficult. To facilitate BGP
network maintenance and management, you can configure peer groups, community, route
reflector, or confederation as required. Table 8-3 lists these solutions.

Table 8-3 Solutions to configuring and managing a large-scale BGP network
Solution Main Objectives Feature Defect
Peer group To improve A peer group is a group -

configuration of peers with the same
efficiency and route routing policies. After
advertisement a peer is added to a peer
efficiency. group, it inherits the
configurations of this
peer group. When the
configurations of the
peer group are
changed, the
configurations of peers
in this group are
changed accordingly.
Route reflector To simplify network In an AS, one device -

(RR) configurations and functions as a route
improve configuration reflector and other
efficiency by devices function as
minimizing full-mesh clients. The clients
IBGP connections establish IBGP
within an AS. connections with the
RR. The RR reflects
routes among the
clients, and therefore
BGP connections do
not need to be
established between
the clients.
Confederation To simplify network It divides an AS into The device needs to be

configurations and several sub-ASs. A reconfigured when the
improve configuration full-mesh connection is network deployment
efficiency by established between mode is switched from
minimizing full-mesh every two IBGP peers non-confederation to
IBGP connections in each sub-AS, and an confederation. After
within an AS. EBGP connection is the reconfiguration, the
established between logical topology
every two sub-ASs. changes accordingly.

Solution Main Objectives Feature Defect
Community To simplify routing The peers in a peer -

policy application and group share the same
network maintenance policy, while the
and management. community allows
devices from different
ASs to share the same
policy. The community
attribute is a route
attribute. It is
transmitted between
BGP peers and is not
restricted by the AS.
Suppressing Route Flapping and Improving the Efficiency of Route Transmission

On a large-scale network, frequent route flapping consumes a great deal of system resources.
To address this problem, you can configure route dampening and route aggregation.
To reduce the number of routes exchanged between BGP peers, you can configure route
aggregation. To improve the efficiency of BGP route transmission, you can configure BGP
outbound route filtering (ORF).
In addition, BGP peers need to exchange BGP messages frequently. To improve the efficiency
of BGP message transmission, you can configure path maximum transmission unit (MTU) auto
discovery.
Table 8-4 shows solutions to suppressing route flapping and improving the efficiency of route
transmission.
Table 8-4 Solutions to suppressing route flapping and improving the efficiency of route
transmission
Solution Objective Feature Note
Route To prevent bandwidths Route dampening is -

dampening and Central Processing used to address the
Unit (CPU) resources problem of route
from being excessively instability. Route
consumed in case of instability is reflected
frequent route flapping by route flapping (a
and ensure proper route in a routing table
network operation. disappears and
reappears frequently).

Route To reduce the size of a Multiple routes can be The NE80E/40E

aggregation routing table and the summarized. After the supports automatic and
number of routes that aggregation, a router manual aggregation.
need to be transmitted can advertise only Manual aggregation
to BGP peers. summarized routes to can be used to control
To suppress route BGP peers. the attributes of the
flapping caused by summarized route and
specific routes. determine whether to
advertise specific
routes.
BGP ORF To improve the Based on an IP prefix Currently, only IP

efficiency of BGP list, BGP ORF allows prefix list-based export
route transmission. BGP routes to be policies are supported.
advertised as required.
Routes to be advertised
are filtered by the
export policy.
Therefore, only routes
that peers need are
advertised to peers.
BGP path To improve the Path MTU auto -

MTU auto efficiency of BGP discovery discovers the
discovery message transmission. smallest MTU on a
path for the
Transmission Control
Protocol (TCP) to
transmit BGP
messages. This feature
prevents BGP
messages from being
re-fragmented during
transmission.
Adjusting BGP Route Convergence Speed

BGP route convergence speed is an important indicator used in evaluating network performance.
Multiple solutions can be deployed on the NE80E/40E to adjust BGP route convergence speed.
Table 8-5 lists the details.

Table 8-5 Solutions to adjusting BGP route convergence speed
BGP timer To adjust BGP route Multiple timers are Keeping the default
modification convergence speed. used in maintaining values of timers is
BGP neighbor recommended because
relationships. The modifying the timer
timer values determine values may interrupt
the speed at which a BGP peer
fault on the network is relationships.
detected, and BGP peer
relationships are
established after the
fault is rectified.
Rapid EBGP To accelerate the Rapid EBGP Rapid EBGP

connection EBGP session fault connection reset allows connection reset is
reset detection and route BGP to detect EBGP applicable to EBGP
convergence. link faults promptly, peers only.
delete the direct EBGP
session on an interface,
and reset the EBGP
session on another
interface.
BGP peer To adjust BGP route BGP peer tracking can Bidirectional
tracking convergence speed. speed up BGP route forwarding detection
convergence by (BFD) for BGP can
adjusting the interval also speed up fault
between peer detection and route
unreachability convergence.
discovery and However, BFD for
connection BGP needs to be
interruption. deployed on the entire
network and has poor
extensibility. If BFD
for BGP cannot be
deployed on the
network, BGP peer
tracking is
recommended because
it is simple to deploy
and has better
extensibility.

Next hop To speed up BGP route Next hop delayed The BGP next hop
delayed convergence and response allows a BGP delayed response is
response minimize traffic loss. peer to delay applicable only to the
responding to the next scenario where
hop unreachable event multiple links are
and to respond to this available between the
event only after the next hop and the
switched route is destination. If there is
available. Therefore, only one link between
the volume of traffic the next hop and the
lost during a route destination,
switchover is configuring the BGP
minimized. next hop delayed
response may increase
the volume of traffic
lost during a link
failure because link
switching is not
possible in this case.
Improving BGP Network Reliability

As the society develops, services such as Internet Protocol television (IPTV), voice, video, and
real-time conferencing require higher network reliability. Table 8-6 lists solutions to improving
Table 8-6 Solutions to improving network reliability
BFD for BGP To speed up fault BFD for BGP is used to -

detection on a BGP detect faults on the link
network. between BGP peers
and notify the fault to
BGP, speeding up BGP
route convergence.

BGP Auto fast To switch services After BGP Auto FRR is In most cases, BFD for
reroute (FRR) immediately in case of enabled on a router, the BGP and BGP Auto
a link failure. router selects the FRR are used together.
optimal route from the BGP Auto FRR takes
routes to the same effect based on the
destination network. In BFD detection result.
addition, the router
automatically adds
information about the
second optimal route to
the backup forwarding
entries of the optimal
route and delivers the
backup forwarding
entry to the forwarding
information base (FIB)
table.
When the active link
becomes faulty, the
system can switch the
traffic immediately to
the standby link. This
process is irrelevant to
route convergence.
Therefore, services are
interrupted only for a
short period of time.
Graceful To avoid traffic When BGP restarts, the -

restart (GR) interruption in case of peer relationship is re-
a BGP restart. established and traffic
forwarding is
interrupted. After GR
is enabled, traffic
interruption can be
avoided.

Non-stop To ensure that the NSR ensures that route NSR is enabled by
routing (NSR) forwarding plane can processing is not default.
function properly even interrupted on the
if the control plane is control and forwarding
faulty. planes during a master/
slave MPU switchover
using the backup
mechanism of a related
protocol.
NSR does not depend
on or affect the remote
peer, and there is no
communication failure
arising from NSR.
Improving BGP Network Security

In most cases, different ASs are under different technical administrations and therefore do not
fully trust each other. To improve BGP network security, the following solutions are available,
as listed in Table 8-7.

Table 8-7 Solutions to improving BGP network security
Solution Main Objectives Main Features Note
MD5 and To check the identity BGP MD5 BGP MD5

keychain of BGP peers and authentication sets an authentication and
authentication prevent packets from MD5 authentication BGP keychain
being tampered with password for a TCP authentication are
by unauthorized users. connection. The mutually exclusive.
authentication is BGP keychain
performed by TCP. If authentication ensures
the authentication fails, higher security than
no TCP connections BGP MD5
can be established. authentication.
BGP keychain l The MD5 algorithm
authentication must be is easy to configure
configured on both and generates a
ends of a BGP single password
connection. A TCP which can only be
connection can be set changed manually.
up and BGP messages MD5
can be exchanged only authentication
when the two ends applies to the
share the same network requiring
password and short-period
encryption algorithms. encryption.
l The keychain
algorithm is
complex to
configure and
generates a set of
passwords.
Keychain
authentication
allows passwords to
be changed
automatically based
on configurations.
Therefore,
keychain
authentication is
applicable to
networks requiring
high security.

Solution Main Objectives Main Features Note
Generalized To protect services The GTSM checks -

TTL security above the IP Layer and TTL values to defend
mechanism improve system against attacks. The
(GTSM) security. GTSM checks whether
the TTL value in the IP
packet header is within
a pre-defined range. If
the TTL value is
beyond the range, the
IP packet is discarded.
Limiting the To prevent system You can limit the -

number of resources from being number of routes
routes received exhausted by excessive received from a
from peers routes received from specified peer or peer
peers. group.
AS_Path To discard routes You can specify upper If the upper limit is set
length carrying an AS_Path limits for the incoming too small, routes are
protection with its length and outgoing AS_Path lost.
exceeding the preset routes. A route is
upper limit. discarded if the
AS_Path length
exceeds the preset
upper limit.
Multi-Protocol Extensions for BGP-4 (MP-BGP)

Conventional BGP-4 manages only IPv4 routing information. The inter-AS transmission of
packets using other network layer protocols (such as IPv6) is limited.
To support multiple network layer protocols, the Internet Engineering Task Force (IETF) extends
BGP-4 to MP-BGP. RFC 2858 defines the MP-BGP standard.
The devices can communicate with each other, irrespective of whether they support MP-BGP.
BGP uses address families to distinguish different network layer protocols. For the values of
address families, refer to RFC 1700 (Assigned Numbers). Multiple MP-BGP extension
applications, such as VPN extensionIPv6 extension, can be configured in their respective address
family views.
NOTE
This chapter does not detail commands for specified applications in the MP-BGP address family view.
For configuration details in the BGP IPv6 address family view, see "BGP4+ configuration". For MP-BGP
applications in multicast, see "MP-BGP configuration" in HUAWEI NetEngine80E/40E Router
Configuration Guide-IP Multicast.
For configuration details in the BGP VPNv4 address family, BGP VPN instance address family, and BGP
Layer 2 Virtual Private Network (L2VPN) address family views, see HUAWEI NetEngine80E/40E Router
Configuration Guide-VPN.

8.2 Configuring the Format of BGP 4-Byte AS Numbers

You can change the format of Border Gateway Protocol (BGP) 4-byte autonomous system (AS)
numbers to your desired format.
By default, a BGP 4-byte AS number is displayed in dotted notation. To use integral 4-byte AS
numbers, perform this configuration task to display 4-byte AS numbers as integers.
NOTICE
Changing the format of 4-byte AS numbers will affect matching results of AS_Path regular
expressions and extended community attribute filters. Therefore, if the system is using an
AS_Path regular expression or an extended community attribute filter as an import or export
policy, you must reconfigure an AS_Path regular expression using the ip as-path-filter
command or an extended community attribute filter using the ip extcommunity-filter command
after changing the format of 4-byte AS numbers. This reconfiguration ensures that routes match
the import or export policy.
l If integral 4-byte AS numbers are configured, you must change 4-byte AS numbers in
AS_Path regular expressions and extended community attribute filters to integral 4-byte
AS numbers.
l If 4-byte AS numbers in dotted notation are configured, you must change 4-byte AS
numbers in AS_Path regular expressions and extended community attribute filters to 4-byte
AS numbers in dotted notation.
Procedure
Step 1 Run:
system-view
Step 2 Run:
as-notation plain
BGP 4-byte AS numbers are configured to display in integers.
NOTE
After you run the as-notation plain command, BGP 4-byte AS numbers are displayed in integers in display
commands but are still displayed in dotted notation in the configuration file.
----End

After configuring the format of BGP 4-byte AS numbers, perform the following operations to
check the configuration:

l Run the display bgp peer [ [ ipv4-address ] verbose ] command to check the format of
BGP 4-byte AS numbers.
l Run the display bgp routing-table command to check the matching results of BGP routes
against AS_Path regular expressions.
# The following is an example before the as-notation plain command is run. In this example,
the 4-byte AS numbers are displayed in dotted notation (see 1.1 and 1.2 in the command output).
<HUAWEI> display bgp peer

Local AS number : 1.1

PrefRcv
10.1.1.1 4 1.2 28 29 0 00:26:36 Established

0
10.1.2.2 4 65001 2 2 0 00:00:21 Established
0
# The following is an example after the as-notation plain command is run. In this example, 4-
byte AS numbers 1.1 and 1.2 have been changed to the integers 65537 and 65538.


PrefRcv
10.1.1.1 4 65538 28 29 0 00:26:51 Established

0
10.1.2.2 4 65001 2 2 0 00:00:36 Established
0
# The following is an example of running the display bgp routing-table command after the as-
notation plain command is run. In this example, the AS number in the AS_Path regular
expression is an integer (65537), and the corresponding information is displayed.
<HUAWEI> display bgp routing-table regular-expression ^65537

*> 1.1.1.1/32 10.1.1.1 0 0 65537?

*> 2.2.2.2/32 10.1.1.1 0 0 65537?
# The following is an example of running the display bgp routing-table command after the as-
notation plain command is run. In this example, the AS number in the AS_Path regular
expression is in dotted notation (1.1), and no corresponding information is displayed.
<HUAWEI> display bgp routing-table regular-expression ^1.1
This example shows that the AS number 65537 in the AS_Path list does not match the AS number
in the AS_Path regular expression.

8.3 Configuring Basic BGP Functions

Configuring basic BGP functions is the prerequisite to building a BGP network.

Basic BGP functions must be configured first when you build up a BGP network.
BGP can be configured on a network to implement communication among ASs. This section
describes how to configure basic BGP functions.
Because BGP uses TCP connections, you need to specify the IP address of the peer when
configuring BGP. The BGP peer may not be the neighboring router. The BGP peer relationship
can also be established by using logical links. Loopback interface addresses are usually used to
establish BGP connections to enhance the stability of these connections.
Configuring basic BGP functions includes the following steps:

l Start BGP processes. This step is a prerequisite for configuring basic BGP functions.
l Establish BGP peer relationships: Devices can exchange BGP routing information only
after they are configured as peers and establish peer relationships.
l Import routes. BGP itself cannot discover routes. Instead, it imports routes discovered by
other protocols to implement communication between ASs.
NOTE
The commands in the BGP-IPv4 unicast address family view can be run in the BGP view. These commands
are described in the BGP-IPv4 unicast address family view in configuration files.
Before configuring basic BGP functions, complete the following task:
the link layer protocol on the interfaces is Up
Data Preparation
To configure basic BGP functions, you need the following data.
No. Data
1 Local AS number and router ID
2 IPv4 address and AS number of a peer
3 Interface originating an Update message

8.3.2 Starting a BGP Process

Starting a BGP process is a prerequisite for configuring basic BGP functions. When starting a
BGP process on a device, specify the number of the AS to which the device belongs.
Context
Perform the following steps on the router where a BGP connection needs to be established:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp { as-number-plain | as-number-dot }
BGP is enabled (the local AS number is specified), and the BGP view is displayed.

router-id ipv4-address
A router ID is set.
Configuring or changing the router ID of BGP causes the BGP peer relationship between
routers to be reset.
NOTE
To enhance network reliability, configuring a loopback interface address as the router ID is recommended.
If no router ID is set, BGP automatically selects the router ID in the system view as the router ID of BGP.
For the rule for selecting a router ID in the system view, see the router-id command .
----End
8.3.3 Configuring BGP Peers

Two devices can exchange BGP routing information only after a peer relationship is establishsd
between them.
Context
Because BGP uses TCP connections, you need to specify IP addresses for peers when
configuring BGP. Two BGP peers are not necessarily neighbors of each other. Such BGP peers
establish a BGP peer relationship through a logical link. Using loopback interface addresses to
set up BGP peer relationships improves the stability of BGP connections, and therefore is
recommended.
IBGP peer relationships are established between devices within an AS. EBGP peer relationships
are established between devices in different ASs.
Procedure
l Configure an IBGP peer.

1. Run:
system-view

2. Run:
The BGP view is displayed.

3. Run:
peer ipv4-address as-number { as-number-plain | as-number-dot }
The IP address of a peer and the number of the AS where the peer resides are specified.
The number of the AS where the specified peer resides must be the same as that of
the local AS.
The IP address of the specified peer can be one of the following types:
– IP address of an interface on a directly connected peer

– IP address of a loopback interface on a reachable peer
– IP address of a sub-interface on a directly connected peer
4. Run:
peer ipv4-address connect-interface interface-type interface-number
[ ipv4-source-address ]
The source interface and source address are specified for a TCP connection.
By default, BGP uses the physical interface that is directly connected to the peer as
the local interface of a TCP connection.
NOTE
When loopback interfaces are used to establish a BGP connection, run the peer connect-
interface command at both ends of the connection to ensure that the connection is correctly
established. If this command is run on only one end, the BGP connection may fail to be
established.
5. (Optional) Run:
peer ipv4-address description description-text
A description is configured for the peer.
Configuring a description for a peer simplifies network management.

l Configure an EBGP peer.
1. Run:
system-view

2. Run:

3. Run:
The IP address of a peer and the number of the AS where the peer resides are specified.

The number of the AS where the specified peer resides must be different from that of
the local AS.
The IP address of the specified peer can be one of the following types:
– IP address of an interface on a directly connected peer

– IP address of a loopback interface on a reachable peer
– IP address of a sub-interface on a directly connected peer
4. (Optional) Run:
peer ipv4-address connect-interface interface-type interface-number
[ ipv4-source-address ]
The source interface and source address are specified for establishing a TCP
connection.
By default, BGP uses the physical interface that is directly connected to the peer as
the local interface of a TCP connection.
NOTE
When loopback interfaces are used to establish a BGP connection, run the peer connect-
interface command at both ends of the connection to ensure that the connection is correctly
established. If this command is run on only one end, the BGP connection may fail to be
established.
5. (Optional) Run:
peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops is configured for an EBGP connection.
By default, a direct physical link must be available between EBGP peers. If such a
link does not exist, run the peer ebgp-max-hop command to allow EBGP peers to
establish a TCP connection over multiple hops.
If hop-count is not specified in the peer ebgp-max-hop command, 255 is used as the
maximum number of hops in EBGP connections.
NOTE
If loopback interfaces are used to establish an EBGP peer relationship, the peer ebgp-max-
hop command (hop-count ≥ 2) must be run. Otherwise, the peer relationship cannot be
established.
6. (Optional) Run:
peer ipv4-address description description-text
A description is configured for the peer.
Configuring a description for a peer simplifies network management.
----End
8.3.4 Configuring BGP to Import Routes

BGP can import routes from other protocols. When routes are imported from a dynamic routing
protocol, the process IDs of the routing protocol must be specified.

Context
BGP itself cannot discover routes. Instead, it imports routes discovered by other protocols such
as an IGP or the static routing protocol into the BGP routing table. These imported routes are
then transmitted within an AS or between ASs.
BGP can import routes in either Import or Network mode:
l In Import mode, BGP imports routes by a specific routing protocol. RIP routes, OSPF
routes, IS-IS routes, static routes, or direct routes can be imported into the BGP routing
table.
l In Network mode, routes with the specified prefix and mask are imported into the BGP
routing table. Compared with the Import mode, the Network mode imports more specific
routes.
Procedure
l Configure BGP to import routes in Import mode.
1. Run:
system-view

2. Run:

3. (Optional) Run:
ipv4-family unicast
The BGP-IPv4 unicast address family view is displayed.

By default, the BGP-IPv4 unicast address family view is displayed.
4. Run:
import-route protocol [ process-id ] [ med med | route-policy route-policy-
name ] *
BGP is configured to import routes from other protocols.

By configuring the parameter med, you can set Multi_Exit Discriminator (MED)
values for the imported routes. The EBGP peer selects the route with the smallest
MED for traffic entering an AS.
By configuring the parameter route-policy route-policy-name, you can filter the
routes imported from other protocols.
NOTE
The process ID of a routing protocol needs to be specified if IS-IS, OSPF, or RIP routes are to
be imported.
5. (Optional) Run:
default-route imported
BGP is configured to import default routes.

To import default routes, run both the default-route imported command and the
import-route command. If only the import-route command is used, no default route

can be imported. In addition, the default-route imported command is used to import

only the default routes that exist in the local routing table.
l Configure BGP to import routes in Network mode.
1. Run:
system-view

2. Run:
bgp{ as-number-plain | as-number-dot }

3. (Optional) Run:
ipv4-family unicast

By default, the BGP-IPv4 unicast address family view is displayed.
4. Run:
network ipv4-address [ mask | mask-length ] [ route-policy route-policy-
name ]
BGP is configured to advertise local routes.

If no mask or mask length is specified, the IP address is processed as a classful address.
A local route to be advertised must be in the local IP routing table. Routing policies
can be used to control the routes to be advertised more flexibly.
NOTE
l The destination address and mask specified in the network command must be consistent
with those of the corresponding entry in the local IP routing table. Otherwise, the specified
route cannot be advertised.
l When using the undo network command to clear the existing configuration, specify a
correct mask.
----End

After basic BGP functions are configured, you can view information about BGP peers and BGP
routes.
Prerequisites
Basic BGP functions have been configured.
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 log
information of a specified BGP peer.
l Run the display bgp routing-table [ ipv4-address [ mask | mask-length ] ] command to
check BGP routes.
----End

Example
# Run the display bgp peer command to view the BGP connection status.
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
9.1.1.2 4 65009 49 62 0 00:44:58 Established 0
9.1.3.2 4 65009 56 56 0 00:40:54 Established 0
200.1.1.2 4 65008 49 65 0 00:44:03 Established 1
# Run the display bgp routing-table 60.0.0.35 command to view a specified BGP route.
<HUAWEI> display bgp routing-table 60.0.0.35

Paths: 1 available, 1 best, 1 select
BGP routing table entry information of 60.0.0.35/32:
Network route.
From: 0.0.0.0 (0.0.0.0)
Route Duration: 3d04h00m12s
Direct Out-interface: InLoopBack0
Original nexthop: 127.0.0.1
Qos information : 0x0
AS-path Nil, origin igp, MED 0, pref-val 0, valid, local, best, select, pre 0
Not advertised to any peer yet
8.4 Configuring BGP Route Attributes

BGP has many route attributes. Configuring route attributes can change route selection results.

Before configuring BGP route attributes, familiarize yourself with the usage scenario, complete
BGP has many route attributes. You can change route selection results by configuring attributes
for routes. Route attributes are listed as follows:
l BGP preference
Setting the BGP preference can affect route selection between BGP routes and other routing
protocols' routes.
l Preferred values
After preferred values are set for BGP routes, the route with the greatest value is preferred
when multiple routes to the same destination exist in the BGP routing table.
l Local_Pref
The Local_Pref attribute has the same function as the preferred value of a route. If both of
them are configured for a BGP route, the preferred value takes precedence over the
Local_Pref attribute.
l Multi_Exit Discriminator (MED)

The MED attribute is used to determine the optimal route for traffic that enters an AS. The
route with the smallest MED value is selected as the optimal route if the other attributes of
the routes are the same.
l Next_Hop
BGP route selection can be flexibly controlled by changing Next_Hop attributes for routes.
l AS_Path
The AS_Path attribute is used to prevent rooting loops and control route selection.
l Accumulated Interior Gateway Protocol Metric (AIGP)
The AIGP attribute is used to select the optimal route in an AIGP administrative domain.
Before configuring BGP route attributes, complete the following tasks:
l Configuring IP addresses for interfaces to ensure IP connectivity between neighboring

nodes
l Configuring Basic BGP Functions
Data Preparation
To configure BGP route attributes, you need the following data.
No. Data
1 AS number
2 BGP preference value
3 Local_Pref value
4 MED value
8.4.2 Configuring the BGP Preference

Setting the BGP preference can affect route selection between BGP routes and other routing
protocols' routes.
Context
Multiple dynamic routing protocols can be run on a device at the same time. In this case, there
is a problem of route sharing and selecting among routing protocols. To address this problem,
the system sets a default preference for each routing protocol. If different protocols have routes
to the same destination, the protocol with the highest preference is selected to forward IP packets.
Perform the following steps on a device running BGP.
Procedure
Step 1 Run:

system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
The IPv4 unicast address family view is displayed.
Step 4 Run:
preference { external internal local | route-policy route-policy-name }
The BGP preference is set.
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
At present, the peer route-policy command cannot be used to set the BGP preference.
----End
8.4.3 Configuring Preferred Values for BGP Routes

After preferred values are set for BGP routes, the route with the greatest value is preferred when
multiple routes to the same destination exist in the BGP routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { group-name | ipv4-address } preferred-value value

A preferred value is set for all the routes learned from a specified peer.
The original preferred value of a route learned from a peer defaults to 0.
If there are multiple routes to the same address prefix, the route with the highest preferred value
is preferred.
----End
8.4.4 Configuring a Default Local_Pref Attribute for a Device

The Local_Pref attribute is used to determine the optimal route for traffic that leaves an AS.
Context
The Local_Pref attribute is used to determine the optimal route for traffic that leaves an AS. If
a BGP device obtains multiple routes from different IBGP peers and these routes have different
next hops to the same destination, the BGP device will select the route with the greatest
Local_Pref value.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
default local-preference preference
A default Local_Pref attribute is set for the local device.
----End
8.4.5 Configuring MED Attributes for BGP Routes

The Multi_Exit Discriminator (MED) attribute equals a metric used in an IGP. The MED
attribute is used to determine the optimal route for traffic that enters an AS. The route with the
smallest MED value is selected as the optimal route if the other attributes of the routes are the
same.
Context
The MED attribute equals a metric used in an IGP, and is used to determine the optimal route
for traffic that enters an AS. If a BGP device obtains multiple routes from different EBGP peers

and these routes have different next hops to the same destination, the BGP device will select the
route with the smallest MED value.
Procedure
l Set the default MED value on a device.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
default med med
The default MED value is set.
NOTE
The default med command is valid only for routes imported using the import-route command
and BGP summarized routes on the local device.
l Compare the MED values of the routes from different ASs.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
compare-different-as-med
The MED values of routes from different ASs are compared.
By default, the BGP device compares the MED values of only routes from different
peers in the same AS. This command enables the BGP device to compare the MED
values of routes from different ASs.
l Configure the deterministic-MED function.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
deterministic-med
The deterministic-MED function is enabled.
If the deterministic-MED function is not enabled and an optimal route is to be selected

among routes that are received from different ASs and carry the same prefix, the
sequence in which routes are received is relevant to the route selection result. After
the deterministic-MED function is enabled and an optimal route is to be selected
among routes that are received from different ASs and carry the same prefix, routes
are first grouped based on the leftmost AS number in the AS_Path attribute. Routes
with the same leftmost AS number are grouped together and compared, and an optimal
route is selected in the group. The optimal route in this group is then compared with
the optimal routes from other groups to determine the final optimal route. This route
selection mode allows the route selection result to be independent of the sequence in
which routes are received.
l Configure the method used by BGP to handle the situation where a route has no MED
attribute during route selection.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
bestroute med-none-as-maximum
The system treats a BGP route as one with the maximum MED value if the route has
no MED value.
After the bestroute med-none-as-maximum command is run, BGP treats a BGP

route as one with the maximum MED value if the route that has no MED attribute
when selecting an optimal route. If this command is not run, BGP uses 0 as the MED
value for a route that has no MED value.
l Compare the MED values of routes in a confederation.
1. Run:
system-view


2. Run:

3. Run:
ipv4-family unicast

4. Run:
bestroute med-confederation
The MED values of routes in a confederation are compared.
----End
8.4.6 Configuring Next_Hop Attributes for Routes

Setting Next_Hop attributes for routes flexibly controls BGP route selection.
Procedure
l Configure a device to change the next-hop address of a route when the device advertises
the route to an IBGP peer.
By default, a device does not change the next-hop address of a route learned from an EBGP
peer before forwarding the route to IBGP peers. The next-hop address of a route advertised
by an EBGP peer to this device is the address of the EBGP peer. After being forwarded to
IBGP peers, this route cannot become an active route because the next hop is unreachable.
The relevant ASBR must be configured to change the next-hop address of the route to the
ASBR's own IP address before the ASBR advertises the route to an IBGP peer. The route
is active on the IBGP peer if the next hop is reachable.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
peer { ipv4-address | group-name } next-hop-local
The device is configured to change the next-hop address of a route to the device's own
IP address before the device advertises the route to an IBGP peer.
By default, a device does not change the next-hop address of a route when advertising
the route to an IBGP peer.

NOTE
If BGP load balancing is configured, the local router changes the next-hop address of a route
to it's own IP address when advertising the route to IBGP peers or peer groups, regardless of
whether the peer next-hop-local command is used.
l Prevent a device from changing the next-hop address of a route imported from an IGP when
the device advertises the route to an IBGP peer.
Perform the following steps on a router that runs BGP and has imported IGP routes:
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
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.
l Prevent a device from changing the next-hop address of a route when the device advertises
the route to an EBGP peer.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family vpnv4 [ unicast ]
The BGP-VPNv4 sub-address family view is displayed.

4. Run:
peer { group-name | ipv4-address } next-hop-invariable
The device is prevented from changing the next-hop address of a route when
advertising the route to an EBGP peer.
By default, provider edges (PEs) in different ASs set up EBGP peer relationships with
each other, and they do not change next-hop addresses of routes when advertising the
routes to their EBGP peers.

In the inter-AS VPN option C networking where route reflectors (RRs) are used, the
peer next-hop-invariable command needs to be run to prevent the RRs from changing
the next-hop address of a route when the RRs advertise the route to EBGP peers. This
ensures that the remote PE iterates a route to the BGP Label Switched Path (LSP)
destined for the local PE during traffic transmission.
l Configure routing-policy-based next hop iteration.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. 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.
Next-hop iteration based on a specified routing policy can control the iterated next
hop based on specific conditions. If a route cannot match the specified routing policy,
the route cannot be iterated.
----End
8.4.7 Configuring AS_Path Attributes for Routes

The AS_Path attribute is used to prevent routing loops and control route selection.
Procedure
l Allow repeated local AS numbers.
BGP uses AS numbers to detect routing loops. In Hub and Spoke networking, if EBGP
runs between a Hub-PE and a Hub-CE, the route sent from the Hub-PE to the Hub-CE
carries the AS number of the Hub-PE. After the Hub-CE sends an Update message that
contains the AS number of the Hub-PE to the Hub-PE, the Hub-PE will deny it.
To ensure proper route transmission in Hub and Spoke networking, configure all the BGP
peers on the path, along which the Hub-CE advertises private network routes to the Spoke-
CE, to accept the routes in which the local AS number repeats once.
1. Run:
system-view

2. Run:


3. Run:
ipv4-family unicast

4. Run:
peer { ipv4-address | group-name } allow-as-loop [ number ]
The local AS number is allowed to repeat in the AS_Path attribute.

Generally, a BGP device checks the AS_Path attribute of a route sent from a peer. If
the local AS number already exists in the AS_Path attribute, BGP ignores this route
to avoid a routing loop.
In some special applications, you can use the peer allow-as-loop command to allow
the AS_Path attributes of routes sent from the peers to contain the local AS number.
You can also set the number of times the local AS number is repeated.
l Configure BGP not to compare AS_Path attributes of routes in the route selection process.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
bestroute as-path-ignore
BGP is configured to ignore AS_Path attributes of routes during route selection.

l Configure a fake AS number.
Generally, a device supports only one BGP process. This means that a device supports only
one AS number. If AS numbers need to be replaced during network migration, you can run
the peer fake-as command to set a fake AS number for a specified peer to ensure smooth
network migration.
1. Run:
system-view

2. Run:

3. Run:
peer { ipv4-address | group-name } fake-as { as-number-plain | as-number-
dot }
A fake AS number is configured.

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.
NOTE
This command can be used only on EBGP peers.

l Enable AS number replacement.
Before advertising a route to a specified CE, a PE on which AS number replacement is

configured replaces the AS number of the CE in the AS_Path attribute of the route with the
local AS number.
NOTICE
Exercise caution when running the peer substitute-as command, because improper use of
this command may cause routing loops.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.

4. Run:
peer { ipv4-address | group-name } substitute-as
AS number replacement is enabled.

l Configure the AS_Path attribute to carry only public AS numbers.
A route advertised by a BGP device to its peer usually carries AS numbers. The AS numbers
may be public or private. Public AS numbers can be used on the Internet. They are assigned
and managed by the Internet Assigned Number Authority (IANA). Private AS numbers
cannot be advertised to the Internet, and they are used only within ASs. If private AS
numbers are advertised to the Internet, a routing loop may occur. To address this problem,
configure the device to delete private AS numbers from the AS_Path attribute.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
peer { ipv4-address | group-name } public-as-only [ force ]
The device is configured to delete private AS numbers (if any) from the AS-Path
attribute before sending update packets.
An AS number ranges from 1 to 4294967295. A public AS number ranges from 1 to

64511, and from 65536 (1.0 in the x.y format) to 4294967295 (65535.65535 in the
x.y format). A private AS number ranges from 64512 to 65534. The AS number 65535
is reserved for particular use.
The peer public-as-only command can be used only on EBGP peers.
After the command without force is run, the device does not delete the private AS
numbers from the AS-Path attribute before sending update packets in either of the
following scenarios:
– The AS_Path of a route contains the AS number of the peer. In this case, deleting
the private AS numbers may lead to a routing loop.
– The AS_Path list contains both public network AS number and private AS number.
This list indicates that the route passes the public network. deleting the private AS
numbers may lead to forwarding error.
To enable the device to delete the private AS numbers from the AS-Path attribute
before sending update packets even in the preceding scenarios, specify force in the
command.
l Set the maximum number of AS numbers in the AS_Path attribute.
1. Run:
system-view

2. Run:

3. Run:
as-path-limit as-path-limit-num
The maximum number of AS numbers in the AS_Path attribute is set.
By default, a maximum of 255 AS numbers can be contained in the AS_Path attribute.
After the as-path-limit command is run on a device, the device checks whether the
number of AS numbers in the AS_Path attribute of a received route exceeds the
maximum value. If the number of AS numbers exceeds the maximum value, the route
is discarded. If the maximum number of AS numbers in the AS_Path attribute is too
small, routes whose number of AS numbers exceeding the maximum value will be
discarded.
l Prevent a BGP device from checking the first AS number contained in the AS_Path attribute
of an Update message received from an EBGP peer.

1. Run:
system-view

2. Run:

3. Run:
undo check-first-as
The BGP device is prevented from checking the first AS number contained in the
AS_Path attribute of an Update message received from an EBGP peer.
By default, a BGP device checks whether the first AS number contained in the
AS_Path attribute of an Update message received from an EBGP peer is the same as
the number of the AS where the EBGP peer resides. If the numbers are not the same,
the BGP device discards the Update message and closes the EBGP connection with
the EBGP peer.
NOTICE
Exercise caution when running the undo check-first-as command, because use of this
command increases the possibility of routing loops.
After the configuration is complete, run the refresh bgp command if you want to
check the received routes again.
----End

After BGP route attributes are configured, you can view information about these route attributes.
Prerequisites
The BGP route attribute configuration is complete.
Procedure
l Run the display bgp paths [ as-regular-expression ] command to check information about
AS_Path attributes of routes.
l Run the display bgp routing-table different-origin-as command to check information
about routes that have the same destination address but different source AS numbers.
l Run the display bgp routing-table regular-expression as-regular-expression command
to check information about routes matching a specified regular expression.
l Run the display bgp routing-table [ network [ { mask | mask-length } [ longer-
prefixes ] ] ] command to check routing information in a BGP routing table.
----End

Example
# Run the display bgp paths command to view information about AS_Path attributes of routes.
<HUAWEI> display bgp paths

Total Number of Paths: 7
Address Refcount MED Path/Origin

0xA276A44C 2 20 10i
0xA276A50C 3 20 10 100i
0xA276A4AC 2 10i
0xA276A56C 3 10 100i
0xA276A32C 2 0 20?
0xA276A2CC 4 0 ?
0xA276A20C 1 0 10i
# Run the display bgp routing-table 60.0.0.35 command to view information about a specified
BGP route.

Network route.
From: 0.0.0.0 (0.0.0.0)
Direct Out-interface: InLoopBack0
8.5 Configuring BGP to Advertise Routes

BGP is used to transmit routing information. BGP advertises only the wanted routes after filtering
routes to be advertised, and modifies route attributes to direct network traffic.

Before configuring BGP to advertise routes, familiarize yourself with the usage scenario,
BGP is used to transmit routing information between ASs. Route advertisement directly affects
traffic forwarding.
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.

Filters can be used to filter routes to be advertised by BGP. BGP can filter routes to be advertised
to a specific peer or peer group.
Before configuring BGP to advertise routes, complete the following task:
Data Preparation
To configure BGP to advertise routes, you need the following data.
No. Data
1 Name or number of an ACL
2 Name, number, and matching mode of an IP prefix list
3 Number or name of an AS_Path filter
4 Number or name and matching mode of a community filter
5 Number or name and matching mode of an extcommunity filter
6 Name and matching mode of a route-policy, and number of the route-policy's node
8.5.2 Configuring BGP Filters

BGP filters filter routes to be advertised.
Context
BGP uses the following types of filters to filter routes:
l Access Control List(ACL)
l IP-Prefix List
l AS_Path filter
l Community filter
l Extcommunity filter
l Route-Policy
Procedure
l Configure an ACL.
An ACL is a series of sequential rules composed of permit and deny clauses. These rules
are described based on source addresses, destination addresses, and port numbers of
packets. ACL rules are used to classify packets. After ACL rules are applied to a device,
the device permits or denies packets based on the ACL rules.

For details on ACL configurations, see the HUAWEI NetEngine80E/40E Router

Configuration Guide - IP Services.
An ACL can be used as a matching condition of a route-policy or used in the filter-
policy { acl-number | acl-name acl-name } export [ protocol [ process-id ] ] command or
the peer { group-name | ipv4-address } filter-policy { acl-number | acl-name acl-name }
export command.
l Configure an IP prefix list.
An IP prefix list is a type of filter used to filter routes based on destination addresses. An
IP prefix list is identified by its name. An IP prefix list can be used flexibly to implement
accurate filtering. For example, it can be used to filter a route or routes to a network segment.
If a large number of routes that do not have the same prefix need to be filtered, configuring
an IP prefix list to filter the routes is very complex.
An IP prefix list can be used as a matching condition of a route-policy or used in the filter-
policy ip-prefix ip-prefix-name export [ protocol [ process-id ] ] command or the peer
{ group-name | ipv4-address } ip-prefix ip-prefix-name export command.
1. Run:
system-view

2. Run:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-
address mask-length [ match-network ] [ greater-equal greater-equal-
value ] [ less-equal less-equal-value ]
An IPv4 prefix list is configured.

match-network is used to filter routes to a specified IP address and can be configured
only when ipv4-address is 0.0.0.0. For example, the ip ip-prefix prefix1 permit
0.0.0.0 8 command filters all routes with mask length 8, while the ip ip-prefix prefix1
permit 0.0.0.0 8 match-network command filters all routes to the IP address range
from 0.0.0.1 to 0.255.255.255.
The mask length range can be specified as mask-length <= greater-equal-value <=
less-equal-value <= 32. If only greater-equal is specified, the prefix range is [greater-
equal-value, 32]. If only less-equal is specified, the prefix range is [mask-length, less-
equal-value].
An IPv4 prefix list is identified by its name, and each IP prefix list can contain multiple
entries. Each entry is identified by an index number, and can specify a matching range
in the form of a network prefix uniquely. An IPv4 prefix list named abcd is used as
an example.
#
ip ip-prefix abcd index 10 permit 1.0.0.0 8
During route matching, the system checks the entries by index number in ascending
order. If a route matches an entry, the route will not be matched with the next entry.
The NE80E/40E denies all unmatched routes by default. If all entries in an IPv4 prefix
list are in deny mode, all routes will be denied by the IPv4 prefix list. In this case, you
must define an entry permit 0.0.0.0 0 less-equal 32 after the entries in deny mode to
allow all the other IPv4 routes to by permitted by the IPv4 prefix list.

NOTE
If more than one IP prefix entry is defined, at least one entry should be set in permit mode.
l Configure an AS_Path filter.
An AS_Path filter is used to filter BGP routes based on the AS_Path attributes contained
in the BGP routes. If you do not want traffic to pass through an AS, configure an AS_Path
filter to filter out the traffic carrying the number of the AS. If the BGP routing table of each
device on a network is large, configuring an ACL or an IP prefix list to filter BGP routes
may be complicated and make it difficult to maintain new routes.
NOTE
If the AS_Path information of a summarized route is lost, the AS_Path filter cannot be used to filter
the summarized route, but can still be used to filter the specific routes from which the summarized
route is derived.
An AS_Path filter can be used as a matching condition of a route-policy or be used in the

peer as-path-filter command.
1. Run:
system-view

2. Run:
ip as-path-filter { as-path-filter-number | as-path-filter-name }
{ permit | deny } regular-expression
An AS_Path filter is configured.
NOTE
For details on how to use AS_Path filters, see 8.25 Applying BGP AS_Path Regular
Expressions.
l Configure a community filter.
A BGP community attribute is used to identify a group of routes with the same properties.
Routes can be classified by community attribute. This facilitates route management.
Some AS internal routes may not need to be advertised to any other AS, whereas AS external
routes need to be advertised to other ASs. These AS external routes have different prefixes
(as a result, an IP prefix list is inapplicable) and may come from different ASs (as a result,
an AS_Path filter is inapplicable). You can set a community attribute value for these AS
internal routes and another community attribute value for these AS external routes on an
ASBR to control and filter these routes.
1. Run:
system-view

2. Run:
ip community-filter
A community filter is configured.
– To configure a standard community filter, run the ip community-filter { basic

comm-filter-name { permit | deny } [ community-number | aa:nn ] * &<1-16> |
basic-comm-filter-num { permit | deny } [ community-number | aa:nn ] *

&<1-16> } [ internet | no-export-subconfed | no-advertise | no-export ] *

command.
– To configure an advanced community filter, run the ip community-filter
{ advanced comm-filter-name | adv-comm-filter-num } { permit | deny } regular-
expression command.
l Configure an extcommunity filter.
Similar to a BGP community filter, a BGP extcommunity filter is used to filter private
network routes.
1. Run:
system-view

2. Perform either of the following operations as required to configure an extcommunity
filter.
– To configure a basic extcommunity filter, run the ip extcommunity-filter { basic-
extcomm-filter-num | basic basic-extcomm-filter-name } { deny | permit } { rt
{ { as-number-plain | as-number-dot }:nn | ipv4-address:nn } } &<1-16>
command.
– To configure an advanced extcommunity filter, run the ip extcommunity-filter
{ adv-extcomm-filter-num | advanced adv-extcomm-filter-name } { deny |
permit } regular-expression command.
Multiple entries can be defined in an extcommunity filter. The relationship between

the entries is "OR". This means that if a route matches one of the rules, the route
matches the filter.
l Configure a route-policy.
A route-policy is used to match routes or route attributes, and to change route attributes
when specific conditions are met. As the preceding filters can be used as matching
conditions of a route-policy, the route-policy is powerful in functions and can be used
flexibly.
1. Run:
system-view

2. Run:
A node is configured for a route-policy, and the view of the route-policy is displayed.
A route-policy consists of multiple nodes. For example, the route-policy route-

policy-example permit node 10 command specifies node 10 and the route-policy
route-policy-example deny node 20 command specifies node 20. The two nodes
belong to the route-policy specified by route-policy-example. The relationship
between the nodes of a route-policy is "OR". The details are as follows:
– If a route matches one node, the route matches the route-policy and will not be
matched with the next node. For example, there are two nodes defined using the
route-policy route-policy-example permit node 10 and route-policy route-
policy-example deny node 20 commands. If a route matches the node defined

using the route-policy route-policy-example permit node 10 command, the route

will not be matched with the node defined using the route-policy route-policy-
example deny node 20 command.
– If a route does not match any node, the route fails to match the route-policy.
When a route-policy is used to filter a route, the route is first matched with the node
with the smallest node value. For example, if two nodes are configured using the
route-policy route-policy-example permit node 10 and route-policy route-policy-
example deny node 20 commands, a route is first matched with the node configured
using the route-policy route-policy-example permit node 10 command.
NOTE
The NE80E/40E considers that each unmatched route fails to match the route-policy by default.
If more than one node is defined in a route-policy, at least one of them must be in permit mode.
3. (Optional) Perform the following operations as needed to configure if-match clauses
for current nodes of the route-policy.
if-match clauses are used to filter routes. If no if-match clause is specified, all routes
will match the node in the route-policy.
– To match an ACL, run the if-match acl { acl-number | acl-name } command.

– To match an IP prefix list, run the if-match ip-prefix ip-prefix-name command.
NOTE
The if-match acl and if-match ip-prefix commands cannot be used together in the same
node of a route-policy, because the latest configuration will override the previous one.
– To match the AS_Path attribute of BGP routes, run the if-match as-path-filter
{ as-path-filter-number | as-path-filter-name } &<1-16> command.
– To match the community attribute of BGP routes, run either of the following
commands:
– 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 ]
– To match the extended community attribute of BGP routes, run the if-match
extcommunity-filter { { basic-extcomm-filter-num | adv-extcomm-filter-num }
&<1-16> | basic-extcomm-filter-name | advanced-extcomm-filter-name }
command.
The operations in Step 3 can be performed in any order. A node may have multiple
if-match clauses or no if-match clause.
NOTE
The relationship between the if-match clauses in a node of a route-policy is "AND". A route
must match all the rules before the action defined by the apply clause is taken. For example,
if two if-match clauses (if-match acl 2003 and if-match as-path-filter 100) are defined in the
route-policy route-policy-example permit node 10 command, a route is considered to match
node 10 only when it matches the two if-match clauses.
4. (Optional) Perform the following operations as needed to configure apply clauses for
current nodes of the route-policy:

apply clauses can be used to set attributes for routes matching if-match clauses. If
this step is not performed, the attributes of routes matching if-match clauses keep
unchanged.
– To replace or add a specified AS number in the AS_Path attribute of a BGP route,

run the apply as-path { as-number-plain | as-number-dot } &<1-10> { additive
| overwrite } | none overwrite } command.
– To delete a specified BGP community attribute from a route, run the apply comm-
filter comm-filter-number delete command.
NOTE
The apply comm-filter delete command deletes a specified community attribute from a
route. An instance of the ip community-filter command can specify only one community
attribute each time. To delete more than one community attribute, run the ip community-
filter command multiple times. If multiple community attributes are specified in one
community filter, none of them can be deleted. For more information, see the HUAWEI
NetEngine80E/40E Router Command Reference.
– To delete all community attributes from a BGP route, run the apply community
none command.
– To set community attributes for a BGP route, run the apply community
{ community-number | aa:nn | internet | no-advertise | no-export | no-export-
subconfed } &<1-32> [ additive ] command.
– To set an extended community attribute (route-target) for a route, run the apply
extcommunity { rt { as-number:nn | 4as-number:nn | ipv4-address:nn } }
&<1-16> [ additive ] command.
– To set the local preference for a BGP route, run the apply local-preference
preference command.
– To set the Origin attribute for a BGP route, run the apply origin { igp | egp { as-
number-plain | as-number-dot } | incomplete } command.
– To set a preferred value for a BGP route, run the apply preferred-value preferred-
value command.
– To set dampening parameters for an EBGP route, run the apply dampening half-
life-reach reuse suppress ceiling command.
apply clauses or no apply clause.
----End
8.5.3 Configuring to Controll the Advertisement of BGP Routing

Information
After a route advertisement policy is configured on a device, the device advertises only routes
matching the policy to its peers.
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. Perform the following
steps on a BGP router:

1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Perform either of the following operations to configure the BGP device to advertise
routes to all peers or peer groups:
– To filter routes based on a basic ACL, perform the following steps:
a. Run filter-policy { acl-number | acl-name acl-name } export [ protocol
[ process-id ] ], the advertised routes is filtered based on an ACL.
b. Run quit, return to the BGP view.
c. Run quit, return to the system view.
d. Run acl { [ number ] acl-number1 | name acl-name basic [ number acl-
displayed.
e. Run rule [ rule-id ] { deny | permit } [ fragment-type fragment-type-
ACL.
When the rule command is run to configure rules for a named ACL, only the
source address range specified by source and the time period specified by
time-range are valid as the rules.
system.

routes.
– To filter routes based on an advanced ACL, perform the following steps:
a. Run filter-policy acl-name acl-name export [ protocol [ process-id ] ], the
advertised routes is filtered based on an ACL.
d. Run acl name acl-name advance [ number acl-number2 ] [ match-order
e. Run rule [ rule-id ] { deny | permit } protocol [ source { source-ip-address
the basic ACL.
system.
routes.
– To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-prefix-
name export [ protocol [ process-id ] ] command.
If protocol is specified, only routes discovered by a specific routing protocol are
filtered. If protocol is not specified, all the routes to be advertised are filtered, including

routes imported using the import-route (BGP) command and local routes advertised
using the network (BGP) 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.
You can configure a BGP device to filter routes to be advertised. Perform the following
steps on a BGP router:
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Perform any of the following operations to configure the BGP device to advertise
routes to a specific peer or peer group:
a. Run peer { ipv4-address | group-name } filter-policy { acl-number | acl-
name acl-name } export, the advertised routes is filtered based on an ACL.
displayed.
ACL.

system.
routes.
a. Run peer { ipv4-address | group-name } filter-policy acl-name acl-name
export, the advertised routes is filtered based on an ACL.
the basic ACL.
system.

routes.
– To filter routes based on an IP prefix list, run the peer { ipv4-address | group-
name } ip-prefix ip-prefix-name export command.
– To filter routes based on an AS_Path filter, run the peer { ipv4-address | group-
name } as-path-filter { as-path-filter-number | as-path-filter-name } export
command.
– To filter routes based on a route-policy, run the peer { ipv4-address | group-
name } route-policy route-policy-name export command.
A peer group and its members can use different export policies to filter routes. Each
peer can select its policy when advertising routes.
----End
8.5.4 Configuring BGP Soft Reset

BGP soft reset allows the system to refresh a BGP routing table dynamically without tearing
down any BGP connection if routing policies are changed.
Context
After changing a BGP import policy, you must reset BGP connections for the new import policy
to take effect, interrupting these BGP connections temporarily. BGP route-refresh allows the
system to refresh a BGP routing table dynamically without tearing down any BGP connection
if routing policies are changed.
l If a device's peer supports route-refresh, the refresh bgp command can be used on the
device to softly reset the BGP connection with the peer and update the BGP routing table.
l If a device's peer does not support route-refresh, the peer keep-all-routes command can
be used on the device to remain all routing updates received from the peer so that the device
can refresh its routing table without closing the connection with the peer.
Procedure
l If the device's peers support route-refresh, perform the following operations:
1. (Optional) Enable route-refresh.
a. Run:
system-view

b. Run:

c. Run:

peer { ipv4-address | group-name } capability-advertise route-refresh
Route-refresh is enabled.
By default, route-refresh is enabled.
If route-refresh is enabled on all BGP devices and the import policy of the local device
is changed, the local device sends a route-refresh message to peers or peer groups.
After receiving the message, the peers or peer groups resend routing information to
the local BGP device. This enables the local device to dynamically refresh its BGP
routing table and apply the new routing policy without closing any BGP connections.
2. Configure BGP soft reset.
a. Run the refresh bgp [ vpn-instance vpn-instance-name ipv4-family | vpnv4 |
vpn-target | l2vpn-ad ] { all | ipv4-address | group group-name | external |
internal } { export | import } command in the user view to softly reset the BGP
connections between the devices and its peers or peer groups.
external softly resets an EBGP connection, and internal softly resets an IBGP
connection.
export triggers outbound BGP soft reset, and import triggers inbound BGP soft reset.
l If the device's peers do not support route-refresh, perform the following operations:
– Configure the device to store all the routing updates received from its peers or peer
groups.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
peer { ipv4-address | group-name } 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.
After this command is used, all routing updates sent by a specified peer or peer group
are stored, regardless of whether an import policy is used. When the local routing
policy changes, the information can be used to regenerate BGP routes again.

NOTE
This command must be run on the local device and its peers. If the peer keep-all-routes
command is run on the device for the first time, the sessions between the device and its peers
are reestablished.
The peer keep-all-routes command does not need to be run on the router that supports route-
refresh. If the peer keep-all-routes command is run on the router, the sessions between the
router and its peers will not be reestablished but the refresh bgp command does not take effect
on the router.
----End

After the configurations of controlling BGP route advertisement has been configured, you can
view filters, routes matching a specified filter, and routes advertised to BGP peers.
Prerequisites
The BGP route advertisement configurations have been configured.
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 advertised-routes [ statistics ]
command to check information about routes advertised by a BGP device to its peers.
----End
Example
After an AS_Path filter is configured, run the display ip as-path-filter [ as-path-filter-
number | as-path-filter-name ] command in the system view to view information about the
configured AS_Path filter. Run the display bgp routing-table as-path-filter { as-path-filter-
number | as-path-filter-name } command to view information about routes matching a specified
AS_Path filter.
# View information about AS_Path filter 3.
<HUAWEI> display ip as-path-filter 3
ListID Mode Expression
3 deny [30]
3 permit .*
# View routes matching AS_Path filter 3.

<HUAWEI> display bgp routing-table as-path-filter 3

*>i 1.1.1.1/32 10.1.1.2 0 100 0 ?

*> 10.1.1.0/24 0.0.0.0 0 0 ?
i 10.1.1.2 0 100 0 ?
*> 10.1.1.1/32 0.0.0.0 0 0 ?
*> 10.3.1.0/24 0.0.0.0 0 0 ?
*> 10.3.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.1.0 0.0.0.0 0 0 ?
* i 10.1.1.2 0 100 0 ?
*> 192.168.1.121/32 0.0.0.0 0 0 ?
*>i 192.168.3.0 10.1.1.2 0 100 0 ?
8.6 Configuring BGP to Receive Routes

BGP is used to transmit routing information. BGP can filter received routes to accept only the
expected routes, and can modify route attributes to direct network traffic.

Before configuring BGP to receive routes, familiarize yourself with the usage scenario, complete
BGP is used to transmit routing information between ASs. Route reception directly affects traffic
forwarding.
The BGP device may receive routes to the same destination from different BGP peers. To control
traffic forwarding paths, the device needs to filter the received BGP routes.
The device may be attacked and receive a large number of routes from its BGP peers, consuming
lots of resources of the device. Therefore, the administrator must limit the resources to be
consumed based on networking planning and device capacities, no matter whether too many
BGP routes caused by malicious attacks or incorrect configurations.
Filters can be used to filter routes to be received by BGP. BGP can filter the routes received
from all peers or peer groups or only the routes received from a specific peer or peer group.
Before configuring BGP to receive routes, complete the following task:

Data Preparation
To configure BGP to receive routes, you need the following data.
No. Data
1 Name or number of an ACL
2 Name, number, and matching mode of an IP prefix list
3 Number or name of an AS_Path filter
4 Number or name and matching mode of a community filter
5 Number or name and matching mode of an extended community filter
6 Name and matching mode of a route-policy, and number of the route-policy's node
8.6.2 Configuring BGP Filters

BGP filters can be used to filter routes to be received.
Context
Filters are needed to filter routes to flexibly receive routes. Currently, six filters are available
for BGP:
l Access Control List(ACL)
l IP-Prefix List
l AS_Path filter
l Community filter
l Extcommunity filter
l Route-Policy
Procedure
l Configure an ACL.
An ACL is a series of sequential rules composed of permit and deny clauses. These rules
are described based on source addresses, destination addresses, and port numbers of
packets. ACL rules are used to classify packets. After ACL rules are applied to a device,
the device permits or denies packets based on the ACL rules.
For details on ACL configurations, see the HUAWEI NetEngine80E/40E Router
An ACL can be used as a matching condition of a route-policy or used in the filter-
policy { acl-number | acl-name acl-name } import command or the peer { group-name |
ipv4-address } filter-policy { acl-number | acl-name acl-name } import command.
l Configure an IP prefix list.
An IP prefix list is a type of filter used to filter routes based on destination addresses. An
IP prefix list is identified by its name. An IP prefix list can be used flexibly to implement

accurate filtering. For example, it can be used to filter a route or routes to a network segment.
If a large number of routes that do not have the same prefix need to be filtered, configuring
an IP prefix list to filter the routes is very complex.
An IP prefix list can be used as a matching condition of a route-policy or used in the filter-
policy ip-prefix ip-prefix-name import command or the peer { group-name | ipv4-
address } ip-prefix ip-prefix-name import command.
1. Run:
system-view

2. Run:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-
address mask-length [ match-network ] [ greater-equal greater-equal-
value ] [ less-equal less-equal-value ]
match-network is used to filter routes to a specified IP address and can be configured

only when ipv4-address is 0.0.0.0. For example, the ip ip-prefix prefix1 permit
0.0.0.0 8 command filters all routes with mask length 8, while the ip ip-prefix prefix1
permit 0.0.0.0 8 match-network command filters all routes to the IP address range
from 0.0.0.1 to 0.255.255.255.
The mask length range can be specified as mask-length <= greater-equal-value <=
less-equal-value <= 32. If only greater-equal is specified, the prefix range is [greater-
equal-value, 32]. If only less-equal is specified, the prefix range is [mask-length, less-
equal-value].
An IPv4 prefix list is identified by its name, and each IP prefix list can contain multiple
entries. Each entry is identified by an index number, and can specify a matching range
in the form of a network prefix uniquely. An IPv4 prefix list named abcd is used as
an example.
#
During route matching, the system checks the entries by index number in ascending
order. If a route matches an entry, the route will not be matched with the next entry.
The NE80E/40E denies all unmatched routes by default. If all entries in an IPv4 prefix
list are in deny mode, all routes will be denied by the IPv4 prefix list. In this case, you
must define an entry permit 0.0.0.0 0 less-equal 32 after the entries in deny mode to
allow all the other IPv4 routes to by permitted by the IPv4 prefix list.
NOTE
If more than one IP prefix entry is defined, at least one entry should be set in permit mode.
l Configure an AS_Path filter.
An AS_Path filter is used to filter BGP routes based on the AS_Path attributes contained
in the BGP routes. If you do not want traffic to pass through an AS, configure an AS_Path
filter to filter out the traffic carrying the number of the AS. If the BGP routing table of each
device on a network is large, configuring an ACL or an IP prefix list to filter BGP routes
may be complicated and make it difficult to maintain new routes.

NOTE
If the AS_Path information of a summarized route is lost, the AS_Path filter cannot be used to filter
the summarized route, but can still be used to filter the specific routes from which the summarized
route is derived.
An AS_Path filter can be used as a matching condition of a route-policy or be used in the

peer as-path-filter command.
1. Run:
system-view

2. Run:
ip as-path-filter { as-path-filter-number | as-path-filter-name }
{ permit | deny } regular-expression
An AS_Path filter is configured.
NOTE
For details on how to use AS_Path filters, see 8.25 Applying BGP AS_Path Regular
Expressions.
l Configure a community filter.
A BGP community attribute is used to identify a group of routes with the same properties.
Routes can be classified by community attribute. This facilitates route management.
Some AS internal routes may not need to be advertised to any other AS, whereas AS external
routes need to be advertised to other ASs. These AS external routes have different prefixes
(as a result, an IP prefix list is inapplicable) and may come from different ASs (as a result,
an AS_Path filter is inapplicable). You can set a community attribute value for these AS
internal routes and another community attribute value for these AS external routes on an
ASBR to control and filter these routes.
1. Run:
system-view

2. Run:
ip community-filter
A community filter is configured.
– To configure a standard community filter, run the ip community-filter { basic

comm-filter-name { permit | deny } [ community-number | aa:nn ] * &<1-16> |
basic-comm-filter-num { permit | deny } [ community-number | aa:nn ] *
&<1-16> } [ internet | no-export-subconfed | no-advertise | no-export ] *
command.
– To configure an advanced community filter, run the ip community-filter
{ advanced comm-filter-name | adv-comm-filter-num } { permit | deny } regular-
expression command.
l Configure an extcommunity filter.
Similar to a BGP community filter, a BGP extcommunity filter is used to filter private
network routes.

1. Run:
system-view

2. Perform either of the following operations as required to configure an extcommunity
filter.
– To configure a basic extcommunity filter, run the ip extcommunity-filter { basic-
extcomm-filter-num | basic basic-extcomm-filter-name } { deny | permit } { rt
{ { as-number-plain | as-number-dot }:nn | ipv4-address:nn } } &<1-16>
command.
– To configure an advanced extcommunity filter, run the ip extcommunity-filter
{ adv-extcomm-filter-num | advanced adv-extcomm-filter-name } { deny |
permit } regular-expression command.
Multiple entries can be defined in an extcommunity filter. The relationship between

the entries is "OR". This means that if a route matches one of the rules, the route
matches the filter.
l Configure a route-policy.
A route-policy is used to match routes or route attributes, and to change route attributes
when specific conditions are met. As the preceding filters can be used as matching
conditions of a route-policy, the route-policy is powerful in functions and can be used
flexibly.
1. Run:
system-view

2. Run:
A node is configured for a route-policy, and the view of the route-policy is displayed.
A route-policy consists of multiple nodes. For example, the route-policy route-

policy-example permit node 10 command specifies node 10 and the route-policy
route-policy-example deny node 20 command specifies node 20. The two nodes
belong to the route-policy specified by route-policy-example. The relationship
between the nodes of a route-policy is "OR". The details are as follows:
– If a route matches one node, the route matches the route-policy and will not be
matched with the next node. For example, there are two nodes defined using the
route-policy route-policy-example permit node 10 and route-policy route-
policy-example deny node 20 commands. If a route matches the node defined
using the route-policy route-policy-example permit node 10 command, the route
will not be matched with the node defined using the route-policy route-policy-
example deny node 20 command.
– If a route does not match any node, the route fails to match the route-policy.
When a route-policy is used to filter a route, the route is first matched with the node
with the smallest node value. For example, if two nodes are configured using the
route-policy route-policy-example permit node 10 and route-policy route-policy-
example deny node 20 commands, a route is first matched with the node configured
using the route-policy route-policy-example permit node 10 command.

NOTE
The NE80E/40E considers that each unmatched route fails to match the route-policy by default.
If more than one node is defined in a route-policy, at least one of them must be in permit mode.
3. (Optional) Perform the following operations as needed to configure if-match clauses
for current nodes of the route-policy.
if-match clauses are used to filter routes. If no if-match clause is specified, all routes
will match the node in the route-policy.
– To match an ACL, run the if-match acl { acl-number | acl-name } command.

– To match an IP prefix list, run the if-match ip-prefix ip-prefix-name command.
NOTE
The if-match acl and if-match ip-prefix commands cannot be used together in the same
node of a route-policy, because the latest configuration will override the previous one.
– To match the AS_Path attribute of BGP routes, run the if-match as-path-filter
{ as-path-filter-number | as-path-filter-name } &<1-16> command.
– To match the community attribute of BGP routes, run either of the following
commands:
– 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 ]
– To match the extended community attribute of BGP routes, run the if-match
extcommunity-filter { { basic-extcomm-filter-num | adv-extcomm-filter-num }
&<1-16> | basic-extcomm-filter-name | advanced-extcomm-filter-name }
command.
if-match clauses or no if-match clause.
NOTE
The relationship between the if-match clauses in a node of a route-policy is "AND". A route
must match all the rules before the action defined by the apply clause is taken. For example,
if two if-match clauses (if-match acl 2003 and if-match as-path-filter 100) are defined in the
route-policy route-policy-example permit node 10 command, a route is considered to match
node 10 only when it matches the two if-match clauses.
4. (Optional) Perform the following operations as needed to configure apply clauses for
current nodes of the route-policy:
apply clauses can be used to set attributes for routes matching if-match clauses. If
this step is not performed, the attributes of routes matching if-match clauses keep
unchanged.
– To replace or add a specified AS number in the AS_Path attribute of a BGP route,

run the apply as-path { as-number-plain | as-number-dot } &<1-10> { additive
| overwrite } | none overwrite } command.
– To delete a specified BGP community attribute from a route, run the apply comm-
filter comm-filter-number delete command.

NOTE
The apply comm-filter delete command deletes a specified community attribute from a
route. An instance of the ip community-filter command can specify only one community
attribute each time. To delete more than one community attribute, run the ip community-
filter command multiple times. If multiple community attributes are specified in one
community filter, none of them can be deleted. For more information, see the HUAWEI
NetEngine80E/40E Router Command Reference.
– To delete all community attributes from a BGP route, run the apply community
none command.
– To set community attributes for a BGP route, run the apply community
{ community-number | aa:nn | internet | no-advertise | no-export | no-export-
subconfed } &<1-32> [ additive ] command.
– To set an extended community attribute (route-target) for a route, run the apply
extcommunity { rt { as-number:nn | 4as-number:nn | ipv4-address:nn } }
&<1-16> [ additive ] command.
– To set the local preference for a BGP route, run the apply local-preference
preference command.
– To set the Origin attribute for a BGP route, run the apply origin { igp | egp { as-
number-plain | as-number-dot } | incomplete } command.
– To set a preferred value for a BGP route, run the apply preferred-value preferred-
value command.
– To set dampening parameters for an EBGP route, run the apply dampening half-
life-reach reuse suppress ceiling command.
apply clauses or no apply clause.
----End
8.6.3 Configuring to Controll the Acceptment of BGP Routing

Information
After an import policy is configured, only the routes that match the import policy can be received.
Procedure
l Configure BGP to receive routes from all its peers or peer groups.
You can configure a BGP device to filter received routes. Perform the following steps on
a BGP router:
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast


4. Perform either of the following operations to configure the BGP device to filter the
routes received from all its peers or peer groups:
a. Run filter-policy { acl-number | acl-name acl-name } import, the received

routes is filtered based on an ACL.
displayed.
ACL.
system.
routes.

a. Run filter-policy acl-name acl-name import, the received routes is filtered

based on an ACL.
the basic ACL.
system.
routes.
– To filter routes based on an IP prefix list, run the filter-policy ip-prefix ip-prefix-
name import command.
NOTE
If an ACL has been referenced in the filter-policy command but no VPN instance is specified
in any ACL rule, BGP will filter routes including public network routes and private network
routes in all address families. If a VPN instance is specified in an ACL rule, only the data traffic
from the VPN instance will be filtered, and no routes of this VPN instance will be filtered.
l Configure a BGP device to receive routes from a specific peer or peer group.
You can configure a BGP device to filter received routes. Perform the following steps on
a BGP router:
1. Run:

system-view

2. Run:

3. Run:
ipv4-family unicast

4. Perform any of the following configurations to configure the BGP device to filter the
routes received from a specific peer or peer group:
a. Run peer { ipv4-address | group-name } filter-policy { acl-number | acl-
name acl-name } import, the advertised routes is filtered based on an ACL.
displayed.
ACL.
system.
routes.


a. Run peer { ipv4-address | group-name } filter-policy acl-name acl-name
import, the advertised routes is filtered based on an ACL.
the basic ACL.
system.
routes.
– To filter routes based on an IP prefix list, run the peer { ipv4-address | group-
name } ip-prefix ip-prefix-nameimport command.
– To filter routes based on an AS_Path filter, run the peer { ipv4-address | group-
name } as-path-filter { as-path-filter-number | as-path-filter-name } import
command.

– To filter routes based on a route-policy, run the peer { ipv4-address | group-

name } route-policy route-policy-name import command.
A peer group and its members can use different import policies when receiving routes.
This means that each member in a peer group can select its own policy to filter received
routes.
l Limit the number of the routes received from a peer or peer group.
When the router running BGP is attacked or network configuration errors occur, the
router receives a large number of routes from its neighbor. As a result, a large number of
resources of the router are consumed. Therefore, the administrator must limit the resources
used by the router based on network planning and the capacity of the router. BGP provides
peer-based route control to limit the number of routes to be sent by a neighbor. Therefore,
the preceding problem is addressed.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
peer { group-name | ipv4-address } route-limit limit [ percentage ]
[ alert-only | idle-forever | idle-timeout times ]
The number of routes that can be received from a peer or peer group is set.
The command provides the limit on the number of received routes based on peers.
You can configure specific parameters as required to control BGP after the number
of the routes received from a peer exceeds the threshold.
– alert-only: The peer relationship is kept. No route is received after the number of
received routes exceeds the threshold, and an alarm is generated and recorded in
the log.
– idle-forever: The peer relationship is interrupted. The router does not retry setting
up a connection. An alarm is generated and recorded in the log. In this case, run
the display bgp peer [ verbose ] command, and you can find that the status of the
peer is Idle. To restore the BGP connection, run the reset bgp command.
– idle-timeout: The peer relationship is interrupted. The router retries setting up a
connection after the timer expires. An alarm is generated and recorded in the log.
In this case, run the display bgp peer [ verbose ] command, and you can find that
the status of the peer is Idle. To restore the BGP connection before the timer
expires, run the reset bgp command.
– If none of the preceding parameters is set, the peer relationship is disconnected.
The router retries setting up a connection after 30 seconds. An alarm is generated
and recorded in the log.

NOTE
If the number of routes received by the local router exceeds the upper limit and the peer route-
limit command is used for the first time, the local router and its peer reestablish the peer relationship,
regardless of whether alert-only is set.
----End
8.6.4 Configuring BGP Soft Reset

BGP soft reset allows the system to refresh a BGP routing table dynamically without tearing
down any BGP connection if routing policies are changed.
Context
After changing a BGP import policy, you must reset BGP connections for the new import policy
to take effect, interrupting these BGP connections temporarily. BGP route-refresh allows the
system to refresh a BGP routing table dynamically without tearing down any BGP connection
if routing policies are changed.
l If a device's peer supports route-refresh, the refresh bgp command can be used on the
device to softly reset the BGP connection with the peer and update the BGP routing table.
l If a device's peer does not support route-refresh, the peer keep-all-routes command can
be used on the device to remain all routing updates received from the peer so that the device
can refresh its routing table without closing the connection with the peer.
Procedure
l If the device's peers support route-refresh, perform the following operations:
1. (Optional) Enable route-refresh.
a. Run:
system-view

b. Run:

c. Run:
peer { ipv4-address | group-name } capability-advertise route-refresh
Route-refresh is enabled.
By default, route-refresh is enabled.
If route-refresh is enabled on all BGP devices and the import policy of the local device
is changed, the local device sends a route-refresh message to peers or peer groups.
After receiving the message, the peers or peer groups resend routing information to
the local BGP device. This enables the local device to dynamically refresh its BGP
routing table and apply the new routing policy without closing any BGP connections.
2. Configure BGP soft reset.
a. Run the refresh bgp [ vpn-instance vpn-instance-name ipv4-family | vpnv4 |
vpn-target | l2vpn-ad ] { all | ipv4-address | group group-name | external |

internal } { export | import } command in the user view to softly reset the BGP
connections between the devices and its peers or peer groups.
external softly resets an EBGP connection, and internal softly resets an IBGP
connection.
export triggers outbound BGP soft reset, and import triggers inbound BGP soft reset.
l If the device's peers do not support route-refresh, perform the following operations:
– Configure the device to store all the routing updates received from its peers or peer
groups.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
peer { ipv4-address | group-name } 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.
After this command is used, all routing updates sent by a specified peer or peer group
are stored, regardless of whether an import policy is used. When the local routing
policy changes, the information can be used to regenerate BGP routes again.
NOTE
This command must be run on the local device and its peers. If the peer keep-all-routes
command is run on the device for the first time, the sessions between the device and its peers
are reestablished.
The peer keep-all-routes command does not need to be run on the router that supports route-
refresh. If the peer keep-all-routes command is run on the router, the sessions between the
router and its peers will not be reestablished but the refresh bgp command does not take effect
on the router.
----End

After configuring BGP route reception, you can view the imported routes matching a specified
filter.
Prerequisites
The BGP route reception configurations have been configured.

Procedure
l Run the display ip as-path-filter [ as-path-filter-number | as-path-filter-name ] command
to check 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 ] command to check
information about a configured extended community 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 routing-table peer ipv4-address accepted-routes command to check
information about the routes that are received by a BGP device from a specified peer and
match the routing policy.
----End
Example
After an AS_Path filter is configured, run the display ip community-filter [ basic-comm-filter-
num | adv-comm-filter-num | comm-filter-name ] command in the system view to view
information about the configured AS_Path filter. Run the display bgp routing-table peer ipv4-
address accepted-routes command to view information about the routes that are received by a
BGP device from a specified peer and match the routing policy.
# View information about a configured community filter.
<HUAWEI> display ip community-filter
Named Community basic filter: aa (ListID = 200)
permit 100
Named Community basic filter: bb (ListID = 201)
permit 200
# View the routes matching the specified BGP community filter named aa.
<HUAWEI> display bgp routing-table community-filter aa


Network NextHop MED LocPrf PrefVal Community
*> 1.1.1.1/32 10.1.1.2 100 0 <0:100>

*> 2.2.2.2/32 10.1.1.2 100 0 <0:100>
*> 3.3.3.3/32 10.1.1.2 100 0 <0:100>
# View the routes that are received by a BGP device from its peer at 10.1.1.2 and match the
routing policy.

<HUAWEI> display bgp routing-table peer 10.1.1.2 accepted-routes


*> 1.1.1.1/32 10.1.1.2 100 0 200?

*> 2.2.2.2/32 10.1.1.2 100 0 200?
*> 3.3.3.3/32 10.1.1.2 100 0 200?
8.7 Configuring a Device to Advertise BGP Supernet

Unicast Routes to BGP Peers
This section describes how to configure a Border Gateway Protocol (BGP) device to advertise
BGP supernet unicast routes to BGP peers.
A BGP supernet route has the same destination address and next hop address or has a more
detailed destination address than the next hop address. Any route that meets one of the following
conditions is a BGP supernet route.
l If you perform bitwise AND operations on the destination address mask with the destination
address and next hop address, respectively, the calculated network addresses are the same,
and the destination address mask is greater than or equal to the next hop address mask.
l If you perform bitwise AND operations on the destination address mask with the destination
address and next hop address, respectively, the calculated network addresses are different.
However, if you perform bitwise AND operations on the next hop address mask with the
destination address and next hop address, respectively, the calculated network addresses
are the same.
When a BGP device receives a BGP supernet unicast route, the BGP device sets the route invalid
and does not advertise it to other BGP peers. If a Huawei device is connected to a non-Huawei
device and you want the Huawei device to advertise BGP supernet unicast routes that it receives
from the non-Huawei device to other BGP peers, configure the Huawei device to advertise BGP
supernet unicast routes to BGP peers.
Before you configure a BGP device to send BGP supernet unicast routes to BGP peers, configure
basic BGP functions.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
supernet unicast advertise enable
The BGP device is enabled to advertise BGP supernet unicast routes to BGP peers.
----End

After you configure a BGP device to advertise BGP supernet unicast routes, check whether the
configuration takes effect.
l Run the display bgp routing-table command to check BGP supernet unicast routes.
l Run the display bgp routing-table network command to check information about a
specified BGP supernet unicast route advertised to BGP peers.
# Run the display bgp routing-table command to view received BGP supernet unicast routes.
<HUAWEI> display bgp routing-table

*>i 1.1.1.1/32 1.1.1.1 0 100 0 ?
# Run the display bgp routing-table network command to view information about a specified
BGP supernet unicast route advertised to BGP peers.

From: 1.1.1.1 (11.1.1.1)
Route Duration: 00h03m12s
Relay IP Nexthop: 11.1.1.1
Relay IP Out-Interface: Ethernet0/0/1
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best,
select, pre 20, IGP cost 10
Advertised to such 1 peers:
15.1.1.1

8.8 Configuring BGP Route Aggregation

Configuring BGP Route Aggregation on a device can reduce the sizes of routing tables on the
peers of the device.
The BGP routing table of a device on a medium or large BGP network contains a large number
of routing entries. Storing the routing table consumes a large number of memory resources, and
transmitting and processing routing information consume lots of network resources. Configuring
route aggregation can reduce the size of a routing table, prevent specific routes from being
advertised, and minimize the impact of route flapping on network performance. BGP route
aggregation and routing policies enable BGP to effectively transmit and control routes.
BGP supports automatic and manual aggregation. Manual aggregation takes precedence over
automatic aggregation. When using manual aggregation, you can apply various routing policies
and set route attributes.
Before configuring BGP route aggregation, complete the following task:
Procedure
l Configure automatic route aggregation.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
summary automatic
Automatic aggregation is configured for imported routes.

The summary automatic command aggregates routes imported by BGP. The routes
can be direct routes, static routes, RIP routes, OSPF routes, or IS-IS routes. After this
command is run, BGP aggregates routes based on natural network segments. The
command, however, cannot aggregate routes imported using the network command.
l Configure manual route aggregation.
1. Run:
system-view


2. Run:
bgp{ as-number-plain | as-number-dot }

3. Run:
ipv4-familyunicast

4. Run:
aggregate ipv4-address { mask | mask-length } [ as-set | attribute-policy
route-policy-name1 | detail-suppressed | origin-policy route-policy-name2
| suppress-policyroute-policy-name3 ] *
Manual route aggregation is configured.

as-set is used to generate an aggregated route in which the AS_Path attribute contains
AS_Path information of specific routes. If many routes need to be aggregated, exercise
caution when using this parameter. Frequent changes in specific routes cause flapping
of the aggregated route.
detail-suppressed is used to suppress the advertisement of specific routes. After
detail-suppressed is set, only aggregated routes are advertised. Aggregated routes
carry the atomic-aggregate attribute, not the community attributes of specific routes.
suppress-policy is used to suppress the advertisement of specified routes. The if-
match clause of route-policy can be used to filter routes to be suppressed. Only the
routes matching the policy will be suppressed, and the other routes will still be
advertised. The peer route-policy command can also be used to filter out the routes
not to be advertised to peers.
After origin-policy is used, only the routes matching route-policy are aggregated.
attribute-policy is used to set attributes for an aggregated route. If the AS_Path
attribute is set in the policy using the apply as-path command and as-set is set in the
aggregate command, the AS_Path attribute in the policy does not take effect. The
peer route-policy command can also be used to set attributes for an aggregated route.
Only the routes that exist in the local BGP routing table can be manually aggregated.
For example, if route 10.1.1.1/24 is not in the BGP routing table, BGP will not generate
an aggregated route for it even if the aggregate 10.1.1.1 16 command is used.
----End

After route aggregation is configured, you can check whether the configuration is correct.
l Run the display bgp routing-table [ network [ mask | mask-length ] ] command to check
information about BGP aggregated routes.
# Run the display bgp routing-table network command to view information about BGP
aggregated routes.

From: 10.2.1.2 (3.3.3.3)
Relay IP Out-interface: Ethernet3/0/1
AS-path 100, origin incomplete, pref-val 0, valid, external, best, select, pre
255
Aggregator: AS 100, Aggregator ID 3.3.3.3, Atomic-aggregate
10.1.1.1
10.2.1.2
8.9 Configuring BGP Peer Groups

Configuring BGP peer groups simplifies the BGP network configuration and improves the route
advertisement efficiency.

Before configuring BGP peer groups, familiarize yourself with the usage scenario, complete the
A BGP peer group consists of BGP peers that have the same update policies and configurations.
A large-scale BGP network has a large number of peers. Configuring and maintaining these
peers is difficult. To address this problem, configure a BGP peer group for BGP peers with the
same configurations. Configuring BGP peer groups simplifies peer management and improves
the route advertisement efficiency.
Based on the ASs where peers reside, peer groups are classified as follows:
l IBGP peer group: The peers of an IBGP peer group are in the same AS.
l Pure EBGP peer group: The peers of a pure EBGP peer group are in the same external AS.
l Mixed EBGP peer group: The peers of a mixed EBGP peer group are in different external
ASs.
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. After a peer group is created, peers can be
added to the peer group. If these peers are not configured separately, they will inherit the
configurations of the peer group. If a peer in a peer group has a specific configuration
requirement, the peer can be configured separately. The configuration of this peer will override
the configuration inherited by the peer from the peer group.
Before configuring BGP peer groups, complete the following task:

Data Preparation
To configure BGP peer groups, you need the following data.
No. Data
1 Type and name of a peer group, and IP addresses of peer group members
8.9.2 Creating IBGP Peer Groups

If multiple IBGP peers exist, adding them to an IBGP peer group can simplify the BGP network
configuration and management. When creating an IBGP peer group, you do not need to specify
an AS number for the IBGP peer group.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
group group-name internal
An IBGP peer group is created.

Step 4 Run:
peer ipv4-address group group-name
A peer is added to the peer group.
NOTE
You can repeat step 4 to add multiple peers to the peer group. If the local device has not established a peer
relationship with this peer, the device will attempt to establish a peer relationship with this peer, and set
the AS number of this peer to the AS number of the peer group.
When creating an IBGP peer group, you do not need to specify the AS number.
After configuring a peer group, you can configure BGP functions for the peer group. By default,
all peers in a peer group inherit the entire configuration of the peer group. The inherited
configuration can be overridden if you directly configure commands for the peer.
----End
8.9.3 Creating Pure EBGP Peer Groups

If multiple EBGP peers exist in an AS, adding them to an EBGP peer group can simplify the
BGP network configuration and management. All the peers in a pure EBGP peer group must
have the same AS number.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
group group-name external
A pure EBGP peer group is created.
Step 4 Run:
peer group-name as-number { as-number-plain | as-number-dot }
An AS number is set for the EBGP peer group. If peers already exist in a peer group, you can
neither change the AS number of the peer group nor delete the AS number of the peer group by
using the undo peer as-number command.
Step 5 Run:
A peer is added to the peer group.
NOTE
You can repeat step 5 to add multiple peers to the peer group. If the local device has not established a peer
relationship with this peer, the device will attempt to establish a peer relationship with this peer, and set
the AS number of this peer to the AS number of the peer group.
----End
8.9.4 Creating Mixed EBGP Peer Groups

If multiple EBGP peers exist in different ASs, adding them to a mixed EBGP peer group can
simplify the BGP network configuration and management. When creating a mixed EBGP peer
group, you need to specify an AS number for each peer.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
A mixed EBGP peer group is created.

Step 4 Run:
A peer is created and an AS number is set for this peer.

Step 5 Run:
The peer is added to the peer group.
NOTE
You can repeat Steps 4 and 5 to add multiple peers to the peer group.
You need to specify an AS number for each peer in a mixed EBGP peer group.
----End

After BGP peer groups are configured, you can view information about BGP peers and BGP
peer groups.
Prerequisites
The BGP peer group configurations have been configured.
Procedure
l Run the display bgp peer [ ipv4-address ] verbose command to check detailed information
about BGP peers.
l Run the display bgp group [ group-name ] command to check information about BGP
peer groups.
NOTE
This command is applied only to devices on which BGP peer groups are created.
If a peer group is specified in this command, detailed information about this peer group
will be displayed. If no peer group is specified in this command, information about all BGP
peer groups is displayed.
----End
Example
Run the display bgp group [ group-name ] command in the system view to view information
about a specified peer group.
# View information about a peer group named rr.

<HUAWEI> display bgp group rr

BGP peer-group: rr
Remote AS: 100
Authentication type configured: None
Group's BFD has been enabled
Type : internal
Configured hold timer value: 180
Keepalive timer value: 60
Minimum route advertisement interval is 15 seconds
PeerSession Members:
10.1.1.2 10.1.1.3
Maximum allowed route limit: 100
Threshold: 75%, Parameter: always connect-retry(default)
Peer Preferred Value: 0
No routing policy is configured
Peer Members:
10.1.1.2 4 100 2004 2175 0 0028h55m Established 0
10.1.1.3 4 100 0 0 0 00:14:52 Connect 0
8.10 Configuring BGP Route Reflectors

Deploying BGP RRs allows IBGP peers to communicate without establishing full-mesh
connections between them. Using BGP RRs simplifies network configurations and improves
route advertisement efficiency.

Before configuring BGP RRs, familiarize yourself with the usage scenario, complete the pre-
BGP uses the AS_Path attribute to prevent route loops, but it does not change the AS_Path
attribute of a route sent between IBGP peers within an AS. This may cause a route loop. To
prevent this problem, the BGP standard defines that a BGP device is prohibited from advertising
any route that received from another IBGP peer. Full-mesh connections then must be created
between IBGP peers to ensure the connectivity between them. If many IBGP peers exists, the
overhead will be large and the configuration workload will be heavy for establishing full-mesh
logical connections between routers. In addition, the network will be difficult to maintain.
Using BGP confederations or RRs can solve these problems. A BGP confederation consists of
several sub-ASs in an AS. Full-mesh logical connections need to be established and maintained
between IBGP peers in each sub-AS. To deploy RRs, you only need to configure the RR
functionality on routers and do not need to change configurations on other devices. In this regard,
deploying RRs is easier and more flexible than deploying confederations.
Before configuring a BGP RR, complete the following task:
Data Preparation
To configure a BGP RR, you need the following data.

No. Data
1 Role of each router (RR, client, or non-client)
2 (Optional) Cluster ID of the RR
8.10.2 Configuring a Route Reflector and Specifying Clients

Deploying an RR and clients in an address family allows IBGP peers to communicate without
having full-mesh logical connections established between them, reducing network configuration
and maintenance workload, and improving network performance.
Context
In an AS, one router serves as an RR, and the other routers serve as clients. IBGP peer
relationships are set up between the RR and clients. The RR reflects routes between clients, and
BGP connections do not need to be established between the clients. A BGP device that is neither
an RR nor a client is called a non-client. Non-clients and the RR must establish full-mesh
connections with each other.
After receiving IBGP routes, the RR selects optimal routes based on BGP route selection policies
and advertises learned routes to its clients and non-clients following the rules described below:
l After learning routes from non-clients, the RR advertises the routes to all clients.
l After learning routes from clients, the RR advertises the routes to all non-clients and clients.
In addition, the RR advertises learned EBGP routes to all non-clients and clients.
It is easy to configure an RR. The RR functionality only needs to be configured on one router.
Configurations on clients are not required.
Perform the following steps on the router that is running BGP and is to be specified as an RR:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
peer { ipv4-address | group-name } reflect-client
The router is specified as an RR and its clients are configured.

To add more clients, repeat the step.
reflect-client configured in an address family is valid only in this address family and cannot be
inherited by other address families. Configuring reflect-client in a specified address family is
recommended.
----End
8.10.3 (Optional) Disabling Route Reflection Between Clients

If the clients of an RR are fully meshed, prohibiting route reflection among the clients can reduce
the link cost.
Context
The RR usually advertises the routes learned from clients to all non-clients and clients. If full-
mesh logical connections have been established between all the clients of the RR, the clients are
capable of sending routes to each other without the help of the RR. Route reflection can be
disabled between clients to reduce the stress on the RR.
Perform the following steps on the RR that is running BGP.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
undo reflect between-clients
Route reflection is disabled between clients.
If the clients of an RR have established full-mesh connections with each other, the undo reflect
between-clients command can be used to disable route reflection between clients in order to
reduce the link cost. By default, route reflection is enabled between the clients of an RR.
This command can only be configured on the RR.
----End
8.10.4 (Optional) Configuring the Cluster ID for a Route Reflector

If several RRs are deployed in a cluster, assigning the same cluster ID to them can prevent route
loops.

Context
A backup RR is usually deployed in an AS to prevent a fault on an RR from causing the clients
and non-clients unable to receive routing information. This backup RR improves network
reliability.
As shown in Figure 8-2, RR1 and RR2 are configured as backups for each other in AS 65000.
Clients 1, 2, and 3 are their clients. An IBGP peer relationship is set up between RR1 and RR2
so that each RR is the other RR's non-client.
Figure 8-2 RR cluster
RR1 RR2
IBGP
Cluster
IBGP IBGP IBGP
Client1 Client2 Client3

AS65000
Route loops may easily occur in this network. For example, when Client1 receives an updated
route from an EBGP peer, it uses IBGP to advertise this route to RR1 and RR2. Then the
following problems will happen in the same time:
l RR1 advertises it to its clients and non-client (RR2),
l RR2 advertises it to its clients and non-client (RR1).
As a result, a route loop occurs between RR1 and RR2.
To address this problem, configure all routers on the network shown in Figure 8-2 into the same
cluster and assign them the same cluster ID. After the configuration is complete, if Client1
receives an updated route from an EBGP peer, it uses IBGP to advertise this route to RR1 and
RR2.
l After receiving this route, RR1 reflects it to its clients and RR2 and adds the local cluster
ID to the front of the cluster list.
l After receiving the route reflected from RR1, RR2 checks the cluster list. After finding that
the local cluster ID is already on the cluster list, RR2 discards the route.
NOTE
Using a cluster list prevents route loops between RRs within an AS.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
reflector cluster-id cluster-id
A cluster ID is configured.
If a cluster has multiple RRs, use this command to set the same cluster-id for these RRs to prevent
route loops.
NOTE
To ensure that a client can learn the routes reflected by an RR, the Cluster ID configured on the RR must
be different from the Cluster ID of the client (By default, the client uses its Router ID as the cluster ID). If
the Cluster ID is the same as the Cluster ID of the client, the client discards received routes.
----End
8.10.5 (Optional) Preventing BGP Routes from Being Added into

the IP Routing Table
Disabling BGP route delivery to the IP routing table on an RR can prevent traffic from being
forwarded by the RR, improving route advertisement efficiency.
Context
Usually, BGP routes are delivered to the IP routing table on the router to guide traffic forwarding.
If the router does not need to forward traffic, disable BGP route delivery to the IP routing table
on the router.
BGP route delivery to the IP routing table is generally disabled on RRs. An RR transmits routes
and forwards traffic within an AS. If the RR is connected to many clients and non-clients, the
route transmission task will consume a lot of CPU resources of the RR and cause the RR unable
to implement traffic forwarding. To improve the efficiency of route transmission, disable BGP
route delivery to the IP routing table on the RR to make the RR dedicated to route transmission.
Procedure
Step 1 Run:
system-view
Step 2 Run:


Step 3 Run:
ipv4-family unicast

Step 4 Run:
routing-table rib-only [ route-policy route-policy-name ]
BGP route delivery to the IP routing table is disabled.

The routes preferred by BGP are delivered to the IP routing table by default.
If route-policy route-policy-name is configured in the routing-table rib-only command, routes
matching the policy are not delivered to the IP routing table, and routes not matching the policy
are delivered to the IP routing table, with the route attributes unchanged.
NOTE
The routing-table rib-only command and the active-route-advertise command are mutually exclusive.
----End
8.10.6 (Optional) Enabling the RR to Modify the Route Attributes

Using the Export Policy
You can enable the route reflector (RR) to modify the route attributes using the export policy to
change route selection results of the BGP.
Context
According to RFC 4456, the route attributes on the RR cannot be modified using the export
policy. This is because it may cause route loops. By default, the RR is disabled from modifying
the route attributes using the export policy. But if you need to re-plan the network traffic, you
can enable the RR to modify the route attributes by using the export policy.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ipv4-family unicast

Step 4 Run:
reflect change-path-attribute
You can enable the RR to modify the route attributes of the BGP routes using the export policy.

By default, you can disable the RR from modifying the route attributes using the export policy.
After you enable the reflect change-path-attribute command on an RR, the configurations of
the RR attributes modified using the export policy takes effect immediately. Perform the
following operations:
l Run the apply as-path command to modify the AS_Path attributes of BGP routes.
l Run the apply comm-filter delete command to delete all community attributes from a BGP
route.
l Run the apply community command modifies the community attributes of BGP routes.
l Run the apply cost command to modify the cost of BGP routes, that is, to modify its
multi_exit discriminator (MED).
l Run the apply ip-address nexthop command to modify the next hop of the BGP routes.
l Run the apply local-preference command to modify the local preference of BGP routes.
l Run the apply origin command to modify the Origin attributes of BGP routes.
l Run the apply extcommunity command to modify the extended community attributes of
BGP routes.
NOTE
After the reflect change-path-attribute command is run on the RR, the peer route-policy export
command takes precedence over the peer next-hop-invariable and peer next-hop-local commands.
----End

After configuring BGP RRs, you can view BGP RR configurations and routing information
transmitted by BGP.
Prerequisites
All BGP RR configurations have been configured.
Procedure
l Run the display bgp [ vpnv4 [ vpn-instance vpn-instance-name | all ] | vpn-target |
l2vpn | vpls ] peer [ ipv4-address ] verbose command to check detailed information about
BGP peers.
prefixes ] ] ] command to check information in a BGP routing table.
----End
Example
# After a BGP RR is configured, run the following command to view detailed information about
its peers.
<HUAWEI> display bgp peer 10.1.1.2 verbose
BGP Peer is 10.1.1.2, remote AS 65009

Type: IBGP link
BGP version 4, Remote router ID 4.4.4.4

Update-group ID: 1
BGP current state: Established, Up for 00h01m24s
BGP current event: KATimerExpired
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 - 50450
Configured: Connect-retry Time: 32 sec
Configured: Active Hold Time: 180 sec Keepalive Time:60 sec
Received : Active Hold Time: 180 sec
Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec
Peer optional capabilities:
Peer supports bgp multi-protocol extension
Peer supports bgp route refresh capability
Peer supports bgp 4-byte-as capability
Address family IPv4 Unicast: advertised and received
Received: Total 3 messages
Update messages 1
Open messages 1
KeepAlive messages 2
Notification messages 0
Refresh messages 0
Sent: Total 4 messages
Update messages 1
Open messages 2
Refresh messages 0
Last keepalive received: 2012-03-06 19:17:37 UTC-08:00
Last keepalive sent : 2012-03-06 19:17:37 UTC-08:00
Last update received: 2012-03-06 19:17:43 UTC-08:00
Last update sent : 2012-03-06 19:17:37 UTC-08:00
Optional capabilities:
Route refresh capability has been enabled
4-byte-as capability has been enabled
It's route-reflector-client
Routing policy configured:
NOTE
The message of It's route-reflector-client will be displayed in the command output only after the display
bgp peer ipv4-address verbose command is run on an RR.
8.11 Configuring a BGP Confederation

BGP confederations can be configured on a large BGP network to reduce the number of IBGP
connections and simplify routing policy management, increasing route advertisement efficiency.
A confederations can be used to reduce the number of IBGP connections in an AS. It divides an
AS into several sub-ASs. Full-mesh IBGP connections are established between devices in each
sub-AS, and full-mesh EBGP connections are established between devices in different sub-ASs,
Compared with RRs, confederations facilitate IGP extensions.

Before configuring a BGP confederation, complete the following tasks:
l Configuring link layer protocol parameters for interfaces to ensure that the link layer
protocol on the interfaces is Up
Procedure
l Configure a BGP confederation.
Perform the following steps on a BGP device:
1. Run:
system-view

2. Run:

3. Run:
confederation id { as-number-plain | as-number-dot }
A confederation ID is set.
4. Run:
confederation peer-as { as-number-plain | as-number-dot } &<1-32>
The number of the sub-AS where other EBGP peers connected to the local AS reside
is set.
{ as-number-plain | as-number-dot } is valid in the confederation only when the sub-

ASs of the confederation are configured.
The confederation id and confederation peer-as commands must be run on all the
EBGP peers in the same confederation, and the same confederation ID must be set for
these EBGP peers.
NOTE
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.
l Configure confederation compatibility.
Other routers may implement the confederation that does not comply with the RFC
standard. In such a situation, confederation compatibility must be configured. Perform the
following steps on a BGP device:
1. Run:
system-view

2. Run:


3. Run:
confederation nonstandard
The routers are configured to be compatible with the nonstandard AS confederation.

By default, the configured confederation accords with RFC 3065.
----End

After a confederation is configured, you can check whether the configuration is correct.
about BGP peers.
# Run the display bgp routing-table network command to view information about a specified
BGP route. For example:
From: 10.1.3.1 (1.1.1.1)
Relay IP Out-Interface: Pos1/0/0
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal-
confed, best, select, active, pre 255
8.12 Configuring BGP Community Attributes

Community attributes are used to simplify routing policy management.

Before configuring BGP community attributes, familiarize yourself with the usage scenario,
Community attributes are used to simplify routing policy application and facilitate network
maintenance. They allow a group of BGP devices in different ASs to share the same routing
policies. Before advertising a route with the community attribute to peers, a BGP device can
change the original community attribute of this route. Community attributes are route attributes,
which are transmitted between BGP peers, and the transmission is not restricted within an AS.
Before configuring BGP community attributes, complete the following task:

Data Preparation
To configure BGP Community attributes, you need the following data.
No. Data
1 Community attribute value
2 Route-policy name, node sequence number, and matching condition
3 Names of inbound and outbound routing policies
8.12.2 Configuring Community Attribute-Related Routing Policies

A routing policy that references a community attribute needs to be configured before the
community attribute is advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
A node is configured for a routing policy, and the view of the routing policy is displayed.
Step 3 (Optional) Configure filtering conditions (if-match clauses) for a routing policy. Community
attributes can be added only to the routes that pass the filtering, and the community attributes
of only the routes that pass the filtering can be modified.
For configuration details, see (Optional) Configuring if-match Clauses.
Step 4 Configure community or extended community attributes for BGP routes.

l Run:
apply community { community-number | aa:nn | internet | no-advertise | no-
export | no-export-subconfed } &<1-32> [ additive ]
Community attributes are configured for BGP routes.

NOTE
A maximum of 32 community attributes can be configured in the apply community command.

l Run:
apply extcommunity { rt { as-number:nn | ipv4-address:nn } } &<1-16>
[ additive ]
An extended community attribute (Route-Target) is configured for BGP routes.
----End

8.12.3 Configuring a BGP Device to Send Community Attributes to

Its Peer
A community attribute takes effect only after the community attribute and the routing policy
referencing the community attribute are advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
peer { ipv4-address | group-name } route-policy route-policy-name export
An export routing policy is configured.
NOTE
When configuring a BGP community, use a routing policy to define the community attribute, and apply
the routing policy to the routes to be advertised.
For details on routing policy configurations, see the chapter "Routing Policy Configuration."
Step 5 Run the following commands to advertise community attributes to the peer group.
l To configure the BGP device to send a standard community attribute to its peer or peer group,
run:
peer { ipv4-address | group-name } advertise-community
l To advertise an extended community attribute to a specified peer or peer group, perform the
following steps:
1. Run the peer { ipv4-address | group-name } advertise-ext-community command to

advertise an extended community attribute to a specified peer or peer group.
2. (Optional) 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.

NOTE
After the peer advertise-ext-community command is enabled, BGP sends the routes with extended
community attribute to its peer or peer group. If the peer or peer group only want to receive the routes, but
not extended community attribute, you can configure the peer discard-ext-community command on the
peer or peer group to discard the extended community attribute from the received routing information.
----End

After configuring BGP community attributes, you can view the configured BGP community
attributes.
Prerequisites
The BGP community attribute configurations have been configured.
Procedure
l Run the display bgp routing-table network [ mask | mask-length ] command to check the
detailed information about BGP routes.
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 information about the routes carrying specified BGP community attributes.
----End
Example
# Run the display bgp routing-table community command to view the routes carrying specified
BGP community attributes.
<HUAWEI> display bgp routing-table community
* 1.1.1.0/24 1.1.1.1 0 0 no-export
* 1.1.1.2/32 1.1.1.1 0 0 no-export
*> 192.168.10.0 10.2.1.2 0 0 no-export-
subconfed
*> 192.168.15.0 10.2.1.2 0 0 internet
*> 192.168.18.0 10.2.1.2 0 0 no-advertise
8.13 Configuring Prefix-based BGP ORF

Prefix-based BGP outbound route filtering (ORF) is used to enable a BGP device to send to its
BGP peer a set of routing policies that can be used by its peer to filter out unwanted routes during
route advertisement.
During routing information transmission between two devices, routing policies can be used on
receiving and sending devices to filter routes.

l If a routing policy is used to filter routing information received by the route receiving device
but no policy is used to filter routing information to be sent by the route sending device
and the route sending device sends a great deal of routing information, the route receiving
device will have to process a great deal of unwanted routing information. This consumes
a lot of network bandwidth resources.
l If routes to be advertised by the route sending device need to be filtered and the device has
many BGP peers, many export policies need to be configured on the device. This is
unhelpful for network planning and maintenance and consumes lots of memory resources.
To address these problems, prefix-based BGP ORF is used to implement on-demand BGP route
advertisement. A BGP device uses an export policy provided by a route receiving device to filter
routes before sending these routes. It is unnecessary for the local device to provide a separate
export policy for each BGP peer. As a result, the loads of the two communication devices,
network bandwidth consumption, and configuration workload are reduced.
NOTE
Currently, only prefix-based export policies are supported.
Before configuring prefix-based BGP ORF, complete the following tasks:

l Configuring an IPv4 Prefix List
Data Preparation
To configure prefix-based BGP ORF, you need the following data.
No. Data
1 Address of a peer or name of a peer group
2 Name of an IP prefix list
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast

Step 4 Run:
peer { group-name | ipv4-address } capability-advertise orf [ non-standard-
compatible ] ip-prefix { both | receive | send } [ standard-match ]
Prefix-based ORF is enabled for a BGP peer or peer group.

By default, prefix-based ORF is not enabled for a peer or peer group.
NOTE
This step needs to be performed on both communication devices.

The ORF capability supported by non-Huawei devices may be different from that defined in the RFC
standard. To enable a Huawei device to communicate with a non-Huawei device, ensure that the devices
are configured with the same compatibility mode (either non-standard-compatible or RFC-compatible).
By default, the RFC-compatible mode is used.
BGP ORF has three modes: send, receive, and both. In send mode, a device can send ORF information. In
receive mode, a device can receive ORF information. In both mode, a device can either send or receive
ORF information. To enable a device to receive ORF IP-prefix information, configure the both or receive
mode on the device and the both or send mode on its peer.
Step 5 Run:
peer { group-name | ipv4-address } ip-prefix ip-prefix-name import
A prefix-based import policy is configured for a peer or peer group.
NOTE
This step is performed only on the receiving device. An IP prefix list specified by ip-prefix-name must
have been configured. Otherwise, route filtering cannot be implemented. For details on IPv4 prefix list
configurations, see 10.2.2 Configuring an IPv4 Prefix List.
----End

After prefix-based BGP ORF is configured, you can run the following commands to check the
previous configuration.
l Run the display bgp peer [ ipv4-address ] verbose command to check prefix-based BGP
ORF negotiation information.
l Run the display bgp peer ipv4-address orf ip-prefix command to check prefix-based BGP
ORF information received from a specified peer.
NOTE
The display bgp peer ipv4-address orf ip-prefix command must be run only on devices that have
sent routing information.
# View prefix-based BGP ORF negotiation information.


Type: EBGP link
Update-group ID: 1
BGP current event: RecvRouteRefresh


Peer supports bgp outbound route filter capability
Support Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
Update messages 1
Open messages 1
Refresh messages 1
Update messages 5
Open messages 2
Refresh messages 1
Outbound route filter capability has been enabled
Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
Multi-hop ebgp has been enabled
No import update filter list
No export update filter list
Import prefix list is: 1
No export prefix list
No import route policy
No export route policy
No import distribute policy
No export distribute policy
# View prefix-based ORF information received from a specified peer.

<HUAWEI> display bgp peer 10.1.1.1 orf ip-prefix
Total number of ip-prefix received: 1
Index Action Prefix MaskLen MinLen MaxLen
10 Permit 3.3.3.3 32
8.14 Configuring to Adjust the BGP Network Convergence

Speed
You can adjust the BGP network convergence speed by adjusting BGP peer connection
parameters to adapt to changes on large-scale networks.


Before adjusting the BGP network convergence speed, familiarize yourself with the usage
Usage Scenario
BGP is used to transmit routing information on large-scale networks. Frequent network changes
affect the establishment and maintenance of BGP peer relationships and the BGP network
convergence speed.
BGP route dampening and triggered update suppress frequent route changes to an extent, but
cannot minimize the impact of network flapping on BGP connections.
To suppress BGP network flapping and speed up BGP network convergence, configure BGP
timers, disable rapid EBGP connection reset, enable BGP tracking and slow peer detection.
l ConnectRetry timer
A ConnectRetry timer is used to set an interval between BGP attempts to initiate TCP
connections. 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.
You can accelerate or slow down the establishment of BGP peer relationships by changing
the BGP ConnectRetry interval. For example, if the ConnectRetry interval is reduced, BGP
will wait less time before retrying to establish a TCP connection when the previous attempt
fails, which speeds up TCP connection establishment. If a BGP peer flaps constantly, the
ConnectRetry interval can be increased to suppress route flapping caused by BGP peer
flapping, which speeds up route convergence.
l BGP Keepalive and hold timers
BGP uses Keepalive messages to maintain BGP peer relationships and monitor connection
status.
After establishing a BGP connection, two peers send Keepalive messages periodically to
each other to detect the BGP connection status. If the router does not receive any Keepalive
message or any other types of packets from the peer within the hold time, the router
considers the BGP connection interrupted and terminates the BGP connection.
l BGP MinRouteAdvertisementIntervalTimer
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. If a route
changes frequently, to prevent the router from sending Update messages upon every
change, set the interval at which Update messages are sent.
l Rapid EBGP connection reset
Rapid EBGP connection reset is enabled by default so that EBGP can quickly detect the
status of interfaces used to establish EBGP connections. If the interface status changes
frequently, disable rapid EBGP connection reset. After rapid EBGP connection reset is
disabled, direct EBPG sessions will not be reestablished and deleted as interface alternates
between Up and Down, which speeds up network convergence.
l BGP peer tracking

BGP peer tracking can speed up network convergence by adjusting the interval between
peer unreachability discovery and a connection interruption. BGP peer tracking is easy to
deploy and has good extensibility.
l Slow peer detection
After slow peer detection is configured on a device, the device identifies the slow BGP
peer (if any) and removes it from the update peer-group to prevent this slow peer from
affecting route advertisement to other peers in this update peer-group. Slow peer detection
speeds up BGP network convergence.
Before adjusting the BGP network convergence speed, configure basic BGP functions.
Data Preparation
To adjust the BGP network convergence speed, you need the following data.
No. Data
1 Value of the ConnectRetry timer
2 Values of BGP Keepalive and hold timers
3 Value of the MinRouteAdvertisementIntervalTimer
4 Interval between peer unreachability discovery and a connection interruption
5 Period for slow peer detection
8.14.2 Configuring a BGP ConnectRetry Timer

You can control the speed at which BGP peer relationships are established by changing the BGP
ConnectRetry timer value.
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.
Perform the following steps on a BGP router:
1. Run:
system-view

2. Run:

3. Run:
timer connect-retry connect-retry-time
A BGP ConnectRetry timer is configured for all peers or peer groups.
By default, the ConnectRetry timer value is 32s.

l Configure a ConnectRetry timer for a specific peer or peer group.
1. Run:
system-view

2. Run:

3. Run:
peer { group-name | ipv4-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.
The ConnectRetry timer configured for a peer or peer group takes precedence over
that configured for all peers or peer groups.
----End
8.14.3 Configuring BGP Keepalive and Hold Timers

The values of BGP Keepalive and hold timers determine the speed at which BGP detects network
faults. You can adjust the values of these timers to improve network performance.
Context
Keepalive messages are used by BGP to maintain peer relationships. After establishing a BGP
connection, two peers periodically send Keepalive messages to each other to detect BGP peer
relationship status. If a device receives no Keepalive message from its peer after the hold timer
expires, the device considers the BGP connection to be closed.

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 routers, 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. This reduces loads of routers. 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.
NOTICE
Changing timer values using the timer command or the peer timer command interrupts BGP
peer relationships between routers. Therefore, exercise caution before changing the value of a
timer.
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.
Procedure
l Configure BGP timers for all peers or peer groups.
1. Run:
system-view

2. Run:

3. 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 and is not less than one second. If the holdtime is not set to 0, it is 3s at least.
By default, the keepalive-time value is 60s and the hold-time value is 180s.
NOTE
Setting the Keepalive time to 20s is recommended. If the Keepalive time is smaller than 20s,
sessions between peers may be closed.
When setting values of keepalive-time and hold-time, note the following points:

– The keepalive-time and hold-time values cannot be both set to 0. Otherwise, the
BGP timers become invalid, meaning that BGP will not send Keepalive messages
to detect connection status.
– The hold-time value cannot be much greater than the keepalive-time value. For
example, keepalive-time cannot be set to 1 while hold-time is set to 65535. If the
hold-time value is too large, BGP cannot detect connection status in time.
After a connection is established between peers, the keepalive-time and hold-time

values are negotiated by the peers. The smaller one of the hold-time values carried by
Open messages of both peers is taken as the hold-time value. The smaller of one third
of the hold-time value and the locally configured keepalive-time value is taken as the
keepalive-time value.
If the local device establishes BGP peer relationships with many devices, it needs to
process huge BGP messages. If hold-time negotiated among BGP peers is small, the
timer may expire before the local device processes the Keepalive messages sent from
other BGP peers. The peer relationships are then interrupted, and routes flap. To solve
the preceding problem, you can configure an appropriate value for min-holdtime min-
holdtime based on the CPU processing capability of the local device.
If the value of min-holdtime is changed, but the values of keepalive-time and hold-
time negotiated between two BGP peers remain unchanged, the established peer
relationship is not affected. Only when the local device attempts to re-establish a
relationship with a remote device, the value of min-holdtime configured on the local
device takes effect. The local device compares min-holdtime with hold-time sent from
the remote device. If the value of min-holdtime exceeds that of hold-time, hold-time
negotiation fails, and the peer relationship fails to be established.
NOTE
If min-holdtime is configured on the local device, and the value of hold-time sent from the
remote device is 0, hold-time negotiation between the two devices succeeds. The negotiated
value of hold-time is 0, and the peer relationship is established. The value 0 of hold-time
indicates that the peer relationship never expires.
l Configure timers for a specific peer or peer group.
1. Run:
system-view

2. Run:

3. Run:
peer { ipv4-address | group-name } timer keepalive keepalive-time hold
hold-time [ min-holdtime min-holdtime ]
The Keepalive and hold timer values are set for a specific peer or peer group.
For information about the relationship between the keepalive-time and hold-time
values, see Configure BGP timers for all peers or peer groups.

NOTE
Timers set for a specific peer or peer group takes precedence over timers set for all
peers or peer groups.
----End
8.14.4 Configuring a MinRouteAdvertisementIntervalTimer

A proper MinRouteAdvertisementIntervalTimer can be configured to suppress frequent route
changes, improving BGP network stability.
Context
BGP peers use update messages to exchange routing information. Update messages can be used
to advertise multiple reachable routes with the same attributes or withdraw multiple unreachable
routes.
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. If a route changes
frequently, to prevent the router from sending Update messages upon every change, set the
interval at which Update messages are sent.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { ipv4-address | group-name } route-update-interval interval
A MinRouteAdvertisementIntervalTimer 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.
ipv4-address specifies the address of a specific group. group-name specifies the name of a peer
group. The MinRouteAdvertisementIntervalTimer configured for a peer takes precedence over
the MinRouteAdvertisementIntervalTimer configured for a peer group.
----End

8.14.5 Configuring the Rate at which BGP Updates Routes in

Response to Non-critical Iteration Changes
You can configure the rate at which BGP updates routes in response to non-critical iteration
changes to prevent BGP from occupying the Central Processing Unit (CPU) resource of other
protocols, reduce CPU loads, and ensure device reliability.
Context
In most cases, BGP routes do not have directly reachable next hops, and route iteration must be
used. When many BGP routes are iterated to one next hop and a non-critical iteration change
occurs on the next hop, such as a change of IGP metric or the number of load balancing routes,
an indirect next hop-enabled device can update forwarding entries rapidly. In this situation, BGP
does not need to update routes one by one, and you can configure the rate at which BGP updates
routes in response to non-critical iteration changes to allow the device to update BGP routes in
the IP routing table gradually. This configuration prevents BGP from occupying the CPU
resource of other protocols, reduces CPU loads, and ensures device reliability.
Before configuring the rate at which BGP updates routes in response to non-critical iteration
changes, configure basic BGP functions.
Data Preparation
To configure the rate at which BGP updates routes in response to non-critical iteration changes,
you need the following data.
No. Data
1 Interval at which BGP updates routes in response to non-critical iteration changes and
the number of routes that are updated during the interval
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:

nexthop recursive-lookup non-critical-event route-update-timer route-update-timer

[ route-update-number route-update-number ]
The rate at which BGP updates routes in response to non-critical iteration changes is configured.
By default, the rate at which BGP updates routes in response to non-critical iteration changes is
not configured.
If route-update-number route-update-number is configured, the number of routes that are

updated each second is route-update-number/route-update-timer. For example, route-update-
timer is 5 and route-update-number is 1000, the number of routes that are updated each second
is 200.
NOTE
When many BGP routes are iterated to one next hop and a non-critical iteration change occurs on the next
hop, if the nexthop recursive-lookup non-critical-event route-update-timer command is configured,
the BGP route convergence is slowed down. Before BGP updates all routes associated with the next hop,
the IP routing table shows iteration information before the update. However, the forwarding entries have
been updated, and traffic is forwarded along the correct path.
The nexthop recursive-lookup non-critical-event route-update-timer command does not take effect to
critical iteration changes on a next hop, and for example, the reachability of the next hop changes due to
interface flapping.
----End
8.14.6 Disabling Fast Reset of EBGP Connections

Disabling rapid EBGP connection reset can prevent repeated reestablishment and deletion of
EBGP sessions in the event of route flapping. This speeds up BGP network convergence.
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.
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.
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 to
implement rapid BGP network convergence, and reduces network bandwidth consumption.
Perform the following steps on a BGP router.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
undo ebgp-interface-sensitive
Rapid EBGP connection reset is disabled.
NOTE
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
8.14.7 Enabling BGP Peer Tracking

BGP peer 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.
Context
BGP can be configured to detect peer relationship status changes in order to implement rapid
BGP convergence. BFD, however, needs to be configured on the entire network, and has poor
extensibility. If BFD cannot be deployed on a device to detect BGP peer relationship status,
BGP peer tracking can be enabled on the device to quickly detect link or peer unreachability,
implementing rapid network convergence.
Perform the following steps on a BGP router.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { group-name | ipv4-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.
ipv4-address specifies the address of a peer. group-name specifies the name of a peer group.
BGP peer tracking configured on a peer takes precedence over BGP peer tracking configured
on the peer group of this peer.

If delay-time is not specified, the default delay (0 seconds) is used. This means that a BGP device
tears down the connection with a peer immediately after detecting the peer unreachable.
A proper delay-time value can ensure network stability.
l If an IBGP peer relationship is established based on an IGP route, the delay-time values set
on BGP peers must be greater than the IGP route convergence time. Otherwise, if IGP route
flapping occurs, the BGP peer relationship will be interrupted before network convergence
is complete.
NOTE
IGP GR is configured and a BGP peer relationship is established based on an IGP route. If a device
becomes faulty and performs an active/standby switchover, the IGP will not delete routes received by
the device. As a result, the BGP peer relationship will not be interrupted, even through BGP peer
tracking does not take effect.
l If BGP peers have negotiated the GR capability and one of the peers performs an active/
standby switchover, the delay-time values on the BGP peers must be greater than the GR
time. Otherwise, the BGP peer relationship will be interrupted before the GR time expires.
As a result, GR becomes invalid.
----End

After the BGP network convergence speed is adjusted, you can view information about BGP
peers and peer groups.
Prerequisites
Adjusting the BGP network convergence speed has been configured.
Procedure
l Run the display bgp peer [ verbose ] command to check information about BGP peers.
l Run the display bgp group [ group-name ] command to check information about BGP
peer groups.
----End
Example
Run the display bgp peer verbose command in the system view to view the configured
Keepalive timer, hold timer, MinRouteAdvertisementIntervalTimer, and BGP tracking function.
# View detailed information about BGP peers.
<HUAWEI> display bgp peer verbose

Type: EBGP link
Update-group ID: 1
BGP current event: RecvKeepalive


Configured: Min Hold Time: 15 sec
Update messages 1
Open messages 1
Refresh messages 0
Update messages 1
Open messages 1
Refresh messages 0
Tracking has been enabled, and the delay is 50s
NOTE
"Tracking has been enabled, and the delay is 50s" is displayed only when the display bgp peer verbose
command is run on the router enabled with BGP tracking.
8.15 Configuring BGP Route Dampening

BGP route dampening can be configured to suppress unstable routes.
The main cause of route instability is route flapping. A route is considered to be flapping when
it repeatedly appears and then disappears in the routing table. BGP is generally applied to
complex networks where routes change frequently. Frequent route flapping consumes lots of
bandwidth and CPU resources and even seriously affects network operations.
BGP route dampening prevents frequent route flapping by using a penalty value to measure route
stability. When a route flaps for the first time, a penalty value is assigned to the route. Later,
each time the route flaps, the penalty value of the route increases by a specific value. The greater
the penalty value, the less stable the route. If the penalty value of a route exceeds the pre-defined
threshold, the route will not be advertised until the penalty value of the route reduces to the reuse
threshold.

Route dampening applies only to EBGP routes. IBGP routes, however, cannot be dampened.
Generally, IBGP routes include routes from the local AS, requiring that the forwarding tables
be the same. In addition, IGP fast convergence aims to achieve information synchronization. If
IBGP routes are dampened, dampening parameters vary on different devices, and the forwarding
tables are inconsistent.
Before configuring BGP route dampening, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
dampening [ half-life-reach reuse suppress ceiling | route-policy route-policy-
name ] *
BGP route dampening parameters are set.
NOTE
The dampening command takes effect only for EBGP routes.
When you configure BGP route dampening, the values of reuse, suppress, and ceiling should
meet the relationship of reuse<suppress<ceiling.
If routes are differentiated based on policies and the dampening command is run to reference
a route-policy, BGP can use different route dampening parameters to suppress different routes.
----End

After BGP route dampening is configured, you can check whether the configuration is correct.
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 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.
# Run the display bgp routing-table flap-info command to view BGP route flapping statistics.
For example:
<HUAWEI> display bgp routing-table flap-info
h - history, i - internal, s - suppressed,
Origin codes: i - IGP, e - EGP, ? - incomplete

Network From Flaps Duration Reuse Path/Ogn
d 129.1.1.0 20.20.200.200 5 00:00:36 00:40:47 600i

*> 129.1.1.0 20.20.200.202 1 00:04:07 100?
d 129.1.2.0 20.20.200.200 5 00:00:36 00:40:47 600i
*> 129.1.2.0 20.20.200.202 1 00:04:07 100?
d 129.1.3.0 20.20.200.200 5 00:00:36 00:40:47 600i
d 129.1.4.0 20.20.200.200 5 00:00:36 00:40:47 600i
d 129.1.5.0 20.20.200.200 5 00:00:36 00:40:47 600i
# Run the display bgp routing-table dampened command to view dampened BGP routes. For
example:
<HUAWEI> display bgp routing-table dampened
Status codes: * - valid, > - best, d - damped

Network From Reuse Path/Origin
d 8.6.244.0/23 223.1.41.247 01:06:25 65534 4837 174 11096 6356i
d 9.17.79.0/24 223.1.41.247 01:06:25 65534 837 3356 23504 29777i
d 9.17.110.0/24 223.1.41.247 01:06:25 65534 837 3356 23504 29777i
d 61.57.144.0/20 223.1.41.247 01:06:25 65534 4837 10026 9924
18429,18429i
d 63.76.216.0/24 223.1.41.247 01:06:25 65534 4837 701 26959i
d 63.78.142.0/24 223.1.41.247 01:06:25 65534 4837 701 26959i
d 63.115.136.0/23 223.1.41.247 01:06:25 65534 4837 701 26956i
d 65.243.170.0/24 223.1.41.247 01:06:25 65534 4837 701 26959i
# Run the display bgp routing-table dampening parameter command to view configured BGP
route dampening parameters. For example:
<HUAWEI> display bgp routing-table dampening parameter
Maximum Suppress Time(in second) : 3973
Ceiling Value : 16000
Reuse Value : 750
HalfLife Time(in second) : 900
Suppress-Limit : 2000
8.16 Configuring a BGP Device to Send a Default Route to

Its Peer
After a BGP device is configured to send a default route to its peer, the BGP device sends a
default route with the local address as the next-hop address to a specified peer, regardless of
whether there are default routes in the local routing table. This greatly reduces the number of
routes on the network.

The BGP routing table of a device on a medium or large BGP network contains a large number
of routing entries. Storing the routing table consumes a large number of memory resources, and
transmitting and processing routing information consume lots of network resources. If a device
needs to send multiple routes to its peer, the device can be configured to send only a default
route with the local address as the next-hop address to its peer, regardless of whether there are
default routes in the local routing table. This greatly reduces the number of routes on the network
and the consumption of memory resources on the peer and network resources.
Figure 8-3 Networking diagram for configuring a BGP device to send a default route to its peer
20.1.1.0/24
RouterA
192.168.2.2/24
20.2.1.0/24
192.168.2.1/24
RouterB
20.3.1.0/24
On the network shown in Figure 8-3, Router A and Router B have established a BGP peer
relationship. Router B has imported routes to network segments 20.1.1.0/24, 20.2.1.0/24, and
20.3.1.0/24 to its BGP routing table. Router A needs to learn these routes from Router B. To
reduce the consumption of memory resources of Router A and bandwidth used by Router B for
sending routing information to Router A, configure Router B to send a default route to its peer
(Router A) and use a routing policy to prevent all the routes to network segments 20.1.1.0/24,
20.2.1.0/24, and 20.3.1.0/24 from being sent to Router A. Then, Router A stores only one default
route but can still send traffic to the three network segments.
Before configuring a BGP device to send a default route to its peer, complete the following task:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:

ipv4-family unicast
Step 4 Run:
peer { group-name | ipv4-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> ]
The device is configured to send a default route to a peer or a peer group.
If route-policy route-policy-name is set, the BGP device changes attributes of a default route
based on the specified route policy.
If conditional-route-match-all { ipv4-address1 { mask1 | mask-length1 } } &<1-4> is set, the

BGP device sends a default route to the peer only when all specified routes exist in the local
routing table.
If conditional-route-match-any { ipv4-address2 { mask2 | mask-length2 } } &<1-4> is set, the

local device sends a default route to the peer when one of the specified routes exists in the local
routing table.
NOTE
After the peer default-route-advertise command is used on a device, the device sends a default route with
the local address as the next-hop address to a specified peer, regardless of whether there is a default route
----End

After a BGP device is configured to send a default route to a peer, you can check whether the
configuration is correct.
l Run the display bgp routing-table [ ipv4-address [ mask | mask-length ] ] command on a

peer to check information about a received BGP default route.
# Run the display bgp routing-table command on a peer to view information about a received
BGP default route.


*>i 0.0.0.0 10.1.1.2 0 0 i

*> 1.1.1.1/32 10.3.1.1 0 0 20?
*>i 4.0.0.0 10.2.1.2 100 0 100?
*>i 10.0.0.0 10.2.1.2 100 0 100?
*>i 10.2.1.0/24 10.1.1.2 0 100 0 i
*> 10.3.1.0/24 0.0.0.0 0 0 i
10.3.1.1 0 0 20?
*>i 192.168.0.0/16 10.2.1.2 100 0 100?
*>i 192.168.15.0 10.2.1.2 100 0 100?

8.17 Configuring BGP Load Balancing

Configuring BGP load balancing better utilizes network resources and reduces network
congestion.
Usage Scenario
On large networks, there may be multiple valid routes to the same destination. BGP, however,
advertises only the optimal route to its peers. This may result in unbalanced traffic on different
routes.
The following two methods can be used to address the problem of unbalanced traffic:
l Use BGP routing policies to allow traffic to be balanced. For example, use a routing policy
to modify the Local_Pref, AS_Path, Origin, and Multi_Exit Discriminator (MED) attributes
of BGP routes to direct traffic to different forwarding paths for load balancing. For details
on how to modify attributes of BGP routes, see Configuring BGP Route Attributes.
l Use multiple paths for load balancing. In this method, multiple equal-cost routes need to
be configured for traffic load balancing.
NOTE
Equal-cost BGP routes can be generated for traffic load balancing only when the first 9 route attributes
described in "Principles of Route Selection" in BGP Features Supported by the NE80E/40E are
the same, and the AS_Path attributes are also the same.
Before configuring BGP load balancing, configure basic BGP functions.
Data Preparation
To configure BGP load balancing, you need the following data.
No. Data
1 Number of BGP routes to be used for load balancing
2 Number of EBGP and IBGP routes to be used for load balancing
Procedure
l Set the number of BGP routes to be used for load balancing.
1. Run:
system-view

2. Run:

3. Run:
ipv4-family unicast

4. Run:
maximum load-balancing [ ebgp | ibgp ] number
The number of BGP routes to be used for load balancing is set.
By default, the number of BGP routes to be used for load balancing is 1, meaning that
load balancing is not implemented.
– ebgp indicates that load balancing is implemented only among EBGP routes.
– ibgp indicates that load balancing is implemented only among IBGP routes.
– If neither ebgp nor ibgp is specified, both EBGP and IBGP routes participate in
load balancing, and the number of EBGP routes to be used for load balancing is
the same as the number of IBGP routes to be used for load balancing.
NOTE
The maximum load-balancing number command cannot be configured together with the
maximum load-balancing ebgp number or maximum load-balancing ibgp number
command.
When routes with the same destination addresses carry out load balancing on the public
network, the system determines the type of optimal routes first. 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.
5. (Optional) Run:
The device has been configured whether to change the next hop addresses of the routes
to be advertised to a local address.
If you run the maximum load-balancing number command, the device changes the
next hop addresses of the routes to be advertised to a local address no matter whether
the routes are used for load balancing.
If you run the maximum load-balancing [ ebgp | ibgp ] number command, the device
does not change the next hop addresses of the routes to be advertised to a local address
no matter whether the routes are used for load balancing.
6. (Optional) Run:
load-balancing as-path-ignore
The router is configured not to compare the AS_Path attributes of the routes to be used
for load balancing.
By default, the router compares the AS_Path attributes of the routes to be used for
load balancing.

NOTE
l If there are multiple routes to the same destination but these routes pass through different
ASs, load balancing cannot be implemented among these routes by default. To implement
load balancing among these routes, run the load-balancing as-path-ignore command.
After the load-balancing as-path-ignore command is run, the device no longer compares
the AS_Path attributes of the routes to be used for load balancing. Therefore, exercise
caution when using this command.
l The load-balancing as-path-ignore and bestroute as-path-ignore commands are
mutually exclusive.
7. (Optional) Run:
bestroute igp-metric-ignore
BGP labeled routes can be selected, regardless of their IGP metric values.
By default, BGP labeled routes with the same destination but different next-hop metric
values cannot balance traffic. To enable these routes to balance traffic, run the
bestroute igp-metric-ignore command. After this command is run, routes can be
selected to balance traffic, regardless of their IGP metric values. Exercise caution
when using this command.
l Set the maximum number of EBGP and IBGP routes to be used for load balancing.
This configuration is used in a VPN where a CE is dual-homed to two PEs. When the CE
and one PE belong to an AS and the CE and the other PE belong to a different AS, you can
set the number of EBGP and IBGP routes to be used for load balancing. This allows VPN
traffic to be balanced among EBGP and IBGP routes.
1. Run:
system-view

2. Run:

3. Run:
The BGP-VPN instance view is displayed.

4. Run:
maximum load-balancing eibgp number
The maximum number of EBGP and IBGP routes is set for load balancing.
By default, the maximum number of EBGP and IBGP routes to be used for load
balancing is not set.
5. (Optional) Run:
maximum load-balancing eibgp number
The device has been configured whether to change the next hop addresses of the routes
to be advertised to a local address.
If you run the maximum load-balancing eibgp number command, the device changes
the next hop addresses of the routes to be advertised to a local address no matter
whether the routes are used for load balancing.

6. (Optional) Run:
The router is configured not to compare the AS_Path attributes of the routes to be used
for load balancing.
By default, the router compares the AS_Path attributes of the routes to be used for
load balancing.
NOTE
l After the load-balancing as-path-ignore command is run, the router no longer compares
the AS_Path attributes of the routes to be used for load balancing. Therefore, exercise
caution when using this command.
l The load-balancing as-path-ignore and bestroute as-path-ignore commands are
mutually exclusive.
l Set the maximum number of labeled BGP routes for load balancing.
Load balancing among labeled BGP routes is applicable to BGP LSP scenarios, such as
inter-AS VPN Option C and seamless MPLS scenarios. After load balancing is configured
among labeled BGP routes on the ingress of a BGP LSP, they can load-balance traffic as
long as equal-cost labeled BGP routes exist, which improves network bandwidth utilization.
1. Run:
system-view

2. Run:

3. (Optional) Run:
ipv4-family unicast

4. Run:
maximum load-balancing ingress-lsp number
The maximum number of labeled BGP routes is set for load balancing.
By default, the maximum number of labeled BGP routes for load balancing is 1.
5. (Optional) Run:
bestroute igp-metric-ignore
BGP labeled routes can be selected, regardless of their IGP metric values.
By default, BGP labeled routes with the same destination but different next-hop metric
values cannot balance traffic. To enable these routes to balance traffic, run the
bestroute igp-metric-ignore command. After this command is run, routes can be
selected to balance traffic, regardless of their IGP metric values. Exercise caution
when using this command.
----End


After the BGP load balancing configurations have been configured, you can run the following
commands to check the configurations.
l Run the display ip routing-table vpn-instance vpn-instance-name [ verbose ] command
to view the routing table of a VPN instance.
# Display the routing table of the VPN instance vpn1. You can see the routes to be used for load
balancing.
<HUAWEI> display ip routing-table vpn-instance vpn1
------------------------------------------------------------------------------
Routing Tables: vpn1
10.1.1.0/24 IBGP 255 0 RD 5.5.5.9 Pos2/0/0

IBGP 255 0 RD 4.4.4.9 Pos1/0/0
10.2.1.0/24 IBGP 255 0 RD 4.4.4.9 Pos1/0/0
IBGP 255 0 RD 5.5.5.9 Pos2/0/0
10.3.1.0/24 Direct 0 0 D 10.3.1.1
Exception Handling
After the maximum load-balancing number command is run on a device, the device changes
the next hop addresses of the routes received from EBGP peers to the IP address used by the
device to establish a peer relationship with an IBGP peer. Then the device advertises the routes
to the IBGP peer. In Figure 8-4, Router B is an EBGP peer of Router A and Router D, and
Router B and Router C are IBGP peers.
Figure 8-4 Networking for configuring BGP load balancing
AS 100 AS 200
1.1.1.9/32 10.1.1.1/30
10.1.1.2/30
RouterA
10.1.2.1/30
10.1.2.2/30
AS 300
10.1.3.2/30 RouterB RouterC
10.1.3.1/30
4.4.4.9/32
RouterD
If the maximum load-balancing number command is not run Router B, Router B does not
change the next hop addresses of routes received from Router A and Router D before advertising
the routes to Router C. The command output on Router C is used as an example.

<RouterC> display bgp routing-table


i 1.1.1.9/32 10.1.1.1 0 100 0 100i

i 4.4.4.9/32 10.1.3.2 0 100 0 300i
*> 10.1.2.0/30 0.0.0.0 0 0 i
After the maximum load-balancing number command is run on Router B, Router B changes
the next hop addresses of the routes received from Router A and Router D to 10.1.2.1 used by
Router B to establish an IBGP peer relationship with Router C. Then Router B advertises the
routes to Router C. The command output on Router C is used as an example.


*>i 1.1.1.9/32 10.1.2.1 0 100 0 100i

*>i 4.4.4.9/32 10.1.2.1 0 100 0 300i
*> 10.1.2.0/30 0.0.0.0 0 0 i
The next hop address change may lead to the change of the link along which data packets are
forwarded. In Figure 8-4, if you want to keep the next hop addresses of the routes received from
Router D before Router B sends them to Router C, configure import and export routing policies
on Router B.
First, configure an import routing policy on Router B to apply a community attribute to routes
received from Router D. Second, configure an export routing policy with the community attribute
set in the import routing policy as the filtering condition on Router B. If a route matches the
filtering condition, Router B changes the next hop address of the route back to the IP address
used by Router D to establish an EBGP peer relationship with Router B. Then, Router B
advertises the route to Router C. Detailed configurations are as follows:
bgp 200
ipv4-family unicast
peer 10.1.2.2 route-policy out export
peer 10.1.3.2 route-policy in import
#
route-policy in permit node 10
if-match ip next-hop ip-prefix prefix1
apply community 1:1
#
route-policy in permit node 20
#
route-policy out permit node 10
if-match community-filter filter1
apply ip-address next-hop 10.1.3.2
#
route-policy out permit node 20
#

ip ip-prefix prefix1 index 10 permit 10.1.3.2 32

#
ip community-filter basic filter1 permit 1:1
After the preceding configurations, Router B changes the next hop addresses of the routes
received from Router D back to the IP address (10.1.3.2) used by Router D to establish an EBGP
peer relationship with Router B. Then, Router B advertises the route to Router C. The command
output on Router C is used as an example.


*>i 1.1.1.9/32 10.1.2.1 0 100 0 100i

i 4.4.4.9/32 10.1.3.2 0 100 0 300i
*> 10.1.2.0/30 0.0.0.0 0 0 i
8.18 Configuring Path MTU Auto Discovery

Path MTU auto discovery allows BGP to discover the smallest MTU value on a path to ensure
that BGP messages satisfy the path MTU requirement. This function improves transmission
efficiency and BGP performance.
The link-layer MTUs of different networks that a communication path traverses vary from each
other. The smallest MTU on the path is the most important factor that influences the
communication between the two ends of the path and is called the path MTU.
The path MTU varies with the selected route and therefore may change. In addition, path MTUs
in the inbound and outbound directions may be inconsistent. The path MTU auto discovery
function is used to find the smallest MTU on the path from the source to the destination. The
path MTU will be used as a basis for IP datagram fragmentation when TCP is used to transmit
BGP messages.
As shown in Figure 8-5, a BGP peer relationship is set up between Router A and Router D. BGP
messages are encapsulated into TCP data packets for transmission. The default maximum
segment size (MSS) is 536. Therefore, Router A sends TCP data packets of the default MSS of
536 to Router D. As a result, a lot of BGP messages are sliced and packed into different packets,
and the number of ACK packets corresponding to these messages increases, leading to a low
transmission efficiency. Path MTU auto discovery solves this problem. As shown in Figure
8-5, the path MTU between Router A and Router D is 1496. To speed up BGP message
transmission and improve BGP performance, configure path MTU auto discovery between
Router A and Router D to allow BGP messages to be transmitted based on the MSS of 1496.

Figure 8-5 Networking diagram for path MTU auto discovery

MTU=1500 MTU=1496 MTU=1500
RouterA RouterB RouterC RouterD
Before configuring path MTU auto discovery, complete the following task:
Data Preparation
To configure path MTU auto discovery, you need the following data.
No. Data
1 (Optional) Aging time of the path MTU
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { group-name | ipv4-address } path-mtu auto-discovery
Path MTU auto discovery is enabled.
By default, path MTU auto discovery is disabled.
After the command is run, a BGP peer learns the path MTU, preventing BGP messages to be
fragmented during transmission.
NOTE
The transmit and receive paths between two BGP peers may be different. Therefore, running this command
on both ends is recommended. It makes both peers exchange messages based on the path MTU.
Step 4 Run:
quit

Step 5 Run:
tcp timer pathmtu-age age-time
The aging time is set for an IPv4 path MTU.

By default, the IPv4 path MTU aging time is set to 0 seconds. An IPv4 path MTU does not age.
The path MTUs of different routes may be different. The path MTU of hosts depends on the
selected route and may change. If there are multiple routes between two communication hosts
and the routes selected for packet transmission change frequently, the path MTU aging time
needs to be configured. The system updates path MTUs based on the path MTU aging time,
increasing the transmission efficiency.
----End

After configuring path MTU auto discovery, you can run the following commands to check the
previous configuration.
l Run the display bgp peer [ ipv4-address ] verbose command to check whether path MTU
auto discovery has been successfully configured.
# After configuring path MTU auto discovery, view detailed information about the BGP peer at
10.1.1.2.

Type: IBGP link
Update-group ID: 1
BGP current state: Established, Up for 1d00h25m21s
Update messages 0
Open messages 1
Refresh messages 0
Update messages 0
Open messages 2
Refresh messages 0


Path MTU discovery has been configured
NOTE
The message of Path MTU discovery has been configured will be displayed only after the display bgp
peer ipv4-address verbose command is run on the router where path MTU auto discovery has been enabled.
8.19 Configuring the BGP Next Hop Delayed Response

Configuring the BGP next hop delayed response can minimize traffic loss during route changes.
Context
Configuring the BGP next hop delayed response can speed up BGP route convergence and
minimize traffic loss.
As shown in Figure 8-6, 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 8-6 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.
Before configuring the BGP next hop delayed response, complete the following task:
Data Preparation
To configure the BGP next hop delayed response, you need the following data.
No. Data
1 Delay in responding to changes of the next hop
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

After configuring the BGP next hop delayed response, you can run the following command to
check the previous configuration.
l Run the display current-configuration configuration bgp | include nexthop recursive-

lookup delay command to view information about the delay in responding to a next hop
change.
l Run the display current-configuration configuration bgp | include nexthop recursive-
lookup non-critical-event delay command to view information about the delay in
responding to non-urgent next hop changes.
# Display the delay in responding to a next hop change.

<HUAWEI> display current-configuration configuration bgp | include nexthop
recursive-lookup delay
nexthop recursive-lookup delay 20
# Display the delay in responding to non-urgent next hop changes.

<HUAWEI> display current-configuration configuration bgp | include nexthop
recursive-lookup non-critical-event delay
nexthop recursive-lookup non-critical-event delay 25
8.20 Configuring BFD for BGP

BFD for BGP speeds up fault detection and therefore increases the route convergence speed.

Usage Scenario
As technologies develop, voice and video services are widely applied. These services are
sensitive to the packet loss and delay. BGP periodically sends Keepalive packets to its peers to
detect the status of its peers. The detection mechanism, however, takes more than one second.
When the data transmission rate reaches the level of Gbit/s, such slow detection will cause a
large amount of data to be lost. As a result, the requirement for high reliability of carrier-class
networks cannot be met.
BFD for BGP can be used to reduce packet loss and delay. BFD for BGP detects faults on links
between BGP peers within 50 milliseconds. The fast detection speed ensures fast BGP route
convergence and minimizes traffic loss.
Before configuring BFD for BGP, configure basic BGP functions.
Data Preparation
To configure BFD for BGP, you need the following data.
No. Data
1 IP address of the BGP peer or name of the peer group for which BFD needs to be
configured
2 BFD parameters, including the minimum and maximum intervals for receiving BFD
packets, Wait-to-Restore (WTR) time of a BFD session, and the detection multiplier
3 Name of the VPN instance for which BFD needs to be configured
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Step 3 Run:
quit
Step 4 Run:

NOTE
BFD for BGP can be configured for the VPN in this view. To configure BFD for BGP for the public
network, skip this step.

peer { group-name | ipv4-address } bfd { min-tx-interval min-tx-interval | min-rx-
interval min-rx-interval | detect-multiplier multiplier | wtr wtr-value } *
NOTE
The BFD parameters of peers take precedence over those of peer groups. If BFD parameters are configured
on peers, they will be used in BFD session establishment.
The default interval for transmitting BFD packets and the default detection multiplier are
recommended. When changing the default values, pay attention to the network status and the
network reliability requirement. A short interval for transmitting BFD packets can be configured
for a link that has a higher reliability requirement. A long interval for transmitting BFD packets
can be configured for a link that has a lower reliability requirement.
NOTE
There are three formulas: Actual interval for the local device to send BFD packets = max {Locally
configured interval for transmitting BFD packets, Remotely configured interval for receiving BFD
packets}, Actual interval for the local device to receive BFD packets = max {Remotely configured interval
for transmitting BFD packets, Locally configured interval for receiving BFD packets}, and Local detection
period = Actual interval for receiving BFD packets x Remotely configured BFD detection multiplier.
For example:
l On the local device, the configured interval for transmitting BFD packets is 200 ms, the interval for
receiving BFD packets is 300 ms, and the detection multiplier is 4.
l On the peer device, the configured interval for transmitting BFD packets is 100 ms, the interval for
Then:
l On the local device, the actual interval for transmitting BFD packets is 600 ms calculated by using the
formula max {200 ms, 600 ms}; the interval for receiving BFD packets 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 device, the actual interval for transmitting BFD packets is 300 ms calculated by using the
by 4.
wtr wtr-value can be specified in the command to suppress frequent BFD and BGP session
flapping caused by link flapping. If a BFD session over a link goes Down, it does not go Up
immediately after the link recovers. Instead, the BFD session waits for the WTR timer to expire
before going Up. If the link fails again before the WTR timer expires, BFD does not send a link
fault message to BGP, and the BGP session status is stabilized.
The default value of wtr-value is 0, which means that the WTR timer will not be started.
Step 7 Run:
peer { group-name | ipv4-address } bfd enable [ single-hop-prefer ]

BFD is enabled for the peer or peer group, and a BFD session is established using default
parameters.
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.
After BFD is enabled for a peer group, BFD sessions will be created on the peers that belong to
this peer group and are not configured with the peer bfd block command.

peer ipv4-address bfd block
A peer is prevented from inheriting the BFD function of the peer group to which it belongs.
If a peer joins a peer group enabled with BFD, the peer inherits the BFD configuration of the
group and creates a BFD session. To prevent the peer from inheriting the BFD function of the
peer group, perform this step.
NOTE
The peer bfd block command and the peer bfd enable command are mutually exclusive. After the peer
bfd block command is run, the BFD session is automatically deleted.
----End

After configuring BFD for BGP, you can run the following command to check the
configurations.
l Run the display bgp bfd session { [ vpnv4 vpn-instance vpn-instance-name ] peer ipv4-
address | all } command to check information about the BFD session between BGP peers.
# View information about the BFD session between BGP peers.

<HUAWEI> display bgp bfd session peer 10.1.1.2
Local_Address Peer_Address LD/RD Interface
10.1.1.1 10.1.1.2 8192/8192 GigabitEthernet1/0/2
Tx-interval(ms) Rx-interval(ms) Multiplier Session-State
100 100 3 Up
Wtr-interval(m)
0
8.21 Configuring BGP Auto FRR

Border Gateway Protocol (BGP) Auto fast reroute (FRR), a protection measure against link
faults, applies to the network topology with both primary and backup links. It can be configured
for services that are sensitive to packet loss and delay.
As networks evolve continuously, voice, on-line video, and financial services raise increasingly
high requirements for real-time performance. Usually, primary and backup links are deployed
on a network to ensure the stability of these services.

In a traditional forwarding mode, the router selects an optimal route out of several routes destined
for the same network and delivers the optimal route to the FIB table for data forwarding. If the
optimal route fails, the router can reselect an optimal route only after routes are converged.
During this period, services are interrupted. After the router delivers the reselected optimal route
to the FIB table, services are restored. Service interruption in this mode lasts a long time, which
cannot meet service requirements.
After BGP Auto FRR is enabled on the router, the router selects an optimal route from the routes
destined for the same network. In addition, the router automatically adds information about the
second optimal route to the backup forwarding entries of the optimal route and delivers the
backup forwarding entries to the FIB table. If the primary link fails, the router switches traffic
to the backup link immediately. The switchover completes within sub-seconds because it does
not depend on route convergence.
Before configuring BGP Auto FRR, configure basic BGP Functions.
Data Preparation
To configure BGP Auto FRR, you need the following data.
No. Data
1 IP address family for which BGP Auto FRR needs to be configured
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
The BGP IPv4 unicast address family view is displayed.
Step 4 Run:
auto-frr
BGP Auto FRR for unicast routes is enabled.
By default, BGP Auto FRR is disabled for unicast routes.

NOTE
On a network with both primary and backup links, the router may also use IP FRR for link protection. BGP
Auto FRR takes effect on a BGP route only when the route fails to match the routing policy specified in
the ip frr command run in the system view because IP FRR takes precedence over BGP Auto FRR.
Step 5 (Optional) Prevent path-switchover-triggered packet loss.
In a BGP Auto FRR scenario, if the device on which FRR is configured completes refreshing
forwarding entries before the intermediate device on the primary path does after the primary
path recovers, traffic may be lost after it switches back to the primary path. The severity of packet
loss is proportional to the number of routes stored on the intermediate device. To solve this
problem, perform any of the following operations to prevent path-switchover-triggered packet
loss:
l In the BGP view of the intermediate device on the primary path, run:
out-delay delay-value
A delay for sending Update packets to all BGP peers is configured. An appropriate delay
ensures that traffic switches back to the primary path after the intermediate device on the
primary path completes refreshing forwarding entries.
The delay-value value is an integer ranging from 0 to 3600, in seconds. The default delay-
value value is 0, indicating that the intermediate device on the primary path sends Update
packets without a delay. The delay-value value is inversely proportional to the route
convergence performance of the device on which FRR is configured.
l In the BGP view or BGP-IPv4 unicast address family view of the intermediate device on the
primary path, run:
peer { group-name | ipv4-address } out-delay delay-value
A delay for sending Update packets is configured. An appropriate delay ensures that traffic
switches back to the primary path after the intermediate device on the primary path completes
refreshing forwarding entries.
l In the BGP view or BGP-IPv4 unicast address family view of the device on which FRR is
configured, run:
route-select delay delay-value
A delay for selecting a route to the intermediate device on the primary path is configured.
An appropriate delay ensures that traffic switches back to the primary path after the
intermediate device completes refreshing forwarding entries.
value value is 0, indicating that the device on which FRR is configured selects a route to the
intermediate device on the primary path without a delay.
----End

After configuring BGP Auto FRR, you can run the following commands to check the
configurations.


prefixes ] ] ] command to check information in a BGP routing table.
l Run the display ip routing-table [ ip-address [ mask | mask-length ] [ longer-match ] ]
verbose command to check backup forwarding entries in an IP routing table.
# Run the display bgp routing-table ip-address mask-length longer-prefixes command. The
command output shows that there are two next hops destined for 4.4.4.4/32. The route with next
hop 10.1.1.2 has a smaller MED value and therefore becomes the optimal route.
<HUAWEI> display bgp routing-table 4.4.4.4 32 longer-prefixes

*> 4.4.4.4/32 10.1.1.2 80 0 200i

* 4.4.4.4/32 10.2.1.2 120 0 200i
# Run the display ip routing-table ip-address mask-length verbose command. The command
output shows that there are two next hops destined for 4.4.4.4/32 and that 10.2.1.2 is the backup
next hop.
<HUAWEI> display ip routing-table 4.4.4.4 32 verbose
------------------------------------------------------------------------------
Summary Count : 1
Protocol: EBGP Process ID: 0
IndirectID: 0x2
RelayNextHop: 0.0.0.0 Interface: Pos1/0/0
BkNextHop: 10.2.1.2 BkInterface: Pos1/0/1
BkIndirectID: 0x1
8.22 Configuring BGP GR

BGP GR can be configured to avoid traffic interruption due to protocol restart.

Before configuring BGP GR, familiarize yourself with the usage scenario, complete the pre-
BGP restart causes peer relationship reestablishment and traffic interruption. After GR is
enabled, traffic interruption can be prevented in the event of BGP restart.

The following roles are involved in BGP GR:

l GR restarter: is a device that is restarted by the administrator or in the case of a failure. The
GR restarter must be a GR-capable device.
l GR helper: is a neighbor of the GR restarter. The GR helper must also have the GR
capability.
Before configuring BGP GR, complete the following task:
Data Preparation
To configure BGP GR, you need the following data.
No. Data
1 BGP AS number
2 Maximum period of time for reestablishing a BGP session
3 Period of time for waiting for End-Of-RIB messages
8.22.2 Enabling BGP GR

Enabling or disabling BGP GR may delete and re-establish all BGP sessions and instances.
Context
A GR-capable device can establish GR sessions with a GR-capable neighbor. By controlling the
session negotiation mechanism of BGP, the GR restarter and the GR helper can understand each
other's GR capability. When detecting the restart of the GR restarter, the GR helper does not
delete the routing and forwarding entries related to the GR restarter, but waits to re-establish a
BGP connection with the GR restarter. After establishing a new BGP connection, the GR
restarter and the GR helper update BGP routes.
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 peer-reset
The router is enabled to reset a BGP session in GR mode.
Currently, BGP does not support dynamic capability negotiation. Therefore, each time a new
BGP capability is enabled on a router, the BGP speaker tears down existing sessions with its
peer and renegotiates BGP capabilities. This process will interrupt ongoing services. To prevent
the service interruptions, run the graceful-restart peer-reset command to enable the router to
reset a BGP session in GR mode. Then, the router will not delete routing entries for existing
sessions when a new BGP capability is enabled.
----End
8.22.3 Configuring Parameters for a BGP GR Session

BGP GR session parameter values can be adjusted as needed, but default values are
recommended. Changing the BGP restart period reestablishes BGP peer relationships.
Context
GR time is the period of time during which the GR helper retains the forwarding information
after having found the GR restarter Down. If the GR helper finds that the GR restarter goes
Down, the GR helper keeps the topology information or routes learned from the GR restarter
till the GR time expires.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
graceful-restart timer restart time
The maximum period of time used for reestablishing a BGP session is set.
The restart period of the router is the maximum waiting period from the time when the GR helper
discovers that the GR restarter restarts to the time when the BGP session is reestablished. By
default, the restart period is 150 seconds.
NOTE
Changing the BGP restart period reestablishes BGP peer relationships.
Step 4 Run:
graceful-restart timer wait-for-rib time

The length of time the GR restarter and GR helper wait for End-of-RIB messages is set.
By default, the time for waiting for End-Of-RIB messages is 600s.
NOTE
You can adjust BGP GR session parameter values as needed, but default values are recommended.
----End

After BGP GR is configured, you can view the BGP GR status.
Prerequisites
The BGP GR configurations have been configured.
Procedure
l Run the display bgp peer verbose command to check the BGP GR status.
----End
Example
# Run the display bgp peer ipv4-address verbose command to view the BGP GR status. For
example:
Type: IBGP link
Update-group ID: 1
BGP current event: RecvUpdate
Graceful Restart Capability: advertised and received
Restart Timer Value received from Peer: 150 seconds
Address families preserved for peer in GR:
IPv4 Unicast (was preserved)
Update messages 1
Open messages 1
Refresh messages 0
Update messages 2
Open messages 2

Refresh messages 0
8.23 Configuring BGP Security

Authentication can be implemented during the establishment of a TCP connection to enhance
BGP security.

Before configuring BGP security, familiarize yourself with the usage scenario, complete the pre-
Message digest 5 (MD5) authentication, keychain authentication, or Generalized TTL Security
Mechanism (GTSM) can be configured on a BGP network to enhance BGP security.
NOTE
By default, authentication is not configured for BGP. Configuring authentication is recommended to ensure
system security.
l MD5 authentication
BGP uses TCP as the transport 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. Most parameters in a packet can be easily obtained by attackers. To
protect BGP against attacks, MD5 authentication can be used during TCP connection
establishment between BGP peers to reduce the possibility of attacks.
To prevent the MD5 password set on a BGP peer from being decrypted, you need to update
the MD5 password periodically.
l Keychain authentication
A keychain consists of multiple authentication keys, each of which contains an ID and a
password. Each key has a lifecycle. Based on the life cycle of a key, you can dynamically
select different authentication keys from the keychain. After keychains with the same rules
are configured on the two ends of a BGP connection, the keychains can dynamically select
authentication keys to enhance BGP attack defense.
l BGP GTSM
The Generalized TTL Security Mechanism (GTSM) is used to prevent attacks by using the
TTL detection. If an attack simulates BGP packets and sends a large number of packets to
a router, an interface through which the router receives the packets directly sends the

packets to BGP of the control layer, without checking the validity of the packets. In this
manner, routers on the control layer process the packets as valid packets. As a result, the
system becomes busy, and Central Processing Unit (CPU) usage is high.
In this case, you can configure GTSM to solve the preceding problem. After GTSM is
configured on a router, the router checks whether the TTL value in the IP header of a packet
is in the pre-defined range after receiving the packet. If yes, the router forwards the packet;
if not, the router discards the packet. This enhances the security of the system.
NOTE
l The NE80E/40E supports BGP GTSM.

l GTSM supports only unicast addresses; therefore, GTSM needs to be configured on all the
routers configured with routing protocols.
Before configuring BGP security, complete the following task:
Data Preparation
To configure BGP security, you need the following data.
No. Data
1 Each router's peer address or peer group name
2 MD5 authentication password
3 Keychain authentication name
8.23.2 Configuring MD5 Authentication

In BGP, MD5 authentication sets an MD5 authentication password for a TCP connection, and
is performed by TCP. If authentication fails, no TCP connection will be established.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
peer { ipv4-address | group-name } password { cipher cipher-password | simple
simple-password }
An MD5 authentication password is set.

An MD5 authentication password can be set either in cipher or plain text.

l cipher cipher-password indicates that a password is recorded in cipher text. This means that
a password is encrypted using a special algorithm and then recorded in a configuration file.
l simple simple-password indicates that a password is recorded in plain text. This means that
a password is directly recorded in a configuration file.
NOTE
When configuring an authentication password, select the ciphertext mode because the password is saved
in configuration files in plaintext if you select simple mode, which has a high risk. To ensure device security,
change the password periodically.
The peer password command run in the BGP view is also applicable to the BGP-VPNv4 address family
view, because both BGP and BGP-VPNv4 use the same TCP connection.
----End
8.23.3 Configuring Keychain Authentication

Keychain authentication needs to be configured on two devices that establish a BGP peer
relationship. The encryption algorithms and passwords for keychain authentication on both peers
must be the same. This allows the peers to establish a TCP connection to exchange BGP packets.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { ipv4-address | group-name } keychain keychain-name
Keychain authentication is configured.
Keychain authentication needs to be configured on two devices that establish a BGP peer
relationship. The encryption algorithms and passwords for keychain authentication on both peers
must be the same. This allows the peers to establish a TCP connection to exchange BGP packets.
Before configuring BGP keychain authentication, ensure that the keychain specified by
keychain-name has been configured. Otherwise, no TCP connection can be set up between two
BGP peers.
NOTE
l The peer keychain command run in the BGP view is also applicable to the BGP-VPNv4 address family
view, because both BGP and BGP-VPNv4 use the same TCP connection.
l BGP MD5 authentication and BGP keychain authentication are mutually exclusive.
----End

8.23.4 Configuring BGP GTSM

The Generalized TTL Security Mechanism (GTSM) function protects devices by checking
whether the TTL value in the IP header is within a pre-defined range.
Procedure
l Adjust GTSM.
Perform the following steps on two devices that establish a BGP peer relationship:
1. Run:
system-view

2. Run:

3. Run:
peer { group-name | ipv4-address } valid-ttl-hops [ hops ]
BGP GTSM is configured.
The valid TTL range of a checked packet is [255 - hops + 1, 255]. For example, the
hops value is 1 for an EBGP direct route. This means that the valid TTL of the EBGP
direct routes is 255. By default, the hops value is 255. This means that the valid TTL
range is [ 1, 255 ].
NOTE
l The configuration in the BGP view is also valid for the VPNv4 extension of MP-BGP. This
is because they use the same TCP connection.
l GSTM is exclusive with EBGP-MAX-HOP; therefore, you can enable only one of them
on the same peer or the peer group.
An interface board of a BGP device enabled with GTSM checks the TTL values in all
received BGP packets. In actual networking, packets with the TTL values out of a
specified range are either allowed to pass or discarded by GTSM. When the default
action of GTSM is drop, an appropriate TTL value range needs to be set based on the
network topology. Packets with the TTL values out of the range will be discarded.
This prevents bogus BGP packets from consuming CPU resources.
l Set the GTSM default action.
Perform the following steps on a GTSM-enabled router:
1. Run:
system-view

2. Run:
The default action to be taken on the packets that do not match a GTSM policy is
Drop.

By default, the action to be taken on the packets that do not match the GTSM policy
is pass
NOTE
If the default action is configured but no GTSM policy is configured, GTSM does not take
effect.
----End

After configuring BGP security, you can view authentication information about BGP peers.
Prerequisites
The BGP security configurations have been configured.
Procedure
about MD5 and keychain authentication on BGP peers.
l Run the display bgp peer verbose command to check whether the GTSM function is
enabled on BGP peers and check the configured maximum valid TTL value.
l Run the display gtsm statistics { slot-id | all } command to check GTSM statistics on a
specified board or all boards, including the total number of packets, the number of passed
packets, and the number of dropped packets.
----End
Example
# Run the display bgp peer ipv4-address verbose command to view detailed information about
MD5 authentication on BGP peers. For example:

Type: EBGP link
Update-group ID: 2
Update messages 1
Open messages 1

Refresh messages 0
Update messages 1
Open messages 1
Refresh messages 0
Authentication type configured: MD5
# Run the display bgp peer ipv4-address verbose command to view detailed information about
keychain authentication on BGP peers. For example:
Type: EBGP link
Update-group ID: 1
BGP current state: Idle
BGP current event: Stop
BGP last state: Active
Update messages 1
Open messages 1
Refresh messages 0
Update messages 1
Open messages 1
Refresh messages 0
Authentication type configured: Keychain(key)
# Run the display bgp peer ipv4-address verbose command to view whether the GTSM function
is enabled on BGP peers and view the configured maximum number of valid hops. For example:

Type: EBGP link

Update-group ID: 2
Update messages 1
Open messages 1
Refresh messages 0
Update messages 1
Open messages 1
Refresh messages 0
GTSM has been enabled, valid-ttl-hops: 210
# Run the display gtsm statistics all command to view GTSM statistics on all boards, including
the total number of packets, the number of passed packets, and the number of dropped packets.
For example:
----------------------------------------------------------------
----------------------------------------------------------------
0 BGP 0 0 0
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
1 BGP 0 0 0
1 BGPv6 0 0 0
1 OSPF 0 0 0
1 LDP 0 0 0
1 OSPFv3 0 0 0
1 RIP 0 0 0
----------------------------------------------------------------

8.24 Disabling the BGP-IPv4 Unicast Address Family

If you do not need to use BGP to transmit public IPv4 unicast routes, you can disable the BGP-
IPv4 unicast address family to reduce the consumption of system resources.
By default, peers in the BGP-IPv4 unicast address family are automatically enabled. After you
configure the peer as-number command in the BGP view, the peer enable command is
automatically configured in the BGP-IPv4 unicast address family view. Peers in other address
family views must be manually enabled.
When you do not need to use BGP to transmit public IPv4 unicast routes, disable the BGP-IPv4
unicast address family. For example, in an IP RAN scenario, BGP is used only to transmit VPNv4
routes rather than public IPv4 unicast routes between superstratum Provider Edges (SPEs) and
underlayer Provider Edges (UPEs). To reduce the consumption of system resources, you can
disable the BGP-IPv4 unicast address family. In addition, one SPE is connected to multiple UPEs
in most cases, and it is complex to disable the BGP-IPv4 unicast address family on all UPEs one
by one. To address this problem, disable the BGP-IPv4 unicast address family in the BGP view.
Pre-configuration Task
Before you disable the BGP-IPv4 unicast address family, configure link-layer protocol
parameters and IP addresses for interfaces to ensure that the link layer protocol of each interface
is Up.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo default ipv4-unicast
The BGP-IPv4 unicast address family is disabled.
NOTE
After you configure the undo default ipv4-unicast command:

l New peers are not enabled in the BGP-IPv4 unicast address family by default. The peers that have
already been specified are not affected.
l To enable the BGP-IPv4 unicast address family for a specified BGP peer, run the peer enable command
in the BGP view or the BGP-IPv4 unicast address family view.
----End


After you disable the BGP-IPv4 unicast address family, run the display current-
configuration configuration bgp | include default ipv4-unicast command to check the
configurations. For example:
# Display the BGP-IPv4 unicast address family configuration.
<HUAWEI> display current-configuration configuration bgp | include default ipv4-
unicast
undo default ipv4-unicast
8.25 Applying BGP AS_Path Regular Expressions

A regular expression is a string of characters that define a rule, against which other strings of
characters are matched. For example, you can define an As_Path regular expression for an
AS_Path Filter and match the AS_Path information carried in BGP routes against the expression
to filter the BGP routes.
AS_Path Components
An AS_Path consists of one or more AS_Path components. The components are expressed using
binary numbers, parentheses "( )", brackets "[ ]", braces "{ }", and spaces. The AS_Path
components are as follows:
l AS_Sequence: records in reverse order all the numbers of the ASs through which a route
passes from the local device to the destination.
l AS_Set: records without an order all the numbers of the ASs through which a route passes
from the local device to the destination. In most cases, AS_Set is used after route
summarization because BGP speakers do not know the actual sequence of ASs through
which the specific routes pass. During route selection, a router considers that AS_Set carries
only one AS number regardless of the actual number of ASs.
l AS_Confed_Sequence: records in reverse order all the numbers of the sub-ASs within a
BGP confederation through which a route passes from the local device to the destination.
l AS_Confed_Set: records without an order all the numbers of the sub-ASs within a BGP
confederation through which a route passes from the local device to the destination.
Figure 8-7 shows the complete format of an AS_Path in a BGP routing table.
Figure 8-7 Format of AS_Path in a BGP routing table

AS_Path: (65001 65003) [65002 65004] 100 200 300 {400 500}
AS_Confed_Sequence AS_Set
AS_Confed_Set AS_Sequence
AS_Path Regular Expressions

An AS_Path filter uses a regular expression to define matching rules. A regular expression
consists of the following parts:

l Metacharacter: defines matching rules.

l General character: defines matching objects.
Table 8-8 lists metacharacters supported by BGP AS_Path regular expressions.
Table 8-8 Metacharacters supported by BGP AS_Path regular expressions
Meta Description Example

chara
cter
. Matches AS_Paths with any .* matches any AS_Path or route.

single character except "\n", NOTE
including spaces. If you have configured a rule in deny mode for an AS_Path
filter, run the ip as-path-filter as-path-filter-name
permit .* command so that other routes will not be
discarded.
* Matches AS_Paths with 0 or See the preceding example.

more sequences of the
character before the asterisk
"*".
+ Matches AS_Paths with 1 or 65+ matches AS_Paths that begin with 6 and include
more sequences of the one 5 or consecutive 5s.
character before the plus "+". l AS_Path examples that 65+ matches: 65, 655,
6559, 65259, and 65529
l AS_Path examples that 65+ does not match: 56,
556, 5669, 55269, 56259, and 56259
| Matches any AS_Path with 100|65002|65003 matches 100, 65002, or 65003.

characters on either side of
the vertical bar "|".
^ Matches AS_Paths ^65 matches AS_Paths beginning with 65.

beginning with the characters l AS_Path examples that ^65 matches: 65, 651,
that follow the caret "^". 6501, and 65001
l AS_Path examples that ^65 does not match: 165,
1650, 6650, and 60065
$ Matches AS_Paths ending 65$ matches AS_Paths ending with 65.

with the characters before the l AS_Path examples that 65$ matches: 65, 165,
dollar sign "$". 1065, 10065, and 60065
l AS_Path examples that 65$ does not match: 651,
1650, 6650, 60650, and 65001
NOTE
^$ matches null strings of characters (null AS_Path) and
can be used to match the locally generated routes.


chara
cter
(xyz) Matches AS_Paths with the (123) matches 123.

characters in the parentheses (8|9|67) matches 8, 9, or 67.
as a whole. (xyz) is used with
the vertical bar "|" in most
cases.
[xyz] Matches AS_Paths with any [896] matches AS_Paths with 8, 9, or 6, such as 6,
character in the brackets "[ ]". 8, 9, 18, 89, 96, 109, 9986, 65001, 1.6, and 8.9.
[^xyz] Matches AS_Paths with any [^896] matches AS_Paths with any character except
character except those in the 8, 9, and 6.
brackets "[ ]". l AS_Path examples that [^896] matches: 3, 18,
109, 9867, 65001, 1.6, and 8.9.
l AS_Path examples that [^896] does not match:
6, 8, 9, 89, 96, 698, 986, 9986, and 66899.
[a-z] Matches AS_Paths with any [2-4] matches 2, 3, and 4, and [0-9] matches numbers
character within the range from 0 to 9.
specified in the brackets "[ ]". NOTE
The characters in the brackets "[ ]" can only be numbers
from 0 to 9. To match AS_Paths within the range from 735
to 907, use (73[5-9]|7[4-9][0-9]|8[0-9][0-9]|90[0-7]).
[^a-z] Matches AS_Paths without [^2-4] matches AS_Paths without 2, 3, or 4, and

any character within the [^0-9] matches AS_Paths without numbers from 0
range specified in the to 9.
brackets "[ ]".
_ Matches AS_Paths with a l ^65001_ matches AS_Paths that begin with

sign, such as a comma ",", left 65001 followed by a sign. Specifically, ^65001_
brace "{", right brace "}", left matches AS_Paths with 65001 as the leftmost
parenthesis "(", right AS number (the number of the last AS through
parenthesis ")", or space. The which a route passes) or the routes sent by peers
underscore "_" can be used at in AS 65001.
the beginning of a regular l _65001_ matches AS_Paths with 65001 or
expression with the same routes that pass through AS 65001.
function as the caret "^" or at
the end of a regular l _65001$ matches AS_Paths that end with a sign
expression with the same followed by 65001. Specifically, _65001$
function as the dollar sign matches AS_Paths with 65001 as the rightmost
"$". AS number (the number of the first AS through
which a route passes) or the routes that originate
in AS 65001.


chara
cter
\ Indicates an escape A backslash "\" is used to disable special functions

character. of signs in regular expressions, such as the left
parenthesis "(" and right parenthesis ")" in an
AS_Confed_Sequence, the left bracket "[" and right
bracket "]" in an AS_Confed_Set, and the left brace
"{" and right brace "}" in an AS_Set.
l $65002_ matches AS_Confed_Sequences that
begin with (65002 followed by a sign.
Specifically, \(65002_ matches AS_Confed_Se-
quences with 65002 as the leftmost AS number
(the number of the last AS through which a route
passes) or the routes sent by peers in AS 65002.
l \(.*_65003_.*$ matches AS_Confed_Sequen-
ces with 65003 or routes that pass through AS
65003.
l _65004\) matches AS_Confed_Sequences that
end with a sign followed by 65004). Specifically,
_65004\) matches AS_Confed_Sequences with
65004 as the rightmost AS number (the number
of the first AS through which a route passes) or
the routes that originate in AS 65004. _65004\)
and 65004\) have the same function.
Multiple rules (permit or deny) can be specified in a filter. The relationship between theses rules
is "OR", which means that if a route meets one of the matching rules, the route matches the
AS_Path filter. The following part demonstrates the functions of AS_Path filters in different
scenarios.
Common Application Scenario

In Figure 8-8, EBGP peer relationships are established between Router A and Router B, between
Router A and Router C, between Router B and Router C, between Router B and Router D,
between Router C and Router D, and between Router D and Router E.

Figure 8-8 Typical BGP networking

2.2.2.7/32
AS 65121 AS 65101 AS 300

Router B
Router A AS 65001 Router D Router E
AS 65011
Router C
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
2.2.2.8/32
Before an AS_Path filter is configured on Router A, the BGP routing table on Router A is as
follows:
[RouterA] display bgp routing-table


*> 1.1.1.9/32 0.0.0.0 0 0 i

*> 2.2.2.7/32 10.1.1.2 0 0 65001i
* 10.1.2.2 0 65011 65001i
*> 2.2.2.8/32 10.1.2.2 0 0 65011i
* 10.1.1.2 0 65001 65011i
*> 2.2.2.9/32 10.1.1.2 0 65001 65101i
* 10.1.2.2 0 65011 65101i
*> 3.3.3.9/32 10.1.1.2 0 65001 65101
300i
* 10.1.2.2 0 65011 65101
300i
Case 1: Configure an AS_Path filter named s1 and allow Router A to accept only routes that
originate in AS 300.
[RouterA] ip as-path-filter s1 permit _300
[RouterA] display bgp routing-table as-path-filter s1


*> 3.3.3.9/32 10.1.1.2 0 65001 65101

300i
* 10.1.2.2 0 65011 65101
300i
The preceding command output shows that the BGP routing table contains only routes that
Case 2: Configure an AS_Path filter named s2 and allow Router A to accept all routes except
those that originate in AS 300.
[RouterA] ip as-path-filter s2 deny _300
[RouterA] ip as-path-filter s2 permit .*


*> 1.1.1.9/32 0.0.0.0 0 0 i

*> 2.2.2.7/32 10.1.1.2 0 0 65001i
* 10.1.2.2 0 65011 65001i
*> 2.2.2.8/32 10.1.2.2 0 0 65011i
* 10.1.1.2 0 65001 65011i
*> 2.2.2.9/32 10.1.1.2 0 65001 65101i
* 10.1.2.2 0 65011 65101i
The preceding command output shows that the BGP routing table contains all routes except
Case 3: Configure an AS_Path filter named s3 and allow Router A to discard routes that pass
through AS 65101.
[RouterA] ip as-path-filter s3 deny _65101_


*> 1.1.1.9/32 0.0.0.0 0 0 i

*> 2.2.2.7/32 10.1.1.2 0 0 65001i
* 10.1.2.2 0 65011 65001i
*> 2.2.2.8/32 10.1.2.2 0 0 65011i
* 10.1.1.2 0 65001 65011i
those that pass through AS 65101.
through intermediate AS 65101.
[RouterA] ip as-path-filter s4 deny ._65101_.



*> 1.1.1.9/32 0.0.0.0 0 0 i

*> 2.2.2.7/32 10.1.1.2 0 0 65001i
* 10.1.2.2 0 65011 65001i
*> 2.2.2.8/32 10.1.2.2 0 0 65011i
* 10.1.1.2 0 65001 65011i
*> 2.2.2.9/32 10.1.1.2 0 65001 65101i
* 10.1.2.2 0 65011 65101i
those that pass through intermediate AS 65101.
Case 5: Configure an AS_Path filter named s5 and allow Router A to accept only locally
generated routes.
[RouterA] ip as-path-filter s5 permit ^$


*> 1.1.1.9/32 0.0.0.0 0 0 i
The preceding command output shows that the BGP routing table contains only locally generated
routes.
Case 6: Configure an AS_Path filter named s6 and allow Router A to accept routes that originate
in AS 300 and pass through AS 65001.
[RouterA] ip as-path-filter s6 permit _65001 .+ 300$


*> 3.3.3.9/32 10.1.1.2 0 65001 65101

300i
The preceding command output shows that the BGP routing table contains only one route that
originates in AS 300 and passes through AS 65001.

Route Summarization Scenario

In Figure 8-8, after the aggregate 2.2.2.0 27 as-set detail-suppressed command is run on
Router B and Router C, the BGP routing table on Router A is as follows:


*> 1.1.1.9/32 0.0.0.0 0 0 i

*> 2.2.2.0/27 10.1.1.2 0 65001 {65101}
i
* 10.1.2.2 0 65011 {65101}
i
*> 3.3.3.9/32 10.1.1.2 0 65001 65101
300i
* 10.1.2.2 0 65011 65101
300i
through AS 65011.
[RouterA] ip as-path-filter s7 deny 65011


*> 1.1.1.9/32 0.0.0.0 0 0 i

*> 2.2.2.0/27 10.1.1.2 0 65001 {65101}
i
*> 3.3.3.9/32 10.1.1.2 0 65001 65101
300i
those that pass through AS 65011.
Case 8: Configure an AS_Path filter named s8 and allow Router A to accept only the routes
carrying an AS_Sequence with 65011 and an AS_Set with 65101.
[RouterA] ip as-path-filter s8 permit .*65011.*\{.*65101.*\}



* 2.2.2.0/27 10.1.2.2 0 65011 {65101}

i
The preceding command output shows that the BGP routing table contains only one route
destined for 2.2.2.0/27 with 10.1.2.2 as the next hop.
Case 9: Configure an AS_Path filter named s9 and allow Router A to accept only the routes
carrying an AS_Sequence with 65011 and an AS_Set with 65101 and the routes carrying an
AS_Sequence with 300.
[RouterA] ip as-path-filter s9 permit .*65011.*\{.*65101.*\}
[RouterA] ip as-path-filter s9 permit 300


* 2.2.2.0/27 10.1.2.2 0 65011 {65101}

i
*> 3.3.3.9/32 10.1.1.2 0 65001 65101
300i
* 10.1.2.2 0 65011 65101
300i
The preceding command output shows that the BGP routing table contains only the routes
carrying an AS_Sequence with 65011 and an AS_Set with 65101 and the routes carrying an
AS_Sequence with 300. In this case, the ip as-path-filter s9 permit .*65011.*\{.*65101.*\} and
ip as-path-filters9 permit 300 commands can be replaced with the ip as-path-filter s9
permit .*65011.*\{.*65101.*\}|300 command.
[RouterA] ip as-path-filter s9 permit .*65011.*\{.*65101.*\}|300


* 2.2.2.0/27 10.1.2.2 0 65011 {65101}

i
*> 3.3.3.9/32 10.1.1.2 0 65001 65101
300i
* 10.1.2.2 0 65011 65101
300i
BGP Confederation Scenario

In Figure 8-9, EBGP peer relationships are established between Router A and Router B, between
Router A and Router C, between Router B and Router C, between Router B and Router D,
between Router C and Router D, and between Router D and Router E. AS 65001, AS 65011,
AS 65101, and AS 65121 form a BGP confederation with AS 200 as its ID.

Figure 8-9 Typical BGP Confederation networking
AS 200 2.2.2.7/32
AS 65121 AS 65101 AS 300

Router B
Router A AS 65001 Router D Router E
AS 65011
Router C
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
2.2.2.8/32
Before an AS_Path filter is configured on Router A, the BGP routing table on Router A is as
follows:


*> 1.1.1.9/32 0.0.0.0 0 0 i

*>i 2.2.2.7/32 10.1.1.2 0 100 0 (65001)i
* i 10.1.3.1 0 100 0 (65011 65001)
i
*>i 2.2.2.8/32 10.1.2.2 0 100 0 (65011)i
* i 10.1.3.2 0 100 0 (65001 65011)
i
*>i 2.2.2.9/32 10.1.4.2 0 100 0 (65001 65101)
i
* i 10.1.5.2 0 100 0 (65011 65101)
i
i 3.3.3.9/32 10.1.6.2 0 100 0 (65001 65101)
300i
i 10.1.6.2 0 100 0 (65011 65001
65101) 300i
Case 10: Configure an AS_Path filter named s10 and allow Router A to discard routes advertised
by peers in AS 65011.
[RouterA] ip as-path-filter s10 deny $65011_




*> 1.1.1.9/32 0.0.0.0 0 0 i

*>i 2.2.2.7/32 10.1.1.2 0 100 0 (65001)i
* i 2.2.2.8/32 10.1.3.2 0 100 0 (65001 65011)
i
*>i 2.2.2.9/32 10.1.4.2 0 100 0 (65001 65101)
i
i 3.3.3.9/32 10.1.6.2 0 100 0 (65001 65101)
300i
those advertised by peers in AS 65011.
Case 11: Configure an AS_Path filter named s11 and allow Router A to discard routes that
[RouterA] ip as-path-filter s11 deny _65101$


*> 1.1.1.9/32 0.0.0.0 0 0 i

*>i 2.2.2.7/32 10.1.1.2 0 100 0 (65001)i
* i 10.1.3.1 0 100 0 (65011 65001)
i
*>i 2.2.2.8/32 10.1.2.2 0 100 0 (65011)i
* i 10.1.3.2 0 100 0 (65001 65011)
i
Route Summarization Scenario Within a Confederation

In Figure 8-9, after the aggregate 2.2.2.0 27 as-set detail-suppressed command is run on
Router B, the BGP routing table on Router B is as follows:
[RouterB] display bgp routing-table


*>i 1.1.1.9/32 10.1.1.1 0 100 0 (65121)i

* i 10.1.2.1 0 100 0 (65011 65121)
i

*> 2.2.2.0/27 127.0.0.1 0 [65011 65101]

i
s> 2.2.2.7/32 0.0.0.0 0 0 i
s>i 2.2.2.8/32 10.1.3.2 0 100 0 (65011)i
* i 10.1.2.2 0 100 0 (65121 65011)
i
* i 10.1.5.1 0 100 0 (65101 65011)
i
s>i 2.2.2.9/32 10.1.4.2 0 100 0 (65101)i
* i 10.1.5.2 0 100 0 (65121 65011
65101)i
* i 10.1.5.2 0 100 0 (65011 65101)
i
*>i 3.3.3.9/32 10.1.6.2 0 100 0 (65101) 300i
Case 12: Configure an AS_Path filter named s12 and allow Router B to accept only routes
carrying an AS_Confed_Set with 65101.
[RouterB] ip as-path-filter s12 permit \[.*65101.*\]
[RouterB] display bgp routing-table as-path-filter s12


*> 2.2.2.0/27 127.0.0.1 0 [65011 65101]

i
The preceding command output shows that the BGP routing table contains only the route
carrying an AS_Confed_Set with 65101.
Case 13: Configure an AS_Path filter named s13 and allow Router B to accept only routes
carrying an AS_Confed_Set in which 65011 is the rightmost AS number.
[RouterB] ip as-path-filter s13 permit _65011\]
[RouterB] display bgp routing-table as-path-filter s13
The preceding command output shows that the BGP routing table contains no routes. Although
the route to 2.2.2.0/27 carries an AS_Confed_Set with 65011, 65011 is not the rightmost AS
number. As a result, this route is also discarded.
8.26 Maintaining BGP

Maintaining BGP involves resetting a BGP connection and clearing BGP statistics.
8.26.1 Configuring BGP to Record Peer Status Changes and Event

Information
After you configure the Border Gateway Protocol (BGP) to record peer status changes and event
information, BGP keeps logs when the peer status changes or an event occurs.

Context
If an error occurs on a BGP peer connection, BGP generates an error code and subcode. If the
error occurs on the local device, the local device changes its local state machine to disconnect
its BGP peer and sends a BGP Notification message to its BGP peer. After the BGP peer receives
the Notification message, the BGP peer records the error code and subcode carried in the message
and changes its state machine.
By default, BGP records peer status changes and event information in the system log files. The
record includes: BGP error codes and subcodes, BGP state machine changes, and whether BGP
Notification messages are sent. The system log files serve as a reference to locate network
connectivity faults.
If you do not want BGP to record peer status changes or event information, run the undo peer
log-change command. After you run the undo peer log-change command, BGP records only
the last peer status change in the log file. You can run the display bgp peer loginfo command
to view this log.
Procedure
Step 1 Run:
system-view
Step 2 Run:
bgp as-number
Step 3 Run:
ipv4-family unicast
Step 4 Run:
peer { ipv4-address | group-name } log-change
BGP is configured to record peer status changes and event information.
----End
8.26.2 Resetting BGP Connections

Resetting a BGP connection will interrupt the peer relationship. You can also reset BGP in GR
mode.

Context
NOTICE
The BGP peer relationship is interrupted after you reset BGP connections with the reset bgp
command. Exercise cautions when running this command.
To reset a BGP session in GR mode, run the reset bgp command with the graceful parameter
specified and run the graceful-restart peer-reset command. If the graceful parameter is not
specified in the reset bgp command or if the graceful-restart peer-reset command is not run,
the GR reset mode does not take effect, so that routing entries will be deleted for existing sessions,
interrupting services. The services will be restored after the BGP peer relationship is
reestablished.
When the BGP routing policy on the router that does not support Route-refresh changes, you
need to reset BGP connections to validate the configuration. To reset BGP connections, run the
following reset commands in the user view.
Procedure
l To validate the new configurations, run the reset bgp all [ graceful ] command in the user
view to reset all BGP connections.
l To validate the new configurations, run the reset bgp { as-number-plain | as-number-
dot } [ graceful ] command in the user view to reset the BGP connection between the
specified AS.
l To validate the new configurations, run the reset bgp ipv4-address [ graceful ] command
in the user view to reset the BGP connection between a specified peer.
l To validate the new configurations, run the reset bgp external [ graceful ] command in
the user view to reset all the EBGP connections.
l To validate the new configurations, run the reset bgp group group-name [ graceful ]
command in the user view to reset the BGP connection with the specified peer-groups.
l To validate the new configurations, run the reset bgp internal [ graceful ] command in
the user view to reset all IBGP connections.
----End
8.26.3 Clearing BGP Information

This section describes how to clear the statistics of BGP accounting, flapped routes, and
suppressed routes.
Context
NOTICE
BGP statistics cannot be restored after being cleared. Exercise caution when running this
command.

Procedure
l Run the reset bgp flap-info [ regexp as-path-regexp | as-path-filter | ipv4-address
[ mask | mask-length ] ] command in the user view to clear the statistics of flapped routes.
l Run the reset bgp dampening [ ipv4-address [ mask | mask-length ] ] command in the user
view to clear the dampened routes and advertise the suppressed routes.
l Run the reset bgp ipv4-address flap-info command in the user view to clear the statistics
of route flapping.
l Run the reset ip bgp-accounting inbound interface [ interface-type interface-number ]
command in the user view to clear the statistics of BGP accounting.
----End
8.27 BGP Route Selection Rules
8.27.1 Route Processing on the BGP router

This section describes the route processing on the BGP router.
Figure 8-10 shows the route processing on the BGP router. BGP routes can be imported from
other protocols or learned from BGP peers. Route summarization can be configured to reduce
the routing table size before routes are selected, advertised, and delivered to the IP routing table.
Figure 8-10 Route processing on the BGP router
1 2
Direct Routing 3 4 5 2
Static policy
IGP BGP
Route Route Export
routing BGP
summarization selection policy
table peers
2
BGP 入口
Import
peers 策略
policy
6
Routes learned from BGP peers
IP routing
table
Table 8-9 lists some key points for Figure 8-10.
Table 8-9 Key points for route processing
No. Remarks
1 BGP can import direct routes, static routes, user network routes, and IGP routes based
on the import-route (BGP) or network command configuration.

No. Remarks
2 BGP can use routing polices when importing routes from other protocols, receiving
routes from BGP peers, or advertising routes to BGP peers. Routing polices can be
used to filter routes or modify route attributes.
3 BGP supports automatic and manual summarization. Multiple routing policies can be
used during manual summarization.
4 BGP selects routes based on strict route selection rules, which is the key point to be
discussed in the following part.
5 BGP adds the optimal route to the BGP routing table and advertises it to BGP peers.
6 BGP adds the routes learned from peers and the optimal route in the BGP routing table
to the IP routing table for traffic forwarding.
8.27.2 BGP Route Selection Rules

When multiple routes are available to the same destination, BGP selects one optimal route based
on BGP route selection rules and adds it to the IP routing table for traffic forwarding.
Figure 8-11 shows how the optimal route is selected.

Figure 8-11 BGP route selection process

Multiple routes to the same No The route is
Is the next hop address reachable?
destination are available. ignored.
Yes
Are PrefVal values The route with the largest PrefVal

the same? No value is preferred.
Yes
Are Local_Pref values The route with the largest
the same? No Local_Pref value is preferred.
Yes
Are they generated Aggregate>Summary>Network
the same way? No >Import>Learned from peers
Yes
The route with the smallest AIGP is
Are AIGP values
preferred, and the route with AIGP is
the same? No preferred to the route without AIGP.
Yes
Are AS_Path lengths The route with the shortest AS_Path
the same? No length is preferred.
Yes
Are Origin types IGP > EGP > Incomplete
the same? No
Are MEDs The one with the smallest MED

Yes
Are peer types EBGP > IBGP
the same? No
Yes
Are IGP costs The one with the smallest IGP cost
Yes
Are Cluster_List lengths The route with the shortest

the same? No Cluster_List length is preferred.
Yes
Are router IDs The route with the smallest router ID
the same? No is preferred.
Yes
Are peer addresses The route with the smallest peer The optimal
the same? No address is preferred. route is selected.
BGP selects routes by comparing route attributes in a fixed order. When a route attribute is a
sufficient condition for determining the optimal route, BGP does not compare the other
attributes; If BGP fails to select the optimal route after comparing all route attributes, the route
that was first received is selected as the optimal route.Table 8-10 lists the abbreviated alias,
route selection rules, and remarks of each matching item. Table 8-10 shows that the route priority
is directly proportional to the PreVal or Local_Pref value and inversely proportional to the rest
of the attribute values or lengths. In addition, the first column can be summarized as a character
string (PPAAA OMTCC RA), which helps memorize the matching sequence.

Table 8-10 BGP route selection process
Abbr Matching Route Selection Rules Remarks

eviate Item
d
Alias
P PrefVal The route with the largest PrefVal is Huawei-specific and valid
PreVal value is preferred. only on the device where it is
The default value is 0. configured.
P Local_Pref The route with the largest To modify the default Local_Pref
Local_Pref value is value of BGP routes, run the default
preferred. local-preference command.
The default value is 100.
A Route type A > S > N > I > L, in -

NOTE which:
A is l A: indicates that
the
routes are
initia
l of summarized using the
the aggregate command.
chara l S: indicates that routes
cter
are summarized using
strin
g the summary
(AS automatic command.
NIL). l N: indicates that
routes are imported
using the network
command.
l I: indicates that routes
are imported using the
import-route
command.
l L: indicates that
routes are learned
from BGP peers.
A Accumulated The route with the -

Interior smallest AIGP value is
Gateway preferred.
Protocol The route with AIGP to
(AIGP) the route without AIGP is
preferred.
A AS_Path The route with the If the bestroute as-path-ignore

shortest AS_Path length command is configured, BGP does not
is preferred. compare the AS_Path attribute.
O Origin IGP > EGP > Incomplete -

Abbr Matching Route Selection Rules Remarks

eviate Item
d
Alias
M Multi Exit The route with the If the bestroute med-none-as-

Discriminator smallest MED value is maximum command is configured,
(MED) preferred. BGP considers the largest MED value
The default value is 0. (4294967295) as the MED of the route
that does not carry an MED.
For details about MED usage, see
MED.
T Peer type EBGP > IBGP -
C IGP cost The route with the If the bestroute igp-metric-ignore

smallest IGP cost is command is configured, BGP does not
preferred. compare the IGP cost.
C Cluster_List The route with the By default, Cluster_List takes

shortest Cluster_List precedence over Originator_ID during
length is preferred. BGP route selection. To enable
Originator_ID to take precedence over
Cluster_List during BGP route
selection, run the bestroute routerid-
prior-clusterlist command.
R Router ID The route with the If routes carry the Originator_ID, the
smallest router ID is originator ID is substituted for the
preferred. router ID during route selection. The
route with the smallest Originator_ID
is preferred.
A Peer IP The route learned from -

address the peer with the smallest
IP address is preferred.
Selection of the Routes for Load Balancing

After BGP load balancing is configured, the BGP routes that meet the following conditions are
used as equal-cost routes for load balancing:
l The routes have the same PrefVal value.

l The routes have the same Local_Pref value.
l All the routes are summarized or non-summarized routes.
l The routes have the same AIGP value.
l The routes have the same AS_Path length.
l The routes have the same origin type (IGP, EGP, or incomplete).
l The routes have the same MED value.

l All the routes are EBGP or IBGP routes. After the maximum load-balancing eibgp
command is run, BGP ignores this limitation when selecting the optimal VPN route.
l The costs of the IGP routes to which the BGP routes are iterated within an AS are the same.
After the maximum load-balancing eibgp command is run, BGP ignores this limitation
when selecting the optimal VPN route.
In addition, BGP labeled routes and non-labeled routes cannot load-balance traffic even if they
meet the preceding conditions.
VPN Route Selection Rules

BGP VPN routes are selected in the same way as BGP public routes except that VPN target-
based route crossing is implemented first on BGP VPN routes. For details about BGP VPN route
crossing, see "VPN Route Crossing" in NE80E/40E Feature Description - IP Routing - BGP.
8.27.3 BGP Routing Table

This section describes how to check route attributes.
Table 8-11 lists all the common route attributes that affect route selection and the commands
that are used to check them.
Table 8-11 Commands used to check route attributes

Route Command Used to Check the Route Attribute
Attribute
PrefVal display bgp routing-table [ network ]
Local_Pref display bgp routing-table [ network ]
Route type display bgp routing-table network
AIGP display bgp routing-table network
AS_Path display bgp routing-table [ network ]
Origin display bgp routing-table [ network ]
MED display bgp routing-table [ network ]
Peer type display bgp routing-table network
IGP cost l display bgp routing-table network

l display ip routing-table ip-address [ mask | mask-length ] [ verbose ],
in which ip-address is the next hop IP address of a BGP route
Cluster_List display bgp routing-table network
Originator_ID display bgp routing-table network
Router ID display bgp routing-table network
Peer IP display bgp routing-table network

address

The following example describes how to check BGP route attributes in the display bgp routing-
table command output.


*> 1.1.1.9/32 0.0.0.0 0 0 i

*>i 2.2.2.7/32 10.1.1.2 0 100 0 (65001)i
* i 10.1.3.1 0 100 0 (65011 65001)
i
*>i 2.2.2.8/32 10.1.2.2 0 100 0 (65011)i
* i 10.1.3.2 0 100 0 (65001 65011)
i
*>i 2.2.2.9/32 10.1.4.2 0 100 0 (65001 65101)
i
* i 10.1.5.2 0 100 0 (65011 65101)
i
i 3.3.3.9/32 10.1.6.2 0 100 0 (65001 65101)
300i
i 10.1.6.2 0 100 0 (65011 65001
65101) 300i
Table 8-12 Description of the display bgp routing-table command output
Item Description
BGP Local
router ID is
1.1.1.2 Router ID: 1.1.1.2, in the same format as an IPv4 address

Item Description
Route status code, displayed in front of each route entry:

l *: indicates a valid route with a reachable next hop address.
l >: indicates an optimal route selected by BGP.
l d: indicates a dampened route.
l h: indicates a History route.
l i: indicates a route learned from an IBGP peer.
l s: indicates a suppressed route. If specific routes for route summarization
are suppressed, s is displayed in front of each specific route.
l S: indicates a route in Stale status, and the route is being deleted. Such
routes may occur during a BGP GR process.
BGP dampening measures route stability using a penalty value. The greater
the penalty value, the less stable a route. Each time route flapping occurs (a
device receives a Withdraw or an Update packet), BGP adds a penalty value
to the route carried in the packet.
When the penalty value of a route exceeds the Suppress value, BGP
suppresses the route by replacing the > sign of the route with the d or h sign.
The route is ignored and its Update packets are not advertised to other BGP
peers until the penalty value of the route decreases to the Reuse value.
l If d is displayed in front of a route, the route is carried in an Update packet.
l If h is displayed in front of a route, the route is carried in a Withdraw
packet.
The penalty value is not increased after it reaches the suppression threshold.
The penalty value of a suppressed route reduces by half after a half-life period.
l When the penalty value of a route with the d sign decreases to the Reuse
value, the route becomes reusable, and BGP removes the d sign, adds the
route to the IP routing table, and advertises an Update packet carrying the
route to BGP peers.
l When the penalty value of a route with the h sign decreases to 0, BGP
Status codes deletes this route from the BGP routing table.
Route origin code, displayed in front of each route entry:

l IGP: indicates that routes are added to the BGP routing table using the
network (BGP) command.
l EGP: indicates that routes are learned through the EGP protocol.
l Incomplete: indicates that routes are added to the BGP routing table using
Origin the import-route (BGP) command.
Network Network address in the BGP routing table
NextHop Next hop address
MED MED value of a BGP route, similar to the cost of IGP routes
LocPrf Local_Pref

Item Description
PrefVal PrefVal
Path/Ogn AS_Path and Origin attributes
Information about Next_Hop, MED, Local_Pref, PrefVal, AS_Path, and Origin can be displayed
using the display bgp routing-table command. To check information about the route type,
AIGP, peer type, IGP cost, Cluster_List, router ID, and peer IP address, run the display bgp
routing-table network command.

From: 10.1.3.1 (192.168.2.3)
Relay IP Out-Interface: GigabitEthernet1/0/4
AS-path Nil, origin incomplete, MED 1234, localpref 100, pref-val 0, valid,
internal, best, select, active, pre 255, IGP cost 1, AIGP 1
Table 8-13 Description of the display bgp routing-table command output
Item Description
BGP local router Router ID of the local device, in the same format as an IPv4 address.
ID
Local AS number Local AS number.
Paths BGP route information.
BGP routing table Information about the BGP route 10.1.1.1/32:

entry information
of 10.1.1.1/32
From IP address of the device that advertised the route. In this example,
10.1.3.1 is the IP address of the interface used by the peer to establish
the BGP peer relationship (peer IP address), and 192.168.2.3 is the
router ID of the peer.
Route Duration Duration of a route.
Relay IP Nexthop IP address of the route to which the BGP route is iterated.
Relay IP Out- Outbound interface of the route to which the BGP route is iterated.
Interface
Original nexthop Original next hop IP address.

Item Description
Qos information QoS information.
AS-path AS_Path attribute. If Nil is displayed, the AS_Path attribute is null.
origin incomplete Origin attribute:

l IGP: indicates that routes are added to the BGP routing table using
the network (BGP) command.
l EGP: indicates that routes are learned through the EGP protocol.
l Incomplete: indicates that routes are imported using the import-
route (BGP) command.
MED MED value of a BGP route, similar to the cost of IGP routes.
localpref Local_Pref
pref-val PrefVal
valid Valid route with a reachable next hop address.
internal Type of the peer from which the route is learned.

l external: indicates that the route is learned from an EBGP peer.
l internal: indicates that the route is learned from an IBGP peer.
best Optimal route.
select Selected route to be delivered to the IP routing table.

NOTE
According to BGP selection rules, BGP selects only one optimal route, and this
route is marked with best. In load balancing or FRR scenarios, more than one
route needs to be added to the IP routing table, and each of the route is marked
with select. Therefore, the number of the route marked with best is 1, and the
number of the routes marked with select is the actual number of routes added to
the IP routing table.
active Active route.
pre 255 Protocol priority of the route: 255
IGP cost IGP cost.
AIGP AIGP
Not advertised to The route has not advertised to any peer yet.
any peer yet
The display bgp routing-table network [ { mask | mask-length } [ longer-prefixes ] ] command

output varies with the route generation mode and transmission mode, and not all BGP attributes
are necessarily displayed. In the preceding example, the route type is not displayed because the
route 12.13.14.15/32 is an IBGP route. If you run the display bgp routing-table network
[ { mask | mask-length } [ longer-prefixes ] ] command, the route type will be displayed. For
example:


Aggregated route.
Direct Out-interface: NULL0
AS-path {65001 10 100}, origin incomplete, pref-val 0, valid, local, best, select,
active, pre 255
Aggregator: AS 200, Aggregator ID 192.168.2.4, Atomic-aggregate
10.1.7.2
172.16.1.2
192.168.1.2
The route 10.0.0.0/8 was manually summarized using the aggregate command. Therefore,
Aggregated route is displayed in the command output. The route type varies as follows:
l If the route is automatically summarized using the summary automatic command,
Summary automatic route will be displayed.
l If the route is imported using the network command, Network route will be displayed.
l If the route is imported using the import-route command, Imported route will be
displayed.
In the following example, an RR and a cluster are configured. Therefore, the Cluster_List
attribute is displayed in the display bgp routing-table network [ { mask | mask-length } [ longer-
prefixes ] ] command output.

From: 10.1.4.1 (2.2.2.2)
Relay IP Out-Interface:
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255
Originator: 1.1.1.1
Cluster list: 0.0.0.1
8.27.4 Route Attributes
Next_Hop
BGP ignores routes with an unreachable next hop address during BGP route selection.
Unlike the Next_Hop attribute in an IGP, the Next_Hop attribute in BGP is not necessarily the
IP address of a neighboring device. In most cases, the Next_Hop attribute in BGP complies with
the following rules:

l When advertising a route to an EBGP peer, a BGP speaker sets the Next_Hop of the route
to the address of the local interface through which the BGP peer relationship is established.
l When advertising a locally generated route to an IBGP peer, a BGP speaker sets the
Next_Hop of the route to the address of the local interface through which the BGP peer
relationship is established.
l When advertising a route learned from an EBGP peer to an IBGP peer, the BGP speaker
does not modify the Next_Hop of the route.
Modifying the Next_Hop

In some scenarios, the Next_Hop needs to be modified. Table 8-14 describes whether the
Next_Hop needs to be modified in specific scenarios.
Table 8-14 Next_Hop processing
Objectives Command Usage Scenarios Remarks
To enable an peer { ipv4-address | By default, when an ASBR If BGP load

ASBR to group-name } next- forwards a route learned balancing has been
modify the hop-local from an EBGP peer to its configured using the
Next_Hops of IBGP peers, the ASBR maximum load-
the routes to be does not change the balancing number
advertised to Next_Hop of the route. command, the router
IBGP peers. Therefore, the Next_Hop modifies the
address of the route Next_Hop of each
remains the EBGP peer IP route to the local IP
address. After being address through
forwarded to the IBGP which the IBGP peer
peers, the route cannot relationship is
become active as the established before it
Next_Hop is unreachable. advertises the route
To address this issue, to IBGP peers,
configure the ASBR to regardless of whether
modify the Next_Hop of the peer next-hop-
the route to the local IP local command is
address before advertising configured. For
the route to IBGP peers. details, see 8.17
After being forwarded to Configuring BGP
the IBGP peers, the route Load Balancing.
can be active because the
Next_Hop is reachable (an
IGP is configured in the
AS).

To prevent a peer { ipv4-address | - By default, a device

device from group-name } next- modifies the
modifying the hop-invariable Next_Hops of the
Next_Hops of routes imported from
the routes an IGP to the local IP
imported from address before
an IGP before advertising the routes
advertising the to IBGP peers.
routes to IBGP
peers.
To prevent a peer { group-name | In an inter-AS VPN Option By default, a device

device from ipv4-address } next- C scenario where an RR is modifies the
modifying the hop-invariable used, the peer next-hop- Next_Hops of routes
Next_Hops of invariable command to the local IP
routes before needs to be run on the RR address before
advertising the to prevent the RR from advertising the routes
routes to modifying the Next_Hops to EBGP peers.
EBGP peers. of routes before In addition, a device
advertising the routes to does not modify the
EBGP peers. This ensures Next_Hops of non-
that the remote PE iterates labeled routes if the
routes to the LSP destined routes are learned
for the local PE during from EBGP peers
traffic transmission. and are to be
advertised to IBGP
peers; the device sets
its interface IP
address as the
Next_Hops of
labeled routes if the
routes are learned
from EBGP peers
and are to be
advertised to IBGP
peers.
To configure nexthop recursive- To enable a device to By default,

BGP lookup route-policy iterate only desired routes, Next_Hop iteration
Next_Hop route-policy-name configure Next_Hop based on a specified
iteration based iteration based on a route-policy is not
on a route- specified route-policy so configured.
policy. that only the routes that
match the route-policy are
iterated.

To enable a apply ip-address The Next_Hops of BGP If a route-policy has

device to next-hop{ ipv4- routes can be modified been specified in the
modify the address | peer- using a route-policy in the import-route or
Next_Hops of address } following situations: network command,
BGP routes l For IBGP peers, the the apply clause
using a route- route-policy can be an configured for the
policy. import or export policy. route-policy using
Even if the next hop the apply ip-address
address configured in next-hop command
the route-policy is does not take effect.
unreachable, the IBGP
peers still add the routes
whose next hop
addresses have been
changed to the address
configured in the route-
policy to the BGP
routing table. However,
the routes are invalid.
l For EBGP peers, the
route-policy can only
be an import policy in
most cases. If the route-
policy is configured as
an export policy, the
routes whose next hop
addresses have been
changed to the address
configured in the route-
policy are discarded by
the EBGP peers
because the next hop
address is unreachable.
When the EBGP peer
relationships are
established on physical
connections, the
Next_Hops of BGP
routes cannot be
modified.
Obtaining a Reachable Next Hop

During route selection, BGP first checks whether the next hop addresses of routes are reachable.
Routes carrying unreachable next hop addresses are invalid and are not selected. Table 8-15
shows how to obtain a reachable next hop IP address or tunnel.

Table 8-15 Unreachable next hop
Item Description Solutions
Unreachable next hop IP A next hop IP address is Common solutions are as

address obtained through route follows:
iteration, but no active routes l Configure static routes or
to the IP address are available an IGP.
in the IP routing table.
l Run the import-route
command.
l Run the network
command.
Alternatively, you can run the
peer next-hop-local
command to change the
Next_Hop to the local IP
address.
Unreachable next hop tunnel Routes fail to be iterated to Configure a tunnel policy or
tunnels. a tunnel selector to ensure
that the routes can be iterated
to tunnels.
A next hop tunnel is obtained Ensure that the tunnel is

through route iteration, but correctly configured and is
the tunnel is unavailable. Up.
The following example shows how to obtain a reachable next hop IP address. In Figure 8-12,
an IBGP peer relationship is established between Router A and Router B, and an EBGP peer
relationship is established between Router B and Router C. Router A imports the route 1.1.1.9/32,
and Router C imports the route 3.3.3.9/32.
Figure 8-12 Networking
1.1.1.9/32 3.3.3.9/32
10.1.1.1/30 10.1.2.1/30
10.1.1.2/30 10.1.2.2/30
Router A Router B Router C
AS 300 AS 65001
# Display the BGP routing table of Router A.




*> 1.1.1.9/32 0.0.0.0 0 0 i

i 3.3.3.9/32 10.1.2.1 0 100 0 65001i
The preceding command output shows that no asterisk (*) is in front of the route 3.3.3.9/32,
which indicates that the route is invalid.
# Display the IP routing table of Router A.

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

10.1.1.0/30 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
The preceding command output shows that the next hop IP address (10.1.2.1) of the route
3.3.3.9/32 is not in the IP routing table, which indicates that the route is not selected due to the
unreachable next hop IP address. The following solutions can address this issue:
l Configure a static route destined for 10.1.2.1/30 on Router A.
l Configure an IGP on Router B and Router C and configure BGP to import the route 10.1.2.1
on Router B. This solution is not applicable to this specific scenario because Router B and
Router C are located in different ASs.
l Run the import-route direct command on Router B. This solution is not optimal because
unnecessary routes may be imported.
l Run the network 10.1.2.0 30 command on Router B to advertise the route 10.1.2.0/30 to
Router A.
l Run the peer 10.1.1.1 next-hop-local command on Router B to configure Router B to
modify the Next_Hop of the route 3.3.3.9/32 before advertising the route to Router A.
In this example, the network 10.1.2.0 30 command is configured on Router B. After the
command is configured, check the BGP routing table of Router A.


*> 1.1.1.9/32 0.0.0.0 0 0 i

*>i 3.3.3.9/32 10.1.2.1 0 100 0 65001i
*>i 10.1.2.0/30 10.1.1.2 0 100 0 i

The preceding command output shows that both * and > are in front of the route 3.3.3.9/32,
which indicates that the route is valid and optimal.
PrefVal
BGP prefers the route with the largest PreVal value during BGP route selection.
PrefVal is Huawei-specific and valid only on the device where it is configured. The PreVal
attribute is set by customers. Therefore, BGP first compares the PreVal values during route
selection.
To configure a PreVal value for the routes learned from a peer or peer group, run the peer
{ group-name | ipv4-address } preferred-value value command.
If multiple routes are available to the same destination, the route with the largest PreVal value
is selected as the optimal route. By default, the PreVal of the routes learned from BGP peers is
0.
Table 8-16 lists two methods to modify the PreVal value.
Table 8-16 Methods to modify the PreVal value
Method Usage Scenario
Run the peer { group-name | ipv4-address } This method sets a PreVal value for the routes
preferred-value value command. learned from a peer or peer group.
Configure an import policy and run the apply This method sets different PreVal values for
preferred-value preferred-value command different routes learned from a peer or peer
to configure an apply clause for the policy. group.
NOTE
If both the methods are used, the method with the
import policy takes effect if routes match the
conditions specified in the peer preferred-value
command and the import policy.
The following example shows how the PreVal value is used during route selection. In Figure
8-13, both ISP1 and ISP2 advertise the routes 10.11.0.0/16 and 10.22.0.0/16 to AS 65001.

Figure 8-13 PreVal application networking
Internet
10.11.0.0/16
10.22.0.0/16
AS 100
10.1.1.1/30 10.1.4.1/30
ISP2
ISP1 EBGP IBGP AS 200
10.1.1.2/30 10.1.4.2/30
AS 300
10.1.2.2/30 10.1.3.2/30
EBGP EBGP
10.1.2.1/30 10.1.3.1/30
RouterA
Client Network
AS 65001
Scenario 1: When no PreVal value is configured on Router A, check the BGP routing table of
Router A.


*> 10.11.0.0/16 10.1.3.2 0 200?

* 10.1.2.2 0 300 100?
*> 10.22.0.0/16 10.1.3.2 0 200?
* 10.1.2.2 0 300 100?
The BGP routing table of Router A shows that Router A receives the routes 10.11.0.0/16 and
10.22.0.0/16 from ISP1 and ISP2. Check the information about the route 10.11.0.0/16 on
Router A.
[RouterA] display bgp routing-table 10.11.0.0


From: 10.1.3.2 (10.1.3.2)
Direct Out-interface: GigabitEthernet0/0/1
AS-path 200, origin incomplete, pref-val 0, valid, external, best, select, active,
pre 255
10.1.3.2
10.1.2.2
From: 10.1.2.2 (10.1.2.2)
AS-path 300 100, origin incomplete, pref-val 0, valid, external, pre 255, not
preferred for AS-Path
The preceding command output shows that the AS_Path of the route learned from ISP2 is shorter
than that of the route learned from ISP1. Therefore, the route learned from ISP2 is selected as
the optimal route. Table 8-17 shows the route attribute comparison of the routes 10.11.0.0/16
learned from ISP1 and ISP2.
Table 8-17 Route attribute comparison of the route learned from ISP1 and that learned from
ISP2
Route Attribute Route Learned Route Learned Comparison

from ISP1 from ISP2
PrefVal 0 0 The same.
Local_Pref - - The same.

NOTE
If a route does not
carry Local_Pref, the
default value 100
takes effect.
Route type Learned from a peer Learned from a peer The same.
AIGP - - The same.
AS_Path 300 100 200 The route learned

from ISP2 is selected
as the optimal route
because its AS_Path
is shorter than that of
the route learned
from ISP1.

Scenario 2: The administrator of AS 65001 requires that ISP1 be active and ISP2 be backup for
the traffic to 10.11.0.0/16 and 10.22.0.0/16.
To meet the preceding requirements, run the peer { group-name | ipv4-address } preferred-
value value command on Router A to increase the PrefVal values of the routes learned from
ISP1. This configuration ensures that the routes learned from ISP1 are selected as the optimal
routes. Detailed configurations are as follows:
bgp 65001
#
ipv4-family unicast
peer 10.1.2.2 preferred-value 120 //Set the PrefVal of the routes
learned from AS 300 to 120.
Run the display bgp routing-table [ ip-address ] command to check the configurations.


*> 10.11.0.0/16 10.1.2.2 120 300 100?

* 10.1.3.2 0 200?
*> 10.22.0.0/16 10.1.2.2 120 300 100?
* 10.1.3.2 0 200?
The preceding command output shows that Router A selects the routes learned from ISP1.
# Display detailed information about the route 10.11.0.0/16 or 10.22.0.0/16 on Router A. The
route 10.11.0.0/16 is used as an example.

From: 10.1.2.2 (10.1.2.2)
AS-path 300 100, origin incomplete, pref-val 120, valid, external, best, select,
active, pre 255
10.1.3.2
10.1.2.2
From: 10.1.3.2 (10.1.3.2)
AS-path 200, origin incomplete, pref-val 0, valid, external, pre 255, not
preferred for PreVal

The preceding command output shows that the PrefVal value of the route learned from ISP1 is
greater than that of the route learned from ISP2 and that the route learned from ISP1 is selected
as the optimal route.
Scenario 3: The expected configurations of the administrator of AS 65001 are as follows:
l For the traffic destined to 10.11.0.0/16, ISP1 is active and ISP2 is backup.
l For the traffic destined to 10.22.0.0/16, ISP2 is active and ISP1 is backup.
To meet the preceding requirements, ensure that Router A selects the route 10.11.0.0/16 learned
from ISP1 and the route 10.22.0.0/16 learned from ISP2. In this situation, the peer preferred-
value command can no longer be used because different PrefVal values are required for the
routes learned from the same ISP. To allow different PrefVal values for the routes learned from
the same ISP, configure import policies. Detailed configurations are as follows:
#
bgp 65001
#
ipv4-family unicast
peer 10.1.2.2 route-policy for_isp1_in import //Apply import policy named
for_isp1_in to the routes learned from 10.1.2.2 and use for_isp1_in to modify the
PrefVal value.
peer 10.1.3.2 route-policy for_isp2_in import //Apply import policy named
for_isp2_in to the routes learned from 10.1.3.2 and use for_isp2_in to modify the
PrefVal value.
#
route-policy for_isp1_in permit node 10 //Define the first node of
for_isp1_in and set the PrefVal value of the route 10.11.0.0/16 to 80.
if-match ip-prefix for_isp1
apply preferred-value 80
#
route-policy for_isp1_in permit node 20 //Define the second node of
for_isp1_in and allow for_isp1_in to permit all routes.
#
route-policy for_isp2_in permit node 10 //Define the first node of
for_isp2_in and set the PrefVal value of the route 10.22.0.0/16 to 120.
if-match ip-prefix for_isp2
apply preferred-value 120
#
route-policy for_isp2_in permit node 20 //Define the second node of
for_isp2_in and allow for_isp2_in to permit all routes.
#
ip ip-prefix for_isp1 index 10 permit 10.11.0.0 16 //Configure an IP prefix
list to match the route 10.11.0.0/16.
ip ip-prefix for_isp2 index 10 permit 10.22.0.0 16 //Configure an IP prefix
#



*> 10.11.0.0/16 10.1.2.2 80 300 100?

* 10.1.3.2 0 200?
*> 10.22.0.0/16 10.1.3.2 120 200?
* 10.1.2.2 0 300 100?
The preceding command output shows that Router A selects the route 10.11.0.0/16 learned from
ISP1 and the route 10.22.0.0/16 learned from ISP2.
# Display detailed information about the route 10.22.0.0/16 on Router A.


From: 10.1.3.2 (10.1.3.2)
AS-path 200, origin incomplete, pref-val 120, valid, external, best, select,
active, pre 255
10.1.3.2
10.1.2.2
From: 10.1.2.2 (10.1.2.2)
AS-path 300 100, origin incomplete, pref-val 0, valid, external, pre 255, not
preferred for PreVal
The preceding command output shows that two routes 10.22.0.0/16 are available in the BGP
routing table of Router A and that the route with the next hop address 10.1.3.2 is selected because
its PrefVal (120) is greater than the PrefVal (0) of the route with next hop address 10.1.2.2. The
PrefVal value is sufficient enough to determine the optimal route, and therefore, Router A does
not compare other route attributes.
The preceding examples show that PrefVal values can be configured as required to control the
traffic forwarding path.
Local_Pref
BGP prefers the route with the highest Local_Pref during BGP route selection.
The Local_Pref attribute is used to determine the optimal route when traffic leaves an AS. The
Local_Pref attribute is available only to IBGP peers and is not advertised to other ASs.
Table 8-18 lists two methods to modify the Local_Pref value.
Table 8-18 Methods to modify the Local_Pref value
Run the default local-preference command. This method sets a default Local_Pref for the
routes that the local device advertises to IBGP
peers.

Configure an import or export policy and run This method sets different Local_Pref values
the apply local-preference command to for different routes that the local device
configure an apply clause for the policy. advertises to IBGP peers.
NOTE
If both the methods are used, the method with the
import policy takes effect if routes match the
conditions specified in the apply local-
preference command and the policy.
The following example shows how the Local_Pref value is used during route selection. In Figure
8-14, both ISP1 and ISP2 advertise the routes 10.11.0.0/16 and 10.22.0.0/16 to AS 65001.
Figure 8-14 Local_Pref application networking
Internet
10.11.0.0/16
10.22.0.0/16
ISP1 ISP2
AS 100 AS 200
10.1.1.1/30 10.1.2.1/30
EBGP EBGP
Client Network
AS 65001
10.1.1.2/30 10.1.2.2/30
10.1.3.1/30
RouterA RouterB
IBGP 10.1.3.2/30
10.1.4.1/30 10.1.5.1/30
IBGP IBGP
10.1.4.2/30 10.1.5.2/30
RouterC
Scenario 1: When no Local_Pref value is configured on Router A and Router B, check the BGP
routing tables of Router A and Router B.



*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i
*> 10.22.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i
The BGP routing table of Router A shows that Router A receives the routes 10.11.0.0/16 and
10.22.0.0/16 from ISP1 and Router B. Check the information about the route 10.11.0.0/16 on
Router A.

From: 10.1.1.1 (192.168.2.5)
AS-path 100 10, origin igp, pref-val 0, valid, external, best, select, active, pre
255
10.1.3.2
10.1.4.2
From: 10.1.3.2 (192.168.2.2)
AS-path 200 10, origin igp, localpref 100, pref-val 0, valid, internal, pre 255,
not preferred for peer type
The preceding command output shows that the route learned from ISP1 is selected as the optimal
route because it is an EBGP route and the route learned from Router B is an IBGP route. Table
8-19 shows the route attribute comparison of the routes 10.11.0.0/16 learned from ISP1 and
Router B.
Table 8-19 Route attribute comparison of the routes 10.11.0.0/16 learned from ISP1 and
Router B

from ISP1 from Router B


Local_Pref - 100 The same.

NOTE
If a route does not
default value 100
takes effect.
AIGP - - The same.
AS_Path 100 10 200 10 The same length.
Origin IGP IGP The same.
MED - - The same.
Peer type EBGP IBGP Route 10.11.0.0/16

learned from ISP1 is
optimal.
The route selection process on Router B is the same as that on Router A. Then, Router A and
Router B advertise the optimal routes to Router C. Check the routing table of Router C.

*>i 10.1.1.0/30 10.1.4.1 0 100 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.2.1 100 0 200 10i
* i 10.1.1.1 100 0 100 10i
*>i 10.22.0.0/16 10.1.2.1 100 0 200 10i
* i 10.1.1.1 100 0 100 10i
The preceding command output shows that Router C selects the routes advertised by Router B.
Check the reason why the routes learned from Router A are not selected on Router C. The route
10.11.0.0/16 is used as an example.
[RouterC] display bgp routing-table 10.11.0.0

From: 10.1.5.1 (192.168.2.2)


AS-path 200 10, origin igp, localpref 100, pref-val 0, valid, internal, best,
select, active, pre 255

From: 10.1.4.1 (192.168.2.3)
not preferred for router ID
The preceding command output shows that Router C selects the route 10.11.0.0/16 learned from
Router B because the router ID (192.168.2.2) of Router B is smaller than that (192.168.2.3) of
Router A. Table 8-20 shows the route attribute comparison of the routes 10.11.0.0/16 learned
from Router A and Router B.
Table 8-20 Route attribute comparison of the routes 10.11.0.0/16 learned from Router A and
Router B

from Router A from Router B
Local_Pref 100 100 The same.
AIGP - - The same.
AS_Path 100 10 200 10 The same length.
MED - - The same.
Peer type IBGP IBGP The same.
IGP cost - - The same.
Cluster_List - - The same length.
Router ID 192.168.2.3 192.168.2.2 Route 10.11.0.0/16

learned from Router
B is optimal.
Scenario 2: The administrator of AS 65001 requires that ISP1 be active and ISP2 be backup for
the traffic to 10.11.0.0/16 and 10.22.0.0/16.
To meet the preceding requirements, run the default local-preference command on Router A
to increase the Local_Pref values of the routes learned from Router A. This configuration ensures

that the routes learned from ISP1 are selected as the optimal routes. Detailed configurations are
as follows:
#
bgp 65001
#
ipv4-family unicast
default local-preference 120 //Set the Local_Pref of the routes
to be advertised to 120.
#



*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 0 100 10i
*> 10.22.0.0/16 10.1.1.1 0 100 10i
The preceding command output shows that Router A selects the routes learned from ISP1.
# Display the routing table of Router B.



*>i 10.1.1.0/30 10.1.3.1 0 120 0 i

*> 10.1.2.0/30 0.0.0.0 0 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
* 10.1.2.1 0 200 10i
*>i 10.22.0.0/16 10.1.1.1 120 0 100 10i
* 10.1.2.1 0 200 10i
The preceding command output shows that Router B selects the routes learned from Router A.
Router B does not advertise the routes learned from ISP2 to its IBGP peers because those routes
are not selected.
# Display detailed information about the route 10.11.0.0/16 or 10.22.0.0/16 on Router B. The
[RouterB] display bgp routing-table 10.11.0.0


From: 10.1.3.1 (192.168.2.3)

10.1.2.1
From: 10.1.2.1 (192.168.2.4)
AS-path 200 10, origin igp, pref-val 0, valid, external, pre 255, not preferred
for Local_Pref
The preceding command output shows that the Local_Pref value of the route learned from
Router A is greater than that of the route learned from ISP2 and that the route learned from
Router A is selected as the optimal route. Table 8-21 shows the route attribute comparison of
the routes 10.11.0.0/16 learned from Router A and ISP2.
Table 8-21 Route attribute comparison of the routes 10.11.0.0/16 learned from Router A and
ISP2

from Router A from ISP2
Local_Pref 120 - Route 10.11.0.0/16

learned from Router
A is optimal.
NOTE
If a route does not
default value 100
takes effect.
# Display the routing table of Router C.


*>i 10.1.1.0/30 10.1.4.1 0 120 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
*>i 10.22.0.0/16 10.1.1.1 120 0 100 10i

Router C selects the routes advertised by ISP1 because Router B did not advertise the routes
learned from ISP2 to Router C.
Scenario 3: The requirements of the administrator of AS 65001 are as follows:
l ISP1 is active and ISP2 is backup for the traffic to 10.11.0.0/16.

l ISP2 is active and ISP1 is backup for the traffic to 10.22.0.0/16.
To meet the preceding requirements, ensure that AS 65001 selects the route 10.11.0.0/16 learned
from Router A and the route 10.22.0.0/16 learned from Router B. Detailed configurations are
as follows:
Figure 8-15 Local_Pref-based BGP route selection networking (1)
Internet
10.11.0.0/16
10.22.0.0/16
ISP1 ISP2
AS 100 AS 200
Set Local_Pref: EBGP EBGP Set Local_Pref:

120 for 10.11.0.0/16 Client Network 200 for 10.22.0.0/16
80 for 10.22.0.0/16 AS 65001 60 for 10.11.0.0/16
To: 11.0.0.0/8
RouterA RouterB
To: 22.0.0.0/8
To: 11.0.0.0/8 IBGP To: 22.0.0.0/8
IBGP IBGP
RouterC
Best route
In this situation, different Local_Pref values are required for the routes learned from the same
ISP. To configure different Local_Pref values for the routes learned from the same ISP, configure
route-policies. Detailed configurations are as follows:
l Configurations on Router A
#
bgp 65001
#
ipv4-family unicast
peer 10.1.1.1 route-policy rp1 import //Apply import policy
named rp1 to the routes learned from 10.1.1.1 and use rp1 to modify the

Local_Pref.
#
route-policy rp1 permit node 10 //Define the first node
of rp1 and set the Local_Pref value of the route 10.11.0.0/16 to 80.
if-match ip-prefix reducepref
apply local-preference 80
#
route-policy rp1 permit node 20 //Define the second
node of rp1 and set the Local_Pref value of the route 10.22.0.0/16 to 120.
if-match ip-prefix addpref
#
route-policy rp1 permit node 30 //Define the third node
of rp1 and allow rp1 to permit all routes.
#
ip ip-prefix addpref index 10 permit 10.11.0.0 16 //Configure an IP
prefix list to match the route 10.11.0.0/16.
ip ip-prefix reducepref index 10 permit 10.22.0.0 16 //Configure an IP
#
l Configurations on Router B
bgp 65001
#
ipv4-family unicast
peer 10.1.2.1 route-policy rp2 import //Apply import policy
named rp2 to the routes learned from 10.1.1.1 and use rp2 to modify the
Local_Pref.
#
route-policy rp2 permit node 10 //Define the first node
of rp2 and set the Local_Pref value of the route 10.22.0.0/16 to 200.
if-match ip-prefix addpref
#
route-policy rp2 permit node 20 //Define the second
node of rp2 and set the Local_Pref value of the route 10.11.0.0/16 to 60.
if-match ip-prefix reducepref
#
route-policy rp2 permit node 30 //Define the third node
of rp2 and allow rp2 to permit all routes.
#
ip ip-prefix addpref index 10 permit 10.22.0.0 16 //Configure an IP
ip ip-prefix reducepref index 10 permit 10.11.0.0 16 //Configure an IP
#


*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 120 0 100 10i
*>i 10.22.0.0/16 10.1.2.1 200 0 200 10i
* 10.1.1.1 80 0 100 10i

# Display detailed information about the route 10.22.0.0/16 on Router A.


From: 10.1.3.2 (192.168.2.2)
10.1.1.1
From: 10.1.1.1 (192.168.2.5)
AS-path 100 10, origin igp, localpref 80, pref-val 0, valid, external, pre 255,
not preferred for Local_Pref
routing table of Router A and that the route with next hop address 10.1.2.1 is selected because
its Local_Pref (200) is greater than the Local_Pref (80) of the route with next hop address
10.1.1.1.
Table 8-22 shows the route attribute comparison of the routes 10.22.0.0/16 learned from ISP1
and Router B.
Table 8-22 Route attribute comparison of the routes 10.22.0.0/16 learned from ISP1 and
Router B.

Local_Pref 200 80 Route 10.22.0.0/16

learned from ISP1 is
optimal.
The route with next hop address 10.1.1.1 is not optimal, and therefore, it is not advertised to
Router B and Router C. In addition, the route 10.11.0.0/16 with next hop address 10.1.2.1 is not
optimal on Router B, and therefore, Router B does not advertise this route to Router A and
Router C. As a result, only one route 10.11.0.0/16 with next hop address 10.1.1.1 is available in
the BGP routing table of Router A.



*>i 10.1.1.0/30 10.1.3.1 0 100 0 i

*> 10.1.2.0/30 0.0.0.0 0 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
* 10.1.2.1 60 0 200 10i
*> 10.22.0.0/16 10.1.2.1 200 0 200 10i
# Display detailed information about the route 10.11.0.0/16 on Router B.


From: 10.1.3.1 (192.168.2.3)
10.1.2.1
From: 10.1.2.1 (192.168.2.4)
AS-path 200 10, origin igp, localpref 60, pref-val 0, valid, external, pre 255,
routing table of Router B and that the route with next hop address 10.1.1.1 is selected because
its Local_Pref (120) is greater than the Local_Pref (60) of the route with next hop address
10.1.2.1. The route with next hop address 10.1.2.1 is not advertised to Router A and Router C
because it is not optimal.


*>i 10.1.1.0/30 10.1.4.1 0 100 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
*>i 10.22.0.0/16 10.1.2.1 200 0 200 10i

The preceding command output shows that the next hop address of the route 10.11.0.0/16 is
10.1.1.1 and that the next hop address of the route 10.22.0.0/16 is 10.1.2.1.
l ISP1 is active and ISP2 is backup for the traffic from Router A and Router C to 10.11.0.0/16
and 10.22.0.0/16.
l ISP2 is active and ISP1 is backup for the traffic from Router B to 10.11.0.0/16 and
10.22.0.0/16.
To meet the preceding requirements, ensure that Router A and Router C select the routes learned
from ISP1. Detailed configurations are as follows:
Figure 8-16 Local_Pref-based BGP route selection networking (2)
Internet
10.11.0.0/16
10.22.0.0/16
ISP1 ISP2
AS 100 AS 200
To: To:
10.11.0.0/16 EBGP EBGP
10.11.0.0/16
10.22.0.0/16 10.22.0.0/16
Client Network
AS 65001
IBGP
RouterA RouterB
To:
11.0.0.0/8
22.0.0.0/8
IBGP IBGP
RouterC
Best route
You can perform either of the following operations:

l Configure an export policy on Router A to modify the Local_Pref of the routes to be
advertised to Router C.
l Configure an import policy on Router C to modify the Local_Pref of the routes learned
from Router A.
The configurations on Router A are used as an example. Detailed configurations are as follows:
bgp 65001
#

ipv4-family unicast
default local-preference 120 //Set the Local_Pref of the routes
to be advertised to 120.



*> 10.1.1.0/30 0.0.0.0 0 0 i

*>i 10.1.2.0/30 10.1.3.2 0 100 0 i
*> 10.11.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i
*> 10.22.0.0/16 10.1.1.1 0 100 10i
* i 10.1.2.1 100 0 200 10i
The preceding command output shows that Router B selects the routes learned from ISP1.



*>i 10.1.1.0/30 10.1.3.1 0 100 0 i

*> 10.1.2.0/30 0.0.0.0 0 0 i
*> 10.11.0.0/16 10.1.2.1 0 200 10i
* i 10.1.1.1 100 0 100 10i
*> 10.22.0.0/16 10.1.2.1 0 200 10i
* i 10.1.1.1 100 0 100 10i
The preceding command output shows that Router B selects the routes learned from ISP2.


*>i 10.1.1.0/30 10.1.4.1 0 120 0 i

*>i 10.1.2.0/30 10.1.5.1 0 100 0 i
*>i 10.11.0.0/16 10.1.1.1 120 0 100 10i
* i 10.1.2.1 100 0 200 10i

*>i 10.22.0.0/16 10.1.1.1 120 0 100 10i

* i 10.1.2.1 100 0 200 10i
The preceding command output shows that Router C selects the routes learned from ISP1.
# Display detailed information about the route 10.11.0.0/16 or 10.22.0.0/16 on Router C. The

From: 10.1.4.1 (192.168.2.3)

From: 10.1.5.1 (192.168.2.2)
The preceding command output shows that Router C selects the routes learned from ISP1
because the Local_Pref of the routes learned from ISP1 is greater than that of the route learned
from ISP2.
The preceding examples show that the modification of the Local_Pref values affects not only
BGP route advertisement but also BGP route selection with an AS. We can configure Local_Pref
values as required to control the forwarding path of the traffic that leaves an AS.
Route Type
BGP prefers locally imported routes to the routes learned from peers during BGP route selection.
BGP routes can be locally imported or learned from peers. The locally imported routes take
precedence over the routes learned from peers during BGP route selection. It is unusual for
locally imported routes and the routes learned from peers to carry the same destination IP address
and coexist in the routing table. Generally, locally imported routes can be the routes imported
using the network or import-route command and the automatically and manually summarized
routes. Precedences of these routes are described as follows:
1. Summarized routes take precedence over non-summarized routes.

2. Summarized routes that are manually generated using the aggregate command take
precedence over summarized routes that are automatically generated based on the
summary automatic command settings.
3. The routes imported using the network command take precedence over the routes imported
using the import-route command.

In Figure 8-17, Router A and Router B are EBGP peers, and Router B, Router C, and Router D
are IBGP peers.
Figure 8-17 Networking
AS 100 AS 65001
Router A Router B Router D
10.1.1.1/30 10.1.1.2/30 10.1.3.1/30
IBGP 10.1.3.2/30
10.1.2.1/30 10.1.4.1/30
IBGP IBGP
Router C
10.1.2.2/30 10.1.4.2/30
The configurations on Router C are as follows:

#
bgp 65001
#
ipv4-family unicast
network 10.1.2.0 255.255.255.252 //Advertise the route
10.1.2.0/30.
10.1.3.0/30.
import-route direct //Import direct routes.
#
The configurations on Router D are as follows:

#
bgp 65001
#
ipv4-family unicast
10.1.3.0/30.
10.1.4.0/30.
#
# Display the routing table of Router D.




*>i 10.1.2.0/30 10.1.4.2 0 100 0 i

*> 10.1.3.0/30 0.0.0.0 0 0 i
* 0.0.0.0 0 0 ?
*> 10.1.3.2/32 0.0.0.0 0 0 ?
*> 10.1.4.0/30 0.0.0.0 0 0 i
* 0.0.0.0 0 0 ?
i 10.1.4.2 0 100 0 ?
*> 10.1.4.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 ?
The preceding command output shows that three routes 10.1.4.0/30 are available in the routing
table. The route with the next hop address 10.1.4.2 is learned from a peer (Router C). Therefore,
BGP first excludes this route from route selection.
[RouterD] display bgp routing-table 10.1.4.0 30

Network route.
From: 0.0.0.0 (0.0.0.0)
10.1.3.1
10.1.4.2
Imported route.
From: 0.0.0.0 (0.0.0.0)
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, pre 0, not
preferred for route type

From: 10.1.4.2 (10.1.2.2)
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, internal, pre
255
The preceding command output shows that the route imported using the network command is
selected as the optimal route.
The configurations on Router B are as follows:
bgp 65001
#
ipv4-family unicast
summary automatic
aggregate 10.0.0.0 255.0.0.0
import-route direct
#




*> 10.0.0.0 127.0.0.1 0 ?

* 127.0.0.1 0 ?
s> 10.1.1.0/30 0.0.0.0 0 0 ?
*> 10.1.1.2/32 0.0.0.0 0 0 ?
s> 10.1.2.0/30 0.0.0.0 0 0 ?
i 10.1.2.2 0 100 0 i
*> 10.1.2.1/32 0.0.0.0 0 0 ?
s> 10.1.3.0/30 0.0.0.0 0 0 ?
i 10.1.3.2 0 100 0 i
*> 10.1.3.1/32 0.0.0.0 0 0 ?
*>i 10.1.4.0/30 10.1.3.2 0 100 0 i
* i 10.1.2.2 0 100 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
The preceding command output shows that two summarized routes 10.0.0.0 are available in the
routing table.

Aggregated route.
AS-path Nil, origin incomplete, pref-val 0, valid, local, best, select, active,
pre 255
Aggregator: AS 65001, Aggregator ID 10.1.1.2
10.1.1.1
10.1.3.2
10.1.2.2
Summary automatic route
AS-path Nil, origin incomplete, pref-val 0, valid, local, pre 255, not preferred
for route type
Aggregator: AS 65001, Aggregator ID 10.1.1.2
The preceding command output shows that the route generated using the aggregate command
is selected as the optimal route.
AIGP
BGP prefers the route with the smallest AIGP value during BGP route selection.

The Accumulated Interior Gateway Protocol Metric (AIGP) attribute is an optional non-
transitive Border Gateway Protocol (BGP) path attribute. After the AIGP attribute is configured
in an AIGP administrative domain, BGP selects paths based on costs in the same manner as an
IGP, and all devices in the domain forward data along the optimal routes. During BGP route
selection, the AIGP attribute is used as follows:
l The priority of a route that carries the AIGP attribute is higher than the priority of a route
that does not carry the AIGP attribute.
l If two BGP routes both carry the AIGP attribute, the device selects the BGP route whose
AIGP value plus the cost of the IGP route to which the BGP route is iterated is smaller.
The AIGP attribute can be added to routes only through route-policies. You can configure an
apply clause for a route-policy using the apply aigp { cost | inherit-cost } command to modify
the AIGP value during BGP route import, acceptance, or advertisement. If no AIGP value is
configured, the IGP routes imported by BGP do not carry the AIGP attribute.
In Figure 8-18, OSPF runs in AS 65002, an EBGP peer relationship is established between
Router A and Router E and between Router B and Router E. Router A and Router B are
configured to import OSPF routes in AS 65002 and advertise the routes to AS 65001.
Figure 8-18 AIGP application networking
AS 65001
Router E
10.1.1.1/30 10.1.3.1/30
EBGP EBGP
10.1.1.2/30 10.1.3.2/30
Router A Router B
10.1.2.1/30 10.1.5.1/30
AS 65002
10.1.2.2/30 10.1.5.2/30
10.1.4.1/30
Router C 10.1.4.2/30 Router D
Run the display bgp routing-table [ ip-address ] command on Router E to check the
configurations. The route 10.1.4.0/30 is used in this example.

# Display the routing table of Router E.

[RouterE] display bgp routing-table


*> 10.1.2.0/30 10.1.1.2 0 0 65002?

* 10.1.3.2 3 0 65002?
*> 10.1.4.0/30 10.1.1.2 2 0 65002?
* 10.1.3.2 2 0 65002?
*> 10.1.5.0/30 10.1.3.2 0 0 65002?
* 10.1.1.2 3 0 65002?
[RouterE] display bgp routing-table 10.1.4.0

From: 10.1.1.2 (10.1.1.2)
AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, best,
10.1.1.2
10.1.3.2
From: 10.1.3.2 (10.1.5.1)
AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, pre 255, not
preferred for router ID
The command output shows that Router E selects the route learned from Router A because the
AIGP attribute has not been configured and the router ID of Router A is smaller than that of
Router B. To change the route selection on Router E, perform the following operations to
configure the AIGP attribute.
Configurations on Router A:
#
bgp 65002
#
ipv4-family unicast
import-route ospf 1 route-policy aigp_policy //Apply route-policy named
aigp_policy to locally imported OSPF routes and use aigp_policy to modify the AIGP
value.
peer 10.1.1.1 aigp //Enable AIGP on the local
device and the peer 10.1.1.1.
#
route-policy aigp_policy permit node 10 //Define the first node of
aigp_policy and set the AIGP value of the route 10.1.4.0/30 to 10.
apply aigp 10
#

route-policy aigp_policy permit node 20 //Define the second node of

aigp_policy and allow aigp_policy to permit all routes.
#
ip ip-prefix prefix1 index 10 permit 10.1.4.0 30 //Configure IP prefix list
named prefix1 to match the route 10.1.4.0/30.
#
Configurations on Router B:
bgp 65002
#
ipv4-family unicast
import-route ospf 1 route-policy aigp_policy1 //Apply route-policy named
aigp_policy1 to locally imported OSPF routes and use aigp_policy1 to modify the
AIGP value.
#
route-policy aigp_policy1 permit node 10 //Define the first node of
aigp_policy1 and set the AIGP value of the route 10.1.4.0/30 to 5.
apply aigp 5
#
route-policy aigp_policy1 permit node 20 //Define the second node of
aigp_policy1 and allow aigp_policy1 to permit all routes.
#
ip ip-prefix prefix2 index 10 permit 10.1.4.0 30 //Configure IP prefix list
named prefix2 to match the route 10.1.4.0/30.
#
Configurations on Router E:
#
bgp 65001
#
ipv4-family unicast
#
Run the display bgp routing-table [ ip-address ] command on Router E to check the
configurations.
# Display the routing table of Router E.
[RouterE] display bgp routing-table


*> 10.1.2.0/30 10.1.1.2 0 0 65002?

* 10.1.3.2 3 0 65002?
*> 10.1.4.0/30 10.1.3.2 2 0 65002?
* 10.1.1.2 2 0 65002?
*> 10.1.5.0/30 10.1.3.2 0 0 65002?
* 10.1.1.2 3 0 65002?
[RouterE] display bgp routing-table 10.1.4.0


From: 10.1.3.2 (10.1.5.1)
AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, best,
select, active, pre 255, AIGP 5
10.1.1.2
10.1.3.2
From: 10.1.1.2 (10.1.1.2)
AS-path 65002, origin incomplete, MED 2, pref-val 0, valid, external, pre 255,
AIGP 10, not preferred for AIGP
The preceding command output shows that Router E selects the route 10.1.4.0/30 learned from
Router B because its AIGP value is smaller than that of the route learned from Router A.
Table 8-23 shows the attribute comparison of the routes 10.1.4.0/30 learned from Router A and
Router B.
Table 8-23 Attribute comparison of the routes 10.1.4.0/30 learned from Router A and Router
B.

AIGP 10 5 The same.
AS_Path
BGP prefers the route with the shortest AS_Path length (the number of included ASs) during
BGP route selection.
Four types of AS_Path attributes are available:
l AS_Sequence: records in reverse order all the ASs through which a route passes from the
local device to the destination.
l AS_Set: records in random order all the ASs through which a route passes from the local
device to the destination. The AS_Set attribute is used in route summarization scenarios.
l AS_Confed_Sequence: records in reverse order all the sub-ASs within a BGP confederation
through which a route passes from the local device to the destination.

l AS_Confed_Set: records in random order all the sub-ASs within a BGP confederation
through which a route passes from the local device to the destination.
Table 8-24 describes the AS_Path-based route selection rules.
Table 8-24 AS_Path-based route selection rules
Item Description
AS_Set BGP takes an AS_Set as one AS number even if the AS_Set

contains multiple AS numbers.
When the aggregate (BGP) command is configured to
generate a manually summarized route, if as-set is specified
in the command, AS_Set will be carried in the summarized
route. The information in the AS_Set is as follows:
l If the routes used in the summarization carry the same
AS_Sequence, this AS_Sequence is carried in the
summarized route, and the AS_Set of the summarized
route is null.
l If the routes used in the summarization carry different
AS_Sequences, all the AS numbers carried in the
AS_Sequences are included in the AS_Set of the
summarized route.
AS_Confed_Sequence and BGP ignores AS_Confed_Sequence and AS_Confed_Set

AS_Confed_Set when calculating the AS_Path length.
bestroute as-path-ignore After the command is configured, BGP does not compare
the AS_Path attribute during route selection.
apply as-path The command can be run to configure an apply clause for a
route-policy so that the ASs in the AS_Path of the route that
matches the route-policy are cleared or replaced, or new ASs
are added.
NOTE
The configuration of the apply as-path command may change the
traffic forwarding path, or cause routing loops or route selection
errors. Therefore, exercise caution when configuring the command.
peer public-as-only After the command is configured, BGP deletes private AS

numbers (if any) from the AS_Path attribute before sending
Update packets. Private AS numbers range from 64512 to
65534.

Item Description
peer fake-as After the command is configured, BGP can use a fake AS
number to set up a BGP peer relationship.
If the local device uses the actual AS number to establish an
EBGP peer relationship with a remote device, the actual AS
number is carried in the AS_Path of the route sent to the
remote device. If the local device uses the fake AS number
to establish the EBGP peer relationship, the fake AS number
is carried in the AS_Path of the route sent to the remote
device.
peer substitute-as If the command is configured and an AS in the AS_Path

carried in the route sent by a PE to the CE of the specified
peer is the same as the AS of the CE, the PE replaces the AS
with the local AS.
NOTE
The peer substitute-as command applies only to PEs in BGP
MPLS IP/VPN scenarios and may cause routing loops if it is
improperly configured. Therefore, exercise caution when using the
command.
During BGP route selection, BGP compares the AS_Path length by calculating the number of
ASs included in the AS_Sequence if AS_Sequence is carried in a route. If both AS_Sequence
and AS_Set are carried in the route, BGP considers the AS_Path length to be the number of ASs
included in the AS_Sequence plus 1.
Deleting Private AS Numbers

As public AS resources are limited, carriers generally use private AS numbers when deploying
VPNs. Private AS numbers, however, must not be advertised to the Internet because they may
cause routing loops. In Figure 8-19, both ISP1 and ISP2 use 65001 as a private AS number.
Figure 8-19 Networking in which a private AS needs to be deleted
On B: peer C public-as-only
ISP1 ISP2
AS 65001 AS 100 AS 200
10.0.0.0/8
Router A Router B Router C
Update Update
10.0.0.0/8 10.0.0.0/8
AS_Path: 65001 AS_Path: 100

In Figure 8-19, Router A advertises the route 10.0.0.0/8 to Router D through ISP1 and ISP2.
After receiving this route, Router D checks its AS_Path. This AS_Path carries AS 65001, which
is the same as the AS of Router D. As a result, Router D discards this route.
To address this problem, run the peer public-as-only command on Router B so that Router B
deletes AS 65001 before adding AS 100 (public AS) to the AS_Path and forwarding the route
to Router C.
In the following situations, after the peer public-as-only command is configured, BGP does not
delete any private AS number from the AS_Path:
l The AS_Path of a route carries the AS number of the remote peer. In this case, deleting
private AS numbers may lead to a routing loop.
l The AS_Path carries both public and private AS numbers, which indicates that the route
has passed through the public network. In this case, deleting private AS numbers may lead
to incorrect traffic forwarding.
The preceding limitations also apply to confederation scenarios.
Adding AS Numbers
In Figure 8-20, AS 65005 imports three routes and advertises them to AS 65001 through two
paths.
Figure 8-20 Networking in which new AS numbers are added to the AS_Path
AS 65002
AS 65004
10.1.2.2/30
10.1.1.2/30 10.1.2.1/30 10.1.4.1/3
Router B Router D
10.1
10.1.1.1/30
AS 65001 Router A Router E
10.1.5.2
10.1.3.1/30 Router C
10.1.3.2/30 10.1.5.1/30
AS 65003



*> 172.16.1.0/24 10.1.3.2 0 65003 65005?

* 10.1.1.2 0 65002 65004
65005?
*> 172.16.2.0/24 10.1.3.2 0 65003 65005?
* 10.1.1.2 0 65002 65004
65005?
*> 172.16.3.0/24 10.1.3.2 0 65003 65005?
* 10.1.1.2 0 65002 65004
65005?

From: 10.1.3.2 (10.1.5.1)
AS-path 65003 65005, origin incomplete, pref-val 0, valid, external, best, select,
active, pre 255
10.1.3.2
10.1.1.2
From: 10.1.1.2 (10.1.1.2)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, pre
255, not preferred for AS-Path
The preceding command output shows that Router A selects the route learned from Router C
because this route has a shorter AS_Path length than that learned from Router B. To enable
Router A to select the route learned from Router B, configure Router B to reduce the AS_Path
length of the route or configure Router C to increase the AS_Path length of the route. In the
following example, Router C is configured to increase the AS_Path length of the route. The
detailed configurations on Router C are as follows:
#
bgp 65003
#
ipv4-family unicast
peer 10.1.3.1 route-policy add_asn export //Apply export policy named
add_asn to routes to be advertised to 10.1.3.1.
#
route-policy add_asn permit node 10 //Define the first node of

add_asn.
if-match ip-prefix prefix1 //Configure IP prefix list
named prefix1.
apply as-path 65003 65003 65003 additive //Add 65003, 65003, 65003
to the AS_Path of the route that matches prefix1.
#
route-policy add_asn permit node 20 //Define the second node of
add_asn to permit all other routes.
#
ip ip-prefix prefix1 index 10 permit 172.16.1.0 24 //Define the first index of
prefix1 to match the route 172.16.1.0/24.
ip ip-prefix prefix1 index 20 permit 172.16.2.0 24 //Define the second index
of prefix1 to match the route 172.16.2.0/24.
ip ip-prefix prefix1 index 30 permit 172.16.3.0 24 //Define the third index of
prefix1 to match the route 172.16.3.0/24.
#



*> 172.16.1.0/24 10.1.1.2 0 65002 65004

65005?
* 10.1.3.2 0 65003 65003
65003 65003 65005?
*> 172.16.2.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65003 65003
65003 65003 65005?
*> 172.16.3.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65003 65003
65003 65003 65005?

From: 10.1.1.2 (10.1.1.2)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best,
10.1.3.2
10.1.1.2
From: 10.1.3.2 (10.1.5.1)
AS-path 65003 65003 65003 65003 65005, origin incomplete, pref-val 0, valid,

external, pre 255, not preferred for AS-Path

The preceding command output shows that the AS_Path length of the route learned from
Router B is shorter than that of the route learned from Router C and that the route learned from
Router B is selected as the optimal route. Table 8-25 shows the attribute comparison of the
routes 172.16.1.0 learned from Router B and Router C.
Table 8-25 Attribute comparison of the routes 172.16.1.0 learned from Router B and Router C

from Router B from Router C
AIGP - - The same.
AS_Path 65002 65004 65005 65003 65003 65003 The route learned
65003 65005 from Router B is
optimal.
AS numbers can be added to the AS_Path as required. However, if an AS number is added to

the AS_Path of a route, the route cannot be received by devices in this AS. Therefore, the local
AS number is added in most cases. For example in Figure 8-20, if Router C adds AS 65001 to
the AS_Path of a route before advertising the route to Router A, Router A will discard the route
upon receipt because the route carries Router A's AS number.
Replacing AS Numbers
When the apply as-path command is configured, if overwrite is specified in the command, the
device will replace the AS numbers in the original AS_Path attribute to achieve the following
goals:
l Hide the actual path information.
l Prevent a route from being discarded by replacing the AS_Path of the route with a shorter
one if the as-path-limit command is configured on the device that receives this route.
l Reduce the AS_Path length.
AS number replacement can also be used for the purpose of load balancing. For example in
Figure 8-20, the apply as-path 65002 65004 65005 overwrite command can be configured on
Router A to replace the AS_Path of the route learned from Router C so that the route has the
same AS_Path as that of the route learned from Router B, and the two routes are used to load-
balance traffic. Detailed configurations on Router A are as follows:
#
bgp 65001
#
ipv4-family unicast
peer 10.1.3.2 route-policy replace_asn import //Apply export policy named

replace_asn to routes to be advertised to 10.1.3.1.

#
route-policy replace_asn permit node 10 //Define the first node of
replace_asn.
if-match as-path-filter filter1 //Configure AS_Path filter
named filter1.
apply as-path 65002 65004 65005 overwrite //Replace the AS_Path of
the route that matches filter1 with 65002, 65004, 65005.
#
route-policy replace_asn permit node 20 //Define the second node of
replace_asn to permit all other routes.
#
ip as-path-filter filter1 permit ^65003 //Define AS_Path filter
named filter1 to match all the routes learned from AS 65003.
#



*> 172.16.1.0/24 10.1.1.2 0 65002 65004

65005?
* 10.1.3.2 0 65002 65004
65005?
*> 172.16.2.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65002 65004
65005?
*> 172.16.3.0/24 10.1.1.2 0 65002 65004
65005?
* 10.1.3.2 0 65002 65004
65005?
The preceding command output shows that the AS_Path of the route received from AS 65003
has been replaced, after which the routes received from AS 65002 and AS 65003 have the same
AS_Path. Run the maximum load-balancing 2 command on Router A to set the maximum
number of routes for load balancing to 2. Then, check the detailed route information. The route
172.16.1.0/24 is used in the following example:

From: 10.1.1.2 (10.1.1.2)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external, best,
10.1.1.2
10.1.3.2


From: 10.1.3.2 (10.1.5.1)
AS-path 65002 65004 65005, origin incomplete, pref-val 0, valid, external,
select, active, pre 255, not preferred for router ID
The preceding command output shows that the route learned from Router B is optimal and is
used along with the route learned from Router C (not optimal) for load balancing. Check the
information about the route 172.16.1.0/24 in the IP routing table.
------------------------------------------------------------------------------
10.1.1.0/30 Direct 0 0 D 10.1.1.1

10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.3.0/30 Direct 0 0 D 10.1.3.1
10.1.3.1/32 Direct 0 0 D 127.0.0.1
172.16.1.0/24 EBGP 255 0 D 10.1.1.2
EBGP 255 0 D 10.1.3.2
172.16.2.0/24 EBGP 255 0 D 10.1.1.2
EBGP 255 0 D 10.1.3.2
172.16.3.0/24 EBGP 255 0 D 10.1.1.2
EBGP 255 0 D 10.1.3.2 GigabitEthernet0/0/0
The preceding command output shows that BGP has delivered the two routes with the same
route prefix to the IP routing table for load balancing.
Clearing the AS_Path

When the apply as-path command is configured, if none overwrite is specified in the command,
the device clears the AS_Path to hide the actual path information. If the AS_Path is null, BGP
considers its length as 0 during route selection.
Origin
The Origin attribute indicates how routes become BGP routes.
Three types of Origin attributes are available:
l IGP: indicates that routes are added to the BGP routing table using the network command.
IGP has the highest priority.
l EGP: indicates that routes are learned through the EGP protocol. EGP has the second
highest priority.

NOTE
The NE80E/40E can receive and send BGP routes with EGP as the Origin. However, the NE80E/
40E does not support the EGP protocol; therefore, to set the Origin of routes to EGP, you need to
run the apply origin { egp { as-number-plain | as-number-dot } | igp | incomplete } command to
configure an apply clause for a route-policy.
l Incomplete: indicates that routes are added to the BGP routing table using the import-
route command. Incomplete has the lowest priority.
The routes imported using the network command are more specific than those imported using
the import-route command. Therefore, IGP takes precedence over Incomplete in route
selection. In Figure 8-21, Router A and Router B are EBGP peers, and Router B, Router C, and
Router D are IBGP peers.
Figure 8-21 Networking diagram with Origin configurations
AS 100 AS 65001
Router A Router B Router D
10.1.1.1/30 10.1.1.2/30 10.1.3.1/30
IBGP 10.1.3.2/30
10.1.2.1/30 10.1.4.1/30
IBGP IBGP
Router C
10.1.2.2/30 10.1.4.2/30
The configurations on Router D are as follows:

#
bgp 65001
#
ipv4-family unicast
10.1.4.0/30.
#
The configurations on Router C are as follows:

#
bgp 65001
#
ipv4-family unicast
#




i 10.1.2.0/30 10.1.2.2 0 100 0 ?

*>i 10.1.4.0/30 10.1.3.2 0 100 0 i
* i 10.1.2.2 0 100 0 ?
The preceding command output shows that two active routes 10.1.4.0/30 are available in the
routing table.

From: 10.1.3.2 (10.1.3.2)
10.1.1.1
From: 10.1.2.2 (10.1.2.2)
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal,
pre 255, not preferred for Origin
The preceding command output shows that the route learned from Router D is selected because
it is imported using the network command and its Origin priority is higher than that of the route
learned from Router C. Table 8-26 describes the attribute comparison of the routes learned from
Router C and Router D.
Table 8-26 Attribute comparison of the routes learned from Router C and Router D

from Router C from Router D
AIGP - - The same.
AS_Path - - The same length.


Origin Incomplete IGP The route learned

from Router D is
optimal.
The Origin attribute can be modified using a route-policy. In the following example, a route-
policy is configured on Router B to modify the Origin attribute, and the detailed configurations
are as follows:
#
bgp 65001
#
ipv4-family unicast
peer 10.1.3.2 route-policy for_d import //Apply import policy named
for_d to the routes learned from 10.1.3.2 and use for_d to modify the Origin
value.
#
route-policy for_d permit node 10 //Define the route-policy
named for_d.
apply origin incomplete //Set the Origin type to
Incomplete.


i 10.1.2.0/30 10.1.2.2 0 100 0 ?

*>i 10.1.4.0/30 10.1.2.2 0 100 0 ?
* i 10.1.3.2 0 100 0 ?
The preceding command output shows that the route learned from Router C becomes the optimal
route.

From: 10.1.2.2 (10.1.2.2)
best, select, active, pre 255
10.1.1.1


From: 10.1.3.2 (10.1.3.2)
pre 255, not preferred for router ID
The preceding command output shows that the route learned from Router C becomes the optimal
route because it has a smaller router ID than the route learned from Router D. Table 8-27 shows
the attribute comparison of the routes learned from Router C and Router D.

AIGP - - The same.
AS_Path - - The same.
Origin Incomplete Incomplete The same.
MED 0 0 The same.
Cluster_List - - The same.
Router ID 10.1.2.2 10.1.3.2 The route learned

from Router C is
optimal.
MED
MED attributes of routes can be configured as required to control traffic forwarding path for the
purpose of load balancing.
The MED attribute is transmitted only within an AS or between two neighboring ASs. The AS
that receives the MED attribute does not advertise it to a third AS.
Similar to the cost used by an IGP, the MED is used to determine the optimal route when traffic
enters an AS. When a BGP peer learns multiple routes that have the same destination address
but different next hop addresses from EBGP peers, the route with the smallest MED value is
selected as the optimal route if all the other attributes are the same.
Table 8-28 lists two methods used to modify the MED value.

Table 8-28 Methods to modify the MED value
Run the default med command. This method sets a default MED for all the
routes that the local device advertises to its
BGP peers. The default med command takes
effect only with the routes imported locally
using the import-route command and BGP
summarized routes.
Configure an import or export policy and run This method sets different MED values for
the apply cost command to configure an different routes advertised by the local device
apply clause for the policy. to its EBGP peers.
Configure an export policy and run the apply This method enables a device to set MED
cost-type internal command to configure an values for the BGP routes that are learned
apply clause for the export policy. from IBGP peers and to be advertised to
EBGP peers and match the export policy to
the costs of the IGP routes to which the BGP
routes are iterated.
The major points about MED attributes that require consideration are as follows:
l If routes are received from different ASs, traffic will be sent to different ASs. In addition,
BGP selects the optimal route only from the routes destined for the same address. Therefore,
BGP only compares the MEDs of routes that are from the same AS (excluding confederation
sub-ASs). MEDs of two routes are compared only if the leftmost AS number in the
AS_Sequence (excluding AS_Confed_Sequence) of one route is the same as its counterpart
in the other route.
l If the compare-different-as-med command is run, BGP compares MEDs of routes even
when the routes are received from peers in different ASs. Do not run this command unless
the ASs use the same IGP and route selection mode. Otherwise, a routing loop may occur.
l If a route does not carry MED, BGP uses the default value (0) as the MED of the route
during route selection. If the bestroute med-none-as-maximum command is run, BGP
considers the largest MED value (4294967295) to be the MED of the route.
l After the bestroute med-confederation command is configured, BGP compares the MEDs
of routes only when the AS_Path attributes of the routes carry no external AS numbers
(ASs that do not belong to the confederation) and the leftmost AS numbers in each
AS_Confed_Sequence are the same.
l After the deterministic-med command is configured, routes will not be selected in the
same sequence they are received.
In Figure 8-22, ISP1 and ISP2 can learn the route 1.1.1.9/32 from Router C or Router D.

Figure 8-22 Networking diagram for MED applications
Internet
ISP1 ISP2
AS 100 AS 200
10
Router A Router B
0
.1
/3
.3
.1
.1
.4
10.1.1.1/30 /3 10.1.2.1/30
.1
0
10
EBGP EBGP
10
.1
.3
0
/3
.
Client Network 2/30
.2
.4
.1
10.1.1.2/30 AS 65001 10.1.2.2/30

10
10.1.5.1/30
Router C Router D
IBGP 10.1.5.2/30
10.1.6.1/30 10.1.7.1/30
IBGP 1.1.1.9/32 IBGP

10.1.6.2/30 10.1.7.2/30
Router E
Scenario 1: Check the BGP routing tables of Router A and Router B before Router C and
Router D are configured to modify the MED of the route 1.1.1.9/32.



*> 1.1.1.9/32 10.1.1.2 0 65001i

* 10.1.3.2 0 65001i


*> 1.1.1.9/32 10.1.4.2 0 65001i

* 10.1.2.2 0 65001i
The preceding command output shows that both ISP1 and ISP2 select the route learned from
Router C as the optimal route. As a result, Router C and Router D cannot load-balance the traffic
from ISP1 or ISP2 to 1.1.1.1/32.
Run the display bgp routing-table ip-address command on Router B to check the reason why
Router B chooses the route learned from Router C.

From: 10.1.4.2 (10.1.1.2)
AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active, pre
255
10.1.2.2
10.1.4.2
From: 10.1.2.2 (10.1.2.2)
AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred for
router ID
The preceding command output shows that Router B selects the route learned from Router C
because the router ID (10.1.1.2) of Router C is smaller than that (10.1.2.2) of Router D. Table
8-29 describes the attribute comparison of the routes learned from Router C and Router D.



AIGP - - The same.
AS_Path 65001 65001 The same length.
MED - - The same.
Peer type EBGP EBGP The same.
Cluster_List - - The same length.
Router ID 10.1.1.2 10.1.2.2 The route learned

from Router C is
optimal.

l For the traffic from ISP1 to 1.1.1.9/32, the link Router A -> Router C is active and the link
Router A -> Router D is backup.
l For the traffic from ISP2 to 1.1.1.9/32, the link Router B -> Router D is active and the link
Router B -> Router C is backup.
To meet the preceding requirements, ensure that ISP1 selects the route learned from Router C
and that ISP2 selects the route learned from Router D. Figure 8-23 shows the networking in
which MED is used to control route selection.

Figure 8-23 Networking diagram for MED applications
Internet
ISP1 ISP2
AS 100 AS 200
Router A Router B
Set MED: EBGP EBGP Set MED:

100 for 1.1.1.9/32 to ISP2 200 for 1.1
Client Network
AS 65001
Router C Router D
IBGP
To: 1.1.1.9/32 To: 1.1.1.9/32

1.1.1.9/32
IBGP IBGP
Router E
Configure route-policies to set different MED values for the routes learned from different peers.
Detailed configurations are as follows:
l Configurations on Router C:
#
bgp 65001
#
ipv4-family unicast
peer 10.1.4.1 route-policy addmed100 export //Apply export policy
named addmed100 to the routes to be advertised to 10.1.4.1 and use addmed100
to modify the MED value.

#
route-policy addmed100 permit node 10 //Define the first node
of addmed100 and set the MED of the route 1.1.1.9/32 to 100.
if-match ip-prefix p1
apply cost 100
#
route-policy addmed100 permit node 20 //Define the second node
of addmed100 to allow addmed100 to permit all other routes.
#
ip ip-prefix p1 index 10 permit 1.1.1.9 32 //Configure an IP prefix
l Configurations on Router D:
NOTE
The following configurations are intended to ensure that Router A selects the route learned from
Router C. However, Router A has already selected the route learned from Router C because the router
ID of Router C is smaller than that of Router D. Therefore, the following configurations on Router
D are optional.
#
bgp 65001
#
ipv4-family unicast
peer 10.1.3.1 route-policy addmed200 export //Apply export policy
named addmed200 to the routes to be advertised to 10.1.3.1 and use addmed200
to modify the MED value.
#
route-policy addmed200 permit node 10 //Define the first node
of addmed200 and set the MED of the route 1.1.1.9/32 to 200.
if-match ip-prefix p1
apply cost 200
#
route-policy addmed200 permit node 20 //Define the second node
of addmed200 to allow addmed200 to permit all other routes.
#
ip ip-prefix p1 index 10 permit 1.1.1.9 32 //Configure an IP prefix
Run the display bgp routing-table [ ip-address ] command to check the configurations. Use
Router B as an example.



*> 1.1.1.9/32 10.1.2.2 0 65001i

* 10.1.4.2 100 0 65001i
# Display detailed information about the route 1.1.1.9/32 on Router B.

[RouterB] display bgp routing-table 1.1.1.9 32


From: 10.1.2.2 (10.1.2.2)

AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active, pre
255
10.1.2.2
10.1.4.2
From: 10.1.4.2 (10.1.1.2)
AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, pre 255, not
preferred for MED
The preceding command output shows that two routes 1.1.1.9/32 are available in the BGP routing
table of Router B and that only the route with next hop address 10.1.2.2 is selected as the optimal
route.
Table 8-30 describes the attribute comparison of the routes learned from Router C and Router
D.

AIGP - - The same.
MED 100 - The route learned

from Router D
carries no MED
value, and therefore,
the default value (0)
is used.
The route learned
from Router D is
optimal.
Figure 8-23 shows that the route learned from Router D does not carry the MED value. During
route selection, BGP uses the default value (0) as the MED of the route. Therefore, this route is

selected as the optimal route. To change the route selection result on Router B, run the bestroute
med-none-as-maximum command on Router B. Detailed configurations are as follows:


*> 1.1.1.9/32 10.1.4.2 100 0 65001i

* 10.1.2.2 0 65001i

From: 10.1.4.2 (10.1.1.2)
AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, best, select,
active, pre 255
10.1.2.2
10.1.4.2
From: 10.1.2.2 (10.1.2.2)
AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred for
MED
The preceding command output shows that two routes 1.1.1.9/32 are available in the BGP routing
table of Router B. The MED of the route with the next hop address 10.1.4.2 is 100, and the MED
of the route with the next hop address 10.1.2.2 is considered as 4294967295 because it carries
no MED. Therefore, the route with the next hop address 10.1.4.2 is selected as the optimal route.
In addition, BGP selects routes in the same sequence they are received. Therefore, the route
selection result is relevant to the sequence in which the routes are received. For example, the
following three BGP routes are available on a device:
l Route A1: AS_Path { 65001 200 }, med 100, igp cost 13, internal, Router id 4.4.4.4
l Route A2: AS_Path { 65001 100 }, med 150, igp cost 11, internal, Router id 5.5.5.5
l Route B: AS_Path { 65002 300 }, med 0, igp cost 12, internal, Router id 6.6.6.6
If the compare-different-as-med (BGP) command is run, route B is the optimal route,
regardless of the sequence in which the routes are received. If the compare-different-as-med
(BGP) command is not configured, BGP does not compare the MED values of routes learned
from different ASs. The route selection is described in the following cases:
l Case 1: Route A1 is received first, followed by route B, and then route A2.
– BGP first compares route A1 and route B. The leftmost AS number in the AS_Path of
route A1 is 65001, which is different from its counterpart in route B (65002). Therefore,

BGP does not compare the MED values, and prefers route B to route A1 because the
IGP cost (12) of route B is smaller than that of route A1 (13).
– BGP then compares route A2 and route B. The leftmost AS number in the AS_Path of
BGP does not compare the MED values, and selects route A2 as the optimal route
because its IGP cost (11) is smaller than that of route B (12).
l Case 2: Route A2 is received first, followed by route B, and then route A1.
BGP does not compare the MED values and prefers route A2 to route B because the
IGP cost (11) of route A2 is smaller than that of route B (12).
– BGP then compares route A1 and route A2. The leftmost AS number in the AS_Path
of route A1 is the same as its counterpart in route A2 (65001). In this situation, BGP
selects route A1 as the optimal route because its MED value (100) is smaller than that
of route A2 (150).
l Case 3: If the deterministic-med command is run, BGP groups the routes that are learned
from different ASs but are destined for the same network segment based on the leftmost
AS number in the AS_Path, selects one optimal route from each group, and then compares
the optimal routes of all the groups. Detailed steps are as follows:
– BGP first compares route A1 and route A2. The leftmost AS number in the AS_Path of
route A1 is the same as its counterpart in route A2 (65001). In this situation, BGP selects
route A1 as the optimal route because its MED value (100) is smaller than that of route
A2 (150).
BGP does not compare the MED values and selects route B as the optimal route because
the IGP cost (12) of route B is smaller than that of route A1 (13).
Case 1 and case 2 show that the route selection result is relevant to the sequence in which routes
are received if the deterministic-med is not configured. Case 3 shows that the route selection
result is irrelevant to the sequence in which routes are received if the deterministic-med is
configured.
Peer Type
When IBGP routes (routes learned from IBGP peers) and EBGP routes (routes learned from
EBGP peers) are available, BGP preferentially selects EBGP routes.
When one EBGP route and multiple IBGP routes are available, BGP selects the optimal route
based on the peer type. If no EBGP route is available or multiple EBGP routes are available,
BGP is unable to select the optimal route based on the peer type.
When multiple egress devices reside on a carrier network and receive routes from the Internet,
the egress devices select the optimal route based on the peer type in most cases. In Figure
8-24, all devices reside in the same AS, Router A and Router B function as egress devices and
are IBGP peers of all devices in the AS. In addition, Router A and Router B receive routes from
the Internet and advertise EBGP routes to all their IBGP peers. Therefore, Router A and
Router B have an IBGP route and an EBGP route, and the two routes have the same AS_Path.
In this situation, Router A and Router B select the EBGP route as the optimal route.

Figure 8-24 Peer type application networking
Internet
EBGP EBGP
Router A Router B
IBGP
The EBGP route is selected as the optimal route, which prevents the traffic that leaves Router
A or Router B for the Internet from being forwarded to the other egress device.
For more peer type-based route selection examples, see Local_Pref.
IGP Cost
BGP prefers the route with the smallest IGP cost during BGP route selection.
This rule helps BGP to choose the route with the smallest cost to its iterated next hop address
quickly. If the bestroute igp-metric-ignore command is configured, BGP does not compare
the IGP cost. In Figure 8-25, OSPF runs in AS 65001, an EBGP peer relationship is established
between Router E and Router A and between Router E and Router B, and an IBGP peer
relationship is established between Router A and Router C, between Router A and Router D,
between Router B and Router C, and between Router B and Router D; Router E is configured
to import routes (1.1.1.9/32 for example) from AS 100 to BGP.

Figure 8-25 Networking diagram with IGP cost configurations
ISP
AS 100
1.1.1.9/32
10.1.5.2/30 10.1.6.2/30
EBGP RouterE EBGP

10.1.5.1/30 10.1.6.1/30
10.1.4.1/30
RouterA 10.1.4.2/30 RouterB
10.1.3.2/30 10.1.3.2/30
AS 65001
10.1.3.1/30 10.1.3.1/30
10.1.2.1/30
RouterC 10.1.2.2/30 RouterD
Run the display bgp routing-table [ ip-address ] command on Router C and Router D to check
the configurations. Router C is used as an example.


*>i 1.1.1.9/32 10.1.5.2 0 100 0 100i

* i 10.1.6.2 0 100 0 100i
*>i 10.1.5.0/30 10.1.3.2 0 100 0 i
*>i 10.1.6.0/30 10.1.2.2 0 100 0 i
The preceding command output shows that two routes 1.1.1.9/32 are available in the routing
table of Router C and that Router C selects the route learned from Router A.

From: 10.1.3.2 (2.2.2.9)


AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, best,

From: 10.1.2.2 (10.1.2.2)
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre
255, IGP cost 2, not preferred for IGP cost
The preceding command output shows that the route with next hop address 10.1.6.2 is ignored
because its IGP cost is larger than that of the other route. Table 8-31 describes the attribute
comparison of the routes learned from Router A and Router B.
Table 8-31 Attribute comparison of the routes learned from Router A and Router B.

AIGP - - The same.
MED 0 0 The same.
IGP cost - 2 The route learned

from Router A is
optimal.
NOTE
If a BGP route carries
no IGP cost value,
BGP considers its IGP
cost to be 0. If no IGP
routes are used during
BGP peer relationship
establishment or the
costs of used IGP
routes are 0, the IGP
cost is not displayed in
the display bgp
routing-table ip-
address command
output.

Cluster_List
BGP prefers the route with the shortest Cluster_List length during BGP route selection.
An RR and its clients form a cluster. In an AS, each RR is uniquely identified by a Cluster_ID.
Similar to an AS_Path, a Cluster_List is composed of a series of Cluster_IDs and is generated
by an RR. The Cluster_List records all the RRs through which a route passes.
l Before an RR reflects a route between its clients or between its clients and non-clients, the
RR adds the local Cluster_ID to the leftmost position of the Cluster_List. If a route does
not carry any Cluster_List, the RR creates one for the route.
l After the RR receives an updated route, it checks the Cluster_List of the route. If the RR
finds that its cluster ID is included in the Cluster_List, the RR discards the route. If its
cluster ID is not included in the Cluster_List, the RR adds its cluster ID to the Cluster_List
and then reflects the route.
The following example shows how Cluster_List is used in BGP route selection. In Figure
8-26, an IBGP peer relationship is established between each two neighboring devices in AS
65001. Router B functions as a level-1 RR, and Router D is its client. Router D functions as a
level-2 RR, and Router E is its client. Router C functions as an RR, and Router E is its client.
Router E is configured to import the route 1.1.1.9/32 to BGP.
Figure 8-26 Networking diagram with Cluster_List configurations
Cluster 2 Cluster 1
RR2 RR1
10.1.2.1/30 10.1.2.2/30
10.1.1.2/30 10.1.4.1/30
Router B Router D
10.1.1.1/30
10.1.4.2/30
AS 65001
Router A Router E
10.1.5.2/30
10.1.3.1/30
Router C
10.1.3.2/30 10.1.5.1/30
RR3 BGP Upd
Cluster3
Run the display bgp routing-table [ ip-address ] command on Router A to check the
configurations.



*>i 1.1.1.9/32 10.1.5.2 0 100 0 i

* i 10.1.4.2 0 100 0 i
table of Router C and that Router A selects the route learned from Router C.

From: 10.1.3.2 (2.2.2.9)
select, active, pre 255, IGP cost 3
Originator: 1.1.1.9

From: 10.1.1.2 (10.1.2.1)
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre
255, IGP cost 3, not preferred for Cluster List
Originator: 1.1.1.9
Cluster list: 0.0.0.2, 0.0.0.1
The preceding command output shows that the route learned from Router B is ignored because
its Cluster_List is longer than that of the route learned from Router C. Table 8-32 describes
attribute comparison of the routes learned from Router B and Router C.
Table 8-32 Attribute comparison of the routes learned from Router B and Router C

AIGP - - The same.


MED 0 0 The same.
IGP cost 3 3 The same.
Cluster_List 0.0.0.2, 0.0.0.1 0.0.0.3 The route learned

from Router C is
optimal.
In most cases, BGP does not advertise the routes learned from an AS to the AS again. When
RRs are deployed, such routes may be advertised to the AS again although routing loops may
occur. Using the Cluster_List attribute can prevent such routing loops.
Originator_ID
If routes carry the Originator_ID, the originator ID is substituted for the router ID during route
selection. The route with the smallest Originator_ID is preferred.
The Originator_ID attribute is four bytes long and is generated by an RR. It carries the router
ID of the route originator in the local AS.
l When a route is reflected by an RR for the first time, the RR adds the Originator_ID to this
route. If a route already carries the Originator_ID attribute, the RR does not create a new
one.
l After receiving the route, a BGP speaker checks whether the Originator_ID is the same as
its router ID. If Originator_ID is the same as its router ID, the BGP speaker discards this
route.
The following example shows how Originator_ID is used during BGP route selection. In Figure
8-27, an IBGP peer relationship is established between each two neighboring devices in AS
65001. The router IDs of Router B and Router C are 2.2.2.9 and 3.3.3.9, respectively, and they
function as RRs. Router D is a client of Router B, and Router E is a client of Router C. Router
D and Router E are configured to import the route 10.1.4.0/30 to BGP.

Figure 8-27 Networking diagram with Originator_ID configurations
Cluster 2
RR2
10.1.2.1/30 10.1.2.2/30
10.1.1.2/30 10.1.4.2/30
Router B Router D
10.1.1.1/30
10.1.4.1/30
AS 65001
Router A Router E
10.1.5.2/30
10.1.3.1/30
RouterC
10.1.3.2/30 10.1.5.1/30
RR3 BGP Upda
Cluster 3
Run the display bgp routing-table [ ip-address ] command on Router A to check the
configurations.


*>i 10.1.4.0/30 10.1.5.2 0 100 0 i

* i 10.1.2.2 0 100 0 i
table of Router A and that Router A selects the route learned from Router C.

From: 10.1.3.2 (3.3.3.9)

select, pre 255, IGP cost 2

Originator: 10.1.4.1

From: 10.1.1.2 (2.2.2.9)
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre
255, IGP cost 2, not preferred for router ID
Originator: 10.1.4.2
The preceding command output shows that the route learned from Router B is not selected due
to a router ID issue. In fact, the router ID of Router B is 2.2.2.9, smaller than that (3.3.3.9) of
Router C. The route learned from Router B should be selected if the router IDs are used to
determine the optimal route. However, the routes carry Originator_ID attributes. In this situation,
the Originator_ID attributes (rather than router IDs) are compared. Router A selects the route
learned from Router C because its Originator_ID (10.1.4.1) is smaller than that (10.1.4.2) of the
route learned from Router B.
Table 8-33 describes the attribute comparison of the routes learned from Router B and Router
C.
Table 8-33 Attribute comparison of the routes learned from Router B and Router C

AIGP - - The same.
MED 0 0 The same.
IGP cost 2 2 The same.
Cluster_List 0.0.0.2 0.0.0.3 The same length.
Originator_ID 10.1.4.2 10.1.4.1 The route learned

from Router C is
optimal.

If routes carry Originator_ID attributes, the Originator_ID attributes (rather than router IDs) are
compared.
Router ID
If multiple routes to the same destination are available, BGP preferentially selects the route
advertised by the device with the smallest router ID.
A router ID uniquely identifies a router in an AS, and the router ID can be configured as follows:
l Run the router-id { ipv4-address | vpn-instance auto-select } command. If no router ID
is configured in the BGP view, BGP selects a router ID configured in the system view. For
details on how a router ID configured in the system view is selected, see router-id.
l Run the router-id (BGP) { ipv4-address | auto-select } command in the BGP VPN instance
IPv4/IPv6 address family view. The router-id (BGP VPN instance IPv4/IPv6 address
family view) command takes precedence over the router-id (BGP) command.
If each route carries an Originator_ID, the Originator_IDs rather than router IDs are compared
during route selection. The route with the smallest Originator_ID is preferred. 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 router id-prior-clusterlist command.
For more router ID-based route selection examples, see Local_Pref, Origin, and MED.
Peer IP Address
BGP prefers the route learned from the peer with the smallest IP address during BGP route
selection.
The peer IP address is the IP address specified in ipv4-address or ipv6-address in the peer
{ group-name | ipv4-address | ipv6-address } as-number { as-number-plain | as-number-dot }
command. The group-name parameter specified in the command is the one specified in the
peer { ipv4-address | ipv6-address } group group-name command.
If the optimal route has not been selected yet before BGP begins to compare peer IP addresses,
the local device may have established multiple BGP peer relationships with another device
through equal-cost links. In most cases, if a backup physical link is available between two
devices, using loopback interfaces to establish a BGP peer relationship is recommended although
multiple BGP peer relationships may be established between the two devices through the
physical links.
In Figure 8-28, two physical links are available between Router A and Router B. Router A and
Router B can use loopback interfaces to establish a BGP peer relationship or use the two links
to establish two BGP peer relationships. In the following example, the two links are used to
establish two BGP peer relationships to show how peer addresses are used in route selection.

Figure 8-28 Networking in which two links are used to establish two BGP peer relationships
AS 65001 AS 65002
10.1.1.1/30 10.1.1.2/30
1.1.1.9/32 2.2.2.9/32
10.1.2.1/30 10.1.2.2/30
Router A Router B
The configurations on Router A are as follows:

#
bgp 65001
#
ipv4-family unicast
#
The configurations on Router B are as follows:

#
bgp 65002
#
ipv4-family unicast
network 2.2.2.9 255.255.255.255
#


*> 2.2.2.9/32 10.1.1.2 0 0 65002i

* 10.1.2.2 0 0 65002i
table and that the route with the next hop address 10.1.1.2 is selected as the optimal route.

From: 10.1.1.2 (192.168.2.4)


AS-path 65002, origin igp, MED 0, pref-val 0, valid, external, best, select,
active, pre 255
10.1.1.2
10.1.2.2
From: 10.1.2.2 (192.168.2.4)
preferred for peer address
The preceding command output shows that the route with the next hop address 10.1.1.2 is
selected as the optimal route because its peer IP address is smaller than that of the other route.

BGP configuration examples explain networking requirements, networking diagram,
Follow-up Procedure
NOTE
8.28.1 Example for Configuring Basic BGP Functions

After configuring basic BGP functions, you can build up a BGP network to use BGP to transmit
routing information.
Multiple ASs exist in a region. To access each other, these ASs must exchange their local routes.
As multiple routers exist in the ASs, there are a large number of routes that change frequently.
How to transmit a great deal of routing information efficiently between ASs without consuming
lots of bandwidth resources has become a problem. BGP can be used to solve this problem.
On the network shown in Figure 8-29, Router A is in AS 65008. Routers B, C, and D are in AS
65009. The routing tables of these routers store many routes, and the routes change frequently.
After BGP is enabled on the routers, the routers can exchange routing information. When routes
of one router changes, the router will send Update messages carrying only changed routing
information to its peers, and will not send its entire routing table. This greatly reduces bandwidth
consumption.

Figure 8-29 Networking diagram for configuring basic BGP functions
GE1/0/0 POS3/0/0 POS2/0/0

8.1.1.1/8 POS2/0/0 9.1.3.2/24 9.1.2.1/24
200.1.1.2/24 RouterC
POS3/0/0 POS2/0/0
9.1.3.1/24 AS 65009 9.1.2.2/24
RouterA
POS2/0/0 POS1/0/0
200.1.1.1/24 RouterB 9.1.1.1/24 POS1/0/0
AS 65008 RouterD
9.1.1.2/24
1. Establish IBGP connections between Routers B, C, and D so that these devices can
exchange routing information.
2. Establish an EBGP connection between Routers A and B so that these devices can exchange
3. Run the network command to configure Router A to advertise route 8.1.1.1/8.
4. Configure Router B to import direct routes and view the routing tables of Routers A and
C.
Data Preparation
l Router IDs 2.2.2.2, 3.3.3.3, and 4.4.4.4 and AS number 65009 of Routers B, C, and D
respectively
l Router ID 1.1.1.1 and AS number 65008 of Router A
Procedure
Step 2 Establish IBGP connections.
[RouterB] bgp 65009
[RouterC] bgp 65009


[RouterD] bgp 65009
Step 3 Establish an EBGP connection.
[RouterA] bgp 65008
[RouterB-bgp] quit
# View the status of BGP connections.

[RouterB] display bgp peer
9.1.1.2 4 65009 49 62 0 00:44:58 Established 0
9.1.3.2 4 65009 56 56 0 00:40:54 Established 0
200.1.1.2 4 65008 49 65 0 00:44:03 Established 1
The preceding command output shows that BGP connections have been established between
Router B and other routers.
Step 4 Configure Router A to advertise a route.
# Configure Router A to advertise route 8.0.0.0/8.

[RouterA-bgp] ipv4-family unicast
[RouterA-bgp-af-ipv4] network 8.0.0.0 255.0.0.0
[RouterA-bgp-af-ipv4] quit
[RouterA-bgp] quit



*> 8.0.0.0 0.0.0.0 0 0 i





*> 8.0.0.0 200.1.1.2 0 0 65008i
# View the routing table of Router C.



i 8.0.0.0 200.1.1.2 0 100 0 65008i
NOTE
The preceding command output shows that Router C has learned the route to destination 8.0.0.0 in AS
65008. The route, however, is invalid because the next hop 200.1.1.2 of this route is unreachable.
Step 5 Configure BGP to import direct routes.
[RouterB] bgp 65009
[RouterB-bgp-af-ipv4] import-route direct



*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009?
*> 9.1.1.2/32 200.1.1.1 0 0 65009?
*> 9.1.3.0/24 200.1.1.1 0 0 65009?
*> 9.1.3.2/32 200.1.1.1 0 0 65009?
*> 200.1.1.0 200.1.1.1 0 0 65009?
*> 200.1.1.2/32 200.1.1.1 0 0 65009?




*>i 8.0.0.0 200.1.1.2 0 100 0 65008i

*>i 9.1.1.0/24 9.1.3.1 0 100 0 ?
*>i 9.1.1.2/32 9.1.3.1 0 100 0 ?
*>i 9.1.3.0/24 9.1.3.1 0 100 0 ?
*>i 9.1.3.2/32 9.1.3.1 0 100 0 ?
*>i 200.1.1.0 9.1.3.1 0 100 0 ?
*>i 200.1.1.2/32 9.1.3.1 0 100 0 ?
The preceding command output shows that the route to destination 8.0.0.0 becomes valid
because the next-hop address of this route is the address of Router A.
# Run the ping 8.1.1.1 command on Router C.
[RouterC] ping 8.1.1.1
0.00% packet loss
----End
Configuration Files
#
sysname RouterA
#
ip address 8.1.1.1 255.0.0.0
#
interface Pos2/0/0
link-protocol ppp
ip address 200.1.1.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
network 8.0.0.0
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 9.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 200.1.1.1 255.255.255.0

#
interface Pos3/0/0
link-protocol ppp
ip address 9.1.3.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
import-route direct
peer 9.1.1.2 enable
peer 9.1.3.2 enable
#
return

#
sysname RouterC
#
interface Pos2/0/0
link-protocol ppp
ip address 9.1.2.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
ip address 9.1.3.2 255.255.255.0
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast
peer 9.1.2.2 enable
peer 9.1.3.1 enable
#
return

#
sysname RouterD
#
interface Pos1/0/0
link-protocol ppp
ip address 9.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 9.1.2.2 255.255.255.0
#
bgp 65009
router-id 4.4.4.4
#
ipv4-family unicast
peer 9.1.1.1 enable
peer 9.1.2.1 enable
#
return

8.28.2 Example for Configuring BGP to Interact with an IGP

Configuring BGP to interact with an IGP can enrich routing tables.
As the Internet grows, devices in different networks need to access each other, data needs to be
reliably transmitted, and the traffic interruption time needs to be minimized. This requires that
routing information be transmitted widely and network convergence be accelerated. BGP can
transmit routing information efficiently and widely. BGP, however, does not calculate routes by
itself. An IGP can implement rapid route convergence, but it transmits routing information with
a low efficiency in a limited scope. After BGP is configured to interact with an IGP, IGP routes
can be imported into BGP routing tables and can be transmitted efficiently, and BGP routes can
also be imported to IGP routing tables so that ASs can access each other.
The network shown in Figure 8-30 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. BGP can be configured
to enable the two ASs to access each other. Interaction between BGP and the IGP can be
configured on edge routers in the two ASs so that the two ASs can exchange routes efficiently
and access each other.
Figure 8-30 Networking diagram for configuring BGP to interact with an IGP
GE1/0/0 GE2/0/0
8.1.1.1/24 POS2/0/0 POS1/0/0
9.1.2.1/24
3.1.1.2/24 9.1.1.1/24
POS1/0/0
POS2/0/0
3.1.1.1/24
AS 65008
AS 65009
1. Configure OSPF on Routers B and C so that these devices can access each other.
2. Establish an EBGP connection between Routers A and B so that these devices can exchange
3. Configure BGP and OSPF to import routes from each other on Router B and view routing
information in the routing table of Router B.
4. (Optional) Configure BGP route summarization on Router B to simplify the BGP routing
table.
Data Preparation

l Area ID 0 of Routers B and C

l Router IDs 1.1.1.1 and 2.2.2.2 and AS numbers 65008 and 65009 of Routers A and B
respectively
Procedure
Step 2 Configuring OSPF
[RouterB] ospf 1
[RouterC] ospf 1
[RouterA] bgp 65008
[RouterA-bgp] quit
[RouterB] bgp 65009
Step 4 Configure BGP to interact with an IGP
# On Router B, configure BGP to import OSPF routes.

[RouterB-bgp-af-ipv4] import-route ospf 1
[RouterB-bgp-af-ipv4] quit
[RouterB-bgp] quit

*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.1.1.0/24 3.1.1.1 0 0 65009?

*> 9.1.2.0/24 3.1.1.1 2 0 65009?
# On Router B, configure OSPF to import BGP routes.

[RouterB] ospf
[RouterB-ospf-1] import-route bgp

------------------------------------------------------------------------------
8.1.1.0/24 O_ASE 150 1 D 9.1.1.1 Pos1/0/0

9.1.1.0/24 Direct 0 0 D 9.1.1.2 Pos1/0/0
9.1.1.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
9.1.2.0/24 Direct 0 0 D 9.1.2.1
9.1.2.1/32 Direct 0 0 D 127.0.0.1
Step 5 (Optional) Configure automatic route summarization.
BGP is used to transmit routing information on large-scale networks. BGP route summarization
can be configured to simplify routing tables of devices on these networks.
[RouterB] bgp 65009
[RouterB-bgp-af-ipv4] summary automatic

*> 8.1.1.0/24 0.0.0.0 0 0 i
*> 9.0.0.0 3.1.1.1 0 65009?
# Run the ping -a 8.1.1.1 9.1.2.1 command on Router A.

[RouterA] ping -a 8.1.1.1 9.1.2.1
0.00% packet loss
----End

Configuration Files
#
sysname RouterA
#
ip address 8.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 3.1.1.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
peer 3.1.1.1 enable
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 9.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 3.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
summary automatic
import-route ospf 1
peer 3.1.1.2 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 9.1.1.0 0.0.0.255
#
return

#
sysname RouterC
#
ip address 9.1.2.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
ip address 9.1.1.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 9.1.1.0 0.0.0.255

network 9.1.2.0 0.0.0.255

#
return
8.28.3 Example for Configuring AS_Path Filters

AS_Path filters can be used as needed to improve network performance.
Enterprises A, B, and C belong to different ASs. Enterprise B's network communicate with the
networks of the other two enterprises through EBGP. Due to the competition relationship,
enterprises A and C hope that the routes that they advertise to enterprise B are not learned by
each other. An AS_Path filter is configured on enterprise B's network to address this problem.
On the network shown in Figure 8-31, Router B establish EBGP connections with Routers A
and C. To disable devices in AS 10 from communicating with devices in AS 30, you can
configure an AS_Path filter on Router B to prevent devices in AS 20 from advertising routes of
AS 30 to AS 10 or routes of AS 10 to AS 30 in order to isolate AS 10 and AS 30.
Figure 8-31 Networking diagram for configuring AS_Path filters
GE1/0/0
AS 10 9.1.1.1/24
POS2/0/0
200.1.2.1/24
RouterA
EBGP
POS2/0/0 POS2/0/0
200.1.2.2/24 EBGP 200.1.3.2/24
GE1/0/0
POS3/0/0 20.1.1.1/24
200.1.3.1/24 RouterC
RouterB
AS 20 AS 30
1. Establish EBGP connections between Routers A and B and between Routers B and C and
configure these devices to import direct routes so that the ASs can communicate with each
other through these EBGP connections.
2. Configure AS_Path filters on Router B and use filtering rules to prevent AS 20 from
advertising routes of AS 30 to AS 10 or routes of AS 10 to AS 30.
Data Preparation


l Router ID 2.2.2.2 and AS number 20 of Router B
l Router ID 3.3.3.3 and AS number 30 of Router C
Procedure
Step 2 Establish EBGP connections.
[RouterA] bgp 10
[RouterA-bgp] import-route direct
[RouterA-bgp] quit
[RouterB] bgp 20
[RouterB-bgp] import-route direct
[RouterB-bgp] quit
[RouterC] bgp 30
[RouterRouterC-bgp] peer 200.1.3.1 as-number 20
[RouterC-bgp] import-route direct
[RouterC-bgp] quit
# View routes advertised by Router B. Routes advertised by Router B to Router C are used as
an example. You can see that Router B advertises the direct route imported by AS 10.
[RouterB] display bgp routing-table peer 200.1.3.2 advertised-routes


*> 9.1.1.0/24 200.1.3.1 0 0 20 10?

*> 20.1.1.0/24 200.1.3.1 0 20 30?
*> 200.1.2.0 200.1.3.1 0 0 20?
*> 200.1.2.1/32 200.1.3.1 0 0 20?
*> 200.1.3.0 200.1.3.1 0 0 20?
*> 200.1.3.2/32 200.1.3.1 0 0 20?
View the routing table of Router C. You can see that Router C has learned the direct route from
Router B.



*> 9.1.1.0/24 200.1.3.1 0 20 10?

*> 20.1.1.0/24 0.0.0.0 0 0 ?
*> 20.1.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
*> 200.1.2.0 200.1.3.1 0 0 20?
*> 200.1.2.1/32 200.1.3.1 0 0 20?
*> 200.1.3.0 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
*> 200.1.3.1/32 0.0.0.0 0 0 ?
*> 200.1.3.2/32 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
Step 3 Configure AS_Path filters on Router B and apply the AS_Path filters to routes to be advertised
by Router B.
# Create AS_Path filter 1 to deny the routes carrying AS number 30. The regular expression
"_30_" indicates any AS list that contains AS 30 and "*" matches any character.
[RouterB] ip as-path-filter path-filter1 deny _30_
[RouterB] ip as-path-filter path-filter1 permit .*
# Create AS_Path filter 2 to deny the routes carrying AS 10.

[RouterB] ip as-path-filter path-filter2 deny _10_
[RouterB] ip as-path-filter path-filter2 permit .*
# Apply the AS_Path filters to routes to be advertised by Router B.

[RouterB] bgp 20
[RouterB-bgp] peer 200.1.2.1 as-path-filter path-filter1 export
[RouterB-bgp] peer 200.1.3.2 as-path-filter path-filter2 export
[RouterB-bgp] quit
Step 4 # View routes advertised by Router B.

# View routes advertised by Router B to AS 30. You can see that Router B does not advertise
the direct route imported by AS 10.


*> 200.1.2.0 200.1.3.1 0 0 20?

*> 200.1.2.1/32 200.1.3.1 0 0 20?
*> 200.1.3.0 200.1.3.1 0 0 20?
*> 200.1.3.2/32 200.1.3.1 0 0 20?
The route does not exist in the BGP routing table of Router C.



*> 20.1.1.0/24 0.0.0.0 0 0 ?

*> 20.1.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
*> 200.1.2.0 200.1.3.1 0 0 20?
*> 200.1.2.1/32 200.1.3.1 0 0 20?
*> 200.1.3.0 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
*> 200.1.3.1/32 0.0.0.0 0 0 ?
*> 200.1.3.2/32 0.0.0.0 0 0 ?
* 200.1.3.1 0 0 20?
# View routes advertised by Router B to AS 10. You can see that Router B does not advertise
the direct route imported by AS 30.


*> 200.1.2.0 200.1.2.2 0 0 20?

*> 200.1.2.1/32 200.1.2.2 0 0 20?
*> 200.1.3.0 200.1.2.2 0 0 20?
*> 200.1.3.2/32 200.1.2.2 0 0 20?
The route does not exist in the BGP routing table of Router A.


*> 9.1.1.0/24 0.0.0.0 0 0 ?

*> 9.1.1.1/32 0.0.0.0 0 0 ?
*> 127.0.0.0 0.0.0.0 0 0 ?
*> 127.0.0.1/32 0.0.0.0 0 0 ?
*> 200.1.2.0 0.0.0.0 0 0 ?
* 200.1.2.2 0 0 20?
*> 200.1.2.1/32 0.0.0.0 0 0 ?
* 200.1.2.2 0 0 20?
*> 200.1.2.2/32 0.0.0.0 0 0 ?
*> 200.1.3.0 200.1.2.2 0 0 20?
*> 200.1.3.2/32 200.1.2.2 0 0 20?
----End
Configuration Files
#

sysname RouterA
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
bgp 10
router-id 1.1.1.1
#
ipv4-family unicast
import-route direct
#
return

#
sysname RouterB
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
undo shutdown
ip address 200.1.3.1 255.255.255.0
#
bgp 20
router-id 2.2.2.2
#
ipv4-family unicast
import-route direct
peer 200.1.2.1 as-path-filter path-filter1 export
peer 200.1.3.2 as-path-filter path-filter2 export
#
ip as-path-filter path-filter1 deny _30_
ip as-path-filter path-filter1 permit .*
ip as-path-filter path-filter2 deny _10_
ip as-path-filter path-filter2 permit .*
#
return

#
sysname RouterC
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown

ip address 200.1.3.2 255.255.255.0

#
bgp 30
router-id 3.3.3.3
#
ipv4-family unicast
import-route direct
#
return
8.28.4 Example for Configuring MED Attributes to Control BGP

Route Selection
Multi_Exit Discriminator (MED) attributes can be used to control BGP route selection.
The MED attribute equals a metric used in an IGP, and is used to determine the optimal route
for traffic that enters an AS. When a BGP device obtains multiple routes to the same destination
address but with different next hops from EBGP peers, the route with the smallest MED value
is selected as the optimal route.
On the network shown in Figure 8-32, BGP is configured on all routers. router A is in AS 65008.
Router B and Router C are in AS 65009. Router A establishes EBGP connections with Router
B and Router C. Router B establishes an IBGP connection with Router C. Traffic sent by
Router A to destination 9.1.1.0 can enter AS 65009 through Router B or Router C. If the attributes
excluding the MED values of the routes advertised by Routers B and C to Router A are the same,
you can change the MED value of the route to be advertised by Router B or Router C to
Router A in order to determine the device through which traffic will enter AS 65009.
Figure 8-32 Networking diagram for configuring MED attributes of routes to control route
selection
POS2/0/0 RouterB
200.1.1.1/24
POS1/0/0 GE1/0/0
AS 65008 200.1.1.2/24 9.1.1.1/24
EBGP
IBGP
RouterA
AS 65009
POS2/0/0
200.1.2.2/24 EBGP GE1/0/0
9.1.1.2/24
POS2/0/0
200.1.2.1/24 RouterC

1. Establish EBGP connections between Router A and Router B and between Router A and
Router C, and establish an IBGP connection between Router B and Router C.
2. Apply a routing policy to increase the MED value of the route sent by Router B to
Router A so that Router A will send traffic to AS 65009 through Router C.
Data Preparation

l Router IDs 2.2.2.2 and 3.3.3.3, and AS numbers 65009 of Routers B and C respectively
l New MED value 100 of the route on Router B
Procedure
Step 2 Establish BGP connections.
[RouterA] bgp 65008
[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterB-bgp] quit
[RouterC] bgp 65009
[RouterC-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterC-bgp] quit

[RouterA] display bgp routing-table 9.1.1.0 24


From: 200.1.1.1 (2.2.2.2)

Direct Out-interface: Pos1/0/0
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, best, select, pre
255
200.1.1.1
200.1.2.1

From: 200.1.2.1 (3.3.3.3)
selected for router ID
Not advertised to any peers yet
The preceding command output shows that there are two valid routes to destination 9.1.1.0/24.
The route with the next-hop address of 200.1.1.1 is the optimal route because the router ID of
Router is smaller.
Step 3 Set MED attributes for routes.
# Apply a routing policy to set an MED value for the route advertised by Router B to Router A
(the default MED value of a route is 0).
[RouterB] route-policy policy10 permit node 10
[RouterB] bgp 65009
[RouterB-bgp] peer 200.1.1.2 route-policy policy10 export


From: 200.1.2.1 (3.3.3.3)
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, best, select, pre
255
200.1.1.1
200.1.2.1

From: 200.1.1.1 (2.2.2.2)
selected for MED

The preceding command output shows that the MED value of the route with the next-hop address
of 200.1.2.1 (Router B) is 100 and the MED value of the route with the next-hop address of
200.1.1.1 is 0. The route with the smaller MED value is selected.
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 200.1.1.2 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 200.1.2.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
#
return

#
sysname RouterB
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 200.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.2 enable
#
apply cost 100
#
return

#

sysname RouterC
#
undo shutdown
ip address 9.1.1.2 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 200.1.2.1 255.255.255.0
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.1 enable
#
return
8.28.5 Example for Configuring BGP Routing Policies

BGP routing policies can be used to flexibly control traffic on a complex network.
Figure 8-33 shows a simplified MPLS network that bears multiple L3VPN services such as
multimedia services, signaling services, and accounting services. Two sites, each of which has
two PEs accessing the core layer, are used as an example. MP-BGP is used to advertise inner
tags and VPNv4 routes between the PEs. Each PE establishes an MP-IBGP peer relationship
with the RR. Each PE sends BGP Update messages to the RR, The RR reflects Update messages
to the PEs excluding the senders of these messages through different planes.
NOTE
Figure 8-33 is a simplified networking diagram, in which there are two sites, one RR, and two planes (each
with three Ps). On the actual network, there are 14 sites with 28 PEs, and each plane has four Ps and two
RRs. Each RR needs to establish MP-IBGP connections with 28 PEs.

Figure 8-33 Networking diagram for configuring routing policies
P1 P3
Plane A
PE1 PE3
P5
VPN site 2
VPN site 1 10.22.1.0/24
10.21.1.0/24 RR
P2
PE4
PE2 P4
Plane
Plane B
B P6
On the network, the core layer has two planes. The Ps on each plane are fully meshed. Because
nodes on different planes need to be connected to provide a backup path, routing policies must
be deployed to ensure that one VPN flow passes through only one plane.
1. Configure different RDs for two PEs in the same site to ensure that each PE can receive
two routes from different PEs 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 the BGP
peers of the two PEs consider the advertised routes as two different routes. This is because
BGP-VPNv4 uses VPNv4 addresses that consist of IPv4 addresses and RDs.
2. Assign different community attributes to the routes advertised by PEs in plane A and the
routes advertised by PEs in plane B.
3. Set different local preferences for routes based on the community attributes of the routes
so that PEs in plane A always choose the routes advertised by remote PEs in plane A and
PEs in plane B always choose the routes advertised by remote PEs in plane B.
Data Preparation

Table 8-34 IP addresses of physical interfaces
Local Device Local Interface Remote Interface Peer Device

and Its IP Address and Its IP Address
P1 GE 1/0/0 GE 1/0/0 P3
20.1.1.1/30 20.1.1.2/30
P1 GE 2/0/0 GE 1/0/0 P5
20.1.2.1/30 20.1.2.2/30
P1 GE 3/0/0 GE 1/0/0 RR
20.1.3.1/30 20.1.3.2/30
P1 GE 3/1/0 GE 1/0/0 P2
20.1.4.1/30 20.1.4.2/30
P1 GE 3/2/0 GE 1/0/0 PE1

20.1.5.1/30 20.1.5.2/30
P2 GE 3/1/0 GE 1/0/0 P6
20.1.6.1/30 20.1.6.2/30
P2 GE 3/0/0 GE 1/0/0 P4
20.1.7.1/30 20.1.7.2/30
P2 GE 2/0/0 GE 2/0/0 RR
20.1.8.1/30 20.1.8.2/30
P2 GE 3/2/0 GE 1/0/0 PE2

20.1.9.1/30 20.1.9.2/30
P3 GE 2/0/0 GE 2/0/0 P5
20.1.10.1/30 20.1.10.2/30
P3 GE 3/0/0 GE 2/0/0 P4
20.1.11.1/30 20.1.11.2/30
P3 GE 3/1/0 GE 1/0/0 PE3

20.1.12.1/30 20.1.12.2/30
P4 GE 3/0/0 GE 3/0/0 P6
20.1.13.1/30 20.1.13.2/30
P4 GE 3/1/0 GE 1/0/0 PE4

20.1.14.1/30 20.1.14.2/30
P5 GE 3/0/0 GE 2/0/0 P6
20.1.15.1/30 20.1.15.2/30

Local Device Local Interface Remote Interface Peer Device

and Its IP Address and Its IP Address
PE1 GE 2/0/0 GE 2/0/0 PE2

20.1.16.1/30 20.1.16.2/30
PE3 GE 2/0/0 GE 2/0/0 PE4

20.1.17.1/30 20.1.17.2/30
Table 8-35 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 1.1.1.9/32 P2 2.2.2.9/32
P3 3.3.3.9/32 P4 4.4.4.9/32
P5 5.5.5.9/32 P6 6.6.6.9/32
PE1 7.7.7.9/32 PE2 8.8.8.9/32
PE3 9.9.9.9/32 PE4 10.10.10.9/32
RR 11.11.11.9/32
Table 8-36 BGP parameter values
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 value of

community attribute 65000:100 is set to 200.
Plane B: The local preference value of
community attribute 65000:200 is set to 200.
NOTE
By default, the BGP local preference value 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 community1

BGP Parameter Value
BGP peer group name client
Procedure
Step 1 Configure a name for each device and an IP address for each interface.
For detailed configurations, see configuration files in this example.
Step 2 Configure an IGP.
In this example, IS-IS is used as an IGP. For detailed configurations, see configuration files in
this example.
After the configurations are complete, run the display ip routing-table command. The command
output shows 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.
# Configure PE1. Configurations of other PEs are the same as that of PE1, and are not provided
here.
[PE1] bgp 65000
[PE1-bgp] peer 11.11.11.9 as-number 65000
[PE1-bgp] peer 11.11.11.9 connect-interface LoopBack0
[PE1-bgp] ipv4-family unicast
[PE1-bgp-af-ipv4] undo peer 11.11.11.9 enable
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 11.11.11.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# 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 7.7.7.9 group client
[RR-bgp-af-vpnv4] peer client reflect-client
[RR-bgp-af-vpnv4] quit
[RR-bgp] quit
NOTE
The undo policy vpn-target command needs to be run 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, the RR performs
VPN-target-based filtering on received VPN IPv4 routes. The matching routes are added to the VPN routing
table, and the other routes are discarded. In this example, no VPN instance is configured on the RR. As a
result, if VPN-target-based filtering is enabled, all the received VPNv4 routes will be discarded.

After the configurations are complete, run the display bgp vpnv4 all peer command on the RR.
The command output shows that the RR has established MP-IBGP connections with all PEs.
[RR] display bgp vpnv4 all peer
PrefRcv
7.7.7.9 4 65000 79 82 0 00:01:31 Established
0
8.8.8.9 4 65000 42 66 0 00:01:16 Established
0
9.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 routing policies.

NOTE
The configurations of PE1, PE2, and the RR are used as an example. The configurations of PE3 and PE4
are the same as the configurations of PE1 and PE2, and are not provided here.
# Configure a routing policy on PE1 so that BGP VPNv4 routes advertised by PEs in plane A
to the RR can carry community attribute 65000:100.
[PE1] route-policy comm permit node 10
[PE1-route-policy] apply community 65000:100
[PE1-route-policy] quit
# Configure a routing policy on PE2 so that BGP VPNv4 routes advertised by PEs in plane B
to the RR can carry community attribute 65000:200.
[PE2] route-policy com permit node 10
[PE2-route-policy] apply community 65000:200
# On PE1, apply the routing policy to the advertised BGP VPNv4 routes so that the community
attribute can be advertised to the RR.
[PE1] bgp 65000
[PE1-bgp-af-vpnv4] peer 11.11.11.9 route-policy comm export
[PE1-bgp-af-vpnv4] peer 11.11.11.9 advertise-community
[PE1-bgp] quit
# On PE2, apply the routing policy to the advertised BGP VPNv4 routes so that the community
attribute can be advertised to the RR.
[PE2] bgp 65000
[PE2-bgp-af-vpnv4] peer 11.11.11.9 route-policy comm export
[PE2-bgp-af-vpnv4] peer 11.11.11.9 advertise-community
[PE2-bgp] quit
# 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
[RR-bgp-af-vpnv4] quit
[RR-bgp] quit

# Configure a community filter on PE1.

[PE1] ip community-filter basic community1 permit 65000:100
# Configure a community filter on PE2.

[PE2] ip community-filter basic community1 permit 65000:200
# On PE1, configure a routing policy to set the local preference value to 200 for routes with
community attribute 65000:100.
[PE1] route-policy local_pre permit node 10
[PE1-route-policy] if-match community-filter community1
[PE1-route-policy] apply local-preference 200
# On PE2, configure a routing policy to set the local preference value to 200 for routes with
community attribute 65000:200.
[PE2] route-policy local_pre permit node 10
[PE2-route-policy] if-match community-filter community1
[PE2-route-policy] apply local-preference 200
# On PE1, apply the routing policy to the imported BGP VPNv4 route so that PEs in plane A
prefer the route advertised by remote PEs in plane A.
[PE1] bgp 65000
[PE1-bgp-af-vpnv4] peer 11.11.11.9 route-policy local_pre import
[PE1-bgp] quit
# On PE2, apply the routing policy to the imported BGP VPNv4 route so that PEs in plane B
prefer the route advertised by remote PEs in plane B.
[PE2] bgp 65000
[PE2-bgp-af-vpnv4] peer 11.11.11.9 route-policy local_pre import
[PE2-bgp] quit
NOTE
After the configurations are complete, you need to configure MPLS, establish tunnels, configure the MPLS
L3VPN function, and connect the PEs to CEs. For detailed configurations, see configuration files in this example.

Run the display bgp vpnv4 all routing-table community command on a PE to view information
about VPNv4 routes with community attributes In the following example, the display on PE1
and PE2 is used.
[PE1] display bgp vpnv4 all routing-table community

Total Number of Routes from all PE: 2

Route Distinguisher: 65000:10001012

*> 10.22.1.0/24 9.9.9.9 0 200 65000:100

* 10.10.10.9 0 100 65000:200
VPN-Instance NGN_Media, router ID 7.7.7.9:

*>i 10.22.1.0/24 9.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

* 9.9.9.9 0 100 65000:100
VPN-Instance NGN_Media, router ID 7.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

* 9.9.9.9 0 100 0 65000:100
Run the display ip routing-table vpn-instance vpna 10.22.1.0 24 command on PE1. The
command output shows that the next hop of route 10.22.1.0/24 is PE3. This means that PE1
prefers the route advertised by PE3.
[PE1] display ip routing-table vpn-instance NGN_Media 10.22.1.0 24
------------------------------------------------------------------------------
Routing Tables: NGN_Media
10.22.1.0/24 IBGP 255 0 RD 9.9.9.9 GigabitEthernet1/0/0
----End
Configuration Files
#
sysname P1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
isis 64

network-entity 49.0091.0100.0100.1009.00
#
undo shutdown
ip address 20.1.1.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.2.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.3.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.4.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.5.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
isis enable 64
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0200.2009.00
#
undo shutdown
ip address 20.1.4.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.8.1 255.255.255.252
isis enable 64
mpls

mpls ldp
#
undo shutdown
ip address 20.1.7.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.6.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.9.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
isis enable 64
#
return
#
sysname P3
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0300.3009.00
#
undo shutdown
ip address 20.1.1.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.10.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.11.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.12.1 255.255.255.252
isis enable 64
mpls

mpls ldp
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
isis enable 64
#
return
#
sysname P4
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0400.4009.00
#
undo shutdown
ip address 20.1.7.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.11.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.13.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.14.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
isis enable 64
#
return
#
sysname P5
#
mpls lsr-id 5.5.5.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0500.5009.00
#

undo shutdown
ip address 20.1.2.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.10.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.15.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface LoopBack0
ip address 5.5.5.9 255.255.255.255
isis enable 64
#
return
#
sysname P6
#
mpls lsr-id 6.6.6.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0600.6009.00
#
undo shutdown
ip address 20.1.6.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.15.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.13.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
interface LoopBack0
ip address 6.6.6.9 255.255.255.255
isis enable 64
#
return

#
sysname PE1
#
ip vpn-instance NGN_Media
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
ip vpn-instance NGN_Signaling
#
mpls lsr-id 7.7.7.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0700.7009.00
#
undo shutdown
ip address 20.1.5.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.16.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
interface GigabitEthernet3/0/0.10
vlan-type dot1q 10
ip binding vpn-instance NGN_Media
ip address 10.21.1.73 255.255.255.252
#
vlan-type dot1q 11
ip binding vpn-instance NGN_Signaling
ip address 10.21.1.77 255.255.255.252
#
vlan-type dot1q 12
ip binding vpn-instance NGN_Other
ip address 10.21.1.81 255.255.255.252
#
interface LoopBack0
ip address 7.7.7.9 255.255.255.255
isis enable 64
#
bgp 65000
peer 11.11.11.9 as-number 65000
peer 11.11.11.9 connect-interface LoopBack0
#
ipv4-family unicast

undo peer 11.11.11.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 11.11.11.9 route-policy local_pre import
peer 11.11.11.9 route-policy comm export
peer 11.11.11.9 advertise-community
#
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 community1
#
ip community-filter basic community1 permit 65000:100
#
return

#
sysname PE2
#
#
mpls lsr-id 8.8.8.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0800.8009.00
#
undo shutdown
ip address 20.1.9.2 255.255.255.252
isis enable 64
mpls
mpls ldp

#
undo shutdown
ip address 20.1.16.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
vlan-type dot1q 10
ip address 10.21.1.13 255.255.255.252
#
vlan-type dot1q 11
ip address 10.21.1.17 255.255.255.252
#
vlan-type dot1q 12
ip address 10.21.1.21 255.255.255.252
#
interface LoopBack0
ip address 8.8.8.9 255.255.255.255
isis enable 64
#
bgp 65000
peer 11.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
#
#
mpls lsr-id 9.9.9.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.0900.9009.00
#
undo shutdown
ip address 20.1.12.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.17.1 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
vlan-type dot1q 10
ip address 10.22.1.73 255.255.255.252
#
vlan-type dot1q 11
ip address 10.22.1.77 255.255.255.252
#
vlan-type dot1q 12
ip address 10.22.1.81 255.255.255.252
#
interface LoopBack0
ip address 9.9.9.9 255.255.255.255
isis enable 64
#
bgp 65000
peer 11.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
#
#
mpls lsr-id 10.10.10.9
mpls
#
mpls ldp
#
isis 64
network-entity 49.0091.0100.1001.0009.00
#
undo shutdown

ip address 20.1.14.2 255.255.255.252

isis enable 64
mpls
mpls ldp
#
undo shutdown
ip address 20.1.17.2 255.255.255.252
isis enable 64
mpls
mpls ldp
#
#
vlan-type dot1q 10
ip address 10.22.1.13 255.255.255.252
#
vlan-type dot1q 11
ip address 10.22.1.17 255.255.255.252
#
vlan-type dot1q 12
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 11.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
#
isis 64
network-entity 49.0091.0100.1101.1009.00
#
undo shutdown
ip address 20.1.3.2 255.255.255.252
isis enable 64
#
undo shutdown
ip address 20.1.8.2 255.255.255.252
isis enable 64
#
interface LoopBack0
ip address 11.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 7.7.7.9 enable
peer 7.7.7.9 group client
peer 8.8.8.9 enable
peer 9.9.9.9 enable
#
return
8.28.6 Example for Configuring BGP Route Reflectors

With BGP RRs, full-mesh connections do not need to be established between IBGP peers,
simplifying the network structure, reducing the configuration workload, and facilitating network
maintenance.

On a large-scale network, multiple routers that run BGP are deployed within an AS. These
routers need to use BGP to advertise routes to each other. To meet this need, IBGP peer
relationships need to be set up between all the routers. However, establishing full-mesh logical
relationships between all routers imposes a heavy burden on configurations and increases the
link cost on routers. In addition, the full-mesh logical connections are difficult to maintain.
Customers require a method that can simplify network configurations, reduce the overhead on
routers, and ensure efficient route advertisement.
The use of RRs meets all these requirements. As shown in Figure 8-34, AS 65010 is divided
into two clusters, Cluster1 and Cluster2. Router B is configured as an RR in Cluster1, and
Router D and Router E are its clients. Router C is configured as an RR in Cluster2, and
Router F, Router G, and Router H are its clients. Router A is the non-client of Router B and
Router C. Router B and Router C are non-clients of each other.
Figure 8-34 Networking diagram for BGP RR configurations
GE3/0/0
9.1.1.1/24
AS 65010
POS1/0/0 POS2/0/0
RouterA POS2/0/0
POS1/0/0 POS2/0/0
RouterB POS4/0/0 POS1/0/0 POS5/0/0
POS2/0/0 RouterC POS4/0/0

RouterH
POS3/0/0
Cluster1 POS3/0/0 Cluster2
POS1/0/0 POS3/0/0
POS1/0/0 POS1/0/0
POS2/0/0 POS2/0/0
RouterD RouterE RouterF RouterG
RouterA GE 3/0/0 9.1.1.1/24 Router C POS 4/0/0 10.1.8.1/24
POS 1/0/0 10.1.1.2/24 POS 5/0/0 10.1.9.1/24
POS 2/0/0 10.1.3.2/24 Router D POS 1/0/0 10.1.4.2/24
Router B POS 1/0/0 10.1.1.1/24 POS 2/0/0 10.1.6.1/24
POS 2/0/0 10.1.4.1/24 Router E POS 2/0/0 10.1.6.2/24
POS 3/0/0 10.1.5.1/24 POS 3/0/0 10.1.5.2/24
POS 4/0/0 10.1.2.1/24 Router F POS 1/0/0 10.1.7.2/24
Router C POS 1/0/0 10.1.2.2/24 Router G POS 1/0/0 10.1.8.2/24
POS 2/0/0 10.1.3.1/24 Router H POS 2/0/0 10.1.9.2/24

POS 3/0/0 10.1.7.1/24
1. Configure IBGP connections between the clients and their RRs, and between the non-clients
and their RRs. Add the clients in each cluster to the same peer group to configure them in
batches (this can simplify configurations).
2. Configure the RR functionality on Router B and Router C and specify their clients, and
configure Router B and Router C to advertise routes to their clients and non-clients.
3. Disable route reflection between clients in Cluster1 to reduce the link cost because an IBGP
relationship is set up between Router D and Router E.
Data Preparation
l AS number (65010 is used as an example here.)

l Router ID of each Router (1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5, 6.6.6.6, 7.7.7.7, and
8.8.8.8 are used as an example for Router A, Router B, Router C, Router D, Router E,
Router F, Router G, and Router H here.)
l ID of each cluster (1 is used as an example for the cluster where Router B resides, and 2 is
used as an example for the cluster where Router C resides.)
Procedure
Assign an IP address to each interface as shown in Figure 8-34. For details about the
configuration, see the following configuration files.
Step 2 Configure IBGP peer relationships between clients and RRs, and between non-clients and RRs.
For details about the configuration, see the following configuration files.
Step 3 Configure RRs.
[RouterB] bgp 65010
[RouterB-bgp] group in_rr internal
[RouterB-bgp] peer 10.1.4.2 group in_rr
[RouterB-bgp] peer 10.1.5.2 group in_rr
[RouterB-bgp-af-ipv4] peer in_rr reflect-client
[RouterB-bgp-af-ipv4] undo reflect between-clients
[RouterB-bgp-af-ipv4] reflector cluster-id 1
[RouterB-bgp] quit

[RouterC] bgp 65010

[RouterC-bgp] group in_rr internal
[RouterC-bgp] peer 10.1.7.2 group in_rr
[RouterC-bgp-af-ipv4] peer in_rr reflect-client
[RouterC-bgp-af-ipv4] reflector cluster-id 2
[RouterC-bgp] quit
# View the routing table of Router D.

[RouterD] display bgp routing-table 9.1.1.0
From: 10.1.4.1 (2.2.2.2)
Relay IP Out-Interface:
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255
Originator: 1.1.1.1
You can see that Router D has learned the route advertised by Router A from Router B. For
details, see the Originator and Cluster_ID attributes of the route.
----End
Configuration Files
#
sysname RouterA
#
ip address 9.1.1.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.3.2 255.255.255.0
#
bgp 65010
router-id 1.1.1.1
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.4.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
ip address 10.1.5.1 255.255.255.0
#
interface Pos4/0/0
link-protocol ppp
ip address 10.1.2.1 255.255.255.0
#
bgp 65010
router-id 2.2.2.2
group in_rr internal
peer 10.1.4.2 group in_rr
#
ipv4-family unicast
reflector cluster-id 1
peer in_rr enable
peer in_rr reflect-client
#
return

#
sysname RouterC
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.2.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.3.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
ip address 10.1.7.1 255.255.255.0
#
interface Pos4/0/0
link-protocol ppp
ip address 10.1.8.1 255.255.255.0
#
interface Pos5/0/0
link-protocol ppp
ip address 10.1.9.1 255.255.255.0

#
bgp 65010
router-id 3.3.3.3
group in_rr internal
#
ipv4-family unicast
reflector cluster-id 2
peer in_rr enable
peer in_rr reflect-client
#
return

#
sysname RouterD
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.4.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.6.1 255.255.255.0
#
bgp 65010
router-id 4.4.4.4
#
ipv4-family unicast
#
return
NOTE
The configuration files of other routers are similar to the configuration file of Router D and are not provided
in this document.
8.28.7 Example for Configuring BGP Confederations

BGP confederations can be used to reduce the number of IBGP connections.
Multiple devices are deployed in a carrier's AS and IBGP full mesh must be implemented in the
AS. If every two devices establish IBGP connections, a large number of IBGP connections will

be established in the AS, increasing operation and maintenance costs. BGP confederations can
be configured to address this problem.
On the network shown in Figure 8-35, IBGP full-mesh connections must be established between
all the devices in AS 200 to ensure link connectivity. It is costly to establish a full-mesh network
because there are multiple BGP devices in AS 200. Confederations can be configured in AS 200
to reduce the number of IBGP connections to be established. After confederations are configured,
AS 200 is divided into three sub-ASs: AS 65001, AS 65002, and AS 65003. AS 65001 establishes
EBGP connections with AS 65002 and AS 65003. The three routers in AS 65001 establish IBGP
full-mesh connections with each other. As a result, the number of IBGP connections in AS 200
is reduced, and operation and maintenance costs are reduced.
Figure 8-35 Networking diagram for configuring confederations
AS 65002 AS 65003
POS1/0/0
RouterB 20.1.2.2/24
POS1/0/0
20.1.1.2/24 RouterC
POS3/0/0
GE2/0/0 POS2/0/0
9.1.1.1/24 POS1/0/0 20.1.1.1/24
20.1.2.1/24 AS 65001
200.1.1.2/24 POS4/0/0 RouterD
RouterA 20.1.3.1/24
POS1/0/0
POS1/0/0 POS5/0/0 20.1.3.2/24
RouterF 200.1.1.1/24 20.1.4.1/24 POS2/0/0
AS 100 20.1.5.1/24
POS1/0/0
20.1.4.2/24
POS2/0/0
20.1.5.2/24
AS 200
RouterE
1. Configure a BGP confederation on each router, divide AS 200 into three sub-ASs: AS
65001, AS 65002, and AS 65003, and configure AS 65001 to establish EBGP connections
with AS 65002 and AS 65003 so that the sub-ASs can communicate with each other.
2. Establish IBGP full-mesh connections between the devices in AS 65001 so that the devices
can communicate with each other.
3. Establish an EBGP connection between AS 100 and AS 200 so that the two ASs can
Data Preparation

l Router IDs 1.1.1.1, 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5, and 6.6.6.6 of Routers A, B, C, D, E,
and F respectively
l AS numbers 100 and 200, and sub-AS numbers 65001, 65002, and 65003 of AS number
200
Procedure
Step 2 Configure BGP confederations.
[RouterA] bgp 65001
[RouterA-bgp] confederation id 200
[RouterA-bgp] confederation peer-as 65002 65003
[RouterA-bgp-af-ipv4] peer 20.1.1.2 next-hop-local
[RouterA-bgp] quit
[RouterB] bgp 65002
[RouterB-bgp] confederation id 200
[RouterB-bgp] confederation peer-as 65001
[RouterB-bgp] quit
[RouterC] bgp 65003
[RouterC-bgp] confederation id 200
[RouterC-bgp] confederation peer-as 65001
[RouterC-bgp] quit
Step 3 Establish IBGP connections between the devices in AS 65001.
[RouterA] bgp 65001
[RouterA-bgp] quit
[RouterD] bgp 65001
[RouterD-bgp] confederation id 200
[RouterD-bgp] quit

[RouterE] bgp 65001
[RouterE-bgp] router-id 5.5.5.5
[RouterE-bgp] confederation id 200
[RouterE-bgp] quit
Step 4 Establish an EBGP connection between AS 100 and AS 200.
[RouterA] bgp 65001
[RouterA-bgp] quit
# Configure Router F.
[RouterF] bgp 100
[RouterF-bgp] router-id 6.6.6.6
[RouterF-bgp] peer 200.1.1.1 as-number 200
[RouterF-bgp] ipv4-family unicast
[RouterF-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterF-bgp-af-ipv4] quit
[RouterF-bgp] quit
# View information about the BGP routing table of Router B and detailed information about
route 9.1.1.0/24.


*>i 9.1.1.0/24 20.1.1.1 0 100 0 (65001) 100i


From: 20.1.1.1 (1.1.1.1)
AS-path (65001) 100, origin igp, MED 0, localpref 100, pref-val 0, valid, external-
The command output shows that Router B can receive routes of other ASs from an EBGP peer.
# View the BGP routing table of Router D.





*>i 9.1.1.0/24 20.1.3.1 0 100 0 100i

[RouterD] display bgp routing-table 9.1.1.0
From: 20.1.3.1 (1.1.1.1)
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal-
The command output shows that Router D can receive routes of other ASs from IBGP peers in
the same confederation.
Confederations ensure network connectivity, reduce the number of IBGP connections in ASs,
and reduce network resource consumption.
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 200.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 20.1.1.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
undo shutdown
ip address 20.1.2.1 255.255.255.0
#
interface Pos4/0/0
link-protocol ppp
undo shutdown
ip address 20.1.3.1 255.255.255.0
#
interface Pos5/0/0
link-protocol ppp
undo shutdown
ip address 20.1.4.1 255.255.255.0
#
bgp 65001
router-id 1.1.1.1
confederation id 200
confederation peer-as 65002 65003


#
ipv4-family unicast
peer 20.1.1.2 next-hop-local
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 20.1.1.2 255.255.255.0
#
bgp 65002
router-id 2.2.2.2
confederation peer-as 65001
#
ipv4-family unicast
#
return
NOTE
The configuration file of Router C is similar to that of Router B, and is not provided here.
#
sysname RouterD
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 20.1.3.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 20.1.5.1 255.255.255.0
#
bgp 65001
router-id 4.4.4.4
#
ipv4-family unicast


#
return
NOTE
The configuration file of Router E is similar to that of Router D, and is not provided here.
l Configuration file of Router F.
#
sysname RouterF
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
interface Pos1/0/0
link-protocol ppp
undo shutdown
ip address 200.1.1.2 255.255.255.0
#
bgp 100
router-id 6.6.6.6
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return
8.28.8 Example for Configuring BGP Community Attributes for

Routes
Community attributes can be used to control BGP route selection.
Enterprises A, B, and C belong to different ASs. Enterprise B's network communicates with the
networks of the other two enterprises using EBGP. Due to the competition relationship with
enterprise C, enterprise A hopes that the routes it advertises to enterprise B are transmitted only
in enterprise B, not to enterprise C. Community attributes can be configured for routes to be
advertised by enterprise A to enterprise B in order to address this problem.
On the network shown in Figure 8-36, Router B establishes EBGP connections with Routers A
and C. To ensure that routes imported by Router A are transmitted only AS 20 after being
advertised to Router B, you can configure the No_Export community attribute for BGP routes
to be advertised by Router A so that the BGPs are sent only to AS 20.

Figure 8-36 Networking diagram for configuring community attributes for BGP routes
GE1/0/0
AS 10 9.1.1.1/24
POS2/0/0
200.1.2.1/24
RouterA
EBGP
POS2/0/0 POS3/0/0
200.1.2.2/24 EBGP 200.1.3.2/24
POS3/0/0
200.1.3.1/24 RouterC
RouterB
AS 20 AS 30
1. Establish EBGP connections between Routers A and B and between Routers B and C so
that the ASs can communicate with each other.
2. Use a routing policy on Router A to configure the No_Export community attribute for BGP
routes to be advertised by Router A to Router B so that the routes are transmitted only in
AS 20 and not to other ASs.
Data Preparation

l Router ID 2.2.2.2 and AS number 20 of Router B
l Router ID 3.3.3.3 and AS number 30 of Router C
Procedure
Step 2 Establish EBGP connections.
[RouterA] bgp 10
[RouterA-bgp] quit

[RouterB] bgp 20
[RouterB-bgp] quit
[RouterC] bgp 30
[RouterC-bgp] quit
# On Router B, view detailed information about route 9.1.1.0/24.


From: 200.1.2.1 (1.1.1.1)
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select, active,
pre 255
200.1.2.1
200.1.3.2
The preceding command output shows that Router B advertises the received BGP route to
Router C in AS 30.
# View the BGP routing table of Router C.


*> 9.1.1.0/24 200.1.3.1 0 20 10i
The preceding command output shows that Router C has learned route 9.1.1.0/24 from Router
B.
Step 3 Configure a BGP community attribute.
# Configure a routing policy on Router A to prevent BGP routes to be advertised by Router A
to Router B from being advertised to any other AS.
[RouterA] route-policy comm_policy permit node 10
[RouterA-route-policy] apply community no-export
[RouterA-route-policy] quit
# Apply the routing policy.

[RouterA] bgp 10
[RouterA-bgp-af-ipv4] peer 200.1.2.2 route-policy comm_policy export

[RouterA-bgp-af-ipv4] peer 200.1.2.2 advertise-community
# On Router B, view detailed information about route 9.1.1.0/24.


From: 200.1.2.1 (1.1.1.1)
Community:no-export
AS-path 10, origin igp, MED 0, pref-val 0, valid, external, best, select, active,
pre 255
The preceding command output shows that route 9.1.1.0/24 carries the configured community
attribute and Router B does not advertise this route to any other AS.
----End
Configuration Files
#
sysname RouterA
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
bgp 10
router-id 1.1.1.1
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 200.1.2.2 route-policy comm_policy export
#
route-policy comm_policy permit node 10
apply community no-export
#
return

#
sysname RouterB
#
interface Pos2/0/0
link-protocol ppp
undo shutdown
ip address 200.1.2.2 255.255.255.0
#
interface Pos3/0/0

link-protocol ppp
undo shutdown
ip address 200.1.3.1 255.255.255.0
#
bgp 20
router-id 2.2.2.2
#
ipv4-family unicast
#
return

#
sysname RouterC
#
interface Pos3/0/0
link-protocol ppp
undo shutdown
ip address 200.1.3.2 255.255.255.0
#
bgp 30
router-id 3.3.3.3
#
ipv4-family unicast
#
return
8.28.9 Example for Configuring Prefix-based BGP ORF

Prefix-based BGP outbound route filtering (ORF) is used to implement on-demand BGP route
advertisement.
On the network shown in Figure 8-37, Routers A and B are in AS 100. Routers C, D, and E are
in AS 200. Router A requires Router C to send only routing information matching the import
policy of Router A, but Router C does not want to maintain a separate export policy for
Router A. Prefix-based BGP ORF can be configured in such a situation.

Figure 8-37 Networking diagram for configuring prefix-based BGP ORF
Loopback1
4.4.4.4/32
RouterD
Loopback1 Loopback1 Loopback1

2.2.2.2/32 1.1.1.1/32 3.3.3.3/32 POS1/0/0
POS1/0/0 20.3.1.1/30
POS2/0/0
20.2.1.1/30
20.3.1.2/30
POS2/0/0 POS1/0/0 POS1/0/0
POS3/0/0
20.2.1.2/30 20.1.1.1/30 20.1.1.2/30
20.4.1.2/30
RouterB RouterA
RouterC
AS100
POS1/0/0
20.4.1.1/30
RouterE
Loopback1
AS200 5.5.5.5/32
1. Establish an EBGP peer relationship between Routers A and C, and establish IBGP peer
relationships between Routers A and B, between Routers C and D, and between Routers C
and E.
2. Configure a prefix-based import policy on Router A, and enable prefix-based BGP ORF
on Routers A and C.
Data Preparation
l Router IDs 1.1.1.1 and 2.2.2.2 and AS number 100 of Routers A and B respectively
l Router IDs 3.3.3.3, 4.4.4.4, and 5.5.5.5 and AS number 200 of Routers C, D, and E
respectively
Procedure
Configure an IP address for each interface, as shown in Figure 8-37. For details on configuration
procedures, see corresponding configuration files.
Step 2 Establish BGP peer relationships.

[RouterA] bgp 100
[RouterA-bgp-af-ipv4] import-route direct
[RouterA-bgp] quit
[RouterB] bgp 100
[RouterB-bgp] quit
[RouterC] bgp 200
[RouterC-bgp-af-ipv4] import-route direct
[RouterC-bgp] quit
[RouterD] bgp 200
[RouterD-bgp] quit
[RouterE] bgp 200
[RouterE-bgp] router-id 5.5.5.5
[RouterE-bgp] quit
Step 3 Configure a prefix-based import policy on Router A.

[RouterA] ip ip-prefix 1 index 10 permit 20.3.1.0 24 less-equal 32
[RouterA] bgp 100
[RouterA-bgp] peer 20.1.1.2 ip-prefix 1 import
[RouterA-bgp] quit
# View routing information sent by Router C.

[RouterC] display bgp routing-table peer 20.1.1.1 advertised-routes


*> 3.3.3.3/32 20.1.1.2 0 0 200?

*> 20.1.1.0/30 20.1.1.2 0 0 200?

*> 20.1.1.1/32 20.1.1.2 0 0 200?

*> 20.3.1.0/30 20.1.1.2 0 0 200?
*> 20.3.1.1/32 20.1.1.2 0 0 200?
*> 20.4.1.0/30 20.1.1.2 0 0 200?
*> 20.4.1.1/32 20.1.1.2 0 0 200?
# View routing information accepted by Router A.

[RouterA] display bgp routing-table peer 20.1.1.2 received-routes


*> 20.3.1.0/30 20.1.1.2 0 0 200?

*> 20.3.1.1/32 20.1.1.2 0 0 200?
When prefix-based BGP ORF is not enabled, Router C sends seven routes, but Router A accepts
only two routes because Router A applies the prefix-based import policy to the seven routes.
Step 4 Enable prefix-based BGP ORF.
[RouterA] bgp 100
[RouterA-bgp] peer 20.1.1.2 capability-advertise orf ip-prefix both
[RouterA-bgp] quit
[RouterC] bgp 200
[RouterC-bgp] peer 20.1.1.1 capability-advertise orf ip-prefix both
[RouterC-bgp] quit
# View prefix-based BGP ORF negotiation information on Router A.

[RouterA] display bgp peer 20.1.1.2 verbose

Type: EBGP link
Update-group ID: 1
BGP current event: RecvRouteRefresh
Peer supports bgp outbound route filter capability
Support Address-Prefix: IPv4-UNC address-family, rfc-compatible, both


Update messages 1
Open messages 1
Refresh messages 1
Update messages 5
Open messages 2
Refresh messages 1
Outbound route filter capability has been enabled
Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
Multi-hop ebgp has been enabled
No import update filter list
No export update filter list
Import prefix list is: 1
No export prefix list
No import route policy
No export route policy
No import distribute policy
No export distribute policy
# View routing information sent by Router C.

[RouterC] display bgp routing-table peer 20.1.1.1 advertised-routes


*> 20.3.1.0/30 20.1.1.2 0 0 200?

*> 20.3.1.1/32 20.1.1.2 0 0 200?
# View routing information accepted by Router A.

[RouterA] display bgp routing-table peer 20.1.1.2 received-routes


*> 20.3.1.0/30 20.1.1.2 0 0 200?

*> 20.3.1.1/32 20.1.1.2 0 0 200?

After BGP ORF is enabled, Router C sends only two routes based on the prefix-based import
policy provided by Router A, and Router A accepts only the two routes.
----End
Configuration Files
#
sysname
RouterA
#
interface
Pos1/0/0
link-protocol
ppp
ip address 20.2.1.2
255.255.255.252
#
interface
Pos1/0/1
link-protocol
ppp
ip address 20.1.1.1
255.255.255.252
#
interface
LoopBack1
ip address 1.1.1.1
255.255.255.255
#
bgp
100
router-id
1.1.1.1
peer 20.1.1.2 as-number
200
100
#
ipv4-family
unicast
undo
synchronization
import-route
direct
peer 20.1.1.2
enable
peer 20.1.1.2 ip-prefix 1
import
peer 20.1.1.2 capability-advertise orf ip-prefix
both
peer 20.2.1.1
enable
#
ip ip-prefix 1 index 10 permit 20.3.1.0 24 greater-equal 24 less-equal
32
#
return

#
sysname
RouterB

#
interface
Pos1/0/0
link-protocol
ppp
ip address 20.2.1.1
255.255.255.252
#
interface
LoopBack1
ip address 2.2.2.2
255.255.255.255
#
bgp
100
router-id
2.2.2.2
100
#
ipv4-family
unicast
undo
synchronization
peer 20.2.1.2
enable
#
return

#
sysname
RouterC
#
interface
Pos1/0/0
link-protocol
ppp
ip address 20.3.1.2
255.255.255.252
#
interface
Pos1/0/1
link-protocol
ppp
ip address 20.1.1.2
255.255.255.252
#
interface
Pos1/0/3
link-protocol
ppp
ip address 20.4.1.2
255.255.255.252
#
interface
LoopBack1
ip address 3.3.3.3
255.255.255.255
#
bgp
200
router-id
3.3.3.3
100


200
200
#
ipv4-family
unicast
undo
synchronization
import-route
direct
peer 20.1.1.1
enable
peer 20.1.1.1 capability-advertise orf ip-prefix
both
peer 20.3.1.1
enable
peer 20.4.1.1
enable
#
return

#
sysname
RouterD
#
interface
Pos1/0/0
link-protocol
ppp
ip address 20.3.1.1
255.255.255.252
#
interface
LoopBack1
ip address 4.4.4.4
255.255.255.255
#
bgp
200
router-id
4.4.4.4
200
#
ipv4-family
unicast
undo
synchronization
peer 20.3.1.2
enable
#
return

#
sysname
RouterE
#
interface
Pos1/0/1
link-protocol
ppp
ip address 20.4.1.1

255.255.255.252
#
interface
LoopBack1
ip address 5.5.5.5
255.255.255.255
#
bgp
200
router-id
5.5.5.5
200
#
ipv4-family
unicast
undo
synchronization
peer 20.4.1.2
enable
#
return
8.28.10 Example for Configuring BGP Load Balancing

Proper use of BGP load balancing better utilizes network resources and reduces network
congestion.
On the network shown in Figure 8-38, BGP is configured on all routers. router A is in AS 100.
routers B and C are in AS 300. router D is in AS 200. Router A establishes EBGP connections
with Routers B and C and Router D establishes EBGP connections with Routers B and C.
Router A has two BGP routes destined for destination 8.1.1.0/24. Traffic can reach destination
8.1.1.0/24 through either Router B or Router C. BGP load balancing can be configured to better
utilize network resources and reduce network congestion.

Figure 8-38 Networking diagram for configuring BGP load balancing
RouterA AS100
POS1/0/0 POS2/0/0
200.1.1.1/24 200.1.2.1/24
POS1/0/0 POS2/0/0
200.1.1.2/24 200.1.2.2/24
RouterB RouterC
AS300
POS2/0/0 POS1/0/0
200.1.3.2/24 200.1.4.2/24
POS2/0/0 POS1/0/0
200.1.3.1/24 200.1.4.1/24
GE3/0/0
AS200 8.1.1.1/24
RouterD
Precautions
When configuring BGP load balancing, note the following point:
l Load balancing can be implemented by configuring BGP attributes, for example, ignoring
the comparison of IGP metrics. Ensure that no routing loops occur when configuring BGP
attributes to implement load balancing.
1. Establish EBGP connections between Routers A and B and between Routers A and C to
enable ASs to communicate with each other using BGP.
2. Establish EBGP connections between Routers D and B and between Routers D and C to
enable ASs to communicate with each other using BGP.
3. Configuring load balancing on Router A so that Router A can send traffic to Router D
through either Router B or Router C.

Data Preparation

l Router IDs 2.2.2.2 and 3.3.3.3, and AS numbers 300 of Routers B and C respectively
l Router ID 4.4.4.4 and AS number 200 of Router D
l Number of BGP routes that implement load balancing (two BGP routes implement load
balancing in this example)
Procedure
Step 2 Establish BGP connections.
[RouterA] bgp 100
[RouterA-bgp] quit
[RouterB] bgp 300
[RouterB-bgp] quit
[RouterC] bgp 300
[RouterC-bgp] quit
[RouterD] bgp 200
[RouterD-bgp-af-ipv4] network 8.1.1.0 255.255.255.0
[RouterD-bgp] quit


Paths : 2 available, 1 best, 1 select
From: 200.1.1.2 (2.2.2.2)


AS-path 200 300, origin igp, pref-val 0, valid, external, best, select, pre 255
200.1.1.2
200.1.2.2

From: 200.1.2.2 (3.3.3.3)
AS-path 200 300, origin igp, pref-val 0, valid, external, pre 255, not selected
for router ID
The preceding command output shows that there are two valid routes from Router A to
destination 8.1.1.0/24. The route with the next-hop address of 200.1.1.2 is the optimal route
because the router ID of Router B is smaller.
Step 3 Configure BGP load balancing.
# Configure load balancing on Router A.

[RouterA] bgp 100
[RouterA-bgp-af-ipv4] maximum load-balancing 2
[RouterA-bgp] quit


Paths : 2 available, 1 best, 2 select
From: 200.1.1.2 (2.2.2.2)
AS-path 200 300, origin igp, pref-val 0, valid, external, best, select, pre 255
Advertised to such 2 peers
200.1.1.2
200.1.2.2

From: 200.1.2.2 (3.3.3.3)
AS-path 200 300, origin igp, pref-val 0, valid, external, select, pre 255, not
selected for router ID
The preceding command output shows that BGP route 8.1.1.0/24 has two next hops: 200.1.1.2
and 200.1.2.2. Both of them are optimal routes.
----End

Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 200.1.1.1 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 200.1.2.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
maximum load-balancing 2
#
return

#
sysname RouterB
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 200.1.1.2 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 200.1.3.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 300
router-id 2.2.2.2
#
ipv4-family unicast
#
return

#
sysname RouterC
#
interface Pos1/0/0
undo shutdown
link-protocol ppp

ip address 200.1.4.2 255.255.255.0

#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 200.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 300
router-id 3.3.3.3
#
ipv4-family unicast
#
return

#
sysname RouterD
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 200.1.4.1 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 200.1.3.1 255.255.255.0
#
undo shutdown
ip address 8.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
#
return
8.28.11 Example for Configuring BFD for BGP

If the link between two BGP peers fails, BFD quickly detects the fault and notifies the fault to
BGP to make service traffic be switched to the backup link. Using BFD for BGP improves
service transmission reliability.

Voice and video services have high requirements for network reliability and stability. If a fault
occurs on a network, service recovery is required to be as quick as possible, and the recovery
time is required to reach the carrier-class reliability requirement (within 50 ms). BFD for BGP
can meet this requirement.
As shown in Figure 8-39, a primary link and a backup link are deployed on the network to ensure
service transmission reliability. EBGP peer relationships are established between indirectly
connected Router A and Router B, and between indirectly connected Router A and Router C.
Under normal circumstances, traffic is transmitted along the primary link between Router A and
Router B. If the primary link fails, it is required that BGP quickly detect this failure and switch
traffic to the backup link (Router A -> Router C -> Router B).
BFD for BGP can be configured to speed up the link switchover. In case the primary link between
Router A and Router B fails, BFD will quickly detect the change in the BGP peer relationship
and notify BGP of the change. Service traffic then will be switched to the backup link for
transmission.
Figure 8-39 Networking diagram of configuring BFD for BGP
GE3/0/0
172.16.1.1/24
GE2/0/0
200.1.1.2/24
AS 100 GE1/0/0 EBGP RouterB

GE1/0/0
200.1.1.1/24 9.1.1.1/24
RouterA IBGP
AS 200
GE2/0/0
200.1.2.1/24 EBGP GE1/0/0
9.1.1.2/24
GE2/0/0
200.1.2.2/24 RouterC
NOTE
If two routers establish an EBGP peer relationship over a direct link, BFD for BGP does not need to be
configured. This is because the ebgp-interface-sensitive command is enabled by default for directly-
connected EBGP peers.
1. Establish multihop EBGP peer relationships between Router A and Router B, and between
Router A and Router C, and establish an IBGP peer relationship between Router B and
Router C so that they can learn routes from each other.

2. Configure the MED attribute to control route selection, making Router A select the route
sent from Router B as the optimal route to reach the network 172.16.1.1/24.
Data Preparation
l Router IDs of Router A, Router B, and Router C (1.1.1.1, 2.2.2.2, and 3.3.3.3 are used as
an example here), number of the AS where Router A resides (100 is used as an example
here), and number of the AS where Router B and Router C reside (200 is used as an example
here)
l Peer IP address in BFD detection (200.1.1.2/24 is used as an example here)
l Minimum interval for transmitting BGP packets (100 is used as an example here), minimum
interval for receiving BGP packets (100 is used as an example here), and local detection
multiplier (4 is used as an example here)
Procedure
Step 2 Configure basic BGP functions. Establish EBGP peer relationships between Router A and
Router B, and between Router A and Router C and an IBGP peer relationship between Router
B and Router C.
[RouterA] bgp 100
[RouterA-bgp] peer 200.1.1.2 ebgp-max-hop
[RouterA-bgp] peer 200.1.2.2 ebgp-max-hop
[RouterA-bgp] quit
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 ebgp-max-hop
[RouterB-bgp] network 172.16.1.0 255.255.255.0
[RouterB-bgp] quit
[RouterC] bgp 200
[RouterC-bgp] peer 200.1.2.1 ebgp-max-hop
[RouterC-bgp] quit
# Check the status of BGP peer relationships on Router A. The command output shows that the
BGP peer relationships are in the Established state.

[RouterA] display bgp peer

200.1.1.2 4 200 2 5 0 00:01:25 Established 0

200.1.2.2 4 200 2 4 0 00:00:55 Established 0
Step 3 Configure the MED attribute.

Set the MED value for the route sent from Router C or Router B to Router A by using a routing
policy.
[RouterB] route-policy 10 permit node 10
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 route-policy 10 export
[RouterB-bgp] quit
[RouterC] route-policy 10 permit node 10
[RouterC-route-policy] apply cost 150
[RouterC] bgp 200
[RouterC-bgp] peer 200.1.2.1 route-policy 10 export
[RouterC-bgp] quit
# Check BGP routing information on Router A.



*> 172.16.1.0/24 200.1.1.2 100 0 200i

* 200.1.2.2 150 0 200i
As shown in the BGP routing table, the next-hop address of the route to 172.16.1.0/24 is
200.1.1.2, and service traffic is transmitted on the primary link between Router A and Router
B.
Step 4 Configure BFD, and set the interval for transmitting BFD packets, the interval for receiving BFD
packets, and the local detection multiplier.
# Enable BFD on Router A. Set the minimum intervals for transmitting and receiving BFD
packets to 100 ms and the local detection multiplier to 4.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bgp 100
[RouterA-bgp] peer 200.1.1.2 bfd enable
[RouterA-bgp] peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4

[RouterA-bgp] quit
# Enable BFD on Router B. Set the minimum intervals for transmitting and receiving BFD
packets to 100 ms and the local detection multiplier to 4.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 bfd enable
[RouterB-bgp] peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
[RouterB-bgp] quit
# Display all BFD sessions on Router A.

[RouterA] display bgp bfd session all
Local_Address Peer_Address LD/RD Interface
200.1.1.1 200.1.1.2 8201/8201 GigibitEthernet2/0/0
Tx-interval(ms) Rx-interval(ms) Multiplier Session-State
100 100 4 Up
Wtr-interval(m)
0
# Run the shutdown command on GE 2/0/0 of Router B to simulate a fault on the primary link.
[RouterB-Gigabitethernet2/0/0] shutdown
# Check the BGP routing table on Router A.



*> 172.16.1.0/24 200.1.2.2 150 0 200i
As shown in the BGP routing table, the backup link of Router A -> Router C -> Router B takes
effect after the primary link fails, and the next-hop address of the route to 172.16.1.0/24 is
200.1.1.2.
----End
Configuration Files
#
sysname RouterA
#
bfd
#
interface Gigabitethernet1/0/0
undo shutdown
ip address 200.1.2.1 255.255.255.0
#
undo shutdown

ip address 200.1.1.1 255.255.255.0

#
bgp 100
router-id 1.1.1.1
peer 200.1.1.2 ebgp-max-hop 255
peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier
4
peer 200.1.1.2 bfd enable
#
ipv4-family unicast
#
return

#
sysname RouterB
#
bfd
#
undo shutdown
ip address 9.1.1.1 255.255.255.0
#
shutdown
ip address 200.1.1.2 255.255.255.0
#
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
bgp 200
router-id 2.2.2.2
peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier
4
peer 200.1.1.1 bfd enable
#
ipv4-family unicast
network 172.16.1.0 255.255.255.0
peer 9.1.1.2 enable
peer 200.1.1.1 route-policy 10 export
#
route-policy 10 permit node 10
apply cost 100
#
return

#
sysname RouterC
#
bfd
#
undo shutdown
ip address 200.1.2.2 255.255.255.0

#
undo shutdown
ip address 9.1.1.2 255.255.255.0
#
bgp 200
router-id 3.3.3.3
#
ipv4-family unicast
peer 9.1.1.1 enable
peer 200.1.2.1 route-policy 10 export
#
apply cost 150
#
return
8.28.12 Example for Configuring BGP Auto FRR

BGP Auto FRR provides backup forwarding entries for the optimal route, minimizing the delay
for important services.
As networks evolve continuously, voice, on-line video, and financial services raise increasingly
high requirements for real-time performance. Usually, primary and backup links are deployed
on a network to ensure the stability of these services. If the primary link fails, the Router needs
to wait for route convergence to be completed. After that, the Router reselects an optimal route
and delivers the reselected route to the FIB table to start a link switchover. This is the traditional
switchover mode. In this mode, service interruption lasts a long time, which does not meet the
services' requirement.
BGP Auto FRR addresses this problem. After BGP Auto FRR is enabled on a Router, the
Router selects the optimal route to forward packets. In addition, the Router automatically adds
information about the second optimal route to the backup forwarding entries of the optimal route
and delivers the backup forwarding entries to the FIB table. If the primary link fails, the router
quickly switches traffic to the backup link. The switchover does not depend on route
convergence. Therefore, the service interruption time is very short, reaching the sub-second
level.
As shown in Figure 8-40, Router A resides in AS 100. There are two paths that can reach the
network 4.4.4.4/32. It is required that traffic be transmitted on LinkA, the primary link, under
normal circumstances and quickly switched to LinkB, the backup link, in the case that LinkA
fails.

Figure 8-40 Networking diagram of configuring BGP Auto FRR
RouterB
/0 PO
S 1/0 24 20 S2/
PO .1.2/ .3 . 0
1 .1 /0
.1 Loopback1
/0 /0 20 /24
O S 1 /2 4 4.4.4.4/32
P .1 .1 PO
1
20. LinkA 20 S1/
.3 . 0
1 .2 /0
/2 4
RouterA
0
LinkB O S 2/ 0/ 4
P /2
PO S . 1 .2
2 0 .4
20.2 2/0/0 RouterD
.1.1/ POS 2/0/0
AS100 24
20.2 1/0/0 POS .1/24
.1
.1.2/
24 20.4
RouterC
AS200
1. Configure EBGP peer relationships between Router A and Router B, and between
Router A and Router C, and configure IBGP peer relationships between Router D and
Router B, and between Router D and Router C to allow them to learn BGP routes from
each other.
2. Configure routing policies on Router B and Router C to change the MED values of routes
sent to Router D so that Router A later can select the route for LinkA as the optimal route.
3. Configure BGP Auto FRR on Router A to enable the service traffic to be quickly switched
to LinkB in case LinkA fails.
Data Preparation
l ID of each Router (1.1.1.1, 2.2.2.2, 3.3.3.3, and 4.4.4.4 are used as an example as the router
IDs of Router A, Router B, Router C, and Router D), number of the AS where Router A
resides (100 is used as an example here), and number of the AS where Router B, Router
C, and Router D reside (200 is used as an example here)
l Names of routing policies on Router B and Router C (rtb and rtc are used as an example
here)
l MED values of routes sent from Router B or Router C to Router D (80 and 120 are used
as an example here)

Procedure
Step 2 Establish EBGP peer relationships between Router A and Router B, and between Router A and
Router C, and establish IBGP peer relationships between Router D and Router B, and between
Router D and Router C.
# Configure EBGP peer relationships on Router A.

[RouterA] bgp 100
[RouterA-bgp] quit
NOTE
The configurations on Router B and Router C are similar to the configuration on Router A, and are not
provided here.
# Configure IBGP peer relationships on Router D.

[RouterD] bgp 200
[RouterD-bgp] quit
NOTE
The configurations on Router B and Router C are similar to the configuration on Router D, and are not
provided here.
Step 3 Configure routing policies on Router B and Router C, specifying different MED values for the
routes from Router B or Router C to Router D.
# Configure a routing policy on Router B.

[RouterB] route-policy rtb permit node 10
[RouterB] bgp 200
[RouterB-bgp-af-ipv4] peer 20.1.1.1 route-policy rtb export
[RouterB-bgp] quit
# Configure a routing policy on Router C.

[RouterC] route-policy rtc permit node 10
[RouterC] bgp 200
[RouterC-bgp-af-ipv4] peer 20.2.1.1 route-policy rtc export
[RouterC-bgp] quit
# Configure Router D to advertise a route to 4.4.4.4/32.

[RouterD] bgp 200
[RouterD-bgp] network 4.4.4.4 32

[RouterD-bgp] quit
# Run the display ip routing-table verbose command on Router A to view detailed information
about the route learned by Router A to reach 4.4.4.4/32.
[RouterA] display ip routing-table 4.4.4.4 32 verbose
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x4
Because the MED value of the route learned from Router B is smaller, Router A selects the route
Router A -> Router B -> Router D as the optimal route to access 4.4.4.4/32. Since FRR is not
configured, no information about the backup route is available.
Step 4 Enable BGP Auto FRR on Router A and check routing information.
# Enable BGP Auto FRR on Router A.

[RouterA] bgp 100
[RouterA-bgp-af-ipv4] auto-frr
[RouterA-bgp] quit
# After the configuration is complete, run the display ip routing-table verbose command on
Router A to view routing information.
[RouterA] display ip routing-table 4.4.4.4 32 verbose
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x4
BkNextHop: 20.2.1.2 BkInterface: Pos2/0/0
BkIndirectID: 0x2
The command output shows that Router A has a backup next hop and a backup outbound
interface to 4.4.4.4/32.
----End

Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
ip address 20.1.1.1 255.255.255.0
#
interface Pos2/0/0
ip address 20.2.1.1 255.255.255.0
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
auto-frr
#
return

#
sysname RouterB
#
interface Pos1/0/0
ip address 20.1.1.2 255.255.255.0
#
interface Pos2/0/0
ip address 20.3.1.1 255.255.255.0
#
bgp 200
router-id 2.2.2.2
#
ipv4-family unicast
peer 20.1.1.1 route-policy rtb export
#
route-policy rtb permit node 10
apply cost 80
#
return

#
sysname RouterC
#
interface Pos1/0/0
ip address 20.2.1.2 255.255.255.0
#
interface Pos2/0/0
ip address 20.4.1.1 255.255.255.0
#
bgp 200
router-id 3.3.3.3
#
ipv4-family unicast
peer 20.2.1.1 route-policy rtc export
#
route-policy rtc permit node 10
apply cost 120

#
return

#
sysname RouterD
#
interface Pos1/0/0
ip address 20.3.1.2 255.255.255.0
#
interface Pos2/0/0
ip address 20.4.1.2 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
network 4.4.4.4 255.255.255.255
#
return
8.28.13 Example for Configuring BGP GTSM

BGP Generalized TTL Security Mechanism (GTSM) can be used on a BGP network to protect
devices against Central Processing Unit (CPU) attacks.
"Valid packet" attacks on a network consume a large number of device resources such as CPU
resources. For example, an attacker forges BGP 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.
GTSM checks whether the TTL value in the header of a packet is within a pre-defined value
range. This protects devices against CPU attacks.
On the network running BGP shown in Figure 8-41, Router A is in AS 10. Routers B, C, and
D are in AS 20. BGP GTSM can be configured on Router B to protect Router B against CPU
attacks, improving network security.

Figure 8-41 Networking diagram for configuring BGP GTSM
IBGP
POS1/0/0 RouterB POS1/0/0
RouterC
EBGP 30.1.1.2/24 20.1.1.2/24
POS2/0/0
RouterA 20.1.1.1/24 L POS2/0/0
oo 20.1.2.1/24
Loopback0 3.3 p b IBGP
POS1/0/0 2.2.2.9/32 IB .3 a c
GP .9 k0
AS10 30.1.1.1/24 /3 POS1/0/0
2
20.1.2.2/24
PC RouterD
AS20
Loopback0
4.4.4.9/32
1. Configure OSPF on Routers B, C, and D to allow these devices to communicate with each
other in AS 20.
2. Establish an EBGP connection between Routers A and B, and establish IBGP full-mesh
connections between Routers B, C, and D using loopback interface addresses.
3. Configure GTSM on Routers A, B, C, and D.
Data Preparation
l Router IDs 2.2.2.9, 3.3.3.9, and 4.4.4.9, and AS numbers 20 of Routers B and C respectively
l TTL values of packets transmitted between Routers A and B, between Routers B and C,
between Routers C and D, and between Routers B and D (TTL values of packets transmitted
between Routers A and B, between Routers B and C, and between Routers C and D is 1,
and TTL values of packets transmitted between Routers B and D is 2 in this example)
Procedure
Step 2 Configure OSPF. The configuration details are not provided here.
Step 3 Establish IBGP full-mesh connections.
[RouterB] bgp 20

[RouterB-bgp] peer 3.3.3.9 connect-interface LoopBack0

[RouterB-bgp] peer 3.3.3.9 next-hop-local
[RouterB-bgp] peer 4.4.4.9 connect-interface LoopBack0
[RouterB-bgp] peer 4.4.4.9 next-hop-local
[RouterC] bgp 20
[RouterC-bgp] peer 2.2.2.9 connect-interface LoopBack0
[RouterC-bgp] peer 4.4.4.9 connect-interface LoopBack0
[RouterD] bgp 20
[RouterD-bgp] peer 2.2.2.9 connect-interface LoopBack0
[RouterD-bgp] peer 3.3.3.9 connect-interface LoopBack0

[RouterA] bgp 10
[RouterB-bgp]quit
# View the connection status of BGP peers.

[RouterB] display bgp peer
3.3.3.9 4 20 8 7 0 00:05:06 Established 0

4.4.4.9 4 20 8 10 0 00:05:33 Established 0
30.1.1.1 4 10 7 7 0 00:04:09 Established 0
The preceding command output shows that BGP connections have been established between
Router B and other Routers.
Step 5 Configure GTSM on Routers A and B. Because the two routers are directly connected, the range
of TTL values contained in packets transmitted between the two devices is [255, 255]. The valid-
ttl-hops value is 1.
# Configure GTSM on Router A.
[RouterA-bgp] peer 30.1.1.2 valid-ttl-hops 1
[RouterA-bgp] quit
# Configure GTSM for the EBGP connection on Router B.

[RouterB] bgp 20
[RouterB-bgp] peer 30.1.1.1 valid-ttl-hops 1
[RouterB-bgp] quit

# View the GTSM configuration.

[RouterB] display bgp peer 30.1.1.1 verbose
Type: EBGP link
Update-group ID : 2
Update messages 1
Open messages 2
Refresh messages 0
Update messages 5
Open messages 2
Refresh messages 0
Authentication type configured: None,
The preceding command output shows that GTSM has been enabled, the valid hop count is 1,
and the BGP connection is in the Established state.
Step 6 Configure GTSM on Routers B and C. Because the two routers are directly connected, the range
# Configure GTSM on Router B.
[RouterB] bgp 20
[RouterB-bgp] quit
# Configure GTSM for the IBGP connection on Router C.

[RouterC-bgp] peer 2.2.2.9 valid-ttl-hops 1


Type: IBGP link
Update-group ID : 0
Update messages 5
Open messages 1
Refresh messages 0
Update messages 10
Open messages 1
Refresh messages 0
Nexthop self has been configured
Connect-interface has been configured
Step 7 Configure GTSM on Routers C and D. Because the two Routers are directly connected, the range
# Configure GTSM for the IBGP connection on Router C.

[RouterC-bgp] peer 4.4.4.9 valid-ttl-hops 1
[RouterC-bgp] quit
# Configure GTSM for the IBGP connection on Router D.

[RouterD-bgp] peer 3.3.3.9 valid-ttl-hops 1

[RouterC] display bgp peer 4.4.4.9 verbose

Type: IBGP link
Update-group ID : 1
Update messages 10
Open messages 1
Refresh messages 0
Update messages 10
Open messages 2
Refresh messages 0
Step 8 Configure GTSM on Routers B and D. Because the two Routers are connected through
Router C, the range of TTL values contained in packets transmitted between the two devices is
[254, 255], and the valid-ttl-hops value is 2.
# Configure GTSM for the IBGP connection on Router B.

[RouterB] bgp 20
[RouterB-bgp] quit
# Configure GTSM on Router D.

[RouterD-bgp] peer 2.2.2.9 valid-ttl-hops 2


Type: IBGP link
Update-group ID : 0
Update messages 13
Open messages 1
Refresh messages 0
Update messages 13
Open messages 1
Refresh messages 0
Nexthop self has been configured
NOTE
l In this example, if the valid-ttl-hops value is smaller than 2 on either of Routers B and D, the IBGP
connection cannot be established between them.
l GTSM must be enabled on both ends of a BGP connection.
# Run the display gtsm statistics all command on Router B to check GTSM statistics. If the
default action to be taken on packets is pass and all packets are valid, no packet is dropped.
[RouterB] display gtsm statistics all
----------------------------------------------------------------


----------------------------------------------------------------
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
1 BGP 0 0 0
1 BGPv6 0 0 0
1 OSPF 0 0 0
1 LDP 0 0 0
1 OSPFv3 0 0 0
1 RIP 0 0 0
2 BGP 0 0 0
2 BGPv6 0 0 0
2 OSPF 0 0 0
2 LDP 0 0 0
2 OSPFv3 0 0 0
2 RIP 0 0 0
3 BGP 0 0 0
3 BGPv6 0 0 0
3 OSPF 0 0 0
3 LDP 0 0 0
3 OSPFv3 0 0 0
3 RIP 0 0 0
4 BGP 32 0 32
4 BGPv6 0 0 0
4 OSPF 0 0 0
4 LDP 0 0 0
4 OSPFv3 0 0 0
4 RIP 0 0 0
5 BGP 0 0 0
5 BGPv6 0 0 0
5 OSPF 0 0 0
5 LDP 0 0 0
5 OSPFv3 0 0 0
5 RIP 0 0 0
7 BGP 0 0 0
7 BGPv6 0 0 0
7 OSPF 0 0 0
7 LDP 0 0 0
7 OSPFv3 0 0 0
7 RIP 0 0 0
----------------------------------------------------------------
If a host forges BGP packets of Router A to attack Router B, the packets are discarded because
their TTL values are not 255 when reaching Router B. The number of dropped packets increases
accordingly in the GTSM statistics of Router B.
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
ip address 30.1.1.1 255.255.255.0
#
bgp 10
router-id 1.1.1.9

peer 30.1.1.2 valid-ttl-hops 1

#
ipv4-family unicast
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 30.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
#
bgp 20
router-id 2.2.2.9
#
ipv4-family unicast
import-route ospf 1
peer 3.3.3.9 enable
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return

#
sysname RouterC
#
interface Pos1/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 20.1.2.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
bgp 20
router-id 3.3.3.9


#
ipv4-family unicast
peer 2.2.2.9 enable
peer 4.4.4.9 enable
#
ospf 1
area 0.0.0.0
network 20.1.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return

#
sysname RouterD
#
interface Pos1/0/0
link-protocol ppp
ip address 20.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.9 255.255.255.255
#
bgp 20
router-id 4.4.4.9
#
ipv4-family unicast
peer 2.2.2.9 enable
peer 3.3.3.9 enable
#
ospf 1
area 0.0.0.0
network 20.1.2.0 0.0.0.255
network 4.4.4.9 0.0.0.0
#
return

Configuration Guide - IP Routing 9 BGP4+ Configuration
9 BGP4+ Configuration
About This Chapter
BGP4+, which is applicable to the large-scale IPv6 network with a complicated structure, is used
between ASs to transmit routing information.
9.1 Introduction
BGP4+ is a dynamic routing protocol used between ASs.
9.2 Configuring Basic BGP4+ Functions

Before building BGP4+ networks, you need to configure basic BGP4+ functions.
9.3 Configuring BGP4+ Route Attributes

BGP4+ has many route attributes. By configuring these attributes, you can change BGP4+
routing policies.
9.4 Controlling the Advertising and Receiving of BGP4+ Routing Information

BGP4+ can perform routing policies on or filter only the routes to be advertised to a certain peer.
9.5 Configuring Parameters of a Connection Between BGP4+ Peers

By setting parameters of a connection between BGP4+ peers, you can adjust and optimize the
BGP4+ network performance.
9.6 Configuring BFD for BGP4+

By configuring BFD for BGP4+, you can provide a fast fault detection mechanism for BGP4+,
and therefore speed up network convergence.
9.7 Configuring BGP4+ PeerTracking

On a network where BFD is unsuitable to deploy, you can configure BGP4+ peer tracking to
implement the fast convergence of IBGP routes.
9.8 Configuring BGP4+ Route Dampening

By configuring BGP4+ route dampening, you can suppress unstable BGP4+ routes.
9.9 Configuring BGP4+ Load Balancing

Configuring BGP4+ load balancing better utilizes network resources and reduces network
congestion.
9.10 Configuring a BGP4+ Peer Group

By configuring a BGP4+ peer group, you can simplify the management of routing policies, and
therefore improve the efficiency of route advertisement.
9.11 Configuring a BGP4+ Route Reflector

By configuring a BGP4+ route reflector, you can solve the problem of establishing fully meshed
connections between multiple IBGP peers.
9.12 Configuring a BGP4+ Confederation

On a large-scale BGP4+ network, configuring a BGP4+ confederation can simplify the
management of routing policies and improve the efficiency of route advertisement.
9.13 Configuring BGP4+ 6PE

By configuring BGP4+ 6PE, you can connect separated IPv6 networks through the MPLS
tunneling technology.
9.14 Configuring Inter-AS 6PE

Inter-AS IPv6 Provider Edge (6PE) allows you to connect separate IPv6 networks that connect
to different ASs over IPv4 tunnels, so that these IPv6 networks can communicate.
9.15 Configuring BGP4+ 6PE FRR

After you configure 6PE FRR on a device, the device can select a backup next hop for received
6PE routes. When the next hop of the primary route between PEs becomes unreachable, traffic
will be quickly switched to the backup next hop.
9.16 Configuring BGP4+ Security

To improve BGP4+ security, you can perform TCP connection authentication.
9.17 Maintaining BGP4+

Maintaining BGP4+ involves resetting a BGP4+ connection and clearing BGP4+ statistics.

BGP4+ configuration examples explain networking requirements, networking diagram,

9.1 Introduction
BGP4+ is a dynamic routing protocol used between ASs.
9.1.1 BGP4+ Overview

BGP4+ is mainly used to control route transmission and select optimal routes.
BGP4+ is a dynamic routing protocol used between Autonomous Systems (ASs), and it is an
extension of BGP.
The traditional BGP4 can manage only the IPv4 routing information. For other network layer
protocols such as IPv6, the traditional BGP4 has a limited capability to transmit routing
information.
The Internet Engineering Task Force (IETF) introduces BGP4+ as a supplement to BGP4 to
support multiple network layer protocols. The RFC for BGP4+ is RFC 2858 (Multiprotocol
Extensions for BGP4).
To support IPv6, BGP4 needs to reflect the IPv6 protocol information to the Network Layer
Reachable Information (NLRI) attribute and the Next_Hop attribute.
BGP4+ introduces two NLRI attributes:
l Multiprotocol Reachable NLRI (MP_REACH_NLRI): advertises the reachable routes and
the next hop information.
l Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI): withdraws the unreachable
routes.
The Next_Hop attribute of BGP4+ is in the format of an IPv6 address. It can be an IPv6 global
unicast address or the link-local address of the next hop.
BGP4+ can be applied to an IPv6 network by using the BGP attribute of multiple protocol
extension. The message and routing mechanisms of BGP remain unaltered.
9.1.2 BGP4+ Features Supported by the NE80E/40E

The system supports various BGP4+ features, including load balancing, route aggregation, route
dampening, community, route reflector, confederation, BGP4+ accounting, 6PE, BFD for BGP4
+, BGP4+ NSR, and BGP4+ GR.
IPv6 Provider Edge (6PE)

After the 6PE function is enabled, the separated IPv6 networks can be connected through the
Multi-Protocol Label Switch (MPLS) tunnel technology. The tunnel in 6PE mode implements
the dual protocol stack of IPv4/IPv6 on PEs of the Internet Service Provider (ISP). It identifies
IPv6 routes by using the label assigned by the Multiprotocol Border Gateway Protocol (MP-
BGP), and implements IPv6 interworking through LSPs between PEs.
Other Attributes
Most of BGP4+ features supported by the NE80E/40E are similar to those of BGP supported by
the NE80E/40E. For details, refer to the chapter "BGP Configuration".

BGP4+ does not support summary automatic and MP-BGP.
9.2 Configuring Basic BGP4+ Functions


Before configuring basic BGP4+ functions, familiarize yourself with the usage scenario,
complete the pre-configuration tasks, and obtain the required data. This can help you complete
the configuration task quickly and accurately.
BGP4+ is configured in an IPv6 network.
Before configuring basic BGP4+ functions, complete the following tasks:
l Enabling IPv6
l Configuring link layer protocol parameters and IPv6 addresses for interfaces to make link
layers of the interfaces Up
Data Preparation
To configure BGP4+, you need the following data.
No. Data
1 Local AS number and Router ID
2 IPv6 address and AS number of the peer
3 (Optional) Interfaces that set up the BGP4+ session
9.2.2 Starting a BGP Process

Starting a BGP4+ process is a prerequisite for configuring basic BGP4+ functions. When starting
a BGP4+ process, you need to specify the number of the AS that the device belongs to.
Context
Perform the following steps on the router on which the BGP4+ connection needs to be set up:
Procedure
Step 1 Run:
system-view

Step 2 Run:
BGP is enabled (the local AS number is specified) and the BGP view is displayed.

router-id ipv4-address
The router ID is set.
Setting or changing the router ID of BGP resets the BGP peer relationship between routers.
NOTE
l To enhance the network reliability, you can manually configure the address of a loopback interface as
the router ID. If the router ID is not set, BGP uses the router ID in the system view. To select the router
ID in the system view, refer to the Command Reference.
l If no interface of a router is configured with an IPv4 address, you must set a router ID for the router.
----End
9.2.3 Configuring an IPv6 Peer

Devices can exchange BGP4+ routing information only after BGP4+ peers are configured and
the BGP4+ peer relationship is established.
Procedure
l Configuring an IBGP Peer
Perform the following steps on the router on which the IBGP connection needs to be set
up:
1. Run:
system-view

2. Run:

3. Run:
peer { ipv6-address | group-name } as-number { as-number-plain | as-number-
dot }
The peer address and the AS where the peer resides are configured.
The AS number of the specified peer must be the same as the local AS number.
When the IPv6 address of a specified peer is a loopback address or a sub-interface

address, you need to perform Configuring the Local Interfaces Used for BGP4+
Connections to ensure the establishment of the peer.
4. (Optional) Run:
peer { ipv6-address | group-name } listen-only

A peer (group) is configured only to listen to connection requests, but not to send
connection requests.
After this command is used, the existing peer relationship is interrupted. The peer on
which this command is used waits for the connection request from its peer to
reestablish the neighbor relationship. This configuration can prevent the conflict of
sending connection requests.
NOTE
This command can be used on only one of two peers. If this command is used on the two peers,
the connection between the two peers cannot be established.
5. Run:
ipv6-family [ unicast ]

6. Run:
peer { ipv6-address | group-name } enable
The IPv6 peers are enabled.

After configuring the BGP4+ peers in the BGP view, you need to enable these peers
in the BGP IPv6 unicast address family view.
l Configuring an EBGP Peer
Perform the following steps on the router on which the EBGP connection needs to be set
up:
1. Run:
system-view

2. Run:

3. Run:
peer { ipv6-address | group-name } as-number { as-number-plain | as-number-
dot }
The IP address and the AS number of a specified BGP peer are specified.
The AS number of the specified BGP peer should be different from the local AS
number.
If the IP address of the specified peer is that of a loopback interface on the reachable
peer or that of a sub-interface on the directly connected peer, you need to complete
the task of Configuring the Local Interfaces Used for BGP4+ Connections to
ensure that the peer is correctly established.
4. Run:
peer { ipv6-address | group-name } ebgp-max-hop [ hop-count ]
The maximum number of hops in the EBGP connections is set.

By default, a direct physical link must be available between EBGP peers. If such a
link does not exist, run the peer ebgp-max-hop command to allow EBGP peers to
establish a TCP connection over multiple hops.

If hop-count is not specified in the peer ebgp-max-hop command, 255 is used as the
maximum number of hops in EBGP connections.
NOTE
When establishing the EBGP connection through loopback interfaces, you must use the peer
ebgp-max-hop command specifying that hop-count is greater than or equal to 2. Otherwise,
BGP cannot set up the EBGP connection with the peer.
5. (Optional) Run:
peer { ipv6-address | group-name } listen-only
The peer or peer group is configured only to listen to connection requests, but not to
send any connection request.
After this command is used, the existing peer relationship is removed. The peer on
which this command is used reestablishes the peer relationship after receiving the
connection request from its peer. After this configuration is done, the conflict of
connection requests is avoided.
NOTE
This command can be used on only one of two peers. If this command is used on the two peers,
the connection between the two peers cannot be established.
6. Run:

7. Run:
peer { ipv6-address | group-name } enable
An IPv6 peer is enabled.
After configuring a BGP4+ peer in the BGP view, enable the peer in the BGP IPv6
unicast address family view.
----End
9.2.4 (Optional) Configuring the Local Interfaces Used for BGP4+

Connections
When establishing BGP4+ peer relationship between two devices through various links, you
need to specify the local interface during the setup of a BGP4+ session on the devices.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:

peer { ipv6-address | group-name } connect-interface interface-type interface-

number [ ipv6-source-address ]
The source interface and source address used to set up a TCP connection are specified.
Usually, BGP4+ uses the physical interface that is directly connected to the peer as the session
interface used for the TCP connection.
To increase the reliability and stability of the BGP4+ connections, configure the local interface
used for the BGP4+ connection as the loopback interface. In this way, when there are redundant
links on the network, the BGP4+ connections are not interrupted due to the failure of a certain
interface or a link.
NOTE
When establishing BGP4+ peer relationship between two devices through various links, specify the local
interface during the setup of a BGP4+ session on the devices by using the peer connect-interface command
is recommended.
----End

After basic BGP4+ functions are configured, you can check BGP4+ peer information.
Prerequisites
Basic BGP4+ functions has been configured.
Procedure
l Run the display bgp ipv6 peer ipv4-address verbose command to check information about
the BGP4+ peers.
l Run the display bgp ipv6 peer ipv6-address { log-info | verbose } command to check
information about the BGP4+ peers.
----End
9.3 Configuring BGP4+ Route Attributes

BGP4+ has many route attributes. By configuring these attributes, you can change BGP4+
routing policies.

Before controlling BGP4+ route selection, familiarize yourself with the usage scenario, complete
You can change the BGP4+ routing policies by configuring the route attributes.
l BGP4+ priority

After the BGP4+ priority is configured, Route Management (RM) is affected in routing
between BGP4+ and the other routing protocols.
l Preferred value of BGP4+ routing information
After the preferred value of BGP4+ routing information is configured, the route with the
greatest preferred value is selected when multiple routes to the same destination exist in
the BGP4+ routing table.
l Local_Pref attribute
The function of the Local_Pref attribute is similar to that of the preferred value of BGP4+
routing information. The preferred value of BGP4+ routing information takes precedence
over the Local_Pref attribute.
l Multi_Exit Discriminator (MED) attribute
After the MED attribute is configured, EBGP peers select the route with the smallest MED
value when the traffic enters an AS.
l Next_Hop attribute
A route with an unreachable next hop is ignored.
l Community attribute
The community attribute can simplify the management of routing policies. The
management range of the community attribute is wider than that of the peer group. The
community attribute can control the routing policies of multiple BGP4+ devices.
l AS_Path attribute
After the AS_Path attribute is configured, the route with a shorter AS path is selected.
l Accumulated interior gateway protocol metric (AIGP)
The AIGP attribute is used to select the optimal route in an AIGP administrative domain.
Before configuring BGP4+ route attributes, complete the following tasks:
l Configuring Basic BGP4+ Functions
Data Preparation
To configure BGP4+ route attributes, you need the following data.
No. Data
1 AS number
2 Protocol priority
3 Local_Pref
4 MED
5 Name of the routing policy for using the community attribute

9.3.2 Configuring the BGP4+ Preference

Setting the BGP4+ preference can affect route selection between BGP4+ and another routing
protocol.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
preference { external internal local | route-policy route-policy-name }
The BGP4+ preference is set.
NOTE
Using peer route-policy command to configure the preference of the BGP protocol on the peers is not
currently supported.
----End
9.3.3 Configuring BGP4+ Preferred Value for Routing Information

After the preferred value is configured for routing information, the route with the largest
preferred value is selected when multiple routes to the same destination exist in the BGP4+
routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:

Step 4 Run:
peer { group-name | ipv4-address | ipv6-address } preferred-value value
The preferred value of a peer is configured.
By default, the preferred value of the route learned from a neighbor is 0.
----End
9.3.4 Configuring the Default Local_Pref Attribute of the Local

Router
The Local_Pref attribute is used to determine the optimal route for the traffic that leaves an AS.
When a BGP4+ router obtains multiple routes to the same destination address but with different
next hops from different IBGP peers, the route with the largest Local_Pref value is selected.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
default local-preference preference
The default Local_Pref of the local router is configured.
----End
9.3.5 Configuring the MED Attribute

The Multi_Exit Discriminator (MED) attribute serves as the metric used by an IGP. After MED
attributes are set, EBGP peers select the route with the smallest MED value for the traffic that
enters an AS.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
Step 4 Run the following commands to configure the BGP4+ MED attribute as required:
l Run:
default med med
The default MED attribute is configured.

l Run:
compare-different-as-med
The MED values from different ASs are compared.

l Run:
deterministic-med
Deterministic-MED is enabled.
If this command is not configured, when an optimal route is to be selected from among routes
which are received from different ASs and which carry the same prefix, the sequence in
which routes are received is relevant to the result of route selection. After the command is
configured, however, when an optimal route is to be selected from among routes which are
received from different ASs and which carry the same prefix, routes are first grouped
according to the leftmost AS in the AS_Path. Routes with the same leftmost AS are grouped
together, and after comparison, an optimal route is selected for the group. The group optimal
route is then compared with optimal routes from other groups to determine the final optimal
route. This mode of route selection ensures that the sequence in which routes are received is
no longer relevant to the result of route selection.
l Run:
bestroute med-none-as-maximum
The maximum MED value is used when the current MED is not available.
l Run:
bestroute med-confederation
The MED values of routes advertised in the local confederation are compared.
The commands in Step 4 can be used regardless of the order.
----End
9.3.6 Configuring the Next_Hop Attribute

By setting the Next_Hop attribute, you can flexibly control BGP4+ route selection.
Procedure
l Modifying the Next Hop When Advertising a Route to an IBGP Peer
1. Run:
system-view

2. Run:


3. Run:

4. Run:
peer ipv6-address next-hop-local
The local address is configured as the next hop when routes are advertised.
In some networking environments, to ensure that the IBGP neighbors find the correct
next hop, configure the next hop address as its own address when routes are advertised
to the IBGP peers.
NOTE
If BGP load balancing is configured, the local router changes the next hop address to its own
address when advertising routes to the IBGP peer groups, regardless of whether the peer next-
hop-local command is used.
l The next-hop iteration based on the routing policy
1. Run:
system-view

2. Run:

3. Run:

4. Run:
nexthop recursive-lookup route-policy route-policy-name
The next-hop iteration based on the specified routing policy is enabled.
By default, the next-hop iteration based on the specified routing policy is disabled.
The next-hop iteration based on the specified routing policy can control the iterated
route according to certain conditions. The route that fails to pass the policy is ignored.
----End
9.3.7 Configuring the AS_Path Attribute

The AS_Path attribute is used to prevent routing loops and control route selection.
Procedure
l Configure the AS_Path Attribute in the IPv6 Address Family View.
1. Run:
system-view


2. Run:

3. Run:

4. Run the following commands to configure the AS_Path attribute as required:
– Run:
peer { ipv6-address | group-name } allow-as-loop [ number ]
The local AS number can be used repeatedly.

– Run:
bestroute as-path-ignore
BGP is configured to ignore AS_Path attributes of routes during route selection.

– Run:
peer { ipv6-address | group-name } public-as-only [ force ]
The device is configured to delete private AS numbers (if any) from the AS_Path
attribute before sending update packets.
The peer public-as-only command can be used only on EBGP peers.
After the command without force is run, the device does not delete the private AS
numbers from the AS_Path attribute before sending update packets in either of the
following scenarios:
– The AS_Path of a route contains the AS number of the peer. In this case,
deleting the private AS numbers may lead to a routing loop.
– The AS_Path list contains both public network AS numbers and private AS
numbers, indicating that the route has passed through the public network.
Deleting the private AS numbers may lead to a forwarding error.
To enable the device to delete the private AS numbers from the AS_Path attribute
before sending update packets even in the preceding scenarios, specify force in
the command.

l Configure a fake AS number.
1. Run:
system-view

2. Run:

3. Run:
peer { ipv6-address | group-name } fake-as { as-number-plain | as-number-
dot }
The fake AS number is set.

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.
NOTE
This command is applicable only to EBGP peers.

l Enable AS number replacement.
1. Run:
system-view

2. Run:

3. Run:

4. Run:
peer { ipv6-address | group-name } substitute-as
AS number replacement is enabled.
After this command is used, if the AS_Path attribute contains the AS number of the
peer, the device replaces the AS number of the peer with the local AS number before
advertising routes to the peer.
NOTICE
If the configuration is incorrect, the command may cause routing loops.
----End
9.3.8 Configuring the BGP4+ Community Attribute

The community attribute is used to simplify the management of routing policies. The
management scope of the community attribute is far larger than that of the peer group. The
community attribute can control the routing policies of multiple BGP4+ routers.
Procedure
l Configuring the routers to Advertise the Community Attribute to the Peers
1. Run:
system-view

2. Run:


3. Run:

4. Run the following commands to advertise community attributes to the peer group:
– To configure the BGP device to send a standard community attribute to its peer or
peer group, run:
peer { ipv4-address | ipv6-address | group-name } advertise-community
routers are configured to advertise the standard community attribute to a peer

group.
– To configure the BGP device to send an extended community attribute to its peer
or peer group, perform the following steps:
a. Run the peer { ipv4-address | group-name } advertise-ext-community
command to advertise an extended community attribute to a specified peer or
peer group.
b. (Optional) 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.
l Applying the Routing Policies to the Advertised Routing Information
1. Run:
system-view

2. Run:

3. Run:

4. Run:
peer { ipv4-address | ipv6-address | group-name } route-policy route-
policy-name export
The outbound routing policies are configured.
NOTE
l When configuring a BGP4+ community, you should define the specific community
attribute by using the routing policies. Then, apply these routing policies to the
advertisement of routing information.
l For the configuration of routing policies, refer to Routing Policy Configuration. For the
configuration of community attributes, refer to 8 BGP Configuration.
----End


After BGP4+ route attributes are configured, you can check information about route attributes.
Prerequisites
BGP4+ route attributes has been configured.
Procedure
l Run the display bgp ipv6 paths [ as-regular-expression ] command to check the AS-Path
information.
l Run the display bgp ipv6 routing-table different-origin-as command to check the route
with the different source AS.
l Run the display bgp ipv6 routing-table regular-expression as-regular-expression
command to check the routing information matching the regular expression of the AS.
l Run the display bgp ipv6 routing-table community [ aa:nn &<1-29> ] [ internet | no-
advertise | no-export | no-export-subconfed ] * [ whole-match ] command to check
routing information about the specified BGP4+ community.
l Run the display bgp ipv6 routing-table community-filter { { community-filter-name |
basic-community-filter-number } [ whole-match ] | advanced-community-filter-number }
command to check information about the routes matching the specified BGP4+ community
attribute filter.
----End
9.4 Controlling the Advertising and Receiving of BGP4+

Routing Information
BGP4+ can perform routing policies on or filter only the routes to be advertised to a certain peer.

Before controlling the advertisement of BGP4+ routes, familiarize yourself with the usage
scenario, complete the pre-configuration tasks, and obtain the required data. This can help you
complete the configuration task quickly and accurately.
This section describes the following:
l Controlling the advertising and receiving of BGP4+ routing information, which includes
the filtering of routing information and the application of the routing policies.
l Soft resetting the BGP4+ connections
In the NE80E/40E, BGP4+ supports the route-refresh capability. When the policies are
changed, the system can refresh the BGP4+ routing table automatically without interrupting
the BGP4+ connections.

If there are routers that do not support route-refresh in the network, you can run the peer
keep-all-routes command to save all route refreshment locally. Then, you can run the
refresh bgp command to soft reset the BGP4+ connections manually.
Before controlling the advertising and receiving of BGP4+ routing information, complete the
following tasks:
Data Preparation
To control the advertising and receiving of BGP4+ routing information, you need the following
data.
No. Data
1 Name and process ID of the external route to be imported
2 Name of the filtering list used in the routing policies
3 Various parameters of route dampening, including half-life of a reachable route, half-

life of an unreachable route, threshold for freeing suppressed routes, threshold for
suppressing routes, and upper limit of the penalty
9.4.2 Configuring BGP4+ to Advertise Local IPv6 Routes

The local routes to be advertised must be in the local IP routing table. You can use routing
policies to control the routes to be advertised.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
network ipv6-address prefix-length [ route-policy route-policy-name ]
The exactly-matched local IPv6 routes are advertised.

You can use the network command to statically inject the IPv6 routes to the BGP4+ routing
table.
To be specific, the command can be used to advertise the routes only with the exactly-matched
address prefix and mask. If the mask is not designated, the routes are exactly matched based on
the natural network segment.
The local routes to be advertised should be in the local IPv6 routing table. You can use routing
policies to control the routes to be advertised more flexibly.
----End
9.4.3 Configuring BGP4+ Route Aggregation

By configuring route aggregation, you can reduce the size of the routing table of a peer. BGP4
+ supports automatic aggregation and manual aggregation.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
aggregate ipv6-address prefix-length [ as-set | attribute-policy route-policy-
name1 | detail-suppressed | origin-policy route-policy-name2 | suppress-policy
route-policy-name3 ] *
Manual aggregation of routes is configured.
Manual aggregation is valid for the routing entries in the local BGP4+ routing table. For example,
if 9:3::1/64 does not exist in the BGP routing table, BGP4+ does not advertise the aggregated
route even after the aggregate 9:3::1 64 command is run to aggregate this route.
When configuring manual aggregation of routes, you can apply various routing policies and set
the route attributes.
----End
9.4.4 Configuring BGP4+ to Import and Filter External Routes

After BGP4+ filters the imported routes, only the eligible routes are added to the local BGP4+
routing table and advertised to BGP4+ peers.

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
default-route imported
BGP4+ is configured to import the default routes.
If the default-route imported command is not used, you cannot import the default routes from
other protocols by using the import-route command.
Step 5 Run:
import-route protocol [ process-id ] [ med med | route-policy route-policy-name ] *
BGP4+ is configured to import routes of other protocols.
NOTE
Specify the process ID when the routes of a dynamic routing protocol are imported.
Step 6 Run:
filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name }
export [ protocol [ process-id ] ]
Imported routes are filtered.
After BGP4+ filters the imported routes, only the eligible routes are added to the BGP4+ local
routing table and advertised to BGP4+ peers. If protocol [ process-id ] is specified, the routes
of the specific routing protocol are filtered. If protocol [ process-id ] is not specified, all the local
BGP routes to be advertised are filtered, including the imported routes and the local routes
advertised through the network command.
----End
9.4.5 Configuring Routers to Advertise a Default Route to a Peer

A router sends a default route with the local address being the next hop to the specified peer,
regardless of whether there are default routes in the local routing table.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
ipv6-family unicast
Step 4 Run:
peer { ipv6-address | group-name } default-route-advertise [ route-policy route-
policy-name ]
Default routes are advertised to peers (or a peer group).
If route-policy route-policy-name is set, the BGP device changes attributes of a default route
based on the specified route-policy.
NOTE
After the command peer default-route-advertise is run, the router sends a default route with the local
address as the next hop to the specified peer, regardless of whether there are default routes in the routing
table.
----End
9.4.6 Configuring the Policy for Advertising BGP4+ Routing

Information
After the policy for advertising routes is configured, only the routes that match the policy can
be added to the local BGP4+ routing table and advertised to BGP4+ peers.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run the following command to configure the outbound routing policy based on the following
different filters:
l Based on the export policy
Run:

filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-

name } export [ protocol [ process-id ] ]
l Based on the routing policy

Run:
peer { ipv4-address | ipv6-address | group-name } route-policy route-policy-
name export
l Based on the ACL

Run:
peer { ipv4-address | ipv6-address | group-name } filter-policy { acl6-number |
acl6-name acl6-name } export
l Based on the AS_Path list

Run:
peer { ipv4-address | ipv6-address | group-name } as-path-filter { as-path-
filter-number | as-path-filter-name } export
l Based on the prefix list

Run:
peer { ipv4-address | ipv6-address | group-name } ipv6-prefix ip-prefix-name
export
The commands in Step 4 can be run regardless of the order.

The outbound routing updates policies used by the members of a peer group can be different
from that used by the group. That is, members of each peer group can select their policies
when advertising routes externally.

1. Run:
quit

2. Run:
quit

3. Run

4. Run

as the rules.

by the system.
1. Run
config } ]

2. Run
name ] *

by the system.

----End
9.4.7 Configuring the Policy for Receiving BGP4+ Routing

Information
Only the routes that match the policy for receiving routes can be received by BGP4+ peers and
added to the routing table.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
l filter-policy { acl6-number | acl6-name acl6-name | ipv6-prefix ipv6-prefix-name } import
The imported global routes are filtered.
l peer { ipv4-address | ipv6-address | group-name } route-policy route-policy-name import
BGP is configured to filter the routes imported from the specified peers.
l peer { ipv4-address | ipv6-address | group-name } filter-policy { acl6-number | acl6-
name acl6-name } import
BGP is configured to filter the routes based on the ACL.
l peer { ipv4-address | ipv6-address | group-name } as-path-filter { as-path-filter-number |
as-path-filter-name } import
BGP is configured to filter the routes based on the AS path list.
l peer { ipv4-address | ipv6-address | group-name } ipv6-prefix ipv6-prefix-name import
BGP is configured to filter the routes based on the prefix list.
The commands in Steps 4 can be run regardless of the order.
The routes imported by BGP can be filtered, and only those routes that meet certain conditions
are received by BGP and added to the routing table.
The inbound routing policies used by the members in a peer group can be different from that
used by the group. That is, each peer can select its policy when importing routes.


1. Run:
quit

2. Run:
quit

3. Run

4. Run

as the rules.
by the system.
1. Run
config } ]


2. Run
name ] *

by the system.
----End
9.4.8 Configuring BGP4+ Soft Resetting

When routing policies are changed, the system can refresh the BGP4+ routing table dynamically
without interrupting BGP4+ connections.
Procedure
l Enabling the Route-refresh Capability
1. Run:
system-view

2. Run:

3. Run:
peer { ipv4-address | ipv6-address | group-name } capability-advertise
{ route-refresh | 4-byte-as }

The route-refresh capability is enabled.
By default, the route-refresh capability is enabled.
If the route-refresh capability is enabled on all the BGP4+ devices, the local device
advertises the route-refresh messages to its peer if the BGP4+ route policies change.
The peer receiving this message sends its routing information to the local device again.
In this way, the BGP4+ routing table is updated dynamically and the new policies are
applied without interrupting the BGP4+ connections.
l Keeping All Route Updates of Peers
1. Run:
system-view

2. Run:

3. Run:

4. Run:
peer { ipv4-address | ipv6-address | group-name } keep-all-routes
All route updates of the peers are kept.
After this command is run, all the route updates of the specified peer are kept regardless
of whether the filtering policies are used. When the BGP connections are soft reset,
this information can be used to generate the BGP4+ routes.
l Soft Resetting a BGP4+ Connection Manually
1. Run:
refresh bgp ipv6 { all | ipv4-address | ipv6-address | group group-name |
external | internal } { export | import }
A BGP4+ connection is soft reset.
A BGP4+ connection must be soft reset in the user view.
----End

After the advertising and receiving of BGP4+ routes are controlled, you can check the advertised
routes that match the specified filter.
Prerequisites
Controlling the advertising and receiving of BGP4+ routing information has been configured.
Procedure
l Run the display bgp ipv6 network command to check the routes advertised through the
network command.

l Run the display bgp ipv6 routing-table as-path-filter { as-path-filter-number | as-path-

filter-name } command to check the routes matching the specified AS-Path filter.
l Run the display bgp ipv6 routing-table community-filter { { community-filter-name |
basic-community-filter-number } [ whole-match ] | advanced-community-filter-number }
command to check the routes matching the specified BGP4+ community filter.
l Run the display bgp ipv6 routing-table peer { ipv4-address | ipv6-address } { advertised-
routes | received-routes } [ statistics ] command to check the routing information
advertised or received by the BGP4+ peers.
----End
9.5 Configuring Parameters of a Connection Between BGP4

+ Peers
By setting parameters of a connection between BGP4+ peers, you can adjust and optimize the
BGP4+ network performance.

Before configuring parameters of a connection between BGP4+ peers, familiarize yourself with
the usage scenario, complete the pre-configuration tasks, and obtain the required data. This can
help you complete the configuration task quickly and accurately.
After a BGP4+ connection is set up between peers, the peers periodically send Keepalive
messages to each other. This prevents the routers from considering that the BGP4+ connection
is closed. If a router does not receive any Keepalive message or any type of packets from the
peer within the specified Hold time, the BGP4+ connection is considered as closed.
When a router sets up a BGP4+ connection with its peer, the router and the peer need negotiation
with each other. The Hold time after negotiation is the shorter one between the Hold time of the
router and that of its peer. If the negotiation result is 0, no Keepalive message is transmitted and
whether the Hold timer expires is not detected.
If the value of the timer changes, the BGP4+ connection is interrupted for a short time as the
router and its peer need negotiate again.
A ConnectRetry timer is used to set the interval between BGP4+ attempts to initiate TCP
connections. After BGP4+ initiates a TCP connection, the ConnectRetry timer is stopped if the
TCP connection is established successfully. If the first attempt to establish a TCP connection
fails, BGP4+ tries again to establish the TCP connection after the ConnectRetry timer expires.
You can speed up or slow down the establishment of BGP4+ peer relationships by changing the
BGP4+ ConnectRetry interval. For example, if the ConnectRetry interval is reduced, BGP4+
will wait less time to retry establishing a TCP connection when an earlier attempt fails. This
speeds up the establishment of the TCP connection. If a BGP4+ peer flaps constantly, the
ConnectRetry interval can be increased to suppress route flapping caused by BGP4+ peer
flapping. This speeds up route convergence.

Before configuring the parameters of a connection between BGP4+ peers, complete the
following tasks:
Data Preparation
To configure the parameters of a connection between BGP4+ peers, you need the following data.
No. Data
1 Values of the BGP4+ timers
2 Interval for sending the update packets
3 BGP4+ ConnectRetry interval
9.5.2 Configuring BGP4+ Timers

Configuring timers properly can improve network performance. Changing the values of BGP4
+ timers will interrupt the peer relationship.
Context
NOTICE
As the change of the timer (with the peer timer command) tears down the BGP peer relationship
between routers. Exercise caution when running this command.
Procedure
l Configure BGP4+ timers for all peers or peer groups.
1. Run:
system-view

2. Run:

3. 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 and is not less than one second. If the holdtime is not set to 0, it is 3s at least.
By default, the keepalive-time value is 60s and the hold-time value is 180s.
NOTE
When setting values of keepalive-time and hold-time, note the following points:
– The keepalive-time and hold-time values cannot be both set to 0. Otherwise, the
BGP timers become invalid, meaning that BGP will not send Keepalive messages
to detect connection status.
– The hold-time value cannot be much greater than the keepalive-time value. For
example, keepalive-time cannot be set to 1 while hold-time is set to 65535. If the
hold-time value is too large, BGP cannot detect connection status in time.
After a connection is established between peers, the keepalive-time and hold-time
values are negotiated by the peers. The smaller one of the hold-time values carried by
Open messages of both peers is taken as the hold-time value. The smaller of one third
of the hold-time value and the locally configured keepalive-time value is taken as the
keepalive-time value.
If the local device establishes BGP peer relationships with many devices, it needs to
process huge BGP messages. If hold-time negotiated among BGP peers is small, the
timer may expire before the local device processes the Keepalive messages sent from
other BGP peers. The peer relationships are then interrupted, and routes flap. To solve
the preceding problem, you can configure an appropriate value for min-holdtime min-
holdtime based on the CPU processing capability of the local device.
If the value of min-holdtime is changed, but the values of keepalive-time and hold-
time negotiated between two BGP peers remain unchanged, the established peer
relationship is not affected. Only when the local device attempts to re-establish a
relationship with a remote device, the value of min-holdtime configured on the local
device takes effect. The local device compares min-holdtime with hold-time sent from
the remote device. If the value of min-holdtime exceeds that of hold-time, hold-time
negotiation fails, and the peer relationship fails to be established.
NOTE
If min-holdtime is configured on the local device, and the value of hold-time sent from the
remote device is 0, hold-time negotiation between the two devices succeeds. The negotiated
value of hold-time is 0, and the peer relationship is established. The value 0 of hold-time
indicates that the peer relationship never expires.
l Configure timers for a specific peer or peer group.
1. Run:
system-view

2. Run:

3. Run:
peer { ipv6-address | group-name } timer keepalive keepalive-time hold
hold-time [ min-holdtime min-holdtime ]

The Keepalive and hold timer values are set for a specific peer or peer group.
For information about the relationship between the keepalive-time and hold-time
values, see Configure BGP4+ timers for all peers or peer groups.
NOTE
Timers set for a specific peer or peer group takes precedence over timers set for all
peers or peer groups.
----End
9.5.3 Configuring the Interval for Sending Update Packets

When a route changes, a router sends an Update packet to notify its peer. If a route changes
frequently, to prevent the router from sending Update packets for every change, you can set the
interval for sending Update packets for changes of this route.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

Step 4 Run:
peer ipv6-address route-update-interval interval
The interval for sending update packets is set.

By default, the update interval is 15 seconds for the IBGP peers and the update interval is 30
seconds for the EBGP peers.
----End
9.5.4 Setting the BGP4+ ConnectRetry Interval

You can speed up or slow down the establishment of BGP4+ peer relationships to adapt the
network changes by changing the BGP4+ ConnectRetry interval.
Context
When BGP4+ initiates a TCP connection, the ConnectRetry timer is stopped if the TCP
connection is established successfully. If the first attempt to establish a TCP connection fails,
BGP4+ tries again to establish the TCP connection after the ConnectRetry timer expires. The
ConnectRetry interval can be adjusted as needed.

l The ConnectRetry interval can be reduced in order to lessen the time BGP4+ waits to retry
establishing a TCP connection after the first attempt fails.
l To suppress route flapping caused by constant peer flapping, the ConnectRetry interval can
be increased to speed up route convergence.
Procedure
l Set a ConnectRetry interval globally.
1. Run:
system-view

2. Run:

3. Run:
timer connect-retry connect-retry-time
A BGP4+ ConnectRetry interval is set globally.

By default, the ConnectRetry interval is 32s.
l Set a ConnectRetry interval on a peer or peer group.
1. Run:
system-view

2. Run:

3. Run:
peer { group-name | ipv6-address } timer connect-retry connect-retry-time
A ConnectRetry interval is set on a peer or peer group.

By default, the ConnectRetry interval is 32s.
The ConnectRetry interval configured on a peer or peer group takes precedence over
a global ConnectRetry interval.
----End
9.5.5 Configuring the Rate at which BGP4+ Updates Routes in

Response to Non-critical Iteration Changes
You can configure the rate at which BGP4+ updates routes in response to non-critical iteration
changes to prevent BGP4+ from occupying the Central Processing Unit (CPU) resource of other
protocols, reduce CPU loads, and ensure device reliability.
Context
In most cases, BGP4+ routes do not have directly reachable next hops, and route iteration must
be used. When many BGP4+ routes are iterated to one next hop and a non-critical iteration

change occurs on the next hop, such as a change of IGP metric or the number of load balancing
routes, an indirect next hop-enabled device can update forwarding entries rapidly. In this
situation, BGP4+ does not need to update routes one by one, and you can configure the rate at
which BGP4+ updates routes in response to non-critical iteration changes to allow the device to
update BGP4+ routes in the IPv6 routing table gradually. This configuration prevents BGP4+
from occupying the CPU resource of other protocols, reduces CPU loads, and ensures device
reliability.
Before configuring the rate at which BGP4+ updates routes in response to non-critical iteration
changes, complete the following task:
Data Preparation
To configure the rate at which BGP4+ updates routes in response to non-critical iteration
changes, you need the following data.
No. Data
1 Interval at which BGP updates routes in response to non-critical iteration changes and
the number of routes that are updated during the interval
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
nexthop recursive-lookup non-critical-event route-update-timer route-update-timer
[ route-update-number route-update-number ]
The rate at which BGP4+ updates routes in response to non-critical iteration changes is
configured.
By default, the rate at which BGP updates routes in response to non-critical iteration changes is
not configured.
If route-update-number route-update-number is configured, the number of routes that are

updated each second is route-update-number/route-update-timer. For example, route-update-

timer is 5 and route-update-number is 1000, the number of routes that are updated each second
is 200.
NOTE
When many BGP4+ routes are iterated to one next hop and a non-critical iteration change occurs on the
next hop, if the nexthop recursive-lookup non-critical-event route-update-timer command is
configured, the BGP4+ route convergence is slowed down. Before BGP4+ updates all routes associated
with the next hop, the IP routing table shows iteration information before the update. However, the
forwarding entries have been updated, and traffic is forwarded along the correct path.
The nexthop recursive-lookup non-critical-event route-update-timer command does not take effect to
critical iteration changes on a next hop, and for example, the reachability of the next hop changes due to
interface flapping.
----End

After parameters of a connection between BGP4+ peers are configured, you can check BGP4+
peers and peer groups.
Prerequisites
Parameters of a connection between BGP4+ peers has been configured.
Procedure
l Run the display bgp ipv6 peer ipv4-address verbose command to check detailed
----End
Example
Run the display bgp ipv6 peer ipv6-address verbose command in the system view. You can
view the configured Keepalive period, holdtime, ConnectRetry interval, and interval at which
Update packets are sent.
<RouterB> display bgp peer 2001:db8:1::1 verbose
BGP Peer is 2001:db8:1::1, remote AS 100

Type: IBGP link
Update-group ID: 1
Configured: Min Hold Time: 150 sec


Update messages 0
Open messages 1
Refresh messages 0
Update messages 0
Open messages 1
Refresh messages 0
9.6 Configuring BFD for BGP4+

By configuring BFD for BGP4+, you can provide a fast fault detection mechanism for BGP4+,
and therefore speed up network convergence.

Before configuring BFD for BGP4+, familiarize yourself with the usage scenario, complete the
BFD can rapidly detect IPv6 forwarding failures. By adopting the BFD fast detection
mechanism, an IPv6 network can transmit voice services, video services, and VoD services with
high QoS. This enables service provides to provide their customers with highly available and
reliable voice over IP (VoIP) and other real-time services.
BGP periodically sends Keepalive messages to the peer to detect faults on the neighbor. This
mechanism, however, takes more than one second to detect a fault. When the data rate is up to
Gbit/s, the detection mechanism causes a great packet loss. This mechanism fails to meet the
requirement on the reliability of core networks.
BGP introduces BFD for BGP4+. The fast detection mechanism of BFD can faster detect faults
on the links between BGP peers. The convergence of networks therefore speeds up.
Before configuring BFD for BGP4+, complete the following tasks:

l Configuring link layer protocol parameters and assigning IP addresses to the interfaces to
ensure that the status of the link layer protocol of the interface is Up
Data Preparation
To configure BFD for BGP4+, you need the following data.
No. Data
1 Type and number of the interface on which BFD is enabled
2 Related BFD detection parameters, including the minimum interval and the
maximum interval for receiving BFD control packets, and the detection time
multiplier
9.6.2 Configuring BFD for BGP4+ in the Public Network Instance

By configuring BFD for BGP4+, you can fast detect the BGP4+ route status. A BFD session
can be established only when two BGP4+ peers are in the Established state.
Context
Perform the following steps on BGP4+ devices at the two ends of a link on which a BFD session
needs to be set up:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Global BFD is enabled on the node.
Step 3 Run:
quit
Back to the system view.
Step 4 Run:
Step 5 Run:
BFD is configured for a peer or a peer group and the BFD session is set up.


If BFD is configured on a peer group, peers that belong to the group set up BFD sessions when
the peer bfd block command is not used on the peers.
NOTE
l A BFD session is set up only when the BGP session is in the Established state.
l If BFD parameters of a peer are set, the BFD session is set up by using BFD parameters of the peer.

The parameters used to set up a BFD session are specified.
NOTE
NOTE
For example:
Then:
by 5.
by 4.


The peer is prevented from inheriting BFD of its group.
If a peer joins a group enabled with BFD, the peer inherits BFD of the group and creates a BFD
session. If you do not want the peer to inherit BFD of the group, you can prevent the peer from
inheriting BFD of its group.
NOTE
The peer bfd block command is exclusive with the peer bfd enable command. After the peer bfd
block command is used, the BFD session is automatically deleted.
----End
9.6.3 Configuring BFD for BGP4+ in a Private Network

On an IPv6 VPN network, configuring BFD for BGP4+ can fast detect the status of VPN BGP4
+ routes. A BFD session can be established only when two BGP4+ peers are in the Established
state.
Context
Perform the following steps on the BGP devices at the both ends of the link that needs to set up
a BFD session:
Procedure
Step 1 Run:
system-view
Step 2 Run:
bfd
Global BFD is enabled on the node.
Step 3 Run:
quit
Back to the system view.
Step 4 Run:
Step 5 Run:
The BGP-VPN6 instance view is displayed.
Step 6 Run:

BFD is configured for a peer or a peer group and the BFD session is set up.

If BFD is configured on a peer group, peers that belong to the group set up BFD sessions when
the peer bfd block command is not used on the peers.
NOTE
l A BFD session is set up only when the BGP session is in the Established state.
l If BFD parameters of a peer are set, the BFD session is set up by using BFD parameters of the peer.

The parameters used to set up a BFD session are specified.
NOTE
NOTE
For example:
Then:
by 5.
by 4.


The peer is prevented from inheriting BFD of its group.
If a peer joins a group enabled with BFD, the peer inherits BFD of the group and creates a BFD
session. If you do not want the peer to inherit BFD of the group, you can prevent the peer from
inheriting BFD of its group.
NOTE
The peer ipv6-address bfd block command is exclusive with the peer { group-name | ipv6-address }
bfd enable command. After the peer bfd block command is used, the BFD session is automatically deleted.
----End

After BFD for BGP4+ is configured, you can check the BFD sessions established by BGP4+.
Prerequisites
BFD for BGP4+ has been configured.
Procedure
l Run the display bgp ipv6 bfd session { [ vpnv6 vpn-instance vpn-instance-name ] peer
ipv6-address | all } command to check the BFD sessions established by BGP4+.
l Run the display bgp [ vpnv6 vpn-instance vpn-instance-name ] peer [ [ ipv6-address ]
verbose ] command to check BGP4+ peers.
l Run the display bgp ipv6 group [ group-name ] command to check BGP peer groups.
l Run the display bgp vpnv6 { all | vpn-instance vpn-instance-name } group [ group-
name ] command to check BGP4+ peer groups.
----End
9.7 Configuring BGP4+ PeerTracking

On a network where BFD is unsuitable to deploy, you can configure BGP4+ peer tracking to
implement the fast convergence of IBGP routes.

Before configuring BGP4+ peer tracking, familiarize yourself with the usage scenario, complete

Since BFD is difficult to deploy and is of poor scalability, in a network where BFD is unsuitable
to be deployed, you can configure BGP4+ peer tracking as a substitution for BFD to implement
the fast convergence of BGP4+ routes.
BGP4+ peer tracking is easy to deploy because it needs to be configured only on the local device,
without the need of configuring it on the peer device. However, BGP4+ route convergence in a
network configured with BGP4+ peer tracking is slower than that in a network enabled with
BFD; therefore, BGP4+ peer tracking cannot meet the requirement of voice services that demand
high convergence speed.
Before configuring BGP4+ peer tracking, complete the following tasks:
l Configuring basic BGP4+ functions
Data Preparation
To configure BGP4+ peer tracking, you need the following data.
No. Data
1 (Optional) Delay for tearing down a connection
9.7.2 Enabling BGP4+ Peer Tracking

Easy to deploy, BGP4+ peer tracking can speed up network convergence and adjust the interval
between a peer's being discovered unreachable and the connection's being torn down.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { group-name | ipv6-address } tracking [ delay delay-time ]
BGP4+ peer tracking is enabled for the specified peer.
By default, BGP4+ peer tracking is disabled.
A proper value of delay-time can ensure network stability when a peer is detected unreachable.

l If delay-time is set to 0, BGP immediately tears down the connection between the local device
and its peer after the peer is detected unreachable.
l If IGP route flapping occurs and delay-time for an IBGP peer is set to 0, the peer relationship
between the local device and the peer alternates between Up and Down. Therefore, delay-
time for an IBGP peer should be set to a value greater than the actual IGP route convergence
time.
l When BGP neighbors successfully perform the GR negotiation, the active/standby
switchover occurs on the BGP neighbors, to prevent the failure of GR, delay-time should be
set to a value greater than GR period. If delay-time is set to be smaller than the GR period,
the connection between the local device and the BGP peer will be torn down, which leads to
the failure of GR.
----End

After BGP4+ peer tracking is configured, you can check the configuration of BGP4+ peer
tracking by viewing detailed information about the BGP peer or peer group.
Prerequisite
All BGP4+ peer tracking configurations are complete.

Run the following commands to check the previous configuration.
l Run the display bgp ipv6 peer [ [ ipv6-address ] verbose ] command to check information
about the BGP4+ peer.
l Run the display bgp ipv6 group [ group-name ] command to check information about the
BGP4+ peer group.
9.8 Configuring BGP4+ Route Dampening

By configuring BGP4+ route dampening, you can suppress unstable BGP4+ routes.

Before configuring BGP4+ route dampening, familiarize yourself with the usage scenario,
BGP4+ dampening can suppress unstable routes. BGP4+ neither adds the unstable routes to the
routing table nor advertises them to other BGP peers.
Before configuring BGP4+ route dampening, complete the following task:

Data Preparation
To configure BGP4+ route dampening, you need the following data.
No. Data
1 Various parameters of dampening, including half-life of a reachable route, half-life

of an unreachable route, threshold for freeing the suppressed routes, threshold for
suppressing routes, and upper limit of the penalty
9.8.2 Enabling BGP4+ Route Dampening

BGP4+ route dampening can improve network stability. You can flexibly use routing policies
for route dampening.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
dampening [ half-life-reach reuse suppress ceiling | route-policy route-policy-
name ] *
The parameters are configured for BGP4+ route dampening.
----End

After BGP4+ route dampening is configured, you can check BGP4+ suppressed routes,
parameters of BGP4+ route dampening, and flapped routes.
Prerequisites
BGP4+ route dampening has been configured.

Procedure
l Run the display bgp ipv6 routing-table dampened command to check BGP4+ dampened
routes.
l Run the display bgp ipv6 routing-table dampening parameter command to check the
configuration parameters of BGP4+ dampening.
l Run the display bgp ipv6 routing-table flap-info [ regular-expression as-regular-
expression | as-path-filter { as-path-filter-number | as-path-filter-name } | network-
address [ prefix-length [ longer-match ] ] ] command to check the statistics of BGP4+
route flapping.
----End
9.9 Configuring BGP4+ Load Balancing

Configuring BGP4+ load balancing better utilizes network resources and reduces network
congestion.
Usage Scenario
On large networks, there may be multiple valid routes to the same destination. BGP, however,
advertises only the optimal route to its peers. This may result in unbalanced traffic on different
routes.
Either of the following methods can be used to address the problem of unbalanced traffic:
l Use BGP routing policies to allow traffic to be balanced. For example, use a routing policy
to modify the Local_Pref, AS_Path, Origin, and Multi_Exit Discriminator (MED) attributes
of BGP routes to direct traffic to different forwarding paths for load balancing. For details
on how to modify attributes of BGP routes, see Configuring BGP4+ Route Attributes.
l Use multiple paths for load balancing. In this method, multiple equal-cost routes need to
be configured for traffic load balancing.
NOTE
Equal-cost BGP routes can be generated for traffic load balancing only when the first 9 route attributes
described in "Principles of Route Selection" in BGP Features Supported by the NE80E/40E are
the same, and the AS_Path attributes are also the same.
Before configuring BGP4+ load balancing, configure basic BGP4+ functions.
Data Preparation
To configure BGP4+ load balancing, you need the following data.
No. Data
1 Number of BGP4+ routes to be used for load balancing

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
The number of BGP4+ routes to be used for load balancing is set.
By default, the number of BGP4+ routes to be used for load balancing is 1, meaning that load
balancing is not implemented.
l ebgp indicates that load balancing is implemented only among EBGP routes.
l ibgp indicates that load balancing is implemented only among IBGP routes.
l If neither ebgp nor ibgp is specified, both EBGP and IBGP routes participate in load
balancing, and the number of EBGP routes to be used for load balancing is the same as the
number of IBGP routes to be used for load balancing.
NOTE
The maximum load-balancing number command cannot be configured together with the maximum load-
balancing ebgp number or maximum load-balancing ibgp number command.
When routes with the same destination addresses carry out load balancing on the public network, the system
determines the type of optimal routes first. 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.

The device has been configured whether to change the next hop addresses of the routes to be
advertised to a local address.
If you run the maximum load-balancing number command, the device changes the next hop
addresses of the routes to be advertised to a local address no matter whether the routes are used
for load balancing.
If you run the maximum load-balancing [ ebgp | ibgp ] number command, the device does not
change the next hop addresses of the routes to be advertised to a local address no matter whether
the routes are used for load balancing.


The router is configured not to compare the AS_Path attributes of the routes to be used for load
balancing.
By default, the router compares the AS_Path attributes of the routes to be used for load balancing.
NOTE
l If there are multiple routes to the same destination but these routes pass through different ASs, load
balancing cannot be implemented among these routes by default. To implement load balancing among
these routes, run the load-balancing as-path-ignore command. After the load-balancing as-path-
ignore command is run, the device no longer compares the AS_Path attributes of the routes to be used
for load balancing. Therefore, exercise caution when using this command.
l The load-balancing as-path-ignore and bestroute as-path-ignore commands are mutually exclusive.
----End

After the BGP4+ load balancing configurations are complete, you can run the following
commands to check the configurations.
l Run the display bgp ipv6 routing-table [ ipv6-address prefix-length ] command to check
routing information in an IPv6 BGP routing table.
l Run the display ipv6 routing-table [ verbose ] command to view the IPv6 routing table.
# Display the routing information in an IPv6 BGP routing table.

<HUAWEI> display ipv6 routing-table vpn-instance vpn1


MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
NextHop : 2001:db8:2001::2 LocPrf :
MED : PrefVal : 0
Label :
Path/Ogn : 200 ?
*
MED : PrefVal : 0
Label :
Path/Ogn : 200 ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?

MED : 0 PrefVal : 0
Label :
Path/Ogn : 200 ?

MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?

MED : 0 PrefVal : 0
Label :
Path/Ogn : 200 ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : 200 ?
*
MED : PrefVal : 0
Label :
Path/Ogn : 200 ?
MED : PrefVal : 0
Label :
Path/Ogn : 200 ?
*
MED : 0 PrefVal : 0
Label :
Path/Ogn : 200 ?
MED : 0 PrefVal : 0
Label :
Path/Ogn : ?
# Display the routing information in the IPv6 routing table.

<HUAWEI> display ipv6 routing-table


Cost : 0 Protocol : EBGP











9.10 Configuring a BGP4+ Peer Group

By configuring a BGP4+ peer group, you can simplify the management of routing policies, and
therefore improve the efficiency of route advertisement.


Before configuring a BGP4+ peer group, familiarize yourself with the usage scenario, complete
A great number of peers exist in a large-scale BGP4+ network, which is not convenient for
configuration and maintenance. In this case, you can configure peer groups to simplify the
management and improve the efficiency of route advertisement. According to the AS where the
peers reside, you can classify peer groups into IBGP peer groups and EBGP peer groups. You
can classify EBGP peer groups into pure EBGP peer groups and mixed EBGP peer groups. This
classification is performed according to the position of the peers in the same external AS.
Before configuring a BGP4+ peer group, complete the following task:
Data Preparation
To configure a BGP4+ peer group, you need the following data.
No. Data
1 Type, name of the peer group, and the member peers
9.10.2 Creating an IBGP Peer Group

When BGP4+ has multiple IBGP peers, you can create an IBGP peer group to simplify the
management of routing policies. When creating an IBGP peer group, you do not need to specify
the AS number.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
group group-name [ internal ]
A peer group is created.

Step 4 Run:
Step 5 Run:
peer group-name enable
The peer group is enabled.
Step 6 Run:
The IPv6 peers are added to the peer group.
NOTE
After an IBGP peer is added to a peer group, the system automatically creates the IPv6 peer in the BGP
view. Besides, the system enables this IBGP peer in the IPv6 address family view.
----End
9.10.3 Creating a Pure EBGP Peer Group

When BGP4+ has multiple EBGP peers that belong to the same AS, you can create an EBGP
peer group to simplify the management of routing policies. All the peers in a pure EBGP peer
group must have the same AS number.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
A pure EBGP peer group is configured.
Step 4 Run:
peer group-name as-number { as-number-plain | as-number-dot }
The AS number of the peer group is set.
Step 5 Run:
Step 6 Run:

Step 7 Run:
The IPv6 peer is added to the peer group.

After an EBGP peer is added to the peer group, the system automatically creates the EBGP peer
in the BGP view. Besides, the system enables this EBGP peer in the IPv6 address family view.
When creating a pure EBGP peer group, you need to specify the AS number of the peer group.
If there are peers in the peer group, you cannot specify the AS number for this peer group.
----End
9.10.4 Creating a Mixed EBGP Peer Group

When BGP4+ has multiple EBGP peers that belong to different ASs, you can create a mixed
EBGP peer group to simplify the management of routing policies. When creating a mixed EBGP
peer group, you need to specify the AS number for each peer.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
A mixed EBGP peer group is created.

Step 4 Run:
The AS number of the IPv6 peer is set.

Step 5 Run:

Step 6 Run:

Step 7 Run:
The IPv6 peers created are added to this peer group.

After an EBGP peer is added to the peer group, the system automatically enables each EBGP
peer in the IPv6 address family view.

When creating a mixed EBGP peer group, you need to create peers separately, and you can
configure different AS numbers for them, but cannot configure the AS number for the peer group.
----End

After a BGP4+ peer group is configured, you can check detailed information about the BGP4+
peer and information about the BGP4+ peer group.
Prerequisites
A BGP4+ peer group has been configured.
Procedure
l Run the display bgp ipv6 group [ group-name ] command to check information about the
IPv6 peer group.
----End
9.11 Configuring a BGP4+ Route Reflector

By configuring a BGP4+ route reflector, you can solve the problem of establishing fully meshed
connections between multiple IBGP peers.

Before configuring a BGP4+ route reflector (RR), familiarize yourself with the usage scenario,
To ensure the connectivity between IBGP peers inside an AS, you need to establish full-meshed
IBGP peers. When there are many IBGP peers, establishing a full-meshed network costs a lot.
The route reflector or the confederation can be used to solve this problem.
Before configuring a BGP4+ route reflector, complete the following task:
l 9.2 Configuring Basic BGP4+ Functions
Data Preparation
To configure a BGP4+ route reflector, you need the following data.
No. Data
1 Roles of each router (reflector, client, and non-client)

9.11.2 Configuring a Route Reflector and Specifying Clients

A route reflector and clients need to be configured in a specified address family.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
peer { ipv4-address | ipv6-address | group-name } reflect-client
The route reflector and its clients are configured.
The router on which this command is run serves as the route reflector. In addition, this command
specifies the peers that serve as its clients.
----End
9.11.3 (Optional) Disabling a Route Reflection Between Clients

If the clients of a route reflector are fully meshed, you can disable route reflection between clients
to reduce the cost.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
Step 4 Run:
Route reflection between clients is disabled.

If the clients of the route reflector are full-meshed, you can use the undo reflect between-
clients command to disable the route reflection between the clients. This reduces cost.
By default, the route reflection between clients is enabled.
This command is used only on the reflector.
----End
9.11.4 (Optional) Configuring the Cluster ID for a Route Reflector

When there are multiple route reflectors in a cluster, you need to configure the same cluster ID
for all the route reflectors in this cluster to avoid routing loops.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

Step 4 Run:
reflector cluster-id cluster-id
The cluster ID of the route reflector is set.
NOTE
When there are multiple route reflectors in a cluster, you can use the command to configure all the route
reflectors in this cluster with the same cluster ID. This avoids routing loops.
----End
9.11.5 (Optional) Preventing BGP4+ Routes from Being Added into

the IPv6 Routing Table
Disabling BGP4+ route delivery to the IPv6 routing table on a route reflector (RR) can prevent
traffic from being forwarded by the RR, improving route advertisement efficiency.
Context
Usually, BGP4+ routes are delivered to the IPv6 routing table on the router to guide traffic
forwarding. If the router does not need to forward traffic, disable BGP4+ route delivery to the
IPv6 routing table on the router.
BGP4+ route delivery to the IPv6 routing table is generally disabled on RRs. An RR transmits
routes and forwards traffic within an AS. If the RR is connected to many clients and non-clients,

the route transmission task will consume a lot of central processing unit (CPU) resources of the
RR and cause the RR unable to implement traffic forwarding. To improve the efficiency of route
transmission, disable BGP4+ route delivery to the IPv6 routing table on the RR to make the RR
dedicated to route transmission.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:

Step 4 Run:
routing-table rib-only [ route-policy route-policy-name ]
BGP4+ route delivery to the IPv6 routing table is disabled.

The routes preferred by BGP4+ are delivered to the IPv6 routing table by default.
If route-policy route-policy-name is configured in the routing-table rib-only command, routes
matching the policy are not delivered to the IPv6 routing table, and routes not matching the
policy are delivered to the IPv6 routing table, with the route attributes unchanged.
NOTE
The routing-table rib-only command and the active-route-advertise command are mutually exclusive.
----End
9.11.6 (Optional) Enabling the RR to Modify the Route Attributes

Using the Export Policy
You can enable the route reflector (RR) to modify the route attributes using the export policy to
change route selection results of the BGP4+.
Context
According to RFC 4456, the route attributes on the RR cannot be modified using the export
policy. This is because it may cause route loops. By default, the RR is disabled from modifying
the route attributes using the export policy. But if you need to re-plan the network traffic, you
can enable the RR to modify the route attributes by using the export policy.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
ipv6-family unicast
Step 4 Run:
reflect change-path-attribute
You can enable the RR to modify the route attributes of the BGP4+ routes using the export
policy.
By default, you can disable the RR from modifying the route attributes using the export policy.
After you enable the reflect change-path-attribute command on an RR, the configurations of
the RR attributes modified using the export policy takes effect immediately. Perform the
l Run the apply as-path command to modify the AS_Path attributes of BGP4+ routes.
l Run the apply comm-filter delete command to delete all community attributes from a BGP4
+ route.
l Run the apply community command modifies the AS_Path attributes of BGP4+ routes.
l Run the apply cost command to modify the cost of BGP4+ routes, that is, to modify its
Multi_Exit Discriminator (MED).
l Run the apply ipv6 next-hop command to modify the next hop of BGP4+ routes.
l Run the apply local-preference command to modify the local preference of BGP4+ routes.
l Run the apply origin command to modify the Origin attributes of BGP4+ routes.
l Run the apply extcommunity command to modify the extended community attributes of
BGP4+ routes.
NOTE
After the reflect change-path-attribute command is run on the RR, the peer route-policy export
command takes precedence over the peer next-hop-invariable and peer next-hop-local commands.
----End

After a BGP4+ route reflector is configured, you can check BGP4+ route information and peer
group information.
Prerequisites
A BGP4+ route reflector has been configured.

Procedure
l Run the display bgp ipv6 peer [ verbose ] command to check information about BGP4+
peers.
BGP4+ peers.
information about BGP4+ peers.
----End
9.12 Configuring a BGP4+ Confederation

On a large-scale BGP4+ network, configuring a BGP4+ confederation can simplify the
management of routing policies and improve the efficiency of route advertisement.

Before configuring a BGP4+ confederation, familiarize yourself with the usage scenario,
The confederation is a method of handling the abrupt increase of IBGP connections in an AS.
The confederation divides an AS into multiple sub-ASs. In each sub-AS, IBGP peers can be
full-meshed or be configured with a route reflector. EBGP connections are set up between sub-
ASs.
Before configuring a BGP4+ confederation, complete the following task:
Data Preparation
To configure a BGP4+ confederation, you need the following data.
No. Data
1 Confederation ID and the sub-AS number
9.12.2 Configuring a BGP4+ Confederation Attribute

BGP4+ confederations deal with increasing IBGP connections in an AS.

Procedure
l Configuring a BGP4+ Confederation
1. Run:
system-view

2. Run:

3. Run:
confederation id { as-number-plain | as-number-dot }
The confederation ID is set.

4. Run:
confederation peer-as { as-number-plain | as-number-dot } &<1-32>
The sub-AS number of other EBGP peers connected to the local AS is set.
A confederation includes up to 32 sub-ASs. { as-number-plain | as-number-dot } is

valid for the confederation that it belongs to.
You must run the confederation id and confederation peer-as commands for all the
EBGP peers that belong to a confederation, and specify the same confederation ID for
them.
NOTE
The old speaker with 2-byte AS numbers and the new speaker with 4-byte AS numbers cannot
exist in the same confederation. Otherwise, routing loops may occur because AS4_Path does
not support confederations.
l Configuring the Compatibility of a Confederation
1. Run:
system-view

2. Run:

3. Run:
confederation nonstandard
The compatibility of the confederation is configured.
When the confederation of other devices does not conform to the RFC, you can use
this command to make standard devices be compatible with nonstandard devices.
----End

After a BGP4+ confederation is configured, you can check BGP4+ route information and
detailed peer information.

Prerequisites
A BGP4+ confederation has been configured.
Procedure
l Run the display bgp ipv6 peer [ verbose ] command to check detailed information about
BGP4+ peers.
----End
9.13 Configuring BGP4+ 6PE

By configuring BGP4+ 6PE, you can connect separated IPv6 networks through the MPLS
tunneling technology.

Before configuring BGP4+ IPv6 Provider Edge (6PE), familiarize yourself with the usage
6PE interconnects separated IPv6 networks at different locations by using the MPLS technology
in an IPv4 network. Multiple modes are used to connect separated IPv6 networks by using the
tunnel technology. The tunnel in 6PE mode supports the IPv4/IPv6 dual stacks on PEs of the
Internet Service Provider (ISP). It identifies IPv6 routes by using the label assigned by MP-BGP,
and implements IPv6 interworking through tunnels between PEs.
Before configuring BGP4+ 6PE, complete the following task:
l Establishing BGP4+ peer relationship between PEs and CEs

l Establishing tunnels between PEs
NOTE
MPLS label switched paths (LSPs), MPLS Local IFNET tunnels, MPLS TE tunnels, and GRE tunnels
are often used between PEs to transmit IPv6 packets. By default, a PE uses an MPLS LSP to transmit
IPv6 packets. If you want a PE to transmit IPv6 packets over an MPLS TE or a GRE tunnel, run the
tunnel-policy command to configure a tunnel policy on the PE and run the peer tnl-policy command
to apply the tunnel policy to IPv6 labeled routes. Then, IPv6 labeled routes will be able to be iterated
to these tunnels. If the MPLS LSPs, MPLS TE tunnels, and GRE tunnels are all unavailable, the PE
uses MPLS Local IFNET tunnels.
Data Preparation
To configure BGP4+ 6PE, you need the following data.
No. Data
1 IP address and AS number of a PE

9.13.2 Configuring a 6PE Peer

IPv6 Provider Edge (6PE) interconnects separated IPv6 networks at different locations by using
the MPLS tunneling technology in an existing IPv4 network.
Context
Perform the following steps on the PE supporting the IPv4/IPv6 dual stacks:
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The IP address and AS number of a PE that needs to be configured with 6PE are specified.
Step 4 Run:
ipv6-family unicast
Step 5 Run:
peer ipv4-address enable
A 6PE peer is configured in the IPv6 unicast address family view.
Step 6 Run:
peer ipv4-address label-route-capability
The capability of sending labeled routes is enabled.
----End
9.13.3 (Optional) Enabling 6PE Routes Sharing the Explicit Null

Label
By enabling IPv6 Provider Edge (6PE) routes sharing the explicit null label, you can save label
resources on 6PE devices.

Context
By default, the 6PE device applies for a label for each 6PE route. When a large number of 6PE
routes need to be sent, a large number of labels are required. This greatly wastes label resources
and causes IPv6 routes unable to be advertised due to the shortage of label resources.
After 6PE routes sharing the explicit null label is enabled, all 6PE routes to be sent to the same
6PE peer share the explicit null label 2.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ipv6-family unicast

Step 4 Run:
apply-label explicit-null
All 6PE routes to be sent to the same 6PE peer share the explicit null label.
If you run this command after a 6PE peer relationship is established, temporary packet loss
occurs.
----End

After BGP4+ IPv6 Provider Edge (6PE) is configured, you can check BGP4+ 6PE peer
information.
Prerequisites
BGP4+ 6PE has been configured.
Procedure
l Run the display bgp ipv6 peer [ verbose ] command to check detailed information about
BGP4+ peers.
----End
Example
Run the display bgp ipv6 peer [ verbose ] command on a PE. The command output shows the
BGP4+ peer relationship between the PE and a CE and the 6PE peer relationship between the
PE and the peer PE.

# Display BGP4+ peer information.

<PE> display bgp ipv6 peer

3.3.3.3 4 200 1248 1342 0 18:06:28 Established

1
2001:db8:1::1 4 100 32 35 0 00:27:20 Established
1
9.14 Configuring Inter-AS 6PE

Inter-AS IPv6 Provider Edge (6PE) allows you to connect separate IPv6 networks that connect
to different ASs over IPv4 tunnels, so that these IPv6 networks can communicate.

Before configuring inter-AS IPv6 Provider Edge (6PE), familiarize yourself with the usage
scenario, complete the pre-configuration tasks, and obtain the required data.
6PE interconnects separate IPv6 networks at different locations using MPLS tunnels on an
existing IPv4 network. Separate IPv6 networks can be connected using multiple tunneling
techniques. 6PE implements IPv4/IPv6 dual stack on service provider PEs and uses MP-BGP
to assign labels to IPv6 routes, enabling IPv6 networks to communicate over tunnels between
PEs.
In practical application, different metropolitan area networks (MANs) of a service provider or

collaborative backbone networks of different service providers often span multiple ASs. If
separate IPv6 networks connect to different ASs, deploy inter-AS 6PE for the IPv6 networks to
communicate.
Before configuring inter-AS 6PE, complete the following tasks:
l Establish BGP4+ peer relationships between PEs and CEs.

l Establish tunnels between PEs.

NOTE
l In inter-AS 6PE OptionB with Autonomous System Boundary Routers (ASBRs) as PEs, PEs
usually establish MPLS Label Switched Paths (LSPs), MPLS Local IFNET tunnels, MPLS TE
tunnels, or GRE tunnels between each other. By default, a PE uses an MPLS LSP to transmit
IPv6 packets. If you want a PE to transmit IPv6 packets over an MPLS TE or a GRE tunnel, run
the tunnel-policy command to configure a tunnel policy on the PE and run the peer tnl-policy
command to apply the tunnel policy to IPv6 labeled routes. Then, IPv6 labeled routes will be
able to be iterated to these tunnels. If the MPLS LSPs, MPLS TE tunnels, and GRE tunnels are
all unavailable, the PE uses MPLS Local IFNET tunnels.
l In inter-AS 6PE OptionB, PEs usually establish MPLS LSPs, MPLS TE tunnels, or GRE tunnels
with ASBRs; ASBRs usually establish MPLS LSPs, MPLS Local IFNET tunnels, MPLS TE
tunnels, or GRE tunnels with each other. By default, a PE or an ASBR uses an MPLS LSP to
transmit IPv6 packets. If you want a PE or an ASBR to transmit IPv6 packets over an MPLS TE
or a GRE tunnel, run the tunnel-policy command to configure a tunnel policy on the PE or ASBR
and run the peer tnl-policy command to apply the tunnel policy to IPv6 labeled routes. Then,
IPv6 labeled routes will be able to be iterated to these tunnels. If the MPLS LSPs, MPLS TE
tunnels, and GRE tunnels are all unavailable, the PE or ASBR uses MPLS Local IFNET tunnels.
l In inter-AS 6PE OptionC, PEs usually establish BGP LSPs with each other. ASBRs usually
establish MPLS LSPs, MPLS Local IFNET tunnels, MPLS TE tunnels, or GRE tunnels with PEs
or other ASBRs. By default, a PE or an ASBR uses an MPLS LSP to transmit IPv6 packets. If
you want a PE or an ASBR to transmit IPv6 packets over an MPLS TE or a GRE tunnel, run the
tunnel-selector command in the system view to configure a tunnel selector on the PE or ASBR
and run the tunnel-selector command in the BGP view to apply the tunnel selector to BGP-IPv4
labeled routes. If the MPLS LSPs, MPLS TE tunnels, and GRE tunnels are all unavailable, the
PE or ASBR uses MPLS Local IFNET tunnels.
Data Preparation
To configure inter-AS 6PE, you need the following data.
No. Data
1 IP addresses and AS numbers of PEs.
9.14.2 Configuring Inter-AS 6PE OptionB (with ASBRs as PEs)

Inter-AS IPv6 Provider Edge (6PE) OptionB (with ASBRs as PEs) enables separate IPv6
networks that connect to different ASs to communicate.
Context
Before configuring inter-AS 6PE OptionB with Autonomous System Boundary Routers
(ASBRs) as PEs, ensure that tunnels have been established between ASBRs to transparently
transmit IPv6 packets. The tunnels can be MPLS Label Switched Paths (LSPs) or MPLS Local
IFNET tunnels. By default, an ASBR uses an MPLS LSP to transmit IPv6 packets. If no MPLS
LSP is available, an ASBR uses an MPLS Local IFNET tunnel to transmit IPv6 packets. The
difference between an MPLS Local IFNET tunnel and an MPLS LSP is that the former does not
require you to enable MPLS LDP on interfaces used to connect PEs.
Perform the following steps on each PE to which separate IPv6 networks are connected:

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The IP address and AS number of the 6PE peer are specified.
Step 4 Run:
ipv6-family unicast
Step 5 Run:
The 6PE peer relationship is enabled in the IPv6 unicast address family view.
Step 6 Run:
The function to send labeled routes is enabled.

6PE routes to be sent to the same 6PE peer are configured to share the same explicit null label.
NOTE
If a 6PE peer relationship has been established, running this command will trigger PEs to re-allocate labels
and cause temporary packet loss.
By default, each 6PE route is assigned a label. The number of required labels is proportionate
to the number of 6PE routes to be sent to the 6PE peer. If a large number of 6PE routes are to
be sent, a large number of labels are required.
After 6PE routes to be sent to the same 6PE peer are configured to share the same explicit null
label, all the 6PE routes to be sent to 6PE peers share the same explicit null label 2. The number
of required labels is irrelevant to the number of 6PE routes to be sent. This configuration saves
label resources on 6PE devices.
----End
9.14.3 Configuring Inter-AS 6PE OptionB

Inter-AS IPv6 Provider Edge (6PE) OptionB enables separate IPv6 networks that connect to
different ASs to communicate over an inter-AS OptionB network.

Context
Before configuring inter-AS 6PE OptionB, configure an inter-AS OptionB network to ensure
that tunnels can be established between Autonomous System Boundary Routers (ASBRs) and
between PEs and ASBRs. For configuration details, see "Configuring Inter-AS VPN OptionB"
in NE80E/40E Configuration Guide - VPN.
On an inter-AS OptionB network, labeled IPv6 routes are transmitted between PEs by means of
ASBRs. The PE and ASBR in the same AS establish an MP-IBGP peer relationship to exchange
labeled IPv6 routes. The ASBRs in two different ASs establish an MP-EBGP peer relationship
to exchange labeled IPv6 routes. After you configure an inter-AS OptionB network, establish
6PE peer relationships between the ASBRs in different ASs and between the PE and ASBR in
the same AS.
Perform the following steps on PEs and ASBRs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
The IP address and AS number of the 6PE peer are specified.
A PE only needs to establish an IBGP peer relationship with the ASBR in the same AS. An
ASBR must establish an IBGP peer relationship with the PE in the same AS and an EBGP peer
relationship with the ASBR in the other AS.
Step 4 Run:
ipv6-family unicast
Step 5 Run:
Step 6 Run:


NOTE
----End
9.14.4 Configuring Inter-AS 6PE OptionC

Inter-AS IPv6 Provider Edge (6PE) OptionC enables separate IPv6 networks that connect to
different ASs to communicate over an inter-AS OptionC network.
Context
Before configuring inter-AS 6PE OptionC, configure an inter-AS OptionC network to ensure
that end-to-end MPLS label switched paths (LSPs) can be established between PEs.
Two inter-AS 6PE OptionC solutions are available, depending on the establishment methods of
end-to-end LSPs.
l Solution 1: A local Autonomous System Boundary Router (ASBR) learns the labeled public
network BGP route from the peer ASBR, assigns a label to this route, and advertises this
route to its IBGP peer, a PE in the same AS. Then, a complete LSP is established between
the ingress and egress PEs on the public network. For more information, see "Configuring
Inter-AS VPN OptionC (Solution 1)" in NE80E/40E Configuration Guide - VPN.
l Solution 2: The IBGP peer relationship between the PE and ASBR in the same AS is not
needed. In this solution, a local ASBR learns the labeled public network BGP route from
the peer ASBR and imports this route to an IGP to trigger LDP LSP establishment. Then,
a complete LSP is established between the ingress and egress PEs on the public network.
For more information, see "Configuring Inter-AS VPN OptionC (Solution 2)" in NE80E/
40E Configuration Guide - VPN.
In an inter-AS 6PE OptionC scenario, PEs establish multi-hop MP-EBGP peer relationships to
exchange labeled IPv6 routes and establish end-to-end BGP LSPs to transmit IPv6 packets. The
way in which an end-to-end BGP LSP is established does not matter much to inter-AS 6PE
OptionC. After configuring an inter-AS OptionC network, perform the following steps on the
ingress and egress PEs that connect to separate IPv6 networks:
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
The IP address and AS number of the peer PE are specified.
Step 4 Run:
peer ipv4-address ebgp-max-hop [ hop-count ]
The maximum number of hops for an EBGP connection is set.
By default, a direct physical link must be available between EBGP peers. If such a link does not
exist, run the peer ebgp-max-hop command to allow EBGP peers to establish a TCP connection
over multiple hops.
If hop-count is not specified in the peer ebgp-max-hop command, 255 is used as the maximum
number of hops in EBGP connections.
Step 5 Run:
ipv6-family unicast
Step 6 Run:
Step 7 Run:

NOTE
----End


After inter-AS IPv6 Provider Edge (6PE) is configured, you can view BGP4+ peer information.
You can also view the IPv6 routes received from the peer CE.
Prerequisites
Inter-AS 6PE has been configured.
Procedure
Step 1 Run the display bgp ipv6 peer [ verbose ] command on a PE to check BGP4+ peer information.
Step 2 Run the display ipv6 routing-table command on a CE to check IPv6 route information.
----End
Example
Run the display bgp ipv6 peer [ verbose ] command on a PE. The command output shows the
BGP4+ peer relationship between the PE and a CE and the 6PE peer relationship between the
PE and an ASBR in the same AS or between the PE and the peer PE.
# Display BGP4+ peer information.

<PE> display bgp ipv6 peer


PrefRcv
5.5.5.5 4 200 38 39 0 00:34:02 Established 1

2001:db8:1::1 4 300 27 41 0 00:24:54 Established 1
Run the display ipv6 routing-table command on each CE. The command output shows the IPv6
routes received from the peer CE.
# Display IPv6 route information.

<CE> display ipv6 routing-table






Interface : LoopBack1 Flags : D



9.15 Configuring BGP4+ 6PE FRR

After you configure 6PE FRR on a device, the device can select a backup next hop for received
6PE routes. When the next hop of the primary route between PEs becomes unreachable, traffic
will be quickly switched to the backup next hop.

Before configuring BGP4+ IPv6 Provider Edge (6PE) FRR, familiarize yourself with the usage
scenario, pre-configuration tasks, and required data. This can help you complete the
6PE services are sensitive to the packet loss and delay. If high requirements are imposed on the
reliability of the IPv4/MPLS network that carries the 6PE services, you can enable 6PE FRR on
6PE devices.
Enabled with 6PE FRR, a 6PE device selects an optimal route and a sub-optimal route among
the routes with the same IP prefix from different 6PE peers. The optimal route serves as the
primary route, and the sub-optimal route serves as the backup route. When traffic forwarding
on the primary route fails, 6PE services can be quickly redirected to the backup next hop.
Before configuring 6PE FRR, complete the following tasks:
l Configuring a routing protocol on 6PE devices to enable the connectivity between devices
on the IPv4/MPLS network

l Configuring different IGP metrics on the IPv4/MPLS network to ensure that two routes of
different costs are generated between 6PE devices
Data Preparation
To configure 6PE FRR, you need the following data.
No. Data
1 IP address of each 6PE device and the number of AS to which it belongs
9.15.2 Configuring BGP4+ 6PE Peers

You need to configure BGP4+ IPv6 Provider Edge (6PE) peers to transmit 6PE routes on the
IPv4/MPLS network.
Context
For details, see Configuring BGP4+ 6PE.
9.15.3 Enabling 6PE FRR

After IPv6 Provider Edge (6PE) FRR is enabled, the system automatically selects the backup
next hop for 6PE routes. So, When the next hop of the primary route between PEs becomes
unreachable, the traffic can be quickly redirected to the backup next hop.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv6-family unicast
Step 4 Run:
auto-frr
The 6PE FRR function is enabled.
The function of the auto-frr command varies with the command configuration view. At present,
the auto-frr command configured in the BGP-IPv6 unicast address family view is valid only
for 6PE FRR.
Step 5 (Optional) Configure the function to prevent path-switchover-triggered packet loss.

In a 6PE FRR scenario, if the device on which FRR is configured completes refreshing
forwarding entries before the intermediate device on the primary path does so after the primary
path recovers, traffic may be temporarily lost after it switches back to the primary path from the
backup path. The severity of packet loss is proportional to the number of routes stored on the
intermediate device. To solve this problem, perform any of the following operations to prevent
path-switchover-triggered packet loss:
l In the BGP view of the intermediate device on the primary path, run:
out-delay delay-value
A delay for sending Update packets to all BGP peers is configured. An appropriate delay
ensures that traffic switches back to the primary path after the intermediate device on the
primary path completes refreshing forwarding entries.
l In the BGP IPv6 unicast address family view of the intermediate device on the primary path,
run:
peer { group-name | ipv6-address } out-delay delay-value
A delay for sending Update packets is configured. An appropriate delay ensures that traffic
switches back to the primary path after the intermediate device on the primary path completes
refreshing forwarding entries.
l In the BGP IPv6 unicast address family view of the device on which FRR is configured, run:
route-select delay delay-value
A delay for selecting a route to the intermediate device on the primary path is configured.
An appropriate delay ensures that traffic switches back to the primary path after the
intermediate device completes refreshing forwarding entries.
value value is 0, indicating that the device on which FRR is configured selects a route to the
intermediate device on the primary path without a delay.
----End

After IPv6 Provider Edge (6PE) FRR is configured, you can view information about the backup
next hop and backup label of the 6PE routes on 6PE devices.
Prerequisites
6PE FRR has been configured.

Procedure
l Run the display ipv6 routing-table ipv6-address [ prefix-length ] [ longer-match ]
verbose command to check the backup next hop, backup tunnel, and backup label in the
routing table.
----End
Example
Run the display ipv6 routing-table ipv6-address [ prefix-length ] [ longer-match ] verbose
command on the 6PE devices enabled with 6PE FRR to check the backup next hop, backup
tunnel, and backup label of 6PE routes in the routing table.
<HUAWEI> display ipv6 routing-table 2001:db8:2003::1 verbose
Routing Table :
Summary Count : 1

NextHop : ::FFFF:2.2.2.2 Preference : 255
Neighbour : ::2.2.2.2 ProcessID : 0
Label : 1033 Protocol : IBGP
State : Active Adv Relied Cost : 0
IndirectID : 0x4
Interface : Pos2/0/0 Flags : RD
BkNextHop : ::FFFF:3.3.3.3 BkInterface :
BkLabel : 1029 BkTunnelID : 0x0
BkPETunnelID : 0xd BkIndirectID : 0x3
9.16 Configuring BGP4+ Security

To improve BGP4+ security, you can perform TCP connection authentication.

Before configuring BGP4+ network security, familiarize yourself with the usage scenario,
l BGP4+ authentication
BGP4+ uses TCP as the transport layer protocol. To enhance BGP4+ security, you can
perform the Message Digest 5 (MD5) authentication when TCP connections are created.
The MD5 authentication, however, does not authenticate BGP4+ packets. Instead, it sets
MD5 authentication passwords for TCP connections, and the authentication is then
completed by TCP. If the authentication fails, TCP connections cannot be established.
NOTE
By default, authentication is not configured for BGP4+. Configuring authentication is recommended

to ensure system security.
l BGP4+ GTSM

The Generalized TTL Security Mechanism (GTSM) is used to prevent attacks by using the
TTL detection. If an attack simulates BGP4+ packets and sends a large number of packets
to a router, an interface through which the router receives the packets directly sends the
packets to BGP4+ of the control layer, without checking the validity of the packets. In this
manner, routers on the control layer process the packets as valid packets. As a result, the
system becomes busy, and CPU usage is high.
In this case, you can configure GTSM to solve the preceding problem. After GTSM is
configured on a router, the router checks whether the TTL value in the IP header of a packet
is in the pre-defined range after receiving the packet. If yes, the router forwards the packet;
if not, the router discards the packet. This enhances the security of the system.
NOTE
l The NE80E/40E supports BGP4+ GTSM.

l GTSM supports only unicast addresses; therefore, GTSM needs to be configured on all the routers
configured with routing protocols.
Before configuring BGP4+ security, complete the following task:
Data Preparation
Before configure BGP4+ security, you need the following data.
No. Data
1 BGP4+ peer address or name of the peer group of each router
2 MD5 authentication password
3 Key-Chain authentication name
9.16.2 Configuring MD5 Authentication

In Message Digest 5 (MD5) authentication of BGP4+, you only need to set MD5 authentication
passwords for TCP connections, and the authentication is performed by TCP. If the
authentication fails, TCP connections cannot be established.
Procedure
Step 1 Run:
system-view
Step 2 Run:

Step 3 Run:
peer { ipv6-address | group-name } password { cipher cipher-password | simple
simple-password }
The MD5 authentication password is configured.
NOTE
When configuring an authentication password, select the ciphertext mode because the password is saved
in configuration files in plaintext if you select simple mode, which has a high risk. To ensure device security,
change the password periodically.
When the peer password command is used in the BGP view, the extensions on Virtual Private Network
version 6 (VPNv6) of MP-BGP are also valid because they use the same TCP connection.
The BGP MD5 authentication and BGP Keychain authentication are mutually exclusive.
----End
9.16.3 Configuring Keychain Authentication

You need to configure Keychain authentication on both BGP4+ peers, and ensure that encryption
algorithms and passwords configured for Keychain authentication on both peers are the same.
Otherwise, TCP connections cannot be established between BGP4+ peers, and BGP4+ messages
cannot be exchanged.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
peer { ipv6-address | group-name } keychain keychain-name
The Keychain authentication is configured.
You must configure Keychain authentication on both BGP peers. Note that encryption
algorithms and passwords configured for the Keychain authentication on both peers must be the
same; otherwise, the TCP connection cannot be set up between BGP peers and BGP messages
cannot be transmitted.
Before configuring the BGP Keychain authentication, configure a Keychain in accordance with
the configured keychain-name. Otherwise, the TCP connection cannot be set up.
NOTE
l When this command is used in the BGP view, the extensions on VPNv6 of MP-BGP are also valid
because they use the same TCP connection.
l The BGP MD5 authentication and BGP Keychain authentication are mutually exclusive.
----End

9.16.4 Configuring Basic BGP4+ GTSM Functions

The GTSM mechanism protects a router by checking whether the TTL value in the IP header is
in a pre-defined range.
Procedure
l Configuring Basic BGP4+ GTSM Functions
Perform the following steps on the two peers:
1. Run:
system-view

2. Run:

3. Run
peer { group-name | ipv6-address } valid-ttl-hops [ hops ]
Basic BGP4+ GTSM functions are configured.

The range of TTL values of packets is [ 255-hops+1, 255 ]. By default, the value of
hops is 255. That is, the valid TTL range is [ 1, 255 ]. For example, for the direct
EBGP route, the value of hops is 1. That is, the valid TTL value is 255.
NOTE
l The configuration in the BGP view is also valid for the VPNv6 extension of MP-BGP. This
is because they use the same TCP connection.
l GSTM is exclusive with EBGP-MAX-HOP; therefore, you can enable only one of them
on the same peer or the peer group.
After the BGP4+ GTSM policy is configured, an interface board checks the TTL
values of all BGP4+ packets. According to the actual networking requirements, you
can configure GTSM to discard or process the packets that do not match the GTSM
policy. If you configure GTSM to discard the packets that do not match the GTSM
policy by default, you can configure the range of finite TTL values according to the
network topology; therefore, the interface board directly discards the packets with the
TTL value not in the configured range. Therefore, the attackers cannot simulate valid
BGP4+ packets to occupy CPU resources.
l Performing the Default GTSM Action
Perform the following steps on the router configured with GTSM:
1. Run:
system-view

2. Run:
The default action is configured for the packets that do not match the GTSM policy.
By default, the packets that do not match the GTSM policy can pass the filtering.

NOTE
If only the default action is configured and the GTSM policy is not configured, GTSM does
not take effect.
----End

After BGP4+ network security is configured, you can check authentication information of BGP4
+ peers.
Prerequisites
BGP4+ security has been configured.
Procedure
l Run the display gtsm statistics { slot-id | all } command to check the statistics of GTSM.
Run the display gtsm statistics command. You can view GTSM statistics on each board,
including the total number of BGP4+ packets, the total number of OSPF packets, the
number of packets that match the GTSM policy, and the number of discarded packets.
BGP4+ GTSM.
l Run the display bgp group [ group-name ] command to check GTSM of a BGP4+ peer
group.
----End
9.17 Maintaining BGP4+

Maintaining BGP4+ involves resetting a BGP4+ connection and clearing BGP4+ statistics.
9.17.1 Resetting BGP4+ Connections

Resetting a BGP4+ connection will interrupt the peer relationship. You can also reset BGP in
GR mode.

Context
NOTICE
The peer relationship is broken after you reset the BGP4+ connections with the reset bgp
ipv6 command. Exercise caution when running this command.
To reset a BGP4+ session in GR mode, run the reset bgp command with the graceful parameter
specified and run the graceful-restart peer-reset command. If the graceful parameter is not
specified in the reset bgp command or if the graceful-restart peer-reset command is not run,
the GR reset mode does not take effect, so that routing entries will be deleted for existing sessions,
interrupting services. The services will be restored after the BGP4+ peer relationship is
reestablished.
After the BGP4+ configuration changes, reset the BGP4+ connections to validate the
modification.
To reset the BGP4+ connections, run the following reset command in the user view.
Procedure
l To validate the new configuration, run the reset bgp ipv6 all [ graceful ] command in the
user view to reset all the BGP4+ connections.
l To validate the new configuration, run the reset bgp ipv6 { as-number-plain | as-number-
dot } [ graceful ] command in the user view to reset the BGP+4 connections between the
peers in a specified AS.
l To validate the new configuration, run the reset bgp ipv6 { ipv4-address | ipv6-address |
group group-name } [ graceful ] command in the user view to reset the BGP+4 connections
with the specified peer (or peer group).
l To validate the new configuration, run the reset bgp ipv6 external [ graceful ] command
in the user view to reset the external BGP4+ connections.
l To validate the new configuration, run the reset bgp ipv6 internal [ graceful ] command
in the user view to reset the internal BGP4+ connections.
----End
9.17.2 Clearing BGP4+ Statistics

This section describes how to clear the statistics of flapped routes, and suppressed routes.
Context
NOTICE
The BGP4+ statistics cannot be restored after being cleared. Exercise caution when running this
command.

Procedure
l Run the reset bgp ipv6 dampening [ ipv6-address prefix-length ] command in the user
view to clear information about route dampening and release the suppressed routes.
l Run the reset bgp ipv6 flap-info [ ipv6-address prefix-length | regexp as-path-regexp |
as-path-filter { as-path-filter-number | as-path-filter-name } ] command in the user view
to clear the statistics of route flapping.
----End

BGP4+ configuration examples explain networking requirements, networking diagram,
NOTE
9.18.1 Example for Configuring Basic BGP4+ Functions

Networking Requirement
As shown in Figure 9-1, there are two ASs: 65008 and 65009. Router A belongs to AS 65008;
Router B, Router C, and Router D belong to AS65009. BGP4+ is required to exchange the routing
information between the two ASs.
Figure 9-1 Networking diagram of configuring basic BGP4+ functions
RouterC AS 65009
POS3/0/0 POS2/0/0
2001:db8:3::2/64 2001:db8:2::1/64
20
01
:d PO
b8 S
AS 65008
POS3/0/0 :2 2/0
GE1/0/0 ::2 /0
2001:db8:3::1/64 POS1/0/0 /6
2001:db8:8::1/64 4
2001:db8:1::1/64
POS2/0/0 RouterB POS1/0/0
RouterA 2001:db8:10::2/64 POS2/0/0 2001:db8:1::2/64 RouterD
2001:db8:10::1/64

1. Configure the IBGP connections among Router B, Router C, and Router D.

2. Configure the EBGP connection between Router A and Router B.
Data Preparation
l The router ID of Router A is 1.1.1.1. Its AS number is 65008.

l The router IDs of Router B, Router C, and Router D are 2.2.2.2, 3.3.3.3, and 4.4.4.4
respectively. Their AS number is 65009.
Procedure
Step 2 Configure the IBGP.
[RouterB] ipv6
[RouterB] bgp 65009
[RouterB-bgp] peer 2001:db8:1::2 as-number 65009
[RouterB-bgp-af-ipv6] peer 2001:db8:1::2 enable
[RouterB-bgp-af-ipv6] network 2001:db8:1:: 64
[RouterB-bgp] quit
[RouterC] ipv6
[RouterC] bgp 65009
[RouterC-bgp-af-ipv6] network 2001:db8:3:: 64
[RouterC-bgp] quit
[RouterD] ipv6
[RouterD] bgp 65009
[RouterD-bgp-af-ipv6] network 2001:db8:2:: 64

[RouterD-bgp] quit
Step 3 Configure the EBGP.

[RouterA] ipv6
[RouterA] bgp 65008
[RouterA-bgp] peer 2001:db8:10::1 as-number 65009
[RouterA-bgp-af-ipv6] peer 2001:db8:10::1 enable
[RouterA-bgp-af-ipv6] network 2001:db8:10:: 64
[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp] quit
# Check the connection status of BGP4+ peers.

[RouterB] display bgp ipv6 peer
2001:db8:1::2 4 65009 8 9 0 00:05:37 Established 2
2001:db8:3::2 4 65009 2 2 0 00:00:09 Established 2
2001:db8:10::2 4 65008 9 7 0 00:05:38 Established 2
The routing table shows that Router B has set up BGP4+ connections with other routers.
[RouterA]display bgp ipv6 routing-table
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
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


MED : 0 PrefVal : 0
Label :
Path/Ogn : i
*
MED : 0 PrefVal : 0
Label :
Path/Ogn : 65009 i
The routing table shows that Router A has learned the route from AS 65009. AS 65008 and AS
65009 can exchange their routing information.
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:8:: 64
network 2001:db8:10:: 64
#
return

#
sysname RouterB
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
#
interface Pos3/0/0
link-protocol ppp
ipv6 enable


#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:1:: 64
network 2001:db8:3:: 64
network 2001:db8:10:: 64
#
return

#
sysname RouterC
#
ipv6
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
#
interface Pos3/0/0
link-protocol ppp
ipv6 enable
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:2:: 64
network 2001:db8:3:: 64
#
return

#
sysname RouterD
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable


#
bgp 65009
router-id 4.4.4.4
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:1:: 64
network 2001:db8:2:: 64
#
return
9.18.2 Example for Configuring a BGP4+ Route Reflection

A BGP4+ route reflector avoids fully meshed connections between IBGP peers and therefore
simplifies the network.
As shown in Figure 9-2, Router B receives an update packet from the EBGP peer and forwards
it to Router C. Router C is configured as a route reflector with two clients, Router B and Router
D.
Router B and Router D need not set up an IBGP connection. When Router C receives the route
update packet from Router B, it reflects the information to Router D. Similarly, when Router C
receives the route update packet from Router D, it reflects the information to Router B.
Figure 9-2 Networking diagram of configuring BGP4+ route reflection
RouterC
AS200
GE2/0/0 GE1/0/0
AS100 2001:db8:101::1/96 2001:db8:102::1/96
GE2/0/0 GE1/0/0 GE1/0/0
2001:db8:100::1/96 2001:db8:101::2/96 2001:db8:102::2/96
GE1/0/0
2001:db8:1::1/64 RouterB
RouterA
GE2/0/0 RouterD
2001:db8:100::2/96
1. Establish an IBGP connection between the client and the route reflector.

2. Configure Router C as the route reflector and check the routing information.
Preparation Data
l The AS numbers are AS 100 and AS 200.
l The router IDs of Router A, Router B, Router C, and Router D are 1.1.1.1, 2.2.2.2, 3.3.3.3,
and 4.4.4.4 respectively.
Procedure
Step 2 Configure basic BGP4+ functions.
[RouterA] ipv6
[RouterA] bgp 100
[RouterA-bgp] quit
[RouterB] ipv6
[RouterB] bgp 200
[RouterB-bgp] quit
[RouterC] ipv6
[RouterC] bgp 200
[RouterD] ipv6
[RouterD] bgp 200


[RouterD-bgp] quit
Step 3 Configure the route reflector.

# Configure Router C as a route reflector, and Router B and Router D serve as its clients.
[RouterC-bgp-af-ipv6] peer 2001:db8:101::2 reflect-client
[RouterC-bgp-af-ipv6] peer 2001:db8:102::2 reflect-client
# Check the routing table of Router B.

[RouterB]display bgp ipv6 routing-table


MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
*
MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
# Check the routing table of Router D.

[RouterD]display bgp ipv6 routing-table




MED : 0 PrefVal : 0
Label :
Path/Ogn : 100 i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
i
MED : 0 PrefVal : 0
Label :
Path/Ogn : i
The routing table shows that Router D and Router B learn the routing information advertised by
Router A from Router C.
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
#
ipv6 enable
ipv6 address 2001:db8:100::1/96
#
bgp 100
router-id 1.1.1.1
#
ipv6-family unicast
network 2001:db8:1:: 64
network 2001:db8:100:: 96
#
return

#
sysname RouterB
#
ipv6
#
ipv6 enable

ipv6 address 2001:db8:101::2/96

#
ipv6 enable
ipv6 address 2001:db8:100::2/96
#
bgp 200
router-id 2.2.2.2
#
ipv6-family unicast
network 2001:db8:100:: 96
network 2001:db8:101:: 96
#
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
ipv6 address 2001:db8:102::1/96
#
ipv6 enable
ipv6 address 2001:db8:101::1/96
#
bgp 200
router-id 3.3.3.3
#
ipv6-family unicast
network 2001:db8:101:: 96
network 2001:db8:102:: 96
peer 2001:db8:101::2 reflect-client
peer 2001:db8:102::2 reflect-client
#
return

#
sysname RouterD
#
ipv6
#
ipv6 enable
ipv6 address 2001:db8:102::2/96
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
#

ipv6-family unicast
network 2001:db8:102:: 96
#
Return
9.18.3 Example for Configuring BFD for BGP4+

After BFD for BGP4+ is configured, BFD can fast detect the fault on the link between BGP4+
peers and notify it to BGP4+ so that service traffic can be transmitted through the backup link.
l As shown in Figure 9-3, Router A belongs to AS 100, Router B to AS 200, and Router C
to AS 200. Establish an EBGP connection between Router A and Router B and that between
Router A and Router C.
C → Router B acts as the standby link.
l Use BFD to detect the BGP session between Router A and Router B. When the link between
Router A and Router B fails, BFD can rapidly detect the failure and notify BGP of the
failure. Traffic is transmitted on the standby link.
Figure 9-3 Networking diagram of configuring BFD for BGP4+
GE3/0/0
2001:db8:7::1/64
GE2/0/0
2001:db8:8::2/64
GE1/0/0 EBGP GE1/0/0

AS 100 RouterB
2001:db8:8::1/64 2001:db8:9::1:1/64
RouterA IBGP
AS 200
GE2/0/0
2001:db8:10::1/64 EBGP GE1/0/0
2001:db8:9::1:2/64
GE2/0/0
2001:db8:10::2/64 RouterC
1. Configure the basic BGP4+ functions on each router.

2. Configure MED attributes to control the routing selection of the routers.
3. Enable the BFD on Router A and Router B.

Data Preparation
l Router IDs and AS numbers of Router A, Router B and Router C

l Peer IPv6 address detected by BFD
l Minimum interval for sending the packets, minimum interval for receiving the packets, and
local detection time multiplier controlled by BFD
Procedure
Step 1 Assign an IPv6 address to each interface.
Step 2 Configure the basic BGP4+ functions. Establish an EBGP connection between Router A and
Router B, that between Router A and Router C. Establish an IBGP connection between Router
B and Router C.
[RouterA] bgp 100
[RouterA-bgp] quit
[RouterB] bgp 200
[RouterB-bgp] peer 2001:db8:9::1:2 as-number 200
[RouterB-bgp-af-ipv6] peer 2001:db8:9::1:2 enable
[RouterB-bgp-af-ipv6] network 2001:db8:7::1 64
[RouterB-bgp] quit
[Routerc] bgp 200
[Routerc-bgp] router-id 3.3.3.3
[Routerc-bgp] peer 2001:db8:10::1 as-number 100
[Routerc-bgp] peer 2001:db8:9::1:1 as-number 200
[RouterC-bgp-af-ipv6] peer 2001:db8:9::1:1 enable
[RouterC-bgp] quit
# Display the established BGP neighbors on Router A.

[RouterA] display bgp ipv6 peer



PrefRcv
2001:db8:8::2 4 200 12 11 0 00:07:26 Established 0

2001:db8:10::2 4 200 12 12 0 00:07:21 Established 0
Step 3 Configure MED attributes.
Set the value of MED sent by Router B and Router C to Router A by using the policy.
[RouterB] route-policy 10 permit node 10
[RouterB] bgp 200
[RouterB-bgp-af-ipv6] peer 2001:db8:8::1 route-policy 10 export
[RouterB-bgp] quit
[RouterC] route-policy 10 permit node 10
[RouterC] bgp 200
[RouterC-bgp-af-ipv6] peer 2001:db8:10::1 route-policy 10 export
[RouterC-bgp] quit
# Display all BGP routing information on Router A.

[RouterA] display bgp ipv6 routing-table


MED : 100 PrefVal : 0
Label :
Path/Ogn : 200 i
*
Label :
Path/Ogn : 200 i
As shown in the BGP routing table, the next hop address of the route to 2001:db8:7::1/64 is
2001:db8:8::2 and traffic is transmitted on the active link Router A → Router B.
Step 4 Configure the BFD detection function, the interval for sending the packets, the interval for
receiving the packets, and the local detection time multiple.
# Enable BFD on Router A, set the minimum interval for sending the packets and the minimum
interval for receiving the packets to 100 ms, and set the local detection time multiple to 4.
[RouterA] bfd
[RouterA-bfd] quit

[RouterA] bgp 100

[RouterA-bgp] peer 2001:db8:8::2 bfd enable
[RouterA-bgp] peer 2001:db8:8::2 bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
[RouterA-bgp] quit
# Enable BFD on Router B, set the minimum interval for sending the packets and the minimum
interval for receiving the packets to 100 ms, and set the local detection time multiple to 4.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bgp 200
[RouterB-bgp] peer 2001:db8:8::1 bfd enable
[RouterB-bgp] peer 2001:db8:8::1 bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
[RouterB-bgp] quit
# Display all BFD sessions set up by BGP on Router A.

[RouterA] display bgp ipv6 bfd session all
Local_Address : 2001:db8:8::1
Peer_Address : 2001:db8:8::2
Tx-interval(ms): 100 Rx-interval(ms): 100
Multiplier : 4 Interface : GigabitEthernet1/0/0
LD/RD : 8192/8192 Session-State : Up
Wtr-interval(m):0
Step 5 Verify the Configuration.

[RouterB-Gigabitethernet2/0/0] shutdown
Step 6 # Display the routing table on Router A.

[RouterA] display bgp ipv6 routing-table


Label :
Path/Ogn : 200 i
As shown in the BGP routing table, the standby link Router A → Router C → Router B takes
effect after the active link fails. The next hop address of the route to 2001:db8:7::1/64 becomes
2001:db8:10::2.
----End
Configuration Files
#
sysname RouterA
#
ipv6
#
bfd

#
undo shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
#
interface NULL0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
router-id 1.1.1.1
peer 2001:db8:8::2 bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
peer 2001:db8:8::2 bfd enable
#
ipv4-family unicast
#
ipv6-family unicast
#
return

#
sysname RouterB
#
sysname RouterB
#
ipv6
#
bfd
#
interface interface GigabitEthernet2/0/0
shutdown
ipv6 enable
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:9::1:1/64
#
undo shutdown
ipv6 enable
#
interface NULL0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 200
router-id 2.2.2.2

peer 2001:db8:8::1 bfd min-tx-interval 100 min-rx-interval 100 detect-

multiplier 4
peer 2001:db8:8::1 bfd enable
peer 2001:db8:9::1:2 as-number 200
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:7:: 64
peer 2001:db8:8::1 route-policy 10 export
peer 2001:db8:9::1:2 enable
#
apply cost 100
#
return

#
sysname RouterC
#
ipv6
#
undo shutdown
ipv6 enable
ipv6 address 2001:db8:9::1:2/64
#
undo shutdown
ipv6 enable
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 200
router-id 3.3.3.3
peer 2001:db8:9::1:1 as-number 200
#
ipv4-family unicast
#
ipv6-family unicast
peer 2001:db8:9::1:1 enable
peer 2001:db8:10::1 route-policy 10 export
#
apply cost 150
#
return
9.18.4 Example for Configuring BGP4+ 6PE

By configuring BGP4+ IPv6 Provider Edge (6PE), you can connect separated IPv6 networks
through the MPLS tunneling technology.

As shown in Figure 9-4, the link between CE1 and PE1 is an IPv6 link; the link between PE1
and PE2 is an IPv4 link; the link between PE2 and CE2 is an IPv6 link. BGP4+ runs between
CE1 and PE1 and between PE2 and CE2. MPLS runs between PE1 and PE2. 6PE is configured
to implement interworking between IPv6 networks.
Figure 9-4 Networking diagram of configuring BGP4+ 6PE
Loopback0 AS200 Loopback0

2.2.2.2 3.3.3.3
POS2/0/0
20.0.0.1/30
PE1 MPLS Tunnel PE2
POS1/0/0 POS2/0/0 POS1/0/0
2001:db8:1::2/64 20.0.0.2/30 2001:db8:2::2/64
POS1/0/0 POS1/0/0
2001:db8:1::1/64 2001:db8:2::1/64
Loopback1 CE1 CE2 Loopback1
2001:db8:5::5/64 2001:db8:6::6/64
Loopback0 Loopback0
AS100 1.1.1.1 4.4.4.4 AS300
1. Configure OSPF on PE1 and PE2 to make them learn loopback interface addresses from
each other.
2. Configure BGP4+ between CE1 and PE1 and between PE2 and CE2.
3. Configure MPLS on PE1 and PE2 and set up the LSP.
4. Configure 6PE on PE1 and PE2.
Data Preparation
l Router IDs of CE1, PE1, PE2, and CE2 as 1.1.1.1, 2.2.2.2, 3.3.3.3, and 4.4.4.4 respectively
l Number of the AS where each router resides
Procedure
Step 1 Configure the IPv4 and IPv6 addresses for each interface.

Step 2 Configure OSPF on PE1 and PE2 to make them learn routes from each other.
Step 3 Configure BGP4+.
# Configure CE1.
[CE1] bgp 100
[CE1-bgp] peer 2001:db8:1::2 as-number 200
[CE1-bgp] ipv6-family unicast
[CE1-bgp-af-ipv6] peer 2001:db8:1::2 enable
[CE1-bgp-af-ipv6] network 2001:db8:5::5 64
[CE1-bgp-af-ipv6] quit
[CE1-bgp] quit
# Configure PE1.
[PE1] bgp 200
[PE1-bgp] peer 2001:db8:1::1 as-number 100
[PE1-bgp-af-ipv6] peer 2001:db8:1::1 enable
[PE1-bgp-af-ipv6] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp] quit
# Configure CE2.
[CE2] bgp 300
[CE2-bgp] quit
# Check whether the neighbor relationship is set up on PE1 and PE2.

[PE1] display bgp ipv6 peer
2001:db8:1::1 4 100 32 35 0 00:27:20 Established
1
2001:db8:2::1 4 300 31 37 0 00:28:08 Established
1
Step 4 Configure MPLS on PE1 and PE2 and set up the LSP.
# Configure PE1.
[PE1] mpls

[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] interface pos2/0/0
[PE1-Pos2/0/0] mpls
[PE1-Pos2/0/0] mpls ldp
[PE1-Pos2/0/0] quit
# Configure PE 2.
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2-Pos2/0/0] mpls
[PE2-Pos2/0/0] quit
# Check whether the LSP is set up, taking PE1 as an example.

[PE1] display mpls lsp
-------------------------------------------------------------------------------
LSP Information: LDP LSP
-------------------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
3.3.3.3/32 NULL/3 -/Pos2/0/0
3.3.3.3/32 1027/3 -/Pos2/0/0
-------------------------------------------------------------------------------
LSP Information: BGP IPV6 LSP
-------------------------------------------------------------------------------
FEC : 2001:db8:1::/64
In Label : 105472 Out Label : -----
In Interface : ----- OutInterface : -----
Vrf Name :
FEC : 2001:db8:5::/64
In Label : 105475 Out Label : -----
In Interface : ----- OutInterface : -----
Vrf Name :
Step 5 Configure 6PE.

# Configure PE1.
[PE1] bgp 200
[PE1-bgp-af-ipv6] peer 3.3.3.3 enable
[PE1-bgp-af-ipv6] peer 3.3.3.3 label-route-capability
[PE1-bgp-af-ipv6] import-route direct
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp-af-ipv6] import-route direct
[PE2-bgp] quit
# Check the connection status of 6PE peers.


3.3.3.3 4 200 1248 1342 0 18:06:28 Established
1
2001:db8:1::1 4 100 32 35 0 00:27:20 Established
1
From the preceding display, you can view that the BGP 6PE connection between PE1 and PE2
is set up.
Take CE1 as an example.
CE1 can learn the address of Loopback 1 from CE2 and ping through CE2.
[CE1] display ipv6 routing-table










Ping the address of Loopback1 of CE2 on CE1.

[CE1] ping ipv6 -c 5 2001:db8:6::6
0.00% packet loss
From the preceding display, you can view that 6PE connects the separated IPv6 networks and
realizes interworking.
----End
Configuration Files
l Configuration file of CE1
#
sysname CE1
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
interface LoopBack1
ipv6 enable
#
bgp 100
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:5:: 64
#
return

#
sysname PE1
#

ipv6
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
interface Pos2/0/0
link-protocol ppp
ip address 20.0.0.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv6-family unicast
import-route direct
peer 3.3.3.3 enable
peer 3.3.3.3 label-route-capability
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 20.0.0.0 0.0.0.3
#
return

#
sysname PE2
#
ipv6
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 20.0.0.2 255.255.255.252
mpls
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
interface LoopBack0

ip address 3.3.3.3 255.255.255.255

#
bgp 200
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv6-family unicast
import-route direct
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 20.0.0.0 0.0.0.3
#
return

#
sysname CE2
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
interface LoopBack1
ipv6 enable
#
bgp 300
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:6:: 64
#
return
9.18.5 Example for Configuring Inter-AS 6PE OptionB (with ASBRs

as PEs)
This section provides an example of how to configure inter-AS IPv6 Provider Edge (6PE)
OptionB (with ASBRs as PEs) for separate IPv6 networks that connect to different ASs to
communicate over MPLS tunnels on the IPv4 public network.

If separate IPv6 networks connect to different ASs, deploy 6PE for the IPv6 networks to
communicate.
In practical application, different inter-AS 6PE solutions are provided for separate IPv6 networks
that connect to multiple ASs, depending on the types of links between the PEs of the ASs. If
EBGP peer relationships and public network tunnels are established between PEs, use the inter-
AS 6PE OptionB (with ASBRs as PEs) solution.
As shown in Figure 9-5, ASBRs also function as PEs. An IPv6 link is established between CE1
and ASBR1 and between ASBR2 and CE2. An IPv4 link is established between ASBR1 and
ASBR2. BGP4+ runs between CE1 and ASBR1 and between ASBR2 and CE2. EBGP runs
between ASBR1 and ASBR2 and an MPLS tunnel is established between ASBR1 and ASBR2.
Figure 9-5 Networking diagram for inter-AS 6PE OptionB (with ASBRs as PEs)
AS 100 GE1/0/1 GE1/0/2 AS 200

20.1.1.1/24 20.1.1.2/24
ASBR1 ASBR2
GE1/0/0 GE1/0/0
2001:db8:1::2/64 2001:db8:2::2/64
GE1/0/0 GE1/0/0
AS 300 AS 400
2001:db8:1::1/64 2001:db8:2::1/64
CE1 CE2
Loopback1 Loopback1
2001:db8:5::5/64 2001:db8:6::6/64
1. Enable MPLS globally and on the interfaces between ASBR1 and ASBR2 to ensure that
ASBRs can use MPLS to assign labels to BGP4+ routes.
2. Configure a 6PE peer relationship between ASBR1 and ASBR2 and enable the function to
exchange labeled IPv6 routes on ASBR1 and ASBR2, so that IPv6 routes can transmit
across multiple ASs.
3. Configure BGP4+ for CE1 and ASBR1 to communicate and for ASBR2 and CE2 to
communicate, separately.
Data Preparation
l AS numbers of ASBR1, ASBR2, CE1, and CE2: 100, 200, 300, 400, respectively

l Router IDs of CE1 and CE2: 3.3.3.3, 4.4.4.4, respectively
Procedure
Step 1 Configure device names and interface IP addresses.
Configure the name of each device and assign an IP address to each interface, as shown in Figure
9-5. For more information about the configuration, see the following configuration files.
Step 2 Configuring MPLS.
# Configure ASBR1.
[ASBR1] mpls lsr-id 1.1.1.1
[ASBR1] mpls
[ASBR1-mpls] quit
[ASBR1] interface gigabitethernet 1/0/1
[ASBR1-GigabitEthernet1/0/1] mpls
[ASBR1-GigabitEthernet1/0/1] quit
# Configure ASBR2.
[ASBR2] mpls
[ASBR2-mpls] quit
Step 3 Configure a 6PE peer relationship.
# Configure ASBR1.
[ASBR1] bgp 100
[ASBR1-bgp] peer 20.1.1.2 as-number 200
[ASBR1-bgp] ipv6-family unicast
[ASBR1-bgp-af-ipv6] peer 20.1.1.2 enable
[ASBR1-bgp-af-ipv6] peer 20.1.1.2 label-route-capability
[ASBR1-bgp-af-ipv6] quit
[ASBR1-bgp] quit
# Configure ASBR2.
[ASBR2] bgp 200
[ASBR2-bgp] quit
Step 4 Configure ASBR1 to communicate with CE1 and ASBR2 to communicate with CE2.
l Configure ASBR1 to communicate with CE1.
# Configure ASBR1.
[ASBR1] ipv6
[ASBR1] bgp 100
[ASBR1-bgp] peer 2001:db8:1::1 as-number 300
[ASBR1-bgp-af-ipv6] peer 2001:db8:1::1 enable
[ASBR1-bgp] quit
# Configure CE1.
[CE1] ipv6

[CE1] bgp 300

[CE1-bgp] router-id 3.3.3.3
[CE1-bgp-af-ipv6] network 2001:db8:5:: 64
[CE1-bgp] quit
l Configure ASBR2 to communicate with CE2.

# Configure ASBR2.
[ASBR2] ipv6
[ASBR2] bgp 200
[ASBR2-bgp] peer 2001:db8:2::1 as-number 400
[ASBR2-bgp-af-ipv6] peer 2001:db8:2::1 enable
[ASBR2-bgp] quit
# Configure CE2.
[CE2] ipv6
[CE2] bgp 400
[CE2-bgp] quit
# Run the display bgp ipv6 peer command on ASBR1 and ASBR2. The command output shows
that the BGP4+ peer relationships have been established.
[ASBR1] display bgp ipv6 peer


PrefRcv
20.1.1.2 4 200 8 8 0 00:05:01 Established

1
2001:db8:1::1 4 300 818 821 0 13:35:29 Established
1
[ASBR2] display bgp ipv6 peer


PrefRcv
20.1.1.1 4 100 8 10 0 00:05:34 Established

1
2001:db8:2::1 4 400 821 828 0 13:38:45 Established
1
Step 5 Check the configurations.
# Run the display ipv6 routing-table command on each CE. The command output shows that
the two CEs have learned the routes to each other's Loopback1 interface. The following example
uses the display on CE1.









# Ping the Loopback1 interface of CE2 from CE1. The command output shows that the
Loopback1 interface of CE2 can be pinged.
[CE1] ping ipv6 -a 2001:db8:5::5 2001:db8:6::6


0.00% packet loss

----End
Configuration Files
l CE1 configuration file
#
sysname CE1
#
ipv6
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 300
router-id 3.3.3.3
#
ipv6-family unicast
network 2001:db8:5:: 64
#
return
l ASBR1 configuration file

#
sysname ASBR1
#
ipv6
#
mpls lsr-id 1.1.1.1
mpls
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
#
ipv6-family unicast


#
return

#
sysname ASBR2
#
ipv6
#
mpls lsr-id 2.2.2.2
mpls
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 200
#
ipv4-family unicast
#
ipv6-family unicast
#
return

#
sysname CE2
#
ipv6
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 400
router-id 4.4.4.4
#
ipv6-family unicast
network 2001:db8:6:: 64

#
return
9.18.6 Example for Configuring Inter-AS 6PE OptionB

OptionB for separate IPv6 networks that connect to different ASs to communicate over an inter-
AS VPN OptionB network.
communicate.
inter-AS OptionB public network tunnels are established between PEs, use the inter-AS 6PE
OptionB solution.
As shown in Figure 9-6, an IPv6 link is established between CE1 and PE1 and between CE2
and PE2. An IPv4 link is established between PE1 and ASBR1, between PE2 and ASBR2, and
between ASBR1 and ASBR2. BGP4+ runs between CE1 and PE1 and between PE2 and CE2.
IBGP runs between PE1 and ASBR1 and between PE2 and ASBR2. EBGP runs between ASBR1
and ASBR2. An MPLS tunnel has been established between PE1 and PE2.
Figure 9-6 Networking diagram for inter-AS 6PE OptionB
AS 100 AS 200
Loopback1 Loopback1
3.3.3.3/32 4.4.4.4/32
GE1/0/1 GE1/0/0 GE1/0/0 GE1/0/1
20.1.1.2/24 192.1.1.1/24 192.1.1.2/24 20.1.2.1/24
Loopback1 Loopback1
2.2.2.2/32 ASBR1 ASBR2
5.5.5.5/32
GE1/0/1 GE1/0/1
PE1 20.1.1.1/24 PE2
20.1.2.2/24
GE1/0/0 GE1/0/0
2001:db8:1::2/64 2001:db8:2::2/64
GE1/0/0 GE1/0/0
2001:db8:1::1/64 2001:db8:2::1/64
CE2
CE1
AS 400
AS 300
Loopback1 Loopback1
2001:db8:5::5/64 2001:db8:6::6/64

1. Configure a dynamic routing protocol so that PE1 and ASBR1 can learn the loopback
interface addresses of each other and PE2 and ASBR2 can learn the loopback interface
addresses of each other.
2. Enable MPLS and MPLS LDP in each AS to ensure that MPLS LDP LSPs can be
established in each AS.
3. Establish a 6PE peer relationship between PE1 and ASBR1, between PE2 and ASBR2, and
between ASBR1 and ASBR2. Enable the function to exchange labeled IPv6 routes on these
routers to allow IPv6 routes to be transmitted across multiple ASs.
4. Configure BGP4+ for CE1 and PE1 to communicate and for CE2 and PE2 to communicate.
Data Preparation
l AS numbers of PE1 and ASBR1 are both 100. AS numbers of PE2 and ASBR2 are both
200. AS numbers of CE1, CE2: 300, 400, respectively
l Open Shortest Path First (OSPF) process IDs 1 and area IDs 0 of PE1, PE2, ASBR1, and
ASBR2
l MPLS LSR IDs of PE1, PE2, ASBR1, and ASBR2: 2.2.2.2, 3.3.3.3, 4.4.4.4, 5.5.5.5,
respectively
Procedure
Step 2 Configure an IGP on the MPLS backbone networks of AS 100 and AS 200, so that the PEs and
ASBRs on each MPLS backbone network can communicate with each other.
This section uses OSPF as an example. For more information about the configuration, see the
following configuration files.
NOTE
Configure OSPF to advertise the 32-bit loopback interface addresses to be used as LSR IDs.
After the configurations in this step are complete, OSPF neighbor relationships are established
between the PEs and ASBRs in the same AS. Run the display ospf peer command. The
command output shows that the OSPF neighbor relationship status is Full. The following
example uses the display on PE1.
[PE1] display ospf peer

Neighbors

DR: 20.1.1.2 BDR: 20.1.1.1 MTU: 0

The PEs and ASBRs in the same AS can learn the loopback interface addresses of each other
and ping each other.
Step 3 Configure basic MPLS functions and MPLS LDP on the MPLS backbone networks of AS 100
and AS 200 to establish MPLS LDP LSPs.
# Configure basic MPLS functions on PE1 and enable LDP on the interface connected to ASBR1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure basic MPLS functions on ASBR1 and enable LDP on the interface connected to
PE1.
[ASBR1] mpls
[ASBR1-mpls] quit
[ASBR1] mpls ldp
[ASBR1-mpls-ldp] quit
[ASBR1-GigabitEthernet1/0/1] mpls ldp
PE2.
[ASBR2] mpls
[ASBR2-mpls] quit
[ASBR2] mpls ldp
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configurations in this step are complete, an LSP is established between PE1 and ASBR1
and between PE2 and ASBR2. Run the display mpls ldp lsp command. The command output
shows whether LDP LSPs have been established. The following example uses the display on
PE1.
[PE1] display mpls ldp lsp
LDP LSP Information

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


-------------------------------------------------------------------------------
2.2.2.2/32 3/NULL 3.3.3.3 127.0.0.1 InLoop0
*2.2.2.2/32 Liberal/1024 DS/3.3.3.3
3.3.3.3/32 NULL/3 - 20.1.1.2 GE1/0/1
3.3.3.3/32 1024/3 3.3.3.3 20.1.1.2 GE1/0/1
-------------------------------------------------------------------------------
A '*' before a UpstreamPeer means the session is stale
A '*' before a DS means the session is stale
Step 4 Configure a 6PE peer relationship.

NOTE
Before configuring a 6PE peer relationship, ensure that the function to exchange labeled routes has been
enabled.
1. # Configure PE1 and ASBR1.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.3 connect-interface LoopBack 1
[PE1-bgp] quit
# Configure ASBR1.
[ASBR1] bgp 100
[ASBR1-bgp] peer 2.2.2.2 connect-interface LoopBack 1
[ASBR1-bgp] quit
2. # Configure PE2 and ASBR2.

# Configure PE2.
[PE2] bgp 200
[PE2-bgp] quit
# Configure ASBR2.
[ASBR2] bgp 200
[ASBR2-bgp] peer 5.5.5.5 connect-interface LoopBack 1

[ASBR2-bgp] quit
3. # Configure ASBR1 and ASBR2.
# Configure ASBR1.
[ASBR1] bgp 100
[ASBR1-bgp] quit
# Configure ASBR2.
[ASBR2] bgp 200
[ASBR2-bgp] quit
Step 5 Configure CE1 to communicate with PE1 and CE2 to communicate with PE2.
# Configure CE1.
[CE1] ipv6
[CE1] bgp 300
[CE1-bgp] quit
# Configure PE1.
[PE1] ipv6
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] ipv6
[PE2] bgp 200
[PE2-bgp] quit
# Configure CE2.
[CE2] ipv6
[CE2] bgp 400


[CE2-bgp] quit
# Run the display bgp ipv6 peer command on PE1 and PE2. The command output shows that
the BGP4+ peer relationship has been established.


PrefRcv
3.3.3.3 4 100 74 69 0 01:03:32 Established

1
2001:db8:1::1 4 300 1224 1244 0 20:21:40 Established
1


PrefRcv
4.4.4.4 4 200 77 72 0 01:06:11 Established

1
2001:db8:2::1 4 400 1227 1243 0 20:24:20 Established
1









[CE1] ping ipv6 -a 2001:db8:5::5 2001:db8:6::6

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ipv6
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 300
router-id 1.1.1.1


#
ipv6-family unicast
network 2001:db8:5:: 64
#
return
l PE1 configuration file

#
sysname PE1
#
ipv6
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv6-family unicast
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return

#
sysname ASBR1
#
ipv6
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#

undo shutdown
ip address 192.1.1.1 255.255.255.0
mpls
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv6-family unicast
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return

#
sysname ASBR2
#
ipv6
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
undo shutdown
ip address 192.1.1.2 255.255.255.0
mpls
#
undo shutdown
ip address 20.1.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200

#
ipv4-family unicast
peer 5.5.5.5 enable
#
ipv6-family unicast
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 20.1.2.0 0.0.0.255
#
return

#
sysname PE2
#
ipv6
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 4.4.4.4 enable
#
ipv6-family unicast
peer 4.4.4.4 enable
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 20.1.2.0 0.0.0.255
#
return


#
sysname CE2
#
ipv6
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 400
router-id 6.6.6.6
#
ipv6-family unicast
network 2001:db8:6:: 64
#
return
9.18.7 Example for Configuring Inter-AS 6PE OptionC (Solution 1)

OptionC solution 1 to enable separate IPv6 networks that connect to different ASs to
communicate over an inter-AS OptionC network.
communicate.
inter-AS OptionC tunnels are established between PEs, use the inter-AS 6PE OptionC solution.
As shown in Figure 9-7, an IPv6 link is established between CE1 and PE1 and between CE2
and PE2. An IPv4 link is established between PE1 and ASBR1, between PE2 and ASBR2, and
between ASBR1 and ASBR2. BGP4+ runs between CE1 and PE1 and between PE2 and CE2.
MP-EBGP runs between PE1 and PE2 and an end-to-end MPLS tunnel is established between
PE1 and PE2.

Figure 9-7 Networking diagram for inter-AS 6PE OptionC solution 1
AS 100 AS 200
Loopback1 Loopback1
3.3.3.3/32 4.4.4.4/32
GE1/0/1
GE1/0/0 GE1/0/0 GE1/0/1
20.1.1.2/24
192.1.1.1/24 192.1.1.2/24 20.1.2.1/24
Loopback1
ASBR1 ASBR2 Loopback1
2.2.2.2/32
5.5.5.5/32
GE1/0/1 GE1/0/1
PE1 20.1.1.1/24 20.1.2.2/24 PE2
GE1/0/0 GE1/0/0
2001:db8:1::2/64 2001:db8:2::2/64
GE1/0/0 GE1/0/0
2001:db8:1::1/64 2001:db8:2::1/64
CE2
CE1
AS 400
AS 300
Loopback1 Loopback1
2001:db8:5::5/64 2001:db8:6::6/64
1. Configure a dynamic routing protocol for PE1 and ASBR1 to learn each other's loopback
interface addresses and for PE2 and ASBR2 to learn each other's loopback interface
addresses.
3. Configure a BGP LSP between PE1 and PE2.
l Configure a routing policy on each ASBR. Configure a routing policy on each ASBR.
After receiving a loopback route from a PE in the same AS, an ASBR assigns an MPLS
label to the route when advertising this route to the remote ASBR. An ASBR assigns
new MPLS labels to labeled IPv4 routes when advertising the routes to the PE in the
local AS.
l Establish an IBGP peer relationship between PE1 and ASBR1 and between PE2 and
ASBR2.
l Configure each ASBR to exchange labeled IPv4 routes with the PE in the same AS and
with the ASBR in the other AS.
4. Configure an MP-EBGP peer relationship between PE1 and PE2 and enable the function
to exchange labeled IPv6 routes on PE1 and PE2, so that BGP4+ routes can be transmitted

NOTE
An EBGP peer relationships can be established between PEs of different ASs. In most cases, these
PEs are not directly connected, and the maximum hops between them must be specified.
Data Preparation
l Open Shortest Path First (OSPF) process IDs 1 and area IDs 0 of PE1, PE2, ASBR1, and
ASBR2
respectively
l Routing policies that apply to routes from ASBR1 to PE1 and ASBR2 and routing policies
that apply to routes from ASBR2 to PE2 and ASBR1
Procedure
The following example uses OSPF as the IGP. The detailed configurations are not provided here.
NOTE
When configuring the IGP, configure OSPF to advertise the 32-bit loopback interface addresses to be used
as LSR IDs.
between the PEs and ASBRs in the same AS. The display ospf peer command output shows
that the OSPF neighbor relationship status is Full. The following example uses the display on
PE1.
[PE1] display ospf peer

Neighbors

DR: 20.1.1.2 BDR: 20.1.1.1 MTU: 0

The PEs and ASBRs in the same AS can learn each other's loopback interface addresses and
ping each other.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
PE1.
[ASBR1] mpls
[ASBR1-mpls] quit
[ASBR1] mpls ldp
PE2.
[ASBR2] mpls
[ASBR2-mpls] quit
[ASBR2] mpls ldp
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
PE1.
LDP LSP Information

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


-------------------------------------------------------------------------------
2.2.2.2/32 3/NULL 3.3.3.3 127.0.0.1 InLoop0
*2.2.2.2/32 Liberal/1024 DS/3.3.3.3
3.3.3.3/32 NULL/3 - 20.1.1.2 GE1/0/1
3.3.3.3/32 1024/3 3.3.3.3 20.1.1.2 GE1/0/1
*5.5.5.5/32 Liberal/1027 DS/3.3.3.3
-------------------------------------------------------------------------------
Step 4 Configure IBGP peer relationships in AS 100 and AS 200 in the IPv4 address family view.
# Establish an MP-IBGP peer relationship between PE1 and ASBR1.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.3 connect-interface loopback 1
[PE1-bgp] quit

[ASBR1] bgp 100
[ASBR1-bgp] peer 2.2.2.2 connect-interface loopback 1
[ASBR1-bgp] quit

[PE2] bgp 200
[PE2-bgp] peer 4.4.4.4 connect-interface loopback 1
[PE2-bgp] quit

[ASBR2] bgp 200
[ASBR2-bgp] peer 5.5.5.5 connect-interface loopback 1
[ASBR2-bgp] quit
Step 5 Enable the function to exchange labeled IPv4 routes.

# Configure PE1 to exchange labeled IPv4 routes with ASBR1.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.3 label-route-capability
[PE1-bgp] quit
# Enable MPLS on GE 1/0/0 that connects ASBR1 to ASBR2.

# Configure a routing policy on ASBR1.

[ASBR1] route-policy policy1 permit node 1
[ASBR1-route-policy] apply mpls-label
[ASBR1-route-policy] quit

[ASBR1-route-policy] if-match mpls-label

# Configure on ASBR1 a routing policy that applies to the routes advertised to PE1 and enable
ASBR1 to exchange labeled IPv4 routes with PE1.
[ASBR1] bgp 100
[ASBR1-bgp] peer 2.2.2.2 route-policy policy2 export
[ASBR1-bgp] peer 2.2.2.2 label-route-capability
# Configure a routing policy that applies to the routes advertised from ASBR1 to ASBR2 and
enable ASBR1 to exchange labeled IPv4 routes with ASBR2.
# Configure ASBR1 to advertise the route destined for PE1's loopback interface address to
ASBR2 and then to PE2.
[ASBR1-bgp] network 2.2.2.2 32
[ASBR1-bgp] quit
NOTE
The configuration of PE2 is similar to the configuration of PE1 and the configuration of ASBR2 is similar
to the configuration of ASBR1. For more information, see the following configuration files.
Step 6 Establish a 6PE peer relationship between PE1 and PE2.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] peer 5.5.5.5 ebgp-max-hop
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp] quit
# Configure CE1.
[CE1] ipv6
[CE1] bgp 300

[CE1-bgp] quit
# Configure PE1.
[PE1] ipv6
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] ipv6
[PE2] bgp 200
[PE2-bgp] quit
# Configure CE2.
[CE2] ipv6
[CE2] bgp 400
[CE2-bgp] quit


PrefRcv
5.5.5.5 4 200 38 39 0 00:34:02 Established

1
2001:db8:1::1 4 300 27 41 0 00:24:54 Established
1


PrefRcv
2.2.2.2 4 100 40 40 0 00:36:36 Established

1
2001:db8:2::1 4 400 30 40 0 00:27:19 Established
1








Loopback1 interface of CE2 can be pinged. The following example uses the display on CE1.
[CE1] ping ipv6 -a 2001:db8:5::5 2001:db8:6::6


0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ipv6
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 300
router-id 1.1.1.1
#
ipv6-family unicast
network 2001:db8:5:: 64
#
return

#
sysname PE1
#
ipv6
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100


#
ipv4-family unicast
peer 3.3.3.3 enable
peer 5.5.5.5 enable
#
ipv6-family unicast
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 20.1.1.0 0.0.0.255
#
return

#
sysname ASBR1
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
undo shutdown
ip address 192.1.1.1 255.255.255.0
mpls
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 2.2.2.2 255.255.255.255
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 20.1.1.0 0.0.0.255
#


apply mpls-label
#
if-match mpls-label
apply mpls-label
#
return

#
sysname ASBR2
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
undo shutdown
ip address 192.1.1.2 255.255.255.0
mpls
#
undo shutdown
ip address 20.1.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 5.5.5.5 255.255.255.255
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 20.1.2.0 0.0.0.255
#
apply mpls-label
#
if-match mpls-label
apply mpls-label
#
return

#
sysname PE2
#
ipv6

#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ipv6-family unicast
peer 2.2.2.2 enable
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 20.1.2.0 0.0.0.255
#
return

#
sysname CE2
#
ipv6
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 400
router-id 6.6.6.6
#
ipv6-family unicast

network 2001:db8:6:: 64
#
return
9.18.8 Example for Configuring Inter-AS 6PE OptionC (Solution 2)

OptionC solution 2 to enable separate IPv6 networks that connect to different ASs to
communicate over an inter-AS OptionC network.
communicate.
inter-AS OptionC public network tunnels are established between PEs, use the inter-AS 6PE
OptionC solution. As shown in Figure 9-8, an IPv6 link is established between CE1 and PE1
and between CE2 and PE2. An IPv4 link is established between PE1 and ASBR1, between PE2
and ASBR2, and between ASBR1 and ASBR2. BGP4+ runs between CE1 and PE1 and between
PE2 and CE2. MP-EBGP runs between PE1 and PE2 and an end-to-end MPLS tunnel is
established between PE1 and PE2. To enable separate IPv6 networks to communicate, use inter-
AS OptionC solution 2.
Figure 9-8 Networking diagram for inter-AS 6PE OptionC solution 2
AS 100 AS 200
Loopback1 Loopback1
3.3.3.3/32 4.4.4.4/32
GE1/0/1
GE1/0/0 GE1/0/0 GE1/0/1
20.1.1.2/24
192.1.1.1/24 192.1.1.2/24 20.1.2.1/24
Loopback1
ASBR1 ASBR2 Loopback1
2.2.2.2/32
5.5.5.5/32
GE1/0/1 GE1/0/1
PE1 20.1.1.1/24 20.1.2.2/24 PE2
GE1/0/0 GE1/0/0
2001:db8:1::2/64 2001:db8:2::2/64
GE1/0/0 GE1/0/0
2001:db8:1::1/64 2001:db8:2::1/64
CE2
CE1
AS 400
AS 300
Loopback1 Loopback1
2001:db8:5::5/64 2001:db8:6::6/64

1. Configure a dynamic routing protocol for PE1 and ASBR1 to learn each other's loopback
interface addresses and for PE2 and ASBR2 to learn each other's loopback interface
addresses.
3. Configure a BGP LSP between PE1 and PE2.
l Configure the PEs in different ASs to exchange routes through ASBRs.
l Configure a routing policy on each ASBR. After receiving a loopback route from a PE
in the same AS, an ASBR assigns an MPLS label to the route when advertising this
route to the remote ASBR. An ASBR assigns new MPLS labels to labeled IPv4 routes
when advertising the routes to the PE in the local AS.
l Configure the local and remote ASBRs to exchange labeled IPv4 routes.
l Configure an LDP LSP between ASBRs to transmit the labeled BGP routes of the public
network.
4. Configure an MP-EBGP peer relationship between PE1 and PE2 and enable the function
to exchange labeled IPv6 routes on PE1 and PE2, so that BGP4+ routes can be transmitted
NOTE
An EBGP peer relationships can be established between PEs of different ASs. In most cases, these
PEs are not directly connected, and the maximum hops between them must be specified.
Data Preparation
l Open Shortest Path First (OSPF) process ID 1 and area ID 0 of PE1, PE2, ASBR1, and
ASBR2
respectively
Procedure
The following example uses OSPF as the IGP. The detailed configurations are not provided here.

NOTE
Configure OSPF to advertise the 32-bit loopback interface addresses to be used as LSR IDs.
between the PEs and ASBRs in the same AS. The display ospf peer command output shows
that the OSPF neighbor relationship status is Full.
The PEs and ASBRs in the same AS can learn the loopback interface addresses of each other
and ping each other.
Step 3 Establish an EBGP peer relationship between ASBRs.
# Configure ASBR1.
[ASBR1] bgp 100
[ASBR1-bgp] quit
# Configure ASBR2.
[ASBR2] bgp 200
[ASBR2-bgp] quit
After the configurations in this step are complete, run the display bgp peer command on each
ASBR. The command output shows that the EBGP peer relationship status is Established. The
following uses the display on ASBR1 as an example:
[ASBR1] display bgp peer


PrefRcv
192.1.1.2 4 200 1188 1188 0 19:45:35 Established

1
Step 4 Advertise the routes of a PE in an AS to the remote PE.

# Configure ASBR1 to advertise the loopback interface address of PE1 to ASBR2.
[ASBR1] bgp 100
[ASBR1-bgp] quit
# Configure ASBR2 to advertise the loopback address of PE2 to ASBR1.

[ASBR2] bgp 200
[ASBR2-bgp] quit
# Configure ASBR1 to import BGP routes to OSPF and advertise the routes of PE2 to PE1 using
OSPF.
[ASBR1] ospf 1
[ASBR1-ospf-1] import-route bgp
# Configure ASBR2 to import BGP routes to OSPF and advertise the routes of PE1 to PE2 using
OSPF.
[ASBR2] ospf 1
[ASBR2-ospf-1] import-route bgp

After the configurations in this step are complete, run the display ip routing-table command
on each PE. The following example uses the display on PE1 as an example.
[PE1] display ip routing-table
------------------------------------------------------------------------------

3.3.3.3/32 OSPF 10 1 D 20.1.1.2
5.5.5.5/32 O_ASE 150 1 D 20.1.1.2
20.1.1.0/24 Direct 0 0 D 20.1.1.1
20.1.1.1/32 Direct 0 0 D 127.0.0.1
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
PE1.
[ASBR1] mpls
[ASBR1-mpls] quit
[ASBR1] mpls ldp
PE2.
[ASBR2] mpls
[ASBR2-mpls] quit
[ASBR2] mpls ldp


[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
PE1.
LDP LSP Information

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
2.2.2.2/32 3/NULL 3.3.3.3 127.0.0.1 InLoop0
*2.2.2.2/32 Liberal/1024 DS/3.3.3.3
3.3.3.3/32 NULL/3 - 20.1.1.2 GE1/0/1
3.3.3.3/32 1024/3 3.3.3.3 20.1.1.2 GE1/0/1
5.5.5.5/32 NULL/1026 - 20.1.1.2 GE1/0/1
5.5.5.5/32 1027/1026 3.3.3.3 20.1.1.2 GE1/0/1
-------------------------------------------------------------------------------
Step 6 Configure ASBRs to exchange labeled IPv4 routes.
# Enable MPLS on GE 1/0/0 that connects ASBR1 to ASBR2.

# Configure a routing policy on ASBR1.

# Configure a routing policy that applies to the routes advertised from ASBR1 to ASBR2 and
enable ASBR1 to exchange labeled IPv4 routes with ASBR2.
[ASBR1] bgp 100
[ASBR1-bgp] quit
NOTE
The configuration of ASBR2 is similar to that of ASBR1. For more information, see the following
Step 7 Configure an LDP LSP between ASBRs to transmit the labeled BGP routes of the public
network.

# Configure ASBR1.
[ASBR1] mpls
[ASBR1-mpls] lsp-trigger bgp-label-route
[ASBR1-mpls] quit
# Configure ASBR2.
[ASBR2] mpls
[ASBR2-mpls] lsp-trigger bgp-label-route
[ASBR2-mpls] quit
Step 8 Establish a 6PE peer relationship between PE1 and PE2.

# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 200
[PE2-bgp] quit
# Configure CE1.
[CE1] ipv6
[CE1] bgp 300
[CE1-bgp] quit
# Configure PE1.
[PE1] ipv6
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] ipv6
[PE2] bgp 200

[PE2-bgp] quit
# Configure CE2.
[CE2] ipv6
[CE2] bgp 400
[CE2-bgp] quit


PrefRcv
5.5.5.5 4 200 54 55 0 00:50:20 Established

2
2001:db8:1::1 4 300 73 75 0 01:10:19 Established
1


PrefRcv
2.2.2.2 4 100 53 53 0 00:49:31 Established

2
2001:db8:2::1 4 400 75 107 0 01:12:16 Established
1










[CE1] ping ipv6 2001:db8:6::6

0.00% packet loss
----End
Configuration Files
#
sysname CE1
#
ipv6

#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 300
router-id 1.1.1.1
#
ipv6-family unicast
network 2001:db8:5:: 64
#
return

#
sysname PE1
#
ipv6
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 5.5.5.5 enable
#
ipv6-family unicast
import-route direct
peer 5.5.5.5 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 20.1.1.0 0.0.0.255

#
return

#
sysname ASBR1
#
mpls lsr-id 3.3.3.3
mpls
lsp-trigger bgp-label-route
#
mpls ldp
#
undo shutdown
ip address 192.1.1.1 255.255.255.0
mpls
#
shutdown
#
undo shutdown
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
network 2.2.2.2 255.255.255.255
#
ospf 1
import-route bgp
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 20.1.1.0 0.0.0.255
#
apply mpls-label
#
return

#
sysname ASBR2
#
mpls lsr-id 4.4.4.4
mpls
lsp-trigger bgp-label-route
#
mpls ldp
#
undo shutdown
ip address 192.1.1.2 255.255.255.0
mpls
#

undo shutdown
ip address 20.1.2.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 200
#
ipv4-family unicast
network 5.5.5.5 255.255.255.255
#
ospf 1
import-route bgp
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 20.1.2.0 0.0.0.255
#
apply mpls-label
#
return

#
sysname PE2
#
ipv6
#
mpls lsr-id 5.5.5.5
mpls
#
mpls ldp
#
undo shutdown
ipv6 enable
#
undo shutdown
ip address 20.1.2.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 200
#
ipv4-family unicast
peer 2.2.2.2 enable
#
ipv6-family unicast
import-route direct

peer 2.2.2.2 enable

#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 20.1.2.0 0.0.0.255
#
return

#
sysname CE2
#
ipv6
#
undo shutdown
ipv6 enable
#
interface LoopBack1
ipv6 enable
#
bgp 400
router-id 6.6.6.6
#
ipv6-family unicast
network 2001:db8:6:: 64
#
return
9.18.9 Example for Configuring BGP4+ 6PE FRR

After you configure IPv6 Provider Edge (6PE) FRR, 6PE devices can select the backup next
hop for received 6PE routes. When the next hop of the primary route between PEs becomes
unreachable, traffic will be quickly redirected to the backup next hop.
A 6PE device learns the 6PE routes with the same IP prefix from different 6PE peers. After BGP
6PE FRR is configured on the 6PE device, a backup link can be selected for the device. When
the next hop of the primary route between PEs becomes unreachable, traffic can be quickly
switched to the backup link.
As shown in Figure 9-9, 6PE peer relationships are established between PE1 and PE2, and
between PE1 and PE3. PE1 receives the 6PE routes to the loopback interface on the CE from
PE2 and PE3. On PE1, it is required to configure a primary 6PE route and a backup 6PE route
to the loopback interface on the CE, with Link_A serving as the primary link and Link_B serving
as the backup link.

Figure 9-9 Networking diagram of configuring 6PE FRR

Loopback1
2.2.2.2/32
IPv4/MPLS
Network PE2
GE2/0/0
POS1/0/0 IPv6 Network
Loopback1 2001:db8:2001::1/64
AS 100 30.1.1.2/30
1.1.1.1/32 GE1/0/0
POS2/0/0 2001:db8:2001::2/64
30.1.1.1/30 Link_A Loopback1
CE 2001:db8:2003::
PE1
Link_B
POS3/0/0 GE2/0/0 AS 200
20.1.1.1/30 2001:db8:2002::2/64
POS1/0/0
GE2/0/0
20.1.1.2/30
2001:db8:2002::1/64
PE3
Loopback1
3.3.3.3/32
1. Configure an IGP on the IPv4/MPLS network to enable the connectivity between network
devices.
2. Enable MPLS and MPLS LDP globally and on the interfaces of the routers on the network
and set up LDP LSPs.
3. Establish 6PE peer relationships between the PEs.
4. Establish EBGP peer relationships between the PEs and CE and import the address of the
loopback interface on the CE into BGP.
5. Configure 6PE FRR on PE1.
Data Preparation
l IP or IPv6 addresses of the interfaces on the routers

l Numbers of the ASs where the PEs and CE reside
l Names of the routing policies used to affect route costs on the PEs
Procedure
Step 1 Configure IP or IPv6 addresses for the interfaces on the routers. For details, see the following
Step 2 Configure an IGP on the IPv4/MPLS network.
In this example, OSPF, as an IGP, is configured. For the configuration details, see the following

After the configuration is complete, run the display ip routing-table command on the PEs, and
you can see that the routers have learned the addresses of the loopback interfaces on the other
routers. The following takes the display on PE1 as an example:
[PE1] display ip routing-table
------------------------------------------------------------------------------

2.2.2.2/32 OSPF 10 1562 D 30.1.1.2 Pos2/0/0
3.3.3.3/32 OSPF 10 1562 D 20.1.1.2 Pos3/0/0
30.1.1.0/30 Direct 0 0 D 30.1.1.1 Pos2/0/0
30.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
30.1.1.2/32 Direct 0 0 D 30.1.1.2 Pos2/0/0
20.1.1.0/30 Direct 0 0 D 20.1.1.1 Pos3/0/0
20.1.1.1/32 Direct 0 0 D 127.0.0.1 Pos3/0/0
20.1.1.2/32 Direct 0 0 D 20.1.1.2 Pos3/0/0
Step 3 Enable MPLS and MPLS LDP globally and on the interfaces of the routers on the network and
set up LDP LSPs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-Pos2/0/0] mpls
[PE1-Pos2/0/0] quit
[PE1-Pos3/0/0] mpls
[PE1-Pos3/0/0] quit
The configurations of the PE2 and PE3 are similar to the configuration of PE1. For details, see
the following configuration files.
After the configuration is complete, run the display mpls ldp lsp command on the PEs, and you
can find the labels allocated to the routes to the loopback interfaces on the other PEs.
LDP LSP Information
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
1.1.1.1/32 3/NULL 3.3.3.3 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/1024 DS/2.2.2.2
*1.1.1.1/32 Liberal/1024 DS/3.3.3.3
2.2.2.2/32 NULL/3 - 30.1.1.2 Pos2/0/0
2.2.2.2/32 1024/3 2.2.2.2 30.1.1.2 Pos2/0/0
2.2.2.2/32 1024/3 3.3.3.3 30.1.1.2 Pos2/0/0
*2.2.2.2/32 Liberal/1025 DS/3.3.3.3
3.3.3.3/32 NULL/3 - 20.1.1.2 Pos3/0/0
3.3.3.3/32 1025/3 2.2.2.2 20.1.1.2 Pos3/0/0
3.3.3.3/32 1025/3 3.3.3.3 20.1.1.2 Pos3/0/0
*3.3.3.3/32 Liberal/1025 DS/2.2.2.2

-------------------------------------------------------------------------------
A '*' before a UpstreamPeer means the session is in GR state
Step 4 Establish 6PE peer relationships between the PEs.
Establish 6PE peer relationships between PE1 and PE2, and between PE1 and PE3.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
# Configure PE3.
[PE3] bgp 100
[PE3-bgp] quit
After the configuration is complete, run the display bgp ipv6 peer command on the PEs, and
you can find that the status of the peer relationships is Established. The following takes the
display on PE1 as an example:


PrefRcv
2.2.2.2 4 100 19 20 0 00:12:53 Established 1

3.3.3.3 4 100 16 18 0 00:12:13 Established 1

Step 5 Establish EBGP peer relationships between PE2 and the CE, and between PE3 and the CE, and
import the address of the loopback interface on the CE into BGP.
# Configure PE2.
[PE2] bgp 100
[PE2-bgp] quit
# Configure PE3.
[PE3] bgp 100
[PE3-bgp] quit
# Configure the CE.

[CE] bgp 200
[CE-bgp] peer 2001:db8:2001::1 as-number 100
[CE-bgp] peer 2001:db8:2002::1 as-number 100
[CE-bgp] ipv6-family unicast
[CE-bgp-af-ipv6] peer 2001:db8:2001::1 enable
[CE-bgp-af-ipv6] peer 2001:db8:2002::1 enable
[CE-bgp-af-ipv6] network 2001:db8:2003::1 128
[CE-bgp-af-ipv6] quit
[CE-bgp] quit
After the configuration is complete, run the display ipv6 routing-table command on the PEs,
and you can find that the PEs have received the routes to the loopback interface on the CE. The
following takes the display on PE2 as an example:
<PE2> display ipv6 routing-table







Step 6 Configure a routing policy on PE3 and apply this policy to make the cost of the route sent from
PE3 to PE1 greater than the cost of the route sent from PE2 to PE1. In this case, PE1 later will
select the route sent from PE2.
# Configure PE3.
[PE3] route-policy addcost permit node 10
[PE3-route-policy] apply cost 20
[PE3] bgp 100
[PE3-bgp-af-ipv6] peer 1.1.1.1 route-policy addcost export
[PE3-bgp] quit
Step 7 Enable 6PE FRR on PE1.
# Configure PE1.
[PE1] bgp 100
[PE1-bgp-af-ipv6] auto-frr
[PE1-bgp] quit

Run the display ipv6 routing-table command on PE1. You can find that PE2 is the next hop of
PE1 on the route to the loopback interface on the CE and there are also a backup next hop and
a backup label on PE1.
[PE1] display ipv6 routing-table 2001:db8:2003::1 verbose
Routing Table :
Summary Count : 1

IndirectID : 0x4
BkNextHop : ::FFFF:3.3.3.3 BkInterface :
BkLabel : 1029 BkTunnelID : 0x0
BkPETunnelID : 0xd BkIndirectID : 0x3
After running the undo ipv6 enable command on GE 2/0/0 of PE2, run the display ipv6 routing-
table command on PE1. You can find that PE3 is the next hop of PE1 on the route to the loopback
interface on the CE and there is no backup next hop for PE1.
[PE1] display ipv6 routing-table 2001:db8:2003::1 verbose
Routing Table :
Summary Count : 1



IndirectID : 0x3
RelayNextHop : :: TunnelID : 0xd
----End
Configuration Files
#
sysname PE1
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 30.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface Pos3/0/0
link-protocol ppp
ip address 20.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv6-family unicast
auto-frr
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 30.1.1.0 0.0.0.3
network 20.1.1.0 0.0.0.3
#
return

#
sysname PE2
#
ipv6

#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 30.1.1.2 255.255.255.252
mpls
mpls ldp
#
link-protocol ppp
ipv6 enable
ipv6 address 2001:db8:2001::1 64
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
router-id 2.2.2.2
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv6-family unicast
peer 1.1.1.1 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 30.1.1.0 0.0.0.3
#
return

#
sysname PE3
#
ipv6
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp
ip address 20.1.1.2 255.255.255.252
mpls
mpls ldp
#
link-protocol ppp
ipv6 enable
ipv6 address 2001:db8:2002::1/64
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255

#
bgp 100
router-id 3.3.3.3
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv6-family unicast
peer 1.1.1.1 enable
peer 1.1.1.1 route-policy addcost export
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 20.1.1.0 0.0.0.3
#
route-policy addcost permit node 10
apply cost 20
#
return

#
sysname CE
#
ipv6
#
link-protocol ppp
ipv6 enable
ipv6 address 2001:db8:2001::2/64
#
link-protocol ppp
ipv6 enable
ipv6 address 2001:db8:2002::2/64
#
interface LoopBack1
ipv6 enable
ipv6 address 2001:db8:2003::1/128
#
bgp 200
#
ipv4-family unicast
#
ipv6-family unicast
network 2001:db8:2003::1 128
#
return

Configuration Guide - IP Routing 10 Routing Policy Configuration
10 Routing Policy Configuration
About This Chapter
Routing policies are used to filter routes to change the path through which network traffic passes.
10.1 Introduction
By configuring routing policies, you can properly use network resources.
10.2 Configuring the IP-Prefix List

An IP prefix list filters routes according to the destination addresses of the routes.
10.3 Configuring the Route-Policy

Each node of a Route-Policy consists of a set of if-match and apply clauses.
10.4 Applying Filters to Received Routes

By applying the related filters of routing policies to routing protocols, you can filter the received
routes.
10.5 Applying Filters to Advertised Routes

By applying the related filters of routing policies to routing protocols, you can filter advertised
routes.
10.6 Applying Filters to Imported Routes

By applying the related filters of routing policies to routing protocols, you can filter imported
routes.
10.7 Controlling the Valid Time of the Routing policy

To ensure network stability, you need to configure the delay for applying a routing policy when
modifying the routing policy.
10.8 Maintaining the Routing Policy

Maintaining routing policies involves clearing the statistics of the IP prefix list and clearing the
number of routes which match or do not match the Route-Policy.

The configuration examples in this section explain the networking requirements, networking
diagram, configuration notes, configuration roadmap, and configuration procedure for different
types of routing policies.

10.1 Introduction
By configuring routing policies, you can properly use network resources.
10.1.1 Overview of the Routing Policy

By using routing policies, you can flexibly control the routes to be sent or received.
Routing Policy
Routing policies are used to filter routes and control the receiving and advertising of routes. By
changing the route attributes such as reachability, you can change the path that the traffic passes
through.
When a router sends or receives routes, it may use certain policies to filter routes. The policies
are used in the following situations:
l Send or receive routes that meet the matching rules.

l A routing protocol such as the Routing Information Protocol (RIP) needs to import the
routes discovered by other routing protocols to enrich its routing information. When
importing routes from other routing protocols, the router may import certain routes that
meet the matching rules, and set attributes of the routes imported to meet the requirement.
To implement a routing policy, you must:
l Define a set of matching rules and setting rules. The policy is applied to the routing
information to meet the requirements of the matching rules.
l Apply the matching rules to the routing policies for route advertisement, reception, and
import.
Differences Between Routing Policy and PBR

Different from the forwarding by searching the Forwarding information base (FIB) according
to the destination address of a packet, Policy-based routing (PBR) is a route selection mechanism
based on policies set by users. PBR supports the information based on the source address and
the length of a packet. PBR selects routes according to the set policy. PBR can be applicable to
security and load balancing.
Routing policies and PBR are different concepts. Table 10-1 shows the differences between the
two concepts.
Table 10-1 Differences between routing policy and PBR
Routing policy Policy-based routing
Forwards packets based on the Forwards packets based on the policy. If packets
destination address in the routing table. fail to be forwarded, the device forwards packets
by searching the routing table.

Routing policy Policy-based routing
Based on the control plane and serves Based on forwarding plane and serves for the
the routing protocol and routing table. forwarding policy.
Combines with the routing protocol Needs to be manually configured hop by hop to
ensure that the packet is forwarded through the
policy.
10.1.2 Routing Policy Features Supported by the NE80E/40E

When configuring routing policies, you can use these filters: ACL, IP prefix list, AS-Path filter,
community filter, extended community filter, RD filter, and Route-Policy.
Filters
The NE80E/40E provides several types of filters for routing protocols, such as Access Control
Lists (ACLs), IP prefix lists, AS-Path filters, community filters, extended community filters
(Extcommunity-filters), and Route-Policies.
l ACL
The ACL consists of the ACL for IPv4 packets and the ACL for IPv6 packets. According
to the usage, ACLs are classified into three types, that is, interface-based ACLs, basic
ACLs, and advanced ACLs. When defining an ACL, you can specify the IP address and
subnet range to match the destination network segment address or the next hop address of
a route.
For details of the ACL configuration, refer to the HUAWEI NetEngine80E/40E Router
l IP-Prefix List
The IP-prefix list consists of IPv4 prefix list and IPv6 prefix list. The implementation of
the IP-prefix is flexible.
An IP-prefix list is identified by its list name. Each prefix list includes multiple entries.
Each entry can independently specify the matching range in the form of the network prefix.
The matching range is identified by an index number that designates the sequence of the
matching check.
During the matching, the router checks entries identified by index numbers in an ascending
order. When a route matches an entry, the system does not search the next entry matching
the route. For the detailed configuration, refer to Configuring the IP-Prefix List.
l AS-Path Filter
Border Gateway Protocol (BGP) routing information packet includes an autonomous
system (AS) path domain. The AS-Path filter specifies the matching condition for the AS
path domain.
For the configuration of AS-Path filter, refer to BGP Configuration.
l Community Filter
The community filter is used only in BGP. The BGP routing information includes a
community attribute domain. It is used to identify a community. The community filter
specifies the matching condition for the community attribute domain.

For the configuration of community filter, refer to BGP Configuration.

l Extcommunity-Filter
The Extcommunity-filter is used only in BGP. The extended community of BGP supports
only the Router-Target (RT) extended community of Virtual Private Network (VPN). The
Extcommunity-filter specifies matching rules for the extended community attribute.
For the configuration of excommunity-filter, refer to BGP Configuration.
l RD Filter
Through Route Distinguisher (RD), the VPN instance implements the independency of
address space and identifies the IPv4 and IPv6 prefixes of the same address space. The RD
attribute filter specifies matching conditions for different RDs.
For the configuration of the RD attribute filter, refer to the HUAWEI NetEngine80E/40E
Router Configuration Guide - VPN.
l Route-Policy
The Route-Policy is a complex filter. A Route-Policy is used to match certain route
attributes, and to change the route attributes when certain matching rules are met. The
Route-Policy uses the preceding filters to define its filtering rules.
A Route-Policy consists of multiple nodes. The relationship between the nodes is "OR".
The system checks the nodes in the routing policy, the node with the smaller value of node
is checked first. When the route matches a node in the routing policy, it passes the Route-
Policy and the system does not search the next matching node.
Each node comprises a set of if-match and apply clauses. The if-match clauses define the
matching rules. The matching objects are certain route attributes. The relationship between
if-match clauses in a node is "AND". A matching succeeds only when all the matching
rules specified by the if-match clauses in the same nod are matched.
The apply clauses specify actions. When a route matches a rule, the apply clause sets
certain attributes for the route. For the detailed configuration, refer to Configuring the
Route-Policy.
Application of the Routing Policy

The routing policy is used in the following situations:
l Import routes that meet the matching rules through filters when a routing protocol imports
routes discovered by other protocols.
l Filter routes that a routing protocol advertises or receives. Only the routes that meet the
matching rules are received or advertised.
For the configuration of routing policy applications, refer to the related routing protocol
configurations.
NOTE
After the routing policy changes, Routing Management Module (RM) immediately notifies various
protocols for processing by default.
10.2 Configuring the IP-Prefix List

An IP prefix list filters routes according to the destination addresses of the routes.


Before configuring the IP prefix list, familiarize yourself with the usage scenario, complete the
Before applying a routing policy, you should set the matching rules, that is, filters. Compared
with an ACL, an IP prefix list is more flexible. When the IP prefix list is used to filter routes, it
matches the destination address of a route.
None.
Data Preparation
To configure an IP prefix list, you need the following data.
No. Data
1 Name of IP prefix list
2 Matched address range
10.2.2 Configuring an IPv4 Prefix List

An IP prefix list filters routes according to IP address prefixes. An IP address prefix is defined
by the IP address and mask length.
Context
Perform the following steps on the router to which the IP prefix list is applied:
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ip-address
mask-length [ match-network ] [ greater-equal greater-equal-value ] [ less-equal
less-equal-value ]
match-network is used to filter routes to a specified IP address and can be configured only when
ipv4-address is 0.0.0.0. For example, the ip ip-prefix prefix1 permit 0.0.0.0 8 command filters

all routes with mask length 8, while the ip ip-prefix prefix1 permit 0.0.0.0 8 match-
network command filters all routes to the IP address range from 0.0.0.1 to 0.255.255.255.
The range of the mask length can be specified as mask-length <= greater-equal-value <= less-
equal-value <= 32. If only greater-equal is specified, the range of the prefix is [greater-equal-
value, 32]; if only less-equal is specified, the range of the prefix is [mask-length, less-equal-
value].
An IPv4 prefix list is identified by its list name. Each prefix list contains multiple entries. Each
entry can independently specify the matching range in the form of the network prefix and identify
it with an index number. For example, the following shows an IPv4 prefix list named abcd:
#
During the matching, the system checks the entries identified by the index numbers in an
ascending order. When a route matches an entry, it does not match other entries.
In the NE80E/40E, all unmatched routes cannot pass the filtering list. If all entries are in deny
mode, all routes are filtered. It is recommended that you define a permit 0.0.0.0 0 less-equal
32 entry after multiple entries in deny mode, therefore allowing all the other IPv4 routes to pass
the IP prefix list.
NOTE
If more than one IP-prefix entry is defined, at least one entry should be in the permit mode.

ip ip-prefix ip-prefix-name description text
The description information of the IP prefix list is displayed.
----End
10.2.3 Configuring an IPv6 Prefix List

An IPv6 prefix list filters routes according to IPv6 address prefixes. An IPv6 address prefix is
defined by the IPv6 address and mask length.
Context
Perform the following steps on the router to which the IP prefix list is applied:
Procedure
Step 1 Run:
system-view
Step 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 ]

match-network is used to filter routes to a specified IPv6 address and can be configured only
when ipv6-address is 0.0.0.0. For example, the ip ipv6-prefix prefix1 permit :: 96 command
filters all IPv6 routes with mask length 96, while the ip ipv6-prefix prefix1 permit :: 96 match-
network command filters all routes to the IPv6 address range from ::1 to ::FFFF:FFFF.
The range of the prefix length can be specified as prefix-length <= greater-equal-value <= less-
equal-value <= 128. If only greater-equal is specified, the range of the prefix is [greater-equal-
value, 128]; if only less-equal is specified, the range of the prefix is [prefix-length, less-equal-
value].
An IPv6 prefix list is identified by its list name. Each prefix list can include multiple entries.
Each entry can independently specify the matching range in the form of the network prefix and
identify it with an index number. For example, the following shows an IPv6 prefix list named
abcd:
#
ip ipv6-prefix abcd index 10 permit 2001:db8:1:: 64
ip ipv6-prefix abcd index 20 permit 2001:db8:2:: 64
During the matching, the system checks the entries identified by the index numbers in an
ascending order. When a route matches an entry, it does not match other entries.
In NE80E/40E, all unmatched routes are filtered. If all entries are in deny mode, all routes are
filtered. It is recommended that you define a permit :: 0 less-equal 128 after multiple entries
in deny mode, therefore allowing all the other IPv6 routes to pass the IP prefix list.
NOTE
If more than one IP-prefix entry is defined, at least one entry should be in the permit mode.

ip ipv6-prefix ipv6-prefix-name description text
The description information of the IPv6 prefix list is displayed.
----End

After an IP prefix list is configured, you can check information about the IP prefix list.
Prerequisites
The IP-Prefix list has been configured.
Procedure
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.
----End
Example
Run the display ip ip-prefix p1 command. You can view information about the prefix list named
p1.

<HUAWEI> display ip ip-prefix p1

Prefix-list pl
Permitted 5
Denied 2
index: 10 permit 192.168.0.0/16 ge 17 le 18
10.3 Configuring the Route-Policy

Each node of a Route-Policy consists of a set of if-match and apply clauses.

Before configuring the Route-Policy, familiarize yourself with the usage scenario, complete the
A Route-Policy is used to match routes or certain route attributes, and to change these attributes
when the matching rules are met.
A Route-Policy consists of multiple nodes. Each node is classified into the following clauses:
l if-match clauses: define the matching rules. The matching rules are used by the routes that
match the Route-Policy. The matching objects refer to some attributes of the route.
l apply clauses: specify actions, that is, configuration commands used to modify certain
attributes.
For more information about Route-Policy, refer to the HUAWEI NetEngine80E/40E Router
Feature Description - IP Routing.
To configure a Route-Policy, complete the following tasks:
l 10.2 Configuring the IP-Prefix List

l Configuring routing protocols
Data Preparation
To configure a Route-Policy, you need the following data.
No. Data
1 Name and node number of the Route-Policy
2 Matching rule
3 Route attributes to be modified

10.3.2 Creating a Route-Policy

By applying a Route-Policy, you can set attributes for the imported routes according to
networking requirements.
Context
Perform the following steps on the router to which the Route-Policy is applied:
Procedure
Step 1 Run:
system-view
Step 2 Run:
A node of the Route-Policy is created and the Route-Policy view is displayed.
l The parameter permit specifies a node in a Route-Policy in permit mode. If a route matches
the node, the router performs actions defined by the apply clauses and the matching is
complete. Otherwise, the route continues to match the next nod.
l The parameter deny specifies a node in a Route-Policy in deny mode. In deny mode, the
apply clauses are not used. If a route entry matches all the if-match clauses of the node, the
route is denied by the node and the next node is not matched. If the entry does not match all
the clauses, the next node is matched.
NOTE
In the NE80E/40E, by default, the unmatched routes are denied. If multiple nodes are defined in a Route-
Policy, at least one of them should be in permit mode.
When the parameter route-policy is used to filter routes, note the following:
l If a route does not match any node, it is denied by the Route-Policy.

l If all the nodes in the routing policy are in deny mode, all the routes are denied by the Route-
Policy.
When a Route-Policy is used to filter the routing information, the node with the smaller value
of node is tested first.

description text
The description of the routing policy is configured.
----End
10.3.3 (Optional) Configuring the If-Match Clause

The if-match clauses define the rules for matching certain route attributes.

Context
Each node of a Route-Policy can comprise multiple if-match clauses or no if-match clause at
all. If no if-match clause is configured for a node in the permit mode, all routes match the node.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The Route-Policy view is displayed.

l To set a matching rule that is based on the basic ACL, perform the following steps:
1. Run if-match acl { acl-number | acl-name }, the ACL is configured to match the routes.
as the rules.
When a route-policy is configured to filter routes:
– If the action specified in an ACL rule is permit, a route that has matched this rule
is considered to have passed the check by the if-match clause.
– If the action specified in an ACL rule is deny, a route that has matched this rule is
considered to have failed the check by the if-match clause.
– If a route has not matched any ACL rules, the route is considered to have failed the
check by the if-match clause.
– If an ACL does not contain any rules, all routes are considered to have failed the
– In a route-policy where the first node is a permit node, if a route has passed the
check by the if-match clause, the system will take the action specified in the
apply clause on this route. If the route has not passed the check by the if-match
clause, the system will take the action specified in the apply clause in the second
node in the route-policy.
– In a route-policy where the first node is a deny node, if a route has passed the check
by the if-match clause, the system will not take the action specified in the apply
clause on this route. If the route has not passed the check by the if-match clause,

the system will take the action specified in the apply clause in the second node in
the route-policy.
l To set a matching rule that is based on the advanced ACL, perform the following steps:
1. Run if-match acl acl-name, the ACL is configured to match the routes.
When a route-policy is configured to filter routes:
– If the action specified in an ACL rule is permit, a route that has matched this rule
is considered to have passed the check by the if-match clause.
– If the action specified in an ACL rule is deny, a route that has matched this rule is
considered to have failed the check by the if-match clause.
– If a route has not matched any ACL rules, the route is considered to have failed the
– If an ACL does not contain any rules, all routes are considered to have failed the
– In a route-policy where the first node is a permit node, if a route has passed the
check by the if-match clause, the system will take the action specified in the
apply clause on this route. If the route has not passed the check by the if-match
clause, the system will take the action specified in the apply clause in the second
node in the route-policy.
– In a route-policy where the first node is a deny node, if a route has passed the check
by the if-match clause, the system will not take the action specified in the apply
clause on this route. If the route has not passed the check by the if-match clause,
the system will take the action specified in the apply clause in the second node in
the route-policy.
l Run:
if-match cost cost
The cost is set to match the routes.

l Run:
if-match interface interface-type interface-number
The outbound interface is configured to match the routes.

l Run:
if-match ip { next-hop | route-source | group-address } { acl { acl-number | acl-
name } | ip-prefix ip-prefix-name }
The next hop, the source address or the multicast group address is configured to match the
routes.
l Run:
if-match ip-prefix ip-prefix-name
The IP prefix list is configured to match the routes.

NOTE
For the same Route-Policy node, you cannot run the if-match acl command and the if-match ip-
prefix command at the same time. This is because the latest configuration overrides the previous
configuration.
l Run:
if-match ipv6 { address | next-hop | route-source } prefix-list ipv6-prefix-name
The next hop or the source address is configured to match the routes.
l Perform as follows to match the type of the route:
– Run:
if-match route-type { external-type1 | external-type1or2 | external-type2 |
internal | nssa-external-type1 | nssa-external-type1or2 | nssa-external-
type2 }
The route type, OSPF in this case, is set to match the routes.
– Run:
if-match route-type { is-is-level-1 | is-is-level-2 }
The route type, IS-IS in this case, is set to match the routes.
l Run:
if-match tag tag
The tag is set to match the routes.
The commands in Step 3 can be used regardless of the order. A node can have multiple or no
if-match clauses.
NOTE
l For the same node in a route-policy, the relationship between if-match clauses is "AND". The route
must meet all the matching rules before the actions defined by the apply clauses are performed. In the
if-match route-type and if-match interface commands, the relationship between the if-match clauses
is "OR". In other commands, the relationship between if-match clauses is "AND".
l If no if-match clause is specified, all the routes meet the matching rules.
----End
10.3.4 (Optional) Configuring the Apply Clause

The apply clauses specify actions to set certain route attributes.
Context
Each node of a Route-Policy can comprise multiple apply clauses or no apply clause at all. The
apply clause is not used when routes need to be filtered but attributes of the routes do not need
to be set.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The Route-Policy view is displayed.

l Run:
apply backup-interface interface-type interface-number
The backup outbound interface is set.

l Run:
apply backup-nexthop { ip-address | auto }
The backup next hop is set.

l Run:
apply cost [ + | - ] cost
The cost of the route is set.

l Set the cost type of the route.
– Run the apply cost-type { external | internal } command to set the cost type of an IS-
IS route.
– Run the apply cost-type { type-1 | type-2 } command to set the cost type of an OSPF
route.
The apply cost-type { external | internal } command and the apply cost-type { type-1 |
type-2 } command are mutually exclusive and cannot be configured at the same time.
l Run:
apply ip-address next-hop { peer-address | ipv4-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 route level of IS-IS is set.

l Run:
apply ospf { backbone | stub-area }
The area of the OSPF that routes are imported into is set.
l Run:
apply preference preference
The preference of the routing protocol is set.

The smaller the preference value, the higher the preference.
l Run:
apply tag tag
The tag of the route is set.
----End

10.3.5 Applying a Route-Policy

A route-policy takes effect only when it is applied to a routing protocol.
Context
A route-policy can be applied to direct, static, RIP/RIPng, IS-IS, OSPF/OSPFv3, BGP/BGP4+,
multicast, and BGP/MPLS IP VPN routes. In addition, a route-policy can be applied to an FRR
scenario. Perform one of the following configurations as needed:
l Apply a route-policy to direct routes.
l Apply a route-policy to static routes.
l Apply a route-policy to RIP routes.
l Apply a route-policy to RIPng routes.
l Apply a route-policy to IPv4 IS-IS routes.
l Apply a route-policy to OSPF routes.
l Apply a route-policy to OSPFv3 routes.
l Apply a route-policy to BGP routes.
l Apply a route-policy to BGP4+ routes.
l Apply a route-policy to multicast routes.
l Apply a route-policy to BGP/MPLS IP VPN routes.
l Apply a route-policy to an FRR scenario.
Procedure
l Apply a route-policy to direct routes.
1. Run:
system-view

2. To apply a route-policy to specific direct routes, see Table 10-2.
Table 10-2 Applying a route-policy to direct routes
Objectives Command Reference
To configure a arp vlink-direct-route 1.15 Configuring the

device to advertise advertise [ route-policy route- Advertisement of IPv4
ARP Vlink direct policy-name ] ARP Vlink Direct
routes that match a Routes on the Public
route-policy on the Network
public network

To configure a ipv6 nd vlink-direct-route 1.16 Configuring the

device to advertise advertise [ route-policy route- Advertisement of IPv6
Neighbor policy-name ] NDP Vlink Direct
Discovery Protocol Routes on the Public
(NDP) Vlink direct Network
routes that match a
route-policy on the
public network
To apply a route- ip direct-routing-table route- -

policy to direct policy route-policy-name
routes on the public
network
NOTE
Currently, QoS
information, such as
the traffic behavior
or local ID, can be
configured for direct
routes only based on
a route-policy. A
router applies
different QoS
policies to packets
based on the QoS
information while
forwarding these
packets. In this
manner, traffic
statistics can be
collected, and
authentication and
accounting can be
performed based on
the direct routes.
l Apply a route-policy to static routes.

1. Run:
system-view

2. Run:
ip static-routing-table route-policy route-policy-name
A route-policy is applied to static routes on the public network.

l Apply a route-policy to RIP routes.
1. Run:
system-view

2. Run:

rip [ process-id ]
A RIP process is enabled, and the RIP view is displayed.

3. To apply a route-policy to specific RIP routes, see Table 10-3.
Table 10-3 Applying a route-policy to RIP routes
To configure a default-route originate [ cost 3.5.2 Configuring RIP to

device to generate a cost | tag tag | route-policy route- Advertise Default
default route or policy-name [ avoid-learning ] ] * Routes
advertise a default
route in the routing
table to neighbors
only when the
matching conditions
of a route-policy are
met
To configure RIP to import-route bgp [ permit-ibgp ] 3.5.4 Configuring RIP to

import the BGP [ cost { cost | transparent } | route- Filter the Routes to be
routes that match a policy route-policy-name ] * Sent
route-policy
To configure RIP to import-route { static | direct | 3.5.4 Configuring RIP to

import the routes unr | { rip | ospf | isis } [ process- Filter the Routes to be
from another routing id ] } [ cost cost | route-policy Sent
protocol that match a route-policy-name ] *
route-policy
To set a priority for preference { preference | route- 3.3.3 Configuring RIP

routes that match a policy route-policy-name } * Preference
route-policy
l Apply a route-policy to RIPng routes.

1. Run:
system-view

2. Run:
A RIPng process is enabled, and the RIPng view is displayed.

3. To apply a route-policy to specific RIPng routes, see Table 10-4.

Table 10-4 Applying a route-policy to RIPng routes
To configure RIPng import-route { { ripng | isis | 4.6.4 Configuring RIPng

to import the routes ospfv3 } [ process-id ] | bgp to Filter the Routes to be
from another routing [ permit-ibgp ] | unr | direct | Sent
protocol that match a static } [ cost cost | route-policy
route-policy route-policy-name ] *
To set a priority for preference { preference | route- 4.3.2 Configuring the

RIPng routes that policy route-policy-name } * RIPng Preference
match a route-policy

– To apply a route-policy in the IS-IS view, perform the following operations:
1. Run the system-view command to enter the system view.
2. Run the isis [ process-id ] command to enter the IS-IS view.
3. To apply a route-policy to IPv4 IS-IS routes in the IS-IS view, see Table 10-5.
Table 10-5 Applying a route-policy to IPv4 IS-IS routes in the IS-IS view
To configure IS-IS default-route-advertise route- -

to generate and policy route-policy-name [ cost 7.4.6 Configuring IS-IS
advertise default cost | tag tag | [ level-1 | to Generate IPv4
routes to the IS-IS level-1-2 | level-2 ] ] * [ avoid- Default Routes
domain only when learning ]
external routes that
match a route-
policy exist in the
routing table of a
Level-1-2 router
To configure IS-IS filter-policy route-policy route- 7.6.3 Configuring IPv4

to advertise the policy-name export [ protocol IS-IS to Import
routes that are [ process-id ] ] External Routes
imported from
another routing
protocol and match
a route-policy
To configure IS-IS filter-policy route-policy route- 7.6.3 Configuring IPv4

to accept the routes policy-name import IS-IS to Import
that match a route- External Routes
policy

To configure IS-IS import-route { direct | static | 7.6.3 Configuring IPv4

to import the routes unr | { ospf | rip | isis } [ process- IS-IS to Import
from another id ] | bgp [ permit-ibgp ] } [ cost- External Routes
routing protocol type { external | internal } |
that match a route- cost cost | tag tag | route-policy
policy route-policy-name | [ level-1 |
level-2 | level-1-2 ] ] *
import-route { { ospf | rip |
isis } [ process-id ] | bgp [ permit-
ibgp ] | direct | unr } inherit-
cost [ { level-1 | level-2 |
level-1-2 } | tag tag | route-
policy route-policy-name ] *
To configure import-route isis level-1 into 7.4.2 Configuring IPv4

Level-1 routes that level-2 [ filter-policy route- IS-IS Route Leaking
match a route- policy route-policy-name | tag
policy to leak to a tag ] *
Level-2 area
To configure import-route isis level-2 into 7.4.2 Configuring IPv4

Level-2 routes that level-1 [ filter-policy route- IS-IS Route Leaking
match a route- policy route-policy-name | tag
Level-1 area
To configure a preference { route-policy route- 7.6.2 Configuring a

priority for the IS-IS policy-name | preference } * Preference Value for
routes that match a IPv4 IS-IS
route-policy
– To apply a route-policy in the IS-IS FRR view, perform the following operations:

3. Run the frr command to enter the IS-IS FRR view.
4. Run the frr-policy route route-policy route-policy-name command to configure
IS-IS to add the backup routes that match a route-policy to the IP routing table.
For details on how to configure IS-IS Auto FRR (IPv4), see 7.11 Configuring
IPv4 IS-IS Auto FRR.
– To apply a route-policy in the IS-IS view, perform the following operations:

3. To apply a route-policy to IPv6 IS-IS routes in the IS-IS view, see Table 10-6.

Table 10-6 Applying a route-policy to IPv6 IS-IS routes in the IS-IS view
To configure IS-IS ipv6 default-route-advertise -

to generate and route-policy route-policy-name 7.13.6 Configuring IS-
advertise default [ cost cost | tag tag | [ level-1 | IS to Generate IPv6
IPv6 routes to the level-2 | level-1-2 ] ] * [ avoid- Default Routes
IS-IS domain only learning ]
when external
routes that match a
route-policy exist in
the routing table of a
Level-1-2 router
To configure IS-IS ipv6 filter-policy route-policy 7.15.3 Configuring

to advertise the IPv6 route-policy-name export IPv6 IS-IS to Import
routes that are [ protocol [ process-id ] ] External Routes
imported from
another routing
protocol and match
a route-policy
To configure IS-IS ipv6 filter-policy route-policy 7.15.3 Configuring

to accept the IPv6 route-policy-name import IPv6 IS-IS to Import
routes that match a External Routes
route-policy
To configure IS-IS ipv6 import-route { direct | 7.15.3 Configuring

to import the IPv6 static | { ospfv3 | ripng | isis } IPv6 IS-IS to Import
routes from another [ process-id ] | bgp [ permit- External Routes
routing protocol ibgp ] } [ cost cost | tag tag |
that match a route- route-policy route-policy-name |
policy { level-1 | level-2 | level-1-2 } ] *
ipv6 import-route { { ripng |
isis | ospfv3 } [ process-id ] |
direct | bgp [ permit-ibgp ] }
inherit-cost [ tag tag | route-
policy route-policy-name |
[ level-1 | level-2 | level-1-2 ] ] *
To configure ipv6 import-route isis level-1 7.13.2 Configuring

Level-1 IPv6 routes into level-2 [ filter-policy route- IPv6 IS-IS Route
that match a route- policy route-policy-name | tag Leaking
Level-2 area
To configure ipv6 import-route isis level-2 7.13.2 Configuring

Level-2 IPv6 routes into level-1 [ filter-policy route- IPv6 IS-IS Route
that match a route- policy route-policy-name | tag Leaking
Level-1 area

To configure a ipv6 preference { route-policy 7.15.2 Configuring a

priority for the IPv6 route-policy-name | preference } Preference Value for
IS-IS routes that * IPv6 IS-IS
match a route-
policy
– To apply a route-policy in the IS-IS IPv6 topology view, perform the following
operations:
3. Run the ipv6 topology topology-name [ topology-id { multicast | topology-id } ]
command to bind the IS-IS process to an IPv6 topology and enter the IS-IS IPv6
topology view.
4. Run the 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 import routes to the IS-IS IPv6
topology.
For details on how to configure IPv6 IS-IS multi-topology, see 7.18 Configuring
Multi-Topology for IPv6 IS-IS.
l Apply a route-policy to OSPF routes.
– To apply a route-policy in the OSPF view, perform the following operations:
2. Run the ospf [ process-id ] command to enable an OSPF process and enter the
OSPF view.
3. To apply a route-policy to OSPF routes in the OSPF view, see Table 10-7.
Table 10-7 Applying a route-policy to OSPF routes
To configure OSPF default-route-advertise 5.5.3 Configuring

to advertise the [ [ always | permit-calculate- OSPF to Import a
default routes in the other ] | cost cost | type type | Default Route
routing table that are route-policy route-policy-name
not generated by [ match-any ] ] *
OSPF to a common
area based on the
parameters of a
route-policy

To configure OSPF filter-policy route-policy route- 5.5.2 Configuring

to advertise the policy-name export [ protocol OSPF to Import
routes that are [ process-id ] ] External Routes
imported from
another routing
protocol and match
a route-policy
To configure OSPF filter-policy route-policy route- 5.5.5 Configuring

to accept the routes policy-name [ secondary ] OSPF to Filter Routes
that match a route- import Received by OSPF
policy
To configure OSPF import-route { limit limit- 5.5.2 Configuring

to import the routes number | { bgp [ permit-ibgp ] | OSPF to Import
that match a route- direct | unr | rip [ process-id- External Routes
policy rip ] | static | isis [ process-id-
isis ] | ospf [ process-id-ospf ] }
[ cost cost | type type | tag tag |
route-policy route-policy-name ]
*}
To configure a local-mt filter-policy route- -

route-policy for policy route-policy-name
OSPF local MT so
that only the routes
that match the route-
policy are added to
the MIGP routing
table
To configure a preference [ ase ] { preference | 5.2.5 (Optional) Setting

priority for OSPF route-policy route-policy-name } the OSPF Priority
routes that match a *
route-policy
– To apply a route-policy in the OSPF area view, perform the following operations:

OSPF view.
3. Run the area area-id command to enter the OSPF area view.
4. Perform either of the following operations to apply a route-policy in the OSPF area
view:
– Run the filter route-policy route-policy-name export command to apply a
route-policy to outgoing Type 3 LSAs (summary LSAs) in the area.
– Run the filter route-policy route-policy-name import command to apply a
route-policy to incoming Type 3 LSAs in the area.

5.5.7 (Optional) Configuring OSPF to Filter LSAs in an Area

– To apply a route-policy in the OSPF FRR view, perform the following operations:
OSPF view.
3. Run the frr command to enter the OSPF FRR view.
4. Run the loop-free-alternate command to enable OSPF IP FRR to generate a loop-
free backup link.
OSPF to add the backup routes that match a route-policy to the IP routing table.
For details on how to configure OSPF IP FRR, see 5.11 Configuring OSPF IP
FRR.
l Apply a route-policy to OSPFv3 routes.
– To apply a route-policy in the OSPFv3 view, perform the following operations:
2. Run the ospfv3 [ process-id ] command to enable an OSPFv3 process and enter
the OSPFv3 view.
3. To apply a route-policy to OSPFv3 routes in the OSPFv3 view, see Table 10-8.
Table 10-8 Applying a route-policy to OSPFv3 routes
To configure default-route-advertise 6.7.4 Configuring

OSPFv3 to [ always | cost cost | type type | OSPFv3 to Import
advertise the default tag tag | route-policy route- External Routes
routes in the routing policy-name ] *
table that are not
generated by
OSPFv3 to an
OSPFv3 routing
area based on the
parameters of a
route-policy
To configure import-route { bgp [ permit- 6.7.4 Configuring

OSPFv3 to import ibgp ] | unr | direct | ripng help- OSPFv3 to Import
the routes that process-id | static | isis help- External Routes
match a route- process-id | ospfv3 help-process-
policy id } [ { cost cost | inherit-cost } |
type type | tag tag | route-policy
To configure a preference [ ase ] { preference | -

priority for OSPFv3 route-policy route-policy-name }
routes that match a *
route-policy

– To apply a route-policy in the OSPFv3 area view, perform the following operations:
the OSPFv3 view.
3. Run the area area-id command to enter the OSPFv3 area view.
4. Perform either of the following operations to apply a route-policy in the OSPFv3
area view:
– Run the filter route-policy route-policy-name export command to apply a
route-policy to outgoing Type 3 LSAs (Inter-Area-Prefix-LSAs) in the area.
– Run the filter route-policy route-policy-name import command to apply a
route-policy to incoming Type 3 LSAs in the area.
For details on how to apply a route-policy to Type 3 LSAs, see 6.7.5 (Optional)
Configuring OSPFv3 to Filter LSAs in an Area.
– To apply a route-policy in the OSPFv3 FRR view, perform the following operations:
the OSPFv3 view.
3. Run the frr command to enter the OSPFv3 IP FRR view.
4. Run the loop-free-alternate command to enable OSPFv3 IP FRR.
OSPFv3 to add the backup routes that match a route-policy to the IP routing table.
For details on how to configure OSPFv3 IP FRR, see 6.11 Configuring OSPFv3
IP FRR.
l Apply a route-policy to BGP routes.
2. Run the bgp { as-number-plain | as-number-dot } command to enter the BGP view.
3. Run the ipv4-family unicast command to enter the IPv4 unicast address family view.
4. To apply a route-policy to specific BGP routes, see Table 10-9.
Table 10-9 Applying a route-policy to BGP routes
To configure a aggregate ipv4-address { mask | 8.8 Configuring BGP

summarized BGP mask-length } [ as-set | Route Aggregation
route and apply a attribute-policy route-policy-
route-policy to it name1 | detail-suppressed |
origin-policy route-policy-
name2 | suppress-policy route-
policy-name3 ] *
To configure BGP dampening [ half-life-reach 8.15 Configuring BGP

route dampening reuse suppress ceiling | route- Route Dampening
policy route-policy-name ] *

To configure BGP import-route protocol 8.3.4 Configuring BGP

to import the routes [ process-id ] [ med med | route- to Import Routes
from another policy route-policy-name ] *
routing protocol
that match a route-
policy
To import local network ipv4-address [ mask | 8.3.4 Configuring BGP

routes that match a mask-length ] [ route-policy to Import Routes
route-policy to the route-policy-name ]
BGP routing table
and advertise them
to BGP peers
To enable BGP nexthop recursive-lookup 8.4.6 Configuring

route iteration route-policy route-policy-name Next_Hop Attributes
based on a route- for Routes
policy
To configure a peer { group-name | ipv4- 8.16 Configuring a

device to send a address } default-route- BGP Device to Send a
default route to a advertise [ route-policy route- Default Route to Its
peer or a peer group policy-name ] [ conditional- Peer
and use a route- route-match-all { ipv4-
policy to modify address1 { mask1 | mask-
the attributes of the length1 } } &<1-4> |
default route conditional-route-match-any
{ ipv4-address2 { mask2 | mask-
length2 } } &<1-4> ]
To prevent a device peer { group-name | ipv4- -

from performing address } route-policy route-
bit-error-triggered policy-name export ignore-bit-
protection error
switching when a
route-policy is used
as an export policy
NOTE
When bit-error-
triggered protection
switching is
configured, bit
errors occur, and
Local_Pref or MED
is modified using an
export route-policy,
run the command to
apply the
Local_Pref or MED
in the export route-
policy.

To configure a peer { group-name | ipv4- 8.5.3 Configuring to

device to accept the address } route-policy route- Controll the
routes that match a policy-name { import | export } Advertisement of BGP
route-policy from a Routing Information
peer or peer group and 8.6.3 Configuring
or advertise the to Controll the
routes that match a Acceptment of BGP
route-policy to a Routing Information
peer or peer group
To use a route- preference route-policy route- 8.4.2 Configuring the

policy to set a BGP policy-name BGP Preference
priority
To prevent the BGP routing-table rib-only [ route- 8.10.5 (Optional)

routes that match a policy route-policy-name ] Preventing BGP
route-policy from Routes from Being
being added to the Added into the IP
IP routing table Routing Table
l Apply a route-policy to BGP4+ routes.

1. Run:
system-view

2. Run:

3. Run:

4. To apply a route-policy to specific BGP4+ routes, see Table 10-10.
Table 10-10 Applying a route-policy to BGP4+ routes
To configure a aggregate ipv6-address prefix- 9.4.3 Configuring

summarized BGP4 length [ as-set | attribute-policy BGP4+ Route
+ route and apply a route-policy-name1 | detail- Aggregation
route-policy to it suppressed | origin-policy
route-policy-name2 | suppress-
policy route-policy-name3 ] *

To configure BGP4 dampening [ half-life-reach 9.8.2 Enabling BGP4+

+ route dampening reuse suppress ceiling | route- Route Dampening
and apply policy route-policy-name ] *
dampening
parameters to the
routes that match a
route-policy
To configure BGP4 import-route protocol 9.4.4 Configuring

+ to import the [ process-id ] [ med med | route- BGP4+ to Import and
routes from another policy route-policy-name ] * Filter External Routes
routing protocol
that match a route-
policy
To import local network ipv6-address prefix- 9.4.2 Configuring

routes that match a length [ route-policy route- BGP4+ to Advertise
route-policy to the policy-name ] Local IPv6 Routes
BGP4+ routing
table and advertise
them to BGP4+
peers
To enable BGP4+ nexthop recursive-lookup 9.3.6 Configuring the

route iteration route-policy route-policy-name Next_Hop Attribute
based on a route-
policy
To configure a peer { group-name | ipv6- 9.4.5 Configuring

device to send a address } default-route- Routers to Advertise a
default route to a advertise [ route-policy route- Default Route to a Peer
peer or a peer group policy-name ]
and use a route-
policy to modify
the attributes of the
default route
To configure a peer { group-name | ipv6- 9.4.7 Configuring the

device to accept the address } route-policy route- Policy for Receiving
routes that match a policy-name { import | export } BGP4+ Routing
route-policy from a Information and 9.4.6
peer or peer group Configuring the Policy
or advertise the for Advertising BGP4+
routes that match a Routing Information
route-policy to a
peer or peer group
To use a route- preference route-policy route- 9.3.2 Configuring the

policy to set a policy-name BGP4+ Preference
BGP4+ priority

To prevent the routing-table rib-only [ route- 9.11.5 (Optional)

BGP4+ routes that policy route-policy-name ] Preventing BGP4+
match a route- Routes from Being
policy from being Added into the IPv6
added to the IPv6 Routing Table
routing table
l Apply a route-policy to multicast routes.

– To apply a route-policy in the system view, perform the following operations:
2. Run the ip rpf-route-static [ vpn-instance vpn-instance-name ] source-address
{ mask | mask-length } [ isis process-id | ospf process-id | rip process-id | bgp |
static ] [ route-policy route-policy-name ]{ rpf-nbr | interface-type interface-
number } [ preference preference ] [ order order-number ] command to configure
multicast static routes and use route-policy route-policy-name to configure the
matching rules of the multicast static routes
For details on how to configure multicast static routes, see Configuring a Static
Multicast Route Function.
– To apply a route-policy in the VPN instance IPv4 address family view, perform the
2. Run the ip vpn-instance vpn-instance-name command to enter the VPN instance
view.
3. Run the ipv4-family command to enable the IPv4 address family for the VPN
instance and enter the VPN instance IPv4 address family view.
4. Run the auto-discovery { mdt | mvpn } [ import route-policy route-policy-
name ] command to configure the A-D mode for multicast VPN and associate the
VPN instance IPv4 address family with an import routing policy
l Apply a route-policy to BGP/MPLS IP VPN routes.
– To apply a route-policy in the BGP view, perform the following operations:
3. Run the ingress-lsp trigger route-policy route-policy-name command to enable
the function of establishing ingress LSPs for labeled BGP routes based on a route-
policy.
On a MAN where the hybrid access mode is used, a large number of BGP labeled
routes are used to establish end-to-end LSPs. Some intermediate nodes do not need
to carry VPN services, but excessive ingress LSPs are created, wasting network
resources. In this situation, run the command to establish ingress LSPs based on a
route-policy to reduce network resource consumption.
– To apply a route-policy in the BGP-VPNv4 address family view, perform the following
operations:


3. Run the ipv4-family vpnv4 command to enter the BGP-VPNv4 address family
view.
4. Run the nexthop recursive-lookup bit-error-detection { med + med-adjust-
value | local-preference - localpref-adjust-value } * [ route-policy route-policy-
name ] command to associate bit error events with the adjustment of the local
preference or MED value for routes that match a route-policy. If route-policy
route-policy-name is not specified in the command, the local preferences or MED
values of all routes are adjusted.
For details on how to configure bit-error-triggered L3VPN route switching, see
Configuring Bit-Error-Triggered VPN Route Switching.
– To apply a route-policy in the VPN instance view, perform the following operations:
view.
3. Perform either of the following operations as required:
– To associate the VPN instance IPv4 or IPv6 address family with one export
route-policy, run the export route-policy route-policy-name command.
The export command can control route transmission between different VPN
instances on a PE, while the peer route-policy export command can control
only the VPNv4 or VPNv6 routes that a PE sends to other PE peers.
– To associate the VPN instance IPv4 or IPv6 address family with one import
route-policy, run the import route-policy route-policy-name command.
The import route-policy command can control route transmission between
different VPN instances on a PE, while the peer route-policy import command
can control only the VPNv4 or VPNv6 routes that a PE sends to other PE peers.
To configure a device to advertise ARP Vlink direct routes that match a route-
policy on a VPN, run the arp vlink-direct-route advertise [ route-policy
route-policy-name ] command. For details, see Configure a direct route
between a PE and a CE.
view.
4. Run the ip { direct-routing-table | static-routing-table } route-policy route-
policy-name command to apply a route-policy to direct or static routes in the VPN
instance IPv4 address family.
After the ip route-policy command is run, a device can modify attributes of direct
or static routes based on the route-policy.


view.
4. Run the nd vlink-direct-route advertise [ route-policy route-policy-name ]
command to configure a device to advertise NDP Vlink direct routes that match a
route-policy on a VPN. For details, see Configure a direct route between a PE and
a CE.
l Apply a route-policy to an FRR scenario.
– For route-policy applications in IP FRR on the public network. see 1.4 Configuring
Public Network IP FRR.
– For route-policy applications in IPv6 FRR on the public network. see 1.5 Configuring
Public Network IPv6 FRR.
– For route-policy applications in IP FRR on a VPN. see Configuring VPN IP FRR.
– For route-policy applications in IPv6 FRR on a VPN. see Configuring IPv6 FRR on a
Private Network.
– For route-policy applications in VPN FRR. see Configuring VPN FRR.
– For route-policy applications in IPv6 VPN FRR. see Configuring IPv6 VPN FRR.
– For route-policy applications in hybrid FRR, see Configuring Hybrid FRR.
– For route-policy applications in hybrid FRR in a static MPLS IP VPN, see Configuring
Hybrid FRR.
----End

After the Route-Policy is configured, you can check information about the Route-Policy.
Prerequisites
The Route-Policy has been configured.
Procedure
l Run the display route-policy [ route-policy-name ] command to check the Route-Policy.
----End
10.4 Applying Filters to Received Routes

By applying the related filters of routing policies to routing protocols, you can filter the received
routes.

Before applying filters to the received routes, familiarize yourself with the usage scenario,

After defining the filters including the IP prefix list, ACL, and Route-Policy related to the routing
policy, you need to import the filters to the protocols. The routing filters are used in the following
situations:
l Filtering the received routes

Use the filter-policy command in the protocol view and apply an ACL or an IP prefix list
to filter the received routes. Only the routes that meet the matching rules are received.
The filter-policy import command is used to filter the received routes.
For the distance vector (DV) protocol and the link state protocol, the procedures are
different after the filter-policy command is run.
– DV protocol
A DV protocol generates routes based on the routing table. The filters affect the routes
received from the neighbor and the routes to be sent to the neighbor.
– Link state protocol
A link state protocol generates routes based on the Link State Database. The filter-
policy command does not affect the Link State Advertisements (LSAs) or the integrity
of the LSDB. Therefore, the effect on the commands of filter-policy import and filter-
policy export are different.
The filter-policy import command identifies the route that is added to a local routing
table from a protocol routing table only. That is, this command affects the local routing
table only, but does not affect the protocol routing table.
NOTE
l BGP has powerful filtering functions. For details of BGP configuration, refer to BGP
Configuration.
l You can run the filter-policy command and the import-route command with different parameters for
RIP, OSPF, IS-IS, and BGP. For details, refer to related configurations.
Before applying filters to received routes, complete the following tasks:
l Configuring the IP-Prefix List

l Configuring an ACL
l Configuring the Route-Policy
Data Preparation
To apply filters to received routes, you need the following data.
No. Data
1 Name of the IP prefix list
2 Name of the ACL
3 Name of the Route-Policy and node number

10.4.2 Filtering Routes Received by RIP

By applying filters, you can control the receiving of RIP routes.
Context
Perform the following steps on the router that runs RIP:
Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ] [ vpn-instance vpn-instance-name ]

1. Run filter-policy { acl-number | acl-name acl-name } import [ interface-type interface-
number ], the filtering policy is configured for routes received by RIP.
as the rules.
by the system.

1. Run filter-policy acl-name acl-name import [ interface-type interface-number ], the
filtering policy is configured for routes received by RIP.
by the system.
l Based on the IP prefix: filter-policy gateway ip-prefix-name import
l Based on the IP prefix: filter-policy ip-prefix ip-prefix-name [ gateway ip-prefix-name ]
import [ interface-type interface-number ]
The filter-policy is configured in the RIP process. If routes are filtered based on an interface,
you can configure only one route-policy based on the interface at a time. If no interface is
specified, the system considers the configured route-policy as the global route-policy, and you
can configure only one route-policy at a time. If the route-policy is configured repeatedly, the
new route-policy will replace the old route-policy.
----End

10.4.3 Filtering Routes Received by OSPF

By applying filters, you can control the receiving of OSPF routes.
Context
Perform the following steps on the router that runs OSPF:
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
An OSPF process is enabled and the OSPF view is displayed.

1. Run filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name }
import, the filtering policy is configured for routes received by OSPF.
as the rules.
by the system.

1. Run filter-policy acl-name acl-name import, the filtering policy is configured for
routes received by OSPF.
by the system.
l Based on the IP prefix: filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-
name } import
----End
10.4.4 Filtering Routes Received by IS-IS

By applying filters, you can control the receiving of IS-IS routes.

Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
isis [ process-id ] [ vpn-instance vpn-instance-name ]
An IS-IS process is enabled and the IS-IS view is displayed.

1. Run filter-policy { acl-number | acl-name acl-name } import, you can configure IS-
IS to filter the received routes to be added to the IP routing table.
as the rules.
by the system.

1. Run filter-policy acl-name acl-name import, you can configure IS-IS to filter the
received routes to be added to the IP routing table.
by the system.
l Based on the IP prefix: filter-policy ip-prefix ip-prefix-name import
l Based on the Route-Policy: filter-policy route-policy route-policy-name import
----End
10.4.5 Filtering Routes Received by BGP

By applying filters, you can control the receiving of BGP routes.
Procedure
l Filtering the Received Routes
Perform the following steps on the router that runs BGP:

1. Run:
system-view

2. Run:

a. Run filter-policy { acl-number | acl-name acl-name } import, the filtering
policy is configured for routes received by BGP.
displayed.
ACL.
system.
routes.

a. Run filter-policy acl-name acl-name import, the filtering policy is
configured for routes received by BGP.
the basic ACL.
system.
routes.
– Based on the IP prefix: filter-policy ip-prefix ip-prefix-name import
l Filtering Routes Received from the Peers or Peer Groups
1. Run:
system-view



a. Run

b. Run
rule [ rule-id ] { deny | permit } [ fragment-type fragment-type-
name | source { source-ip-address source-wildcard | any } | time-

system.
routes.
a. Run
acl name acl-name advance [ number acl-number2 ] [ match-order
{ auto | config } ]

b. Run
rule [ rule-id ] { deny | permit } protocol [ source { source-ip-
address source-wildcard | any } | time-range time-name ] *


system.
routes.
3. Run:
quit

4. Run:

5. Run:
ipv4-family unicast

6. Run:
peer { group-name | ipv4-address } filter-policy { acl-number | acl-name
acl-name } import
The filtering policy is configured for routes received from peers or peer groups.
----End

After filters are applied to the received routes, you can check information about the routing table
of each protocol.

Prerequisites
Applying filters to received routes has been configured.
Procedure
l Run the display rip process-id route command to check information about the RIP routing
table.
l Run the display ospf [ process-id ] routing command to check information about the OSPF
routing table.
l Run the display isis [ process-id ] route command to check information about the ISIS
routing table.
l Run the display bgp routing-table command to check information about the BGP routing
table.
l Run the display ip routing-table command to check information about the public IPv4
routing table.
Run the display ip routing-table command on the neighboring router. You can find that
the routes that meet the matching rules set on the neighboring router are filtered or the
actions defined by the apply clauses are performed.
----End
10.5 Applying Filters to Advertised Routes

By applying the related filters of routing policies to routing protocols, you can filter advertised
routes.

Before applying filters to advertised routes, familiarize yourself with the usage scenario,
policy, you need to import the filters to the protocols.
l Filtering the advertised routes

Use the filter-policy command in the protocol view and import an ACL or an IP prefix list
to filter the advertised routes. Only the routes that meet the matching rules are advertised.
The filter-policy export command is used to filter the advertised routes.
For the distance vector (DV) protocol and the link state protocol, the procedures are
different after the filter-policy command is run.
– DV protocol
A DV protocol generates routes based on the routing table. The filters affect the route
received from the neighbor and the route to be sent to the neighbor.
– Link state protocol

A link state protocol generates routes based on Link-State Databases (LSDBs). The
filter-policy does not affect Link State Advertisements (LSAs) or the integrity of
LSDBs. The commands of filter-policy import and filter-policy export are different.
To advertise routes, you can run the filter-policy export command on a device to control
whether the device advertises the routes imported by a specific routing protocol (such
as RIP) from other routing protocols. If the device has not imported any route in
Import mode, it will not add LSAs or Link State Protocol Data Units (LSPs)
corresponding to the imported routes to its LSDB. The device, however, can advertise
LSAs that carry the routing information discovered by the specific routing protocol
itself to other routers.
NOTE
l BGP has powerful filtering function. For details of BGP configuration, refer to BGP Configuration.
Before applying filters to advertised routes, complete the following tasks:
l 10.2 Configuring the IP-Prefix List

l 10.3 Configuring the Route-Policy
Data Preparation
To apply filters to advertised routes, you need the following data.
No. Data
2 Name of the ACL
10.5.2 Filtering Routes Advertised by RIP

By applying filters, you can control the advertisement of RIP routes.
Context
Procedure
Step 1 Run:
system-view

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

1. Run filter-policy { acl-number | acl-name acl-name } export [ protocol [ process-id ]
| interface-type interface-number ], the filtering policy is configured for routes
advertised by RIP.
as the rules.
by the system.
1. Run filter-policy acl-name acl-name export [ protocol [ process-id ] | interface-type
interface-number ], the filtering policy is configured for routes advertised by RIP.


by the system.
l Based on the IP prefix: filter-policy acl-name acl-name export [ protocol [ process-id ] |
interface-type interface-number ]
The filter-policy is configured in the RIP process. If routes are filtered based on an interface,
you can configure only one route-policy based on the interface at a time. If no interface is
specified, the system considers the configured route-policy as the global route-policy, and you
can configure only one route-policy at a time. If the route-policy is configured repeatedly, the
new route-policy will replace the old route-policy.
----End
10.5.3 Filtering Routes Advertised by OSPF

By applying filters, you can control the advertisement of OSPF routes.
Context
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]


id ] ], the filtering policy is configured to filter the imported routes when these routes
are advertised by OSPF.
as the rules.
by the system.

1. Run filter-policy acl-name acl-name export [ protocol [ process-id ] ], the filtering

policy is configured to filter the imported routes when these routes are advertised by
OSPF.
by the system.
id ] ]
l Based on the Route-Policy: filter-policy route-policy route-policy-name export
[ protocol [ process-id ] ]
----End
10.5.4 Filtering Routes Advertised by IS-IS

By applying filters, you can control the advertisement of IS-IS routes.
Context

Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]

id ] ], the filtering policy is configured for routes advertised by IS-IS.
as the rules.
by the system.


1. Run filter-policy acl-name acl-name export [ protocol [ process-id ] ], the filtering
policy is configured for routes advertised by IS-IS.
by the system.
id ] ]
l Based on the Route-Policy: filter-policy route-policy route-policy-name export
[ protocol [ process-id ] ]
----End
10.5.5 Filtering Routes Advertised by BGP

By applying filters, you can control the advertisement of BGP routes.
Procedure
l Filtering the Advertised Routes
1. Run:

system-view

2. Run:

3. Run:
ipv4-family unicast

a. Run filter-policy { acl-number | acl-name acl-name } export [ protocol
[ process-id ] ], the filtering policy is configured for routes advertised by BGP.
b. Run quit, return to BGP view.
displayed.
ACL.
system.
routes.


a. Run filter-policy acl-name acl-name export [ protocol [ process-id ] ], the
filtering policy is configured for routes advertised by BGP.
b. Run quit, return to BGP view.
displayed.
ACL.
system.
routes.
– Based on the IP prefix: filter-policy ip-prefix ip-prefix-name export [ protocol
[ process-id ] ]
For the routes imported by BGP, only the routes that meet matching rules can be added
to the BGP local routing table and advertised to the BGP peers.

– If protocol in the filter-policy command is specified, only the routes of the

specified protocol are filtered.
– If protocol in the filter-policy command is not specified, all the routes advertised
by BGP are filtered, including the imported routes and the local routes advertised
through the network command.
NOTE
The filter-policy export commands of different protocols have different affect ranges on routes
advertisement:
l For the link state protocol, only the routes imported are filtered.
l For the DV protocol, the routes imported and the routes discovered by the protocols are
filtered.
l Filtering Routes Advertised to the Peers
1. Run:
system-view

a. Run

b. Run
rule [ rule-id ] { deny | permit } [ fragment-type fragment-type-
name | source { source-ip-address source-wildcard | any } | time-

system.


routes.
a. Run
acl name acl-name advance [ number acl-number2 ] [ match-order
{ auto | config } ]

b. Run
rule [ rule-id ] { deny | permit } protocol [ source { source-ip-
address source-wildcard | any } | time-range time-name ] *

system.
routes.
3. Run:
quit


4. Run:

5. Run:
ipv4-family unicast

6. Run:
peer { group-name | ipv4-address } filter-policy { acl-number | acl-name
acl-name } export
The filtering policy is configured for routes advertised to the peers or peer groups.
----End

After filters are applied to advertised routes, you can check information about the routing table
of each protocol.
Prerequisites
Applying filters to advertised routes has been configured.
Procedure
table.
routing table.
routing table.
table.
routing table.
the routes that meet the matching rules set on the neighboring router are filtered or the
actions defined by the apply clauses are performed.
----End
10.6 Applying Filters to Imported Routes

By applying the related filters of routing policies to routing protocols, you can filter imported
routes.


Before applying filters to imported routes, familiarize yourself with the usage scenario, complete
policy, you need to import the filters to the protocols.
l Applying the policy to import external routes

– Use the import-route command in the protocol view. Import the required external
routes to the protocols and apply a Route-Policy to the imported routes.
– After the external routes are imported, run the filter-policy export to filter the routes.
Only the routes that meet the matching rules are advertised.
NOTE
l BGP has powerful filtering functions. For details of BGP configuration, refer to BGP
Configuration.
Before applying filters to imported routes, complete the following tasks:
l Configuring the IP-Prefix List

l Configuring the Route-Policy
Data Preparation
To apply filters to imported routes, you need the following data.
No. Data
2 Name of the ACL
10.6.2 Applying Route-Policy to Routes Imported by RIP

By applying filters, you can control the import of RIP routes.
Context

Procedure
Step 1 Run:
system-view
Step 2 Run:
rip [ process-id ]
A RIP routing process is enabled and the RIP view is displayed.
Step 3 Run:
import-route bgp [ 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 ] *
The external routes are imported.
----End
10.6.3 Applying Route-Policy to Routes Imported by OSPF

By applying filters, you can control the import of OSPF routes.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
import-route { limit limit-number | { bgp [ permit-ibgp ] | direct | unr | rip
[ process-id-rip ] | static | isis [ process-id-isis ] | ospf [ process-id-ospf ] }
[ cost cost | type type | tag tag | route-policy route-policy-name ] * }
----End
10.6.4 Applying Route-Policy to Routes Imported by IS-IS

By applying filters, you can control the import of IS-IS routes.
Context

Procedure
Step 1 Run:
system-view
Step 2 Run:
isis [ process-id ]
Step 3 Configuring IS-IS to Import External Routes

l If you want to set the cost for the imported route, you can run the import-route protocol
[ process-id ] [ cost-type { external | internal } | cost cost | tag tag | route-policy route-
policy-name | [ level-1 | level-2 | level-1-2 ] ] * command to import the external routes.
l If you want to keep the original cost for the imported route, you can run the import-route
{ { rip | isis | ospf } [ process-id ] | bgp } inherit-cost [ tag tag | route-policy route-policy-
name | [ level-1 | level-2 | level-1-2 ] ] * command to import the external routes.
----End
10.6.5 Applying Route-Policy to Routes Imported by BGP

By applying filters, you can control the import of BGP routes.
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
ipv4-family unicast
Step 4 Run:
import-route protocol [ process-id ] [ med med | route-policy route-policy-name ] *
----End


After filters are applied to imported routes, you can check information about the routing table
of each protocol.
Prerequisites
Applying filters to imported routes has been configured.
Procedure
table.
routing table.
routing table.
table.
routing table.
the routes that meet the matching rules on the neighboring router are filtered or the actions
defined by the apply clauses are performed.
----End
10.7 Controlling the Valid Time of the Routing policy

To ensure network stability, you need to configure the delay for applying a routing policy when
modifying the routing policy.

Before configuring the delay for applying a routing policy, familiarize yourself with the usage
In actual applications, when the configurations of multiple cooperative routing polices change,
the Routing Management Module (RM) immediately notifies related protocols to apply a new
routing policy, after the configuration of the routing policy is complete. An incomplete routing
policy causes route flapping, instability of the network, and a waste of time during packet
processing.
The NE80E/40E provides the following rules for processing changes of a routing policy:
l By default, the RM immediately notifies the protocol of applying the new policy when the
routing policy changes.

l If the valid time of the routing policy is configured, when the commands used to configure
the routing policy change, the RM does not notify various protocols of immediately
processing the changes. Instead, the RM waits for a certain period, and then notifies various
protocols of applying the changed routing policy.
l If the routing policy changes again during the waiting time, the RM resets the timer.
You can run related commands to set the waiting time as required.
None.
Data Preparation
To configure the valid time of the routing policy, you need the following data.
No. Data
1 Delay for applying the routing policy
10.7.2 Configuring the Delay for Applying the Routing Policy

When modifying multiple cooperative routing policies, you need to configure the delay for
applying a routing policy.
Context
Perform the following steps on the router on which the delay for applying routing policy needs
to be changed:
Procedure
Step 1 Run:
system-view
Step 2 Run:
route-policy-change notify-delay delay-time
The delay for applying the routing policy is set.
The delay ranges from 1 to 180, in seconds.
By default, the RM immediately notifies the protocol of applying the new policy when the routing
policy changes.
----End

After the delay for applying a routing policy is configured, you can check the configuration.

Prerequisites
Controlling the valid time of the routing policy has been configured.
Procedure
l Run the display current-configuration | include notify-delay command to check the
delay for applying the routing policy.
----End
Example
Run the display current-configuration command. You can find the delay for applying the
routing policy. For example:
<HUAWEI> display current-configuration | include notify-delay
route-policy-change notify-delay 10
10.8 Maintaining the Routing Policy

Maintaining routing policies involves clearing the statistics of the IP prefix list and clearing the
number of routes which match or do not match the Route-Policy.
Context
NOTICE
The statistics of IP prefix lists and the number of routes which match or do not match the Route-
Policy cannot be restored after being cleared. Exercise caution when running this command.
By default, the statistics of IP prefix lists and the number of routes which match or do not match
the Route-Rolicy are not cleared.
Procedure
l Run reset ip ip-prefix [ ip-prefix-name ] command in the user view to clear the IPv4 prefix
list statistics.
l Run reset ip ipv6-prefix [ ipv6-prefix-name ] command in the user view to clear the IPv6
prefix list statistics.
l Run reset route-policy route-policy-name counters command in the user view to clear the
number of routes which match or do not match the Route-Rolicy.
----End

The configuration examples in this section explain the networking requirements, networking
diagram, configuration notes, configuration roadmap, and configuration procedure for different
types of routing policies.

NOTE
10.9.1 Example for Filtering Received and Advertised Routes

Filters can be applied to the received and advertised routes according to networking
requirements.
As shown in Figure 10-1, in the network that runs OSPF, Router A receives routes from the
network, and provides some of these routes for Router B. Router A is required to provide only
172.1.17.0/24, 172.1.18.0/24 and 172.1.19.0/24 for Router B. Router C is required to receive
only172.1.18.0/24.Router D receives all the routes provided by Router B.
Figure 10-1 Networking diagram for filtering received and advertised routes
RouterC
POS3/0/0
172.1.16.0/24
POS1/0/0 192.168.2.1/24 172.1.17.0/24
192.168.2.2/24 POS1/0/0
192.168.1.2/24 172.1.18.0/24
POS1/0/0 172.1.19.0/24
POS1/0/0
192.168.3.2/24 RouterB 172.1.20.0/24
192.168.1.1/24
POS2/0/0 RouterA
192.168.3.1/24
RouterD OSPF
1. Configure basic OSPF functions on Router A, Router B, Router C, and Router D.

2. Configure static routes on Router A, and import these routes to OSPF.
3. Configure the policy for advertising routes on Router A, and check the filtering result on
Router B.
4. Configure the policy for receiving routes on Router C, and check the filtering result on
Router C.
Data Preparation
l Five static routes imported by Router A.

l Router A, Router B, Router C, and Router D that reside in Area 0, that is the backbone area.

l Name of the IP prefix list and route to be filtered.
Procedure
[RouterA] ospf
[RouterB] ospf
[RouterC] ospf
[RouterD] ospf
Step 3 Configure five static routes on Router A and import these routes to OSPF.
[RouterA] ip route-static 172.1.16.0 24 NULL 0
[RouterA] ospf
[RouterA-ospf-1] import-route static
# Check the IP routing table on Router B. You can view that the five static routes are imported
to OSPF.
------------------------------------------------------------------------------

172.1.16.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0

172.1.17.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0
172.1.18.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0
172.1.19.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0
172.1.20.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0
192.168.1.0/24 Direct 0 0 D 192.168.1.2 Pos1/0/0
192.168.1.1/32 Direct 0 0 D 192.168.1.1 Pos1/0/0
192.168.1.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
192.168.2.0/24 Direct 0 0 D 192.168.2.1 Pos3/0/0
192.168.2.1/32 Direct 0 0 D 127.0.0.1 Pos3/0/0
192.168.2.2/32 Direct 0 0 D 192.168.2.2 Pos3/0/0
192.168.3.0/24 Direct 0 0 D 192.168.3.1 Pos2/0/0
192.168.3.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
192.168.3.2/32 Direct 0 0 D 192.168.3.2 Pos2/0/0
Step 4 Configure the policy for advertising routes.

# Configure the IP prefix list named a2b on Router A.
[RouterA] ip ip-prefix a2b index 10 permit 172.1.17.0 24
# Configure the policy for advertising routes on Router A and use the IP prefix list named a2b
to filter routes.
[RouterA] ospf
[RouterA-ospf-1] filter-policy ip-prefix a2b export static
# Check the IP routing table on Router B, and you can view the three routes received by Router
B from a2b.
------------------------------------------------------------------------------
172.1.17.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0
172.1.18.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0
172.1.19.0/24 O_ASE 150 1 D 192.168.1.1 Pos1/0/0
192.168.1.0/24 Direct 0 0 D 192.168.1.2 Pos1/0/0
192.168.1.1/32 Direct 0 0 D 192.168.1.1 Pos1/0/0
192.168.1.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
192.168.2.0/24 Direct 0 0 D 192.168.2.1 Pos3/0/0
192.168.2.1/32 Direct 0 0 D 127.0.0.1 Pos3/0/0
192.168.2.2/32 Direct 0 0 D 192.168.2.2 Pos3/0/0
192.168.3.0/24 Direct 0 0 D 192.168.3.1 Pos2/0/0
192.168.3.1/32 Direct 0 0 D 127.0.0.1 Pos2/0/0
192.168.3.2/32 Direct 0 0 D 192.168.3.2 Pos2/0/0
Step 5 Configure the policy for receiving routes.

# Configure the IP prefix list named in on Router C.
[RouterC] ip ip-prefix in index 10 permit 172.1.18.0 24
# Configure the policy for receiving routes on Router C, and use IP prefix list named in to filter
routes.
[RouterC] ospf
[RouterC-ospf-1] filter-policy ip-prefix in import
# Check the IP routing table on Router C, and you can find that Router C in the local core routing
table receives only one route from the IP prefix list named in.


------------------------------------------------------------------------------
172.1.18.0/24 O_ASE 150 1 D 192.168.2.1 Pos1/0/0
192.168.2.0/24 Direct 0 0 D 192.168.2.2 Pos1/0/0
192.168.2.1/32 Direct 0 0 D 192.168.2.1 Pos1/0/0
192.168.2.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
# Check the IP routing table on Router D, and you can find that Router D in the local core routing
table receives all the routes advertised by Router B.
[RouterD] display ip routing-table
------------------------------------------------------------------------------

172.1.17.0/24 O_ASE 150 1 D 192.168.3.1 Pos1/0/0
172.1.18.0/24 O_ASE 150 1 D 192.168.3.1 Pos1/0/0
172.1.19.0/24 O_ASE 150 1 D 192.168.3.1 Pos1/0/0
192.168.1.0/24 OSPF 10 1 D 192.168.3.1 Pos1/0/0
192.168.2.0/24 OSPF 10 1 D 192.168.3.1 Pos1/0/0
192.168.3.0/24 Direct 0 0 D 192.168.3.2 Pos1/0/0
192.168.3.1/32 Direct 0 0 D 192.168.3.1 Pos1/0/0
192.168.3.2/32 Direct 0 0 D 127.0.0.1 Pos1/0/0
# Check the OSPF routing table of Router C. You can find that three routes defined by the IP
prefix list named a2b are in the OSPF routing table. In the link state protocol, you can run the
filter-policy import command to filter the routes that join the local core routing table from the
protocol routing table.

Routing Tables
Routing for Network

192.168.2.0/24 1 Stub 192.168.2.2 192.168.2.2 0.0.0.0
192.168.1.0/24 2 Stub 192.168.2.1 192.168.2.1 0.0.0.0
192.168.3.0/24 2 Stub 192.168.2.1 192.168.2.1 0.0.0.0
Routing for ASEs

172.1.17.0/24 1 Type2 1 192.168.2.1 192.168.1.1
172.1.18.0/24 1 Type2 1 192.168.2.1 192.168.1.1
172.1.19.0/24 1 Type2 1 192.168.2.1 192.168.1.1
Total Nets: 6
----End
Configuration Files

#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
#
ospf 1
filter-policy ip-prefix a2b export static
import-route static
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
ip ip-prefix a2b index 10 permit 172.1.17.0 24
#
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 192.168.3.1 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return

#
sysname RouterC
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.2.2 255.255.255.0
#
ospf 1
filter-policy ip-prefix in import
area 0.0.0.0
network 192.168.2.0 0.0.0.255
#
ip ip-prefix in index 10 permit 172.1.18.0 24
#
return

#
sysname RouterD
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.3.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.3.0 0.0.0.255
#
return
10.9.2 Example for Applying the Routing Policy When Importing

Routes
By applying routing policies, you can control the import of routes and set attributes for imported
routes.
As shown in Figure 10-2, Router B exchanges routing information with Router A through OSPF
and with Router C through IS-IS.
Router B is required to import IS-IS routes into OSPF and to use the routing policy to set the
route attributes. The cost of the route 172.17.1.0/24 is set to 100, and the tag of the route
172.17.2.0/24 is set to 20.
Figure 10-2 Networking diagram of applying a routing policy for imported routes
RouterB IS-IS
POS1/0/0 POS2/0/0 GE1/0/0
OSPF
192.168.1.2/24 192.168.2.2/24 172.17.1.1/24
GE2/0/0
RouterA 172.17.2.1/24
POS1/0/0 POS4/0/0
GE3/0/0
192.168.1.1/24 192.168.2.1/24
RouterC 172.17.3.1/24
1. Configure basic IS-IS functions on Router B and Router C.

2. Configure OSPF on Router A and Router B and then import IS-IS routes.
3. Configure the routing policy on Router B and apply the routing policy when OSPF imports
IS-IS routes, and verify the routes.
Data Preparation

l The IS-IS level of Router C is Level-2. The system ID is ID 0000.0000.0001. The IS-IS
level of Router B is Level-2. The system ID is ID 0000.0000.0002. The area number of
Router B and Router C is 10.
l Router A and Router B are located in Area 0, that is, the backbone area.
l Configure the name of the filtering list and IP prefix list. The cost of the route 172.17.1.0/24
is 100. The tag of the route 172.17.2.0/24 is 20.
Procedure
[RouterC] isis
[RouterC-Pos4/0/0] isis enable
[RouterC-GigabitEthernet1/0/0] isis enable
[RouterB] isis
[RouterB-Pos2/0/0] isis enable
Step 3 Configure OSPF and import routes.

# Configure Router A and enable OSPF.
[RouterA] ospf
# Configure Router B. Enable OSPF and import IS-IS routes.

[RouterB] ospf
[RouterB-ospf-1] import-route isis 1
# Check the OSPF routing table of Router A. You can view the imported routes.


Routing Tables
Routing for Network
192.168.1.0/24 1 Stub 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs
172.17.1.0/24 1 Type2 1 192.168.1.2 192.168.1.2
172.17.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.1.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
Total Nets: 5
[RouterA]
Step 4 Configure the filtering list.
# Configure ACL 2002 to match 172.17.2.0/24.

[RouterB] acl number 2002
[RouterB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
[RouterB-acl-basic-2002] quit
# Configure the IP prefix list named prefix-a to match 172.17.1.0/24.

[RouterB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
Step 5 Configure the Route-Policy.

[RouterB] route-policy isis2ospf permit node 10
[RouterB-route-policy] if-match ip-prefix prefix-a
[RouterB-route-policy] if-match acl 2002
[RouterB-route-policy] apply tag 20
Step 6 Apply the Route-Policy when the route is imported.
# Configure Router B and apply the Route-Policy as the route is imported.

[RouterB] ospf
[RouterB-ospf-1] import-route isis 1 route-policy isis2ospf
# Check the OSPF routing table of Router A. You can view the cost of the route with the
destination address as 172.17.1.0/24 is 100. The tag of the route with the destination address as
172.17.2.0/24 is 20. Other routing attributes do not change.
Routing Tables
Routing for Network
192.168.1.0/24 1 Stub 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs
172.17.1.0/24 100 Type2 1 192.168.1.2 192.168.1.2
172.17.2.0/24 1 Type2 20 192.168.1.2 192.168.1.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.1.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
Total Nets: 5

[RouterA]
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname RouterB
#
acl number 2002
rule 5 permit source 172.17.2.0 0.0.0.255
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.1.2 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
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 RouterC
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
#

ip address 172.17.1.1 255.255.255.0

isis enable 1
#
ip address 172.17.2.1 255.255.255.0
isis enable 1
#
ip address 172.17.3.1 255.255.255.0
isis enable 1
#
interface Pos4/0/0
link-protocol ppp
ip address 192.168.2.1 255.255.255.0
isis enable 1
#
return

Configuration Guide - IP Routing 11 Route Monitoring Group Configuration
11 Route Monitoring Group Configuration
About This Chapter
11.1 Overview
This section describes the route monitoring group and its features supported by the NE80E/
40E.
11.2 Configuring a Route Monitoring Group

In a dual-device hot backup scenario, you can add network-side routes to a route monitoring
group and associate access-side service modules with it so that the service modules can perform
primary/backup link switchovers upon route changes in the group. This mechanism can prevent
traffic congestion or loss.

11.1 Overview
This section describes the route monitoring group and its features supported by the NE80E/
40E.
11.1.1 Introduction
All monitored network-side routes of the same type can be added to a group called a route
monitoring group. Each route monitoring group is identified by a unique name.
A route monitoring group monitors the status of its member routes, each of which has a down-
weight. The down-weight sum of the route monitoring group changes with the number of routes
that are Down and indicates the link quality. If a route in the route monitoring group goes Down,
its down-weight is added to the down-weight sum of the route monitoring group. If a route in
the route monitoring group goes Up again, its down-weight is subtracted from the down-weight
sum of the route monitoring group.
Service modules can be associated with the route monitoring group, and a switchover threshold
can be configured for each service module to perform a primary/backup access-side link
switchover. If the down-weight sum of the route monitoring group reaches the switchover
threshold of a service module, the routing management (RM) module instructs the service
module to switch services from the primary link to the backup link. If the down-weight sum of
the route monitoring group falls below the threshold, the RM module instructs the service module
to switch services back.
If a service module is associated with a route monitoring group in a dual-device hot backup
scenario, services can be switched to the backup link if the primary link fails, therefore preventing
traffic overload or forwarding failures.
11.1.2 Route Monitoring Group Features Supported by the NE80E/

40E
A down-weight can be set for each route in the route monitoring group based on link attributes,
such as the bandwidth, and a switchover threshold can be set for each service module that is
associated with the route monitoring group to perform a primary/backup access-side link
switchover.
l A route monitoring group monitors the status of its member routes. If a route in the group
goes Down, its down-weight is added to the down-weight sum of the route monitoring
group. If the down-weight sum of the route monitoring group reaches the switchover
threshold of a service module, the RM module instructs the service module to switch
services from the primary link to the backup link.
l If a route in the route monitoring group goes Up again, its down-weight is subtracted from
the down-weight sum of the route monitoring group. If the down-weight sum of the route
monitoring group falls below the threshold of a service module, the RM module instructs
the service module to switch services back.
As shown in Figure 11-1, the route monitoring group contains 10 routes, each having a down-
weight of 10. The route monitoring group is associated with service modules A, B, C, and D
whose switchover thresholds are 80, 50, 30, and 20, respectively.

l If two routes in the route monitoring group go Down, the RM module instructs service
module D to switch services from the primary link to the backup link. If one more route
goes Down, the RM module instructs service module C to perform a primary/backup link
switchover. If five routes go Down, the RM module instructs service module B to perform
a primary/backup link switchover. If the number of routes that go Down reaches eight, the
RM module instructs service module A to perform a primary/backup link switchover.
l If the number of routes that are Down in the route monitoring group falls below eight, the
RM module instructs service module A to switch services back. If the number of routes
that are Down in the route monitoring group falls below five, the RM module instructs
service module B to switch services back. If the number of routes that are Down in the
route monitoring group falls below three, the RM module instructs service module C to
switch services back. If the number of routes that are Down in the route monitoring group
falls below two, the RM module instructs service module D to switch services back.
Figure 11-1 Route monitoring group
1 2 3 4 … ... 9 10
Network side
Route monitoring group
BRAS Trigger
Status management
Service Module Service Module Service Module Service Module

A B C D
Access side
11.2 Configuring a Route Monitoring Group

In a dual-device hot backup scenario, you can add network-side routes to a route monitoring
group and associate access-side service modules with it so that the service modules can perform
primary/backup link switchovers upon route changes in the group. This mechanism can prevent
traffic congestion or loss.
Context
To improve network reliability, most carriers implement device-level redundancy by deploying
two devices. The two devices back up each other or share traffic load. If one of the devices fails,
the other device takes over services. Despite the benefit of enhanced network reliability, you
must dual-home other devices to the two devices, which may provoke link reliability and load
balancing issues.
As shown in Figure 11-2, BRAS 2 backs up BRAS 1. NPEs on the user side are dual-homed to
the two BRASs to load-balance traffic, and the two BRASs are connected to routers on the
network side.

l If the link between BRAS 1 and router A or between BARS 1 and router B fails, the link
bandwidth between BRAS 1 and the IP core network decreases. The NPEs, however, cannot
detect the link failure and keep sending packets to the IP core network through BRAS 1.
As a result, the other link between BRAS 1 and the IP core network may be overloaded.
l If the links between BRAS 1 and router A and between BARS 1 and router B both fail,
only the links between BRAS 2 and the IP core network are available. The NPEs, however,
cannot detect the link failure and keep sending packets to the IP core network through
BRAS 1. As a result, the packets are discarded.
Figure 11-2 Route monitoring group
IP Core
Router A Router B
Network side
......
BRAS 1 BRAS 2
Access side
......
NPE 1 NPE 2 NPE m
Primary path
Backup path
To address the packet drop issue, deploy a route monitoring group on each BRAS, and add
network-side routes of the BRAS to the route monitoring group. If the down-weight sum of the
route monitoring group reaches the switchover threshold of a service module that is associated
with the group, the RM module instructs the service module to perform a primary/backup access-
side link switchover. This mechanism prevents traffic overload and service interruptions.
Data Preparation
To configure a route monitoring group, you need the following data.

No. Data
1 Name of each route monitoring group
2 Destination IP address and mask of each route to be added to a route

monitoring group
3 Down-weight of each route in a route monitoring group
4 (Optional) Delay after which the RM module instructs the service

module to perform a link switchback
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip route-monitor-group group-name
A route monitoring group is created, and the route monitoring group view is displayed.
Step 3 Run:
track ip route [ vpn-instance vpn-instance-name ] dest-address { mask | mask-
length } [ down-weight down-weight-value ]
A route is added to the route monitoring group.
To add multiple routes to the route monitoring group, repeat this step. A maximum of 16 routes
can be added to a route monitoring group.

trigger-up-delay delay-value
A delay is configured after which the RM module instructs the service module to perform a link
switchback.
By default, the delay is 5s.
If a route in a route monitoring group goes Up, the RM module delivers this route to the
forwarding table and establishes a forwarding entry for it, which takes some time. Packet loss
may occur if the RM module instructs the service module to perform a link switchback
immediately when the down-weight sum of the route monitoring group falls below the
switchover threshold of the service module. To address this issue, run the trigger-up-delay
command to configure a delay after which the RM module instructs the service module to
perform a link switchback.
If the value of delay-value is set to 0, the RM module instructs the service module to perform a
link switchback immediately when the down-weight sum of the route monitoring group falls
below the threshold of the service module.
Step 5 Run:
monitor enable (route monitoring group view)

The route monitoring group is enabled.
By default, the route monitoring group is disabled.
When a large number of routes are being added to or deleted from a route monitoring group, the
down-weight sum of the route monitoring group may change frequently, which in turn leads to
service flapping of the service modules associated with the route monitoring group. To prevent
such service flapping, run the undo monitor enable command to disable the route monitoring
group so that it is dissociated from all service modules. After the routes are added or deleted,
run the monitor enable command to re-associate the route monitoring group with all service
modules.
----End
Example
After configuring the route monitoring group, check the configurations.
l Run the display ip route-monitor-group [ group-name ] command to check information
about a route monitoring group or all route monitoring groups.
l Run the display ip route-monitor-group track-route [ vpn-instance vpn-instance-
name ] dest-address { mask | mask-length } command to check information about all route
monitoring groups to which a route has been added.
Run the display ip route-monitor-group command. The command output shows information
about all route monitoring groups.
<HUAWEI> display ip route-monitor-group
Route monitor group number : 2
Route monitor group Total weight Down weight State
uplink 20 20 Enabled
downlink 20 20 Enabled
Run the display ip route-monitor-group track-route dest-address mask-length command. The

command output shows information about all route monitoring groups to which a route has been
added.
<HUAWEI> display ip route-monitor-group track-route 192.168.1.0 24
Route monitor group Total weight Down weight State
uplink 600 100 Enabled
downlink 500 20 Enabled
Follow-up Procedure
In a dual-device hot backup scenario, you can also associate specified service modules with a
route monitoring group to protect specified services.

Configuration Guide - IP Routing A Glossary
A Glossary
This appendix collates frequently used glossaries in this document.
Access Control List A list that contains a group of rules that consist of rule { deny |
permit } statements. In firewall, ACL is applied to an interface of
a router. The router then decides which packets can be received or
be rejected. In QoS, ACL is used to classify traffic.
Accounting To record the network resources used by users.
Additional System ID A system ID assigned by the network manager. Each additional

system ID can generate up to 256 additional or extended LSP
fragments.
Area A logical set of network segments and devices. Areas are connected
through routers to form AS.
Area border router A router that can belong to more than two areas of which one area
(ABR) must be a backbone area.
AS Border Router A router that exchanges routing information with other ASs.
(ASBR)
Autonomous System A network set that uses the same routing policy and is managed by
the same technology administration department. Each AS has a
unique identifier that is an integer. The identifier is assigned by
IANA. An AS can be divided into areas.
Backbone Area An area that is responsible for routing between areas and forwarding
routing information of non-backbone areas.
Backbone Router A router with a minimum of one interface connecting to the

backbone area

Border Gateway A type of external gateway protocol used to exchange inter-AS

Protocol routes with routing loop. BGP-4 becomes the ECP standard.
Classless InterDomain To use IP address and mask to indicate network address and sub-
Routing network address. Through CIDR, routers can flexibly aggregate
routes. This reduces the size of the routing table.
Extended Community A list that identifies a community, which is divided into standard
Access List community access list and extended community access list.
Exterior Gateway A routing protocol that runs between different ASs.

Protocol (EGP)
Incremental SPF To recalculate the routes that change but not to recalculates all
routes.
Interior Gateway A routing protocol that runs in an AS, including RIP, OSPF.
Protocol (IGP)
Internet engineering An organization engaged in the development and design of TCP/IP

task force protocol suite.
Intra-Domain Router A router with all interfaces that belong to an OSPF area.
Multi-Exit-Disc An attribute that is equivalent to the metrics used by IGP. It is only

(MED) exchanged between two adjacent ASs. The AS that receives this
attribute does not advertise it to any other ASs.
Multiprotocol Border A multiprotocol extension for BGP-4, which is also called BGP-4+.
Gateway Protocol MP-BGP is the extended protocol of BGP-4. MP-BGP can carry
both IPv4 unicast routing information and routing information of
other network protocols, such as multicast and IPv6.
NE80E/40E provides multiple types of MP-BGP applications,
including extension of multicast and the extension of BGP/MPLS
VPN.
Network Entity Title Network layer information of an IS itself. It excludes the transport
(NET) layer information (SEL = 0) and can be regarded as a special NSAP.

Network Service A network address defined by ISO, through which entities on the
Access Point (NSAP) network layer can access OSI network services.
Originating System A router that runs the IS-IS protocol
Partial Route A type of route calculation that is similar to that of PRC. Only the
Calculation routes that change are calculated. Instead of calculating the node
path, PRC updates the leaf routes according to the SPT calculated
by I-SPF.
Path Attribute A part of Update packet.
Poison Reverse A feature that RIP learns a route from the neighboring interface, sets
its cost to 16, and advertises it to the neighboring routers.
Pseudonode A virtual node that is used to simulate broadcast network. It is

generated by DIS.
Router ID A unique identifier of a router in an AS, which is an integer of 32

bits.
Split Horizon A feature that RIP does not send the route learned from the
neighboring interface back to its neighboring router.
Stub area A specific area in which ABRs do not transmit the routes outside the
AS.
System ID To uniquely identify a host or a router in an area.
System ID System ID of the originating system.
Transmit area An area that provides an internal route of a non-backbone area for
both ends of a virtual link.

User Network Route When a user goes online through a Layer 2 device, such as a switch,
but there is no available Layer 3 interface and the user is assigned
an IP address, no dynamic routing protocol can be used. To enable
devices to use IP routes to forward the traffic of this user, use the
Huawei User Network Route (UNR) technology to assign a route to
forward the traffic of the user.
Versatile Routing A versatile operation platform of Huawei data communication.

Platform (VRP)
Virtual Link A logical channel that connects two ABRs through a non-backbone
area.
Virtual System The system, identified by an additional system ID, is used to generate
extended LSP fragments. These fragments carry the additional
system IDs in their LSP IDs

Configuration Guide - IP Routing B Acronyms and Abbreviations
B Acronyms and Abbreviations
This appendix collates frequently used acronyms and abbreviations in this document.
ABR Area Border Router
ACL Access Control List
ARP Address Resolution Protocol
AS Autonomous System; Access Server
ASBR Autonomous System Boundary Router
ATM Asynchronous Transfer Mode
BDR Backup Designated Router
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
BRI Basic Rate Interface
CE Customer Edge
CIDR Classless Inter-Domain Routing
CLNP Connectionless Network Protocol
CPU Central Processing Unit
CSNP Complete Sequence Number PDUs

DD Database Description
DIS Designated Intermediate System
DR Designated Router
DVMRP Distance Vector Multicast Routing Protocol
EBGP External BGP
EGP Exterior Gateway Protocol
FDDI Fiber Distributed Digital Interface
FRR Fast ReRoute
GR Graceful Restart
GTSM Generalized TTL Security Mechanism
HDLC High level Data Link Control
HSB Hot Standby
IBGP Internal BGP
ICMP Internet Control Message Protocol
ID Identification
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IP Internet Protocol
ISDN Integrated Services Digital Network
IS-IS Intermediate System-Intermediate System

ISO International Organization for Standardization
ISP Internet Service Provider
L2VPN Layer 2 VPN
L3VPN Layer 3 VPN
LAN Local Area Network
LAPB Link Access Procedure, Balanced
LSA Link State Advertisement
LSDB Link-State Data Base
LSP Label Switch Path
LSP Link State Protocol Data Unit
LSR Label Switching Router
LSR Link State Request Packet
LSU Link State Update Packet
MAC Medium Access Control
MD5 Message Digest 5
MED Multi-Exit discrimination
MIB Management Information Base
MP Multilink PPP
MP-BGP Multiprotocol Border Gateway Protocol
MPLS Multi-Protocol Label Switching
MTU Maximum Transmission Unit
NBMA Non Broadcast Multiple Access
NET Network Entity Title
NLRI Network Layer Reachable Information
NSSA Not-So-Stubby Area

OSI Open System Interconnection
OSPF Open Shortest Path First
P2P Point to Point
PC Personal Computer
PDU Protocol Data Unit
PE Provider Edge
PIM Protocol Independent Multicast
PIM-DM Protocol Independent Multicast-Dense Mode
PIM-SM Protocol Independent Multicast-Sparse Mode
POS Packet Over SDH/SONET
PPP Point-to-Point Protocol
PRI Primary Rate Interface
PSNP Partial Sequence Number PDUs
RD Route Distinguisher
RIP Routing Information Protocol
RM Routing Management
RPF Reverse Path Forwarding
RPM Routing Policy Management
SNMP Simple Network Management Protocol
SPF Shortest Path First
TCP Transmission Control Protocol

TE Traffic Engineering
UDP User Datagram Protocol
UP User Plane
VPN Virtual Private Network
VRP Versatile Routing Platform
VT Virtual-Template
WAN Wide Area Network


Configuration Guide - IP Routing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuration Guide - IP Routing

Uploaded by

Copyright:

Available Formats

HUAWEI NetEngine80E/40E Router

Configuration Guide - IP Routing

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2014-09-30) Huawei Proprietary and Confidential i

About This Document

Product Name Version

HUAWEI NetEngine80E/40E V600R008C10

Issue 02 (2014-09-30) Huawei Proprietary and Confidential ii

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Calls attention to important information, best practices and

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

Issue 02 (2014-09-30) Huawei Proprietary and Confidential iii

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

# A line starting with the # sign is comments.

Changes in Issue 02 (2014-09-30)

Changes in Issue 01 (2014-06-30)

Issue 02 (2014-09-30) Huawei Proprietary and Confidential iv

About This Document.....................................................................................................................ii

Issue 02 (2014-09-30) Huawei Proprietary and Confidential v

2 IP Static Route Configuration...................................................................................................89

Issue 02 (2014-09-30) Huawei Proprietary and Confidential vi

2.3.2 Configuring an IPv6 Static Route on the Public Network.........................................................................................98

Issue 02 (2014-09-30) Huawei Proprietary and Confidential vii

3.2.1 Before You Start......................................................................................................................................................158

Issue 02 (2014-09-30) Huawei Proprietary and Confidential viii

3.9.2 Enabling RIP GR.....................................................................................................................................................197

Issue 02 (2014-09-30) Huawei Proprietary and Confidential ix

4.7.2 Disabling Receiving of RIPng Packets on an Interface...........................................................................................243

Issue 02 (2014-09-30) Huawei Proprietary and Confidential x

5.4.3 Configuring Equal-Cost Routes...............................................................................................................................287

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xi

5.13.4 Checking the Configurations.................................................................................................................................337

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xii

6.4.1 Before You Start......................................................................................................................................................414

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiii

6.10.6 Checking the Configurations.................................................................................................................................448

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xiv

7.2.3 Configuring IPv4 IS-IS Interfaces...........................................................................................................................507

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xv

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvi

7.20 Configuring Local MT..............................................................................................................................................629

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xvii

8.3.1 Before You Start......................................................................................................................................................756

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xviii

8.10.7 Checking the Configurations.................................................................................................................................818

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xix

8.27 BGP Route Selection Rules......................................................................................................................................886

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xx

9.4.2 Configuring BGP4+ to Advertise Local IPv6 Routes...........................................................................................1062

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xxi

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xxii

10 Routing Policy Configuration.............................................................................................1193

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xxiii

10.8 Maintaining the Routing Policy..............................................................................................................................1251