NE Series Router Maintenance Guide PDF

NE Series Router Maintenance
Guide
Issue 01
Date 2016-06-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2016. 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 01 (2016-06-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
NE Series Router Maintenance Guide Contents
Contents
1 Change History.............................................................................................................................. 1
2 Routine Maintenance Items........................................................................................................ 2
2.1 Backing Up the Configuration File................................................................................................................................ 3
2.2 Restoring the Configuration Files...................................................................................................................................4
2.3 Hardware Operations Involving Risks........................................................................................................................... 5
2.4 Command Executions That Involve Risks..................................................................................................................... 7
2.5 Commonly Used Commands for Maintenance.............................................................................................................. 9
3 Emergency Maintenance Guidelines.......................................................................................12

3.1 Guide to Collecting Fault Information......................................................................................................................... 13
3.1.1 Collecting Basic Fault Information........................................................................................................................... 13
3.1.2 Collecting Device Fault Information......................................................................................................................... 13
3.2 Guide to Handling Emergencies...................................................................................................................................14
3.2.1 Failed to Log in to the System Through the Serial Interface.....................................................................................14
3.2.2 Failed to Start the System.......................................................................................................................................... 18
3.2.3 Status of Hardware Components Is Abnormal.......................................................................................................... 21
3.2.4 Interface Status Is Abnormal..................................................................................................................................... 24
3.3 Guide to Restarting a Device........................................................................................................................................28
3.3.1 Preparations for the Restart....................................................................................................................................... 29
3.3.2 Guide to Restarting the NE40E&NE80E.................................................................................................................. 29
3.3.3 Verification After the Restart.....................................................................................................................................31
3.3.4 Solution to the Restart Failure................................................................................................................................... 33
3.4 Built-in System Software Is Incorrect or Does Not Exist............................................................................................ 34
3.4.1 Loading the System Software Through the CF Card................................................................................................ 34
3.5 Guide for Creating a User Account and Elevating a User Account Right................................................................... 35
3.5.1 Using MIB to Load a User Account Configuration File........................................................................................... 36
3.5.2 Using FTP/TFTP to Replace the Current Device Configuration File....................................................................... 43
3.5.3 Using the CONSOLE Interface to Load a New Device Configuration File During a Device Restart......................44
4 Configuration Note..................................................................................................................... 49
4.1 Basic Configuration...................................................................................................................................................... 50
4.1.1 SSH............................................................................................................................................................................ 50
4.1.1.1 Login Failure of an SSH Client Because the Number of Saved SSH Public Keys Reaches the Upper Limit.......50
4.1.2 VTY........................................................................................................................................................................... 51
Issue 01 (2016-06-30) Huawei Proprietary and Confidential ii

4.1.2.1 High CPU Usage Because No ACL Is Configured for VTY Channels................................................................. 51
4.2 System Management.....................................................................................................................................................52
4.2.1 NTP............................................................................................................................................................................52
4.2.1.1 Frequent Changes of Preferentially Selected Remote NTP Servers Because No Preference Is Configured......... 52
4.2.1.2 Clock Synchronization Failure Between an NTP Client and Server Because of Incorrect Authentication
Configuration......................................................................................................................................................................53
4.2.2 NQA...........................................................................................................................................................................55
4.2.2.1 Failure of Association Between NQA and Another Protocol Due to a Too Short NQA Probe Period..................55
4.3 Network Reliability...................................................................................................................................................... 56
4.3.1 BFD........................................................................................................................................................................... 56
4.3.1.1 Incorrect LSP Switchovers Caused by Different Incoming and Outgoing Paths of the BFD for LSP Session..... 56
4.3.1.2 Traffic Interruptions Caused by Asymmetric Configurations on Both Devices of a Static BFD Session............. 59
4.3.1.3 Periodic BFD Session Flapping Caused by BFD Discriminator Conflict..............................................................62
4.3.1.4 Incorrect LSP Switchovers Caused by Different Incoming and Outgoing Paths of a Static BFD for CR-LSP
Session................................................................................................................................................................................ 64
4.3.1.5 Inner-Link Protection Failure in a BFD Multi-Layer Protection Scenario Because the Inner BFD Detection
Interval is Greater than the Outer BFD Detection Interval.................................................................................................67
4.4 Lan Access and MAN Access...................................................................................................................................... 69
4.4.1 Eth-Trunk...................................................................................................................................................................69
4.4.1.1 Incorrect Eth-Trunk Status Due to LACP E-Trunk Global Configuration Inconsistency......................................69
4.5 IP Service......................................................................................................................................................................71
4.5.1 TCP............................................................................................................................................................................ 71
4.5.1.1 TCP Disconnection Because the TCP Buffer Size Is Too Small............................................................................71
4.5.1.2 TCP6 Disconnection Because the TCP6 Buffer Size Is Too Small........................................................................73
4.6 IP Routing.....................................................................................................................................................................74
4.6.1 IGP.............................................................................................................................................................................74
4.6.1.1 IGP Neighbor Flapping Due to a Too Short Neighbor Timeout Period................................................................. 74
4.6.1.2 Unexpected Traffic Diversion Because IGP Routes Take Precedence over Imported Routes...............................77
4.6.1.3 Route Learning Failure of OSPF Neighbors Because of Inconsistent Network Types at Both Ends.................... 81
4.6.1.4 Failure of the Switchover from Default Routes After the IS-IS Overload Bit Is Set............................................. 83
4.6.1.5 IPv6 Service Forwarding Failure on an Interface That Does Not Support IPv6 in an IS-IS IPv6 Standard
Topology............................................................................................................................................................................. 85
4.6.2 BGP........................................................................................................................................................................... 88
4.6.2.1 BGP Route Flapping Due to a BGP Route Priority Change.................................................................................. 88
4.7 IP Multicast...................................................................................................................................................................91
4.7.1 PIM............................................................................................................................................................................ 91
4.7.1.1 Multicast Service Interruption Because PIM Is Not Enabled on a Backup Link................................................... 91
4.8 MPLS............................................................................................................................................................................92
4.8.1 MPLS LDP................................................................................................................................................................ 92
4.8.1.1 Incorrect LDP Session Status Due to Parameter Configuration Inconsistency When Local and Remote LDP
Sessions or Multiple Links Coexist.................................................................................................................................... 92
4.8.1.2 LSP Traffic Loss Because LDP-IGP Synchronization Is Not Enabled on an LDP Interface.................................98
4.8.2 MPLS TE................................................................................................................................................................. 101
Issue 01 (2016-06-30) Huawei Proprietary and Confidential iii

4.8.2.1 Failure to Establish an Inter-IGP Area TE Tunnel because the Explicit Path that Contains IP Addresses of Inter-
area Nodes is not Configured........................................................................................................................................... 101
4.8.2.2 RSVP-TE GR Failure Because the RSVP-TE Hello Mechanism Is Not Configured.......................................... 103
4.8.2.3 Unexpected CSPF Route Calculation Result in an IGP Multi-Process or Multi-Area Scenario..........................104
5 Special Topic.............................................................................................................................. 111

5.1 High CPU Usage.........................................................................................................................................................112
5.1.1 Change History........................................................................................................................................................ 112
5.1.2 NEs & Versions........................................................................................................................................................112
5.1.3 Background..............................................................................................................................................................112
5.1.3.1 Troubleshooting Process.......................................................................................................................................112
5.1.3.2 Common Commands............................................................................................................................................ 114
5.1.4 Troubleshooting Procedure......................................................................................................................................115
5.1.4.1 Locating the Board with a High CPU Usage........................................................................................................115
5.1.4.2 Locating the Task with a High CPU Usage.......................................................................................................... 115
5.1.5 Troubleshooting Cases.............................................................................................................................................117
5.1.5.1 Loop Exists on the Network................................................................................................................................. 117
5.1.5.2 Router IDs Conflict...............................................................................................................................................119
5.1.5.3 Specific Operations Have Been Performed.......................................................................................................... 120
5.1.5.4 Physical Interface and Trunk Interface on the Same Board Join the Same VLAN..............................................120
5.2 MPLS OAM Session Goes Down and a dLOCV Defect Occurs...............................................................................122
5.3 CPU Usage for the MPLS OAM Module Is High......................................................................................................123
5.4 MPLS-TP OAM Session Goes Down and a dLOCV Defect Occurs.........................................................................124
5.5 CPU Usage for the MPLS-TP OAM Module Is High................................................................................................125
5.6 Multi-device Backup.................................................................................................................................................. 125
5.6.1 Introduction............................................................................................................................................................. 125
5.6.2 Multi-device Backup Principles.............................................................................................................................. 127
5.6.2.1 Basic Process........................................................................................................................................................ 127
5.6.2.2 Route Deployment Policies.................................................................................................................................. 129
5.6.3 Basic Specifications for Dual-device Hot Backup Deployment..............................................................................132
5.6.4 Hot Backup Deployment for IPv4 Multicast Services............................................................................................ 135
5.6.4.1 Deployment Precautions.......................................................................................................................................135
5.6.4.2 Configuration Introduction................................................................................................................................... 135
5.6.5 Hot Backup Deployment for L2TP LAC Services.................................................................................................. 138
5.6.5.1 Deployment Constraints....................................................................................................................................... 138
5.6.5.2 Configuration Introduction................................................................................................................................... 139
5.6.6 Service Maintenance................................................................................................................................................143
5.6.6.1 How Do I Obtain RBP Information?.................................................................................................................... 143
5.6.6.2 How Do I Obtain RBS Information?.................................................................................................................... 144
5.6.6.3 How Do I Obtain Forwarding Information of a Multi-device Backup User?...................................................... 146
5.6.6.3.1 Obtaining Forwarding Path Information of IPv4 Hot Backup Users................................................................ 146
5.6.6.3.2 Obtaining Forwarding Path Information of IPv6 Hot Backup Users................................................................ 147
5.6.6.4 Maintenance for IPv4 Multicast Service Hot Backup.......................................................................................... 148
Issue 01 (2016-06-30) Huawei Proprietary and Confidential iv

5.6.6.5 Maintenance for L2TP LAC Service Hot Backup................................................................................................148

5.6.6.6 Troubleshooting for L2TP LAC Hot Backup....................................................................................................... 150
5.6.7 FAQs........................................................................................................................................................................ 150
5.6.8 Acronyms and Abbreviations.................................................................................................................................. 151
5.7 L2TP........................................................................................................................................................................... 153
5.7.1 L2TP Overview....................................................................................................................................................... 153
5.7.2 Typical Scenarios and Deployment of L2TP...........................................................................................................156
5.7.2.1 Networking Requirements.................................................................................................................................... 156
5.7.2.2 Feature Deployment............................................................................................................................................. 156
5.7.2.3 Configuration Procedure.......................................................................................................................................157
5.7.2.4 Checking the Configurations................................................................................................................................ 167
5.7.3 List of L2TP RADIUS Attributes............................................................................................................................168
5.7.4 L2TP Tunnel Reliability.......................................................................................................................................... 170
5.7.6 FAQs........................................................................................................................................................................ 176
5.8 BOD............................................................................................................................................................................178
5.8.1 BOD Service Feature...............................................................................................................................................180
5.8.1.1 BOD Overview..................................................................................................................................................... 180
5.8.1.2 BOD Service Process............................................................................................................................................182
5.8.1.2.1 BOD Service Process (Diameter Gx Interface)................................................................................................. 187
5.8.1.2.2 BOD Service Process (COPS Interface)............................................................................................................189
5.8.1.2.3 BOD Service Process (RADIUS CoA Interface).............................................................................................. 191
5.8.1.3 BOD Service Accounting..................................................................................................................................... 195
5.8.2 BOD Service Deployment....................................................................................................................................... 201
5.8.2.1 Deployment Limitation.........................................................................................................................................202
5.8.2.2 Deployment Roadmap.......................................................................................................................................... 202
5.8.2.3 Data Planning....................................................................................................................................................... 203
5.8.2.4 Typical Scenarios and Feature Deployment......................................................................................................... 203
5.8.2.4.1 A RADIUS Server Delivers the HW-Policy-Name Attribute over CoA...........................................................204
5.8.2.4.2 A RADIUS Server Delivers CAR Attributes over CoA....................................................................................213
5.8.2.4.3 A RADIUS Server Delivers the HW-Domain-Name Attribute over CoA........................................................ 217
5.8.3.1 Troubleshooting for BOD Service Failures.......................................................................................................... 222
5.8.4 FAQs........................................................................................................................................................................ 225
5.9 CGN............................................................................................................................................................................226
5.9.1 About This Document............................................................................................................................................. 226
5.9.2 CGN service board.................................................................................................................................................. 227
5.9.2.1 Versatile Service Flexible Card (SP80)................................................................................................................ 227
5.9.2.2 Versatile Service Flexible Card(SP160)............................................................................................................... 229
5.9.2.3 Versatile Service Board (VSUI-160-E)................................................................................................................ 231
Issue 01 (2016-06-30) Huawei Proprietary and Confidential v

5.9.2.4 Flexible Card Value-Added Service Processing Unit (VSUF-160)......................................................................234

5.9.2.5 Flexible Card Value-Added Service Processing Unit (VSUF-80)........................................................................237
5.9.2.6 Flexible Card Value-Added Service Processing Unit (VSUF-40)........................................................................241
5.9.3 CGN Overview........................................................................................................................................................ 243
5.9.3.1 What Is CGN?...................................................................................................................................................... 243
5.9.3.2 CGN Transition Techniques................................................................................................................................. 245
5.9.3.3 CGN Principles.....................................................................................................................................................249
5.9.3.4 Key CGN Techniques........................................................................................................................................... 250
5.9.3.4.1 CGN Port Allocation Mode............................................................................................................................... 250
5.9.3.4.2 NAT ALG.......................................................................................................................................................... 251
5.9.3.4.3 CGN Security.................................................................................................................................................... 251
5.9.3.4.4 CGN Address Tracing....................................................................................................................................... 253
5.9.3.4.5 CGN Reliability................................................................................................................................................. 254
1. Intra-chassis Backup.....................................................................................................................................................254
2. Inter-chassis Redundancy............................................................................................................................................. 256
5.9.3.5 Common CGN deployment scenarios.................................................................................................................. 260
5.9.4 CGN Solution Design.............................................................................................................................................. 264
5.9.4.1 CGN Solutions Overview..................................................................................................................................... 264
5.9.4.1.1 NAT444 Solution Overview.............................................................................................................................. 265
5.9.4.1.2 Dual-stack+NAT444 Solution Overview...........................................................................................................266
5.9.4.1.3 DS-Lite Solution Overview............................................................................................................................... 268
5.9.4.1.4 Dual-Stack+L2-NAT Solution...........................................................................................................................269
5.9.4.1.5 NAT64 Solution................................................................................................................................................. 270
5.9.4.2 Key Elements for Solution Design....................................................................................................................... 271
5.9.4.2.1 CGN Traffic Diversion...................................................................................................................................... 271
5.9.4.2.2 NAT Modes Supported by CGN Boards........................................................................................................... 274
5.9.4.2.3 CGN Port Pre-allocation....................................................................................................................................275
5.9.4.2.4 Public Address Pool and Route Advertisement.................................................................................................277
5.9.4.2.5 User-based CGN Resource Management Solution............................................................................................279
5.9.4.2.6 External-to-Internal Network Access Solution..................................................................................................279
5.9.4.2.7 CGN User Source Tracing Solution.................................................................................................................. 281
5.9.4.2.8 CGN Reliability................................................................................................................................................. 282
1. Inter-board Backup....................................................................................................................................................... 282
2. Inter-chassis Redundancy............................................................................................................................................. 283
5.9.5 CGN Solution Deployment Guide...........................................................................................................................286
5.9.5.1 Distributed NAT444 Solution Deployment Guide............................................................................................... 286
5.9.5.1.1 Solution Overview............................................................................................................................................. 286
5.9.5.1.2 Deployment Preparation.................................................................................................................................... 288
1. License Preparation...................................................................................................................................................... 288
2. Version Preparation.......................................................................................................................................................290
3. Device Evaluation.........................................................................................................................................................290
4. Performance Evaluation............................................................................................................................................... 291
Issue 01 (2016-06-30) Huawei Proprietary and Confidential vi

5. User Quantity Evaluation............................................................................................................................................. 293

6. Service Evaluation........................................................................................................................................................ 293
1. NAT Services................................................................................................................................................................ 293
2. NAT Service Restrictions............................................................................................................................................. 295
7. Peripheral Systems....................................................................................................................................................... 296
1. RADIUS Server............................................................................................................................................................ 296
2. Log Server.................................................................................................................................................................... 298
3. Portal Server................................................................................................................................................................. 298
5.9.5.1.3 Deployment Planning........................................................................................................................................ 299
1. Port Pre-allocation Scheme.......................................................................................................................................... 299
2. Public Network Address Pool Scheme......................................................................................................................... 300
3. ACL Matching Scheme................................................................................................................................................ 301
4. NAT Scheme.................................................................................................................................................................302
5. Reliability Scheme........................................................................................................................................................303
6. Log Source Tracing Solution........................................................................................................................................305
7. User Management Scheme........................................................................................................................................... 306
5.9.5.1.4 Example for Configuring Distributed NAT444................................................................................................. 308
5.9.5.1.5 Live Network Deployment Examples............................................................................................................... 315
1. 1+1 CGN Board Solution Deployment Example......................................................................................................... 315
2. 2:1 CGN Board Solution Deployment Example.......................................................................................................... 317
3. 2+1 CGN Board Solution Deployment Example......................................................................................................... 320
4. NAT444+CoA Solution Deployment in Load Balancing Mode Example................................................................... 322
5. Master/Slave NAT444+DAA Solution Deployment Example..................................................................................... 326
6. Example for Deploying the Distributed NAT444 Inter-chassis Hot Backup Solution................................................. 330
5.9.5.2 Centralized NAT444 Solution Deployment Guide............................................................................................... 335
1. License Support............................................................................................................................................................ 336
1. Design Solution to Port Pre-allocation......................................................................................................................... 343
4. NAT Scheme.................................................................................................................................................................345
7. User Management Solution.......................................................................................................................................... 349
5.9.5.2.4 Example for Configuring Centralized NAT444.................................................................................................351
Issue 01 (2016-06-30) Huawei Proprietary and Confidential vii

5.9.5.2.5 Live Network Deployment Examples............................................................................................................... 357

1. Centralized NAT444 User Capacity Expansion Solution.............................................................................................357
2. Centralized VPN+NAT444 Solution Deployment....................................................................................................... 359
3. Centralized NAT444 Dual-Device Hot Backup Deployment Example....................................................................... 361
5.9.5.3 Distributed DS-Lite Solution Deployment Guide................................................................................................ 364
1. RADIUS Server............................................................................................................................................................ 372
2. Log Server.................................................................................................................................................................... 374
3. DNS Server...................................................................................................................................................................375
4. CPE............................................................................................................................................................................... 375
4. NAT Scheme.................................................................................................................................................................378
6. Usermanagement Scheme.............................................................................................................................................381
5.9.5.3.4 Example for Configuring Distributed DS-Lite in a Typical Scenario............................................................... 383
5.9.5.4 Centralized DS-Lite Solution Deployment Guide................................................................................................390
1. RADIUS Server............................................................................................................................................................ 397
2. Log Server.................................................................................................................................................................... 399
3. DNS Server...................................................................................................................................................................400
4. CPE............................................................................................................................................................................... 400
Issue 01 (2016-06-30) Huawei Proprietary and Confidential viii

4. NAT Scheme.................................................................................................................................................................403
5.9.5.4.4 Example for Configuring Centralized DS-Lite in a Typical Scenario...............................................................409
5.9.5.4.5 Live Network Deployment Example................................................................................................................. 413
1. Deployment Solution of Dual-Device Cold Backup in a Centralized DS-Lite Scenario............................................. 413
5.9.5.5 Centralized NAT64 Solution Deployment Guide................................................................................................. 416
6. Service Evaluation........................................................................................................................................................ 425
1. DNS64 Server...............................................................................................................................................................427
2. Log Server.................................................................................................................................................................... 427
4. NAT Scheme.................................................................................................................................................................429
5.9.5.5.4 Example for Configuring Centralized NAT64 in a Typical Scenario................................................................434
5.9.6 Appendix................................................................................................................................................................. 439
5.9.6.1 CGN Log Format..................................................................................................................................................439
5.9.6.1.1 User Log Format................................................................................................................................................439
1. User Syslog Formats.....................................................................................................................................................439
2. RADIUS Log Format................................................................................................................................................... 450
3. User NetStream Log Format.........................................................................................................................................451
5.9.6.1.2 Flow Log Format............................................................................................................................................... 455
1. Flow Syslogs Format.................................................................................................................................................... 455
2. Flow Elogs Format....................................................................................................................................................... 462
3. Flow NetStream Log Format........................................................................................................................................ 468
6 Trouble Case...............................................................................................................................474
6.1 Boards Cannot Be Registered.....................................................................................................................................476
6.1.1 The ALM Indicator on the LPU Is On and the Log SRM/2/TMLINEERR Is Displayed.......................................476
Issue 01 (2016-06-30) Huawei Proprietary and Confidential ix

6.1.2 1GB Memory of the NE40E&NE80E MPU Remains the Same After the Memory Is Expanded to 2GB............. 477
6.1.3 A TCAM Chip Failure Causes All MPLS Tunnels to Go Down............................................................................ 478
6.1.4 Slave MPU Cannot Be Registered Because the System Software Package and the Master MPU Do Not Match. 479
6.1.5 NE40E&NE80E Is Registered Repeatedly But No Trap Information About the Registration Failure Is Sent to the
NMS..................................................................................................................................................................................485
6.1.6 NE5000E Fails to Collect Traffic Statistics.............................................................................................................487
6.1.7 A Fan Fails to Be Registered Because Versions of MonitorBus on the Master and Slave MPUs of an NE40E are
Incompatible..................................................................................................................................................................... 489
6.2 The CPU Usage Is High............................................................................................................................................. 491
6.2.1 LDP Flapping Causes High CPU Usage on a Router..............................................................................................491
6.2.2 A Large Number of UDP Attack Packets with a TTL Value of 1 Cause High CPU Usage on the LPU................ 492
6.3 Clock Synchronization Troubleshooting.................................................................................................................... 495
6.3.1 Bit Errors Occur on NodeBs....................................................................................................................................495
6.4 Telnet Troubleshooting............................................................................................................................................... 496
6.4.1 Users Are Forced Offline 10-plus Seconds After They Log In...............................................................................496
6.5 SSH Troubleshooting..................................................................................................................................................499
6.5.1 The Administrator Cannot Log in to the router Through SSH Due to Inconsistent Key Lengths.......................... 499
6.5.2 Login to the SSH Server Fails Because a Local RSA Key Pair Is Not Configured................................................ 500
6.6 NetStream................................................................................................................................................................... 501
6.6.1 NetStream Sampling Fails....................................................................................................................................... 501
6.6.2 NetStream Original Traffic Sampling on a VLANIF Interface Fails...................................................................... 503
6.7 GTL License Troubleshooting....................................................................................................................................505
6.7.1 The Slave MPU Resets Because the GTL File Does Not Comply With the Specification.....................................505
6.7.2 The Statuses of the Master and Slave MPUs of an NE5000E Are Asynchronous Caused by the Invalid GTL of the
Slave MPU........................................................................................................................................................................506
6.8 GE Interface Troubleshooting.................................................................................................................................... 507
6.8.1 The 10GE Interfaces Connecting Two Devices Cannot Be Up...............................................................................508
6.8.2 Interconnected Interfaces Alternate Between Up/Down States...............................................................................509
6.8.3 Severe Packet Loss Occurs After the FE Optical Module Is Mistakenly Inserted into a GE Optical Interface......510
6.8.4 Interface Rate of an NE40E&NE80E-X2 Decreases from 10 Gbit/s to 10 Mbit/s When the License Expires...... 511
6.9 ARP Troubleshooting................................................................................................................................................. 512
6.9.1 PCs on the Same Network Segment Cannot Access Each Other Because ARP Proxy Is Not Enabled................. 512
6.9.2 The Webpage Cannot Be Opened After Service Cutover Due to Improper Static ARP Configurations................ 513
6.9.3 ARP Entries on the NE40E&NE80E Fail to Be Updated in Time Because the Received Gratuitous ARP Packets
Do Not Comply with the RFC Standard...........................................................................................................................516
6.10 IP Forwarding........................................................................................................................................................... 518
6.10.1 Improper Static Route Configuration Causes Service Interruption After Any of Multiple Links Fails................518
6.11 OSPF Troubleshooting..............................................................................................................................................520
6.11.1 OSPF Neighbor Relationship Cannot Become Full Due to Redirection Configured on the Interface..................520
6.11.2 Routes Are Abnormal Because the FA Fields in Type 5 LSAs Are Set Incorrectly............................................. 523
6.11.3 The router Receives Two LSAs with the Same LS ID but Fails to Calculate a Route Based on One of the LSAs
.......................................................................................................................................................................................... 525
6.11.4 The OSPF Neighbor Relationship Cannot Be Established Between Two Devices Because the Link Between the
Devices Is Faulty.............................................................................................................................................................. 527
Issue 01 (2016-06-30) Huawei Proprietary and Confidential x

6.11.5 An OSPF Routing Loop Occurs Because Router IDs of Devices Conflict........................................................... 528
6.11.6 Services on the Master Plane Are Interrupted Because a Device on the Slave Plane Performs Master/Slave
Switchover on a Bearer Network......................................................................................................................................530
6.11.7 User with the Correct User Name and Password Fails to Pass HWTACACS Authentication..............................531
6.11.8 Why Cannot the OSPF Neighbor Relationship Be Established Between Two Devices Enabled with the Opaque-
LSA Capability?............................................................................................................................................................... 533
6.11.8.1 Inappropriate OSPF Costs Cause Traffic Interruption During a Link Switchover.............................................534
6.11.8.2 Downstream Traffic Cannot be Load Balanced Due to the Inappropriate Routing Protocol Route Preference
.......................................................................................................................................................................................... 536
6.12 IS-IS Troubleshooting...............................................................................................................................................538
6.12.1 An Upper-layer Device Cannot Learn IS-IS Routes Due to Differences in the Types of Routes Imported by IS-IS
on a Huawei Device and a Non-Huawei Device.............................................................................................................. 538
6.12.2 A device Fails to Establish IS-IS Peer Relationships with an MA5200 Because an Intermediate Transmission
Device Goes Down........................................................................................................................................................... 539
6.13 BGP Troubleshooting............................................................................................................................................... 540
6.13.1 Traffic Traverses the Egress Device of an AS Because BGP Delivers Default Routes with Different MEDs..... 540
6.13.2 MAN Users Fail to Access the Internet Because of BGP Route Flapping............................................................542
6.13.3 Routing Policies Delivered by a PE Do Not Take Effect Because There Are Multiple Routing Policies with the
Same Name.......................................................................................................................................................................544
6.13.4 A PE Fails to Establish the Public Network LSP Because the Path of IGP Routes Is Incorrect...........................546
6.13.5 Next Hop of the Incoming Traffic Changes After a Master/Slave Switchover of the Attached Non-Huawei
Devices............................................................................................................................................................................. 548
6.13.6 The Outgoing Traffic Is Not Balanced Because BGP Load Balancing Is Not Enabled........................................549
6.13.7 Summary Routes Advertised by EBGP Flap Frequently Because Routing Protocols Are Configured with
Improper Preferences........................................................................................................................................................552
6.13.8 A Router Does Not Receive the Route Advertised by Its IBGP Peer Because the AS_PATH Attribute of the
Route Carries the AS Number of the Peer........................................................................................................................554
6.13.9 Why Does Configuring BGP in an Incorrect Sequence Causes a National Backbone Network Service
Interruption?..................................................................................................................................................................... 555
6.14 L3VPN Troubleshooting...........................................................................................................................................557
6.14.1 VPNs Configured with the Same VPN Target Cannot Communicate...................................................................557
6.14.2 Ping Between the PEs on a VPN Fails.................................................................................................................. 559
6.14.3 Communications Between the VPN and the Public Network Fail on a Device....................................................561
6.14.4 VPN Services Are Interrupted Because the Link Between an ABR and a BAS Fails in a Full-meshed NSSA... 567
6.14.5 A Routing Loop Occurs After a Sham Link Is Established Between PEs............................................................ 569
6.14.6 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN Option B Setup Because the Mask of the Loopback
Address on an Intermediate Router Is Incorrect............................................................................................................... 572
6.14.7 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR................................574
6.14.8 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE.......................................... 576
6.14.9 CEs Cannot Ping Through Each Other..................................................................................................................578
6.14.10 Failed to transmit Large Packets of the Private Network.................................................................................... 579
6.14.11 PE Fails to Ping Through the Remote CE Network Segment............................................................................. 580
6.14.12 L2VPN IP RAN Troubleshooting........................................................................................................................581
6.14.13 Packets Are Lost or Duplicate Packets Are Received on an Integrated IP RAN with the Networking of HVPLS
+ L3VPN/IP......................................................................................................................................................................581
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xi

6.14.14 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down.......581
6.14.15 CE Cannot Access Some Web Servers Due to the MTU Configuration............................................................. 587
6.14.16 The RR Fails to Reflect VPN Routes.................................................................................................................. 589
6.14.17 CE1 Cannot Register with CE2 Because the Maximum Number of Routes Exceed the Upper Threshold........591
6.14.18 Users Attached to a CE Cannot Access the Internet After BGP/MPLS IP VPN Services Are Deployed.......... 593
6.14.19 VPNv4 Routes on a PE Cannot Take Effect........................................................................................................594
6.14.20 MPLS VPN Convergence Is Slow.......................................................................................................................597
6.14.21 One-way Audio Occurs Between the CEs Because the vpn-target import-extcommunity Command Is Not
Configured........................................................................................................................................................................ 598
6.14.22 PEs Fail to Exchange Private Network Routes Because the Mask Set for the Loopback Interface Is Not a 32-bit
Mask................................................................................................................................................................................. 600
6.14.23 Some MPLS VPN Services on a Device Become Abnormal After the Service Cutover....................................601
6.15 VPLS Troubleshooting............................................................................................................................................. 605
6.15.1 VPLS Services Fail................................................................................................................................................605
6.15.2 VSIs Cannot Be Up in LDP Signaling Mode........................................................................................................ 607
6.15.3 Packets Cannot Be Forwarded Successfully Between Two PEs Though VSIs Are Up........................................609
6.15.4 VSIs Cannot Be Up in BGP Signaling Mode........................................................................................................610
6.15.5 PEs Cannot Interwork Though VSIs Are Up........................................................................................................ 612
6.16 QoS........................................................................................................................................................................... 615
6.16.1 Packets Are Not Discarded After Traffic Policy Is Configured............................................................................ 615
6.16.2 Packets of VPN Services Are Lost Because the IP Precedence of a Device Is Incorrectly Set............................ 616
6.16.3 Slow Web Page Loading for Some ADSL Users.................................................................................................. 619
6.16.4 Rate Limit Does Not Take Effect When Both Rate Limit and Access Control Are Configured.......................... 620
6.16.5 The DNS Server Cannot Be Accessed Due to Incorrect Configurations of Traffic Classification....................... 622
6.16.6 System Informs That the Outbound Queues' CIRs Exceed the Upper Limit When the cir-percentage Value
Configured for the EF Queue Exceeds 31........................................................................................................................ 624
6.17 BFD Troubleshooting............................................................................................................................................... 625
6.17.1 Traffic Loss Occurs in a Network Enabled with BFD-based IP FRR................................................................... 626
6.17.2 VoIP Services Are Interrupted After a Board Recovers from a Fault................................................................... 627
6.18 VRRP Troubleshooting.............................................................................................................................................629
6.18.1 Pinging a VRRP Interface Address Fails.............................................................................................................. 629
6.18.2 Data Packets Are Discarded on a Network Configured with VRRP.....................................................................631
6.18.3 The VRRP Non-preemption Mode Does Not Take Effect.................................................................................... 634
6.18.4 A Master/Slave MPU/SRU Switchover Fails Because the Master/Slave Switchover Function Is not Enabled...636
6.18.5 VRRP Heartbeat Packets Are Lost After the hub mode enable Command Is Run............................................. 637
6.19 URPF Troubleshooting............................................................................................................................................. 640
6.19.1 Ping Fails After URPF Strict Check Is Configured...............................................................................................640
6.19.2 Ping Between Two Interconnected Interfaces Sometimes Fails............................................................................641
6.20 Local Attack Defense Troubleshooting.................................................................................................................... 643
6.20.1 Files Are Uploaded Slowly Using FTP Because of the Security Protection Configured on Upstream LPUs...... 643
6.20.2 Ping Packets Are Discarded After the Device Upgrades Caused by the LPU cpu-defend car Configuration...... 644
6.21 User Fails to Get Online Troubleshooting................................................................................................................646
6.21.1 Level 3 Telnet Users Have Only Level 0 Authority Because the RADIUS Server Is Unreachable..................... 646
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xii

6.21.2 The Telnet User Is Logged Out Because the Accounting Function Is Not Enabled on the RADIUS Server....... 648
6.21.3 Logs About Login Failures Are Generated Continuously After Old Devices Are Replaced with New Ones......649
6.21.4 RADIUS Authentication Failure Causes an ME60 User to Fail to Log In to the Directly Connected
NE40E&NE80E That Functions as the FTP Server......................................................................................................... 650
6.21.5 User Login Fails When User Names Carry Domain Names During HWTACAS Authentication....................... 652
7 FAQ.............................................................................................................................................. 654
7.1 Hardware.................................................................................................................................................................... 655
7.1.1 Boards...................................................................................................................................................................... 655
7.1.1.1 How to Differentiate Between the LAN LPU and WAN LPU?........................................................................... 655
7.1.1.2 Does the CF Card on the NE40E&NE80E Support Hot Swap?...........................................................................655
7.1.1.3 Can the Optical Module on the WAN Board Receive Optical Signals With Different Wavelengths?.................655
7.1.1.4 Can a Multimode Optical Module Be Applied to a 10G POS Board?................................................................. 656
7.1.1.5 What Do the "Non-Convergence Mode" and "Convergence Mode" Mean in the Board Description?............... 656
7.1.1.6 What Services Does the E1 Interface on the NE40E&NE80E Support?............................................................. 657
7.1.1.7 The Slave MPU/SRU Is Abnormally Reset Due To an Unknown Reason.......................................................... 657
7.1.1.8 What Logical Software Should Be Upgraded When the Interface Board Is Identified as the Slot of the MPU?
.......................................................................................................................................................................................... 658
7.1.1.9 What Logical Software Should Be Upgraded When the CPU of the LPU Does not Run?..................................658
7.1.1.10 When is the LPU powered off automatically?....................................................................................................658
7.1.1.11 When is the LPU powered off permanently?......................................................................................................658
7.1.1.12 Can the service boards of the device be separately powered on?.......................................................................658
7.1.1.13 How to Solve the Problem that the DDR SDRSM of the interface board Fails the ECC Check?..................... 658
7.1.1.14 How to Delete a Telnet User That Is Displayed Through the display users Command?.................................. 659
7.1.1.15 What Is the Wire Sequence of the E1 Cable Connecting a 24-Port Board on the NE40E&NE80E?................ 659
7.1.1.16 How to query the ESN on the MPU?................................................................................................................. 660
7.2 System........................................................................................................................................................................ 660
7.2.1 Command Line Management.................................................................................................................................. 660
7.2.1.1 What Are the Functions of the display saved-configuration Command and the display saved-configuration
last Command?.................................................................................................................................................................660
7.2.1.2 Which File Does the compare configuration Command Compare the Current Configuration with?................661
7.2.1.3 Which File Does the reset saved-configuration Command Is Used to Clear?...................................................661
7.2.1.4 Which Configuration File Does the save Command Save the Configuration to?................................................661
7.2.1.5 Which Methods Can Be Adopted to Upgrade or Degrade a Command?............................................................. 662
7.2.1.6 Why Does the System Always Prompt that Configurations Are Inconsistent After the compare configuration
Command Is Run?............................................................................................................................................................ 662
7.2.1.7 How to Collect the Command Running Time?.................................................................................................... 663
7.2.1.8 a^ Can Match a^. Why Does a(^) Match Neither a^ Nor a(^)?............................................................................663
7.2.1.9 $a Matches $a. Why Does ($)a Match Neither $a Nor ($)a?............................................................................... 663
7.2.1.10 Why Does abc$) Match Neither abc$) Nor abc?................................................................................................663
7.2.1.11 Why Does the display current-configuration | include 10.x.x.x Command Output Include Information About
Other IP Addresses?......................................................................................................................................................... 663
7.2.1.12 Why Is All Configuration Information Displayed When the display current-configuration | include 123|456|
Command Is Executed?.................................................................................................................................................... 664
7.2.2 User Management....................................................................................................................................................664
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xiii

7.2.2.1 How Many Levels Can Users Logging in to the router Be Classified Into? What Are Differences Between
Them?............................................................................................................................................................................... 664
7.2.3 FTP.......................................................................................................................................................................... 664
7.2.3.1 Why Does the Compressed Log File That Is Downloaded from the Device Fail to Be Depressed?................... 664
7.2.3.2 Why Cannot a File Be Downloaded After the FTP Connection Is Established with the Device Through the
Relevant Windows Command Line?................................................................................................................................ 665
7.2.3.3 Which Well-known Port Number Is Used by FTP?............................................................................................. 665
7.2.3.4 What Are the Functions of the ftp client-source and ftp server-source Commands?........................................665
7.2.3.5 What Is the Function of the ftp timeout Command?........................................................................................... 665
7.2.3.6 Why Does the Size of a File Change After the File Is Uploaded Through FTP?.................................................665
7.2.3.7 Are application protocols such as FTP are disabled by default?.......................................................................... 665
7.2.3.8 Why Does a PC, Working as an FTP Client, Fail to Upload a File? ................................................................... 665
7.2.4 Telnet....................................................................................................................................................................... 666
7.2.4.1 Why Does the Telnet Connection Fail on the Device?.........................................................................................666
7.2.4.2 Why Does a Client Fail to Telnet the Device When the IP Address of the Client Is Not Denied in an ACL That Is
Configured in a VTY User Interface View?..................................................................................................................... 666
7.2.4.3 Why Cannot the VTY Channels 16 to 20 (user-interface vty 16 20) Be Logged in to?.....................................666
7.2.4.4 Why Does the Telnet Connection Fail After the Terminal Prompts that the Password Is Not Set?.....................666
7.2.4.5 Why Cannot the Commands Such as system-view Be Run After the Password Authentication or Non-password
Authentication Is Configured for the Telnet Connection?................................................................................................667
7.2.5 TFTP........................................................................................................................................................................ 667
7.2.5.1 How Can TFTP Be Used to Upload and Download Files?.................................................................................. 667
7.2.5.2 Why Does the TFTP File Downloading Stop After the Size of the Downloaded File Reaches a Certain Size?. 667
7.2.6 Info Center............................................................................................................................................................... 667
7.2.6.1 How to View the Configuration of the Information Center Function?.................................................................667
7.2.6.2 How to Enable and Disable the Information Center Function?............................................................................667
7.2.6.3 How to Identify the CF Card Directory for Log Files.......................................................................................... 668
7.2.6.4 How to Configure a Log Host?.............................................................................................................................668
7.2.6.5 How to Filter Out a Log Message?.......................................................................................................................669
7.2.6.6 How Many Log Messages Can a Log Buffer Store?............................................................................................ 671
7.2.6.7 How To Configure a HUAWEI NetEngine40E/80E to Log the User Login Message?....................................... 671
7.2.6.8 What Is the Default Level of Log Messages That Can Be Stored to the Log Buffer?......................................... 671
7.2.6.9 How to Clear a Log Message Through the info-center filter-id Command?......................................................672
7.2.6.10 How Can I Solve the Problem that the Log Host on a Device Fails to Receive Logs?......................................672
7.2.6.11 Will Running the Command to Disable the Information Center Be Logged?....................................................673
7.2.6.12 How Many Types of Timestamp Formats Does the Information Center Support and How Can I Configure
These Timestamp Formats?.............................................................................................................................................. 673
7.2.6.13 Why Are Some Old Log Files Uncompressed?..................................................................................................674
7.2.7 SNMP...................................................................................................................................................................... 674
7.2.7.1 What Does the Log Message Saying "Failed to login through SNMP" Mean?................................................... 674
7.2.7.2 How to Configure Agent on a Host When the SNMP Version of the Connected NMS and Host is v1, v2c, or v3?
.......................................................................................................................................................................................... 676
7.2.7.3 How to Configure an SNMPv3-Enabled Trap Host to Send SNMPv3 Alarm Messages?...................................677
7.2.7.4 Why Does the walk Operation Performed by SNMP Agent Time Out on a Certain Node?................................677
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xiv

7.2.7.5 Will an Alarm Message Be Generated in the Case of a Telnet Login Failure?.................................................... 677
7.2.7.6 Does SNMP Check Packets Based on an ACL First Or Based on Communities First?...................................... 677
7.2.7.7 Why Are Communication Failure Reasons Different Since Source IP Addresses Do Not Match the Configured
ACL?................................................................................................................................................................................ 678
7.2.7.8 How Are Alarm Types and Alarm Severity Defined? What Are the Mappings Between Alarm Severity and IC
Levels?..............................................................................................................................................................................678
7.2.8 SSH.......................................................................................................................................................................... 679
7.2.8.1 Why Cannot SSH Be Used to Log in to a Device After the CF Card of the Device Is Replaced?...................... 679
7.2.8.2 Why Does the System Prompt that the Number of Public Keys Reaches the Upper Threshold When the Device
Functions as the STelnet Client?.......................................................................................................................................679
7.2.8.3 How to Configure the router Serving as the SSH Server So That PCs or Other Network Devices Can Log In to
the SSH Server?................................................................................................................................................................679
7.2.9 System Clock........................................................................................................................................................... 679
7.2.9.1 Why is the information about the daylight saving time lost after router is upgraded to V600R002?.................. 679
7.2.10 NTP........................................................................................................................................................................680
7.2.10.1 Can the NTP Clock Adjusting Period Be Modified?......................................................................................... 680
7.2.10.2 Why Can Clock Synchronization Still Be Achieved When the Authentication Key IDs Are Configured
Differently on the Client and Server?............................................................................................................................... 680
7.2.10.3 What May Cause Clock Unsynchrnization?.......................................................................................................680
7.2.10.4 What Are the Meanings of the Following Logs? If the Following Logs Repeatedly Appear, What Is the
Implication on the Device?...............................................................................................................................................680
7.2.10.5 What Is the Relationship Between Time Zone/Daylight Saving Time and NTP?............................................. 681
7.2.10.6 Is It Normal to Find that the NTP Clock Status Is Unsynchronized?.................................................................681
7.2.10.7 Do Huawei Devices Support NTP V4?.............................................................................................................. 681
7.2.10.8 What Does the NTP Stratum Mean?.................................................................................................................. 681
7.2.10.9 Why Flapping and Unsynchronization Occur After Multiple Clock Sources Are Specified and the Clock
Synchronization State Is Entered?.................................................................................................................................... 681
7.2.10.10 How Great the Clock Deviation Is When the Client Loses Synchronization with the Server?........................682
7.2.10.11 How Long Does It Take to Change the Asynchronization State to the Synchronization State on the Client?.682
7.2.10.12 What Is the Interval at Which the Client Sends Request Packets to or Receives the Response Packets from the
Server?.............................................................................................................................................................................. 682
7.2.10.13 How to Maintain the Synchronization State?................................................................................................... 683
7.2.11 1588v2................................................................................................................................................................... 683
7.2.11.1 What Need to Be Noted on the Access on the BITS Interface?......................................................................... 683
7.2.11.2 What Need to Be Noted for the Configuration of a TCandBC Device?.............................................................683
7.2.12 NetStream.............................................................................................................................................................. 683
7.2.12.1 Why Cannot GRE Tunnel Interfaces Be Configured with the Command that Enables NetStream Sampling?.684
7.2.12.2 When the ip netstream mpls-aware ip-only Command Is Configured, the Message "Error: Please disable mpls-
label aggregation first." Is Prompted. Why?.....................................................................................................................684
7.2.12.3 Why Cannot the VE Interface Be Configured with the NetStream Sampling Command?................................ 684
7.2.12.4 What Is ACL-based Sampling?.......................................................................................................................... 684
7.2.12.5 How About the Output Format of NetStream Packets?..................................................................................... 684
7.2.12.6 How many types of licenses are there for NetStream services?.........................................................................685
7.2.12.7 How to control NetStream services through a GTL license?............................................................................. 685
7.2.12.8 How to check the status of the GTL license?..................................................................................................... 685
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xv

7.2.12.9 What should be noted when configuring the ip netstream sampler command?.............................................. 686
7.2.12.10 What is the aging time of a NetStream flow used for and what is the difference between the active aging time
and the inactive aging time?............................................................................................................................................. 686
7.2.12.11 Do both the active aging time and the inactive aging time of a NetStream flow need to be configured with
values manually? What are the configuration notes?....................................................................................................... 686
7.2.12.12 Will services be affected when the ip netstream sampler fix-packets command is run to change the interval
at which packets are sampled?..........................................................................................................................................687
7.2.12.13 What is the function of specifying a source IP address through the ip netstream export source command?
.......................................................................................................................................................................................... 687
7.2.12.14 Why the NMS Does Not Receive Template Packets?...................................................................................... 687
7.2.12.15 Can the ip netstream mpls-aware ip-only Command and MPLS Aggregation Be Enabled at the Same Time?
.......................................................................................................................................................................................... 687
7.2.13 NQA.......................................................................................................................................................................687
7.2.13.1 Why Does the NQA Test Result Display the Packet Discard Rate of 100% When the Network Can Be Pinged?
.......................................................................................................................................................................................... 687
7.2.14 Online Packet Header Obtaining........................................................................................................................... 688
7.2.14.1 Q: Can Multiple Interfaces Perform Online Packet Header Obtaining at the Same Time and How Is The Packet
Information Displayed?.................................................................................................................................................... 688
7.2.15 LLDP..................................................................................................................................................................... 688
7.2.15.1 Why Cannot Neighbors Be Discovered When the Two Devices Are Enabled with LLDP?............................. 688
7.2.16 Log and Alarm Files.............................................................................................................................................. 688
7.2.16.1 What are modes of sending trap messages to the NMS and what is the default mode?.....................................688
7.2.16.2 How to change the storage path of a log message?............................................................................................ 688
7.2.16.3 Why the system prompts a CRC error when the log file is decompressed?.......................................................689
7.2.16.4 What is the function of the logfilebuf.dat file in the CF card?........................................................................... 689
7.2.16.5 By default, the log buffer saves log messages of which levels? Will the log buffer records log messages about
the command execution?.................................................................................................................................................. 689
7.2.17 Tracert....................................................................................................................................................................689
7.2.17.1 In the case that there are multiple equal-cost links and the default per-destination load balancing mode is
adopted, why the tracert test result outputs the interface IP address of each equal-cost link?.........................................689
7.2.17.2 In per-destination load balancing mode, why all hops except the first hop of packets in the Tracert test are
identical?...........................................................................................................................................................................689
7.2.18 GTL License.......................................................................................................................................................... 690
7.2.18.1 What is the impact if the GTL license fails to be activated?.............................................................................. 690
7.2.18.2 How to check whether the GTL license is activated?.........................................................................................690
7.2.18.3 What Are the Differences Between PAF/License Files and GTL Files? What Are the Deployment Scenarios of
These Files?...................................................................................................................................................................... 690
7.3 How Can I Use the Self-Loop Function to Detect the Ping Failure on an Interface?................................................ 690
7.3.1 Ethernet Interfaces................................................................................................................................................... 691
7.3.1.1 What Are Meanings of Fields in the Output of the display interface Command Displaying Information on a
10GE Interface?................................................................................................................................................................ 691
7.3.1.2 Do Traffic Statistics About Sub-interfaces Include Layer 2 Header Length?...................................................... 694
7.3.1.3 Q: Why Does the VLL Bound to a Sub-interface Change to Down After the MTU of the Main Interface Is
Changed and the shutdown and undo shutdown Commands Are Run on the Sub-interface?...................................... 694
7.3.2 Eth-Trunk Interfaces................................................................................................................................................ 694
7.3.2.1 What Is the MAC Address of an Eth-Trunk Interface?........................................................................................ 694
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xvi

7.3.2.2 What Is the MAC Address of a VLANIF Interface?............................................................................................694

7.3.2.3 Can Interfaces on interface boards of Different Types Be Bundled into a Trunk Interface on the
NE40E&NE80E?..............................................................................................................................................................694
7.3.2.4 Can Optical Interfaces and Electrical Interfaces on the Same LPU Be Bundled into One Eth-Trunk Interface?
.......................................................................................................................................................................................... 695
7.3.2.5 After Being Bundled into a Trunk Interface, Can Two GE Interfaces Working in 100 Mbit/s Full-Duplex Mode
on the NE40E&NE80E Communicate with a Trunk Interface with 100 Mbit/s Member Interfaces on Another Device?
.......................................................................................................................................................................................... 695
7.3.2.6 Can a User Check Statistics About Physical Interfaces of a Trunk Interface by Using the Network Management
Software?.......................................................................................................................................................................... 695
7.3.2.7 Can a GE Interface Working at 100 Mbit/s Full-Duplex Mode and an FE Interface Working at 100 Mbit/s Be
Bundled into the Same Trunk Interface?.......................................................................................................................... 695
7.3.2.8 How Many Load Balancing Modes Supported by the Trunk Module? What Are Differences Between Them?
.......................................................................................................................................................................................... 695
7.3.2.9 What Is the Function of the load-balance { ip | mac | packet-all } Command in the Eth-Trunk Interface View?
.......................................................................................................................................................................................... 695
7.3.2.10 Why a Log Is Generated Five Minutes After an Eth-Trunk Interface Changes from Down to Up?..................695
7.3.2.11 Which LPUs Support Link Aggregation?...........................................................................................................696
7.3.3 ATM Interfaces........................................................................................................................................................ 697
7.3.3.1 What Are the Possible Causes When the Status of the ATM Interface Is Down?................................................697
7.3.3.2 Why Are Packets Discarded and Is the CRC Incorrect When the Ping Succeeds?..............................................697
7.3.4 VE Interfaces........................................................................................................................................................... 697
7.3.4.1 Why the Directly Connected VE Interfaces Cannot Ping Through Each Other?.................................................698
7.3.4.2 Why Do Services Become Abnormal When VE Interfaces Reside on the Private Network Side of the VPLS
Network?.......................................................................................................................................................................... 698
7.3.5 10GE LAN Interfaces.............................................................................................................................................. 698
7.3.5.1 Can Interfaces on 10GE LAN Boards Be Added to Eth-Trunk Interfaces?.........................................................698
7.3.6 10GE WAN Interfaces............................................................................................................................................. 698
7.3.6.1 Can Interfaces on a 10GE LAN Board and Interfaces on a 10GE WAN Board Be Added to the Same Eth-Trunk
Interface?.......................................................................................................................................................................... 698
7.3.7 Loopback Interfaces................................................................................................................................................ 698
7.3.7.1 Can the isis silent Command Be Configured in the Loopback Interface View?.................................................. 698
7.3.8 IFNET...................................................................................................................................................................... 698
7.3.8.1 Why Is the Last Time for Protocol Statuses to Go Up Not Displayed Since the Physical Layer and Link Layer
Statuses of the Interfaces Are Both Up?...........................................................................................................................698
7.3.8.2 Why Is the display this interface Command Output on a Tunnel Interface Different from That of Another Type
of Interface?...................................................................................................................................................................... 699
7.3.8.3 Why Is the display this interface Command Output on a TE-tunnel Interface Different from That on a Tunnel
Interface? ......................................................................................................................................................................... 700
7.3.8.4 Why Are the Real-time Input Rate and Output Rate Recorded in Interface Statistics 0 Sometimes?................. 701
7.3.9 Common.................................................................................................................................................................. 702
7.3.9.1 What Is a Jumbo Frame?...................................................................................................................................... 702
7.3.9.2 What Do Optical Power Values in Optical Module Specifications Mean?.......................................................... 702
7.4 Layer 2 Networks....................................................................................................................................................... 702
7.4.1 VLAN...................................................................................................................................................................... 702
7.4.1.1 How to Limit the Packet Rates of Different VLANs on a Physical Interface?.................................................... 702
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xvii

7.4.1.2 Can Sub-VLANs of a Super VLAN Be Separately Configured with Static ARP?..............................................703
7.4.1.3 Does the NE40E&NE80E Allows a Sub-VLAN of a Super VLAN to Be Encapsulated with Two Tags?..........703
7.4.1.4 When Do Direct Routes Have 32-bit Masks?...................................................................................................... 703
7.4.1.5 Can an Interface Be Configured with Both QinQ Termination and dot1q Termination?.....................................703
7.4.2 QinQ........................................................................................................................................................................ 703
7.4.2.1 How to Check Statistics About a Sub-interface for QinQ VLAN Tag Termination?...........................................703
7.4.2.2 Why Does Not a Configured Sub-interface for QinQ VLAN Tag Termination Send ARP Requests?................704
7.4.2.3 How Many Tags Does a Packet Carry from a QinQ Interface That Accesses the VPLS Network in an
Asymmetrical Manner to the Public Network?................................................................................................................ 704
7.4.2.4 Do the Control VID Configured on a Sub-interface for QinQ VLAN Tag Termination and the Global VLAN ID
Conflict?........................................................................................................................................................................... 704
7.4.2.5 Do Sub-interfaces for QinQ VLAN Tag Termination Support DHCP Relay?.....................................................704
7.4.2.6 How to Configure a Sub-interface for Dot1q VLAN Tag Termination with an IP Address to Access a Remote
(Indirectly-Connected) Address?......................................................................................................................................704
7.4.2.7 Which Sub-interfaces Can Be Used as Access Interfaces in QinQ?.................................................................... 705
7.4.2.8 Why Cannot Configure the qinq stacking, control-vid, qinq termination, or dot1q termination Command on a
Created Sub-interface?..................................................................................................................................................... 707
7.4.2.9 How to Describe Parameters of the control-vid Command for QinQ Configurations?....................................... 707
7.4.2.10 Why the qinq termination Command or the dot1q termination Command Cannot Be Configured on a Sub-
interface Whose Main Interface Is Configured with the mode user-termination Command?..........................................709
7.4.2.11 What Is the Difference Between QinQ and 802.1Q Packet Formats?................................................................709
7.4.2.12 Which Command Is Used to Query QinQ Statistics on Sub-interfaces for QinQ VLAN Tag Termination?.... 709
7.4.2.13 What Are Differences Between Symmetry and Asymmetry Sub-interfaces for QinQ VLAN Tag Termination?
.......................................................................................................................................................................................... 713
7.4.2.14 What Are the Three Types of QinQ Sub-interfaces and Their Configuration Commands?...............................714
7.4.3 LACP....................................................................................................................................................................... 715
7.4.3.1 What Is the Interval for Sending an LACP Packet?............................................................................................. 715
7.4.3.2 What Is the Function of the Delay for LACP Preemption?..................................................................................715
7.4.4 MSTP.......................................................................................................................................................................715
7.4.4.1 How MSTP BPDUs Are Transparently Transmitted on a VPLS Network?........................................................ 715
7.4.4.2 When Do You Need to Configure Edge Interfaces?.............................................................................................716
7.4.4.3 What Are Precautions for Configuring the Formats of Sent and Received BPDUs on STP Interfaces?............. 716
7.5 IP Services.................................................................................................................................................................. 716
7.5.1 IP..............................................................................................................................................................................716
7.5.1.1 How to Process Tracert Packets When Links Carry Out Equal-Cost Load Balancing?.......................................717
7.5.1.2 What Do the Bad Protocol and No Route Items Denote in the Statistics on IP Traffic?......................................717
7.5.2 ARP......................................................................................................................................................................... 717
7.5.2.1 Why Do ARP Entries Fail to Be Created After Strict ARP Learning Is Configured?......................................... 717
7.5.3 Socket...................................................................................................................................................................... 718
7.5.3.1 How to Understand the display tcp status Command Output?............................................................................. 718
7.5.3.2 What Does SOCK in the Task List Stand For?.....................................................................................................718
7.5.3.3 Which Ports Can Be Bound by Socket?............................................................................................................... 720
7.5.3.4 Why Does the Upper Layer Application Function Normally When the TCP Checksum in the Packet Header
obtained on the Windows Platform Is Detected Faulty?.................................................................................................. 720
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xviii

7.5.4 DHCP.......................................................................................................................................................................720
7.5.4.1 Can DHCP Services Access a Super VLAN Configured on the NE40E&NE80E?.............................................720
7.5.4.2 Do Broadcast Ethernet Interfaces on the NE40E&NE80E Support Address Unnumbered?............................... 720
7.6 IP Routing...................................................................................................................................................................720
7.6.1 Static Route..............................................................................................................................................................720
7.6.1.1 What Are the Differences Between a Static Route Configured with Only the Next Hop Address and a Static
Route Configured with Both the Next Hop Address and Outbound Interface?............................................................... 720
7.6.1.2 Why Is a Static Route Configured with an Outbound Interface Preferred?......................................................... 721
7.6.1.3 Why Does the Static Route Configured for Interworking Between the Public Network and Private Network Not
Take Effect?...................................................................................................................................................................... 721
7.6.2 OSPF........................................................................................................................................................................722
7.6.2.1 What Are OSPF Authentication Types? What Are the Authentication Principles? ............................................ 722
7.6.2.2 How Is the Cost of an OSPF Interface Calculated?..............................................................................................722
7.6.2.3 Must Two Interfaces Reside on the Same Network Segment and Have the Same Subnet Mask Digits to Establish
an OSPF Neighbor Relationship?.....................................................................................................................................722
7.6.2.4 Must All the Devices on an OSPF NBMA Network Be Fully Meshed? ............................................................ 722
7.6.2.5 Must the IP Addresses of Interfaces on the Two Ends of a P2P Link Be on the Same Network Segment?........ 723
7.6.2.6 What Are the Functions of OSPF Virtual Links?................................................................................................. 723
7.6.2.7 What Are the Common LSA Types of OSPF? Why Is Type 6 LSA Unavailable?..............................................723
7.6.2.8 What Does the ToS Field in an OSPF LSA Mean?.............................................................................................. 724
7.6.2.9 What Does the OSPF LSA Refresh Interval Mean? How Long Is the LSA Refresh Interval?........................... 724
7.6.2.10 When OSPF Imports External Routes to Generate Type 5 LSAs (ASE LSAs) or Type 7 LSAs (NSSA LSAs),
What Are the Rules of Filling in the Forwarding Address? ............................................................................................ 724
7.6.2.11 When OSPF Imports Routes as Type 5 LSAs, What Is the Function of the Input Forwarding Address?......... 724
7.6.2.12 What is the LSA Retransmit Interval? How to Set it?........................................................................................725
7.6.2.13 What Are a DR, a BDR, and a DR Other? What Are the Election Rules?.........................................................725
7.6.2.14 What Is the Function of the Interface MTU in OSPF Database Description (DD) Packets, and How to
Configure it? .................................................................................................................................................................... 726
7.6.2.15 What Is the Purpose of a Domain ID? ............................................................................................................... 726
7.6.2.16 What Is the Purpose of an OSPF Route Tag?..................................................................................................... 726
7.6.2.17 What Is the Purpose of a Tag in an ASE-LSA and NSSA-LSA?.......................................................................727
7.6.2.18 What Is the Purpose of Setting the DN Bit in an OSPF LSA? .......................................................................... 727
7.6.2.19 What Is the Function of the vpn-instance-capability simple Command? .......................................................727
7.6.2.20 What Is an OSPF Sham Link and What Is the Function of an OSPF Sham Link?............................................ 727
7.6.2.21 How Does OSPF Filter Received Routes? ........................................................................................................ 728
7.6.2.22 What Is an ABR? Is a Device Configured with More than Two Areas an ABR? ............................................. 728
7.6.2.23 When Multiple ABRs Exist in an NSSA Area, on Which Router Does OSPF Translate Type-7 LSAs into
Type-5 LSAs?................................................................................................................................................................... 728
7.6.2.24 How Is an OSPF Router ID Selected? How Is the Default Router ID Obtained?..............................................728
7.6.2.25 What Are the OSPF Network-Type Specifications?.......................................................................................... 729
7.6.2.26 In the Case of 50 Thousand OSPF Routes, How Long Does it Take to Establish an OSPF Neighbor
Relationship?.................................................................................................................................................................... 730
7.6.2.27 What Is the Maximum Number of Equal-Cost Routes Supported by OSPF?....................................................730
7.6.2.28 How Can an OSPF Route Be Hidden so that It Is Not Advertised to Any Other Area?....................................730
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xix

7.6.2.29 Why Can No OSPF Neighbor Relationship Be Established After FR Is Configured?...................................... 730
7.6.2.30 Why Is the OSPF Neighbor Relationship Establishment on an ATM Interface Slow?......................................730
7.6.2.31 Two Areas Are Configured and the Total Costs of Two Routes Learnt from These Two Areas Are the Same.
However, No ECMP Route Be Generated. Why?............................................................................................................ 731
7.6.2.32 What Are the Common Causes that an OSPF Neighbor Cannot Enter the Full State or Generate Routes?......731
7.6.2.33 How Can OSPF Faults Be Easily Identified?..................................................................................................... 731
7.6.2.34 How Can Faster OSPF Convergence Be Achieved?.......................................................................................... 731
7.6.2.35 Can a Full Neighbor Relationship Be Established if the Network Types of the Two Ends of an OSPF Link Are
Different?..........................................................................................................................................................................732
7.6.2.36 Why Cannot OSPF Inter-Area Route Summarization Take Effect?...................................................................732
7.6.2.37 Why Are the Routes with Smaller Costs Passing Through the Backbone Area Not Preferred?........................732
7.6.2.38 Can the OSPF Network Type Be Configured As P2P or NBMA?.....................................................................732
7.6.2.39 Does the HUAWEI NetEngine40E/80E Support OSPF MD5 Authentication on an Interface?........................ 733
7.6.2.40 Can OSPF Establish a Neighbor Relationship by Using the Secondary IP Address?........................................733
7.6.2.41 Two Routers Are Interconnected. After the Shut Down Command Is Run on One of the Routers, Why Does the
Original LSA Still Exist in the LSDB on the Peer?......................................................................................................... 733
7.6.2.42 What Are the Precautions for Configuring the Cost of a Virtual Link?............................................................. 733
7.6.2.43 Why Does a Failure Occur in the Configuration of a Network Address/Mask and Host Address/Mask
Combination?....................................................................................................................................................................733
7.6.2.44 Why Does Not an LSDB Display Redistributed External Routes?....................................................................734
7.6.2.45 Why Does an ABR Advertise Continuous Network Segment Addresses of an Area as a Summary Address?
.......................................................................................................................................................................................... 734
7.6.2.46 Why Cannot an OSPF Route that Exists in the LSDB Be Found in the Routing Table?...................................734
7.6.2.47 How Can Network Type Problems Be Solved Effectively?............................................................................... 734
7.6.2.48 Why Cannot an OSPF Sham Link Be Established?........................................................................................... 735
7.6.2.49 Why Cannot an OSPF Virtual Link Be Established? ........................................................................................ 735
7.6.2.50 After MIB Parameters Are Configured on the MIB Browser and Router, the MIB Browser Connection Fails
and the OSPF MIB Cannot Be Displayed Normally. Why?.............................................................................................735
7.6.2.51 Why Cannot the Standby Board Restart Through GR after a Switchover to the Standby Board?.....................736
7.6.2.52 Why Are the VPN Routes Learnt from the Peer Incorrect?............................................................................... 736
7.6.2.53 Why Are IGP-Shortcut and Forwarding-Adjacency Forward Tunnel Interfaces Not Advertised? .................. 736
7.6.2.54 When the display ospf peer Command Is Run, Only FULL/DR and FULL/BDR Is Displayed, with all Other
Neighbors Showing 2-WAY/DROTHER. Why?..............................................................................................................736
7.6.2.55 Why Is There No OSPF Neighbor as FULL/DR or FULL/BDR on the Serial Port Link?................................736
7.6.2.56 Can an OSPF Neighbor Relationship Be Established Between Routers that Are on Different Subnets?..........737
7.6.2.57 How Can an OSPF Neighbor Relationship with a Router on a Certain Interface Be Prevented?......................737
7.6.2.58 What Is the Relationship Between OSPF Interface Authentication and Area Authentication?......................... 737
7.6.2.59 Do Problems Occur in Route Calculation When the Backbone Area Is Discontinuous?.................................. 738
7.6.2.60 What Commands Can Be Used to Obtain Common OSPF Information?.......................................................... 738
7.6.2.61 What Commands Can Be Used to Obtain the Information About the OSPF Network Connection?.................739
7.6.2.62 What Commands Are Used to Obtain the Information about the OSPF Routing Table?.................................. 740
7.6.2.63 What Commands Are Used to Obtain the Information about the OSPF Network Type?.................................. 740
7.6.2.64 Why Is the OSPF Default Cost Incorrect?..........................................................................................................740
7.6.2.65 Under What Conditions Is the Status of OSPF Set to Invalid Adv?.................................................................. 740
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xx

7.6.2.66 Why Does the ASBR Generate No Equal-Cost Route?..................................................................................... 741

7.6.2.67 Why Cannot OSPF Import BGP Routes?...........................................................................................................741
7.6.2.68 What Does Each Error Value in the Output of the display ospf error Command Mean?.................................741
7.6.2.69 What Is the Difference Between Unplanned GR and Planned GR?...................................................................746
7.6.2.70 Are the MTUs in the DD Packets Exchanged to Establish an OSPF Neighbor Relationship Checked?........... 746
7.6.2.71 What Are the Destination Addresses of Various Packets Sent by Interfaces with Different Network Types?.. 747
7.6.2.72 How to Determine that Configured OSPF Router IDs Conflict?....................................................................... 747
7.6.2.73 How to Determine that the IP Addresses of Interfaces in an OSPF Area Conflict?.......................................... 749
7.6.2.74 The Local Device Advertises a Host Route with a 24-bit Mask of a Loopback Interface to Its Neighbor. Why Is
the Mask Length of the Route in the Routing Table of the Neighbor Changed to 32 Bits?.............................................752
7.6.2.75 Why Is an OSPF Neighbor Relationship Established Slowly (One Minute) on a Broadcast Network with a Few
Routes?............................................................................................................................................................................. 752
7.6.2.76 Why Are the OSPF Routes in the Routing Table in the Inactive State?.............................................................752
7.6.2.77 Why Does the Interface of an OSPF Process Have Different Statuses Simultaneously?.................................. 752
7.6.2.78 Why Cannot OSPF P2P Interfaces on a Square-Shared Network Establish an OSPF Neighbor Relationship?
.......................................................................................................................................................................................... 753
7.6.2.79 Why Is the Calculated Metric of an OSPF Link 65535?.................................................................................... 753
7.6.2.80 What Are the Rules of Filling In the FA Field of an OSPF LSA?..................................................................... 754
7.6.2.81 Does a Device Support OSPF NSF Described in RFC 3623?............................................................................754
7.6.2.82 What Are the Recommended Values of OSPF Timers?..................................................................................... 754
7.6.2.83 Why Do OSPF Neighbors Have Problems Forming an Adjacency?................................................................. 754
7.6.2.84 Why Is the OSPF Neighbor Stuck in a Certain State?....................................................................................... 754
7.6.3 IS-IS.........................................................................................................................................................................756
7.6.3.1 What Is the Difference Between IS-IS and OSPF in the OSI Reference Model Posed by the ISO?................... 756
7.6.3.2 What Are the Characteristics of IS-IS and OSPF In Terms of Protocols?........................................................... 756
7.6.3.3 Does IS-IS Support P2MP Interfaces?................................................................................................................. 757
7.6.3.4 In the display isis interface Command Output, Why the MTU on a Broadcast Network Is 1497 Bytes Whereas
the MTU on a P2P Network Is 1500 Bytes?.................................................................................................................... 757
7.6.3.5 How Are IS-IS Neighbor Relationships Established?.......................................................................................... 758
7.6.3.6 What Are the Principles of DIS Election on a Broadcast Network?.................................................................... 758
7.6.3.7 What Types of cost-style Can Be Configured in an IS-IS Process and What Are their Features?.......................759
7.6.3.8 What Are the Functions of IS-IS Timers and What Are Their Default Values?.................................................. 760
7.6.3.9 What Is the Working Principle of BFD for IS-IS?............................................................................................... 761
7.6.3.10 What Is the Difference Between Dynamic BFD for IS-IS and Static BFD for IS-IS?.......................................761
7.6.3.11 What Are the Functions of T1 Timer, T2 Timer, and T3 Timer in GR?.............................................................761
7.6.3.12 What Are the IS-IS TE Features?....................................................................................................................... 762
7.6.3.13 How to Configure IS-IS Fast Convergence?...................................................................................................... 762
7.6.3.14 How to Enable IS-IS to Support IGP-LDP Synchronization?............................................................................762
7.6.3.15 Where Are IS-IS and OSPF Deployed on the Network?....................................................................................762
7.6.3.16 Is IS-IS Applicable to the Network Where One CE Is Dual-Homed to Two PEs?............................................ 762
7.6.3.17 How to Obtain the Maximum Number of IS-IS Routes Carrying Out Load Balancing?...................................763
7.6.3.18 Three-way Handshake Is Implemented on P2P Interfaces of an IS-IS Device, Why Does the Problem that the
Local Device Is Up and the Remote Device Is Down Occur?......................................................................................... 764
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxi

7.6.3.19 In an IPv6 Topology, Why Does Not the Level-1-2 Device on an IS-IS Network Set an ATT Flag in the Header
of a Packet?.......................................................................................................................................................................764
7.6.3.20 What Do the Parameters in the set-overload Command Mean?.........................................................................764
7.6.3.21 Q:How to View the Source of an IS-IS Route?.................................................................................................. 764
7.6.4 BGP......................................................................................................................................................................... 765
7.6.4.1 What Is the Function of the undo synchronization Command?......................................................................... 765
7.6.4.2 Why Cannot the Router ID of the System Changed by Using the router id Command Take Effect?................ 765
7.6.4.3 Why Does BGP Attempt to Establish Connections over 30 Seconds After the Peer Is Configured?..................765
7.6.4.4 What Are the Advantages of Using the Loopback Address to Establish BGP Peer Relationship?..................... 765
7.6.4.5 Why Does One BGP End Send the Open Packet Twice Sometimes?..................................................................765
7.6.4.6 How to Set the Durations of the Hold Timer and Keepalive Timer of the BGP Peer?........................................ 765
7.6.4.7 What Do Such BGP Peer States As active, no neg, and idle (admin) Stand For?................................................766
7.6.4.8 Why Are BGP Connections Re-established After the peer connect-interface Command Is Configured?........ 766
7.6.4.9 What Is the Function of the BGP MD5 Authentication? What Are Functions of the simple Parameter and the
cipher Parameter?............................................................................................................................................................. 766
7.6.4.10 Why Is Not the BGP Connection Disconnected Immediately After the shutdown Command Is Run on Either
Interface Between Two Devices?..................................................................................................................................... 767
7.6.4.11 Why Is the BGP Connection with the Same Peer in the VPNv4 Address Family Disconnected After the BGP
Connection with a Peer in the Unicast Address Family Is Reset by Using the reset bgp ipv4-address Command?..... 767
7.6.4.12 How Does BGP Handle an Incorrect Packet?.................................................................................................... 767
7.6.4.13 What Is the Role of the Atomic Aggregation Attribute in Manual Aggregation?..............................................767
7.6.4.14 Why Does Automatic Aggregation Not Function on Routes of the Entire Network Received from the Peer?.767
7.6.4.15 Does the Neighbor Relationship Need to Be Established Between RRs in the Dual RR Backup Environment?
.......................................................................................................................................................................................... 767
7.6.4.16 Why Does a Route Loop Occur Between IBGP Peers When EBGP Routes Are Withdrawn?......................... 767
7.6.4.17 Is It Normal That undo peer 61.255.9.20 route-policy policy_1 export Appears in the VPNv4 View of the
Configuration File?...........................................................................................................................................................768
7.6.4.18 Why Do Export Policies Configured on the RR Not Take Effect?.................................................................... 769
7.6.4.19 What Is the Difference Between valid best and valid in the Detailed BGP Route Attributes?.......................... 769
7.6.4.20 What Is Route Iteration?.....................................................................................................................................769
7.6.4.21 How Does BGP Select Routes?..........................................................................................................................769
7.6.4.22 What Is the Relationship Between the Peer and the Group?.............................................................................. 770
7.6.4.23 What Is Route Cross?......................................................................................................................................... 770
7.6.4.24 What Does the Public Parameter Indicate Which Appears After the Next Hop Is Specified for the Static Route
in the Private Network?.................................................................................................................................................... 771
7.6.4.25 Why Does the Number of Ext-Community Attributes Increase in the BGP Private Routing Table?................ 771
7.6.4.26 Why Must the RD Be Globally Unique When the PE Serves as a Reflector or an ASBR?...............................771
7.6.4.27 Why Cannot BGP Peer Be Established?............................................................................................................ 772
7.6.4.28 Why Cannot the Route of 192.168.1.0/26 Be Imported After network 192.168.1.0 Is Configured?............... 772
7.6.4.29 Why Do Certain IGP Routes Fail to Be Imported When the import-route Command Is Used to Import IGP
Routes to BGP?................................................................................................................................................................ 772
7.6.4.30 Why Do Certain BGP Routes Fail to Be Imported When the import-route Command Is Used to Import BGP
Routes?............................................................................................................................................................................. 772
7.6.4.31 Why Cannot the Community Attribute of a Route Be Displayed on the Neighbor After the Route with the
Community Attribute Is Advertised to the Neighbor?..................................................................................................... 773
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxii

7.6.4.32 How to Change the Next Hop of a Route?......................................................................................................... 773

7.6.4.33 Why Do Routes Listed in the BGP Routing Table Carry Out Load Balancing Though Load Balancing Is Not
Configured?...................................................................................................................................................................... 773
7.6.4.34 Why Cannot Some Routes Be Dampened After dampening Is Configured? How to Use BGP to Dampen
Route Flapping? ...............................................................................................................................................................773
7.6.4.35 Why Is the MED Value of the OSPF Route Imported to the PE Not the Cost Value of OSPF?........................ 773
7.6.4.36 Why Is the Private Network Route Still in the Invalid State After the Public Network Tunnel Is Established?
.......................................................................................................................................................................................... 773
7.6.4.37 Why Cannot the VPN Route Perform Tunnel Load Balancing?........................................................................ 773
7.6.4.38 How to Check Whether EBGP Neighbor Flapping Is Caused by the Excessive Long AS-Path Attribute?...... 774
7.6.4.39 Why Is the Next Hop Address of a Route Imported by BGP from Another Protocol to the BGP Routing Table
0.0.0.0?............................................................................................................................................................................. 775
7.6.4.40 What Are the Views Where the preference Command Can Be Run?............................................................... 776
7.6.4.41 Why Is the Mask Length of a Route in the BGP Routing Table Not Displayed?.............................................. 776
7.6.4.42 Why Cannot the Import Policy Be Used to Change the Preference of a Route on a Peer?................................776
7.6.4.43 After the default med 1 Command Is Run, Why Is the Cost of an IGP Route Imported with the network
Command Still Used as an MED Value?..........................................................................................................................776
7.6.4.44 What Is the Address Range of a BGP Peer?.......................................................................................................777
7.6.4.45 What Is the Full Name of MED?........................................................................................................................777
7.6.4.46 Why Do Two Different VPN Instances on a PE Fail to Successfully Ping Each Other?...................................777
7.6.4.47 Why Are Routes Discarded After I Configure a Policy to Modify Attributes of the Routes?........................... 778
7.6.4.48 When the peer next-hop-local Command Is Not Run on a Device, Why Does the Device Change the Next Hop
of the Route Received from an EBGP Peer to the Address of Its Loopback Interface When Sending the Route to Its
IBGP Peer?....................................................................................................................................................................... 779
7.6.4.49 How to View the BGP Routes Before Filtering?................................................................................................779
7.6.4.50 What Are the Functions of the peer keep-all-routes Command?..................................................................... 779
7.6.4.51 Can the Next Hop of a BGP Route Be Redirected Through a Routing Policy?.................................................779
7.6.4.52 Why Is the BGP Down Cause Displayed as 6/6 When an Interface Goes Down?............................................ 779
7.6.4.53 How to Process a 4-Byte AS Number?.............................................................................................................. 780
7.6.5 RM and TNLM........................................................................................................................................................ 780
7.6.5.1 What Is the Meaning of Each Field in the display ip routing-table verbose Command Output?..................... 780
7.6.5.2 What Is the Meaning of "Flag" in the display fib Command Output?................................................................ 781
7.6.5.3 What Is the Meaning of the order Parameter in the Configuration of the Multicast Static Route?.................... 782
7.6.5.4 Why Is the Number of Routes Listed in the Routing Table Inconsistent with That Listed in the FIB After the
Mechanism of Route Iteration as Required Is Adopted?..................................................................................................783
7.6.5.5 How Are Static Routes Prevented from Supernet Iteration?................................................................................ 783
7.6.5.6 Why Cannot the Backup Information of a Static Route or a BGP Route Be Generated After IP FRR Is
Configured?...................................................................................................................................................................... 783
7.6.5.7 Why Is the Prompt That the Route Is Modified Displayed When the Static Multicast Routes Share the Same
Source IP Address and Address Mask but Differ in the Outbound Interface?................................................................. 783
7.6.5.8 Can a Public Route Be Iterated to the Tunnel?.....................................................................................................784
7.6.5.9 What Is the Logical Relationship Between the Nodes in a Route-Policy?...........................................................784
7.6.5.10 Why Can Static Multicast Routes That Are Configured with Invalid Route Policies Take Effect?.................. 785
7.6.5.11 What Is Wildcard "ip-prefix"?............................................................................................................................ 785
7.6.5.12 Can IP FRR That Is Not Configured with the Backup Outbound Interface Take Effect?..................................786
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxiii

7.6.5.13 What Are Rules for the Election and Update of Router IDs?.............................................................................786
7.6.5.14 How to Select a Tunnel Among Multiple Tunnels Working in Load Balancing Mode?....................................786
7.6.5.15 What Are the Functions of the Tunnel Policy?...................................................................................................787
7.6.5.16 What Are Tunnel Selection Rules Configured Through the tunnel select-seq Command and tunnel binding
Command?........................................................................................................................................................................787
7.6.5.17 Why Does the TE Tunnel to Be Bound Fail to Be Found After the tunnel binding Command Is Configured?
.......................................................................................................................................................................................... 788
7.6.5.18 How to Correctly Understand Load Balancing Carried Between 32 Routes?....................................................788
7.6.5.19 Can the Outbound Interface Only Be the Point-to-Point Interface During the Configuration of a Static Route
for Multicast?....................................................................................................................................................................788
7.6.5.20 Does the Configuration of an Active Static Route Still Exist When the Outbound Interface Status of the Static
Route Goes Down?........................................................................................................................................................... 789
7.6.5.21 What Do PAF Items in RM Represent?..............................................................................................................789
7.6.6 Routing Policy......................................................................................................................................................... 789
7.6.6.1 After the load-balance packet Command Is Run, the tracert Command Output Shows that Packet-by-Packet
Load Balancing Is Configured. Why Cannot Packet-by-Packet Load Balancing Be Implemented for Traffic?............. 789
7.6.6.2 What Is UCMP?....................................................................................................................................................790
7.6.6.3 On an Ethernet, After an Interface Is Configured with an IP Address, the Host Route and Network Segment
Route Associated With the Interface IP Address Are Generated. On a PPP Network, Why Is the Host Route Destined
for the Remote Interface Generated?................................................................................................................................790
7.7 Multicast..................................................................................................................................................................... 790
7.7.1 How to Perform Load Balancing When the Outbound Interface of Multicast Traffic Is an Eth-Trunk Interface or
an IP-Trunk Interface?...................................................................................................................................................... 790
7.7.2 Why Is the Multicast Source Register Message Still Forwarded After the register-policy Command Is Configured
on the RP to Discard the Register Message?.................................................................................................................... 790
7.7.3 Which Inter-AS Modes Are Supported by Multicast VPNs?.................................................................................. 791
7.7.4 How to Enable an RP Router to Filter the Received Multicast Data Packets Based on the Source Address or
Source/Group Address?.................................................................................................................................................... 791
7.7.5 What Are the Functions of PIM Silent on a PIM Interface?................................................................................... 791
7.7.6 When a Host Leaves a Group, How Does an IGMP Querier Judge Whether Any Other Members of the Group
Exist on the Network Segment?....................................................................................................................................... 791
7.7.7 Can the Hosts and Devices on the Same User Network Segment Run Different Versions of IGMP?....................792
7.7.8 What Are Functions of an RPF Check in MSDP and What Is the Process of an RPF Check?...............................792
7.7.9 How Do Unicast Packets (Such as Register Packets and Graft Packets) of a Multicast Routing Protocol Pass an
Mtunnel Interface Since an Mtunnel Interface Does Not Advertise Its Routes?............................................................. 793
7.7.10 Why Does the Downstream Interface Used by the Source'S DR to Send Register Messages Remain in the
Register State?.................................................................................................................................................................. 793
7.7.11 On Which Interfaces Need PIM Be Enabled In a PIM Domain?.......................................................................... 793
7.7.12 Can PIM-DM and PIM-SM Run Simultaneously in a PIM Domain?...................................................................794
7.7.13 Why Must We Ensure that Unicast Routes Are Reachable Before Configuring Multicast Services?.................. 794
7.7.14 How to Perform the RPF Check for Establishing an RPT in a PIM-SM Domain?...............................................795
7.7.15 Why Is the Forwarding of the Multicast Data Packet Interrupted After the Multicast Data Reaches the
Intermediate Device Through the MDT?......................................................................................................................... 795
7.7.16 Why Is Multicast Forwarding Prone to Be Interrupted on a Device Where Preferential Use of the Static RP Is
Enabled?........................................................................................................................................................................... 795
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxiv

7.7.17 Why Is Multicast Forwarding on a Normal Interface Interrupted After Hello Messages Are Sent to This
Interface?.......................................................................................................................................................................... 796
7.7.18 Why Cannot an MDT Be Set Up Correctly If PIM Is Not Enabled on an RPF Interface?................................... 796
7.7.19 Why Cannot an MDT Be Set Up Correctly If the RPF Neighbor Is Not a PIM Neighbor?................................. 796
7.7.20 Why Cannot an MDT Be Set Up Correctly If There Is No Unicast Route to the Multicast Source?................... 797
7.7.21 Why Cannot an RPT Be Set Up Correctly If Static RP Configurations on the Devices over the Entire Network
Are Inconsistent?.............................................................................................................................................................. 797
7.7.22 How Does IGMP Elect a Querier from Multiple Devices on a Shared Network Segment?................................. 797
7.7.23 What Are Differences Between the Querier and the PIM DR and Who Is Responsible for Forwarding Multicast
Data?................................................................................................................................................................................. 798
7.7.24 What Are Requirements for Configuring IGMP Parameters on Each Interface of the Devices on a Shared
Network Segment?........................................................................................................................................................... 798
7.7.25 Why Are not (S, G) Entries Generated After SSM Mapping Is Enabled?............................................................ 799
7.7.26 Can a Device Process the Report Messages Delivered After the Maximum Response Time Expires?................799
7.7.27 Why Does the SA Filtering Policy Configured on the MSDP Peer Originating SA Messages Fail to Take Effect?
.......................................................................................................................................................................................... 800
7.7.28 Why Cannot (S, G) Information Be Exchanged Though Anycast RP Is Configured?..........................................800
7.7.29 Why Does the State of the MSDP Peer Keep Down Though the MSDP Peer Relationship Is Set Up?...............800
7.7.30 Why Cannot the router Learn Entries of Group Members After Layer 2 Multicast Is Correctly Configured and
All Interfaces Are Up?......................................................................................................................................................801
7.7.31 What Are Characteristics of PIM-DM, PIM-SM, and PIM-SSM and Which Type of Network Is Each Mode
Applicable to?...................................................................................................................................................................802
7.7.32 Does a Device Preferentially Select the Route with the Highest Precedence Rather Than the Route with the
Longest Matched Mask?...................................................................................................................................................802
7.7.33 Does an Outbound Interface Functioning as a DR Stop Forwarding Multicast Data Immediately If It Changes to
Be a Non-DR Because of Changed DR Priority After a PIM DR Switching Delay Is Set?............................................ 802
7.8 QoS............................................................................................................................................................................. 803
7.8.1 CAR......................................................................................................................................................................... 803
7.8.1.1 Will the FTP Service Be Affected If the Default CBS and PBS Configurations Are Adopted for the CAR?.....803
7.8.1.2 After the Rate in a CAR Policy Is Limited to 20 Mbit/s, the Interface Rate Sometimes Exceeds 20 Mbit/s. Why
Does the CAR Policy Not Take Effect?............................................................................................................................803
7.8.1.3 What Are the Reference Values of the CIR and CBS of the CAR on a Sub-Interface?.......................................803
7.8.1.4 After the qos car cir 10000 cbs 1000000 pbs 0 green pass yellow pass red discard inbound Command Is
Configured on an Interface, Traffic on the Interface Is at a Steady Rate of About 10M. Why Does Great Jitter Occur?
.......................................................................................................................................................................................... 803
7.8.2 Traffic Policy........................................................................................................................................................... 804
7.8.2.1 If Multiple Behaviors Are Configured in One Policy, What Is the Execution Sequence of Multiple Behaviors in
One Traffic Policy?...........................................................................................................................................................804
7.8.2.2 Can the Master and Backup Next Hops That Are Not Defined in the Routing Table Be Configured for
Redirection on the Device?...............................................................................................................................................804
7.8.2.3 Why Are No Statistics About the Number of Packets Matching an ACL Rule Collected After a Traffic Policy Is
Configured on the Device?............................................................................................................................................... 804
7.8.2.4 How Does share-mode Function When a Traffic Policy Is Applied to Different Interfaces?.............................. 804
7.8.2.5 If URPF and the Traffic Policy Are Both Configured on an Interface, Which Is Executed First? Does URPF
Affect MPLS Forwarding?............................................................................................................................................... 805
7.8.2.6 When the ATM Service Type Is Set to VBR on the Device, What Does the Last CDVT Parameter Mean?...... 805
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxv

7.8.2.7 Can Traffic Switch Back to the Original Path If the Interface Configured with Redirection Is Down?.............. 805
7.8.2.8 How to Configure an Anti-virus Access List?......................................................................................................805
7.8.2.9 How to Define the Traffic Policy and Use the Traffic Policy on Interfaces?....................................................... 806
7.8.2.10 Whether Can the Same Traffic Policy Limit the Traffic on Users on Different Sub Interfaces?....................... 806
7.8.2.11 How to Impose the Limit on the Access of the Host with the Specific Source or Destination Address to the
Network?.......................................................................................................................................................................... 806
7.8.2.12 How to Enable a Server to Set Up Website Services but Disable Other Servers to Set Up Website Services?. 807
7.8.2.13 How to Prevent Any Source IP Address from Pinging a Destination Address?................................................ 807
7.8.2.14 How to Limit the Online Service of Users to a Certain Period?........................................................................ 807
7.8.2.15 How Do I Check Packet Drop Between Devices?..............................................................................................808
7.8.2.16 How to deal with the relationship between the deny/permit mode defined in ACL and the deny/permit mode
defined in traffic behavior?...............................................................................................................................................809
7.8.2.17 Why Does a User Fail to Go Online After a Traffic Policy Is Configured?.......................................................809
7.8.3 ATM QoS.................................................................................................................................................................809
7.8.3.1 Why Is the CLP Field in ATM Cells Not Kept After Successful Configuration of Transparent Transmission of
ATM Cells?.......................................................................................................................................................................809
7.8.3.2 Why Do ATM Cells Fail to Go Into Internal Queues of the PE After Configuration of Transparent Transmission
of ATM Cells?.................................................................................................................................................................. 810
7.8.3.3 Why Does the Command Configured in the DS Domain Fail to Be Displayed?.................................................810
7.8.3.4 Is the trust upstream default Command Effective on Both Upstream or Downstream Packets?......................... 810
7.8.4 HQos........................................................................................................................................................................ 810
7.8.4.1 HQoS Is Configured on the User Side of the PE. Why Does HQoS Not take Effect?.........................................810
7.8.4.2 Q: Why Cannot a Large Number of Users Access the Internet or Why Is the Internet Access Speed Low If a
RADIUS Server Is Used to Allocate User Bandwidth?................................................................................................... 810
7.8.5 UCL......................................................................................................................................................................... 811
7.8.5.1 Presume that a Policy Is Configured with Both ACL 3000 and ACL 6000. If the Policy Is Globally Applied,
How Many Rules Are Delivered? If the Policy Is Applied to an Interface, How Many Rules Are Delivered?.............. 811
7.8.6 BAS HQoS...............................................................................................................................................................811
7.8.6.1 Why Does Not BAS HQoS Take Effect at the User Side?................................................................................... 811
7.8.7 Last Mile QoS..........................................................................................................................................................811
7.8.7.1 Why Does Not Last Mile QoS Take Effect?.........................................................................................................811
7.8.7.2 How Does Last Mile QoS Configurations Take Effect with L2TP Services?......................................................811
7.8.8 Others.......................................................................................................................................................................811
7.8.8.1 What Are Configuration Differences Between QoS-related Commands on a Logical Interface and QoS-related
Commands on a Physical Interface?.................................................................................................................................812
7.8.8.2 Under Which Conditions Can Policy-based Routing on the NE40E&NE80E Take Effect? Must Reachable
Routes Exist?.................................................................................................................................................................... 812
7.8.8.3 Is There Any Restriction on Weights Assigned to WFQ Queues? Is It Required that the Sum of Weights of all
WFQ Queues Be 100?...................................................................................................................................................... 813
7.8.8.4 Can the Policies Configured on a Main Interface Take Effect on All Its Sub-interfaces?................................... 813
7.9 MPLS..........................................................................................................................................................................813
7.9.1 LDP..........................................................................................................................................................................813
7.9.1.1 What Are the Functions of LDP Hello Messages?...............................................................................................814
7.9.1.2 How to Identify an LDP Hello Message?.............................................................................................................814
7.9.1.3 How to View the Number of Received and Sent Hello Messages?......................................................................814
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxvi

7.9.1.4 Why the Number of Both Received and Sent Hello Messages Is Zero?.............................................................. 814
7.9.1.5 Why Cannot the Peer Receive a Hello Message from the Local LSR When Both the Local Interface and Peer
Interface Are Up?............................................................................................................................................................. 814
7.9.1.6 Why Does Not the Number of Both Received and Sent Hello Messages Increase?............................................814
7.9.1.7 How to Determine an LDP Transport Address Used to Set Up a TCP Connection?........................................... 814
7.9.1.8 How to View the LDP Transport Address Used to Set Up a TCP Connection?.................................................. 815
7.9.1.9 How to Determine a Server and a Client in a TCP Connection for an LDP Session?......................................... 815
7.9.1.10 How to View a TCP Connection Set Up for an LDP Session?.......................................................................... 815
7.9.1.11 How to Judge Whether a TCP Connection on a Server Is Normal?...................................................................815
7.9.1.12 Why Does a TCP Connection Fail to Be Set Up?.............................................................................................. 815
7.9.1.13 Why Does a TCP Connection Fail Go Up When the Ping Is Successful?......................................................... 815
7.9.1.14 Why Is Not a Listening Port Created on a Server?.............................................................................................815
7.9.1.15 Why Does Not a Client Initiate a TCP Connection?.......................................................................................... 816
7.9.1.16 Why Does a TCP Connection Fail to Be Set Up When Both a Server and a Client Initiate a TCP Connection?
.......................................................................................................................................................................................... 816
7.9.1.17 What Are the Functions of LDP Keepalive Messages?......................................................................................816
7.9.1.18 How to View the Number of Received and Sent Keepalive Messages?............................................................ 816
7.9.1.19 Why Does Not the Number of Both Received and Sent Keepalive Messages Increase?...................................816
7.9.1.20 What Are the Common Causes of the Problem that an LDP Session Suddenly Goes Down?.......................... 816
7.9.1.21 How to Locate the Cause of the Problem that an LDP Session Flaps After a Hello Hold Timer Expires?....... 816
7.9.1.22 How to Locate the Cause of the Problem that an LDP Session Flaps After a Keepalive Hold Timer Expires?
.......................................................................................................................................................................................... 817
7.9.1.23 Why Cannot an LDP Session Go Up After a TCP Session Is Normally Set Up?..............................................817
7.9.1.24 In Which Scenario Do LSPs Flap?..................................................................................................................... 817
7.9.1.25 How to Troubleshoot the Problem of LSP Flapping?.........................................................................................817
7.9.1.26 Which Measures Can Be Taken When LSP Flapping Occurs?..........................................................................817
7.9.1.27 How to Verify That an LDP LSP Is Successfully Set Up?................................................................................. 818
7.9.1.28 What Is the Process of Configuring LDP over TE?........................................................................................... 818
7.9.1.29 How to Troubleshoot the Problem that an LSP Fails to Be Set Up in the LDP over TE Scenario?.................. 819
7.9.1.30 What Are the Functions of MPLS Ping?............................................................................................................ 820
7.9.1.31 Does MPLS Ping Support Fragmented Packets?............................................................................................... 820
7.9.1.32 What Are the Functions of GR Timers Configured in the MPLS LDP View?.................................................. 820
7.9.1.33 What Is the Default Value of Each GR Timer Set in the MPLS LDP View?.....................................................821
7.9.1.34 Why Is the Logged LDP GR Time Larger Than the Timeout Period (10 Minutes) of the MPLS Forwarding
State Holding Timer?........................................................................................................................................................821
7.9.1.35 How to Judge Whether a Device Is in the LDP GR Process?............................................................................ 821
7.9.1.36 Why Does Not an LSR Retain Forwarding Entries After the Master/Slave Switchover Is Performed on the
Neighbor?......................................................................................................................................................................... 821
7.9.1.37 How to Judge Whether an LSR Has the GR Capability?................................................................................... 821
7.9.1.38 Why Does LDP Loop Detection Not Need to Be Enabled?...............................................................................821
7.9.1.39 Why Is No Optimal Route Generated?...............................................................................................................821
7.9.1.40 Why Cannot the Primary LSP Be Bound to a Backup LSP When LDP FRR Is Enabled?................................822
7.9.1.41 How to Judge Whether a Liberal LSP Is Generated When LDP FRR Is Enabled?........................................... 822
7.9.1.42 How to Judge Whether Manual LDP FRR Is Correctly Configured?................................................................ 823
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxvii

7.9.1.43 Does Packet Loss Occur During the LDP FRR Switchback?............................................................................ 823
7.9.1.44 What Types of Labels Are Distributed Through LDP?...................................................................................... 823
7.9.1.45 What Is an Explicit Null Label?......................................................................................................................... 823
7.9.1.46 What Is an Implicit Null Label?......................................................................................................................... 824
7.9.1.47 In Which Scenario Does LDP Use Non-Null Labels?........................................................................................824
7.9.1.48 How to Identify the Type of the Label Pushed into a Packet at the Penultimate Hop?......................................824
7.9.1.49 How to Configure an Explicit Null Label Be Assigned to the Penultimate Hop?............................................. 825
7.9.1.50 What Is the Meaning of the MTU in the display mpls interface Command Output?...................................... 825
7.9.1.51 What Are the Meanings of MTUs in the display mpls interface verbose Command Output?........................ 825
7.9.1.52 What Is the Meaning of the MTU in the display mpls ldp interface verbose Command Output?..................825
7.9.1.53 What Is the Meaning of the MTU in the display mpls lsp include Command Output?................................... 826
7.9.1.54 What Are the Causes of the Problem that a Static LSP Cannot Go Up?............................................................826
7.9.1.55 What Is the Difference Between a Static LSP Bound to a Tunnel and a Static CR-LSP?................................. 827
7.9.1.56 Which Must Be Specified, the Next-hop Address or the Outgoing Interface, When a Static Ingress LSP Is to Be
Set Up?............................................................................................................................................................................. 827
7.9.1.57 Why Does an LDP Session Fail to Be Set Up After the Link Protocol Is Changed to Frame Relay on an LDP-
Enabled POS Interface?....................................................................................................................................................827
7.9.1.58 What Are the Causes of the Board Problem, Which Results In LDP Session Flapping?.................................. 828
7.9.1.59 Why Cannot an LDP Session Be Set Up Between ATM Interfaces?................................................................. 829
7.9.1.60 What Are the Messages of LDP and the Intervals for Sending These Messages?............................................. 830
7.9.1.61 What Problems Does the Coexistence of a Local LDP Session and a Remote LDP Session Solve?................ 830
7.9.1.62 Are There Any LDP Sub-features?.................................................................................................................... 831
7.9.1.63 What Are Functions of the remote-peer pwe3 and remote-ip ip-address pwe3 Commands?......................... 833
7.9.1.64 What Are Functions of the lsp-trigger { all | host | ip-prefix ip-prefix-name | none } Command?................. 834
7.9.1.65 What Are Functions of the propagate mapping Command?............................................................................834
7.9.1.66 How to Configure RDs of Two Devices, to Which a CE is Dual-Homed, to Enable an Automatic Service
Failover If a Failure Occurs?............................................................................................................................................ 835
7.9.1.67 Is MPLS Forwarding Supported After a CPOS Interface is Encapsulated with FR?.........................................835
7.9.1.68 How to Allocate Labels to a Penultimate Hop After the label advertise non-null Command Has Been
Configured in the MPLS View on the Egress?.................................................................................................................835
7.9.1.69 Which Routes Can Iterate to LSPs After the route recursive-lookup tunnel Command Has Been Configured?
.......................................................................................................................................................................................... 835
7.9.1.70 Q: Why the Size of MPLS L2VPN Packets Sent by a PE Is Different from That in Port Queue Statistics?.....835
7.9.2 TE............................................................................................................................................................................ 835
7.9.2.1 What Are the Advantages of MPLS TE Against the Ordinary MPLS?............................................................... 836
7.9.2.2 What Is the Role of CSPF in the TE Architecture?.............................................................................................. 836
7.9.2.3 Why is RSVP Called a Soft State?....................................................................................................................... 836
7.9.2.4 How Many Types of RSVP-TE Messages Are There?........................................................................................ 836
7.9.2.5 What Does Make-before-break Mean?.................................................................................................................837
7.9.2.6 Types of FRR Protection...................................................................................................................................... 838
7.9.2.7 CR-LSP Backup Modes........................................................................................................................................839
7.9.2.8 Differences Between CR-LSP Backup and TE FRR............................................................................................839
7.9.2.9 How to Verify Results of the CSPF Route Calculation?...................................................................................... 839
7.9.2.10 In MPLS TE, How to Judge Whether Loops Are Formed?............................................................................... 839
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxviii

7.9.2.11 Why Does RSVP Authentication Fail?...............................................................................................................840

7.9.2.12 Why Does an RSVP Message Time Out?.......................................................................................................... 840
7.9.2.13 How to Determine Whether the Destination Address of a Tunnel Is Reachable or Not?.................................. 840
7.9.2.14 What Is the Relationship Between the Destination Address of a Tunnel and the IP Address of a Loopback
Interface?.......................................................................................................................................................................... 841
7.9.2.15 How to Check the Path of a Tunnel?.................................................................................................................. 841
7.9.2.16 How Can a TE Tunnel Participate in Route Calculation?.................................................................................. 841
7.9.2.17 Why Does the TE Tunnel Fail to Be Set Up Although the LSP is Successfully Calculated by the CSPF?.......841
7.9.2.18 Of the Equal-cost TE Links, the Link with the Maximum Reservable Bandwidth is Selected in CSPF
Calculation Although tie-breaking Is Set to most-fill. Why?........................................................................................... 842
7.9.2.19 For TE Tunnel Re-optimization, What Are the Criteria Determining Whether the Re-optimization Path Is a
Better One?....................................................................................................................................................................... 842
7.9.2.20 RSVP-TE Is Enabled on Both Ends of a Link. But Running the display mpls rsvp-te peer Command Displays
no Information About the RSVP Peer. Why?...................................................................................................................842
7.9.2.21 What Is the Typical Application of the LDP over TE Tunnel Feature?............................................................. 842
7.9.2.22 How Are TE Tunnels Used in Inter-AS BGP/MPLS IP VPN Forwarding and Inter-AS VPWS Forwarding?.842
7.9.2.23 How to View the Basic Attributes of a Tunnel?................................................................................................. 843
7.9.2.24 How to View the Actual Path of a Tunnel and the Binding of FRR?.................................................................844
7.9.2.25 How to View Information About the Allocation of Link Bandwidth?...............................................................844
7.9.2.26 How to View Information About an LSP?......................................................................................................... 844
7.9.2.27 How to View Information About PSB and RSB?...............................................................................................844
7.9.2.28 What Are the Functions of RSVP Route Pinning?.............................................................................................844
7.9.2.29 Why Is Not TE-IGP Synchronization Designed?...............................................................................................845
7.9.2.30 What Is the Meaning of an RSVP Neighbor Address?...................................................................................... 845
7.9.2.31 Are There Any TE Sub-Features?...................................................................................................................... 847
7.9.2.32 What Is the Hop Limit of a TE Tunnel?............................................................................................................. 859
7.9.3 VPLS....................................................................................................................................................................... 861
7.9.3.1 Does the Device Support MAC Address Learning in Qualified Mode on a VPLS Network?.............................861
7.9.3.2 How Many Tags Are Carried in a Packet Sent by a Sub-interface for QinQ VLAN Tag Termination Accessing a
VPLS Network in Symmetry Mode?................................................................................................................................861
7.10 VPN.......................................................................................................................................................................... 861
7.10.1 MPLS L2VPN....................................................................................................................................................... 861
7.10.1.1 Under What Conditions Can a VSI Be Up in a VPLS Network?.......................................................................861
7.10.1.2 Under What Conditions Can a PW Be Up When the VPLS Network Is Configured?...................................... 861
7.10.1.3 May the VSI Status Be Affected When ACs on Both Ends of a PW Are Bound to Interfaces of Different
Types?............................................................................................................................................................................... 862
7.10.1.4 Can Communication Be Normal When ACs Are Bound to Interfaces of Different Types on Both Ends of a
PW?.................................................................................................................................................................................. 862
7.10.1.5 May the VSI Status Be Affected When Both VSIs Learn MAC Addresses in Different Modes?.....................862
7.10.1.6 Why the LSP Token in a VPLS MID Entry Is Different from the Token of the Current Tunnel?..................... 862
7.10.1.7 How Can a PW Be Set Up Between Devices Through Martini VPLS?.............................................................862
7.10.1.8 Can a Device Configured with a Martini VPLS Link Communicate with a Device Configured with a VLL?. 862
7.10.1.9 How to Locate the Cause of the Problem that the Martini VPLS Connection Fails to Go Up?.........................863
7.10.1.10 Can VSIs Go Up Only When PEs Being Bound to VSIs?............................................................................... 864
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxix

7.10.1.11 Can Only One VSI on One End of a PW Be Up?.............................................................................................864

7.10.1.12 Is the Full Mesh Required by PEs in the Networking of VPLS Using LDP Signaling?..................................864
7.10.1.13 Can a VSI Be Up Only When VSI IDs on Both Ends of a PW Are the Same?............................................... 864
7.10.1.14 Is negotiation-vc-id Relevant to a UPE?.......................................................................................................... 864
7.10.1.15 When Does the mpls ldp remote-peer Command Need to Be Run During the Process of Configuring a VPLS
Peer?................................................................................................................................................................................. 865
7.10.1.16 How Can a PW Be Set Up Between Devices Connected Through Kompella VPLS?.....................................865
7.10.1.17 How to Locate the Cause of the Problem that the Kompella VPLS Connection Fails to Go Up?...................865
7.10.1.18 What Are the Precautions for Configuring a Huawei Device to Interwork with a Non-Huawei Device Through
Kompella VPLS?.............................................................................................................................................................. 866
7.10.1.19 What Is the Relationship Between the Site, Range, and Offset of BGP VPLS?.............................................. 866
7.10.1.20 How Can a PW Be Set Up Between Two Devices When One Is Configured With the Martini VLL and the
Other Is Configured with the PEW3 VLL?...................................................................................................................... 867
7.10.1.21 Under What Conditions Can an LDP VC Connection Be Up?........................................................................ 867
7.10.1.22 How to Locate the Cause of the Problem that the Martini or PWE3 VLL Connection Fails to Go Up?.........867
7.10.1.23 How to Change a VLL to the Martini Mode?.................................................................................................. 869
7.10.1.24 When Do local-ce ip and local-ce mac Need to Be Set On a Heterogeneous Network?................................. 869
7.10.1.25 What Special Configurations Are Required by an FR Interface and What Are the Principles for Configuring a
DCE Interface and a DTE Interface on a CE and a PE?...................................................................................................869
7.10.1.26 What Are the Functions of Control Words in PWE3?......................................................................................870
7.10.1.27 Can a Multi-Hop VC with the Same Peer and Different Encapsulation Types Be Set Up on an SPE Configured
with the mpls switch-l2vc Command?............................................................................................................................ 870
7.10.1.28 Can a PW ID Be Set to Zero or No PW ID Be Set When a Static PW Is to Be Set Up?................................. 870
7.10.1.29 How to Implement VLL Load Balancing?....................................................................................................... 870
7.10.1.30 What is Multi-Hop in PWE3? When Does Multi-Hop PWE3 Need to Be Configured? How to Configure
Multi-Hop PWE3?............................................................................................................................................................ 870
7.10.1.31 What Are Differences Between the Tagged and Untagged Encapsulation Modes on an Ethernet Interface and
the Tagged and Raw Encapsulation Modes on a PWE3 Tunnel?.....................................................................................871
7.10.1.32 Why CEs on Both Ends of a PW Cannot Communicate with Each Other When Interfaces on the CEs and PEs
Are Up After the CEs Access the PEs Through the ATM Homogeneous Medium?....................................................... 871
7.10.1.33 When AC Interfaces on PEs on Both Ends of a PWE3 Tunnel Are Ethernet Interfaces, the Two CEs Cannot
Ping Each Other When the mpls l2vc Command Without ip-interworking Is Used on PEs. Why?................................ 872
7.10.1.34 Which Configuration Takes Effect, L2VPN or L3VPN When an Interface Is Concurrently Bound to an
L2VPN and L3VPN?........................................................................................................................................................872
7.10.1.35 What Are Differences Between Ethernet OAM and Other Link Detection Mechanisms?.............................. 872
7.10.1.36 Why Cannot Ethernet OAM in Transient Interruption Mode Be Configured in the VLL FRR Networking?.872
7.10.1.37 What Are the Precautions for Configuring VLL FRR Switchback Policies?.................................................. 873
7.10.1.38 In PWE3 Heterogeneous Internetworking, CEs Run OSPF. Why Cannot the Local CE Learn Routes to the
Peer CE Through OSPF?.................................................................................................................................................. 873
7.10.1.39 Tunnels Are Correctly Configured Between PEs. Why Cannot a VC Be Bound to the Tunnel After PWE3 Is
Configured?...................................................................................................................................................................... 873
7.10.1.40 How Can a PW Be Set Up Between Devices Through the Kompella VLL?................................................... 873
7.10.1.41 What Are the Precautions for Configuring a Huawei Device to Interwork with a Non-Huawei Device Through
Kompella VLL?................................................................................................................................................................ 874
7.10.1.42 Are the Full Connections Between PEs in a VPLS Network Physical or Logical? How to Prevent Routing
Loops?.............................................................................................................................................................................. 874
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxx

7.10.1.43 How Does the System Calculate the Blocking Time in MAC Flapping?........................................................ 874
7.10.1.44 Why Forwarding Entries Are Correct but Traffic Forwarding Fails on a PE After Some VPLS Services Are
Deployed?......................................................................................................................................................................... 875
7.10.2 L3VPN...................................................................................................................................................................875
7.10.2.1 Does a Super VLAN Transmit L3VPN Services on a Device?..........................................................................875
7.10.2.2 Can Load Balancing Be Performed for L3VPN Traffic Transmitted over an MPLS Network?........................876
7.10.2.3 May L3VPN Services Be Interrupted During a Master/Slave Failover on the Device?.................................... 876
7.10.2.4 What Are VPN Label Allocation Modes and What Are Differences Between These Modes?......................... 876
7.10.2.5 Can a Notification of a Link Failure on a Link Between the Remote PE and CE Is Sent over a VLL to Instruct
the Local PE or CE to Change the Connection Status?.................................................................................................... 876
7.10.2.6 What Is the Function of the remote-ip ip-address pwe3 Command?................................................................. 877
7.10.2.7 Can the NE40E&NE80E Back Up Configurations to the N2000 Server by Using VPNs?............................... 877
7.10.2.8 Why Traffic Is Unevenly Shared After the Load-Balancing Mode Changes from Route Load Balancing to
Trunk Load Balancing on a P in an L3VPN Scenario?.................................................................................................... 877
7.10.3 ATM IWF.............................................................................................................................................................. 877
7.10.3.1 What Is the Possible Cause for Communication Failure in the MPLS L2VPN?............................................... 877
7.10.3.2 Why IWF Is Addressed?.....................................................................................................................................878
7.11 Security..................................................................................................................................................................... 878
7.11.1 URPF..................................................................................................................................................................... 878
7.11.1.1 What Is the Difference Between the URPF Strict Mode and the URPF Lose Mode?........................................878
7.11.1.2 Q: Can the router Forward a Packet through an Interface that receives the packet?.......................................... 878
7.11.2 Port Mirroring........................................................................................................................................................ 878
7.11.2.1 Can the Device Mirror Traffic of Multiple Ports to One Observing Port? If So, Is There a Restriction on the
Number of Mirrored Ports?.............................................................................................................................................. 878
7.11.2.2 Is Traffic on Sub-interfaces Mirrored After Mirroring Is Configured on the Main Interface?.......................... 878
7.11.2.3 Can an Interface Be Configured As a Mirroring Port and an Observing Port At the Same Time?.................... 879
7.11.2.4 Do Ethernet Interfaces Support the Port Mirroring Function?........................................................................... 879
7.11.3 Local Defense........................................................................................................................................................ 879
7.11.3.1 How to Configure Users to Manage the Router Through a Specified Interface?...............................................879
7.11.3.2 Why Some Normal Packets Are Discarded When Local Attack Defense Policy Is Applied?...........................879
7.11.3.3 Is NetStream Information in the Cache a Basis for Checking Whether Attacks Exist?.....................................879
7.11.3.4 Services Are Interrupted After a Layer 2 Interface Is Shut Down or When the CPU Usage of the Board Where
the Interface Resides Increases. How to Handle This Problem?...................................................................................... 879
7.11.4 other....................................................................................................................................................................... 880
7.11.4.1 Can a Routing Protocol and Routing Protocol Services Be Run on GE 0/0/0 on an SRU/MPU?..................... 880
7.12 Reliability................................................................................................................................................................. 880
7.12.1 BFD....................................................................................................................................................................... 880
7.12.1.1 When Does Batch Backup Occur?..................................................................................................................... 880
7.12.1.2 Why Does VRRP Switchback Need to Be Controlled?..................................................................................... 880
7.12.1.3 When Does an Address Pool Need to Be Bound to the RBP?........................................................................... 880
7.12.1.4 When Does an Address Pool Need to Be Bound to the RBS?........................................................................... 880
7.12.1.5 Why More Than the Maximum Number of BFD Sessions Can Be Configured and the System Only Prompts an
Error When the Configurations Are Committed?.............................................................................................................881
7.12.1.6 Why the Contents of the Time Entry in Session Statistics Vary with the Session Status?.................................881
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxi

7.12.1.7 Why the commit Command Needs to Be Used?................................................................................................ 881

7.12.1.8 Why the BFD Session Detection Mode Is Still Asynchronous After the Demand command Is Configured in the
BFD Session View?.......................................................................................................................................................... 882
7.12.1.9 Why the Type of a Single-hop Route Is Displayed as Multi-hop in BFD Session Details?...............................882
7.12.1.10 Can You List All the Session Detect Modes and Specify When a Session Detect Mode Is Adopted?............883
7.12.1.11 Why Is Information on the LPU Inconsistent with that on the MPU?............................................................. 883
7.12.1.12 What Is the Difference Between Min Tx Interval (ms) and Actual Tx Interval (ms)?.................................... 884
7.12.1.13 Why the Packet Count Stops Increasing When the Session Goes Up?............................................................ 884
7.12.1.14 Why Does the BFD Session in the Down State Remain Down After Receiving a Packet Indicating the Up
State?................................................................................................................................................................................ 885
7.12.1.15 Does Any Change in the Tx or Rx Parameter Result in BFD Session Flapping?............................................ 885
7.12.1.16 How Long Does It Take for a BFD Session to Go Up After It Is Established?............................................... 885
7.12.1.17 What Are the Four Parameters of a Dynamic BFD Session?...........................................................................885
7.12.1.18 BFD for IFNET, Also Called BFD for Interface or Interface Status Association, Is a Widely Used Feature of
BFD. What Are the Purpose and Typical Scenarios of This Feature?..............................................................................885
7.12.1.19 What Is BFD for PST?......................................................................................................................................886
7.12.1.20 When the process-interface-status Command Is Run, the System Displays "Error: A BFD session has been
configured with process-interface-status." What Does This Error Prompt Mean?.......................................................... 886
7.12.1.21 When Different Applications Share the Same BFD Session and Set Different Values of TX and RX
Parameters, Which Value Does the BFD Session Adopt?................................................................................................886
7.12.1.22 During the Configuration of Dynamic BFD for IS-IS, If Tx and Rx Parameters Are Both Set on an Interface
Through the isis bfd enable Command and Configured Globally in the IS-IS View, Which Configuration of the
Parameters Takes Effect?..................................................................................................................................................886
7.12.1.23 What Is the Range of the Source Port Number of BFD Protocol Packets?......................................................886
7.12.1.24 Why No Corresponding BFD Session Is Available After Static BFD Is Configured?.................................... 887
7.12.1.25 Why Does a Dynamic BFD Session Fail to Be Created?.................................................................................887
7.12.1.26 How to Handle the Situation that a BFD Session Is Successfully Created But Remains Down?....................887
7.12.1.27 What Are the TTL Values of BFD-related Features?....................................................................................... 887
7.12.1.28 When the BFD for Static LSP Session and BFD for Dynamic LSP Session Coexist (the Two BFD Sessions
Are of the Same FEC), Which BFD Session Will Take Effect?.......................................................................................887
7.12.1.29 What Defines the Default Minimum Tx and Rx Values?................................................................................. 888
7.12.1.30 What Are the Meanings of Two Items in the display bfd session all verbose Command Output?................ 888
7.12.1.31 Why Must a BFD Session Take Less Time to Detect a Trunk Member Interface Than It Takes to Detect a
Trunk Interface?................................................................................................................................................................889
7.12.1.32 What Is the Meaning of the C Bit in a BFD Control Packet?.......................................................................... 889
7.12.2 VRRP.....................................................................................................................................................................889
7.12.2.1 Why Cannot the VRRP Status Be Switched Properly After STP Is Enabled?...................................................889
7.12.2.2 How Does a VRRP Backup Group Track the BFD Session Status?.................................................................. 890
7.12.2.3 How to Identify the Interface That Has Sent Incorrect Packets After a Large Number of TTL Error Log
Messages Are Generated on a Device in a VRRP Backup Group?..................................................................................893
7.12.2.4 Why Is There Only Logs Indicating that a Backup Device Is Switched to a Master Device, but Not Logs
Indicating that a Master Device Is Switched to a Backup Device?..................................................................................895
7.12.2.5 What Are the Formats of Two Types of Packets Sent by VRRP Backup Groups?............................................895
7.12.2.6 How to Determine the Master and Slave Status in a VRRP Backup Group in the Situation Where Two Virtual
IP Addresses Assigned to It Are Two Addresses of Interfaces Configured with the VRRP Backup Group?................. 896
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxii

7.12.2.7 Up to Eight Interfaces on a HUAWEI NetEngine40E/80E Are Tracked by an Unlimited Number of VRRP
Backup Groups, Why?......................................................................................................................................................897
7.12.2.8 How to Negotiate the Master and Backup Status of Devices with the Same Priority but Different IP Addresses
in a VRRP Backup Group?...............................................................................................................................................897
7.12.2.9 How Does Proxy ARP Function When Multiple IP Addresses Are Mapped to One Virtual MAC Address in
ARP Entries?.................................................................................................................................................................... 897
7.12.2.10 How to Distinguish BFD Sessions When a VRRP Backup Group Tracks the Status of BFD Sessions with
Automatically-Negotiated Discriminators?...................................................................................................................... 898
7.12.2.11 Why Cannot a Preemption Delay on a Device Functioning as the IP Address Owner Take Effect?............... 898
7.12.2.12 Can a VRRP Backup Group Be Established by Using a Secondary IP Address?............................................898
7.12.2.13 After an NQA Test Instance Is Deleted, Why Can the Configuration of Associating VRRP with NQA Be Still
Restored?.......................................................................................................................................................................... 898
7.12.3 Eth-OAM............................................................................................................................................................... 899
7.12.3.1 Can EFM OAMPDUs Be Transmitted Between Different VLANs?................................................................. 899
7.12.3.2 Can Ethernet CFM Be Used to Detect Links Between Trunk Member Interfaces?...........................................899
7.12.3.3 What Are the Differences Between 802.1ag MAC Ping and Generic GMAC Ping?........................................ 900
7.12.3.4 Can You List the Advantages and Disadvantages of BFD and EFM OAM?..................................................... 902
7.12.4 NQA.......................................................................................................................................................................902
7.13 User Access.............................................................................................................................................................. 902
7.13.1 What Is the Sequence of Authentication Modes in AAA?.................................................................................... 902
7.13.2 Why Is the User Logged Out Ten-Plus Seconds After the RADIUS Server Becomes Faulty and the User
Alternatively Logs in Through Local Authentication?.....................................................................................................903
7.13.3 Why Is the Log Indicating that the RADIUS Server Is Down Generated When the User Uses a Local Account to
Log in to the router?......................................................................................................................................................... 903
7.13.4 The NE40E&NE80E Controls the Online Time of a User Through the Session Timeout Period Delivered by a
RADIUS Server. Why Does the User Remain Online When the Timeout Period Expires?............................................ 904
7.13.5 PPPoE User Configured on the NE40E&NE80E Fails to Dial Up. RADIUS Debugging Information Shows that
the Authentication Success Message Is Received but No Accounting Packet Is Received?........................................... 904
7.13.6 How Does the NE40E&NE80E Convert RADIUS Attributes?............................................................................ 904
7.13.7 Why Cannot the DHCPv4 Client Obtain an IP Address From the Remote IP Address Pool in the Case that the
BAS and DHCPv4 Server Are Correctly Configured?.................................................................................................... 905
7.13.8 What Address Does the router Use to Send L2TP and RADIUS Packets?...........................................................905
7.13.9 What Is the Process of L2TP Tunnel Authentication?.......................................................................................... 905
7.13.10 If the LNS Is a Device of Huawei But the LAC Is Not, What Should Be Noted During the Configuration of the
LNS?................................................................................................................................................................................. 906
7.13.11 If the LAC Is a Device of Huawei But the LNS Is Not, What Should Be Noted During the Configuration of the
LAC?................................................................................................................................................................................ 906
7.13.12 How Can I Jointly Use L2TP Parameters Set on the router and the RADIUS Server?...................................... 906
7.13.13 What Configurations Are Adopted on the NE40E&NE80E to Arrange Different Users of the RADIUS
Authentication to Be Authenticated by Different LNSs?................................................................................................. 907
7.13.14 When the NE40E&NE80E Functions as an LAC, How Does the NE40E&NE80E Match Primary and Backup
LNSs in the L2TP Group?................................................................................................................................................ 908
7.13.15 Can the NE40E&NE80E Not Authenticate the Tunnel Name of the LAC When Performing Tunnel
Authentication?.................................................................................................................................................................908
7.13.16 If the PPP Authentication Is configured Differently on the LNS and the LAC, Can a User Pass the
Authentication and Join in the VPN?............................................................................................................................... 908
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxiii

7.13.17 Which Interface Does the Device Select to Send RADIUS and L2TP Packets?................................................ 909
7.13.18 Why Do L2TP Users Fail to Pass the Authentication Through Dialup?.............................................................909
7.13.19 Why Cannot 802.1X Authentication Work Together with Web Authentication in Wired Access Whereas This
Can Be Achieved in Wireless Access?............................................................................................................................. 910
7.13.20 Why Cannot the NE40E&NE80E Assign IP Address to PPPoX User Through RADIUS?............................... 910
7.13.21 Which Attributes of the RADIUS Packets Will Change After PPPoE+ Is Deployed?....................................... 910
7.13.22 Why Cannot the PPPoE User Go Online by Dialing Up?................................................................................... 910
7.13.23 What Do the Full Match and Fuzzy Match Mean for the service-name Parameter in PPPoE?.......................... 911
7.13.24 Why Cannot the PPPoX User Obtain an IP Address Through DHCP Server?................................................... 911
7.13.25 Why Cannot the VPN User Pass the Authentication After Dialing In?.............................................................. 911
7.13.26 For the L2TP Access, What Aspects Need We Pay Attention to During the Configuration of the LAC and LNS?
.......................................................................................................................................................................................... 911
7.13.27 On a DHCPv6 Layer 3 Network, a Client Accesses the DHCPv6 Server Through a DHCPv6 Relay Agent. Why
Cannot the Client Get Online Though Configurations of the Relay Agent and DHCPv6 Server Are Correct?.............. 912
7.13.28 What Is the Relationship Between Ordinary L3 Users and Ordinary L2 Users?................................................ 912
7.13.29 Why Cannot Mandatory Web Authentication Be Performed for NE40E&NE80E Users?.................................912
7.13.30 How Can the Static Users and PPP Users, Belonging to the Same VLAN, Access the NE40E&NE80E Through
the Same Port?.................................................................................................................................................................. 912
7.13.31 Why Cannot the Static User Go Online Immediately After Being Disconnected Manually?.............................913
7.13.32 Why Cannot I Open the Web Authentication Page When Entering the URL of Other Websites Except for the
Web Authentication Server URL?.................................................................................................................................... 913
7.13.33 Why It Prompts That the IP Addresses Conflict?................................................................................................913
7.13.34 Why Cannot Super Long Ping Packets Reach the Network Side Through the CAPWAP Channel After a
Wireless User Accesses the Internet?............................................................................................................................... 913
7.13.35 Why Cannot Super Long Ping Packets Reach the Network Side Through the CAPWAP Channel After a
Wireless User Accesses the Internet?............................................................................................................................... 914
7.13.36 Why Do Lots of Users Fail to Pass RADIUS Authentication During Login After Device Upgrade?................914
7.13.37 What May Cause Slow Network Access After Lots of Users Get Online?.........................................................914
7.13.38 Q: Why Cannot Static Users Attached to the NE40E&NE80E Go Online?....................................................... 915
7.13.39 Why Does a DHCP Client Fail to Access the router and Why Is No Failure Cause Available?........................ 915
7.13.40 Why Does a Static User Without Being Assigned an IP Address Automatically Obtain an IP Address from the
Address Pool After Connecting to the Network?............................................................................................................. 915
7.13.41 How to Configure an ACL on the NE40E&NE80E to Make a Group of DHCP Users Communicate with a
Certain Destination Address?........................................................................................................................................... 915
7.13.42 Can Users Accessing the NE40E&NE80E Through Different Interfaces Obtain Addresses from the Global
Address Pool?................................................................................................................................................................... 915
7.14 Video Service............................................................................................................................................................916
7.14.1 Why Are the Packet Loss Statistics Collected by the MDI and No-Reference QoE Algorithms Different?........916
7.14.2 Why Cannot Channels Be Configured on the router?........................................................................................... 916
7.14.3 Why Cannot MDI or VMOS Be Enabled for a VAS Group?................................................................................916
Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxiv

NE Series Router Maintenance Guide 1 Change History
1 Change History
Date Change Remark
2016–06–30 This is the first official released.
Issue 01 (2016-06-30) Huawei Proprietary and Confidential 1

NE Series Router Maintenance Guide 2 Routine Maintenance Items
2 Routine Maintenance Items
About This Chapter
This chapter describes maintenance items, operation guide and expected results during each
maintenance period.
2.1 Backing Up the Configuration File
2.2 Restoring the Configuration Files
2.3 Hardware Operations Involving Risks
This section describes hardware operations involving risks and aftereffects that may be caused
by misoperations.
2.4 Command Executions That Involve Risks
This section describes commands whose executions involve risks and aftereffects that may be
caused by misoperations.
2.5 Commonly Used Commands for Maintenance
This chapter describes the commonly used commands during maintenance.

2.1 Backing Up the Configuration File
Context
A configuration file can be backed up using the following methods.
Procedure
l Directly Copying the File
Run the display current-configuration command on the command line interface and
copy all command outputs into a txt file. In this manner, the configuration file is backed
up into the hard disk of the maintenance terminal.
l Directly copy the configuration file to the CFcard.
You can take the step to copy the current configuration file immediately to the CFcard of
the router. Run the following commands to copy the configuration file to the CFcard of
the router before starting the router:
<HUAWEI> copy vrpcfg.zip cfcard:/backup.zip
Copy cfcard:/vrpcfg.zip to cfcard:/backup.zip?[Y/N]:y
100% complete
Info:Copied file cfcard:/vrpcfg.zip to cfcard:/backup.zip...Done
l Backing Up the File Through TFTP

a. Assign an IP address to the router.
The router functions as a TFTP client.
Connect the router and maintenance terminal to set up a Telnet environment. Assign
an IP address to the interface on the router. Ensure that this IP address and the IP
address of the TFTP server are in the same network segment.
b. Run the TFTP server application program.
Run the TFTP server application program on the PC. Configure the path where the
downloaded file is to be saved, IP address of the TFTP server, and interface
number.
c. Transfer the configuration file.
Run the tftp command with parameters specifying the IP address (10.110.24.209 in
this example) of the TFTP server, operation, and name of the configuration file on
the command line interface.
<HUAWEI> tftp 10.110.24.209 put vrpcfg.zip
Transfer file in binary mode.
Now begin to copy file to remote tftp server, please wait for a
while... \
TFTP: 1503 bytes sent in 1 seconds.
File uploaded successfully.
l Backing Up the File Through FTP

a. Connect the router and maintenance terminal to set up a Telnet environment. Assign
an IP address to the interface on the router.
b. Enable the FTP service.
The router functions as an FTP server.

Enable the functions of the FTP server. Create an FTP user with the username as
huawei and password as Huawei@123. The user is authorized to access
"cfcard:/".
<HUAWEI> system-view
[HUAWEI] ftp server enable
[HUAWEI] aaa
[HUAWEI-aaa] local-user hello@163.com password irreversible-cipher
%TGB6yhn7ujm
[HUAWEI-aaa] local-user hello@163.com service-type ftp
[HUAWEI-aaa]local-user hello@163.com level 3
[HUAWEI-aaa] local-user hello@163.com ftp-directory cfcard:/
c. On the maintenance terminal, initiate an FTP connection to the router.
Set up an FTP connection on the PC with the router through the FTP client. Assume
that the IP address of the router is 10.110.24.254.
C:\Documents and Setting\Administrator> ftp 10.110.24.254
Connected to 10.110.24.254.
220 FTP service ready.
User (10.110.24.254:(none)): huawei
331 Password required for hello@163.com.
Password:
230 User logged in.
d. Configure transfer parameters.
If the FTP user passes the authentication, the FTP client displays the prompt
character of "ftp>". Enter binary following the prompt character. Then, specify the
path where the uploaded file is to be saved on the FTP client.
ftp> binary
200 Type set to I.
ftp> lcd c:\temp
Local directory now C:\temp.
e. Transfer the configuration file.
On the PC, run the get command to download the configuration file to the specified
path and save the file as backup.zip.
ftp> get vrpcfg.zip backup.zip
200 Port command okay.
150 Opening ASCII mode data connection for vrpcfg.zip.
226 Transfer complete.
ftp: 1021 bytes received in 0.06Seconds 60.02Kbytes/sec.
ftp>
----End
2.2 Restoring the Configuration Files

You can restore the configuration files through the following ways.
NOTE
After restoring the configuration files, reset the router to make the configuration files take effect.
Recovering the Configuration Files Saved in the CF Card Memory

This action is to restore the configuration files saved in the CF card memory of the router as
the configuration files of the current system.

Run the following commands when the router works normally.

<HUAWEI> copy backup.zip CFcard:/vrpcfg.zip
Copy CFcard:/backup.zip to CFcard:/vrpcfg.zip?[Y/N]:y
100% complete
Info: Copied file CFcard:/backup.zip to CFcard:/vrpcfg.zip...Done
Recovering the Configuration Files Saved in the PC Through TFTP

This action is to restore the configuration files saved in the PC as the configuration files of the
current system.
The router works as the TFFP client. The restoration procedure is similar to that for backing
up the configuration files through TFTP. Run the tftp get command to download the
configuration files saved in the PC to the CF card memory of the router.
Recovering the Configuration Files Saved in the PC Through FTP

This action is to restore the configuration files saved in the PC as the configuration files of the
current system.
The router acts as the FTP server. The restoration procedure is similar to that for backing up
the configuration files through FTP. Run the ftp put command to upload the configuration
files saved in the PC to the CF card memory of the router.
2.3 Hardware Operations Involving Risks

This section describes hardware operations involving risks and aftereffects that may be caused
by misoperations.
Table 2-1 lists the hardware operations that involving risks.
NOTICE
The operations listed below have to be performed with caution.

Table 2-1 Hardware operations involving risks

Item Sub-item Aftereffects that may be
caused by misoperations
Operations on Hot swapping the master main l When the standby main
boards control board is prohibited control board runs normally,
data backup from the master
board to the standby one
requires a certain period. In
this case, the latest data on the
main control board cannot be
backed up entirely to the
standby board. Therefore,
removing the in-service master
control board may result in
incorrect statistics and data
loss.
l When the standby main
control board fails to run,
removing the in-service master
board may result in interrupt
of partial or even global
services.
l If a device has been recently
started and an MPU is
removed before LPUs register,
the LPUs fail to automatically
upgrade and must be manually
upgraded using the BootROM
and BootLoad.
Operations on Pressing the Reset button on the l If you press the Reset button
boards main control board is not allowed, on the panel, the board is
unless otherwise required. forced to reset the hardware.
This operation can be carried
out only by qualified
personnel in case that a fatal
fault occurs in the system.
l If the Reset button on the
panel is pressed by mistake,
the main control board will be
reset. Its results are the same
as those of removing the in-
service master control board.
Operations on Pressing the OFL button is not If you press the OFL button, the
boards allowed, unless otherwise board is powered off and the
required.. service is interrupted.

Item Sub-item Aftereffects that may be

Operations on Inserting and removing boards l Electrostatic on human body

boards without wearing ESD wrist strap does great harm to electrical
are prohibited parts on the board.
l If the maintenance personnel
insert and remove boards
without wearing ESD wrist
strap, the board may be
damaged or not run stably.
Operations on Debugging the Console with the Only Huawei professional

boards Console cable is prohibited engineers can use the debugging
Console; otherwise, abnormality
of board running or board
resetting may be caused.
Operations on Hot swapping the CF card is When the CF card is reading or

the CF card prohibited writing data, hot swapping the CF
card may cause abnormity of the
operating system. That is resetting
caused by infinite loop or loss of
heartbreak of the main control
board on which the CF card is on.
Operations for Plugging in and plugging out the l The network cables inside the
cable network cables inside the cabinet cabinet are used for
are not allowed, unless otherwise communication between the
required. host and the terminal.
l Plug-in and plug-out of the
cables inside the cabinet may
make the terminal fail to log
on to the router.
Operations for Operating the power supply in the l The maintenance personnel
power supply power distribution frame of the can operate the power supply
cabinet is prohibited based on the guide only in the
case of upgrading, expansion,
parts replacement or fatal
faults.
l Operations may cause fatal
faults such as shut-down of the
device and interruption of the
services.
2.4 Command Executions That Involve Risks

This section describes commands whose executions involve risks and aftereffects that may be
caused by misoperations.

NOTICE
The commands given below can be used only by the qualified and trained personnel.
Table 2-2 Command executions that involve risks

Classification Command Function Aftereffect that may be
Reboot reboot Rebooting the This command can be used only

system in the case of office deployment
or upgrading; otherwise, the
services carried over the device
will be interrupted.
Format formatdevice- Formatting the Using this command may cause

name storage device loss of all the files on the
specified storage device and the
files cannot be restored.
Delete delete [ / Deleting the This command is used to delete

unreserved ] specified files the specified files in the storage
{ filename | in the storage device of the router. If you use
cfcard: } device unreserved when deleting files,
delete [ / the files cannot be restored.
unreserved ]
{ filename |
cfcard: }
delete [ /
unreserved ]
[ /quiet ]
{ filename |
device-name }
User interface authenticatio Authenticating When setting user authentication

n-mode the logon users on the Console and VTY user
interface, if the mode is password
or AAA, you have to set the
password or the user name to log
on to the router.

Classification Command Function Aftereffect that may be

System startup Setting the In the active/standby mode, set

maintenance system- large file for the large files for next startup at
software next startup the same time on the active and
standby main control board.
Otherwise, the router will restart
continuously.
In the active/standby mode, set
the large files for next startup at
the same time on the active and
standby main control board.
Otherwise, the router will restart
continuously.
-
System upgrade Upgrading a Using this command to upgrade

maintenance board the software or the logical file of a
board will interrupt the services.
System power off slot Powering off a Using this command will power
maintenance board off a board and interrupt the
services.
System reset slot Restarting a Using this command will restart

maintenance board the specified board.
2.5 Commonly Used Commands for Maintenance

This chapter describes the commonly used commands during maintenance.
Table 2-3 shows the commonly used commands for maintenance.
Table 2-3 Commonly used commands for maintenance

Command Function
dir [ /all ] [ filename ] Displays the information on the specified

file or directory in the storage device of
the router.
display alarm { slot-id | all | active |history | Displays alarms.

information name alarm-name }
display bgp [ vpnv4 vpn-instance vpn- Displays BGP peer.

instance-name ] peer [ { group-name | ipv4-
address } log-info | [ ipv4-address ] verbose ]
display bgp vpnv4 all peer [ [ ipv4-address ]
verbose ]

Command Function
display clock [ utc ] Displays the information on the output

port of the interface board reference
source and the attributes of the clock
reference source.
display cpu-usage [ configuration ] [ slave | Displays the statistics and configurations

slot slot-id [ vcpu vcpu-number ]] of CPU usage.
display cpu-usage [ task-name ] [ slave | slot
slot-id ]
display current-configuration Displays the valid parameters of the

[ configuration [ configuration-type router.
[ configuration-instance ] ] | controller |
interface interface-type [ interface-number ] ]
display fan Displays the status of the fan.
display fib [ slot-id ] statistics Displays the total number of the FIB
entries.
display device [ pic-status | slot-id ] Displays the basic information about the
router.
display [ ipv6 ] ftp-server Displays the parameters of the FTP server

in use.
display interface [ interface-type [ interface- Displays the running status and statistics
number ] ] of an interface.
display ip interface [ interface-type Displays IP-related configurations and

interface-number ] statistics of an interface such as the
packets transceived, bytes, multicast
packets, and broadcast packets received,
sent and discarded.
display ip interface brief [ slot slot-number Displays IP-related brief information of an

[ card card-number ] | [ interface-type interface such as the IP address, status of
[ interface-number ] ] the physical link and protocol, and the
description of the interface.
display ip routing-table Displays the brief information of IPv4

routing table.
display isis peer [ verbose ] [ process-id | Displays the IS-IS peer relationship.
vpn-instance vpn-instanc-name ]
display local-user Displays the attributes of local users.

Command Function
display logbuffer [ size value | slot slot-id | Displays the record in the log buffer.
module module-name |level { severity |
emergencies | alerts | critical | errors |
warnings | notifications | informational |
debugging } ]*
display logbuffer summary [ level severity |
slot slot-id ]*
display memory-usage [ slave | slot slot-id | Displays the CPU usage of the router.
threshold [ slot slot-id ] ]
display ospf [ process-id ] brief Displays the brief information of OSPF.
display ospf [ process-id ] peer [ [ interface- Displays OSPF neighbors.

type interface-number ] neighbor-id | brief |
last-nbr-down ]
display patch-information Displays the status of the patch.
display power Displays the status of power supply.
display saved-configuration [ last | time | Displays the configuration files for next
configuration ] startup of the router.
display startup Displays the system software and the

configuration files related to the current
and next startup.
display switchover state Displays the backup status of the active/

standby board.
display temperature slot slot-id Displays the status of the slot temperature
transducer.
display trapbuffer [ size value ] Displays the record in the alarm buffer.
display voltage slot slot-id Displays the status of the voltage

transducer in the specified slot.
display version Displays the version of system software.
ping [ ip ] [ -a source-ip-address | -c count | - Displays IP network connection and

d | -f | -h ttl-value | -i interface-type interface- whether the host is reachable.
number } | -m time | -n | -p pattern | -q | -r | -s
packetsize | -t timeout | -tos tos-value | -v | -
vpn-instance vpn-instance-name ] * host
tracert [ -a source-ip-address | -f first-TTL | - Tests the gateways through which the

m max-TTL | -p port | -q nqueries | -vpn- packets pass from the host to the
instance vpn-instance-name | -w timeout ] * destination and checks the network
host connection to locate the faults.

NE Series Router Maintenance Guide 3 Emergency Maintenance Guidelines
3 Emergency Maintenance Guidelines
About This Chapter
This chapter guides you how to perform emergency maintenance.

3.1 Guide to Collecting Fault Information
This section guides you how to collect and back up fault information as the reference for
troubleshooting.
3.2 Guide to Handling Emergencies
This section guides you how to handle emergencies.
3.3 Guide to Restarting a Device
This section guides you how to restart a device when a fault on the device causes services to
be interrupted and the device fails to restart automatically.
3.4 Built-in System Software Is Incorrect or Does Not Exist
Incorrect or no system software was delivered along with the device. You need to copy the
correct system software through cfcard2 (located on the panel of the MPU/SRU). You can
also load the system software through the BootROM.
3.5 Guide for Creating a User Account and Elevating a User Account Right

3.1 Guide to Collecting Fault Information

This section guides you how to collect and back up fault information as the reference for
troubleshooting.
When an emergency occurs, you need collect and back up fault information on time for
reference. When seeking Huawei technical support, you need provide the collected
information to Huawei engineers for fault location and rectification.
When a fault occurs, collect the following information:
l Basic fault information
l Device fault information
3.1.1 Collecting Basic Fault Information

This section describes what items need to be collected and how to collect basic fault
information.
Table 3-1 lists the basic fault information to be collected when a fault occurs.
Table 3-1 Basic fault information table

No. Item Collection Method
1 Occurrence time Record the time when the fault occurs. The value should
be accurate to a minute.
2 Fault symptom Collect the fault symptom and maintain detailed records.
3 Fault severity level Record the fault severity level according to the range and
the severity of the fault.
4 Software version Collect information about the software version on

console through the display version command when you
can log in to the device through Telnet or the serial
interface.
5 Networking Draw a networking diagram showing upstream and

information downstream devices and the peer interfaces.
6 Taken measures Record the measures that have been taken and the
results.
NOTE
When collecting fault information through command lines, you can copy the information displayed on
the console, such as the serial interface or the Telnet terminal, and then attach it to a txt. file for a record.
3.1.2 Collecting Device Fault Information

This section describes what items need to be collected and how to collect the device fault
information.

When a fault occurs and you can log in to the device through Telnet or the serial interface,
collect the following information.
Table 3-2 Fault information table
1 Device information Run the display device command to collect the device
information.
2 Temperature Run the display temperature command to collect the

temperature information.
3 CPU usage Run the display cpu-usageslotslot-id command to

collect the CPU usage information.
4 Routing table Run the display ip routing-table command to collect

information the routing table information.
5 Log information Run the display logbuffer command to collect the log
information.
6 Alarm information Run the display trapbuffer command to collect the

alarm information.
7 Configuration Run the display current-configuration command to

information collect the configuration information.
8 Diagnostic Run the display diagnostic-information file-name

information command to collect the diagnostic information.
NOTE
By default, running the display diagnostic-information file-
name command saves the device's diagnostic information to the
file with a specified filename in Cfcard:/.
9 Interface information Run the display interface command to collect the

interface information.
10 Network connectivity Run the ping command to collect information about the
information network connectivity and record the results.
NOTE
When a device runs normally, you are recommended to back up the historical traps and logs in the CF
card through the Trivial File Transfer Protocol (TFTP) or File Transfer Protocol (FTP). For detailed
operations, refer to the HUAWEI NetEngine40E/80E Router Configuration Guide - Basic Configuration.
3.2 Guide to Handling Emergencies

This section guides you how to handle emergencies.
3.2.1 Failed to Log in to the System Through the Serial Interface

Fault Symptom
After the serial interface of a PC or a terminal is connected to the console interface of the
NE40E&NE80E through the standard RS-232 configuration cable and the relevant parameters
are set, nothing is displayed on the terminal.
Fault Information Collection

If you are unable to log in to the system through the serial interface, collect the following
information besides the generic information described in the Chapter "3.1 Guide to
Collecting Fault Information" for future reference.

1 Communications Check whether the communication parameters set for

parameters of the the software such as Windows-based HyperTerminal for
serial interface the communication between serial interfaces are
consistent with the communication parameters set on
the console port of the NE40E&NE80E, such as the
bard rate, data bit, parity check or not, stop bit, and flow
control or not.
2 Indicator status Check the status of the following indicators:

l RUN, ALM, LINK, and ACT indicators of the
MPU/SRU
l PWR IN, PWR OUT, and ALM indicators of the
power modules
l RUN and ALM indicators of the fans

Processing Procedure
Figure 3-1 Flowchart of solving the problem that users cannot log in to a system through the
serial interface
Start
Does No Repair the Yes

Is the fault
the power module power supply
rectified?
work normally? system
Yes No
No Yes
Is the cable in Replace the Is the fault
good condition? cable rectified?
Yes No
Are No
Is the fault Yes
parameters for the Modify the
serial interface parameters rectified?
correct?
Yes No
Does No Exchange or
Is the fault Yes
the MPU/SRU work replace the
rectified?
normally? MPU/SRU
Yes No
Is the fault Yes

Reset the system
rectified?
Seek technical
End
support
NOTICE
All the following steps are performed only when the customer's services are already
interrupted, and therefore have no adverse effect on services. If the customer's services are not
interrupted, collect fault information and provide it to Huawei engineers for further
processing.

Procedure
Step 1 Check and repair the power supply system.
When you find that the indicators of all the boards are off and all the fans fail to work (which
can be identified by fan's rotating), or the indicator of the power module is abnormal, the
power supply system of the device is possibly faulty and need repairing. The power supply
system consists of the following:
l Power supply system of the equipment room, chassis, or cabinet
l Power module
l Power supply system of the backplane
You can solve the problem according to the steps:
1. Check whether the power module is switched on. When there are multiple power
modules, ensure that at least one works normally.
2. Check whether the PWR IN indicator of the power module is on. If not, it can be
concluded that the power input of the power module is abnormal. You can use tools such
as a multimeter to check the power supply of the equipment room, chassis, and cabinet.
If the power supply is abnormal, ask electricians for help.
3. Check whether the PWR OUT indicator of the power module is on. If not, it can be
concluded that the power output of the power module is abnormal. You can replace the
power module to solve the problem.
4. Check whether the ALM indicator of the power module is on. If so, it can be concluded
that the power module is faulty. You can replace the power module to solve the problem.
5. When none of the preceding problems is found, but the power supply system fails to
work, seek Huawei technical support according to Technical Support.
Step 2 Check and replace the cable.
Check whether the cable is in good condition. You can replace the cable with a new one to
check that you can normally log in.
Step 3 Check parameters of the serial interface.
Check whether parameters set for the serial interface are identical with those for the console
interface on the NE40E&NE80E. If they are not identical, modify the parameters of the serial
interface.
By default, set the baud rate of the console interface on the NE40E&NE80E to 9600 bit/s,
data bit to 8, stop bit to 8 1, and parity check and flow control to none. When the parameters
of the console interface are modified, adopt the modification.
Step 4 Exchange and replace the MPU/SRU.
If the serial interface, cable, power supply system are normal, the problem may be caused by
the fault on the MPU/SRU. When two MPUs/SRUs are installed in the system, try to press
and hold the OFL button for about 6s till the OFL indicator is on before removing a board.
And insert the terminal of the cable into the console port of the slave MPU/SRU; when there
is only one MPU/SRU, you can replace it with a spare one.
Step 5 Reset the system.
If the fault persists after the preceding steps are performed, you can reset the system by
switching off the power module and then switching it on three minutes later to solve the
problem. For details, see 3.3 Guide to Restarting a Device.

Step 6 Seek Huawei technical support.

If the fault persists after the preceding steps are performed, you can seek Huawei technical
support according to "Technical Support."
----End
3.2.2 Failed to Start the System
Fault Symptom
The system is failed to be started and the prompt may be displayed on the terminal as follows:
l "The SDRAM testing.........FAIL!", which indicates that the self-test of memory fails.
l "XXXXX selftest.........FAIL!", which indicates that the self-test of a certain module
fails.
l The system remains in the phase of file decompression for a long time.
l The system is repeatedly restarted.

If you are unable to start the system, collect the following information besides the generic
information described in the chapter "3.1 Guide to Collecting Fault Information" for future
reference.

1 System startup Copy system startup information on the console such as

information the serial interface or Telnet terminal to a .txt file for
storage.
2 Name of the startup Check the name of the startup file through the Basic
file Input/Output System (BIOS) menu.

Figure 3-2 Flow chart of solving the problem that the system cannot be started
Start
Is the No Repair the Yes

Is the fault
power module work power supply
rectified?
normally? system
No
Yes
Yes Remove and Yes

Is the memory self- Is the fault
insert the
check failed? rectified?
memory bar
No
No Replace the Is the fault Yes

memory bar rectified?
No
Is the Yes Debug and Yes

Is the fault
module self-check replace the
rectified?
failed? MPU/SRU
No
No
Is the file Yes Re-upload the Yes

Is the fault
decompression startup file
rectified?
failed? through BIOS
No No
Make the
Is the Yes startup files of
Is the fault Yes
system repeatedly the master and
rectified?
restarted? slave MPUs/
SRUs identical No
No
Seek technical
End
support
NOTICE
interrupted, do not perform the following steps. Instead, collect fault information and feed it
back to Huawei engineers for further processing.

Procedure
Step 1 Check and repair the power supply system.
can be identified by fan's rotating), or the indicator of the power module is abnormal, the
l Power module
Step 2 Insert and remove the memory bar.
When the system displays "The SDRAM testing.........FAIL!", the memory bar is possibly
loose or is incorrectly inserted (only when there is a single memory bar). You can try the
following operations to solve the problem:
1. Remove the MPU/SRU.
2. Remove the memory bar and then re-install it. When there is only one memory bar,
check whether it is inserted in slot 1. If so, remove it and then insert it in slot 0.
NOTE
Figure 3-3 shows how the memory bar slots on an MPU/SRU are numbered. When two memory
bars are inserted on the MPU/SRU. The memory slot close to the panel is slot 2, and the one close
to the CPU is slot 1.

Figure 3-3 Memory bar slots on an MPU/SRU
3. Re-insert the MPU/SRU.
Step 3 Replace the memory bar.

If the problem cannot be solved by removing and re-insertion of the memory bar, the memory
bar is possibly faulty. You can replace the memory bar with a new one of the same
specification. For the type and specification of memory bars, contact Huawei technical
support personnel.
Step 4 Exchange and replace the MPU/SRU.

When the system prompts "XX XXX selftest.........FAIL!", or the memory self-test still fails
after you perform Steps 1 and 2, the MPU/SRU is possibly faulty. When two MPUs/SRUs are
installed in the system, try to press and hold the OFL button for about 6s till the OFL
indicator is on before removing a board. And insert the terminal of the cable into the console
port of the slave MPU/SRU; when there is only one MPU/SRU, you can replace it with a
spare one.
Step 5 Upload the startup file through BIOS again.

When the system remains in the phase of file decompression or is repeatedly restarted, the
startup file is possibly incorrect or damaged. You can try to upload the startup file through
BIOS.

Seek Huawei technical support according to "Technical Support."
----End
3.2.3 Status of Hardware Components Is Abnormal
Fault Symptom
Hardware components refer to hardware modules including board modules, power supply
modules, and fan modules. The abnormality of hardware component status includes (one or
multiple items):

l When you run the display device command in any view to view information about a
hardware component where services are interrupted, the hardware component status is
Abnormal.
l When you run the display device command in any view to view information about a
hardware component where services are interrupted, the hardware component status is
Unregistered.
l The RUN or STATUS indicator of a hardware component blinks or is off, or the ALM
indicator of the hardware component is on.

When you find that the status of the hardware component is abnormal, collect the following
information besides the generic information described in the Chapter "3.1 Guide to
Collecting Fault Information" for future reference.

1 Indicator status of a Check that the status of the indicator on a hardware

hardware component component is off, on, blinking quickly, or blinking
slowly. Observe whether the RUN and ALARM
indicators of the fan modules and power supply modules
are normal. Normally, the RUN indicator is green and the
ALARM indicator is off.
2 Detailed information Run the display device slot-id command in any view to
about a hardware view detailed information about the specified hardware
component component.
3 Status of a PIC Run the display device pic-status command in any view
channel to collect information about the status of a PIC channel.

Figure 3-4 Flow chart of solving the problem that the hardware component status is abnormal
Start
Reset the component
Yes Is the fault

rectified?
No
Replace the component
No Cut over the services

Is the fault
on the board and seek
rectified?
technical support
Yes
End
NOTICE
Procedure
Step 1 Reset the hardware component.
The processing of the hardware component abnormality is complex.
can be identified by fan's rotating), or the ALM indicator of the power module is on, the

l Power module

If the abnormality occurs on the fan modules, directly replace the fan modules.
If a board is abnormal and the situation is urgent, reset and replace the board. Relevant cause
location will be performed by Huawei technical support personnel.
You can reset a board by using the reset slot slot-id command in the user view, pressing the
RESET button on the panel, or pulling out and inserting the board.
NOTE
You are recommended not to pull out and insert in the board for resetting. This can avoid damages on
the board.
Step 2 Replace the hardware component.

When the problem cannot be solved by resetting the hardware component, you can try to
replace the hardware component with a spare one.
Step 3 Cut over services on the board and seek Huawei technical support.
When the preceding methods cannot solve the problem, you can cut over services on the
faulty board to a normal board or a board in an vacant slot. For operation details, contact
Huawei technical support personnel or comply with your cutover scheme.
In addition, report the fault information to the local Huawei office for technical support.
----End
3.2.4 Interface Status Is Abnormal
Fault Symptom
The abnormality of the interface status includes:
l When the display interface [ interface-type interface-number ] command is run in any
view to check an interface where services are interrupted, the interface status is Down.
view to check an interface where services are interrupted, the number of packets
transmitted on the interface remains unchanged.
view to check the interface where services are interrupted, a large number of CRC
packets are received.

l The indicator status of an interface is abnormal. For example, the LINK indicator of the
interface is off.

When you find the interface status is abnormal, collect the following information besides the
generic information described in the chapter "3.1 Guide to Collecting Fault Information"
for future reference.

1 Indicator status of an Check whether the indicator (LINK/ACT) on a faulty

interface interface is off, on, or blinking. If the indicator is on, the
link is Up. If the indicator is blinking, the data is being
received or transmitted. If the indicator is off, the link is
Down.
2 Detailed information Run the display interface [ interface-type interface-

about an interface number ] command in any view to collect detailed
information about an interface.
3 Brief IP-related Run the display ip interface brief [ interface-type

information about an interface-number ] command in any view to collect brief
interface IP-related information about an interface.
4 Brief information Run the display interface brief command in any view to
about all interfaces collect brief information about all interfaces.

Figure 3-5 Flow chart of solving the problem that the interface status is abnormal
Start
Status
of interface Proceed to the
Yes
indicator flow for handling
normal? service faults
No
Interface No Yes
status Is manually Shut up the
shut down? interface
is Up?
No
Yes Yes
Fault
Detect the link End
rectified?
Packets are No Perform Cut over

transeived a local No
theservices
normally? loopback test on the
board and
Yes
Check and modify the seek board
Reset the No Is the status Yes configuration of the and seek
interface normal? data link layer or the support
upper layer protocol
Fault No
rectified?
Yes
End
NOTICE
NOTE
Usually, the interface fault is caused by the problem of the cable or optical module.
l When the cable is broken or the optical module is damaged, the interface fails to go Up.
l When the cable or optical module on an interface has been being used for many years, the signal
attenuation may be severe. In this case, although the interface is Up, a large number of packets are
discarded.
Replace the cable or optical module on the faulty interface. If the problem persists, perform the
following operations.

Procedure
Step 1 Start the interface manually.
Run the display this in the interface view to check the configuration files of the faulty
interface. If you find that an interface is shut down through the shutdown command, run the
undo shutdown command in the interface view to start it.
Step 2 Check the link and rectify the link fault.
Before checking a link, check whether the LINK indicator of the interface is on.
If so, it indicates that the physical link is Up and you can detect the link as follows:
1. Run the display this interface command in the interface view to check whether the
interface parameters at both ends of the link are identical, such as the duplex mode and
rate.
2. In the case of optical interfaces, use the optical power meter to check whether the
receiving and sending optical signals at both ends are normal. If it is not convenient to
use the optical power meter, you can use the optical power detecting function in the
optical module: run display this interface in the error interface and compare the
parameters in the display information with the optical module parameters, and check
whether the power of the send or receive optical signals are in normal range. If optical
interfaces only send or receive optical signals, the optical module is possibly faulty or
the optical fiber does not match the optical module. Then, you can try to replace the
optical module or the optical fiber.
3. If the interface is an electric interface, observe the pinouts in the RJ-45 connectors on
both ends of the case to check whether the cable should be straight-through or crossover
cable for the specified interface.
DANGER
When you check the receiving and sending of optical signals, do not look into the optical fiber
without eye protection. You must use the optical power meter to measure the optical power.
When the LINK indicator of the interface is off, you can check the link as follows:
1. Perform a physical loopback test on the device. That is, connect the faulty interface to an
interface is in the normal state through an optical fiber or cable in good condition. Pay
attention to the two interfaces' type should match with each other.
2. If the LINK indicator is on, it indicates that the interface is normally. In this situation,
you need to check whether the optical fiber or cable is damaged and the trunk link runs
normally. Usually, you need to check the optical fibers, cables, and trunk links at the
neighboring sites.
3. If the LINK indicator is off, it indicates that the interface hardware is faulty. When a
pluggable optical module is used, you can replace the optical module; otherwise, cut
over services on the faulty interface to other interfaces in the normal state.
Step 3 Conduct a local loopback test.
When the interface status is Up, but the number of packets transmitted on the interface
remains unchanged during a specified period, it indicates that the interface can neither receive
nor send any packets. In this situation, you can run the loopback local command on the
interface to perform a local loopback test and then run the ping command to initiate a data

transmission test to check whether the number of packets changes. After the local loopback
test is complete, run the undo loopback command to disable the local loopback.
NOTE
The procedures of testing the receiving and sending of packets through the ping command in Ethernet
interfaces are as follows:
1. Run the arp static ip-address mac-address command in the system view to construct an IP address
on the same segment with the faulty interface and a MAC address in the local ARP table. You can
select the MAC address at will, but it cannot be the local MAC address, a broadcast or multicast
address. The feature of broadcast or multicast address is: the 8th bit of MAC address is 1.
2. Run the ping command in the view of the faulty interface ( it does not matter that ping succeed or
failed. ) to send a certain number of ping packets to the constructed IP address.
3. Run the display this interface command in the view of the faulty interface to check whether the
number of received and sends packets are correct. Because the ARP is just configured, the first ping
may discard a few packets. Ping for the second time, the number of received and sent packets will
equal. If so, the local loopback test is successful and this indicates that the local interface is normal.
4. Run undo arp static command to delete the MAC address, and run undo loopback command in the
interface view to disable the local loopback.
The above operation can only locate a faulty interface. If the interface is OK, maybe the optical module
is faulty. You can location optical module faulty as follows: connect the RX and TX ports of optical
module with two ends of an optical fiber, and run undo shutdown in interface view to test the receiving
and sending of packets again.
Step 4 Check and modify the data link layer or upper layer protocol.
If the interface still fails to send and receive packets in the local loopback test, check the data
link layer or upper layer protocol. For example, check whether the Point-to-Point Protocol
(PPP) or the High level Data Link Control (HDLC) protocol at both ends is identical and the
routing protocol runs normally.
Step 5 Reset the interface.

If the fault persists after the preceding steps are performed, you can reset the interface to solve
the problem.
Run the shutdown command to disable the interface, and then run the undo shutdown
command to enable the interface to reset the interface.

Seek Huawei technical support according to Technical Support.
----End
3.3 Guide to Restarting a Device

This section guides you how to restart a device when a fault on the device causes services to
be interrupted and the device fails to restart automatically.
When a critical fault occurs on the NE40E&NE80E during the equipment running, the
NE40E&NE80E is automatically restarted. After the restart, the NE40E&NE80E runs
normally. The NE40E&NE80E needs to be restarted manually only in emergency or
exception, for example, services are interrupted because of the fault occurred on the
NE40E&NE80E, and the NE40E&NE80E fails to automatically restart or recover by using
other methods.

3.3.1 Preparations for the Restart

This section describes the preparations for the restart of the NE40E&NE80E.
Before restarting the NE40E&NE80E, confirm whether configuration files of the
NE40E&NE80E need to be backed up. Configuration files should be backed up and executed
automatically after the restart. In this case, services can be automatically resumed.
For the backup and restoration of configuration files, refer to "Guide to Emergency
Maintenance" in the Chapter HUAWEI NetEngine40E/80E Router - Routine Maintenance.
3.3.2 Guide to Restarting the NE40E&NE80E

This section describes procedures and precautions of restarting the NE40E&NE80E.
NOTICE
The MPU/SRU is not hot swappable. Therefore, do not plug out and plug in the MPU/SRU in
service. Boards of other types are hot swappable.
You can restart the NE40E&NE80E in any of the following methods:

l Running the reboot command
l Running the schedule reboot command
l Switching the system off and then on
l Operating through the NMS
NOTE
You are recommended not to restart the NE40E&NE80E remotely. Otherwise, once the restart operation
fails, services may be interrupted for a long period.
Checking Whether Configuration Files Are Correct

Run the display startup command to check whether configuration files are correct. For
example:
<HUAWEI> display startup
MainBoard:
Configed startup system software: cfcard:/V600R009C10.cc
Startup system software: cfcard:/V600R009C10.cc
Next startup system software: cfcard:/V600R009C10.cc
Startup saved-configuration file: cfcard:/vrpcfg.zip
Next startup saved-configuration file: cfcard:/vrpcfg.zip
Startup paf file: cfcard:/paf.txt
Next startup paf file: cfcard:/
paf_V600R009C10.txt
Startup license file: cfcard:/license.txt
Next startup license file: cfcard:/
license_V600R009C10.txt
Startup patch package: NULL
Next startup patch package: NULL
SlaveBoard:


paf_V600R009C10.txt
The displayed "vrpcfg.zip" denotes the name of the current configuration file.
Running the reboot Command

Before manually restarting the NE40E&NE80E, run the reboot command on the
configuration terminal.
Enter the reboot command in the user view and press Y after the display to restart the
NE40E&NE80E. The operation example is as follows:
<HUAWEI> reboot
Master mpu:
Paf: V600R009C10
License: V600R009C10
Slave mpu:
Paf: V600R009C10
Info:The system is now comparing the configuration, please wait.

Info:Save current configuration?[Y/N]:
NOTE
The reboot command output varies with system versions. Take the command output of the current
system version as the standard.
Running the schedule reboot Command

The schedule reboot command is run in the user view and has two modes, namely, schedule
reboot delay and schedule reboot at.
l The schedule reboot delay command is used to enable the scheduled reboot function
and set the wait delay for the NE40E&NE80E.
The wait delay set for the scheduled restart of the NE40E&NE80E can be expressed in
two formats: "hour: minute" and "absolute minutes". The total minutes cannot be greater
than 30 x 24 x 60 minutes.
l The schedule reboot at command is used to enable the scheduled restart function and set
the specific restart date and time for the NE40E&NE80E. Note that the specified date
cannot be 30 days later than the current date.
If the schedule reboot at command sets a specific date (yyyy/mm/dd) and the date is a
future date, the NE40E&NE80E is restarted at the set time and the error is within 1
minute. If no specific date is set, the following situations occur:
– If the set time is later than the current time, the router is restarted at this time that
day.
– If the set time is earlier than the current time, the router is restarted at this time the
next day.

After the schedule reboot delay or schedule reboot at command is run, the system prompts
you to confirm the restart. Enter Y or y, and the configuration takes effect. If the related
configuration exists, the latest configuration overrides the previous one.
NOTE
If you adjust the system time through the clock command after running the schedule reboot delay or
schedule reboot at command, the parameter set through the schedule reboot delay or schedule reboot
at command becomes invalid.
You can run the undo schedule reboot command to remove the parameter set through the
schedule reboot delay or schedule reboot at command.
You can run the display schedule reboot command to view the parameter set through the
schedule reboot delay or schedule reboot at command.
Operating Through the NMS

The operation for restarting the NE40E&NE80E differs for different type of NMS. For detail,
refer to the NMS Online Help.
3.3.3 Verification After the Restart

This section describes how to verify the device after the restart.
NOTICE
After the NE40E&NE80E is restarted, check that the configuration data is recovered correctly
and completely. The loss of configuration data will result in the service interruption and you
are therefore required to manually add the configuration data and save it.
Verifying the Restart Information

If you log in to the NE40E through the console interface and restart the NE40E by running the
reboot command, the display on the configuration terminal after the restart is as follows:
<HUAWEI> reboot
mpu 9:
Paf: V600R009C10
Info:The system is now comparing the configuration, please wait.
Warning: All the configuration will be saved to the configuration file for the n
ext startup:cfcard:/vrpcfg.zip, Continue?[Y/N]:y
Now saving the current configuration to the slot 9 ..
Save the configuration successfully.
System will reboot! Continue?[Y/N]:y
*************************************************************
* Copyright 2000-2009 Huawei Tech. Co., Ltd. *
*************************************************************
Board Name ....................................... CR52SRUA
SDRAM Size ....................................... 1024MB
Enable the instruction cache ..................... pass!
Disable the data cache ........................... pass!
Disable the ECC................................... pass!
The sdram data bus walk 1 testing ................ pass!
The sdram data bus walk 0 testing ................ pass!
The sdram address bus walk 1 testing ............. pass!

The sdram address bus walk 0 testing ............. pass!

Press CTRL+T to start sdram full test in 01 seconds!
The SDRAM ECC initializing ....................... pass!
Now begin to initialize system
Cache library initializing........................ pass!
Exception vectors initializing.................... pass!
The host bridge initializing...................... pass!
Page table initializing........................... pass!
CPU initializing.................................. pass!
Console device initializing....................... pass!
PCI scanning...................................... pass!
L2 cache initializing............................. pass!
Wind kernel configuration initializing............ pass!
Instruction cache initializing.................... pass!
Data cache initializing........................... pass!
MMU initializing.................................. pass!
System clock initializing......................... pass!
I/O and file system initializing.................. pass!
TTY devices creating and initializing............. pass!
Standard input/output/error device setting........ pass!
Exception show routines initializing.............. pass!
Exception handling installing..................... pass!
Log task initializing............................. pass!
WDT starting...................................... pass!
PHYs resetting.................................... pass!
MUX devices initializing.......................... pass!
Now begin to test key chips
The serial port testing .......................... pass!
The bridge register testing ...................... pass!
The bridge internal sram(256K Bytes) testing ..... pass!
The epld1 testing ................................ pass!
The epld2 testing ................................ pass!
The main boot ROM and backup boot ROM comparing .. pass!
The boot ROM testing ............................. pass!
The battery testing .............................. pass!
Press CTRL+T to start sdram full test in 2 seconds!
The slot ID testing .............................. pass!
Starting...
Uncompressing..................Done!
Starting at 0x1600000...
CLOCK_REALTIME(yyyy/mm/dd - hh:mm:ss) is: 2007/11/14 - 11:22:21
Start file system check...
cfcard:/ - Volume is OK
cfcard2:/ - Volume is OK
cfcard2:/ - Volume is OK
****************************************************
* *
* 8090 boot ROM, Ver 204.00 *
* *
****************************************************
Copyright 2001-2009 Huawei Tech. Co., Ltd.
Creation date: Oct 31 2007, 11:29:00
CPU type : MPC7447
CPU L2 Cache : 512KB
CPU Core Frequency : 1GHz
BUS Frequency : 133MHz
Press Ctrl+B to enter Main Menu... 0
Auto-booting...
Booting from CFcard...
The start file is cfcard:/V600R009C10.cc
The config file is cfcard:/vrpcfg.zip
The paf file is cfcard:/paf_V600R009C10.txt
The license file is cfcard:/license_V600R009C10.txt
Loading.
......// Omitted.
Information note: ModuNo = 0xd0000, InfoType = 1, InfoNo = 0Recover configurati
on...OK!
Press ENTER to get started.

The preceding display shows that the device is restarted successfully. You can press Enter and
enter the user view.
Checking Whether the Software Version Is Correct

Run the display version command to check whether the software version is correct. For
example:
<HUAWEI> display version
Huawei Versatile Routing Platform Software
VRP (R) software, Version VRP 5.16 (NE40E&NE80E
V600R009C10)
Copyright (C) 2000-2011 Huawei Technologies Co., Ltd
HUAWEI NE40E uptime is 0 day, 1 hour, 44 minutes
......
The preceding command output shows the Versatile Routing Platform (VRP) version, host
version, and patch version. You can check whether the version number before and after the
restart is identical.
Checking Whether Configuration Files Are Correct

Run the display startup command to check whether configuration files are correct. For
example:
MainBoard:
paf_V600R009C10.txt
SlaveBoard:
paf_V600R009C10.txt
The displayed "vrpcfg.zip" denotes the name of the current configuration file.
3.3.4 Solution to the Restart Failure

This section describes how to handle the failure in the restart of the NE40E&NE80E.
If the system fails to be upgraded, to ensure that the NE40E&NE80E operates normally, you
need to roll back the version. For the rollback procedures, see the Upgrade Guide.

If any problem arises during the restart of the NE40E&NE80E, contact the local Huawei
technical support personnel.
3.4 Built-in System Software Is Incorrect or Does Not Exist

Incorrect or no system software was delivered along with the device. You need to copy the
correct system software through cfcard2 (located on the panel of the MPU/SRU). You can
also load the system software through the BootROM.
3.4.1 Loading the System Software Through the CF Card

This section describes loading the system software through the CF Card of router.
Context
The method of loading the system software through the CF card is used mainly during the
engineering stage or troubleshooting process. Before loading the system software through the
CF card, prepare two CF cards. If there are two CF cards on the MPUB (SRUA), do as
follows to load the system software. Replace the CF cards on the panels of the master
MPU/SRU and slave MPU/SRU with these new CF cards. With this method, you do not have
to pull out the MPU/SRU.
Procedure
Step 1 Connect the two new CF cards (cfard2s) to the PC using a card reader, and set up a file named
startup on each of the two new CF cards.
Step 2 Copy the next startup files to the directory cfcard2:/startup. Operation on two cfcard2s is the
same.
The rebooting files should be named as following:
l System software: ends with .cc.
l Config file: contains vrpcfg, and ends with .cfg or .zip.
l License file: contains license, and ends with .txt.
l PAF file: contains paf, and ends with .txt.
l GTL license file: ends with .dat.
Step 3 Power off the device, and then replace the CF cards on the master and slave MPU/SRU with
the two new CF cards having the startup files.
Step 4 Power on the device. The device automatically copies the startup files from the directory
cfcard2:/startup to the directory cfcard:/. After the startup files are copied, the device clears
and deletes the directory cfcard2:/startup. Then, the device sets the copied files as the next
startup files.

NOTICE
1. Make sure that the directory cfcard:/ has enough space for storing the startup files that are
copied from the directory cfcard2:/startup.
2. The system compares the startup files on the cfcard2s with those on the original CF cards
before copying startup files to the CF cards. The system copies every startup file from the
cfcard2s whose name or size is different from that of the startup file on the CF cards.
3. If multiple startup files of the same type exist on the cfcard2s, the system copies only the
latest one.
4. If the name of a startup file on the cfcard2 is the same as that on the CF card, the startup
file of the CF card is overwritten.
5. The original system software on the CF card, however, is not overwritten.
Step 5 Run the display startup command to check whether the system software and configuration
file are successfully loaded.
----End
3.5 Guide for Creating a User Account and Elevating a

User Account Right
This chapter provides methods for creating a user account and elevating a user account right.
l Method 1: Using MIB to Load a User Account Configuration File
l Method 2: Using FTP/SFTP to Replace the Current Device Configuration File
l Method 3: Using the CONSOLE Interface to Load a New Device Configuration File
During a Device Restart
The following table describes the advantages and requirements of each method.
Method Advantage Requirement
Method 1 Does not require device restarts 1. Requires the right to perform MIB
and therefore does not interrupt operations.
services. 2. Requires a MIB tool and the device
configuration file stored on a local PC.
Method 2 Is easy to use. 1. Requires device restarts.

2. Requires the FTP/SFTP function.
3. Requires an FTP/SFTP account.
Method 3 Does not require preset 1. Requires device restarts.

configurations. 2. Is complex and time consuming.
Method 1 is first recommended because it does not interrupt services.

Background
Two common causes for account unavailability are as follows:
l AAA is configured, but an account is lost.
l An account does not have the required administrative right after commands levels are
increased.
NOTE
If an account does not have the required administrative rights, try the CONSOLE or AUX interface for
login. By default, a CONSOLE or AUX interface login user has the management right. If you do not get
the required administrative right, turn to the following methods.
Troubleshooting
This section provides methods for creating a user account and elevating a user account right.
3.5.1 Using MIB to Load a User Account Configuration File

This section describes how to use MIBs to load a user account configuration file.
NOTE
This section mentions two types of configuration files. One type is the device configuration file, and the
other type is the user account configuration file. Note their differences during the following operations.
Prerequisites
l The device is running properly, and all device configurations are correct.
l You have the right to set MIB objects.
l A FTP/TFTP server is deployed, or a local PC is available to function as an FTP/TFTP
server.
l A MIB tool is available, and the device configuration file is present on a local PC.
Procedure
1. Create a user account configuration file and write configurations for a new or modified
user account into this file.
NOTE
Write only user account configurations into the file to minimize service interruption risks.
– For cause 1, add a user account.
Create a user account configuration file on a local PC. Configure a new user
account and write the configurations into this file.
For example:
#
aaa
local-user new-user password irreversible-cipher qaz@WSX123
local-user new-user service-type telnet
local-user new-user level 3
#
– For cause 2, change the user level to the required level.

NOTE
If you are not sure about the required level, change the user level to level 15, which provides
you with the highest administrative right.

Create a user account configuration file on a local PC. Change the user level and
write the new configurations into this file.
For example:
#
aaa
local-user old-user password irreversible-cipher qaz@WSX123
local-user old-user service-type telnet
local-user old-user level 15
#
NOTE
The "#" comment character indicates the system view and must be entered in the user
account configuration file.
2. (Optional)Configure the local PC as an FTP/TFTP server and upload the user account
configuration file to an FTP directory on the PC.
NOTE
l Perform this step when there is no FTP/TFTP server on the live network.
l Before performing this step, ensure that FTP/TFTP server software is available on the PC.
The following example uses the WFTPD software to describe how to configure an FTP
directory.
a. Start the WFTPD software. Choose Security —> Users/rights.
The User/Rights Security Dialog window is displayed.
b. Click New User, set a user name, and click OK.

c. In the displayed Change Password dialog box, set a password and click OK.
d. In the Home Directory field label, configure an FTP directory.
e. Click Done.
f. Upload the user account configuration file to the FTP directory.
3. Modify the device configurations using a MIB tool. The following example uses MIB
Browser.
Log in to http://support.huawei.com and download the correct MIB file to the PC.
a. Add the HUAWEI-CONFIG-MAN-MIB object to MIB Browser.
b. Open the device configuration file and record the values of the read, write, and
version parameters. These values will be used when you set connection parameters
on MIB Browser.

#
snmp-agent
snmp-agent local-engineid 000007DB7FFFFFFF00004191
snmp-agent community read public
snmp-agent community write private
snmp-agent sys-info version all
#
c. Enter the device IP address in the Remote SNMP agent box. Click the icon to set
connection parameters on MIB Browser.
d. In the displayed SNMP Protocol Preferences window, set SNMP protocol version,
Read community, and Set community based on actual configurations.
e. Connect MIB Browser to the device.
If the connection is successful, the icon becomes available.

f. Choose Edit —> Find. Then, enter 1.3.6.1.4.1.2011.6.10.1.2.4.1 to query MIB

information.
g. After CfgOperateTable is displayed, right-click hWCfgOperateEntry. Then, choose

Multiple Variable Bindings > Prompt For Instance.

h. In the displayed hwCfgOperateTable window, set objects that are listed in Table 1-1
and delete any object that is not listed in this table.
Table 1 lists objects to be set in hwCfgOperateTable and required values.

NOTE
Set the objects as specified in the "Required Value" column.
Table 3-7 Objects to be set and required values
Object Object Required Value
hwCfgOperateType 4
hwCfgOperateProtocol 1 for FTP and 2 for TFTP
hwCfgOperateFileName Name of the user account configuration

file created in Step 1
hwCfgOperateServerAddress IP address of the FTP/TFTP server

hwCfgOperateUserName User name used to log in to the FTP/

TFTP server
hwCfgOperateUserPassword Password used to log in to the FTP/TFTP

server
hwCfgOperateEndNotificationSwitch 1
hwCfgOperateRowStatus 4
4. Click the drop-down list on the right of Get and select Set.
– For cause 1, use the new user account to log in to the device. Run the display this
command in the AAA domain view to check whether the new user account
configurations have taken effect.
[HUAWEI-aaa] display this
#
aaa
local-user new password irreversible-cipher qaz@WSX123
local-user new service-type telnet
local-user new level 3
local-user 8090 password irreversible-cipher qaz@WSX123
local-user 8090 service-type ftp
local-user 8090 level 3
local-user 8090 ftp-directory
cfcard:/
[HUAWEI -aaa]
– For cause 2, use the original user account to log in to the device to check whether
you have the required right.
[HUAWEI-aaa] display this
#
aaa
local-user old password simple irreversible-cipher qaz@WSX123
local-user old service-type telnet
local-user old level 15
local-user 8090 password irreversible-cipher qaz@WSX123
local-user 8090 service-type ftp
local-user 8090 level 15
local-user 8090 ftp-directory

cfcard:/
[HUAWEI -aaa]
3.5.2 Using FTP/TFTP to Replace the Current Device

Configuration File
CAUTION
This method requires device restarts and interrupts services. Excise caution before using this
method.
Prerequisites
l The FTP/TFTP server function is enabled on the device. An FTP/TFTP account is
available.
l Restarting the device is permitted.
l You have the name of the next startup configuration file. (You can read the historical
display startup command output to learn the name of the next startup configuration file).
Procedure
1. Create a device configuration file.
NOTE
l To minimize service interruption risks, ensure that a new device configuration file has the
same configurations as the current device configuration file. To learn the current device
configurations, log in to the device using FTP/SFTP.
l When you create a device configuration file, ensure the command configurations and
command views are correct. In addition, do not press Enter to break a command, irrespective
of how long the command is.
2. Log in to the device using FTP/TFTP.
Connect a PC to the device by using FTP/TFTP (for example, C:\>ftp 128.3.170.5).
Enter the FTP/SFTP user name and password.
For example:
C:\>ftp 128.3.170.5
Connected to 128.3.170.5
220 FTP service ready.
User (128.3.170.7:(none)): 8090
331 Password required for 8090.
Password:****
230 User logged in.
ftp> bin
200 Type set to I.
ftp> cd cfcard:
3. Upload the new device configuration file to the device and replace the original next
startup device configuration file.
4. Restart the device to make the new device configuration file take effect.

3.5.3 Using the CONSOLE Interface to Load a New Device

Configuration File During a Device Restart
CAUTION
This method requires device restarts and interrupts services. Excise caution before using this
method.
Prerequisites
l A CONSOLE interface is available for login to the device.
l Restarting the device is permitted.
Procedure
1. Log in to the device using the CONSOLE interface.
2. Restart the device.
For example, during the device restart, information similar to the following appears on
the HyperTerminal:
****************************************************
*
*
* 8090 boot ROM, Ver 366.00
*
*
*
****************************************************
Copyright 2001-2008 Huawei Tech. Co.,

Ltd.
Creation date: Aug 16 2009,
20:05:44
CPU type :
MPC7447A
CPU L2 Cache :
512KB
CPU Core Frequency :
1GHz
3. Press Ctrl+B within 3 seconds after the "Press Ctrl+B to enter Main Menu... 3" message
is displayed.
4. Enter the correct password to display the main menu.

NOTE
l The default passwords to access the BootLoad and BootROM menus is WWW@HUAWEI.
Using the default password poses security risks. Therefore, changing the default password in
the boot main menu is recommended.
l After device is upgraded, the password for the BootROM menu remains. Changing the default
password is recommended after upgrade.
l The new password is at least six characters long and contains at least two of upper-case letters,
lower-case letters, digits, and special characters.
Password:
**********
Main Menu(bootload ver:
43.00)
1. Boot with default

mode
2. Boot from
CFcard
3. Enter ethernet
submenu
4. Set boot file and
path
5. Modify boot ROM
password
6. Chkdsk
CFcard
7. Format
CFcard
8. List file in
CFcard
9. Delete file from
CFcard
10. Set patch
mode
11. Set version back
signal
12.
Reboot
Press Ctrl+B to return Main Menu in any sub menu.
5. Enter 3 to enter the Ethernet interface submenu.

The following example uses the Ethernet interface submenu:
Enter your choice(1-12): 4
1. Download file to SDRAM through ethernet interface and boot
2. Download file to CFcard through ethernet interface
3. Modify ethernet interface boot parameters
4. Return to main menu
Enter your choice(1-4):
6. Select 3. Modify ethernet interface boot parameters to set the FTP/TFTP server IP
address and password. Specify the name of the device configuration file to be
downloaded.

NOTE
l You can deploy an independent FTP/TFTP server or configure the local PC as the FTP/TFTP
server.
l If an independent FTP/TFTP server is used, ensure that the FTP/TFTP server is physically
connected to the device using the CONSOLE interface.
Be sure to select 3 to modify boot parameters before downloading!
Note: two protocols for download, tftp & ftp.

You can modify the flags following the menu.
tftp--0x80, ftp--0x0.
'.' = clear field; '-' = go to previous field; ^D = quit
boot device : mgi0

\\If an MPUC or SRUC is used, enter motetsec0. If another type of main
control boards is used, enter mgi0. If mgi0 does not work, enter mgi2.
\\On an MPUH, set this parameter to motetsec0.
\\On an MPUD or MPUG, set this parameter to mottsec3.
processor number : 2
\\If the boot device parameter is set to motetsec0, set this parameter to 0;
if the boot device parameter is set to mgi0, set this parameter to 2; if the
boot device parameter is set to mgi2, set this parameter to 0.
\\On an MPUC/SRUC/MPUD/MPUG/MPUH, set this parameter to 0.
host name : host
\\Use the default value.
file name : vrpcfg.zip
\\Set this parameter to the name of the new device configuration file stored
on the FTP/TFTP server.
inet on ethernet (e) : 1.1.1.100:FFFFFF00
\\Set this parameter to an IP address and a mask, using which the device can
interwork with the FTP/TFTP server.
inet on backplane (b):
\\(Optional) Set a backup interface to be connected to the FTP/TFTP server.
host inet (h) : 1.1.1.2
\\Set this parameter to the IP address of the FTP/TFTP server.
gateway inet (g)
\\Set this parameter to the IP address of the FTP/TFTP server.
user (u) : 8090
\\Set this parameter to an FTP/TFTP user name that has been configured on the
FTP/TFTP server.
ftp password (pw) (blank = use rsh): ******
\\Set this parameter to the FTP/TFTP user password.
flags (f) : 0x0
\\If FTP is used, set this parameter to 0x0; if TFTP is used, set this
parameter to 0x80. The default value is 0x0.
target name (tn)
startup script (s)
other (o) :
7. After the previous menu is displayed, enter 2 to specify CF cards as the storage devices
for the new device configuration file.
Ethernet
Submenu
1. Download file to SDRAM through ethernet interface and

boot
2. Download file to CFcard through ethernet
interface
3. Modify ethernet interface boot

parameters

4. Return to main
menu
8. Select a CF card on which the device configuration file will be stored.

2
Download to CFcard through ethernet interface

Submenu
1. Download file to
CFcard
2. Download file to
CFcard2
3. Return to up
menu

1
Attaching interface lo0... done

After you select a CF card successfully, submenus will be closed, and the main menu
will be displayed.
9. In the main menu, enter 4 to display the submenu for setting the startup device
configuration file.
Main Menu(bootload ver:
43.00)
1. Boot with default

mode
2. Boot from
CFcard
3. Enter ethernet
submenu
4. Set boot file and
path
5. Modify boot ROM
password
6. Chkdsk
CFcard
7. Format
CFcard
8. List file in
CFcard
9. Delete file from
CFcard
10. Set patch
mode
11. Set version back
signal
12.
Reboot
Press Ctrl+B to return Main Menu in any sub menu.

– Enter 4 to set the startup device configuration file.

Enter your choice(1-11):5
Boot Files Submenu
1. Modify the boot file

2. Modify the paf file
3. Modify the license file
4. Modify the config file
5. Modify the patch file
6. Modify the patch states file
Config file is cfcard:/dta.cfg, modify the file name if needed.

Please input correctly,
– Enter the CF directory specified in Step 8. For example, enter cfcard:/vrpcfg.zip.

10. Restart the device to make the new device configuration file take effect.
NOTICE
For operation details, see the BootROM upgrade method described in the device upgrade
guide.

NE Series Router Maintenance Guide 4 Configuration Note
4 Configuration Note
About This Chapter
4.1 Basic Configuration

4.2 System Management
4.3 Network Reliability
4.4 Lan Access and MAN Access
4.5 IP Service
4.6 IP Routing
4.7 IP Multicast
4.8 MPLS

4.1 Basic Configuration

4.1.1 SSH
4.1.1.1 Login Failure of an SSH Client Because the Number of Saved SSH Public
Keys Reaches the Upper Limit
If the number of SSH public keys saved on an SSH client reaches the upper limit (20), the
client fails to log in to the new server.
Problem Description
Application scenario
A device functions as an SSH client, and a user uses this client to log in to an SSH server.
Trigger conditions
The problem occurs if the number of SSH public keys saved on an SSH client reaches 20.
Symptom
The SSH client fails to log in to the new server using stelnet command.
Identification method
Run the display current-configuration | include assign rsa-key command in the user view
to check whether the number of SSH public keys saved on the SSH client reaches 20.
In this example, the number of SSH public keys saved on the SSH client reaches 20, and the
problem described in this precaution notice will occur.
<HUAWEI> display current-configuration | include assign rsa-key
#
ssh client 1.1.1.1 assign rsa-key 1.1.1.1
#
Root Cause
After the number of SSH public keys saved on the SSH client reaches 20, no more public
keys can be stored for new connections, causing the login failure.

Impact and Risk

The SSH client fails to log in to the new server using stelnet command.
Measures and Solutions

Recovery measures
Delete unneeded SSH public keys.
[HUAWEI] undo ssh client 1.1.1.2 assign rsa-key
Workarounds
Same as the recovery measures
Preventive measures
4.1.2 VTY
4.1.2.1 High CPU Usage Because No ACL Is Configured for VTY Channels
If no ACL is configured for VTY channels on a device, the device is exposed to external
attacks, which leads to high CPU usage.
Problem Description
Telnet or SSH is used for login.
Trigger conditions
The problem occurs if the following conditions are met:
1. No ACL is configured for VTY channels.
2. The device is under attack.
Symptom
The device is exposed to external attacks, which leads to high CPU usage.
Run the display current-configuration command in user view to check whether the acl acl-
number inbound command is run for all VTY channels.
In this example, acl acl-number inbound command is not configured in VTY 16 to 20.
<HUAWEI> display current-configuration configuration
#
user-interface vty 0 14
acl 3100 inbound
authentication-mode aaa
protocol inbound ssh
#

Root Cause
Without an ACL for VTY channels, the device cannot be protected against external attacks.
Impact and Risk

If the device is under attack, the CPU usage goes high on the main control board, which
adversely affects services.

Recovery measures
Ensure that the acl acl-number inbound command is run for all VTY channels.
#
acl 3100 inbound
acl 3100 inbound
Workarounds
Preventive measures
4.2 System Management

4.2.1 NTP
4.2.1.1 Frequent Changes of Preferentially Selected Remote NTP Servers Because
No Preference Is Configured
When multiple remote NTP servers are specified using the ntp-service unicast-server server-
ip command, the preference parameter must be specified for one of the servers so that this
server is preferentially selected.
Problem Description
Multiple remote NTP servers are specified using the ntp-service unicast-server server-ip
command in system view.
Trigger conditions
There is a high probability that the problem occurs if the preference parameter is not
specified for one of the remote NTP servers.
Symptom

The preferentially selected remote NTP server frequently changes. As a result, the time on the
NTP client frequently changes accordingly, and a large number of logs are recorded.
Run the display current-configuration configuration ntp command in the user view to
check configurations on the NTP client.
In this example, more than one remote NTP server is configured, but the preference
parameter is not specified for any of them. As a result, the problem described in this
precaution notice may occur.
<HUAWEI> display current-configuration configuration ntp
#
ntp-service unicast-server 10.1.1.1
ntp-service unicast-server 10.1.1.2
#
Root Cause
The preferentially selected remote NTP server is not fixed because the preference parameter
is not specified for any remote NTP server. As a result, the client has to frequently
synchronize time with different servers.
Impact and Risk

The preferentially selected remote NTP server frequently changes. As a result, the time on the
NTP client frequently changes accordingly, and a large number of logs are recorded.

Recovery measures
Run the ntp-service unicast-server server-ip preference command in the system view to
specify a remote NTP server as the preferentially selected server.
Workarounds
Same as the recovery measure
Preventive measures
Same as the recovery measure
4.2.1.2 Clock Synchronization Failure Between an NTP Client and Server Because
of Incorrect Authentication Configuration
An NTP authentication mode is configured, and the ntp-service authentication enable
command is run, but no other authentication-related commands are run. As a result, the NTP
client fails to synchronize clock signals with the NTP server.
Problem Description
As NTP client, the ntp-service authentication enable command is run in the system view to
configure NTP authentication.

Trigger conditions
The problem occurs if none of the following commands are run:
l ntp-service authentication-keyid key-id authentication-mode mode cipher password
l ntp-service reliable authentication-keyid key-id
l ntp-service unicast-server server-ip authentication-keyid key-id (applies only to the
NTP client)
Symptom
The NTP client fails to synchronize clock signals with the NTP server.
Run the display current-configuration configuration ntp command in the user view to
check configurations on the NTP client.
In this example, NTP authentication is enabled, but no other authentication-related commands
are run.
<HUAWEI> display current-configuration configuration ntp
#
ntp-service authentication enable
#
Root Cause
NTP authentication is enabled using the ntp-service authentication enable command,
without any of the following configurations:
l NTP authentication key configured using the ntp-service authentication-keyid
authentication-mode mode cipher password command
l Key ID used to transmit messages to the remote server configured using the ntp-service
unicast-server sever-ip authentication-keyid key-id command
l Reliable authentication key configured using the ntp-service reliable authentication-
keyid key-id command
Impact and Risk

The NTP client fails to synchronize clock signals with the NTP server.

Recovery measures
Run the following commands in the system view:
[HUAWEI] ntp-service authentication enable
[HUAWEI] ntp-service reliable authentication-keyid 169
[HUAWEI] ntp-service unicast-server 172.0.0.1 authentication-keyid 169
[HUAWEI] ntp-service authentication-keyid 169 authentication-mode md5 cipher
Root@123
Workarounds
Preventive measures

4.2.2 NQA
4.2.2.1 Failure of Association Between NQA and Another Protocol Due to a Too
Short NQA Probe Period
The probe period configured for an NQA test instance is too short. Consequently, when a
probe is still going on, the next probe begins, leading to a "no result" error. As a result,
association between NQA and another protocol fails.
Problem Description
An NQA test instance is configured.
Trigger conditions
The problem occurs if the following inequality is met:
Frequency < (Probe-count – 1) x Interval + Timeout
Symptom
The NQA test result is "no result."
Run the display current-configuration configuration nqa command in the user view to
check the configurations of the NQA test instance.
In this example, the NQA probe period configured using the frequency command is 20s,
probe-count is 5, interval is 6s, and timeout is 4s. The configurations meet the preceding
inequality. Therefore, this test result is "no result.".
<HUAWEI> display current-configuration configuration nqa
#
nqa test-instance 1 1
test-type icmp
destination-address ipv4 127.0.0.1
frequency 20
interval seconds 6
timeout 4
probe-count 5
start now
#
Root Cause
The probe period configured for an NQA test instance is too short. Consequently, when a
probe is still going on, the next probe begins, leading to a "no result" error.
Impact and Risk

The board on which the NQA test instance is configured restarts. If another protocol is
associated with NQA, such as a routing protocol or VRRP, the association fails, adversely
affecting service forwarding.


Recovery measures
If the problem occurs, perform the following procedure to restore services:
1. Run the stop command in the NQA view to stop the test.
2. Run the frequency interval command in the NQA view to reconfigure the probe period
and ensure that the following inequality is met:
Frequency > (Probe-count – 1) x Interval + Timeout
3. Run the start now command in the NQA view to start the test.
Workarounds
Preventive measures
4.3 Network Reliability

4.3.1 BFD
4.3.1.1 Incorrect LSP Switchovers Caused by Different Incoming and Outgoing
Paths of the BFD for LSP Session
A BFD for LSP session is configured, and the LSP from the source device to the destination
device is different from the return LSP or IP path. When the return LSP or IP path fails, the
session goes Down, causing an incorrect LSP switchover.
Problem Description
In Figure 4-1, two paths exist between Router A and Router B.

Figure 4-1 Networking diagram for incorrect LSP switchovers caused by different incoming
and outgoing paths of the BFD for LSP session
Device C
Path 1
Device A Path 2 Device B
Device D
Trigger conditions
The problem occurs if any of the following conditions is met:
1. A dynamic BFD for LSP session is configured, and paths 1 and 2 are the LSP and IP
path, respectively.
2. A static BFD for LSP (excluding BFD for TE-LSP) session is configured. The session on
path 2 is configured to travel along an LSP, and the LSP is configured not to share the
LSP from Router A to Router B.
3. A static BFD for TE-LSP session is configured on both paths 1 and 2, and strict explicit
paths are not configured for the TE-LSPs on devices A and B.
Symptom
The BFD session aims to monitor link 1 (path 1). However, when link 2 (path 2) fails, the
session goes Down because the return path fails, triggering the LSP on path 1 to be
incorrectly switched. When traffic is switched to the faulty path 2, service traffic is lost.
1. In the following example, a dynamic BFD session monitors a forward LSP and a reverse
IP routing path. The identification method depends on the network, and the forward and
reverse paths of the BFD session must be consistent.
2. Check the BFD session's neighbor information on Router A.
# Run the display bfd session all verbose command in the user view to check the BFD
session's neighbor information from Router A to Router B. The content in bold indicates
the BFD session's neighbor and next hop from Router A to Router B.

<HUAWEI> display bfd session all verbose

------------------------------------------------------------------------------
--
State : Up Name : dyn_16396
------------------------------------------------------------------------------
--
Local Discriminator : 16396 Remote Discriminator : 16392
Session Detect Mode : Asynchronous Mode Without Echo Function
BFD Bind Type : TE_LSP
Bind Session Type : Dynamic
Bind Peer IP Address : 2.2.2.2
NextHop Ip Address : 10.1.1.2
......
3. Check the BFD session's neighbor information on Router B.

# Run the display bfd session all verbose command in the user view to check the BFD
session's neighbor information from Router B to Router A. The content in bold indicates
the BFD session's neighbor from Router B to Router A.
------------------------------------------------------------------------------
--
(Multi Hop) State : Up Name : dyn_16392
------------------------------------------------------------------------------
--
BFD Bind Type : Peer IP Address
Bind Session Type : Entire_Dynamic
......
4. Check the routing information from Router B to Router A.

# Run the display ip routing-table ip-address mask verbose command in the user view
to check the routing information from Router B to Router A. The content in bold
indicates the BFD session's next hop from Router B to Router A. The BFD session's next
hop from Router A to Router B is 10.1.1.2, but the BFD session's next hop from Router
B to Router A is 10.2.1.2. The BFD session's incoming and outgoing paths are different,
indicating that the problem described exists.
<HUAWEI> display ip routing-table 1.1.1.1 32 verbose
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black
hole route
------------------------------------------------------------------------------
Routing Table : _public_
Summary Count : 1
Destination: 1.1.1.1/32
Protocol: ISIS-L2 Process ID: 1
Preference: 15 Cost: 10
NextHop: 10.2.1.2 Neighbour: 0.0.0.0
State: Inactive Adv Age: 1d04h15m09s
Tag: 0 Priority: high
Label: NULL QoSInfo: 0x0
IndirectID: 0xE600087A
RelayNextHop: 0.0.0.0 Interface: GigabitEthernet0/5/5
TunnelID: 0x0 Flags:
Root Cause
The BFD session's path from Router A to Router B is different from that from Router B to
Router A. When the link from Router B to Router A fails, the BFD session goes Down. After
detecting the BFD session Down event, Router A incorrectly triggers an LSP switchover.

Impact and Risk

When the BFD session's incoming and outgoing paths are different and the outgoing path
fails, the incoming LSP is incorrectly switched.

Recovery measures
None
Workarounds
When deploying a BFD for LSP session on a network:
1. For a dynamic BFD for LSP session, configure a route constraint mode to ensure that the
incoming and outgoing paths are the same (for example, use high-priority static routes).
2. For a static BFD for non-TE-LSP session, configure a route constraint mode to ensure
that the incoming and outgoing paths are the same (for example, use high-priority static
routes).
3. For a static BFD for TE-LSP session, configure strict explicit paths to constrain the
incoming and outgoing LSPs and configure a BFD for TE-LSP session on both the
incoming and outgoing LSPs to ensure that the incoming and outgoing paths are the
same.
Preventive measures
Same as the workarounds
4.3.1.2 Traffic Interruptions Caused by Asymmetric Configurations on Both

Devices of a Static BFD Session
A static BFD session is configured. When configurations on both devices are asymmetric,
traffic is interrupted.
Problem Description
In Figure 4-2, a static BFD session is configured to monitor the link between devices A and
B.
Figure 4-2 Networking diagram for traffic interruptions caused by asymmetric configurations
on both devices of a static BFD session
interface1 interface1
10.1.1.1/24 10.1.1.2/24
Device A Device B
Trigger conditions

There is a high probability that the problem occurs if any of the following conditions is met:
1. Run the wtr wtr-value command in the BFD session view on Router A. Do not run the
wtr wtr-value command on Router B, or run the wtr wtr-value command to configure a
different WTR value on Router B.
2. Run the process-interface-status command in the BFD session view on Router A, but
do not run the command on Router B
3. Run the process-pst command in the BFD session view on Router A, but do not run the
command on Router B
Symptom
The service switching behaviors on both devices are different, causing traffic interruptions.
1. Check the static BFD session's WTR value.

# Run the display this command in the BFD session view on Router A. The local
discriminator must match the remote discriminator on Router B. The WTR time is 2
minutes.
[HUAWEI] bfd session a
[HUAWEI-bfd-session-a] display this
#
bfd a bind peer-ip 10.1.1.2
discriminator local 1
discriminator remote 2
wtr 2
#
return
# Run the display this command in the BFD session view on Router B. The local
discriminator must match the remote discriminator on Router A. No WTR time is
configured on Router B.
#
#
return
2. Check the process-interface-status configuration on both devices of the static multicast

BFD session.
discriminator must match the remote discriminator on Router B. The interface
association is configured.
#
bfd a bind peer-ip default-ip interface GigabitEthernet1/0/0
process-interface-status
#
return

Run the display this command in the BFD session view on Router B. The local
discriminator must match the remote discriminator on Router A. No interface association
is configured on Router B.
#
bfd a bind peer-ip default-ip interface GigabitEthernet1/0/0
#
return
3. Check the process-pst configuration on both devices of the static BFD session.
Run the display this command in the BFD session view on Router A. The local
discriminator must match the remote discriminator on Router B. The PST association is
configured.
#
bfd a bind peer-ip 10.1.1.2 interface GigabitEthernet1/0/0
process-pst
#
return
Run the display this command in the BFD session view on Router B. The local
discriminator must match the remote discriminator on Router A. No PST association is
configured on Router B.
#
bfd a bind peer-ip 10.1.1.1 interface GigabitEthernet1/0/0
#
return
Root Cause
1. Both devices have asymmetric wtr wtr-value configurations.
– After the session goes Up through negotiation, the time specified using the wtr wtr-
value command on Router A does not expire in a period, and Router A notifies the
upper layer of a link Down event. However, Router B notifies the upper layer of a
link Up event because the wtr wtr-value command is not run on Router B. As a
result, service switching behaviors on both devices are different and in turn traffic is
lost.
2. Both devices of the static multicast BFD session have asymmetric process-interface-
status configurations.
– The interface association states on both devices are different. When the session
enters the DetectDown state, Router A's interface protocol status is Down, but
Router B considers the interface Up. As a result, traffic may be lost.
3. The static BFD session is bound to physical interfaces, or both devices of the static BFD
for LSP session have asymmetric process-pst configurations.

– The PST association behaviors on both devices are different. When the session
enters the DetectDown state, Router A associates the PST but Router B does not.
As a result, traffic may be lost.
Impact and Risk

Service switching behaviors are asymmetric, causing traffic loss.

Recovery measures
Use asymmetric wtr wtr-value, process-interface-status, and process-pst configurations on
both devices of the static BFD session.
Workarounds
Preventive measures
4.3.1.3 Periodic BFD Session Flapping Caused by BFD Discriminator Conflict

A static BFD session flaps because of remote discriminator conflict.
Problem Description
As in Figure 4-3, a static BFD session is configured to monitor the link between devices A
and B.
Figure 4-3 Networking diagram for periodic BFD session flapping caused by BFD
discriminator conflict
interface1 interface1 interface2 interface1

10.1.1.1/24 10.1.1.2/24
Device A Device B Device C
Trigger conditions
1. A static BFD session is configured on Router B, which establishes a session with Router
A. The local discriminator a is configured on Router B.
2. A static BFD session is configured on Router C, and its remote discriminator is also set
to a.
Symptom

The BFD session periodically flaps, and the BFD session Down reasons on both devices are
both neighbor Down.
1. Check the static BFD session configurations on both devices.

# Run the display this command in the BFD session view on Router B. The local
discriminator must match the remote discriminator on Router A.
#
#
return
discriminator must match the remote discriminator on Router B.
#
#
return
2. Check detailed information about the BFD session.

# Run the display bfd session all verbose command in the user view to check detailed
information about the BFD session on Router A. The BFD session detects a neighbor
Down event.
------------------------------------------------------------------------------
--
(Multi Hop) State : Down Name : a
------------------------------------------------------------------------------
--
Active Multi : -
Last Local Diagnostic : Neighbor Signaled Session Down
……
# Run the display bfd session all verbose command in the user view to check detailed
information about the BFD session on Router B. The BFD session detects a neighbor
Down event.
------------------------------------------------------------------------------
--
(Multi Hop) State : Down Name : a
------------------------------------------------------------------------------
--
Active Multi : -
Last Local Diagnostic : Neighbor Signaled Session Down
……

3. Check the BFD session configuration on Router C.

# Run the display current-configuration configuration bfd-session command in the
user view to check whether any BFD session with local discriminator conflict exists on
Router C. The remote discriminator conflicts with the remote discriminator on Router B.
<HUAWEI> display current-configuration configuration bfd-session
#
#
return
Root Cause
The local discriminator is used to match a BFD session. When Router C sends a Down packet
to Router B in the Up state, Router B incorrectly considers that the Down packet is for itself.
As a result, the BFD session enters the NeighborDown state. Device B then sends a Down
packet to Router A, and Router A's BFD session also enters the NeighborDown state. When
Router C continuously sends Down packets to Router B at the second level, the BFD sessions
on devices A and B periodically flap.
Impact and Risk

The BFD session periodically flaps, causing services bound to the BFD session to flap.

Recovery measures
Change the remote discriminator of the BFD session on Router C to a different value.
Workarounds
Plan discriminators uniformly to prevent discriminator conflict when deploying BFD on a
network.
Preventive measures
4.3.1.4 Incorrect LSP Switchovers Caused by Different Incoming and Outgoing

Paths of a Static BFD for CR-LSP Session
A static BFD for CR-LSP session is configured. If incoming and outgoing paths are
inconsistent, the BFD session considers the CR-LSP Down, triggering a service switchover or
even causing a service interruption.
Problem Description
A static BFD for CR-LSP session is configured.
Trigger condition
There is a possibility that the problem occurs if the static BFD for CR-LSP session detects
incoming and outgoing CR-LSP path inconsistency.

Symptom
The BFD session considers the CR-LSP Down, triggering a service switchover or even
causing a service interruption.
1. Run the display current-configuration configuration bfd-session command in the user
view to check whether a static BFD for CR-LSP session is configured.
In this example, the local BFD discriminator is local1,the remote BFD discriminator is
remote2 for the primary LSP. local BFD discriminator is local3,the remote BFD
discriminator is remote3 for the backup LSP.
<HUAWEI> display current-configuration configuration bfd-session
#
bfd tunnel1 bind mpls-te interface Tunnel0/0/27 te-lsp
process-pst
#
bfd tunnel1-back bind mpls-te interface Tunnel0/0/27 te-lsp backup
process-pst
#
return
2. Run the display current-configuration interface tunnel-name command in the user

view to check the TE tunnel configuration.
In this example, destination IP address is 192.168.1.1, the explicit paths of the primary
LSP is main-to-devicea and the explicit paths of the backup LSP is backup-to-devicea.
<HUAWEI> display current-configuration interface Tunnel 0/0/27
#
interface Tunnel0/0/27
description huawei
mtu 1600
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 192.168.1.1
mpls te tunnel-id 27
mpls te record-route label
mpls te path explicit-path main-to-devicea
mpls te path explicit-path backup-to-devicea secondary
mpls te backup hot-standby mode revertive wtr 60
mpls te backup ordinary best-effort
mpls te igp shortcut
mpls te igp metric absolute 10
mpls te commit
isis enable 100
statistic enable #
return
3. Run the display mpls te tunnel-interface tunnel-name command in the user view to
check the 3-tuple information about the tunnel.
In this example, Session ID of Tunnel 0/0/27 is 27,Ingress LSR ID is
192.168.1.2,Primary LSP ID is 3,Backup LSP ID is 32772.
<HUAWEI> display mpls te tunnel-interface Tunnel 0/0/27
----------------------------------------------------------------
Tunnel0/0/27
----------------------------------------------------------------
Tunnel State Desc : UP
Active LSP : Primary LSP
Session ID : 27
Ingress LSR ID : 192.168.1.2 Egress LSR ID: 192.168.1.1
Admin State : UP Oper State : UP

Primary LSP State : UP

Main LSP State : READY LSP ID : 3
Hot-Standby LSP State : UP
Main LSP State : READY LSP ID : 32772
4. Check the tunnel path. The path is used for comparison with the path queried on the peer
device.
Run the display current-configuration interface tunnel 0/0/27 command to check
whether the mpls te record-route or mpls te record-route label command is run. If the
command is run, run the display mpls te tunnel path lsp-id ingress-lsr-id session-id
local-lsp-id command to check the tunnel path.
Otherwise, run the tracert lsp te tunnel-name command to check the tunnel path.
<HUAWEI> display mpls te tunnel path lsp-id 192.168.1.2 27 3
Tunnel Interface Name : Tunnel0/0/27
Lsp ID : 192.168.1.2 :27 :3
Hop Information
Hop 0 192.168.1.2
Hop 1 100.0.2.7
Hop 2 100.0.2.8
Hop 3 192.168.1.1
<HUAWEI> tracert lsp te Tunnel 0/0/27
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel0/0/1, press CTRL_C
to break.
TTL Replier Time Type Downstream
0 Ingress 192.168.1.2/[3 ]
1 192.168.1.1 32 ms Egress
5. Run the display explicit-path explicit-name command in the user view to check the
explicit paths of the tunnel.
– If no explicit path is configured on the device or the tunnel configuration does not
contain an explicit path, configure strict explicit paths for the tunnels.
– If the configured explicit path contains less hops than the path queried in Step 4,
add the missing hops to the explicit path configuration.
– If the loose mode is configured for the explicit path, change the mode to the strict
mode.
<HUAWEI> display explicit-path main-to-devicea
1 62.231.253.26 Strict Include
<HUAWEI> display explicit-path backup-to-devicea
6. Check the egress of the tunnel based on the TE tunnel's destination IP address
(192.168.1.1).
Run the display bfd configuration discriminator local-discr-value verbose command
in the user view on the egress of the TE tunnel, set local-discr-value to the Remote
Discriminator (2) in the ingress's static BFD for CR-LSP session, and locate the
corresponding TE tunnel (Tunnel0/0/28).
<HUAWEI> display bfd configuration discriminator 2 verbose
------------------------------------------------------------------------------
--
BFD Session Configuration Name : to_3
------------------------------------------------------------------------------
--
BFD Bind Type :
TE_LSP

Bind Session Type :

Static
Bind Interface : Tunnel0/0/28 TE LSP Type : Primary
TOS-EXP : 7 Local Detect Multi :
3
Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10
WTR Interval (ms) : - Process PST :
Enable
Proc Interface Status :
Disable
Bind Application : LSPM | L2VPN
Session Description :
-
------------------------------------------------------------------------------
--
7. Perform Steps 2 to 5 on the egress based on the obtained tunnel name (Tunnel0/0/28) to
locate the actual tunnel path, and compare the path with the one obtained in Step 5.
If the two paths are consistent except for opposite directions, no action is required. If the
paths are inconsistent, change the tunnel path to the one obtained on the ingress.
Root Cause
The incoming and outgoing CR-LSP paths are inconsistent.
Impact and Risk

The static BFD for CR-LSP session considers the CR-LSP Down, which may be incorrect.

Recovery measures
Change the explicit path to ensure that the actual path traversed by the tunnel is the same as
the tunnel path for the ingress of the TE tunnel.
Workarounds
If static BFD for CR-LSP is configured, ensure that the incoming and outgoing explicit paths
of the tunnel are consistent.
Preventive measures
4.3.1.5 Inner-Link Protection Failure in a BFD Multi-Layer Protection Scenario

Because the Inner BFD Detection Interval is Greater than the Outer BFD
Detection Interval
In a multi-layer protection scenario, if the inner BFD detection interval is greater than the
outer BFD detection interval, the outer protection detects link faults earlier than the inner
protection does. As a result, the inner protection cannot trigger link switchover in time.
Problem Description
In some cases, multi-layer protection may be deployed. For example, BFD for RSVP, BFD for
TE-LSP, and BFD for TE-tunnel are configured.

Trigger conditions
The problem occurs if the inner BFD detection interval is greater than the outer BFD
detection interval.
Symptom
The outer protection detects link faults earlier than the inner protection does. If a backup path
is available for the outer protection mechanism, the inner protection is useless.
Run the display bfd session all verbose command in the user view to check detailed BFD
session information, including the detection interval.
In this example, the first BFD session monitors inner LSPs, with BFD Bind Type being
TE_LSP, and Detect Interval being 2664 ms. The second BFD session monitors a tunnel,
with BFD Bind Type being TE_TUNNEL, and Detect Interval being 300 ms.
--------------------------------------------------------------------------------
State : Up Name : dyn_16393
--------------------------------------------------------------------------------
BFD Bind Type : TE_LSP
Bind Session Type : Dynamic
NextHop Ip Address : 10.1.1.2
Bind Interface : Tunnel1 TE LSP Type : Primary
Tunnel ID : 33
FSM Board Id : 9 TOS-EXP : 6
Actual Tx Interval (ms): 999 Actual Rx Interval (ms): 888
Local Detect Multi : 48 Detect Interval (ms) : 2664
Echo Passive : Disable Acl Number : -
Destination Port : 3784 TTL : 1
Proc Interface Status : Disable Process PST : Enable
WTR Interval (ms) : - Config PST : Enable
Active Multi : 3
Last Local Diagnostic : No Diagnostic
Bind Application : TE
Session TX TmrID : - Session Detect TmrID : -
Session Init TmrID : - Session WTR TmrID : -
Session Echo Tx TmrID : -
Session Description : -
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
State : Up Name : te
--------------------------------------------------------------------------------
BFD Bind Type : TE_TUNNEL
Bind Session Type : Static
NextHop Ip Address : -.-.-.-
Bind Interface : Tunnel1
Tunnel ID : 33
Proc Interface Status : Disable Process PST : Disable
WTR Interval (ms) : - Config PST : Disable

Active Multi : 3
Last Local Diagnostic : No Diagnostic
Bind Application : No Application Bind
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 2/0
Root Cause
The inner BFD detection interval is greater than the outer BFD detection interval.
Consequently, the outer protection detects link faults earlier than the inner protection does. As
a result, the inner protection cannot trigger link switchover in time.
Impact and Risk

Only the outer protection takes effect.

Recovery measures
Change the inner BFD detection interval to a value less than the outer BFD detection interval.
Workarounds
Ensure that the inner BFD detection interval is less than the outer BFD detection interval in a
multi-layer protection scenario.
Preventive measures
4.4 Lan Access and MAN Access

4.4.1 Eth-Trunk
4.4.1.1 Incorrect Eth-Trunk Status Due to LACP E-Trunk Global Configuration

Inconsistency
Eth-Trunk interfaces in static LACP mode are added to an E-Trunk. An LACP E-Trunk
system ID and a system priority are configured using the lacp e-trunk { system-id system-id |
priority priority } command on each device with the E-Trunk configured. If the LACP E-
Trunk system ID or system priority on one device is different from that on the other device,
the Eth-Trunk status may be incorrect.
Problem Description
As in Figure 4-4, Eth-Trunk interfaces in static LACP mode are added to an E-Trunk.

Figure 4-4 Networking diagram for incorrect Eth-Trunk status due to LACP E-Trunk global
configuration inconsistency
PE1 LACP E-Trunk System ID:1-1-1

0
ru nk 1 LACP E-Trunk Priority:100
-T
Eth-Trunk 1 Eth E-Trunk Priority: 10
E-Trunk 1
CE LACP E-Trunk System ID:1-1-1

Eth-Tru
nk 10 LACP E-Trunk Priority:100
E-Trunk Priority: 20
PE2
Trigger conditions
l An E-Trunk is configured on PE1 and PE2.
l Either the system ID or priority configured using the lacp e-trunk { system-id system-id
| priority priority } command on PE1 is different from its counterpart on PE2.
Symptom
The Eth-Trunk status is incorrect.
Run the display eth-trunk eth-trunk-id command in any view on PE1 and PE2 to check the
configured E-Trunk system ID and priority.
# Check PE1. The command output shows that Eth-Trunk1 is added to E-Trunk1.
[HUAWEI] interface eth-trunk 1
[HUAWEI-Eth-Trunk1] display this
#
interface Eth-Trunk1
mode lacp-static
e-trunk 1
#
[HUAWEI] display eth-trunk 1
Eth-Trunk1's state information is:
Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to flow
System Priority: 100 System ID: 0001-0001-0001
Least Active-linknumber: 1 Max Active-linknumber: 16
Operate status: down Number Of Up Port In Trunk: 0
--------------------------------------------------------------------------------
ActorPortName Status PortType PortPri PortNo PortKey PortState Weight
Partner:
--------------------------------------------------------------------------------
ActorPortName SysPri SystemID PortPri PortNo PortKey PortState
# Check PE2. The command output shows that Eth-Trunk1 is added to E-Trunk1.

[HUAWEI] interface eth-trunk 1
[HUAWEI-Eth-Trunk1] display this
#
mode lacp-static
e-trunk 1
#
[HUAWEI] display eth-trunk 1
Eth-Trunk1's state information is:
Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to flow
System Priority: 101 System ID: 0001-0001-0001
Least Active-linknumber: 1 Max Active-linknumber: 16
Operate status: up Number Of Up Port In Trunk: 0
--------------------------------------------------------------------------------
ActorPortName Status PortType PortPri PortNo PortKey PortState Weight
Partner:
--------------------------------------------------------------------------------
ActorPortName SysPri SystemID PortPri PortNo PortKey PortState
The preceding information shows that System Priority on PE1 does not match that on PE2.
Root Cause
In the LACP E-Trunk scenario, a CE only detects one PE even if there are two PEs. In this
situation, the two PEs must have the same global LACP E-Trunk configurations.
Impact and Risk

The status of the Eth-Trunks that are E-Trunk members does not match the expected master/
backup status.

Recovery measures
Ensure the LACP E-Trunk system ID and system priority consistency between PE1 and PE2.
Workarounds
Preventive measures
4.5 IP Service
4.5.1 TCP
4.5.1.1 TCP Disconnection Because the TCP Buffer Size Is Too Small
The TCP buffer is used to cache packets. If the size of the buffer is too small, the size of
packets that can be sent or received by the device is even smaller, leading to TCP
disconnection.

Problem Description
Services that depend on TCP connections, such as BGP and LDP, are configured.
Trigger conditions
There is a possibility that the problem occurs if the following conditions are met:
l A small size (1 KB for example) is configured for a TCP buffer using the tcp window
window-size command.
l The size of the service packets that depend on the TCP connection is greater than the
buffer size.
Symptom
TCP disconnection occurs.
Run the display tcp status command in the user view to check the TCP connection status.
The following output shows the TCP connection before it is disconnected.
<HUAWEI> display tcp status
TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID State
7800b1ec 6 /1 0.0.0.0:21 0.0.0.0:0 23553 Listening
72094f08 144/4 0.0.0.0:22 0.0.0.0:0 23553 Listening
78000714 144/1 0.0.0.0:23 0.0.0.0:0 23553 Listening
7800a90c 175/3 0.0.0.0:179 1.1.1.1:0 0 Listening
7208f1d8 175/6 0.0.0.0:179 1.1.1.2:0 0 Listening
7374df44 175/327 2.2.2.2:54269 3.3.3.3:179 0 Syn_Sent
12d26d68 144/6 192.168.131.166:23 192.168.224.3:57582 0 Established
15691498 144/29 192.168.131.166:23 192.168.224.3:61044 0 Established
7375240c 144/23 192.168.131.166:23 192.168.242.37:50132 0 Established
12d23a60 144/5 192.168.131.166:23 192.168.242.37:54566 0 Established
7374bbc4 144/30 192.168.131.166:23 192.168.250.23:8426 0 Established
7067cff4 175/10 192.168.131.166:179 192.168.242.37:54512 0 Established
After the TCP connection is disconnected, its information is not displayed.

7800b1ec 6 /1 0.0.0.0:21 0.0.0.0:0 23553 Listening
72094f08 144/4 0.0.0.0:22 0.0.0.0:0 23553 Listening
78000714 144/1 0.0.0.0:23 0.0.0.0:0 23553 Listening
7800a90c 175/3 0.0.0.0:179 1.1.1.1:0 0 Listening
7208f1d8 175/6 0.0.0.0:179 1.1.1.2:0 0 Listening
7374df44 175/327 2.2.2.2:54269 3.3.3.3:179 0 Syn_Sent
Root Cause
The buffer size is too small. As a result, service packets cannot be sent or received.
Impact and Risk

Services that depend on the TCP connection are interrupted.

Recovery measures

Run the tcp ipv6window window-size command to set a proper size (8 KB for example) for
the TCP buffer.
By default, the size for TCP buffer is 8 KB.
Workarounds
Preventive measures
4.5.1.2 TCP6 Disconnection Because the TCP6 Buffer Size Is Too Small
The TCP6 buffer is used to cache packets. If the size of the buffer is too small, the size of
packets that can be sent or received by the device is even smaller, leading to TCP6
disconnection.
Problem Description
Services that depend on TCP6 connections, such as BGP and LDP, are configured.
Trigger conditions
There is a possibility that the problem occurs if the following conditions are met:
l A small size (1 KB for example) is configured for a TCP6 buffer using the tcp ipv6
window window-size command.
l The size of the service packets that depend on the TCP6 connection is greater than the
buffer size.
Symptom
TCP6 disconnection occurs.
Run the display tcp ipv6 status command in the user view to check the TCP6 connection
status.
The following output shows the TCP6 connection before it is disconnected.

<HUAWEI> display tcp ipv6 status
* - MD5 Authentication is enabled.
# - Keychain Authentication is enabled.
TCP6CB TID/SoID Local Address Foreign Address State VPNID
78004bdc 144/3 ::->22 ::->0 Listening 23553
78000dbc 144/2 ::->23 ::->0 Listening 23553
12d26d68 144/6 2000::1->23 2000::2->57582 Established 0
After the TCP6 connection is disconnected, its information is not displayed.

<HUAWEI> display tcp ipv6 status
* - MD5 Authentication is enabled.
# - Keychain Authentication is enabled.
TCP6CB TID/SoID Local Address Foreign Address State VPNID
78004bdc 144/3 ::->22 ::->0 Listening 23553
78000dbc 144/2 ::->23 ::->0 Listening 23553

Root Cause
The buffer size is too small. As a result, service packets cannot be sent or received.
Impact and Risk

Services that depend on the TCP6 connection are interrupted.

Recovery measures
Run the tcp ipv6 window window-size command to set a proper size (8 KB for example) for
the TCP6 buffer.
By default, the size for TCP6 buffer is 8 KB.
Workarounds
Preventive measures
4.6 IP Routing
4.6.1 IGP
4.6.1.1 IGP Neighbor Flapping Due to a Too Short Neighbor Timeout Period
If the IGP (OSPF or IS-IS) neighbor timeout period is too short, neighbor relationships may
easily go Down, interrupting services.
Problem Description
An IGP, such as OSPF or IS-IS, is configured.
Trigger conditions
There is a low probability that the problem occurs if either of the following conditions is met:
l On an IS-IS interface, if the isis timer hello 3 command is run, but the isis timer
holding-multiplier command is not, the neighbor timeout period is considered too short.
l On an OSPF interface, the neighbor timeout period is considered too short if either of the
following conditions is met:
– In the interface view, the ospf timer hello 1 command is run, but the ospf timer
dead command is not.
– In the interface view, the ospf timer dead interval command is run, and the interval
is no greater than 4s.
Symptom

IGP (OSPF or IS-IS) neighbor relationships may easily go Down, interrupting services.
1. Run the display current-configuration configuration isis or display current-
configuration configuration ospf command in the user view to check whether IS-IS or
OSPF is configured.
<HUAWEI> display current-configuration configuration isis
#
isis 100
is-level level-2
cost-style wide
network-entity 10.0000.0100.0005.00
#
<HUAWEI> display current-configuration configuration ospf
#
ospf 100
area 0.0.0.0
network 31.1.1.0 0.0.0.255
network 123.23.3.0 0.0.0.255
#
2. Run the display isis interface verbose or display ospf interface all command in the
user view to check all interfaces with IS-IS or OSPF enabled. IS-IS is enabled on
interface GigabitEthernet3/0/6.1001
<HUAWEI> display isis interface verbose
Interface information for ISIS(100)
-----------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
GE3/0/6.1001 001 Up Down 1497 L1/L2 --
Circuit MT State : Standard
Circuit Parameters : p2p
Description : HUAWEI, GigabitEthernet3/0/6.1001 Interface
SNPA Address : 0018-8266-56be
IP Address : 26.1.1.5
IPV6 Link Local Address :
IPV6 Global Address(es) :
Csnp Timer Value : L12 10
Hello Timer Value : 10
DIS Hello Timer Value :
Hello Multiplier Value : 1000
Cost : L1 10 L2 10
Ipv6 Cost : L1 10 L2 10
Retransmit Timer Value : L12 5
LSP-Throttle Timer : L12 50
Bandwidth-Value : Low 1000000000 High 0
Static Bfd : NO
Dynamic Bfd : NO
Dynamic IPv6 Bfd : NO
Fast-Sense Rpr : NO
Extended-Circuit-Id Value : 0000000001
Suppress Base : NO
IPv6 Suppress Base : NO
Link quality adjust cost : NO
Link quality : 0x0(Best)
# Run the display ospf interface all command in any view and check for OSPF-enabled
interfaces. The command output shows that OSPF is enabled on GigabitEthernet3/0/4
and GigabitEthernet3/0/9.
<HUAWEI> display ospf interface all
OSPF Process 100 with Router ID 20.1.1.2
Interfaces
Area: 0.0.0.0 (MPLS TE not enabled)
Interface: 12.3.3.1 (GigabitEthernet3/0/4)

Cost: 1 State: BDR Type: Broadcast MTU: 1500
Priority: 1

Designated Router: 12.3.3.2

Backup Designated Router: 12.3.3.1
Timers: Hello 10 , Dead 40 , Poll 120 , Retransmit 5 , Transmit Delay 1
Cost: 1 State: DR Type: Broadcast MTU: 1500
Priority: 1
3. Check whether the neighbor timeout period is too short.

On an IS-IS interface, if the isis timer hello 3 command is run, but the isis timer
holding-multiplier command is not, the neighbor timeout period is considered too short.
On an OSPF interface, the neighbor timeout period is considered too short if either of the
following conditions is met:
– In the interface view, the ospf timer hello 1 command is run, but the ospf timer
dead command is not.
– In the interface view, the ospf timer dead interval command is run, and the interval
is no greater than 4s.
# Check information about GE 3/0/6.1001. The command output shows that the neighbor
timeout period is too small.
<HUAWEI> display current-configuration interface GigabitEthernet3/0/6.1001
#
vlan-type dot1q 1001
ip address 26.1.1.5 255.255.255.0
isis enable 100
isis circuit-type p2p
isis timer hello 3

#
return
# Check information about GE 3/0/4. The command output shows that the neighbor
<HUAWEI> display current-configuration interface GigabitEthernet3/0/4
#
interface GigabitEthernet3/0/4
undo shutdown
ip address 12.3.3.1 255.255.255.0
ospf timer hello 1

#
return
# Check information about GE 3/0/9. The command output shows that the neighbor
<HUAWEI> display current-configuration interface GigabitEthernet3/0/9
#
undo shutdown
ip address 31.1.1.1 255.255.255.0
ospf timer hello 3
ospf timer dead 4

#
return
Root Cause
The neighbor timeout period is too short.

Impact and Risk

IGP (OSPF or IS-IS) neighbor relationships may easily go Down, interrupting services.

Recovery measures
Use the default neighbor timeout period.
Workarounds
Preventive measures
4.6.1.2 Unexpected Traffic Diversion Because IGP Routes Take Precedence over
Imported Routes
Multiple ASBRs use an IGP to import external routes. If the priority of the imported routes is
lower than that of IGP routes, only one of the ASBRs can successfully import the external
routes, and the other ASBRs learn routes using the IGP, causing traffic diversion.
Problem Description
In Figure 4-5, devices A and B are ASBRs. They import BGP routes and advertise the routes
to devices C and D for the forwarding of upstream traffic. Because BGP routes have a lower
priority than OSPF routes, the BGP routes learned by Router B become inactive after Router
B learns the OSPF routes from Router A. As a result, Router B does not re-advertise the BGP
routes to Router D. Consequently, Router D's upstream traffic passes through Router C and
then Router A.

Figure 4-5 Networking diagram for unexpected traffic diversion because IGP routes take
precedence over imported routes
Device A Device B
(ASBR) (ASBR)
Device D’s
upstream traffic
Device C Device D
Trigger conditions
There is a high probability that the problem occurs if the following conditions are met:
1. Multiple ASBRs use an IGP to import external routes.
2. The priority of the imported routes is lower than that of IGP routes.
Symptom
Service traffic is not forwarded along the imported routes. Instead, the traffic passes through
another ASBR.
1. Run the following command and check whether an IGP imports external routes.
# In the user view, run the display current-configuration configuration ospf command
to check whether the OSPF imports external routes. This configuration indicates that
OSPF imports BGP routes.
#
ospf 1 router-id 1.1.1.6
import-route bgp
area 0.0.0.0
network 1.1.19.6 0.0.0.0
#
return
# In the user view, run the display current-configuration configuration ospfv3

command to check whether the OSPFv3 imports external routes. This configuration
indicates that OSPFv3 imports static routes.
<HUAWEI> display current-configuration configuration ospfv3
#

ospfv3 1
router-id 1.1.1.1
import-route static
#
return
# In the user view, run the display current-configuration configuration isis command
to check whether the ISIS imports external routes. This configuration indicates that ISIS
imports static routes.
#
isis 1
cost-style wide
network-entity 10.000a.0011.0006.00
import-route static
#
return
2. Check the priority of the imported routes.

# In OSPF configurations, priority for intra-area and inter-area OSPF routes is 200, and
priority for OSPF ASE and NSSA routes is 200.
[HUAWEI] ospf 1
[HUAWEI-ospf-1] display this
#
ospf 1
preference 200
preference ase 200
#
return
# In OSPFv3 configurations, priority for intra-area and inter-area OSPFv3 routes is 100,
and priority for OSPFv3 ASE and NSSA routes is 100.
[HUAWEI] ospfv3 1
[HUAWEI-ospfv3-1] display this
#
ospfv3 1
router-id 1.1.19.6
preference 100
preference ase 100
#
return
# In ISIS configurations, priority for intra-area and inter-area IS-IS routes is 200.
[HUAWEI] isis 1
[HUAWEI-isis-1] display this
#
isis 1
cost-style wide
network-entity 00.0005.0000.0019.0006.00
preference 200
#
return
# In BGP configurations, the priorities for EBGP routes and IBGP routes are 200 and
180, respectively. The Local_Pref is 150.
[HUAWEI] bgp
[HUAWEI-bgp] display this
#
bgp 100
#
ipv4-family unicast
undo synchronization
preference 200 180 150

# In RIP configurations, priority for RIP routes is 200.

<HUAWEI> display current-configuration configuration rip
#
rip 1
preference 200
#
return
# In RIPNG configurations, priority for RIPNG routes is 200.

<HUAWEI> display current-configuration configuration ripng
#
ripng 1
preference 200
#
return
# In static configurations, priority for static routes is 200.

#
¡¡
ip route-static 1.1.1.1 32 NULL 0 preference 200
#
3. If no route priority is configured, Huawei devices use the following default priorities.
Route soure Huawei Prefrence
DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 255
EBGP 255
BGP Local 255
If the priority of the imported routes is lower than that of IGP routes, traffic diversion
may occur.
Root Cause
The priority of the imported routes is lower than that of IGP routes. As a result, the imported
routes become inactive, causing the traffic diversion.
Impact and Risk

Traffic diversion occurs.


Recovery measures
Reduce the priority value of IGP routes to a value smaller than that configured for the
imported routes. The smaller the value, the higher the priority.
NOTE
Prevent the priority change from affecting normal services.
Workarounds
Preventive measures
4.6.1.3 Route Learning Failure of OSPF Neighbors Because of Inconsistent

Network Types at Both Ends
The network type of an OSPF interface is P2P, and the network type of another OSPF
interface is broadcast. After a neighbor relationship is established between the two interfaces,
they cannot learn routes from each other.
Problem Description
OSPF is enabled on two interfaces.
Trigger conditions
The problem occurs if the network type of an OSPF interface is P2P and the network type of
another OSPF interface is broadcast.
Symptom
An OSPF neighbor relationship can be established between the two interfaces, but they cannot
learn routes from each other.
1. Run the display ospf interface all command in the user view to check information about
all OSPF broadcast interfaces.
In the following example, GigabitEthernet1/0/1 and GigabitEthernet1/1/0 are broadcast
interfaces.
Interfaces

Cost: 1 State: DROther Type: Broadcast MTU: 1500 Priority: 123

Cost: 1 State: DROther Type: Broadcast MTU: 1500

Priority: 0
2. Run the display ospf peer interface-name command in the user view to check all OSPF
neighbor relationships established on the broadcast interfaces obtained in the first step.
– If no neighbor relationship information is displayed or the neighbor state is not
Full, the problem described in this precaution notice will not occur.
– If the neighbor state is Full, check whether the network types of the local and
remote interfaces are the same.
NOTE
l For broadcast neighbors, the value of the DR field displayed in the command output must be
an IP address. If None is displayed in this field, the network types of the local and remote
interfaces are different.
l For P2P neighbors, the value of the DR field must be None. If the value is not None, the
network types of the local and remote interfaces are different.
The following example shows information about the broadcast interface
GigabitEthernet1/0/1's neighbor that is in Full state. Because no IP address is displayed
in the DR field, the network types of the local and remote interfaces are different.
<HUAWEI> display ospf peer GigabitEthernet1/0/1
Neighbors
Area 0.0.0.0 interface 192.168.1.1(GigabitEthernet1/0/1)'s neighbors

Router ID: 1.1.1.3 Address: 192.168.1.3
State: Full Mode:Nbr is Master Priority: 123
DR: None BDR: None MTU: 0
Dead timer due in 33 sec
Retrans timer interval: 5
Neighbor is up for 00:45:35
Authentication Sequence: [ 0 ]

Neighbors

DR: 192.168.2.3 BDR: None MTU: 0 Dead timer due in 32 sec
Root Cause
OSPF uses Hello packets to discover, establish, and maintain neighbor relationships. Hello
packets carry no field that indicates the network type. Therefore, Hello packet transmission
and OSPF neighbor relationship establishment are not affected even though the network types
are different.
However, broadcast and P2P interfaces calculate shortest path trees (SPTs) differently.
Broadcast interfaces run for the DR, and the DR advertises Network LSAs. Other broadcast
interfaces first calculate the path to the DR, then locate all devices in the network segment
based on Network LSAs, and finally calculate routes. P2P interfaces calculate the path to each
other based on Router LSAs.
The Router LSAs advertised by broadcast interfaces contain only information about the path
to the DR. Therefore, a P2P interface fails to calculate the path from a broadcast neighbor to

itself based on the neighbor's Router LSA. Similarly, a broadcast interface fails to calculate
the path from a P2P neighbor to itself based on the neighbor's Router LSA because the Router
LSA advertised by the P2P neighbor does not contain information about the path to the DR.
Impact and Risk

Routes cannot be correctly calculated, interrupting services.

Recovery measures
Run the ospf network-type command in the interface view to ensure that the two interfaces at
both ends have the same network type.
1. In the following example, the network type of the P2P interface is changed to broad
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] display this
#
undo shutdown
ip address 192.168.1.1 255.255.255.0
ospf network-type p2p
ospf dr-priority 123
#
return
2. Run the display ospf peer interface-name command in the user view on both devices to
check whether an IP address is displayed in the DR field.
In the following example, an IP address is displayed in the DR field of
GigabitEthernet1/0/1.
Neighbors

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
Dead timer due in 38 sec
Workarounds
Preventive measures
4.6.1.4 Failure of the Switchover from Default Routes After the IS-IS Overload
Bit Is Set
The overload (OL) bit is set to 1 on a device so that the routes passing through the device are
switched to a backup path. However, if the device advertises default routes, services will not
be switched to a backup path from the default routes.

Problem Description
As in Figure 4-6, IS-IS neighbor relationships are established between devices A and C,
between A and B, between C and D, and between B and D. Link T is the primary path, and
the Router A -> Router B -> Router D link is the backup path.
l During a cutover, the set-overload command is run in the IS-IS view on Router C to
switch services to the backup path.
l The set-overload on-startup command is run in the IS-IS view on Router C to delay
route switchback in the case of a master/slave MPU switchover or device restart.
Figure 4-6 Networking diagram for failure of the switchover from default routes after the IS-
IS overload bit is set
Device C
1.0.0.2/24 4.0.0.1/24
co
st
=
10
1.0.0.1/24 Link T 10 Device D

=
st
co
4.0.0.2/24 100.1.1.1/24
Device A
co cost = 10
st
10
= 3.0.0.2/24
2.0.0.1/24
=
30
st
co
2.0.0.2/24 3.0.0.1/24
Device B
Trigger conditions
1. The set-overload [ on-startup ] command is run in the IS-IS view on Router C to set the
overload bit for non-pseudonode LSPs.
2. The default-route-advertise command is run in the IS-IS view on Router C to advertise
default routes.
Symptom
The set-overload or set-overload on-startup command is run in the IS-IS view on Router C.
However, 600s after the device is restarted, services are not switched to the backup path from
default routes.

Run the display isis process-id lsdb local verbose command in the user view to check LSP
information. If the OL bit is 1 and default routes are advertised, the problem has occurred.
The content bold indicates that the OL bit is set to 1 and that default routes are advertised.
<HUAWEI> display isis 1 lsdb local verbose
ATTENTION: System is overloaded
Manual overload set YES OverLoad on Startup NO
System Memory Low NO Memory Allocate Failure NO
Level-2 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL
-------------------------------------------------------------------------------
abcd.0001.0031.00-00* 0x0000008e 0x6726 1183 76 0/0/1
SOURCE abcd.0001.0031.00
NLPID IPV4
AREA ADDR 10
INTF ADDR 10.10.1.1
INTF ADDR 30.1.1.2
+NBR ID aaaa.0001.0030.00 COST: 10
+IP-Extended 10.10.1.1 255.255.255.255 COST: 0
+IP-Extended 30.1.1.0 255.255.255.0 COST: 10
abcd.0001.0031.00-01* 0x00000001 0x289a 1179 34 0/0/0
SOURCE abcd.0001.0031.00
+IP-Extended 0.0.0.0 0.0.0.0 COST: 0
*(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended),
ATT-Attached, P-Partition, OL-Overload
Root Cause
Default route advertisement is not affected although the OL bit is set to 1.
Impact and Risk

If no specific routes are available, services will be interrupted.

Recovery measures
During the cutover, run the undo default-route advertise command in the IS-IS view. After
the cutover, run the default-route advertise command again.
[HUAWEI] isis 1
[HUAWEI-isis-1] undo default-route-advertise
Workarounds
None
Preventive measures
4.6.1.5 IPv6 Service Forwarding Failure on an Interface That Does Not Support
IPv6 in an IS-IS IPv6 Standard Topology
In an IS-IS IPv6 standard topology, IPv4 and IPv6 services share the same shortest path trees
(SPTs). If the outbound interface of a device on one of the SPTs does not support IPv6, IPv6
services are interrupted.

Problem Description
As in Figure 4-7, IS-IS neighbor relationships are established between devices A and C,
between A and B, between C and D, and between B and D. IS-IS IPv4 and IPv6 services are
deployed, and the IPv6 standard topology is used.
Figure 4-7 Networking diagram for IPv6 service forwarding failure on an interface that does
not support IPv6 in an IS-IS IPv6 standard topology
Device C
co
st
3 =
Link T 4 Device D
=
st
co
Device A
cost = 10
co
6
st
=
= st
co
5
IPv4 topology
Device B
IPv6 topology
Trigger conditions
There is a high probability that the problem occurs if the following conditions are met:
1. Run the ipv6 enable topology standard command in the IS-IS process view to enable
IPv6 for the process and set the topology type to standard.
2. The outbound interface of a device on one SPT does not support IPv6.
Symptom
IPv6 services fail to be forwarded.
1. Run the display current-configuration configuration isis command in the user view to
check whether the ipv6 enable topology standard command is run in the IS-IS process.
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ipv6 enable topology standard

#
#
return
2. Run the display isis process-id interface verbose command in the user view to check
the IS-IS interface status and topology mode. In the command output, locate the interface
with IPV4.State being Up, IPV6.State being Down, and Circuit MT State being
Standard. In this example, GE1/0/0.1 is the faulty outbound interface.
<HUAWEI> display isis 1001 interface verbose
Interface information for ISIS(1001)
------------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
GE1/0/0.1 001 Up Down 1497 L1/L2 --
Circuit MT State : Standard
Circuit Parameters : p2p
Description : HUAWEI, GigabitEthernet1/0/0.1 Interface
SNPA Address : 781d-ba56-fa3a
IP Address : 20.1.1.6
IPV6 Link Local Address :
IPV6 Global Address(es) :
Csnp Timer Value : L12 10
Hello Timer Value : 10
DIS Hello Timer Value :
¡¡
3. Run the display current-configuration interface interface-name command in the user

view to check whether IPv6 is enabled on the outbound interface. The isis ipv6 enable
command is not enabled on the interface, indicating that the problem described may
occur.
<HUAWEI> display current-configuration interface GigabitEthernet1/0/0.1
#
ip address 1.2.0.1 255.255.255.0
isis enable 1
#
Root Cause
During route calculation, IS-IS fails to identify the interfaces that do not support IPv6 when
IPv4 and IPv6 services share the same topology.
Impact and Risk

When IPv6 service traffic reaches the interface that does not support IPv6, the traffic is
interrupted.

Recovery measures
Configure IPv6 on this problem interface.
[HUAWEI] interface GigabitEthernet1/0/0.1
[HUAWEI-interface-GigabitEthernet1/0/0.1] display this
#
ipv6 enable
ip address 1.2.0.1 255.255.255.0
ipv6 address auto link-local
isis enable 1
isis ipv6 enable 1


#
Workarounds
None
Preventive measures
Deploy an IS-IS IPv6 topology for IPv6 services to isolate IPv6 route calculation from IPv4
route calculation.
[HUAWEI] isis 1
[HUAWEI-isis-1] display this
#
isis 1
cost-style wide
network-entity 10.0000.0000.0001.00
#
ipv6 enable topology ipv6
#
#
return
4.6.2 BGP
4.6.2.1 BGP Route Flapping Due to a BGP Route Priority Change
A device sends a static route to a peer device using OSPF, and the peer device sends the route
back using BGP. If the preference command is run in the BGP view and the configured BGP
route priority is higher than the static route's priority, BGP route flapping occurs.
Problem Description
In Figure 4-8,
1. Router A imports a static route to the OSPF routing table and sends the route to Router B
using OSPF.
2. Device B imports the route to the BGP routing table and then sends the route back to
Router A using BGP.
3. The preference command is run in the BGP view, and the configured BGP route priority
is higher than the static route's priority. As a result, the static route becomes inactive. In
this case, OSPF deletes this route and also instructs Router B to delete it.
4. Device B deletes the BGP route and also instructs Router A to delete it. After Router A
deletes the BGP route, the static route becomes active again. Then, OSPF re-imports the
static route, indicating that the processing goes back to step 1. The processing keeps
repeating. As a result, route flapping occurs.
Figure 4-8 Networking diagram for BGP route flapping due to a BGP route priority change
Device A Device B

Trigger conditions
1. An OSPF neighbor relationship and a BGP peer relationship are established between
Router A and Router B.
2. A static route is configured on Router A and imported to the OSPF routing table.
3. The import-route or network command is run on Router B to import the route to the
BGP routing table.
4. The preference command is run in the BGP view on Router A, and the configured BGP
route priority is higher than the static route's priority.
Symptom
Route flapping occurs, adversely affecting services.
1. Check the IP routing table multiple times on Router A. The following example shows
that the protocol of the route to 20.0.0.0 shifts between static and IBGP alternately.
<HUAWEI> display ip routing-table 20.0.0.0 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Protocol: Static Process ID: 0
State: Active Adv Age: 04h36m27s
Tag: 0 Priority: medium
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: NULL0
TunnelID: 0x0 Flags: D
------------------------------------------------------------------------------
Summary Count : 2
Protocol: IBGP Process ID: 0
State: Active Adv Relied Age: 00h00m00s
Tag: 0 Priority: low
IndirectID: 0x1ee
RelayNextHop: 0.0.0.0 Interface: Vlanif503
TunnelID: 0x0 Flags: RD
State: Inactive Adv Age: 04h36m28s
IndirectID: 0x0
RelayNextHop: 0.0.0.0 Interface: NULL0
TunnelID: 0x0 Flags:
2. Check the IP routing table multiple times on Router B. The following example shows
that route flapping exists too.


------------------------------------------------------------------------------
Summary Count : 1
Protocol: O_ASE Process ID: 20
IndirectID: 0x0
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x0
------------------------------------------------------------------------------
Summary Count : 1
IndirectID: 0x0
Root Cause
The preference command configuration is not proper.
Impact and Risk

Route flapping occurs, adversely affecting services.

Recovery measures
Measure 1: Delete the preference command configuration from the BGP public network IPv4
address family on Router A.
Measure 2: Change the static route's priority to a value smaller than the one configured using
the preference command.
Workarounds

Preventive measures
4.7 IP Multicast
4.7.1 PIM
4.7.1.1 Multicast Service Interruption Because PIM Is Not Enabled on a Backup

Link
If equal-cost routes or multiple links are available for Layer 3 multicast services, and PIM is
enabled on the interface of only one of the links, multicast services are interrupted during a
link switchover.
Problem Description
Multiple links or equal-cost routes are available for multicast services.
Trigger conditions
l PIM is enabled on the interface of only one being used of the equal-cost routes or
multiple links.
l PIM is not enabled on the interface of the link after swithover because of the changes on
configurations, routes or links.
Symptom
PIM routes are unavailable, and multicast services are interrupted.
Run the display pim [ vpn-instance vpn-instance-name | all-instance ] interface [ interface-

type interface-number | up | down ] and display pim ipv6 interface [ interface-type
interface-number | up | down ] commands to check whether PIM is enabled on the interfaces
of equal-cost routes or multiple links.
If PIM is enabled on all the interfaces, the problem described in this precaution notice will not
occur.
<HUAWEI> display pim interface Ethernet1/0/0
VPN-Instance: public net
Interface State NbrCnt HelloInt DR-Pri DR-Address
Ethernet1/0/0 up 1 30 1 1.1.1.1
Root Cause
After multicast services are switched to a backup link on which PIM is not enabled, multicast
route selection fails, and no multicast forwarding entries can be used.

Impact and Risk

Multicast services are interrupted on the link on which PIM is not enabled.

Recovery measures
Enable PIM on all equal-cost links.
Workarounds
Preventive measures
4.8 MPLS
4.8.1 MPLS LDP
4.8.1.1 Incorrect LDP Session Status Due to Parameter Configuration

Inconsistency When Local and Remote LDP Sessions or Multiple Links Coexist
When local and remote LDP sessions or multiple links exist between two LSRs, an LDP
session can be established on only one of the links or cannot be established.
Problem Description
Local and remote LDP sessions or multiple links exist between two LSRs, and the problem
described may occur in the following scenarios:
1. Multiple links are available. Figure 4-9 shows an example.

2. Local and remote LDP sessions coexist. Figure 4-10 shows an example.
3. Multiple links and local and remote LDP sessions coexist. Figure 4-11 shows an
example.
Figure 4-9 Multi-link networking
Local Adjacency
LSR1 Local Adjacency LSR2

Figure 4-10 Local and remote coexistent LDP session
Remote Adjacency
LSR3
Local Adjacency
LSR1 LSR2
Figure 4-11 Multi-link local and remote coexistent LDP session
Remote Adjacency
LSR3
Local Adjacency
LSR1 Local Adjacency LSR2
Trigger conditions
There is a high probability that the problem occurs if LDP adjacencies with the same peer ID
exist in the output of the display mpls ldp adjacency all command in the user view.
Symptom
Symptom of customer services:
1. Some discovery sources of the LDP session cannot be bound. As a result, LDP LSPs
cannot balance traffic or session protection does not take effect for coexisting local and
remote sessions.

2. LDP sessions fail to be set up, interrupting services.
Symptom of services on the device:
1. LDP peers exist, but LDP sessions cannot be established.

# Run the display mpls ldp peer peer-id command in the user view to check LDP peer
information. The following command output shows that a specified LDP peer exists.
<HUAWEI> display mpls ldp peer 1.1.1.1
LDP Peer Information in Public network
------------------------------------------------------------------------------
Peer LDP ID : 1.1.1.1:0

Peer Max PDU Length : 4096 Peer Transport Address :
2.2.2.2
Peer Loop Detection : Off Peer Path Vector Limit :
----
Peer FT Flag : Off Peer Keepalive Timer : 45
Sec
Recovery Timer : ---- Reconnect Timer :
----
Peer Type : Local
Peer Label Advertisement Mode : Downstream
Unsolicited
Peer Discovery Source :
GigabitEthernet1/0/0
Peer Deletion Status : No
Capability-Announcement : Off
Peer mLDP P2MP Capability : Off
Peer mLDP MP2MP Capability : Off
Peer mLDP MBB Capability : Off
------------------------------------------------------------------------------
# Run the display mpls ldp session peer-id command in any view to check information
about LDP sessions between LDP peers. If Session State is not Operational, the LDP
session of the specified peer ID is not established.
<HUAWEI> display mpls ldp session 4.4.4.4
LDP Session Information
------------------------------------------------------------------------------
Peer LDP ID : 4.4.4.4:0 Local LDP ID : 5.5.5.5:0
TCP Connection : Not established
Session State : NonExistent Session Role : Active
Session FT Flag : Off MD5 Flag : On
Reconnect Timer : --- Recovery Timer : ---
Keychain Name : ---
Authentication applied : Peer
# In the multi-LDP instance scenario, run the display mpls ldp peer peer-id and display
mpls ldp session peer-id commands. Use the peerID 4.4.4.4 and VPN instance vpn1 as
an example.
<HUAWEI> display mpls ldp peer vpn-instance vpn1 4.4.4.4
LDP Peer Information in VPN-Instance: vpn1
------------------------------------------------------------------------------
Peer LDP ID : 4.4.4.4:0
VPN-Instance : vpn1
Peer Max PDU Length : 4096 Peer Transport Address : 4.4.4.4
Peer Loop Detection : Off Peer Path Vector Limit : ----
Peer FT Flag : Off Peer Keepalive Timer : 45 Sec
Recovery Timer : ---- Reconnect Timer : ----
Peer Type : Local
Peer mLDP MBB Capability : Off
------------------------------------------------------------------------------

<HUAWEI> display mpls ldp session vpn-instance vpn1 4.4.4.4

LDP Session Information
------------------------------------------------------------------------------
Peer LDP ID : 4.4.4.4:0 Local LDP ID : 11.5.6.5:0
VPN-Instance : vpn1
TCP Connection : 11.5.6.5 -> 4.4.4.4
Session State : NonExistent Session Role : Active
Session FT Flag : Off MD5 Flag : Off
Reconnect Timer : --- Recovery Timer : ---
Keychain Name : ---
Authentication applied : ---
1. Run the display mpls ldp adjacency all command in the user view to check LDP
adjacency information. If no adjacency information is displayed, the problem described
will not occur. If adjacency information is displayed, further check is needed.
The same peer IDs in bold indicates a multi-link scenario or a local and remote
coexistent LDP session scenario. Check peer IDs of 1.1.1.2, 1.1.1.3, and 6.6.6.6.
<HUAWEI> display mpls ldp adjacency all
LDP Adjacency Information in Public
Network
Codes: R: Remote Adjacency, L: Local
Adjacency
A '*' before an adjacency means the adjacency is being
deleted.
------------------------------------------------------------------------------
SN SourceAddr PeerID VrfID AdjAge(DDDD:HH:MM) RcvdHello

Type
------------------------------------------------------------------------------
1 2.2.2.1 1.1.1.2 0 0000:00:37 449

L
2 2.2.1.1 1.1.1.4 0 0000:00:04 57
L
3 1.1.1.2 1.1.1.2 0 0000:00:09 148 R
4 3.3.3.3 1.1.1.2 0 0000:00:00 11
L
5 2.2.3.1 1.1.1.3 0 0000:00:20 258 L
6 1.1.1.2 1.1.1.3 0 0000:00:20 76
R
------------------------------------------------------------------------------
LDP Adjacency Information in VPN-Instance: vpn1

Codes: R: Remote Adjacency, L: Local Adjacency
A '*' before an adjacency means the adjacency is being deleted.
------------------------------------------------------------------------------
SN SourceAddr PeerID VrfID AdjAge(DDDD:HH:MM) RcvdHello Type
------------------------------------------------------------------------------
1 2.3.2.1 6.6.6.6 1 0000:00:08 103 L
2 2.4.2.1 6.6.6.6 1 0000:00:02 33 L
------------------------------------------------------------------------------
TOTAL: 8 Record(s) found.
2. Check LDP adjacencies with the same peer ID.

# In the case of local adjacencies, run the display ip routing-table ip-address command
in the user view to determine the corresponding outbound interfaces. The peer ID 1.1.1.2
has two local adjacencies 2.2.2.1 and 3.3.3.3 and a remote adjacency 1.1.1.2.

<HUAWEI> display ip routing-table 2.2.2.1

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

Summary Count : 1
Destination/Mask Proto Pre Cost Flags NextHop Interface
2.2.2.1/32 Direct 0 0 D 127.0.0.1
# Run the display current-configuration interface interface-type interface-number

command in the user view to check configurations on the interface. LDP is enabled on
the interface.
<HUAWEI> display current-configuration interface GigabitEthernet 1/0/0
#
undo shutdown
ip address 2.2.2.1 255.255.255.0
isis enable 1
mpls
mpls ldp
dcn
#
# If a private route is used, run the display ip routing-table vpn-instance vpn-instance-

name ip-address command in any view to check the outbound interface of the route.
<HUAWEI> display ip routing-table vpn-instance vpn1 2.3.2.1
------------------------------------------------------------------------------
Routing Table : vpn1
Summary Count : 1
2.4.2.0/24 Direct 0 0 D 10.5.6.5 Ethernet0/0/1
# In the case of remote adjacencies, run the display mpls ldp remote-peer peer-id peer-
id command in the user view to check information about a remote LDP peer.
<HUAWEI> display mpls ldp remote-peer peer-id 1.1.1.2
LDP Remote Entity

Information
------------------------------------------------------------------------------
Remote Peer Name : 5to3

Remote Peer IP : 1.1.1.2 LDP ID :
1.1.1.1:0
Transport Address : 1.1.1.1 Entity Status :
Active
Configured Keepalive Hold Timer : 45 Sec

Configured Keepalive Send Timer : ---
Configured Hello Hold Timer : 45 Sec
Negotiated Hello Hold Timer : 45 Sec
Configured Hello Send Timer : ---
Configured Delay Timer : 10 Sec
Hello Packet sent/received : 272/271
Label Advertisement Mode : Downstream
Unsolicited
Remote Peer Deletion Status : No
Auto-config : ---
------------------------------------------------------------------------------
# Run the display current-configuration configuration mpls-ldp-remote name

command in the user view to check configurations on the remote peer. A remote
adjacency is established with the remote peer.

<HUAWEI> display current-configuration configuration mpls-ldp-remote

5to3
#
mpls ldp remote-peer 5to3
remote-ip 1.1.1.2
#
return
3. If the preceding outbound interface or LDP remote peer has any of the following
configurations, the problem described may occur:
– The mpls ldp transport-address command is run in all or part of local interface
views of the same LDP peer, but the specified transport addresses are different.
– The mpls ldp transport-address command is run in all or part of local interface
views of the same VPN LDP peer, but the specified transport addresses are
different.
– The mpls ldp timer keepalive-hold command is run in all or part of local interface
views and LDP remote views of the same LDP peer, but the specified Keepalive
hold intervals are different.
– The mpls ldp timer keepalive-send command is run in all or part of local interface
views and LDP remote views of the same LDP peer, but the specified Keepalive
send intervals are different.
– The mpls ldp advertisement command is run in all or part of local interface views
and LDP remote views of the same LDP peer, but the specified label advertisement
modes are different.
– The mpls ldp local-lsr-id command is run in all or part of local interface views and
LDP remote views of the same LDP peer, but the specified interfaces are different.
Root Cause
The parameters specified in the mpls ldp transport-address, mpls ldp timer keepalive-
hold, mpls ldp timer keepalive-send, mpls ldp advertisement, or mpls ldp local-lsr-id
command are different among adjacencies when establishing an LDP session.
Impact and Risk

When local and remote LDP sessions or multiple links exist between two LSRs, an LDP
session can be established on only one of the links or cannot be established.

Recovery measures
When local and remote LDP sessions or multiple links exist, ensure parameter configuration
consistency in LDP interface views and LDP remote views.
1. Configure the same transport address when running the mpls ldp transport-address
command in all or part of local interface views of the same LDP peer, or use the default
transport address.
2. Configure the same transport address when running the mpls ldp transport-address
command in all or part of local interface views of the same VPN LDP peer.
3. Configure the same Keepalive hold interval when running the mpls ldp timer
keepalive-hold command in all or part of local interface views and LDP remote views of
the same LDP peer, or use the default Keepalive hold interval.

4. Configure the same Keepalive send interval when running the mpls ldp timer
keepalive-send command in all or part of local interface views and LDP remote views of
the same LDP peer, or use the default Keepalive send interval.
5. Configure the same label advertisement mode when running the mpls ldp
advertisement command in all or part of local interface views and LDP remote views of
the same LDP peer, or use the default label advertisement mode.
6. Configure the same interface when running the mpls ldp local-lsr-id command in all or
part of local interface views and LDP remote views of the same LDP peer, or use the
default interface.
Workarounds
Preventive measures
4.8.1.2 LSP Traffic Loss Because LDP-IGP Synchronization Is Not Enabled on an

LDP Interface
LDP is enabled on an interface, but LDP-IGP synchronization is not enabled. An LDP session
flaps or the primary link fails, and then traffic is switched to a backup link. After the LDP
session becomes stable or the link recovers, traffic is switched back. However, LSP traffic
forwarding is affected or interrupted.
Problem Description
LDP convergence is slower than IGP route convergence. As a result, LSP traffic may be lost.
As shown in Figure 4-12.
l When the primary link fails, both the IGP route and LSP are switched to the backup link.
When the primary link recovers, the IGP route is switched back to the primary link
earlier than the LDP LSP because IGP route convergence is faster than LDP
convergence. As a result, LSP traffic is lost.
l If an IGP runs normally on the primary link, but the LDP session between nodes on the
primary link fails, the IGP route still uses the primary link, but the LSP of the primary
link is deleted. Because the optimal IGP route does not use the backup link, no LSP can
be set up on the backup link. As a result, LSP traffic is lost.

Figure 4-12 Networking diagram for LSP traffic loss because LDP-IGP synchronization is
not enabled on an LDP interface
The primary tunnel

1 recovers after a physical
fault is cleared
LSR3
The IGP status is Up
2 but the LDP session
goes Down on the
primary tunnel
LSR1 LSR2 LSR5 LSR6
LSR4
Primary tunnel
Backup tunnel
Trigger conditions
There is a high probability that the problem occurs if LDP is enabled on an interface but LDP-
IGP synchronization is not enabled.
Symptom
No LSP information is displayed in the output of the display mpls lsp protocol ldp include
ip-address 32 command, indicating that the LDP LSP to the specified destination IP address is
not established. After an LDP session becomes stable or the primary link recovers, it takes a
long time for the LDP LSP traffic to recover, affecting LSP services or causing a service
interruption.
Run the display current-configuration interface command in the user view to check
interface configurations. If MPLS LDP is enabled on the interface, but LDP-IGP
synchronization is not, the problem described may occur.
The following command output shows that MPLS LDP is enabled in the interface view, and
LDP is associated with IS-IS and OSPF.
<HUAWEI> display current-configuration interface
#
undo shutdown
mtu 9192
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis ldp-sync

isis timer ldp-sync hold-max-cost infinite

ospf ldp-sync
ospf timer ldp-sync hold-max-cost
infinite
mpls
mpls ldp
dcn
negotiation auto
#
¡¡
Root Cause
1. When the primary link fails, both the IGP route and LSP are switched to the backup link.
When the primary link recovers, the IGP route is switched back to the primary link
earlier than the LDP LSP because IGP route convergence is faster than LDP
convergence. As a result, LSP traffic is lost.
2. If an IGP runs normally on the primary link, but the LDP session between nodes on the
primary link fails, the IGP route still uses the primary link, but the LSP of the primary
link is deleted. Because the optimal IGP route does not use the backup link, no LSP can
be set up on the backup link. As a result, LSP traffic is lost.
Impact and Risk

LSP traffic forwarding is affected or interrupted during traffic switchback after the LDP
session flapping or link failure on the primary link is resolved.

Recovery measures
Configure LDP-IGP synchronization on the LDP-capable interface, and set the value of the
hold-max-cost timer to infinite. IS-IS and OSPF are commonly used as an IGP. You can
determine to use which one as required.
#
undo shutdown
mtu 9192
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis ldp-sync
isis timer ldp-sync hold-max-cost infinite
ospf ldp-sync
ospf timer ldp-sync hold-max-cost
infinite
mpls
mpls ldp
¡¡
Workarounds
Preventive measures

4.8.2 MPLS TE
4.8.2.1 Failure to Establish an Inter-IGP Area TE Tunnel because the Explicit Path
that Contains IP Addresses of Inter-area Nodes is not Configured
To establish a TE tunnel that spans multiple IGP areas, an explicit path that contains IP
addresses of inter-area nodes must be configured, and CSPF must be enabled on the ingress
and inter-area nodes.
Problem Description
A TE tunnel that spans multiple IGP areas needs to be established.
Figure 4-13 Diagram for TE tunnel that spans multiple IGP areas
Area1 Area2 Area3
Device A Device B Device C Device D
As shown in Figure 4-13, a TE tunnel needs to be established between RouterA and RouterD.
The outbound interface of RouterA and the inbound interface of RouterB belong to area 1.
The outbound interface of RouterB and the inbound interface of RouterC belong to area 2.
The outbound interface of RouterC and the inbound interface of RouterD belong to area 3.
RouterB and RouterC are inter-area nodes.
Trigger conditions
l No explicit path that contains IP addresses of inter-area nodes is configured.
l CSPF is enabled on all the devices along the tunnel.
Symptom
The TE tunnel fails to be established.
1. Run the display current-configuration configuration mpls command in the user view
to check global MPLS configurations.
In the following example, mpls te and mpls te cspf is configured.
<HUAWEI> display current-configuration configuration mpls
#
mpls lsr-id 1.1.1.1
#

mpls
mpls te
mpls rsvp-te
mpls te cspf
#
return
2. Run the display current-configuration interface tunnel-name command in the user

view to check the destination IP address and explicit path of the tunnel.
In the following example, the destination IP address is 4.4.4.4 and the explicit path of the
tunnel is huawei .
#
destination 4.4.4.4
mpls te record-route
mpls te backup hot-standby
mpls te tunnel-id 1
mpls te path explicit-path huawei
#
return
3. Run the display mpls te cspf tedb all command in the user view to check CSPF TEDB
information. If the destination IP address of the tunnel is not displayed in the command
output, multiple IGP areas exist in the scenario.
In the following example, the destination IP address (4.4.4.4) of Tunnel0/0/1 is not
displayed in the TEDB.
<HUAWEI> display mpls te cspf tedb all
Maximum Nodes Supported: 2000 Current Total Node Number: 4
Maximum Links Supported: 8000 Current Total Link Number: 6
Maximum SRLGs supported: 10000 Current Total SRLG Number: 0
Id Router-Id IGP Process-Id Area Link-Count
1 1.1.1.1 ISIS 1 Level-1 2
2 2.2.2.2 ISIS 1 Level-1 1
3 1.1.1.1 ISIS 1 Level-2 2
4 2.2.2.2 ISIS 1 Level-2 1
4. Check whether an explicit path is configured for the tunnel.

– If no explicit path is configured, configure an explicit path that contains IP
addresses of inter-area nodes.
– If an explicit path is configured, run the display current-configuration
configuration explicit-path explicit-name command to check whether the explicit
path contains IP addresses of inter-area nodes.
<HUAWEI> display current-configuration configuration explicit-path test
#
explicit-path test
next hop 192.168.1.2 include loose
#
Root Cause
Routers in an IGP area cannot obtain the TEDB information in other areas. Therefore, an
explicit path that contains IP addresses of inter-area nodes is required.
Impact and Risk

The TE tunnel that spans multiple IGP areas fails to be established.


Recovery measures
Configure an explicit path that contains IP addresses of inter-area nodes and enable CSPF on
the ingress and inter-area nodes.
Workarounds
Preventive measures
4.8.2.2 RSVP-TE GR Failure Because the RSVP-TE Hello Mechanism Is Not

Configured
The mpls rsvp-te hello support-peer-gr or mpls rsvp-te hello full-gr command is run in the
MPLS view, but the mpls rsvp-te hello command is not run on RSVP-TE interfaces. As a
result, RSVP-TE GR does not take effect.
Problem Description
RSVP-TE GR is configured.
Trigger conditions
The problem occurs if the RSVP-TE Hello mechanism is not configured on RSVP-TE
interfaces.
Symptom
RSVP-TE GR does not take effect.
1. Run the display current-configuration configuration mpls command in the user view
to check global MPLS configurations. Check whether the mpls rsvp-te hello support-
peer-gr or mpls rsvp-te hello full-gr command is run.
#
mpls lsr-id 1.1.1.1
#
mpls
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls rsvp-te hello support-peer-gr
mpls te cspf
#
return
2. Run the display current-configuration interface command in the user view to check
whether the mpls rsvp-te command is run on the RSVP-TE interface.1. If it is run, check
whether the mpls rsvp-te hello command is also run.
#
interface Ethernet3/0/0

undo shutdown
ip address 192.168.21.1 255.255.255.0
isis enable 1
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 100000
mpls te bandwidth bc0 100000
mpls rsvp-te
mpls rsvp-te hello
#
Root Cause
RSVP-TE GR depends on the RSVP-TE Hello mechanism. If the Hello mechanism is not
configured, RSVP-TE GR does not take effect.
Impact and Risk

RSVP-TE GR does not take effect. When the active/standby switchover is performed between
RSVP nodes, the RSVP neighbor relationship is torn down because of signaling protocol
timeout. As a result, the CR-LSP is deleted, interrupting services on the CR-LSP.

Recovery measures
Run the mpls rsvp-te hello command in interface view to enables the Hello mechanism.
Workarounds
When deploying RSVP-TE GR, configure the RSVP-TE Hello mechanism on RSVP-TE
interfaces.
Preventive measures
4.8.2.3 Unexpected CSPF Route Calculation Result in an IGP Multi-Process or

Multi-Area Scenario
Multiple MPLS TE-enabled IGP processes are configured on a device. The CSPF algorithm is
used to calculate the optimal TE tunnel path. However, the optimal path cannot be selected
from the multiple IGP processes. As a result, the optimal path calculated from a single process
is not the one expected by the customer, which may cause service congestion or interruptions.
Problem Description
As in Figure 4-14, TE tunnels are configured on a device. The tunnel passes through multiple
paths that belong to different IGP processes.
A TE tunnel is established between the ingress ASG1 and the egress RSG1, and multiple
paths are available for the tunnel. In normal cases, the path marked red in the preceding figure
is selected as the optimal path. After route flapping occurs in IS-IS process 2119 and TE re-
optimization is performed, the path marked blue is selected as the optimal path.

Figure 4-14 Networking diagram for unexpected CSPF route calculation result in an IGP
multi-process or multi-area scenario
CSG1
ISIS 2119
ASG1 RSG1
ISIS 1000
ASG2 ASG3
Trigger conditions
1. A TE tunnel is established between the ingress and the egress.

2. Multiple IGP processes are deployed on the ingress and the egress.
3. The optimal path for the TE tunnel is calculated automatically based on IGP routes. No
explicit paths or path constraints are deployed.
Symptom
1. The optimal TE tunnel path is not the one expected by the customer. Service congestion
or an interruption occurs.
# Run the display current-configuration interface Tunnel 0/0/1 command in the user
view and check whether the device is enabled to record routes. In the following example,
Tunnel0/0/1 is used as an example.
#
destination 4.4.4.4
#
Return

NOTE
If the mpls te record-route label command is run, run the display mpls te tunnel path Tunnel0/0/1
command to check the path of the TE tunnel. Otherwise, run the tracert lsp te Tunnel 0/0/1 command
to check the path.
# Run the display mpls te tunnel path Tunnel0/0/1 command in the user view and
check the path along which a tunnel passes.
<HUAWEI> display mpls te tunnel path Tunnel0/0/1
Lsp ID : 3.3.3.3 :100 :3
Hop Information
Hop 0 3.3.3.3
Hop 1 10.1.1.1
Hop 2 10.1.1.2
Hop 3 2.2.2.2
# Run the tracert lsp te Tunnel 0/0/1 command in the user view and check the path
along which a tunnel passes.
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel0/0/1, press CTRL_C
to break.
0 Ingress 10.1.2.1/[3 ]
1 3.3.3.3 32 ms Egress
Obtain the path through which the tunnel passes and check whether the actual path and
planned path match each other. If a mismatch occurs, the problem has occurred.
1. Check whether MPLS TE, RSVP-TE, and CSPF are enabled.
# Run the display current-configuration configuration mpls command in the user
view to check whether the MPLS TE, RSVP-TE, and CSPF functions are enabled. If all
the three functions are enabled, the problem described may occur, and a further check is
needed. If any of the three functions is not enabled, the problem described will not occur.
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
return
2. Check whether multiple IS-IS or OSPF processes exist.

# Run the display current-configuration configuration isis or display current-
configuration configuration ospf command in the user view to check whether multiple
IS-IS or OSPF processes are configured. If multiple IS-IS or OSPF processes are
configured, the problem described may occur, and a further check is needed.
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0002.0001.00
traffic-eng level-2
#
isis 2
is-level level-2
cost-style wide
network-entity 10.0000.0002.0002.00
traffic-eng level-2
…

#
#
ospf 1
opaque-capability enable
area 0.0.0.0
network 1.1.1.2 0.0.0.0
network 2.2.2.1 0.0.0.0
network 11.2.1.0 0.0.0.255
network 20.20.20.20 0.0.0.0
mpls-te enable
#
ospf 2
area 0.0.0.0
network 101.1.10.0 0.0.0.255
network 101.1.11.0 0.0.0.255
…
3. Check whether TE is enabled in the IS-IS or OSPF process.
# Run the display current-configuration configuration isis or display current-
configuration configuration ospf command in the user view to check whether TE is
enabled for IS-IS or OSPF. If TE is enabled for more than one IS-IS or OSPF process,
the problem described may occur, and Step 5 is required. If TE is enabled for only one
OSPF process, Step 4 is required. If TE is enabled for only one IS-IS process, the
problem described will not occur.
#
isis 1
is-level level-2
cost-style wide
network-entity 10.0000.0002.0001.00
traffic-eng level-2
#
#
ospf 1
area 0.0.0.0
network 1.1.1.2 0.0.0.0
network 2.2.2.1 0.0.0.0
network 11.2.1.0 0.0.0.255
network 20.20.20.20 0.0.0.0
mpls-te enable
4. Check whether multiple OSPF areas are configured.
# Run the display current-configuration configuration ospf command in the user view
to check whether more than one OSPF area is configured. If multiple OSPF areas are
configured and MPLS TE is enabled for each area, the problem described may occur,
and a further check is needed.
#
ospf 1
area 0.0.0.0
network 1.1.1.2 0.0.0.0
mpls-te enable
area 0.0.0.9
network 1.1.1.9 0.0.0.0
mpls-te enable
5. Check the route along which a TE tunnel passes.
Run the display mpls te tunnel path Tunnel tunnel-number command in the user view
to check the path of the TE tunnel. If the path is not the one expected by the customer,
the problem has occurred. In this case, take recovery measures. The tunnel named
Tunnel0/0/1 is used as an example


#
destination 4.4.4.4
#
return
If the mpls te record-route label command is run, run the display mpls te tunnel path
Tunnel0/0/1 command to check the path of the TE tunnel. Otherwise, run the tracert lsp
te Tunnel 0/0/1 command to check the path.
<HUAWEI> display mpls te tunnel path Tunnel0/0/1
Lsp ID : 3.3.3.3 :100 :3
Hop Information
Hop 0 3.3.3.3
Hop 1 10.1.1.1
Hop 2 10.1.1.2
Hop 3 2.2.2.2
LSP Trace Route FEC: TE TUNNEL IPV4 SESSION QUERY Tunnel0/0/1 , press
CTRL_C to break.
0 Ingress 10.1.2.1/[3 ]
1 3.3.3.3 32 ms Egress
Root Cause
Each time MPLS TE is enabled for an IGP process, CSPF is instructed to update the TEDB
information. CSPF calculates the optimal path for the TE tunnel only from the IGP process
that is last updated to the TEDB. Consequently, the optimal path may be not the one expected
by the customer.
Impact and Risk

The optimal path calculated from a single process is not the one expected by the customer,
which may cause service congestion or interruptions.

Recovery measures
Same as the solutions
Workarounds
Same as the solutions
Preventive measures
1. Primary measure: Configure an explicit path in the system view and apply it to the TE
tunnel. An explicit path named pri1 is used as an example.
# Run the explicit-path pri1 command in the system view to configure an explicit path
named pri1.
[HUAWEI] explicit-path pri1
[HUAWEI-explicit-path-pri1] display this
#

explicit-path pri1
next hop 1.3.1.1
next hop 3.4.1.3
#
return
# Run the mpls te path explicit-path pri1 command in the TE tunnel interface view to
configure an explicit path named pri1.
[HUAWEI] interface Tunnel 0/0/1
#
destination 4.4.4.4
mpls te fast-reroute
mpls te path explicit-path pri1
#
return
After an explicit path is configured in the TE tunnel interface view, you need to run the
mpls te commit command to commit the configuration.
NOTE
In the case of an IGP inter-area scenario, the configured explicit path must pass through the ABR, and
CSPF must be enabled on the ABR.
Explicit path constraints must also be configured for the hot-standby LSP. Otherwise, the problem
described may occur.
2. Alternative measure: Run the preferred-igp command in the MPLS view to enable
CSPF to preferentially select the optimal route from a specified IGP process.
# In the case of an IS-IS multi-process scenario, run the mpls te cspf preferred-igp isis
1 command in the MPLS view to enable CSPF to preferentially select the optimal route
from IS-IS process 1.
[HUAWEI] mpls
[HUAWEI-mpls] display this
mpls lsr-id 1.1.22.13
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
mpls te cspf preferred-igp isis 1
#
return
# In the case of an OSPF multi-process scenario, run the mpls te cspf preferred-igp
ospf 1 area 0.0.0.0 command in the MPLS view to enable CSPF to preferentially select
the optimal route from OSPF process 1 in area 0. The area parameter is optional.
[HUAWEI] mpls
[HUAWEI-mpls] display this
mpls lsr-id 1.1.22.13
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls te cspf
mpls te cspf preferred-igp ospf 1 area 0.0.0.0
#
return

NOTE
Using the alternative measure as a backup is recommended. Even if CSPF is enabled to preferentially
select the optimal route from a preferred IGP process (process 1 for example), if route calculation fails
in this process due to link flapping, CSPF selects the optimal route from another process (process 2 for
example). If route calculation succeeds in process 2, an LSP is established. To switch back to the
preferred IGP process (process 1), CSPF must wait for TE re-optimization and recalculate routes.
Therefore, this alternative measure may not necessarily solve the problem described.
In addition, only one preferred process can be configured. If different TE tunnels need to use paths that
belong to different IGP process (for example, the RSG belongs to multiple aggregation rings, and each
ring runs a different IGP process), this measure is not applicable.

NE Series Router Maintenance Guide 5 Special Topic
5 Special Topic
About This Chapter
5.1 High CPU Usage

5.2 MPLS OAM Session Goes Down and a dLOCV Defect Occurs
5.3 CPU Usage for the MPLS OAM Module Is High
5.4 MPLS-TP OAM Session Goes Down and a dLOCV Defect Occurs
5.5 CPU Usage for the MPLS-TP OAM Module Is High
5.6 Multi-device Backup
5.7 L2TP
5.8 BOD
5.9 CGN

5.1 High CPU Usage
5.1.1 Change History
Date Revised Section Description
2016-06-01 N/A First release
5.1.2 NEs & Versions

This document is applicable to NE40E&80Es of V300R003, V300R0006, V600R001,
V600R002, V600R003 or a later version and CX600s of V200R002, V300R006, V600R001,
V600R002, V600R003 or a later version.
5.1.3 Background
5.1.3.1 Troubleshooting Process
If one or more tasks consume a lot of CPU resources, the CPU usage becomes high. If these
tasks consume CPU resources for such a long time that the resources cannot be scheduled to
other tasks, protocols may go Down or SSH logins fail.
High CPU usage may occur on the MPU or LPU. If the device's CPU usage rises, check
whether the high CPU usage occurs on the MPU or LPU. Then check for the tasks that are
consuming a lot of CPU resources.
The troubleshooting flowchart is as follows:

High CPU usage
Locate the task with a high CPU usage
TSD (PES), INFO, VM

SOCK, VPR, ROUT task and tAtaS
and VRS tasks tasks
Check Chec
Check
whether wheth
No whether No
route the C
an attack
flapping card i
exists
exists faulty
Yes
Yes Y
Troubleshoot
Troubleshoot the the route
attack source flapping source Rectify the
and address the and address the card fau
attack issue route flapping
issue

5.1.3.2 Common Commands
The following table lists the commands commonly used to locate the high CPU usage issue.
Table 5-1 Commands of versions earlier than V600R001

Command Function
display health Displays the CPU and memory usage on

each board.
display cpu-usage Displays detailed CPU usage on the MPU.
display cpu-usage slot slot-id Displays detailed CPU usage on an LPU.
display cpu-defend slot slot-id car index Displays CPU CAR statistics.
index Indexes of common protocols are as
follows:
l 3: LACPDU
l 8: ARP
l 27: BFD
l 48: IGMP
Table 5-2 Commands of V600R001 or a later version

Command Function
display cpu-usage Displays detailed CPU usage on the MPU.
display health Displays the CPU and memory usage on

each board.
display cpu-usage slot slot-id Displays detailed CPU usage on an LPU.
display cpu-defend car protocol protocol- Displays CPU CAR statistics.

type statistics slot slot-id
display attack-source-trace slot all Displays information about attack source

verbose tracing.
display attack-source-trace slot slot-id
verbose

NOTE
For V600R001 or later versions, the first three tasks with the highest CPU usage are logged when the
CPU usage reaches the threshold. A log example is as follows, indicating that the VT1 is the task with
the highest CPU usage.
TOR_HW_NE40E_BG1 %%01SRM/4/CPUMEMALARM(l)[12]:Board 5 CPU usage is Upper than
threshold.
TOR_HW_NE40E_BG1 %%01VOSCPU/4/CPU_USAGE_HIGH(l)[13]:The CPU is overloaded,
and the tasks with top three CPU occupancy are VT1 (98%), SRM(0%), SOCK(0%).
(CpuUsage=98%, Threshold=80%)
For versions earlier than V600R001, only the information indicating that the CPU usage reaches the
threshold is logged. Therefore, for versions earlier than V600R001, if the CPU usage is found high,
collect the display cpu-usage or display cpu-usage slot slot-id command output for further fault
locating.
5.1.4 Troubleshooting Procedure
5.1.4.1 Locating the Board with a High CPU Usage
Run the display health command to locate the board with a high CPU usage.
[HUAWEI] display health
Slot CPU Usage Memory Usage (Used/Total)
-----------------------------------------------------
18 MPU(Master) 19% 18% 158MB/873MB
1 LPU 6% 20% 77MB/401MB
2 LPU 5% 18% 72MB/401MB
3 LPU 100% 19% 74MB/401MB
5.1.4.2 Locating the Task with a High CPU Usage
Run the display cpu-usage command to locate the task with a high CPU usage.
[HUAWEI] display cpu-usage slot 3
CPU Usage Stat. Cycle : 60 (Second)
CPU Usage : 100% Max: 100%
CPU Usage Stat. Time : 2008-05-19 21:53:48
CPU Usage Stat. Tick : 0x656(CPU Tick High) 0xf3fecf72(CPU Tick Low)
Actual Stat. Cycle : 0x0(CPU Tick High) 0x780dfa32(CPU Tick Low)
TaskName CPU Runtime(CPU Tick High/CPU Tick Low)
SOCK 31% 0/25f0915d
TSD 40% 0/31357d8f
l If the TSD, PES, SOCK, VPR, or VRS task is found with a high CPU usage, the cause of
the problem may be an attack or loop. Then you need to address the attack or loop issue.
To check the rate of receiving packets, run the efu ts counter 3 rx command in the
diagnostic view repeatedly at an interval of 1 second. In this command, 3 indicates the
slot ID of the board. In the command output, locate the type of packet whose count
increases at a highest speed. Before collecting the information, run the efu ts counter 3
rx clear command to clear historical records. For example:
[HUAWEI-diagnose] efu ts counter 3 rx
query the ts debug counter receive result :
[counter name] [ value ] [counter name] [ value ] [counter name] [ value ]
R_INGRESS_CTRL 0000000351 R_EGRESS_CTRL 0000000351 R_CTRL_ERROR 0000000000
R_INGRESS_DATA 0000000000 R_EGRESS_DATA 0000502969 R_DATA_ERROR 0000000000
R_INGRESS_EVENT 0000000351 R_EGRESS_EVENT 0000001816 R_EVENT_ERROR 0000000000
V4_ARP_MISS 0000000000 V4_FWD_TBL_VLN 0000000000 V6_NDH_MISS 0000000000
V6_ND_MISS 0000000000 V6_FWD_TBL_VLN 0000000000 MPLS_ARP_MISSe 0000000000

R_ATM_INARP 0000000000 R_DATA_ATM_OAM 0000000000 R_ETH_BPDU 0000000000

R_ETH_HGMP 0000000000 R_ETH_LACP 0000000000 R_ETH_VRRP 0000000000
R_ETUNNEL_FRAG 0000000000 R_IPV4_ARP 0000000139 V4_FWD_MISS 0000000000
V4_ICMP_RDIRCT 0000000000 V4_MC_FWD_MISS 0000000000 V4_MC_FWD_R_MS 0000000000
[HUAWEI-diagnose] efu ts counter 3 rx

query the ts debug counter receive result :
[counter name] [ value ] [counter name] [ value ] [counter name] [ value ]
R_INGRESS_CTRL 0000000351 R_EGRESS_CTRL 0000000351 R_CTRL_ERROR 0000000000
R_INGRESS_DATA 0000000000 R_EGRESS_DATA 0000502969 R_DATA_ERROR 0000000000
R_INGRESS_EVENT 0000000351 R_EGRESS_EVENT 0000001816 R_EVENT_ERROR 0000000000
V4_ARP_MISS 0000000000 V4_FWD_TBL_VLN 0000000000 V6_NDH_MISS 0000000000
V6_ND_MISS 0000000000 V6_FWD_TBL_VLN 0000000000 MPLS_ARP_MISSe 0000000000
R_ATM_INARP 0000000000 R_DATA_ATM_OAM 0000000000 R_ETH_BPDU 0000000000
R_ETH_HGMP 0000000000 R_ETH_LACP 0000000000 R_ETH_VRRP 0000000000
R_ETUNNEL_FRAG 0000000000 R_IPV4_ARP 0000003652 V4_FWD_MISS 0000000000
V4_ICMP_RDIRCT 0000000000 V4_MC_FWD_MISS 0000000000 V4_MC_FWD_R_MS 0000000000
In this example, ARP packets are increasing at the highest speed, with some 3000
packets sent per second. This indicates that an ARP attack exists. Then, check whether a
loop exists. In the diagnostic view, run the efu me slot 1 egress and display ring-packet
fwd_to_cp low 10 commands to view the attack source. For example:
FFFF FFFF FFFF 00E0 FC97 8612 0806
0001
0800 0604 0001 00E0 FC97 8612 0200
0101
0000 0000 0000 0200 010A 0201 0A0E
0F00
1201 1102 0002 0000 0001 0001
In this example, 0806 0001 indicates the ARP request packet, and 0200 0101 indicates
the source address which can be translated as 2.0.1.1.
Other common attacks include ICMP. You can run the efu me slot 1 egress and display
ring-packet fwd_to_cp low 10 commands to view the attack source. For example:
00E0 FC7D A492 00E0 FC97 8612 0800 4500
0054 5D4D 0000 FF01 5859 0200 0101 0200
0102 0800 0E76 ABD5 0813 0E3A 34A6 0000
0000 504E 4702 0E35 CFA9 0001 0203 0405
In this example:
– 0800 4500 indicates the start of an Ethernet IP packet, and 01 indicates an ICMP
packet.
– 0200 0101 indicates the source address, that is, the attack source.
– 0200 0102 indicates the destination address.
l If the route task is with a high CPU usage, the cause of the problem is typically route
flapping. Then you need to determine the involved protocol.
Run the display cpu-usage command to check whether the task of the route module is
with a high CPU usage. For example:
[HUAWEI] display cpu-
usage
CPU Usage Stat. Cycle: 60
(Second)
CPU Usage : 80% Max:
100%
CPU Usage Stat. Time : 2009-03-03
11:29:10
CPU Usage Stat. Tick : 0x14e3(CPU Tick High) 0x875dd46(CPU Tick
Low)
Actual Stat. Cycle : 0x0(CPU Tick High) 0x7751e4b6(CPU Tick
Low)
TaskName CPU Runtime(CPU Tick High/CPU Tick

Low)
BUFM 0% 0/
27831f
VIDL 89%
0/6af2409f
INFO 0% 0/
14407
RPR 0% 0/
5bcf5e
L2IF 0% 0/
9705e
BFD 0% 0/
163d5a
ROUT 60% 0/ 5e32cdb
Run the display ip routing-table statistics command to check the involved protocol.
For example:
[HUAWEI] display ip routing-table statistics
Proto total active added deleted freed
routes routes routes routes routes
DIRECT 17 17 80 63 63
STATIC 2 0 2 0 0
RIP 0 0 0 0 0
OSPF 0 0 0 0 0
IS-IS 1 1 10 9 9
BGP 0 0 0 0 0
Total 20 18 92 72 72
l If the top 3 tasks with a high CPU usage are INFO, VMON, and tAtaSvc1, the cause of
the problem is typically a CF card fault and there is a high probability that CFCARD2 is
frequently recording logs.
Run the following command to check whether the CF card is faulty:
[HUAWEI-diagnose] bspdiag mpu 9 display cfcard cfcardreg
CONFIG__REG:0x42 0x80 0x2E 0x00
CONFIG2__REG:0xFF 0xFF 0xFF 0xFF
The CFcard2 state: States ERROR! //CFCARD2 is faulty.
The CFcard state: OK! //The CF card is normal.
If the CF card is faulty, replace it with a new one.

If the problem persists, collect information and contact Huawei engineers.
5.1.5 Troubleshooting Cases
5.1.5.1 Loop Exists on the Network
In case of a Layer 2 loop, protocol packets are continuously copied, leading to a large number
of protocol packets to be sent and eventually a high CPU usage. Typically, a large number of
ARP packets are sent in this scenario.
Perform the following operations to locate the fault:
1. Run the display health command to locate the board with a high CPU usage. In this
example, slots 1 and 2 have a high CPU usage.
Slot CPU Usage Memory Usage(Used/Total)
---------------------------------------------------------
17 MPU(Master) 31% 37% 687MB/1845MB
1 LPU 73% 22% 190MB/842MB
2 LPU 79% 22% 190MB/842MB
3 LPU 15% 25% 213MB/841MB
4 LPU 9% 26% 222MB/841MB

2. Run the display cpu-usage slot command to locate the task with a high CPU usage. In
this example, the MACL and PES tasks on the board in slot 2 have a high CPU usage.
[HUAWEI] display cpu-usage slot
2

(Second)
CPU Usage : 79% Max: 96% //The CPU usage is

79%.

17:40:24
CPU utilization for five seconds: 79%: one minute: 79%: five minutes:
79%.
TaskName CPU Runtime(CPU Tick High/Tick Low) Task

Explanation
PES 22% 0/21aa8998 PES //The PES task has a high

CPU
usage.
MACL 20% 0/1f2d9ca0 MACL //The MAC learning task has a

high CPU
usage.
OS 29% 0/2b2b8f38 Operation System -
3. Run the display attack-source-trace slot all verbose command to view attack source
information. For example, a large number of broadcast and multicast packets are sent to
the CPU from the GE 1/0/2 and GE 1/1/11 interfaces.
[HUAWEI] display attack-source-trace slot all verbose
No 4287 packet Info:
Interface Name : GigabitEthernet1/0/2
PeVlanid : 350
CeVlanid : 0
Attack Type : Application apperceive
Attack Pack Time : 2012-04-30 14:55:21
Attack Source Data:
01 00 5e 00 00 12 00 00 5e 00 01 03 81 00 01 5e 08 00 45 c0 00 28 c9 c3
00
00 ff 70 8b 1b 0a b2 7b 02 e0 00 00 12 21 03 78 01 00 01 e1 46 0a b2 7b
01
00 00 00 00 00 00 00 00 00 00 00 00 00
----------------------------------
No 4288 packet Info:
PeVlanid : 350
CeVlanid : 0
Attack Type : CPCAR
Attack Pack Time : 2012-04-30 14:55:21
Attack Source Data:
ff ff ff ff ff ff 80 fb 06 ae 0d 33 81 00 01 5e 08 06 00 01 08 00 06 04
00
01 80 fb 06 ae 0d 33 0a b2 7b 05 00 00 00 00 00 00 0a b2 7b 01 00 00 00
00
00 00 00 00 00 00 00 00 00 00 00 00 00
In this example, a large number of ARP and VRRP packets are received. Run the
display cpu-defend car protocol statistics slot command to view packet details. For
example, ARP and VRRP packets are discarded on the board in slot 1.

[HUAWEI] display cpu-defend car protocol arp statistics slot 1

Slot : 1
Application switch : Open
Default Action : Min-to-cp
--------------------------------------------
IPV4 ARP packet
Protocol switch: N/A
Packet information:
Passed packet(s) : 46929862
Dropped packet(s) : 564972185
Configuration information:
Configged CIR : 2000 kbps Actual CIR in NP : 2000 kbps
Configged CBS : 20000 bytes Actual CBS in NP : 20000 bytes
Priority : The index on this board can not be shown . Please see the NP
Priority.
Min-packet-length : NA
[HUAWEI] display cpu-defend car protocol vrrp statistics slot 1

Slot : 1
--------------------------------------------
VRRP packet
Protocol switch: Open
Packet information:
Priority : high
Then analyze the packet content. It is found that interfaces where a large amount of
traffic is transmitted all join VLAN 350. This indicates that a loop occurs in VLAN 350.
The solution is to clear the loop issue on the network.
5.1.5.2 Router IDs Conflict

1. Run the display health command to locate the board with a high CPU usage.
---------------------------------------------------------
10 MPU(Master) 100% 48% 418MB/863MB
1 LPU 15% 43% 178MB/405MB
2 LPU 11% 43% 178MB/405MB
3 LPU 10% 33% 310MB/917MB
9 MPU(Slave) 6% 41% 358MB/863MB
2. Run the display cpu-usage slot command to locate the task with a high CPU usage.
[HUAWEI] display cpu-usage slot 17
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage : 100% Max: 100%
CPU Usage Stat. Time : 2011-09-20 15:16:51
CPU Usage Stat. Tick : 0x44556(CPU Tick High) 0xced3d558(CPU Tick Low)
Actual Stat. Cycle : 0x0(CPU Tick High) 0x78110d2f(CPU Tick Low)
TaskName CPU Runtime(CPU Tick High/CPU Tick Low) Task Explanation

TICK 0% 0/ a946cc TICK
HOT 0% 0/ 48a9fa Hot insert/remove task
ROUT 80% 0/ 612b9d97 Route task
In this example, the CPU usage on the MPU reaches 100%, and the CPU usage of the
ROUT task reaches 80%, which indicates that a large number of routes flap on the

network. Then, check device logs. If no logs have interface or protocol flapping records,
it can be found that a router ID conflict exists.
3. Run the display ospf spf-statistics verbose command to check that the problem results
from a router ID conflict in an area and this LS ID is the conflicting router ID.
– Route calculation had been performed several times, and the interval for route
calculation is short.
– The cause of route calculation is LSA.
– The type is Router and the LS ID is the same as that of the Adv Router.
[HUAWEI] display ospf spf-statistics verbose
Routing table change statistics:
Index: 1 This spf calculation is Intra full calculation
Time : 2011-09-20,07:54:07
Intra : 0 Added,0 Deleted
Inter : 0 Added,0 Deleted
External : 0 Added,0 Deleted
The reason of calculation is:LSA
NO. Type LS ID Adv Router
1 Router 192.168.1.1 192.168.1.1
Index: 2 This spf calculation is Intra full calculation
Time : 2011-09-20,07:54:02
Intra : 0 Added,0 Deleted
Inter : 0 Added,0 Deleted
External : 0 Added,0 Deleted
The reason of calculation is:LSA
NO. Type LS ID Adv Router
1 Router 192.168.1.1 192.168.1.1
The solution is to address the router ID conflict.
5.1.5.3 Specific Operations Have Been Performed
Execution of the display diagnostic-information command makes the CPU usage go up.
The display diagnostic-information command is used for one-click collection of network
fault information. This command contains the display memory XXX group command group.
If the display memory XXX group command is run, all the allocated memory blocks in the
system will be traversed. Due to traverse algorithm issues, a lot of system resources will be
used when a large number of allocated memory blocks exist in the system.
In V600R001C00SPCe00, to observe information about memory block allocation, run the
display diagnostic-information command which will executes the display memory XXX
group command group for a consecutive of 5 times. This makes the system slow down and
the CPU resources used for a long time, affecting the processing of SSH protocol packets.
This problem has been addressed in the patch of V600R001C00SPC036 or later versions. The
display diagnostic-information command can then traverse the display memory XXX
group command group for only one time, reducing the CPU usage.
5.1.5.4 Physical Interface and Trunk Interface on the Same Board Join the Same
VLAN
Multicast traffic is broadcast in VLANs. When MAC learning is triggered on a physical

interface, the IsBC bit of MAC entries is 0. After MAC learning is triggered on the Trunk
interface, the IsBC bit of MAC entries is 1, and MAC entries are broadcast on the device. If
both the physical interface and trunk interface on the same board join the same VLAN, IsBC
bit transient


1. Run the display health command to locate the board with a high CPU usage.
---------------------------------------------------------
10 MPU(Master) 14% 48% 418MB/863MB
1 LPU 15% 43% 178MB/405MB
2 LPU 11% 43% 178MB/405MB
3 LPU 10% 33% 310MB/917MB
4 LPU 59% 42% 172MB/405MB
5 LPU 61% 42% 172MB/405MB
2. Run the display cpu-usage slot command to locate the task with a high CPU usage. For
example, the MAC learning task on the board in slot 4 has a high CPU usage.
[HUAWEI] display cpu-usage slot
4

(Second)
CPU Usage : 59% Max:

96%

17:40:24
CPU utilization for five seconds: 59%: one minute: 59%: five minutes:
59%.
TaskName CPU Runtime(CPU Tick High/Tick Low) Task

Explanation
MACL 40% 0/1f2d9ca0 MACL
3. View configurations and check whether the physical interface and trunk interface on a
board join the same VLAN.
a. Check the member interface of VLAN 100. It is found that the Eth-Trunk interface
(such as Eth-Trunk 6) and GE 4/0/0 are the physical interfaces on the board in slot
4, and GE 5/0/0 is the physical interface on the board in slot 5.
[HUAWEI] display vlan 100
VLAN ID Type Status MAC Learning Broadcast/Multicast/Unicast
Property
-------------------------------------------------------------------------
-------
100 common enable enable forward forward forward
default
----------------
Tagged Port: Eth-Trunk6 Eth-
Trunk7
GigabitEthernet8/0/15 GigabitEthernet8/0/16
b. Check the member interfaces of Eth-Trunk 6. It is found that the physical interfaces
on the boards in slot 4 and slot 5 are member interfaces. The Eth-Trunk interface
also includes the member interfaces of the boards in slot 4 and slot 5.
[HUAWEI]display trunkmembership eth-trunk 6
Trunk ID: 6
used status: VALID
TYPE: ethernet
Working Mode : Normal
Working State: Normal
Number Of Ports in Trunk = 2
Number Of UP Ports in Trunk = 2
operate status: up

Interface GigabitEthernet4/0/18, valid, operate up, weight=1,

Interface GigabitEthernet5/0/18, valid, operate up, weight=1,
The solution is to avoid adding the physical interface and trunk interface on a board to
the same VLAN.
5.2 MPLS OAM Session Goes Down and a dLOCV Defect

Occurs
NEs and Versions

NE40E\NE80E V600R006
PTN6900 V600R006
Common Causes
A dLocv defect occurs if the MPLS OAM session goes Down in the command output.
l display mpls oam egress or display mpls oam ingress: displays information about an
MPLS OAM session that monitors bidirectional associated LSPs.
l display mpls oam bidirectional-tunnel: displays information about an MPLS OAM
session that monitors a static bidirectional co-routed LSP.
l display mpls oam l2vc: displays information about an MPLS OAM session that
monitors PWs.
This fault is commonly caused by one of the following:
l Cause 1: Configurations on one end of an MPLS OAM session are different from those
on the other end.
l Cause 2: An MPLS OAM session is disabled from sending or receiving test packets.
l Cause 3: A service bound to an MPLS OAM session is Down.
l Cause 4: A link flaps.
Procedure
Step 1 Cause 1
If an MPLS OAM session with automatic negotiation disabled is used, the same test packet
type and the same interval at which packets are sent must be configured on both ends of the
session. A configuration inconsistency causes a dLOCV defect. To remove the defect, change
a specific setting on one end to be the same as that on the other end. The display current-
configuration command can be used to help verify whether the two ends of the MPLS OAM
session have the same configurations.
Step 2 Cause 2
Run the following command to manually enable the session that is not a self-negotiation
session.
l Run the mpls oam egress enable or mpls oam ingress enable command to configure an
MPLS OAM session that monitors bidirectional associated LSPs.

l Run the mpls oam bidirectional-tunnel enable command to configure an MPLS OAM
session that monitors a static bidirectional co-routed LSP.
l Run the mpls oam l2vc enable command to configure an MPLS OAM session that
monitors PWs.
Step 3 Cause 3
If a service bound to an MPLS OAM session is Down, the MPLS OAM session cannot send
test packets and goes Down. Locate the cause for the service Down event.
Step 4 Cause 4
Check the cause for link flapping.
----End
Conclusion
A configuration error causes an MPLS OAM session to fail to go Up. If such a problem
occurs, verify configurations, including whether the same parameters are configured on both
ends of the session and whether MPLS OAM is enabled. If the configurations are correct,
check whether a service bound to the MPLS OAM session has a problem, such as flapping or
a link connectivity failure.
5.3 CPU Usage for the MPLS OAM Module Is High
NEs and Versions

PTN6900 V600R006
Common Causes
If CPU usage of a device reaches the threshold-crossing alarm (VOSCPU/4/
CPU_USAGE_HIGH), run the display cpu-usage command to view CPU usage. The
command output shows that the OAM module uses the most CPU resources. This fault is
commonly caused by one of the following:
Link flapping
Procedure
Step 1 Check whether a link flaps. If a link flaps, locate the cause and rectify the fault.
----End
Conclusion
A link is abnormal, which causes interface flapping. As a result, MPLS OAM frequently
detects a defect and a recovery event. The MPLS OAM reports each event to the service
module, which causes the service to flap and CPU usage to soar.

5.4 MPLS-TP OAM Session Goes Down and a dLOCV

Defect Occurs
NEs and Versions

PTN6900 V600R006
Common Causes
The display mpls-tp oam meg command output shows that an MPLS-TP OAM session goes
Down. A dLocv defect occurs.
This fault is commonly caused by one of the following:
l Cause 1: Configurations on one end of an MPLS-TP OAM session are different from
those on the other end.
l Cause 2: An MPLS-TP OAM session is disabled from sending or receiving test packets.
l Cause 3: A service bound to an MPLS-TP OAM session is Down.
l Cause 4: A link flaps.
Procedure
Step 1 Cause 1
If an MPLS-TP OAM session with automatic negotiation disabled is used, the same test
packet type and the same interval at which packets are sent must be configured on both ends
of the session. A configuration inconsistency causes a dLOCV defect. To remove the defect,
change a specific setting on one end to be the same as that on the other end. The display
current-configuration command can be used to help verify whether the two ends of the
MPLS-TP OAM session have the same configurations.
Step 2 Cause 2
Run the cc send enable command to enable the local end to send CC or CV detection packets
or the cc receive enable command to enable the local end to receive CC or CV detection
packets.
Step 3 Cause 3
If a service bound to an MPLS-TP OAM session is Down, the MPLS-TP OAM session
cannot send test packets and goes Down. Locate the cause.
Step 4 Cause 4
Check the cause for link flapping.
----End
Conclusion
A configuration error causes an MPLS-TP OAM session to fail to go Up. If such a problem
occurs, verify configurations, including whether the same parameters are configured on both

ends of the session and whether MPLS-TP OAM is enabled. If the configurations are correct,
check whether a service bound to the MPLS-TP OAM session has a problem, such as flapping
or a link connectivity failure.
5.5 CPU Usage for the MPLS-TP OAM Module Is High
NEs and Versions

PTN6900 V600R006
Common Causes
If CPU usage of a device reaches the threshold-crossing alarm (VOSCPU/4/
CPU_USAGE_HIGH), run the display cpu-usage command to view CPU usage. The
command output shows that the MPLS-TP OAM module uses the most CPU resources. This
fault is commonly caused by one of the following:
Link flapping
Procedure
Step 1 Check whether a link flaps. If a link flaps, locate the cause and rectify the fault.
----End
Conclusion
A link is abnormal, which causes interface flapping. As a result, MPLS-TP OAM frequently
detects a defect and a recovery event. The MPLS-TP OAM reports each event to the service
module, which causes the service to flap and CPU usage to soar.
5.6 Multi-device Backup
5.6.1 Introduction
What's BRAS reliability?
BRAS reliability enables user information to be backed up in real time when BRASs are
deployed. If the master device or link fails, services are quickly switched to a backup device
or board, ensuring service continuity. After the master device or link recovers, services are
switched back to the master device without being interrupted.
High reliability techniques supported by ME60s include link-level reliability, network server
reliability, and device-level reliability. This document describes hot backup in device-level
reliability. For link-level reliability and network server reliability, see related documents and
technical white papers.
Carrier-class new services' requirements for reliability

Typical applications

5.6.2 Multi-device Backup Principles
5.6.2.1 Basic Process
The following aspects must be considered to implement service-level high reliability

deployment:
l Service information backup
ME60s forward user data packets only after users are authenticated and authorized. To ensure
that a backup device controls packet forwarding and user authorization, user information must
be synchronized on the master and backup devices.
l Master and backup decision
After multi-device backup is deployed, an aggregation switch that accesses a network must be
dual-homed to two ME60s. The two ME60s can work in load balancing mode based on the
VLAN granularity. When a user accesses the network, the master ME60 forwards user traffic,
and the backup ME60 waits to take over if the master ME60 fails. Therefore, a mechanism is
needed to decide the master and backup roles between the two ME60s. VRRP is used for role
decision.
l Forwarding control
Forwarding control controls upstream (user-to-network) and downstream (network-to-user)

traffic in normal and abnormal situations.

Upstream control uses the MAC address table of a switch to control traffic. The master and
backup ME60s use the same MAC address to set up a session with a user. The ME60s send
gratuitous ARP packets to control the forwarding path of upstream traffic.
Downstream control uses routes to control downstream traffic. If a network segment is
planned for each link, network segment routes are advertised when the VRRP backup group is
in the Master state and withdrawn in the Backup state, which controls the forwarding path of
downstream traffic. If multiple links share a network segment, especially when IP address
resources are scarce, both the master and backup ME60s use different costs to advertise
network segment routes. In this situation, the upstream IP core network has its routes destined
for an ME60. When the upstream link of this ME60 fails, the IP core network changes the
destination of the user network segment routes after route convergence.
Figure 5-1 Aggregation switch dual-homing networking
Service process:
1. The two VRRP-enabled ME60s form a VRRP backup group and determine the master/
backup status. One ME60 with a higher VRRP priority is elected as the master device,
and the other ME60 becomes the backup device. Only the master ME60 forwards user
traffic. The backup ME60 receives user session information synchronized from the
master ME60.
2. After a user accesses the network through the master ME60, the user's IP session
information, including the MAC address, IP address, DHCP lease, and DHCP Option 82
information, are synchronized to the backup ME60.

3. One device BFD session and one link BFD session are used to monitor network
connectivity. The device BFD session is established between the two ME60s, and the
link BFD session is established between an ME60 and the switch.
4. The device BFD session is used to monitor the status of an ME60. If the master ME60
detects that the device BFD session goes Down, a fault occurs on the network. In this
situation, the master ME60 checks the link BFD session.
– If the link BFD session is Up, the fault occurs on the backup ME60 or the link
between the backup ME60 and switch. If this case occurs, a master/backup VRRP
switchover does not need to be performed.
– If the link BFD session goes Down, a master/backup VRRP switchover is
performed.
5. After a master/backup VRRP switchover is performed, the new master ME60 (ME60-B)
advertises the user IP route and the new backup ME60 (ME60-A) withdraws the user IP
route. Network-to-user traffic is switched to ME60-B. On the user side, ME60-B sends
gratuitous ARP packets to modify the MAC table on the switch. User-to-network traffic
is also switched to ME60-B.
6. ME60-B creates a new IP session forwarding table based on the synchronized IP session
information. Once ME60-B receives user packets, it forwards the packets based on the
new IP session forwarding table. Additionally, ME60-B checks the MAC address, IP
address, VLAN ID, and PVC information in the user packets and performs QoS
scheduling based on the IP session information. The user does not detect the fault on the
network.
7. After the fault is rectified, user traffic is switched back to ME60-A.
5.6.2.2 Route Deployment Policies
The following route deployment policies are recommended for downstream forwarding
control:
l Address Pool Space Used by Each Interface Exclusively
l Global Address Pool Space Shared and Traffic Bypassed Through Tunnels
Comparison between the two route deployment policies
Address Pool Space Used by Each Global Address Pool Space

Interface Exclusively Shared and Traffic Bypassed
Through Tunnels
Advan Route switching is easy. Each interface Route control is simple. Master and
tages exclusively uses a network segment. If a backup address pools are configured
fault occurs on a link or device, a route based on a VRRP backup group.
is advertised or withdrew based on the Routes advertised using the master
network segment, which is easy to and backup address pools have
control. different priorities. Traffic switchover
Traffic switchovers are fast, and rates reach the millisecond level.
switchover rates depend on the rates at
which upper-layer routers update routes.
Disad Each interface exclusively uses address A traffic bypass tunnel must be
vantag pool space, which wastes address pool configured, which wastes bandwidth
es resources. resources.

Figure 5-2 Deployment of the exclusively used address pool
NOTE
In this policy, address pools on both the master and backup devices must be bound to a remote backup
profile (RBP) so that the RBP controls the advertisement and withdrawal of the address pools' network
segment routes.
An exclusively used address pool is an address pool or address segment exclusively used by a
backup group or link. To control network-to-user traffic, user packets must be forwarded
correctly on the IP core network so that the device through which a user goes online forwards
the traffic to the user properly. An exclusively used address pool allows a network segment
route to be advertised to the IP core network using an IGP. In this policy, ME60-1 and
ME60-2 cannot advertise the same network segment route. Advertising the same network
segment route will cause load balancing on the IP core network and network-to-user traffic to
be forwarded incorrectly.
Advertisement of a network segment route by an ME60 depends on an address pool, which is
related to an RBP.
The rules for controlling network segment routes in this policy are as follows:
When an address pool is bound to an RBP and the RBP is in the Master state, the network
segment route is advertised. When the RBP is in the Backup state, the network segment route
is not advertised.
After the RBP status changes, the address pool's network segment route is advertised or
withdrawn.

On the network shown in Figure 5-2, If link 1 fails, a user goes online through ME60-2.
ME60-1 must withdraw the network segment route destined for 10.1.0.0/16, and ME60-2
must re-advertise the network segment route destined for 10.1.0.0/16.
Shared address pool (recommended)
In BRAS scenarios, an address pool (an IP network segment) is planned based on services. A
service (for example, Internet access or VoIP service) corresponds to a domain's
configuration. If terminals that go online through different access links have a service (for
example, Internet access service), the terminals share address pool resources in a domain.
This mode is called multi-link address pool sharing.
During actual deployment, planning address pools based on links is difficult, because the
number of public addresses is limited and dividing address pools wastes address resources.
Address pools can be divided based on authentication domains, which allows an address pool
on an ME60 to be shared between links or backup groups. In this situation, forwarding control
cannot be performed by advertising or withdrawing a network segment route of an address
pool. To implement forwarding control, using a shared address pool and tunnel protection is
recommended.
Figure 5-3 Deployment of the shared address pool
NOTE
In this policy, the address pool on the master device must be bound to a remote backup service (RBS)
but the address pool on the backup device does not need to be bound to an RBS.
If a link fault occurs on the network side and the protection tunnel goes Down, the RBS withdraws the
network segment route of the address pool that is bound to it. The RBS re-advertises the network
segment route only after the protection tunnel is re-established and goes Up.

On the network shown in Figure 5-3, a protection tunnel, for example, a label switched path
(LSP), is established between ME60-1 and ME60-2. If the link between ME60-1 and the
switch fails, ME60-1 directs the affected users' routes to the protection tunnel and forwards
the routes to ME60-2 over the protection tunnel. ME60-2 then sends out the routes for IP
forwarding until they reach the users.
A protection tunnel instead of rerouting is preferentially used, because a user's host routes
exist only on ME60-1 and ME60-2. If rerouting is used, downstream packets are forwarded to
the CR. As a result, network-to-user traffic flaps between the CR and ME60-1 until the TTL
value is reduced to 0 and the packets are discarded. If a protection tunnel is used, the
downstream packets are re-encapsulated and transmitted to ME60-2 over the protection
tunnel. There is only one hop when ME60-2 transmits the packets for IP forwarding.
5.6.3 Basic Specifications for Dual-device Hot Backup

Deployment
Table 5-3 Basic specifications for ME60 dual-device hot backup

No. Item Description
1 Access topologies Only the following access topologies are supported:

l Each aggregation switch is dual-homed to the interfaces
of the master and backup ME60s in the tree-shaped
networking.
l A ring network (semi-ring) formed by aggregation
switches is dual-homed to the master and backup
ME60s.
2 Access media Only Ethernet links
3 Access interfaces FE, GE, and 10GE interfaces and their sub-interfaces
Single- and double-tagged packets
Eth-Trunk interface with its member interfaces residing on a
board
NOTE
In V600R002C02SPC700 and later versions, Eth-Trunk interfaces
support hot backup.
Inter-board Eth-Trunk backup is supported from V600R007C00.
Virtual Ethernet interfaces do not support dual-device hot backup.
4 Protection tunnel Direct paths between ME60s, MPLS LSPs, and MPLS TE
types tunnels
NOTE
In versions earlier than V600R003C05, traffic can be forwarded
only on one load-balancing path of a protection tunnel.
In V600R003C05 and later versions, traffic can be forwarded on all
load-balancing paths of a protection tunnel.

5 Access user types DHCP, DHCP+web authentication, PPPoE (including

PPPoE leased line), static access, and L2TP LAC users
NOTE
In V600R003C05 and later versions, for a dual-stack user, IPv4
supports hot backup but IPv6 does not.
6 Service types IPv4 unicast and multicast, web authentication, and

CoA/DM services
In V600R003C05 and later versions, IPv4 DAA services
support hot backup.
V600R007 supports dual-stack access.

V600R007 allows non-hot backup users and hot backup
users to share an IPv4 address pool.
Hot backup is not supported for redirection to a domain after
quotas are exhausted.
8 Network-side faults Switching performance is equivalent to IGP/BGP route

convergence, which depends network deployment.

9 IPv6 services V600R007C00 and later versions support inter-chassis

backup for IPv6 access users.
(1) ME60s support ND/DHCPv6/ND+PD IPv6 hot backup
for IPoE Layer 2 subscribers and support IPoE dual-stack
hot backup but do not support IPv6 static user backup.
(2) ME60s support ND/DHCPv6/ND+PD IPv6 hot backup
for PPPoE Layer 2 subscribers and support PPPoE dual-
stack hot backup.
(3) IPv6 hot backup users and non-hot backup users can
share an address pool. That is, IPv6 also supports virtual
backup.
(4) In ND mode, the deployment solution provides only the
unshared prefix assignment mode.
(5) IPv6 services' protection tunnels support only the MPLS
LSP mode (6PE and 6VPE models).
(6) IPv6 address pools do not support inter-chassis
borrowing (the local RUI-slave address pool cannot be used
to assign an IP address to the master device).
(7) IPv6 hot backup does not support address pool planning
based on backup groups or links.
(8) IPv6 hot backup does not support the mapping of
RADIUS authorization address pool names to the local
device.
(9) In IPv6 hot backup and PPPoE dual-stack access mode,
if a network fault causes a master/backup device switchover
when a dual-stack user accesses the device using one stack
and is dialing up using the other stack. There is a possibility
that only one stack access is allowed on the backup device.
(10) IPv6 multicast does not support hot backup.
(11) IPv6 DAA services do not support hot backup.
(12) DS-Lite does not support hot backup.
(13) IPv6 remote address pools do not support hot backup.
10 N:1 backup 2:1 backup is recommended.

V600R008 supports 2:1 L2TP LAC hot backup. The
specification for L2TP sessions per device is 64K (128K in
1:1 backup mode).
11 Interconnection with ME60s can be interconnected with IPv4 RADIUS servers

external servers and IPv4 web authentication servers (portal protocol) but
cannot be interconnected with COPS servers.
12 QoS collaboration SQ, CAR, and home HQoS

5.6.4 Hot Backup Deployment for IPv4 Multicast Services
5.6.4.1 Deployment Precautions
1. The VRRP recovery delay must be twice or three times the interval at which multicast
query packets are sent to ensure that entries on the master and backup devices are the
same. The default interval at which multicast query packets are sent is 60s.
2. In IPoE scenarios, when deploying VRRP on a Layer 2 access network (non-MC-Trunk,
non-SmartLink, and non-primary/secondary VLL) to determine the master/backup status,
you can run the undo dhcp-stb igmp-copy command in the remote backup profile
(RBP) view to disable multicast protocol packet backup, alleviating backup pressure on
the master device. In this way, multicast hot backup can also be implemented.
5.6.4.2 Configuration Introduction
1. Networking
Figure 5-4 Multicast hot backup configuration example
2. Data preparation
Table 5-4 Data preparation for multicast hot backup
1 User access interface GE 1/0/0 for both ME60-1 and ME60-2

User VLAN 100
2 Network-side interface GE 2/0/0 for both ME60-1 and ME60-2 to connect

to the IP core network
3 IP addresses for establishing ME60-1: 10.0.0.1

an RBS ME60-2: 10.0.0.2

4 Access terminal PPPoE and DHCP STBs
5 RR server RR server: 192.168.2.2

An RR server is statically specified in this
example.
3. Configurations
ME60-1:
# Configure a BFD session on the access side to rapidly detect faults in interfaces or links and
trigger a master/backup VRRP switchover.
100.0.0.2 is the IP address of ME60-2's GE 1/0/0.2.
bfd bfd-acc bind peer-ip 100.0.0.2
commit
# Configure a VRRP backup group on GE 1/0/0.2, and configure the VRRP backup group to
track the BFD session and network-side interface.
interface gigabitethernet 1/0/0.2

vlan-type dot1q 200
ip address 100.0.0.1 255.255.255.0
vrrp vrid 1 virtual-ip 100.0.0.100
admin-vrrp vrid 1
vrrp vrid 1 priority 120
vrrp vrid 1 track bfd-session 1 peer
vrrp vrid 1 track interface gigabitethernet 2/0/0 reduced 50
# Configure an RBS.
remote-backup-service s1
peer 10.0.0.2 source 10.0.0.1 port 3000
track interface gigabitethernet 2/0/0
# Configure an RBP for backing up BRAS user information and multicast services.
remote-backup-profile p1
peer-backup hot
vrrp-id 1 interface gigabitethernet 1/0/0.2
backup-id 10 remote-backup-service s1
service-type bras #BRAS user information backup
service-type multicast #Multicast service backup
# (Optional) Run the undo dhcp-stb igmp-copy command to disable multicast backup on
DHCP terminals.
# Configure a domain to which users belong (parameters such as an authentication mode are
omitted).
aaa
domain iptv
...
# Configure a BAS interface and user-side VLAN.


user-vlan 100
remote-backup-profile p1 #The RBP is bound to the interface.
bas
access-type layer2-subscriber default-domain authentication iptv
authentication-method bind
Configure basic multicast services.

# Enable multicast globally.
multicast routing-enable
# Enable PIM on the network-side interface.

interface gigabitethernet 2/0/0
pim sm
# Enable IGMP and PIM on the user access interface.

igmp enable
pim silent
# Configure an RP router.
pim
static-rp 192.168.2.2
ME60-2:
100.0.0.1 is the IP address of ME60-1's GE 1/0/0.2.
commit

vlan-type dot1q 200
ip address 100.0.0.2 255.255.255.0
admin-vrrp vrid 1
# Configure an RBS.
peer 10.0.0.1 source 10.0.0.2 port 3000
track interface gigabitethernet 2/0/0
# Configure an RBP for backing up BRAS user information and multicast services.
peer-backup hot
service-type multicast #Multicast service backup
# (Optional) Run the undo dhcp-stb igmp-copy command to disable multicast backup on
DHCP terminals.

# Configure a domain to which users belong (parameters such as an authentication mode are
omitted).
aaa
domain iptv
...
# Configure a BAS interface and user-side VLAN.

user-vlan 100
remote-backup-profile p1 #The RBP is bound to the interface.
bas
access-type layer2-subscriber default-domain authentication iptv
authentication-method bind
Configure basic multicast services.

# Enable multicast globally.
multicast routing-enable
# Enable PIM on the network-side interface.

pim sm
# Enable IGMP and PIM on the user access interface.

igmp enable
pim silent
# Configure an RP router.
pim
static-rp 192.168.2.2
5.6.5 Hot Backup Deployment for L2TP LAC Services

ME60s support L2TP (VPDN) hot backup when functioning as LACs from V600R003C05. If
ME60s function as LNSs or LTSs, they do not support hot backup.
5.6.5.1 Deployment Constraints
1. If the specification for L2TP sessions per device is 128K, only two-device hot backup is
supported. That is, L2TP hot backup can be deployed only on two LACs.
– V600R008C10 allows you to set the specification for L2TP sessions per device. If
the specification is set to 64K, 2:1 hot backup is supported. That is, one LAC can
form hot backup with two LACs.
2. ME60s support hot backup only when functioning as LACs.
3. Two ME60s support a total of 16K L2TP tunnels and 128K sessions.
4. ME60s do not support RADIUS authorization for LAC IP addresses.
5. LAC IP addresses can be used only for L2TP services because IP addresses must be
configured on two LACs.
6. Only the loopback interface IP address can be used as an LAC's source IP address for
communication with an LNS.
7. The IP core network cannot use a static route to specify the LAC IP route.

8. The set l2tp tunnel base-id command must be run on the backup device to change the
base value for tunnel ID allocation to a value different from that of a host. By default,
tunnel IDs allocated by an LAC range from 1 to 16384. To prevent a tunnel conflict in
load balancing mode, you must run the set l2tp tunnel base-id command in the system
view to specify a base value for tunnel ID allocation.
9. L2TP hot backup requires the VRRP recovery delay for the master device to be greater
than 20 minutes. A VRRP recovery delay of 30 minutes is recommended.
10. For a non-hot backup L2TP group in hot backup scenarios, the access function is locked
after the system starts and before data synchronization for hot backup is complete. The
access function is unlocked only after data synchronization is complete or the VRRP
recovery delay elapses.
11. The Hello period for an L2TP tunnel must be set to 60s (default value). The Hello
function cannot be disabled.
5.6.5.2 Configuration Introduction
1. Networking
Figure 5-5 L2TP LAC hot backup configuration example
2. Data preparation
L2TP LAC hot backup is deployed on two LACs in load balancing mode. By default, a
terminal that logs in through LAC1 uses the IP address 1.1.1.1 to establish a tunnel to the
LNS, and a terminal that logs in through LAC2 uses the IP address 2.2.2.2 to establish a
tunnel to the LNS.

Table 5-5 Data preparation for L2TP LAC hot backup

1 User access interface GE 1/0/0 for both ME60-1 and ME60-2

User VLAN 100
2 Network-side interface GE 2/0/0 for both ME60-1 and ME60-2 to connect

to the IP core network
3 LAC1's IP address for 1.1.1.1, which is configured on a loopback

communicating with the LNS interface. The IP address is advertised to the IP
core network through a policy route. The route has
a small cost on LAC1 and a large cost on LAC2.
4 LAC2's IP address for 2.2.2.2, which is configured on a loopback

communicating with the LNS interface. The IP address is advertised to the IP
core network through a policy route. The route has
a small cost on LAC2 and a large cost on LAC1.
5 LNS's IP address 3.3.3.3
6 IP addresses for LAC1 and The IP addresses for LAC1 and LAC2 to establish
LAC2 to establish an RBS an RBS cannot be the same as those for an LAC
and LNS to establish a tunnel and must be
independently planned.
10.0.0.1 for LAC1; 10.0.0.2 for LAC2
3. Configurations
LAC1:
# Configure a loopback interface address for LAC1 (master) to communicate with the LNS.
interface loopback1
ip address 1.1.1.1 32
# Configure a loopback interface address for LAC2 (backup) to communicate with the LNS.
interface loopback2
# Configure a loopback interface address for an RBS.

interface loopback2
# Configure virtual template interface 1.

interface virtual-template 1
ppp authentication-mode chap
# Create an L2TP group and configure its attributes.

l2tp enable
#
l2tp-group lac1
tunnel name lac1
start l2tp ip 3.3.3.3 #LNS IP address
tunnel authentication #tunnel authentication

tunnel password simple huawei1 #tunnel authentication password

tunnel source loopback1 rui #Loopback1's IP address is used to establish a
tunnel to the LNS and is used for hot backup.
# Configure an IP address for a backup channel.

interface loopback3
100.0.0.2 is the IP address of LAC2's GE 1/0/0.2.
commit
vlan-type dot1q 200
ip address 100.0.0.1 255.255.255.0
admin-vrrp vrid 1
vrro vrid 1 preempt timer delay 1800 #The preemption delay is 30 minutes on the
master device.
vrrp vrid 1 track interface gigabitethernet 2/0/0 reduced 50
# Create an RBS and configure it to track the network-side interface.

peer 10.0.0.2 source 10.0.0.1 port 3000 #A data protection tunnel is
automatically established for L2TP.
track interface gigabitethernet2/0/0
# Configure an RBP for backing up BRAS user information and L2TP services.
peer-backup hot
service-type l2tp #L2TP user information backup
# Configure BAS access on GE 1/0/0.1, and bind the RBP to GE 1/0/0.1 from which users go
online.
user-vlan 100
pppoe-server bind virtual-template 1
bas
access-type layer2-subscriber
authentication-method ppp
Configure a routing policy and route advertisement.

# Configure an IP prefix.
ip ip-prefix lac1 permit 1.1.1.1 32
# Configure a routing policy.

route-policy lac-ip-export permit

if-match ip-prefix lac1
apply cost +100
apply cost +200
# Configure OSPF to import a UNR that matches the routing policy.

ospf 1
import-route unr route-policy lac-ip-export
area 0.0.0.0
#
LAC2:
# Configure a loopback interface address for LAC1 (backup) to communicate with the LNS.
interface loopback1
# Configure a loopback interface address for LAC2 (master) to communicate with the LNS.
interface loopback2
# Configure a loopback interface address for an RBS.

interface loopback2
# Configure virtual template interface 1.

interface virtual-template 1
ppp authentication-mode chap
# Create an L2TP group and configure its attributes.

l2tp enable
#
l2tp-group lac1
tunnel name lac1
start l2tp ip 3.3.3.3 #LNS IP address
tunnel authentication #tunnel authentication
tunnel password simple huawei1 #tunnel authentication password
tunnel source loopback2 rui #Loopback1's IP address is used to establish a
tunnel to the LNS and is used for hot backup.
#
# Specify a base value for tunnel ID allocation on LAC2. The default base value is 0,
indicating master/backup LAC load balancing. Base values must be configured and cannot be
the same on the master and backup LACs.
set l2tp tunnel base-id 16384
#
# Configure an IP address for a backup channel.

interface loopback3
100.0.0.1 is the IP address of LAC1's GE 1/0/0.2.
commit

vlan-type dot1q 200
ip address 100.0.0.2 255.255.255.0
admin-vrrp vrid 1
# Create an RBS and configure it to track the network-side interface.

peer 10.0.0.1 source 10.0.0.2 port 3000 #A data protection tunnel is
automatically established for L2TP.
track interface gigabitethernet2/0/0
# Configure an RBP for backing up BRAS user information and L2TP services.
peer-backup hot
service-type l2tp #L2TP user information backup
# Configure BAS access on GE 1/0/0.1, and bind the RBP to GE 1/0/0.1 from which users go
online.
user-vlan 100
pppoe-server bind virtual-template 1
bas
access-type layer2-subscriber
authentication-method ppp
Configure a routing policy and route advertisement.

# Configure an IP prefix.
# Configure a routing policy.

route-policy lac-ip-export permit
apply cost +200 #The cost is greater than that on LAC1.
apply cost +100 #The cost is less than that on LAC1.
# Configure OSPF to import a UNR that matches the routing policy.

ospf 1
import-route unr route-policy lac-ip-export
area 0.0.0.0
#
5.6.6 Service Maintenance
5.6.6.1 How Do I Obtain RBP Information?

You can run the following command in the user view to obtain RBP information:
display remote-backup-profile [slot <id> | slave] [ name ]
If no parameter is specified, the list of RBPs configured in the system is displayed.

<HUAWEI> display remote-backup-profile
----------REMOTE-BACKUP-PROFILE----------
PROFILE-ID PROFILE-NAME
-----------------------------------------
0x800 12
0x801 14
0x802 a2
0x803 aa
0x804 am
0x805 am2
You can specify the slave parameter to obtain RBP information on the slave MPU.
<HUAWEI> display remote-backup-profile slave
am
-----------------------------------------------
Profile-Index : 0x804
Profile-Name : am
Service : bras
Remote-backup-service: 7-8
Backup-ID : 1
track protocol : VRRP
VRRP-ID : 1
VRRP-Interface : Eth-Trunk11.300
Interface :
Eth-Trunk11.301
Eth-Trunk11.331
State : Slave <--local status
Peer State : Slave <--peer status
Backup mode : hot
Slot-Number : --
Card-Number : --
Port-Number : --
Frame-route metric : 100
Traffic threshold : 50(MB)
Traffic interval : 10(minutes)
ip pool include info :
* ip pool hsi-m include : hsi-m (5) ,
hsi-s (10) ,
5.6.6.2 How Do I Obtain RBS Information?
You can run the following command in the user view to obtain RBS information:
display remote-backup-service [ <name> ] [ verbose ]
<HUAWEI> display remote-backup-service 7-8 verbose
----------------------------------------------------------
Service-Index : 0
Service-Name : 7-8
TCP-State : Connected <-- The connection is normal.
Peer-ip : 201.201.1.8
Source-ip : 201.201.1.7
TCP-Port : 3000
Track-BFD : --
Track-interface0 : --
Track-interface1 : --
Last up time : 2010-08-30 11:45:36
----------------------------------------------------------
ip pool:
hsi-m metric 100
# Information about a protection tunnel is as follows:

Rbs-ID : 0
Protect-type : ip-redirect
Next-hop : 201.7.5.109
Vlanid : 0
Peer-ip : 201.201.1.9
Vrfid : 0
Tunnel-index : 0x0
Tunnel-state : DOWN
Tunnel-OperFlag: NORMAL
Spec-interface : GigabitEthernet1/0/5
Out-interface : Null
User-number : 0
----------------------------------------------------------
Packet queue info:
Packets in TX : 0
Packets in RX : 0
Statistic information:
Last 1 seconds input rate: 8 Bytes/sec, 1 Packets/sec
Last 1 seconds output rate: 8 Bytes/sec, 1 Packets/sec
Peak rate:
input rate: 59 Bytes/sec, 7 Packets/sec
output rate: 124 Bytes/sec, 7 Packets/sec
Input:
Total: 5897 Bytes, 678 Packets
SYN_REQ: 0 Packets, SYN_RCV: 0 packets, SYN_OVER: 1 packets
REAL_RCV: 11 Packets, HELLO: 661 packets
[bras] Last 1 seconds rate: 0 Packets/sec
Peak rate: 0 Packets/sec
Total packet: 0
SYN_RX: 0 packets, REAL_RX: 0 packets
[wlan] Last 1 seconds rate: 0 Packets/sec
Total packet: 0
[arp] Last 1 seconds rate: 0 Packets/sec
Total packet: 0
[dhcp-server-pool] Last 1 seconds rate: 0 Packets/sec
Total packet: 0
[RBP] Last 1 seconds rate: 0 Packets/sec
Total packet: 11
Output:
Total: 6654 Bytes, 679 Packets
SYN_REQ: 0 Packets, SYN_SEND: 0 packets, SYN_OVER: 1 packets
REAL_SEND: 13 Packets, HELLO: 660 packets, SEND_ERR: 0 packets
[bras] Last 1 seconds rate: 0 Packets/sec
Total packet: 0
SYN_TX: 0 packets, REAL_TX: 0 packets
SYN_OVER_TX: 2 packets,
[wlan] Last 1 seconds rate: 0 Packets/sec
Total packet: 0
[arp] Last 1 seconds rate: 0 Packets/sec
Total packet: 0
[dhcp-server-pool] Last 1 seconds rate: 0 Packets/sec
Total packet: 0

[RBP] Last 1 seconds rate: 0 Packets/sec
Total packet: 13
--------------------END-INFO------------------------------
If verbose is specified, backup statistics about each service are displayed.

Input:
SYN_REQ: number of received synchronization request packets
SYN_RCV: number of received synchronization data packets
SYN_OVER: number of received synchronization end packets
REAL_RCV: number of received real-time backup data packets
HELLO: number of received heartbeat packets
Output:
SYN_REQ: number of sent synchronization request packets
SYN_SEND: number of sent synchronization data packets
SYN_OVER: number of sent synchronization end packets
REAL_SEND: number of sent real-time backup data packets
HELLO: number of sent heartbeat packets
SEND_ERR: number of sent error packets
Statistics contain each service's data.
bras: ME60 user information backup service (ME60 multi-device backup)
RBP: RBP information backup service (RBP status synchronization)
5.6.6.3 How Do I Obtain Forwarding Information of a Multi-device Backup User?
5.6.6.3.1 Obtaining Forwarding Path Information of IPv4 Hot Backup Users
You can run the following command to obtain forwarding information of an IPv4 hot backup
user:
display fib ¡ verbose
To check whether an IPv4 hot backup user has an FRR protection path, run the following
command to obtain detailed forwarding information:
[HUAWEI] display fib 19.0.0.252 verbose
Route Entry Count: 1
Destination: 19.0.0.252 Mask : 255.255.255.255
#The primary path is on the access interface. If the interface is physically
Down, traffic is transmitted over the backup path but routes are not updated.
Nexthop : 19.0.0.252 OutIf : GigabitEthernet1/0/6.201
LocalAddr : 0.0.0.0 LocalMask: 0.0.0.0
Flags : HU Age : 10sec

ATIndex : 0 Slot : 1
LspFwdFlag : 0 LspToken : 0x0
InLabel : NULL OriginAs : 0
BGPNextHop : 0.0.0.0 PeerAs : 0
QosInfo : 0x0 OriginQos: 0x0
NexthopBak : 18.0.0.1 OutIfBak : GigabitEthernet1/0/9 backup path
information
LspTokenBak: 0x0 InLabelBak : NULL
LspToken_ForInLabelBak : 0x0
EntryRefCount : 0
VlanId : 0xB User's UCM CID instead of VLAN
BgpKey : 0
BgpKeyBak : 0
LspType : 0 Label_ForLspTokenBak : 0
MplsMtu : 0 Gateway_ForLspTokenBak : 0
NextToken : 0x0 IfIndex_ForLspTokenBak : 0
Label_NextToken : 0 Label : 0
LspBfdState : 0
If a VLAN is used, an IPv4 hot backup user has only one forwarding path. The interface on
the path is the access interface when the device is in the master state and is the protection
tunnel interface when the device is in the backup state.
5.6.6.3.2 Obtaining Forwarding Path Information of IPv6 Hot Backup Users
Information on the master device: The terminal goes online through Eth-Trunk 1.11; the
outbound interface on the master device is the going-online interface; and the next hop and
destination addresses are the same.
[HUAWEI] display ipv6 routing 2002:0:0:2328:: v
Routing Table :
Summary Count : 1
Destination : 2002:0:0:2328:: PrefixLength : 64
NextHop : 2002:0:0:2328:: Preference : 64
Neighbour : :: ProcessID : 0
Label : NULL Protocol : Unr
State : Active NoAdv Cost : 1
Entry ID : 1686973424 EntryFlags : 0x80000110
Reference Cnt: 3 Tag : 0
Priority : medium Age : 775sec
IndirectID : 0x0
RelayNextHop : :: TunnelID : 0x0
Interface : Eth-Trunk1.11 Flags : D
Information on the backup device: The terminal goes online through Eth-Trunk 1.11; the
outbound interface on the backup device is the protection tunnel's outbound interface Eth-
Trunk 52; no next hop exists; the tunnel ID is not 0, indicating that traffic is transmitted
through an MPLS LSP.
[HUAWEI] display ipv6 routing 2002:0:0:2328:: v
Routing Table :
Summary Count : 1
Destination : 2002:0:0:2328:: PrefixLength : 64
NextHop : :: Preference : 64
Neighbour : :: ProcessID : 0
Label : 4097 Protocol : Unr
State : Active NoAdv Cost : 1
Entry ID : 1581490280 EntryFlags : 0x80000110
Reference Cnt: 3 Tag : 0
Priority : medium Age : 816sec
IndirectID : 0x0
Interface : Eth-Trunk52 Flags : D

5.6.6.4 Maintenance for IPv4 Multicast Service Hot Backup
1. Obtain RBP configurations.

<HUAWEI> display remote-backup-profile profile1
Profile-Name : profile1
Service : bras multicast #Multicast backup is enabled.
Remote-backup-service: service1
Backup-ID : 10
VRRP-ID : 1
Interface :
Eth-Trunk1.1
State : Master
Peer State : Slave
Backup mode : hot
Slot-Number : --
Card-Number : --
Port-Number : --
Traffic threshold : 50(MB)
DHCP user IGMP copy : enable #Indicates that IGMP packets from DHCP
terminals are backed up.
2. Obtain multicast backup statistics.

<HUAWEI> display multicast-rui statistic all
------------------Multicast RUI statistic-------------------
Main board:
Master send to slave: 0 Slave receive: 0
Send fail: 0 Receive fail: 0
Send success: 0 Receive success: 0
Master MPU receive from LPU: 0 Slave MPU send to LPU: 0
Receive fail: 0 Send fail: 0
Receive success: 0 Send success: 0
------------------------------------------------------------
IO board:(Slot 2)
Master LPU send to MPU: 0 Slave LPU receive from MPU: 0
Send fail:0 Receive fail: 0
Send success: 0 Receive success: 0
------------------------------------------------------------
5.6.6.5 Maintenance for L2TP LAC Service Hot Backup
1. Obtain RBP configurations.

<HUAWEI> display remote-backup-profile profile1
Profile-Name : profile1
Service : bras l2tp #L2TP backup is enabled.
Remote-backup-service : s1
Backup-ID : 10
VRRP-ID : 1
Interface :
Eth-Trunk1.1
State : Master
Peer State : Slave
Backup mode : hot
Slot-Number : --
Card-Number : --
Port-Number : --
Traffic threshold : --

2. Obtain hot backup tunnel information.

<HUAWEI> display l2tp tunnel rui
Tunnel ID base: 16384 #Base values must be different on the master and backup
devices.
LTID: local assigned tunnel ID , RTID: Remote assigned tunnel ID
RA: Remote Ip address, RN: Remote Name; RG: Register(L:local,R:remote)
Basic Info Redundant info
------------------------------------------------------------------------------
LTID RTID RA RN Sessions RG state Life(s)
------------------------------------------------------------------------------
7 86 3.3.3.3 HUA-241 1 L active 14s
------------------------------------------------------------------------------
Total 1, printed 1
active indicates that the local end and LNS keep the tunnel keepalive.
Life indicates the tunnel's establishment duration.
3. Obtain hot backup session information.

<HUAWEI> display l2tp session rui
LSID: local assigned session ID , RSID: Remote assigned session ID
RG: Register(L:local,R:remote), FWS: Forwarding state(L:local interface,
P:protect path).
Basic Info Redundant info
------------------------------------------------------------------------------
LSID RSID LTID RTID UserID UserName RG state Life FWS
------------------------------------------------------------------------------
9 75 8 88 8 user#@domain1 L active 669510s L
----------------------------------------------------------------------------
Total 1, printed 1
4. Obtain hot backup statistics.

<HUAWEI> display l2tp statistic rui
statistic of l2tp redundant:
Receive Send
------------------------------------------------------------------------------
Tunnel establish | 100 100
Tunnel teardown | 40 20
Session establish | 300 10
Session teardown | 300 50
Hello packet | 100 100 From remote peer: 100
ZLB packet | 30 30 From remote peer: 30
------------------------------------------------------------------------------
last receive backup message information:
[1] last drop 0 tunnel(s) establish backup message.
[2] last update 2 tunnel(s) backup message.
[3] last create 100 tunnel(s) backup message.
[4] last teardown 40 tunnel(s) backup message.
[5] last one hello/ZLB backup message.
[6] last drop 0 session(s) establish backup message.
[7] last update 0 session(s) backup message.
[8] last create 300session(s) backup message.
[9] last teardown 300 session(s) backup message.
------------------------------------------------------------------------------
5. Obtain hot backup statistics about abnormal users (whose state is master and whose
upstream and downstream traffic does not increase in the master state).
<HUAWEI> display l2tp session lac abnormal-rui-users
The upstream and downstream of following LAC users are all without increasing.
LTSD: local assigned session ID , RTSD: Remote assigned session ID
RG: Register(L:local,R:remote), FWS: Forwarding state(L:local
interface,P:protect path)
LSID RSID LTID RTID UserID UserName RG state MAC
------------------------------------------------------------------------------
27823 248 2 4 7958 user5@hz L active 0011-1111-2222
35523 2769 40000 5 13818 user9@hz R inactive 0011-3333-2222

------------------------------------------------------------------------------
Total 2/2 printed
5.6.6.6 Troubleshooting for L2TP LAC Hot Backup
1. An L2TP user occasionally fails to go online.

Check whether the RBS was interrupted (run the display remote-backup-service command
to view the latest tunnel connection time). If the RBS was interrupted, batch data
synchronization is performed after reconnection. L2TP service access is not performed during
data synchronization. You can also check whether the record "Batch backup starts, the system
rejects new dialing." exists in a log.
2. In load balancing mode, user information backup fails after the master LAC is reset.
Check whether the L2TP tunnel base value configuration on the backup device is correct. The
configuration must be the same on the master and backup devices. An ME60 supports 16K
L2TP tunnels with indexes 1 to 16K and 128K sessions. In L2TPv2, a tunnel ID and session
ID both consist of 16 bits. During session retrieval, a session ID corresponds to two tunnel
IDs. During dual-device deployment, a session ID corresponds to four tunnel IDs and tunnel
IDs on two LACs cannot be duplicate. You can run the display l2tp tunnel rui command to
view a base value, which can be set using the set l2tp tunnel base-id command in the system
view.
If the L2TP tunnel base value configuration is correct, check whether the L2TP user goes
online successfully.
3. L2TP protection fails, and the L2TP tunnel is torn down.
The L2TP tunnel has a flow control mechanism similar to that of TCP. A control packet has a
sequence number, which is used to control packet sending and retransmission. If the send
sequence number NS of a control packet is not within the receive window, the tunnel is torn
down. All sessions in the tunnel are also torn down. Each tunnel has an independent sequence
number and flow control processing.
In L2TP hot backup, devices synchronize tunnel or session information after establishing a
tunnel or session. Devices also synchronize sequence numbers when sending Hello packets
and receiving Hello and ZLB packets. Devices do not synchronize sequence numbers during
tunnel or session establishment.
In hot backup scenarios, when the master LAC is reset (or a fault occurs on the network side),
the sequence number on the backup device becomes incorrect. The hot backup mechanism
enables the backup LAC to receive a control packet from the LNS to correct the sequence
number. However, the semi-connection session that does not complete dial-up still causes the
LNS to tear down the tunnel (the backup LAC has no session information and cannot return a
response to the LNS).
5.6.7 FAQs
1. Must a pair of backup links have the same slot ID and interface number on the master
and backup ME60s?
No. A pair of backup links can have different slot IDs and interface numbers on the
master and backup ME60s.
2. What is the number of address pools that can be bound to an RBS?
A total of 1024 address pools can be bound to an RBS.

3. Must VRRP and BAS interfaces be the same in an RBP?

No. VRRP and BAS interfaces are usually the same in an RBP.
4. Can an RBP cross different physical interfaces?
No. An RBP can control only a physical interface's sub-interfaces.
An RBP can be bound only to an Eth-Trunk's sub-interfaces and cannot cross Eth-
Trunks.
5. What is the number of address pools that can be bound to an RBP?
A total of 1024 address pools can be bound to an RBP.
6. What sub-interfaces can an RBP be applied to?
An RBP can be applied to a maximum of 4094 sub-interfaces.
7. How do I obtain a user's status (master or backup)?
(1) Run the display-access-user command to obtain the interface through which the user
goes online.
(2) Run the display this command in the interface view to obtain the RBP bound to the
interface.
(3) Run the display remote-backup-profile command to check information about the
RBP. State in the command output indicates the RBP's status, that is, the user's status.
8. How do I obtain the forwarding path of a user's traffic?
You can run the display ip routing command to view the user's 32-bit route. If the route
has the primary and backup paths and the primary path is Down or the RBP is in the
backup state, the forwarding path is the backup path. Otherwise, the forwarding path is
the primary path. If the route has only one path, the forwarding path is this path.
9. What are precautions for short lease+hot backup deployment?
If a short lease (for example, 1 minute) is configured, performing a master/backup
switchover may cause terminals to be logged out due to renewal failures, especially
when a large number of users exist. If the short lease function is enabled (for secondary
address assignment for web authentication users) on an interface and a short lease is
configured, performing a master/backup switchover may also cause terminals to be
logged out due to renewal failures.
It is recommended that a lease greater than 30 minutes be configured in preceding
situations.
5.6.8 Acronyms and Abbreviations
Acronym and Full Name

Abbreviation
AC access concentrator
AP access point
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
CoA change-of-authorization
CGN Carrier Grade NAT


Abbreviation
DHCP Dynamic Host Configuration Protocol
DS-Lite Dual-stack Lite
FRR fast reroute
GR graceful restart
GUA globally unique address
IGMP Internet Group Management Protocol
IGP Internal Gateway Protocol
IP6CP IPv6 Control Protocol
IPCP IP Control Protocol
IPoE IP over Ethernet
IS-IS Intermediate System-Intermediate System
L2TP Layer 2 Tunneling Protocol
LAC L2TP access concentrator
LNS L2TP network server
LTS L2TP tunnel switch
MC-Trunk multi-chassis trunk
ME60 multi-service control gateway
NAT Network Address Translation
NCP Network Control Protocol
ND neighbor discovery
NDRA ND Router Advertise
OLT optical line terminal
OSPF Open Shortest Path First
PIM Protocol Independent Multicast
PPPoE PPP over Ethernet
RBP remote backup profile
RBS remote backup service
RG residential gateway
STB set top box


Abbreviation
SLAAC stateless address autoconfiguration
UNR user network route
VLAN virtual local area network
VLL virtual leased line
VPLS virtual private LAN segment
VPN virtual private network
VRRP Virtual Router Redundancy Protocol
5.7 L2TP
5.7.1 L2TP Overview

L2TP - Layer 2 Tunneling Protocol
----------Feature Glance - L2TP----------
What's L2TP?
Layer 2 Tunneling Protocol (L2TP) runs on a virtual private dial-up network (VPDN) and extends the PPP model
by allowing a PPP session to cross an IP network. L2TP is the most popular VPDN tunneling protocol.
LAC LNS
Access
PPP PPP IP
L2TP
Basic L2TP concepts
Item Description
LAC An L2TP access concentrator (LAC) is the initiator of an L2TP tunnel and extends a user's PPP
connection, performs L2TP encapsulation for data received from the user and sends the data to the LNS,
and performs L2TP decapsulation for data received from the LNS and sends the data to the user.
LNS An L2TP network server (LNS) is the terminator of an L2TP tunnel and terminates a user's PPP
connection, performs L2TP decapsulation for data received from the LAC and forwards the data, and
performs L2TP encapsulation for data sent to the user and sends the data to the LAC.
LTS An L2TP tunnel switch (LTS) functions as both the LNS (for connecting to the LAC) and LAC (for
connecting to the LNS), receives a tunnel access request from the LAC, establishes an L2TP tunnel with
the LAC, and initiates an L2TP tunnel establishment request to the new LNS.
Tunnel An L2TP tunnel is used to establish a virtual connection on an IP network and defines an LNS-LAC pair.
Multiple L2TP tunnels can be established between an LNS-LAC pair.
Session An L2TP session is carried on an L2TP tunnel. A tunnel can carry multiple sessions. A session connection
can be established only after a tunnel is established. Each session connection corresponds to a PPP data
flow between an LAC-LNS pair.
L2TP Implementation Principles
L2TP tunnel establishment process

LAC LNS
SCCRQ
SCCRP
SCCCN
ZLB No messages waiting in queue
Start-Control-Connection-Request (SCCRQ): is used to initiate a request to the peer end to

establish a control connection.
Start-Control-Connection-Reply (SCCRP): is sent in response to a received SCCRQ
Note message and allows control connection establishment.
Start-Control-Connection-Connected (SCCCN): is sent in response to a received SCCRP
message and notifies the peer end that tunnel establishment is complete.
Zero-Length Body (ZLB): is sent to the peer end if queues of the local end have no outgoing
messages.
L2TP session establishment process
LAC LNS
Call Detected ICRQ
ICRP
ICCN
ZLB No messages waiting in queue
Incoming-Call-Request (ICRQ): is only sent by the LAC to the LNS when an incoming call is
detected, requesting session connection establishment. The ICRQ carries session
parameters.
Note Incoming-Call-Reply (ICRP): is sent by the LNS to the LAC in response to a received ICRQ
message and allows session connection establishment.
Incoming-Call-Connected (ICCN): is sent by the LAC to the LNS in response to a received
ICRP message and used to instruct the LNS to establish a session connection.
Process for a PPP user's call establishment through an L2TP tunnel
PC LAC RADIUS Server LNS RADIUS Server
1. Call setup
2. PPP LCP setup
3. PAP or CHAP
authentication
4. Access request
5. Access accept
6. Tunnel establishment
7. PAP or CHAP authentication
(challenge/response)
8. Authentication success
9. User CHAP response, PPP
negotiation parameter
10. Access request
11. Access accept

12. CHAP authentication twice (challenge/response)
13. Access request
14. Access accept

15. Authentication success
Step Description
1 The PC initiates a call connection request.
2 The PC and LAC perform PPP LCP negotiation.
3 The LAC performs PAP or CHAP authentication on user information provided by the PC.
4 The LAC sends the authentication information (user name and password) to the RADIUS server for
authentication.
5 The RADIUS server authenticates the user. If the authentication is successful, the RADIUS server returns the
user's LNS address and the LAC is ready to initiate a tunnel establishment request.
6 The LAC initiates a tunnel establishment request to the specified LNS.
7 The LAC sends a CHAP challenge to the LNS, and the LNS returns a CHAP response and sends its own
CHAP challenge to the LAC. The LAC then returns a CHAP response.
8 The tunnel authentication is successful.
9 The LAC sends the user's CHAP response, response identifier, and PPP negotiation parameters to the LNS.
10 The LNS sends the access request information to the RADIUS server for authentication.
11 The RADIUS server authenticates the request information and returns a response if the authentication is
successful.
12 If forcible local CHAP authentication is configured on the LNS, the LNS authenticates the user and sends a
CHAP challenge. The PC returns a CHAP response.
13 The LNS sends the access request information to the RADIUS server for authentication again.
14 The RADIUS server authenticates the request information and returns a response if the authentication is
successful.
15 After the authentication is successful, the LNS and PC perform IPCP negotiation. The user can access
enterprise resources after obtaining an IP address.
L2TP tunnel switching
In certain networking environments, a session may need to traverse multiple tunnels to reach the destination.
Tunnel switching is used to switch sessions from one tunnel to another tunnel.
RADIUS Server RADIUS Server RADIUS Server
IP Network IP Network IP Network
WAN WAN
PSTN/ISDN
Tunnel1 Tunnel2
LNS' LAC'
PC LAC LTS LNS Headquarters
The process for the PC to visit the headquarters is as follows:
The PC initiates a tunnel establishment request to the LAC, and then the LAC
Step 1
establishes a tunnel and session with the LTS.
The LTS finds that the session's destination is not itself and initiates a tunnel
Step 2
establishment request to the LNS.
The LTS transmits the session established with the LAC to the tunnel established with
Step 3
the LNS.
Step 4 When the session reaches the LNS, a PPP connection is established.
Typical L2TP Usage Scenarios
1. Typical user access
RADIUS Server RADIUS Server
PSTN/ISDN Internet
PC DSLAM LAC LNS Headquarters

L2TP Tunnel
A remote dial-up user initiates a PPP connection to the Internet. The DSLAM connects to the LAC
through the PSTN/ISDN. The LAC performs LCP negotiation (link negotiation) and authenticates the
PPP user. After the authentication is successful, the LAC initiates an L2TP tunnel and session
Note connection request to the LNS. After receiving the request, the LNS authenticates the request. If the
authentication is successful, the LNS establishes an L2TP tunnel with the LAC and authenticates the
user based on negotiation information from the LAC. Renegotiation can also be forcibly performed for
the user. If the user authentication is successful, the LNS assigns an IP address to the user.
2. PPPoE+L2TP user access
Enterprise
network 1
ISP1
DSLAM PSTN/ISDN Internet Enterprise

network 2
LAC LNS
L2TP Tunnel
DSLAM
ISP2
The LAC determines whether an L2TP user enters an L2TP tunnel based on the domain to which the
user belongs. ISP1's users are PPPoE users, who access the LAC using PPPoE. The LAC
authenticates the users and connects them to enterprise network 1 after the authentication is
successful. ISP2's users are L2TP users. After establishing PPP connections, these users use the
Note L2TP tunnel between the LAC and LNS to transmit data and connect to enterprise network 2.
3. PC functioning as an LAC
RADIUS Server
PC
(LAC)
Internet
LNS
L2TP Tunnel Headquarters
 The user must install L2TP dial-up software.

 The user can access the Internet and the access mode and place are not limited.
 An L2TP tunnel is established between the user side and LNS and carries one L2TP session.
Note
 When the user has high requirements on information security, IPsec can be used for encryption
and authentication.
4. L2TP accessing L3VPN
PSTN/ISDN Internet L3VPN
PC DSLAM LAC LNS (PE)

L2TP Tunnel
 The LNS serves as a PE of the L3VPN.

 A remote dial-up user initiates a PPP connection.
 The DSLAM connects to the LAC through the PSTN/ISDN. The LAC performs LCP negotiation and
Note
authenticates the user. After the authentication is successful, the LAC initiates an L2TP tunnel and
session connection request to the LNS.
After receiving the request, the LNS authenticates the request. If the authentication is successful,
the LNS establishes an L2TP tunnel with the LAC and authenticates the user based on negotiation
information from the LAC. Renegotiation can also be forcibly performed for the user.
5. LAC accessing LNS through VPN
LNS A and LNS B use the same IP address to establish L2TP tunnels to the LAC. The tunnel between LNS A
and the LAC is configured as VRF1, and the tunnel between LNS B and the LAC is configured as VRF2.
RADIUS Server
VRF1
LNS A
ISP1
user1@isp1
Access Internet
LAC
LNS B
ISP2
user1@isp2 VRF2
The user initiates a PPP connection request to the LAC.

 After authenticating the user, the LAC establishes an L2TP session and tunnel based on the VRF
ID configured in user domain and the LNS's IP address. The VRF ID is used to determine the LNS to
Note
which the connection request is sent.
After the tunnel is established, the LNS authenticates the user and assigns an IP address to the
user if the authentication is successful.
6. L2TP HQoS
L2TP HQoS performs QoS scheduling on users on the LNS side, so that precise control is performed for the
L2TP tunnel and service traffic in the tunnel.
RADIUS Server
Access Internet
PC NAS (LAC) LNS

L2TP Tunnel
L2TP HQoS has the following scheduling modes:

 Tunnel-based scheduling: The services used by a single user are treated in the same manner.
Therefore, user queues are allocated to tunnels, not to users.
Note  Session-based scheduling: A user queue is allocated to each user. A group queue is allocated to
each tunnel. Each user uses 1 to 8 priority queues for SP or WFQ scheduling.
5.7.2 Typical Scenarios and Deployment of L2TP
5.7.2.1 Networking Requirements

On the network shown in Figure 5-6, a single LNS may not be able to carry all L2TP services
due to performance limitations. Load balancing can be used to resolve this issue. The LNC
selects an LNS based on priorities to establish an L2TP tunnel, and the LNS selects a tunnel
board on which the L2TP tunnel will be established based on the number of sessions,
implementing load balancing on the LAC and LNS.
Figure 5-6 Configuring L2TP tunnel load balancing
LNS1
GE1/0/1
GE2/0/0.1 GE1/0/1
Access L2TP
Internet
Network L2TP
GE1/0/2 Headquarter
PC
LAC GE1/0/1
LNS2
5.7.2.2 Feature Deployment

l On the LAC side, configure four LNS IP addresses, which belong to two LNSs, in an
L2TP group, and specify IP addresses and priorities for the LNSs.
l On the LNS side, create an LNS group on each LNS, and bind two tunnel boards and
two interfaces to each LNS group. The IP addresses of the interfaces bound to each LNS
group correspond to the LNS IP addresses configured on the LAC side.
To complete the configuration, you need the following data:
Item Data
LAC's interfaces and l GE 1/0/1: 11.11.11.1/24

IP addresses l GE 1/0/2: 12.12.12.1/24
l Loopback 0: 1.1.1.1/32
LNS1's interfaces and l GE 1/0/1: 11.11.11.2/24

IP addresses l Loopback 0: 3.3.3.3/32
l Loopback 1: 4.4.4.4/32

Item Data
LNS2's interfaces and l GE 1/0/1: 12.12.12.2/24

IP addresses l Loopback 0: 5.5.5.5/32
l Loopback 1: 6.6.6.6/32
PC's user name and l User name: user1@isp1

password l Password: Hello
Tunnel authentication CHAP

mode
Tunnel authentication 1qaz#EDC

password
Tunnel name on the LAC

LAC side
Tunnel name on the l LNS1's tunnel name: LNS1

LNS side l LNS2's tunnel name: LNS2
Number of a virtual 1
template
L2TP group IDs l LAC's L2TP group ID: lac1

l LNS1's L2TP group ID: lns1
l LNS2's L2TP group ID: lns2
Address pool LNS1's address pool:

numbers, ranges, and l Address pool number: pool1
masks
l Range: 10.10.0.10 to 10.10.0.100
l Mask: 255.255.255.0
LNS2's address pool:
l Address pool number: pool1
l Range: 10.10.0.102 to 10.10.0.200
l Mask: 255.255.255.0
5.7.2.3 Configuration Procedure
Configuration Roadmap
1. Configure a user.
2. Configure an LAC.
– Assign IP addresses to the LAC's interfaces and configure reachable routes to
LNSs.
– Configure PPPoX access services on the LAC, including configuring a virtual
template, binding the virtual template to an interface, and configuring a BAS
interface.

– Enable L2TP.
– Configure an L2TP tunnel on the LAC (configure four LNS IP addresses for load
balancing based on priorities).
– Configure a tunnel authentication mode.
– Configure a RADIUS server and a domain from which the user goes online.
3. Configure LNSs.
– Assign an IP address to each LNS's interface and configure a reachable route to the
LAC.
– Configure a virtual template.
– Configure an L2TP tunnel on each LNS.
– Configure a tunnel authentication mode.
– Configure tunnel parameters on each LNS (configure two tunnel boards on each
LNS for load balancing based on the number of sessions).
– Configure an address pool for assigning IP addresses to L2TP users.
– Configure domains for L2TP users and specify the address pool in each domain.
Configuration Procedure
l Configure a user.
Create a dial-up connection, with the number set to the LAC's access number for
receiving an address assigned by an LNS.
Enter the user name user1@isp1 and password Hello (the user name and password have
been registered on the LNS) in the displayed dial-up terminal window.
l Configure an LAC.
a. Assign IP addresses to physical interfaces.
St Command Description
ep
1 <HUAWEI> system-view Set GE 1/0/1's IP address

[HUAWEI] sysname LAC
[LAC] interface gigabitethernet 1/0/1 to 11.11.11.1/24.
[LAC-GigabitEthernet1/0/1] ip address
11.11.11.1 255.255.255.0
[LAC-GigabitEthernet1/0/1] quit
2 [LAC] interface gigabitethernet 1/0/2 Set GE 1/0/2's IP address

[LAC-GigabitEthernet1/0/2] ip address
12.12.12.1 255.255.255.0 to 12.12.12.1/24.
[LAC-GigabitEthernet1/0/2] quit
b. Configure PPPoX access services.

# Configure a virtual template.
ep
1 [LAC] interface virtual-template 1 Configure virtual

[LAC-Virtual-Template1] ppp
authentication-mode chap template 1 and specify
[LAC-Virtual-Template1] quit CHAP authentication.

# Bind virtual template 1 to GE 2/0/0.1.

ep
1 [LAC] interface gigabitethernet 2/0/0.1 Bind virtual template 1

[LAC-GigabitEthernet2/0/0.1] pppoe-server
bind virtual-template 1 to GE 2/0/0.1 (the
[LAC-GigabitEthernet2/0/0.1] user-vlan 1 interface through which
100 the user goes online).
[LAC-GigabitEthernet2/0/0.1-vlan-1-100]
quit
# Configure a BAS interface.

ep
1 [LAC-GigabitEthernet2/0/0.1] bas Configure a BAS

[LAC-GigabitEthernet2/0/0.1-bas] access-
type layer2-subscriber interface, and set the
[LAC-GigabitEthernet2/0/0.1-bas] access type to layer2-
authentication-method ppp subscriber and the
[LAC-GigabitEthernet2/0/0.1-bas] quit
[LAC-GigabitEthernet2/0/0.1] quit
authentication method to
PPP.
c. Create a loopback interface.

ep
1 [LAC] interface loopback0 Set loopback 0's IP

[LAC-LoopBack0] ip address 1.1.1.1
255.255.255.255 address to 1.1.1.1/32.
[LAC-LoopBack0] quit
d. # Create an L2TP group and configure attributes for tunnel load balancing.

ep
1 [LAC] l2tp enable Configure four LNS IP

[LAC] l2tp-group lac1
[LAC-l2tp-lac1] tunnel name LAC addresses, and enable the
[LAC-l2tp-lac1] start l2tp ip 3.3.3.3 ip addresses for load
4.4.4.4 preference 2 ip 5.5.5.5 ip balancing based on
6.6.6.6 preference 4
[LAC-l2tp-lac1] tunnel priority
priorities.
NOTE
l For an L2TP group,
the allow l2tp and
start l2tp commands
are mutually
exclusively.
l Priorities specified for
LNS IP addresses take
effect only after the
tunnel priority
command is run. A
smaller value indicates
a higher priority. An
LAC preferentially
selects an LNS with a
high priority to
establish a tunnel. If
the LNS with a high
priority is unavailable,
an LAC selects an
LNS with the second
high priority to
establish a tunnel. If
LNSs have the same
priority, an LAC
establishes tunnels to
the LNSs in load
balancing mode.
2 [LAC-l2tp-lac1] tunnel authentication Enable L2TP tunnel

[LAC-l2tp-lac1] tunnel password simple
1qaz#EDC authentication, and set a
tunnel authentication
password to 1qaz#EDC.
3 [LAC-l2tp-lac1] tunnel source loopback0 Configure loopback 0 as

[LAC-l2tp-lac1] quit
the tunnel source
interface used for the
LAC to initiate a tunnel
establishment request to
an LNS.
e. Configure a RADIUS server.

ep
1 [LAC] radius-server group radius1 Configure a RADIUS

[LAC-radius-radius1] radius-server
authentication 20.20.20.1 1812 server group named
[LAC-radius-radius1] radius-server radius1, and specify
accounting 20.20.20.1 1813 RADIUS authentication
[LAC-radius-radius1] radius-server shared-
key itellin
and accounting servers.
[LAC-radius-radius1] quit
f. Configure a user access domain.
ep
1 [LAC] aaa Specify an L2TP group

[LAC-aaa] domain isp1
[LAC-aaa-domain-isp1] l2tp-group lac1 named lac1 and an
[LAC-aaa-domain-isp1] radius-server group RADIUS server group
radius1 named radius1 in a
[LAC-aaa-domain-isp1] authentication-
scheme default1
domain.
[LAC-aaa-domain-isp1] accounting-scheme
default1
[LAC-aaa-domain-isp1] quit
g. Configure routes.
ep
1 [LAC] ip route-static 3.3.3.3 Set the next hop address

255.255.255.255 11.11.11.2
[LAC] ip route-static 4.4.4.4 of the LAC to LNS1 to
255.255.255.255 11.11.11.2 11.11.11.2.
2 [LAC] ip route-static 5.5.5.5 Set the next hop address

255.255.255.255 12.12.12.2
[LAC] ip route-static 6.6.6.6 of the LAC to LNS2 to
255.255.255.255 12.12.12.2 12.12.12.2.
l Configure LNS1.
a. Assign an IP address to a physical interface.
ep

[HUAWEI] sysname LNS1
[LNS1] interface gigabitethernet 1/0/1 to 11.11.11.2/24.
[LNS1-gigabitethernet1/0/1] ip address
11.11.11.2 255.255.255.0
[LNS1-gigabitethernet1/0/1] quit
b. Create a virtual template.

ep
1 [LNS1] interface virtual-template 1 Configure virtual

[LNS1-Virtual-Template1] ppp
[LNS1-Virtual-Template1] quit CHAP authentication.
c. Create loopback interfaces.

ep
1 [LNS1] interface loopback0 Set loopback 0's IP

[LNS1-LoopBack0] ip address 3.3.3.3
255.255.255.255 address to 3.3.3.3/32.
[LNS1-LoopBack0] quit

255.255.255.255 address to 4.4.4.4/32.
d. Enable L2TP and create an L2TP group.

ep
1 [LNS1] l2tp enable Create an L2TP group,

[LNS1] l2tp-group lns1
[LNS1-l2tp-lns1] tunnel name LNS1 bind it to virtual template
[LNS1-l2tp-lns1] allow l2tp virtual- 1, and specify the remote
template 1 remote LAC tunnel name as LAC.
NOTE
For an L2TP group, the
allow l2tp and start l2tp
commands are mutually
exclusively.
2 [LNS1-l2tp-lns1] tunnel authentication Enable L2TP tunnel

[LNS1-l2tp-lns1] tunnel password simple
[LNS1-l2tp-lns1] quit tunnel authentication
e. Create and configure an LNS group.

ep
1 [LNS1] lns-group group1 Create an LNS group

[LNS1-lns-group-group1] bind slot 1
[LNS1-lns-group-group1] bind slot 2 named group1, and bind
it to the tunnel boards in
slots 1 and 2.

ep
2 [LNS1-lns-group-group1] bind source Bind loopback 0 and

loopback 0
[LNS1-lns-group-group1] bind source loopback 1 to the LNS
loopback 1 group (the IP addresses
of loopback 0 and
loopback 1 are LNS IP
addresses selected for the
LAC to establish
tunnels).
3 [LNS1-lns-group-group1] tunnel load- Enable load balancing

balance by-session
[LNS1-lns-group-group1] quit based on the number of
sessions in the LNS
group. After the function
is enabled, a tunnel is
preferentially established
on the tunnel board that
has the minimum
number of sessions in the
LNS group.
f. Configure an address pool for address assignment to users.

ep
1 [LNS1] ip pool pool1 bas local Configure a local address

[LNS1-ip-pool-pool1] gateway 10.10.0.1
255.255.255.0 pool named pool1, and
[LNS1-ip-pool-pool1] section 0 10.10.0.10 specify an address
10.10.0.100 segment.
[LNS1-ip-pool-pool1] quit
g. Configure a RADIUS server.

ep
1 [LNS1] radius-server group radius1 Configure a RADIUS

[LNS1-radius-radius1] radius-server
[LNS1-radius-radius1] radius-server radius1, and specify
shared-key itellin
[LNS1-radius-radius1] quit
h. Configure a user access domain.

ep
1 [LNS1] aaa Specify a RADIUS

[LNS1-aaa] domain isp1
[LNS1-aaa-domain-isp1] authentication- server group named
scheme default1 radius1 in a domain, and
[LNS1-aaa-domain-isp1] accounting-scheme bind an address pool
default1
[LNS1-aaa-domain-isp1] radius-server
named pool1 to the
group radius1 domain.
[LNS1-aaa-domain-isp1] ip-pool pool1
[LNS1-aaa-domain-isp1] quit
[LNS1-aaa] quit
i. Configure a route.
ep
1 [LNS1] ip route-static 1.1.1.1 Set the next hop address

255.255.255.255 11.11.11.1
of LNS1 to the LAC to
11.11.11.1.
l Configure LNS2.
a. Assign an IP address to a physical interface.
ep

[HUAWEI] sysname LNS2
[LNS2] interface gigabitethernet 1/0/1 to 12.12.12.2/24.
[LNS2-gigabitethernet1/0/1] ip address
12.12.12.2 255.255.255.0
[LNS2-gigabitethernet1/0/1] quit
b. Create a virtual template.
ep
1 [LNS2] interface virtual-template 1 Configure virtual

[LNS2-Virtual-Template1] ppp
[LNS2-Virtual-Template1] quit CHAP authentication.
c. Create loopback interfaces.
ep

255.255.255.255 address to 5.5.5.5/32.

ep

255.255.255.255 address to 6.6.6.6/32.
d. Enable L2TP and create an L2TP group.

ep
1 [LNS2] l2tp enable Create an L2TP group,

[LNS2] l2tp-group lns2
[LNS2-l2tp-lns2] tunnel name LNS2 bind it to virtual template
[LNS2-l2tp-lns2] allow l2tp virtual- 1, and specify the remote
template 1 remote LAC tunnel name as LAC.
NOTE
For an L2TP group, the
allow l2tp and start l2tp
commands are mutually
exclusively.
2 [LNS2-l2tp-lns2] tunnel authentication Enable L2TP tunnel

[LNS2-l2tp-lns2] tunnel password simple
[LNS2-l2tp-lns2] quit tunnel authentication
e. Create and configure an LNS group.

ep
1 [LNS2] lns-group group1 Create an LNS group

[LNS2-lns-group-group1] bind slot 1
[LNS2-lns-group-group1] bind slot 2 named group1, and bind
it to the tunnel boards in
slots 1 and 2.
2 [LNS2-lns-group-group1] bind source Bind loopback 0 and

loopback 0
[LNS2-lns-group-group1] bind source loopback 1 to the LNS
loopback 1 group (the IP addresses
of loopback 0 and
loopback 1 are LNS IP
addresses selected for the
LAC to establish
tunnels).

ep
3 [LNS2-lns-group-group1] tunnel load- Enable load balancing

balance by-session
[LNS2-lns-group-group1] quit based on the number of
sessions in the LNS
group. After the function
is enabled, a tunnel is
preferentially established
on the tunnel board that
has the minimum
number of sessions in the
LNS group.
f. Configure an address pool for address assignment to users.
ep
1 [LNS2] ip pool pool1 bas local Configure a local address

[LNS2-ip-pool-pool1] gateway 10.10.0.101
255.255.255.0 pool named pool1, and
[LNS2-ip-pool-pool1] section 0 specify an address
10.10.0.102 10.10.0.200 segment.
[LNS2-ip-pool-pool1] quit
g. Configure a RADIUS server.
ep
1 [LNS2] radius-server group radius1 Configure a RADIUS

[LNS2-radius-radius1] radius-server radius1, and specify
shared-key itellin
[LNS2-radius-radius1] quit
h. Configure a user access domain.
ep
1 [LNS2] aaa Specify a RADIUS

[LNS2-aaa] domain isp1
[LNS2-aaa-domain-isp1] authentication- server group named
scheme default1 radius1 in a domain, and
[LNS2-aaa-domain-isp1] accounting-scheme bind an address pool
default1
[LNS2-aaa-domain-isp1] radius-server
named pool1 to the
group radius1 domain.
[LNS2-aaa-domain-isp1] ip-pool pool1
[LNS2-aaa-domain-isp1] quit
[LNS2-aaa] quit

i. Configure a route.
ep
1 [LNS2] ip route-static 1.1.1.1 Set the next hop address

255.255.255.255 12.12.12.1
of LNS2 to the LAC to
12.12.12.1.
5.7.2.4 Checking the Configurations
After you configure L2TP, check the configurations.
Procedure
l Run the test l2tp-tunnel command on the LAC to test the connectivity of L2TP tunnels
with a specified L2TP group and specified LNS IP addresses.
l Run the display l2tp tunnel command to check tunnel establishment.
l Run the display l2tp session command to check session establishment.
Example
Run the test l2tp-tunnel command on the LAC to test the connectivity of L2TP tunnels with
an L2TP group named lac1 and specified LNS IP addresses.
<LAC> test l2tp-tunnel l2tp-group lac1 ip-address 3.3.3.3
Testing L2TP tunnel connectedness now.......
Test L2TP tunnel connectedness success.
<LAC> test l2tp-tunnel l2tp-group lac1 ip-address 5.5.5.5
Testing L2TP tunnel connectedness now.......
Test L2TP tunnel connectedness success.
After the configuration is successful, run the display l2tp tunnel command on the LAC and
an LNS to check that the tunnel is successfully established when a user goes online. The
command output on LNS1 is used as an example.
<LNS1> display l2tp tunnel
---------------------------------------------------------
-----------tunnel information in LAC----------------------
Total 0,0 printed
---------------------------------------------------------
-----------tunnel information in LNS----------------------
The tunnel information of k board 1
LocalTID RemoteTID RemoteAddress Port Sessions RemoteName
---------------------------------------------------------
13921 7958 11.11.11.1 1701 1 LAC
---------------------------------------------------------
Total 1,1 printed from slot 1
Table 5-6 Description of the display l2tp tunnel command output

Item Description
LocalTID Local tunnel ID
RemoteTID Remote tunnel ID

Item Description
RemoteAddress Remote IP address
Port Remote port number
Sessions Number of sessions
RemoteName Remote name
# Run the display l2tp session command to check session establishment. The command
output on LNS1 is used as an example.
<LNS1> display l2tp session lns slot 1
LocalSID RemoteSID LocalTID RemoteTID UserID
UserName
------------------------------------------------------------------------------
2036 1469 13921 7958 62172

user1@isp1
------------------------------------------------------------------------------
Total 1, 1 printed from slot 1
Table 5-7 Description of the display l2tp session command output
Item Description
LocalSID Local session ID, which uniquely identifies a session
RemoteSID Remote session ID, which uniquely identifies a

session
LocalTID Local tunnel ID
RemoteTID Remote tunnel ID
UserID User ID
UserName User name
5.7.3 List of L2TP RADIUS Attributes

Standard L2TP RADIUS attributes and implementation:
Table 5-8 Standard L2TP RADIUS attributes
Attribute Attribute Name Description

No.
64 Tunnel-Type Tunnel protocol type. The value is an integer. If

the value is 3, the tunnel protocol type is L2TP.


No.
65 Tunnel-Medium-Type Tunnel bearer medium type. The value is fixed

at 1. If the value is incorrectly delivered, a
tunnel cannot be established.
66 Tunnel-Client-Endpoint IP address of the LAC that initiates a tunnel

establishment request. The IP address is in
dotted decimal notation. One tag can deliver
only one IP address.
67 Tunnel-Server-Endpoint IP address of the LNS that establishes a tunnel.

The IP address is in dotted decimal notation. A
tag can deliver a maximum of eight IP
addresses, with each IP address separated by a
space. Multiple IP addresses work in primary/
secondary mode.
68 Acct-Tunnel-Connection Accounting ID of the tunnel server. The format

is <TunnelID>-<SessionID>, for example,
12-1245. The attribute takes effect after tunnel-
acct-2867 is configured in a domain.
69 Tunnel-Password Tunnel authentication password. A plaintext or

ciphertext password with a maximum of 253
bits is supported.
82 Tunnel-Assignment-ID Tunnel ID, a main factor of the tunnel selection

algorithm in RFC 2868
83 Tunnel-Preference Tunnel priority. The attribute takes effect when

multiple L2TP attributes are delivered. L2TP
tunnels with the same priority work in load
balancing mode, and L2TP tunnels with
different priorities work in primary/backup
mode.
90 Tunnel-Client-Auth-ID Local end name of a tunnel, which supports a

maximum of 253 characters
91 Tunnel-Server-Auth-ID Remote end name of a tunnel, which supports a

maximum of 253 characters. A device can
parse and save the attribute. The attribute is
used to determine the validity of SCCRP
packets.
Huawei proprietary L2TP RADIUS attributes and implementation:

Table 5-9 Huawei proprietary L2TP RADIUS attributes

No.
26-96 HW-Tunnel-Group-Name Name of an L2TP group. The length is 32

characters. The delivered L2TP group name
must be a locally configured correct name.
26-89 HW-L2TP-Terminate- L2TP user logout cause. The attribute is carried

Cause in an accounting stop packet sent to the AAA
server and encapsulated with AVP 46. The
format is Logout code (2 bytes)+Control
protocol number (2 bytes)+Direction (1 byte)
+Validity flag (1 byte)+L2TP AVP 46
information (0 to 64 bytes).
26-80 HW-Tunnel-Session-Limit Number of sessions limited for each tunnel.

The value ranges from 0 to 16284.
26-63 HW-Tunnel-VPN-Instance Name of the VPN instance on the local end of a

tunnel. The attribute must be delivered with
No. 66 standard attribute, and a tag is
supported.
5.7.4 L2TP Tunnel Reliability

LAC-Side Load Balancing
Load balancing mode:
l The start l2tp [ ip ip-address [ weight lns-weight | preference preference | remote lns-
name ] * ] &<1-8> command can be locally run to implement a maximum of eight LNS
IP addresses for tunnel load balancing.
l 31 tags can be delivered over RADIUS, and each tag contains eight LNS IP addresses for
tunnel load balancing.
Load balancing algorithm:
l Primary/Secondary mode
a. After receiving an L2TP session establishment request, the LAC selects an LNS IP
address based on the sequence of the LNS IP addresses configured in the command
or of the tags delivered by the RADIUS server.
b. If no tunnel is established for the LNS IP address, the LAC initiates a tunnel
establishment request to the LNS. After a tunnel is established, a session is
established on the tunnel.
c. If a tunnel has been established for the LNS IP address, the LAC establishes a
session on the tunnel.
d. If the preceding process fails, the LAC selects another LNS IP address for an
attempt until it successfully selects an LNS IP address and establishes a session.
l Weight-based mode

a. After receiving an L2TP session establishment request, the LAC searches the
configured eight LNS IP addresses or the tags delivered by the RADIUS server for
an LNS IP address. If the LAC finds an LNS IP address for which no tunnel is
established, it initiates a tunnel establishment request to the LNS.
b. If tunnels have been established for all the LNS IP addresses, the LAC selects a
tunnel with the minimum value of Number of sessions on a tunnel/Tunnel weight to
establish a session.
c. If a tunnel fails to be established or is deleted unexpectedly, the LNS IP address
cannot be used to establish a tunnel within a period unless the address is the last
one.
l Priority-based mode
a. After receiving an L2TP session establishment request, the LAC selects an LNS IP
address from the LNS IP addresses configured in the command or the tags delivered
by the RADIUS server based on priorities.
b. The LAC preferentially selects an LNS IP address or tag with a high priority to
establish a tunnel. If the LNS IP address or tag with a high priority is unavailable,
an LAC selects an LNS IP address or tag with the second high priority to establish a
tunnel. If LNS IP addresses or tags have the same priority, the LAC establishes
tunnels to the LNSs in load balancing mode.
LNS-Side Load Balancing

1. Multiple tunnel boards can be bundled as one tunnel board on the LNS side.
2. When the LAC initiates a tunnel establishment request to an LNS, the LNS selects a
tunnel board to establish a tunnel based on the load balancing configuration. The tunnel
board corresponds to the established tunnel's ID.
3. After receiving a packet, the LNS selects a tunnel boards for L2TP processing based on
the tunnel ID.
Symptom
After L2TP is configured, an L2TP user fails to go online.
Common Causes
l Layer 3 forwarding between the LAC and the LNS fails.
l L2TP is not enabled on the LAC or the LNS.
l L2TP group attributes of the LAC and the LNS are not matched.
l The LAC and the LNS do not have the consistent tunnel authentication scheme or
password.
l Strict tunnel authentication has been configured for the LAC, and the remote tunnel
name configured on the LAC is inconsistent with the tunnel name configured on the
LNS.
l The LNS group is incorrectly bound to the tunnel board and loopback interface.
l The PPPoX service fails.
l The IP address pool is incorrectly configured, and the IP address pool fails to allocate a
correct IP address to the L2TP user.

l The VPN accessed by the L2TP user is incorrectly configured.
Troubleshooting Flowchart
Figure 5-7 shows the troubleshooting flowchart.

Figure 5-7 Troubleshooting flowchart for the failure of the L2TP user to get online
An L2TP user
fails to get online
Yes
No Rectify the fault of the link

Can the LAC ping the LNS successfully? Is fault rect
between the LAC and the LNS.
No
Yes
No
Is L2TP enabled on the LAC and the Enable L2TP Is fault rect
LNS?
No
Yes
No
Are the L2TP group and its attributes Correctly configure the L2TP
correctly configured for the LAC and the Is fault rect
group and its attributes
LNS?
No
Yes
Configure tunnel authentication

Are the tunnel authentication No
for the LAC and the LNS and
mode and password correct for the LAC Is fault rect
and the LNS? set the matched user name
and password
No
Yes
Is AAA authentication Configure tunnel authentication

configured on the LAC? Is the No and consistent user names and
remote tunnel name configured on the LAC Is fault rect
consistent with the tunnel name passwords for the LAC
configured on the LNS? and LNS
No
Yes
No
Correctly configure the LNS
Is the LNS group correctly configured? Is fault rect
group and its attributes
No
Yes
No
Is the PPPoX service normal? Correctly configure user access Is fault rect
No
Yes
Issue 01 (2016-06-30) Huawei Proprietary and Confidential

No Correctly configure an IP
173
Copyright © Huawei Technologies Co., Ltd. address pool for the user Is fault rect
Can the L2TP obtain an IP address?
domain on the LNS side
No
Yes
Troubleshooting Procedure
1. Check that the LAC can ping the LNS successfully.
– If the ping operation succeeds, it indicates that the Layer 3 forwarding between the
LAC and the LNS is normal. Then, go to Step 2.
– If the ping operation fails, you need to check the Layer 3 connectivity between the
LAC and the LNS.
2. Check that L2TP is enabled on the LAC and the LNS.
Run the display current-configuration | include l2tp command on the LAC and the
LNS.
– If the command output shows l2tp enable, it indicates that L2TP is correctly
enabled on the LAC and the LNS. In this case, go to Step 3.
– If the command output does not show l2tp enable, you need to configure the l2tp
enable command to enable L2TP. After the configuration, if the fault persists, go to
Step 3.
3. Check that the L2TP group attributes of the LAC and the LNS are correctly configured.
– On the LAC
Run the display l2tp-group group-name command and check whether the LNS
address specified by the LnsIPAddress field is the same as the actual LNS address.
If they are different, run the start l2tp command to set them the same.
– On the LNS
Run the display l2tp-group group-name command to check the following fields.
n Check the RemoteName field to see whether the tunnel name specified on the
LNS is the same as the tunnel name specified on the LAC.
n Check the VTNum field to see whether the bound VT is the same as the VT of
the tunnel interface.
NOTE
The name of the remote tunnel end, that is, remote-name, must be specified for the L2TP
group (except the default L2TP group, default-lns) when the L2TP tunnel is configured on
the LNS.
If the specified remote tunnel end is inconsistent with the actual remote tunnel end,
you need to run the allow l2tp virtual-template virtual-template-number remote
remote-name command to make them the same.
If the L2TP group attributes are correctly configured but the fault persists, go to Step 4.
4. Check that the LNS group is correctly configured.
– Run the display lns-group name lns-name command on the LNS to check the Slot
and Interface fields to see whether the tunnel group is bound to the tunnel board
and loopback interface. If the tunnel group is not bound to the tunnel board and
loopback interface, run the bind slot slot-id and the bind source interface-type
interface-number commands in the LNS group view to bind them.
– If the LNS group is correctly configured but the fault persists, go to Step 5.
5. Check that consistent tunnel authentication scheme and password are configured on the
LAC and the LNS.
Run the display l2tp-group group-name command on the LAC and the LNS to check
the TunnelAuth, Tunnel aaa Auth, and RADIUS-auth fields. These fields show

whether the authentication schemes of both the LAC and the LNS are the same. If these
fields indicate that the authentication schemes are different, you need to set them the
same.
– If the tunnel authentication scheme is configured, you need to check whether the
tunnel authentication passwords configured on the LAC and the LNS are the same.
If they are different, run the tunnel password { simple | cipher } password
command to set the same password.
NOTE
The tunnel authentication request can be initiated by the LAC or the LNS. As long as one
end is enabled with tunnel authentication, the authentication is performed in the tunnel setup
process. The tunnel can be set up only if the passwords of both ends are the same and not
vacant.
– If the authentication schemes and passwords are the same on both tunnel ends but
the fault persists, go to Step 6.
6. Check that strict tunnel authentication is configured for the LAC, and the remote tunnel
name configured on the LAC is consistent with the tunnel name configured on the LNS.
Run the display l2tp-group group-name command on the LAC. If Use tunnel
authentication strict is displayed in the TunnelAuth field, strict tunnel authentication is
configured for the LAC.
– If strict tunnel authentication is used, check that the remote tunnel name configured
on the LAC is consistent with the tunnel name configured on the LNS.
n If they are inconsistent, run the start l2tp [ ip ip-address [ weight lns-
weight ] ] & <1-8> command on the LAC and run the tunnel name tunnel-
name command on the LNS to change the remote tunnel name on the LAC and
the tunnel name on the LNS to be consistent.
n If they are consistent, go to Step 7.
– If strict tunnel authentication is not configured, go to Step 7.
7. Check that the PPPoX service is normal.
If the PPPoX service is normal but the fault persists, go to Step 8.
8. Check that the L2TP user is assigned an IP address.
– If the user is not assigned an IP address, you need to correctly configure the IP
address pool on the LNS.
– If the user is assigned a correct IP address but the fault persists, go to Step 9.
9. Check that the VPN instance is correctly configured.
If the L2TP user accesses the VPN, run the display current-configuration command to
check the following:
– Check whether the VPN instance is configured with the RD.
– Check whether the interface connecting to the enterprise is bound to a VPN
instance.
– Check whether the domain is bound to the VPN instance.
– Check whether the IP address pool is bound to the VPN instance.
If the VPN instance is correctly configured but the fault persists, go to Step 10.
10. Collect the following information and contact Huawei technical support personnel.
– Results of the preceding troubleshooting procedure
– Configuration files, log files, and alarm files of the devices

5.7.6 FAQs
Which Interface Address Does a Router Select to Send L2TP Packets?

The following scenarios are involved:
l If the RADIUS server delivers the address of a tunnel's local end through No. 66
attribute Tunnel_Client_Endpoint, a router uses this address as the source address to send
L2TP packets to the LNS.
l If the RADIUS server does not deliver the Tunnel_Client_Endpoint attribute, a router
selects the address of the interface bound to the L2TP group using the tunnel source
interface-type interface-number command as the source address to send L2TP packets to
the LNS.
l If no interface is bound to the L2TP group, a router uses the IP address of the interface
that can reach the LNS in the local routing table as the source address to send L2TP
packets to the LNS. Generally, the address of the upstream interface on the router is
used.
What Is the L2TP Tunnel Authentication Process?

If tunnel authentication is configured on both ends, the L2TP tunnel authentication process is
as follows:
l Tunnel authentication and tunnel establishment are performed simultaneously.
l When sending an SCCRQ message to the LNS, the LAC generates a random character
string as the local CHAP Challenge and sends it to the LNS. After receiving the
Challenge, the LNS generates a new character string based on the Challenge, locally
configured password, and SCCRP message, uses MD5 to calculate a 16-byte Response,
generates a random character string (LNS Challenge), and sends the Response and
random character string to the LAC through an SCCRP message.
l Authentication process on the LAC: The LAC generates a new character string based on
its own CHAP Challenge, locally configured password, and SCCRP message, uses MD5
to calculate a 16-byte character string, and compares the character string with the LNS
CHAP Response in the SCCRP message from the LNS. If they are the same, the
authentication is successful; otherwise, the tunnel is disconnected.
l LAC authentication on the LNS: After finding the LNS CHAP Challenge in the SCCRP
message, the LAC generates a new character string based on the LNS CHAP Challenge,
locally configured password, and SCCCN message, uses MD5 to calculate a 16-byte
character string as the LAC CHAP Response, and sends the LAC CHAP Response to the
LNS through an SCCCN message. After receiving the SCCCN message, the LNS
generates a character string based on its own CHAP Challenge, locally configured
password, and SCCCN message, uses MD5 to calculate a 16-byte character string, and
compares the character string with the LAC CHAP Response in the SCCCN message. If
they are the same, the authentication is successful; otherwise, the tunnel is disconnected.
If the LNS Is a Huawei Device but the LAC Is a Non-Huawei Device, What Are
Precautions for Configurations on the LNS?
The LNS does not support some parameters for LAC and PC PPP prenegotiation, and no PPP
session can be established on the LNS. PPP renegotiation parameters must be configured on
the LNS to force the LNS to perform PPP renegotiation with the PC.

If the LAC Is a Huawei Device but the LNS Is a Non-Huawei Device, What Are
Precautions for Configurations on the LAC?
The LAC does not support some parameters for LNS and PC PPP prenegotiation, and no PPP
session can be established on the LAC. Before configuration, check whether negotiation
parameters are supported on the LNS and PC.
How Does an NE80E/40E Functioning as an LAC Match the Master and Backup
LNSs in an L2TP Group?
An NE80E/40E functions as an LAC, and multiple LNSs are configured in an L2TP group. If
the tunnel load-sharing command is not run in the L2TP group, one of the LNSs is
configured as the primary LNS and the other ones are backup LNSs. You can run the display
l2tp-group command to view information about the LNSs. The first one is the primary LNS,
and the other ones are backup LNSs.
When the NE80E/40E cannot establish a connection to the primary LNS, the NE80E/40E
sends a request packet for establishing a connection to the backup LNSs in order until a
connection is established successfully. A timer is configured on the NE80E/40E. After the
timer times out, the primary LNS is in the Up state. If the primary LNS is normal, the
NE80E/40E establishes a connection to the primary LNS only. During the timeout period of
the timer, the NE80E/40E establishes connections to the backup LNSs even if the primary
LNS is normal.
If the PPP Authentication Mode Configured on the LNS Is Different from That
on the LAC, Can a User Be Authenticated or Join a VPN?
When different PPP authentication modes are configured on the LAC and LNS, PPP dial-up
terminals must be compatible with both PAP and CHAP authentication modes; otherwise a
user cannot be authenticated.
When the PPP authentication mode is set to PAP authentication on the LAC but is set to
CHAP authentication on the LNS, the user is authenticated by the LAC in plaintext mode.
After the LAC authenticates the user, the LNS authenticates the user. LCP parameters
negotiated with the LAC are sent to the LNS. The LNS refuses to receive unacceptable
parameters, including the authentication mode. Then, the secondary negotiation is triggered.
CHAP authentication is specified in the secondary negotiation. The LNS delivers the
challenge word and completes authentication.
In L2TP Access Scenarios, What Are Precautions for Configurations on the LAC
and LNS?
In L2TP access scenarios, precautions for configurations on the LAC and LNS are as follows:
l L2TP must be enabled on the LAC and LNS.

l IPv6 forwarding must be enabled on the LAC and LNS.
l The same L2TP group must be configured on the LAC and LNS.
l The IP address of the LNS must be bound to the L2TP group on the LAC.
l A tunnel must be configured in the L2TP group on the LAC.
l The tunnel configured in the L2TP group on the LAC must be bound to the L2TP group
on the LNS.

l Tunnel authentication modes and passwords configured on the LAC and the LNS must
be consistent.
Acronym and Abbreviation Full Name
LAC L2TP access concentrator
LNS L2TP network server
PPP Point-to-Point Protocol
RADIUS Remote Authentication Dial User Service
5.8 BOD


5.8.1 BOD Service Feature
5.8.1.1 BOD Overview
Definition
Bandwidth on demand (BOD) is a value-added service featuring dynamic bandwidth
allocation. When users need to adjust their bandwidths, they can dynamically activate or

deactivate the BOD service through a portal server. User bandwidths are dynamically changed
without carriers' intervention.
Compared with DAA and EDSG, BOD can implement user-level bandwidth adjustment but
cannot adjust a service's bandwidth. No license is required for BOD.
BOD allows user bandwidths to be dynamically allocated and some basic user attributes (such
as ACL groups, user priorities, and accounting policies) to be modified.
Figure 5-8 BOD
Customer
Engineer User
service
Traditional mode: Services can only be modified in a carrier's
business hall, which is time-consuming.
Policy
Self-service
delivery
application
Self-service
Service modification No customer or
takes effect in real engineer service
time. is required.
BOD mode: Users can use a portal to change services any time
anywhere, which is time-saving.
Characteristics
The BOD service has the following characteristics:
l User bandwidths can be dynamically changed.

l Users can randomly change bandwidths when using bandwidth guaranteed services.
l Profit source: Different tariffs are used for different bandwidths or traffic volumes.
l Service mode: refined bandwidth control and user self-service.
l Accounting mode: duration-based accounting or traffic-based accounting.
Typical Applications
BOD is intended for individuals or small- and medium-sized enterprise (SME) leased line
users who usually do not require high access bandwidths but occasionally require bandwidth
bursts. For users who use high-bandwidth services (such as video services), BOD enables
them to use a self-service method to increase the total access bandwidth. After users no longer
require the increased bandwidth, they can restore the basic access bandwidth.

Figure 5-9 BOD service

Advertisement: Provide high-bandwidth services on
demand and online (8 MB: 3 yuan/hour; 20 MB: 5
yuan/hour). For details, visit www.xxx.com. You can
activate the service at the website.
Portal
Change the Voice
bandwidth online.
The 512 KB
bandwidth is
insufficient to watch
HD videos, but a ISP1 Video
monthly package
with the 8 MB
bandwidth is too
expensive. What Download
ISP2
shall I do?
Email
5.8.1.2 BOD Service Process

A user obtains the basic bandwidth when going online in a specific access authentication
mode.
After going online, the user accesses the portal server and selects a desired bandwidth type.
The portal server delivers the selected bandwidth type to the policy server.
The policy server delivers the bandwidth index to the BNG based on the selected bandwidth
type. The BNG obtains bandwidth data from the local configuration based on the bandwidth
index and sets a bandwidth for the user. After the bandwidth takes effect, the user can use
network resources based on the new bandwidth.

Figure 5-10 BOD service process

3. Applies for
bandwidth Policy server AAA server
resources. 1. Visits ISP1's
network using
Portal server the default
7. Reports
bandwidth. ISP1
accounting
information.
Internet
ISP2
4. Sends
bandwidth 6. Visits ISP2's
parameters. network using the
Metro backbone
selected bandwidth.
5. Adjusts user layer
bandwidth. BNG
BNG
2. Use the
portal to apply
for desired
bandwidth. Metro access layer L3
User
The user needs to

adjust bandwidth online
in self-service mode.
BOD service interfaces are classified as COPS, CoA (RADIUS), or Diameter interfaces.
Interface Characteristics
COPS Bandwidths, user groups, priorities, and multicast

templates can be modified.
CoA (RADIUS) An AAA server also functions as a policy server,

which can deliver attributes (such as quotas and
multicast templates) together with BOD service
polices. Services are easy to expand.
NOTE
A CoA interface can be used to deliver BOD service polices
or directly deliver attributes to change user bandwidths.
Differences between the two delivery modes are as follows:
After BOD service polices are delivered, users' basic service
traffic is counted into the generated BOD service and
accounting information after bandwidth change is sent to the
server. When a CoA interface is used to deliver attributes to
change user bandwidths, no service is generated but users'
real-time accounting packets are sent after bandwidth
change.

Interface Characteristics
Diameter BOD service policy name and BOD service polices

can be delivered.
l A RADIUS server delivers the HW-Policy-Name attribute through a CoA interface.

NOTE
BOD service policies are configured, and QoS profiles are bound to the policies.
A CoA interface is used to deliver the HW-Policy-Name attribute to adjust user bandwidths.
The attribute involved is as follows:
No. Attribute Attr Se Description Remarks
ibut rv
e er
Typ T
e y
pe
26-9 HW-Policy- strin Al Name of a value- The length is 32

5 Name g l added service characters. In some
policy. A packet versions, the name of a
can carry a value-added service
maximum of 16 policy is Policy-Name.
HW-Policy-Name Multiple policy names
attributes to can be delivered in a
deliver 16 value- Huawei No. 95
added services. attribute, and these
(For the DAA policy names are
service, a packet separated by vertical
can carry only one bars (|).
HW-Policy-Name
attribute; for the
EDSG service, a
packet can carry a
maximum of eight
HW-Policy-Name
attributes.)
l A RADIUS server delivers the HW-Domain-Name attribute through a CoA interface.

NOTE
Domains are configured, and QoS profiles are bound to the domains.
A CoA interface is used to deliver the HW-Domain-Name attribute.
The attribute involved is as follows:

No. Attribute Attri Server Description Remarks

bute Type
Typ
e
26-13 HW-Domain- Strin Standar Domain name used 64 bytes

8 Name g d, in user
Plus11 authentication. The
domain name may
be a roaming or
mandatory domain
name. The domain
name may not be the
domain name in the
user name.
l A RADIUS server delivers CAR or QoS profile attributes through a CoA interface.
NOTE
After users go online, a RADIUS server delivers CAR or QoS profile attributes through a CoA
interface.
The attributes involved are as follows:
No Attribut Attribute Server Description Remarks

. e Type Type
HW- The length is 4

Input- Upstream bytes. The attribute
Committ committed 26-2 must be
26- ed-Burst- Standard, burst size delivered together
1 Size Integer Plus11 (CBS), in bits. with this attribute.
26- HW- Integer Standard, Upstream The length is 4

2 Input- Plus11 committed bytes.
Committ information
ed- rate (CIR), in
Informati bit/s.
on-Rate
26- HW- Integer Standard, Upstream The length is 4

3 Input- Plus11 peak bytes. The attribute
Peak- information is used only in dual
Informati rate (PIR), in leaky bucket. The
on-Rate bit/s. attribute 26-2 must
be delivered
together with this
attribute.
26- HW- Integer Standard, Downstream The length is 4

4 Output- Plus11 CBS, in bits. bytes. The attribute
Committ 26-5 must be
ed-Burst- delivered together
Size with this attribute.

No Attribut Attribute Server Description Remarks

. e Type Type

5 Output- Plus11 CIR, in bit/s. bytes.
Committ
ed-
Informati
on-Rate

6 Output- Plus11 PIR, in bit/s. bytes. The attribute
Peak- is used only in dual
Informati leaky bucket. The
on-Rate attribute 26-5 must
be delivered
together with this
attribute.
26- HW- String All QoS profile The maximum

31 QOS- delivered by a length is 32 bytes.
Profile- RADIUS
Name server.
When a home
user accesses a
device, the
attribute is
used to
configure
bandwidths
for the home
user's each
service. When
a common
user accesses a
device, the
attribute is
used to
configure the
common user's
total
bandwidth and
traffic
scheduling
preference.

5.8.1.2.1 BOD Service Process (Diameter Gx Interface)
Figure 5-11 BOD service process (Diameter Gx interface)

Portal
Subscriber BNG Radius Server Diameter Server Server
Access request
Apply session Access-accept (basic qos policy)
qos resource
1: base Session Accounting Start (for base user)
user is Accounting ACK
online
2: base Gx CCR-I request
user send Gx CCA-I (can install the BOD service)
CCR
Install BoD
3: Select service via soap
the bod Install BoD service via Gx RAR
service Gx RAA
4: policy’s Accounting Start (for bod service)

start
Accounting Response
accounting
5: policy’s Gx CCR-U (for policy’s quota-out)
quota-out,
request Send the new quota via Gx CCA-U
new
Install BoD
6: Remove service via soap
Remove BoD service via Gx RAR
the bod
service Gx RAA request
Accounting Stop (for bod policy)

7: policy’s
stop Accounting ACK
accounting
1. The user sends an access request, and the BNG performs RADIUS authentication and
sends an Accounting Start message to the RADIUS server.
2. The BNG uses a CCR-I message to send user information to the policy server.
a. After the user goes online, the BNG uses a CCR-I message to send user information
to the policy server through the Gx interface.
b. The policy server sends a CCA-I message to the BNG through the Gx interface.
This message can carry a BOD service policy name and BOD quota information.

NOTE
l If this message carries only a BOD service policy name, Steps 3 and 5 are not required.
l If this message carries both a BOD service policy name and BOD quota information, Step 3 is
not required.
l If this message carries neither a BOD service policy name nor BOD quota information, Step 3
is required.
3. The user selects a BOD service through the portal server, and the portal server delivers
the BOD service.
a. The user accesses the portal server and selects a desired BOD service policy or
bandwidth parameter on the portal server.
b. The portal server delivers the selected BOD service policy or bandwidth parameter
to the policy server through the SOAP interface.
c. The policy server uses an RAR message to deliver the BOD service policy name or
bandwidth parameter to the BNG through the Gx interface. (If the RAR message
carries the BOD quota information, Step 5 is required. If the RAR message does not
carry the BOD quota information, Step 5 is not required.)
4. The BNG sends a RADIUS Accounting Start message for the BOD service.
a. After generating a BOD service, the BNG sends a RADIUS Accounting Start
message for the BOD service to the RADIUS server by default. You can configure
the BNG not to send a RADIUS Accounting Start message for the BOD service.
b. After receiving the RADIUS Accounting Start message, the RADIUS server returns
a RADIUS Accounting Response message.
5. The BNG performs quota management for the BOD service if the RAR or CCR-I
message carries the quota information during BOD service delivery.
a. If the quota information is carried during BOD service installation, the BNG
performs quota management for the BOD service. After the quota is exhausted, the
BNG uses a CCR-U message to notify the policy server of the quota exhaustion
through the Gx interface.
b. The policy server checks whether a new quota is available. If a new quota is
available, the policy server uses a CCA-U message to deliver the new quota. If no
new quota is available, the policy server uses an RAR message to remove the BOD
service.
6. The policy server removes the BOD service.
a. The policy server uses an RAR message to remove the BOD service through the Gx
interface, which can be triggered when the quota is exhausted and no new quota is
available or when the user actively removes the BOD service through the portal
server.
b. After removing the BOD service, the BNG uses an RAA message to notify the
policy server of the removal through the Gx interface.
7. The BNG sends a RADIUS Accounting Stop message for the BOD service.
a. After removing the BOD service, the BNG sends a RADIUS Accounting Stop
message for the BOD service to the RADIUS server by default. You can configure
the BNG not to send a RADIUS Accounting Stop message for the BOD service.
b. After receiving the RADIUS Accounting Stop message, the RADIUS server returns
an Accounting ACK message to the BNG.

5.8.1.2.2 BOD Service Process (COPS Interface)

Users can visit a portal page to select desired services. The portal server notifies the policy
server of the selected services. The policy server then delivers the corresponding service
policy to the BNG.
Figure 5-12 BOD service process (COPS interface)
Terminal AAA server BNG Portal Server Cops/Policy Server
1. Initiates a login
request. 2. Instructs the
AAA server to
authenticate the
user. 3. Sends a login
notification.
4. Access the portal
page. 5. Sends user
and service
information.
6. Delivers the
BOD service
7. Sends an
policy.
accounting start
packet.
8. Notifies the portal.
9. Notifies the
terminal that BOD
services have been
activated.
10. Reports the
traffic volume.
1. The user initiates a login request to the BNG.

2. The BNG instructs the AAA server to authenticate the user. After the user is
authenticated, the AAA server performs authorization and starts accounting for the user.
3. After the user logs in, the BNG sends a login notification to the policy server and
registers user information.
4. The user accesses the portal server's portal page to customize a BOD service.
5. After the user submits the customization request, the portal server sends the user
information and customized BOD service information to the policy server.
6. The policy server delivers the BOD service policy to the BNG through the negotiated
Diameter/COPS/RADIUS interface.
7. The BNG enforces the BOD service policy delivered by the policy server. After
installing the BOD service, the BNG sends an Accounting Start message for the BOD
service.
8. The policy server notifies the portal server that the BNG has installed the BOD service.

9. The portal server uses the portal page to notify the user that the BOD service has been
activated and can be used.
10. The user starts to use the BOD service. The BNG performs accounting and control for
the BOD service based on the BOD service policy and reports the traffic volume to the
policy server.
The COPS message exchange process for the BOD service is as follows:
Figure 5-13 COPS message exchange process for the BOD service
BNG Cops/Policy Server
1.OPN Message
2.CAT Message
Apply for new bandwidth.
3.REQ Message
4.DEC Message
5.RPT Message
Restore the default bandwidth.
6.DRQ Message
7.KA Message
1. The BNG sends the policy server a Client-Open (OPN) message (Code = 6) with the
Client-type field set to client. After receiving the OPN message, the policy server sends a
Client-Accept (CAT) message (Code = 7) to the BNG to establish a client-server
relationship.
2. After the BNG receives the CAT message, a client-server relationship is established.
3. After the user goes online, the BNG sends the policy server a Request (REQ) message
(Code = 1) carrying information such as the user's IP address and name.
4. After the policy server receives the REQ message, the user logs in to the portal page to
customize a BOD service. The policy server then sends a Decision (DEC) message
(Code = 2) carrying a BOD service policy to the BNG.
5. After enforcing the BOD service policy carried in the DEC message, the BNG sends a
Report State (RPT) message (Code = 3) to the policy server, indicating that the BOD
service policy has been enforced.

6. If the state identified by the client handle on the BNG does not take effect, the BNG
sends a Delete Request State (DRQ) message (Code = 4) to the policy server.
7. The BNG and policy server send Keepalive (KA) messages (Code = 9) to each other.
5.8.1.2.3 BOD Service Process (RADIUS CoA Interface)
BOD Service Activation and Deactivation Process

After a user goes online, the RADIUS server uses a CoA message to deliver Huawei No. 95
attribute carrying a configured BOD service policy name. The BNG obtains configured BOD
parameters based on the BOD service policy and generates a BOD service.
The RADIUS server uses a CoA message to activate a BOD service and a DM message to
deactivate a BOD service.
When the RADIUS server uses a CoA message to directly change user bandwidths, the BNG
cannot send Accounting Start/Stop messages. No license is required for this situation.
The BOD service process is as follows:
NOTE
In this example, the user's basic bandwidth and new bandwidth are 2 Mbit/s and 5 Mbit/s, respectively.

Figure 5-14 BOD service process
Subscriber BNG Radius Server Portal Server
The user goes online successfully, with a

basic bandwidth of 2 Mbit/s.
COA-Request The COA-Request
BOD active
(policy1, for 5M) packet carries at
least two attributes:
COA ACK standard No. 44
attribute (the user’s
Applies the new accounting ID) and
policy (5 Mbit/s 26-95 attribute
bandwidth) to (policy template
generate a service. policy1).
Accounting Start
Accounting ACK
BOD deactive The DM-Request

DM-Request
packet carries at
(policy1, for 5M)
least two attributes:
DM ACK standard No. 44
Restores to the attribute (the user’s
basic bandwidth accounting ID) and
and deletes the 26-95 attribute
service. (policy template
Accounting Stop policy1).
Accounting ACK
Secondary BOD Service Activation

The BNG supports only new BOD service activation after original BOD service deactivation.
The RADIUS server uses a DM message to deliver the original BOD service policy.
If the RADIUS server has used a CoA message to deliver an HW-Policy-Name (26-95)
attribute, the BNG considers that a new service is activated when the RADIUS server uses a
CoA message to deliver another HW-Policy-Name (26-95) attribute. If the values of the two
attributes are the same, the BNG uses a CoA-NAK message to return a failure reason.

Message Types and RADIUS Attributes

Message RADIUS Attribu Attribute Description
Type Attribute te
Value
CoA- Acct-Session-Id 44 Accounting ID

Request
HW-Policy-Name (26-95) Value-added service (DSG/BOD) policy
name
CoA-ACK User-name 1 User name
Acct-Session-Id 44 Accounting ID
NAS-Identifier 32 NAS name
CoA-NAK Acct-Session-Id 44 Accounting ID
Error-Cause 101 Logout reason
Acct-Req User-name 1 User name

(start)
Service-Type 6 When a common user is authenticated,
this attribute has a fixed value of 2,
indicating the Framed type. When an
administration and maintenance user is
authenticated, this attribute has a fixed
value of 6, indicating the Administrator
type.
Framed-IP- 8 User IP address

Address
Filter-ID 11 User group name
Calling_Station_Id 31 User information
Acct-Session-Id 44 Accounting ID
HW-IP-Host- 26-60 User IP address and MAC address

Address
HW-Domain- 26-138 Domain name used in user authentication.

Name The domain name may be a roaming or
mandatory domain name. The domain
name may not be the domain name in the
user name.
HW-Policy-Name 26-95 Value-added service (DSG/BOD) policy

name
DM-Request Acct-Session-Id 44 Accounting ID
HW-Policy-Name (26-95) Value-added service policy name
DM-ACK Acct-Session-Id 44 Accounting ID


Type Attribute te
Value

Address
NAS-Identifier 32 NAS name
DM-NAK Acct-Session-Id 44 Accounting ID
Error-Cause 101 Logout reason
Acct-Req User-name 1 User name

(stop)
Service-Type 6 When a common user is authenticated,
this attribute has a fixed value of 2,
indicating the Framed type. When an
administration and maintenance user is
authenticated, this attribute has a fixed
value of 6, indicating the Administrator
type.

Address
Filter-ID 11 User group name
Calling_Station_Id 31 User information
Acct-Input-Octets 42 Number of upstream bytes
Acct-Output- 43 Number of downstream bytes

Octets
Acct-Session-Id 44 BOD accounting ID
Acct-Session- 46 User online duration, in seconds

Time
Acct-Input- 47 Number of upstream packets

Packets
Acct-Output- 48 Number of downstream packets

Packets
Terminate-Cause 49 Reason of session interruption
Event-Timestamp 55 Time when an Accounting Request

message was generated
HW-IP-Host- 26-60 User IP address and MAC address

Address


Type Attribute te
Value
HW-Domain- 26-138 Domain name used in user authentication.

Name The domain name may be a roaming or
mandatory domain name. The domain
name may not be the domain name in the
user name.
HW-Policy-Name 26-95 Value-added service (DSG/BOD) policy

name
Table 5-10 Error-Cause (101) Attribute
Error-Cause Description
In the Disconnect-Request, the error code is

201 Residual Session Context
returned when obtaining the user basic information
Removed
according to the user CID fails.
The error code is returned when the attribute parsed

401 Unsupported Attribute
by the RADIUS is not supported.
The error code is returned when the accounting ID

402 Missing Attribute
does not exist.
The error code is returned when the host names do

403 NAS Identification Mismatch not exist or the host names are not matching in the
DM and COA request packet.
The error code is returned when encapsulating the

404 Invalid Request attribute fails or RADIUS module fails to parse the
DM and COA packet
The error code is returned when the COA fails to

405 Unsupported Service
respond.
The error code is returned when the user that is

503 Session Context Not Found searched for according to the session ID does not
exist.
504 Session Context Not The error code is returned when the DM fails to
Removable respond.
5.8.1.3 BOD Service Accounting
Accounting Modes
BOD service accounting is classified as individual or non-individual accounting.

l Non-individual accounting (default accounting mode)

Both common and value-added services are accounted. When BOD services are
generated or deleted, common service accounting remains unchanged.
l Individual accounting
Only value-added services are accounted. After BOD services are generated, common
service accounting stops and BOD service accounting starts. After BOD services are
deleted, common service accounting starts and BOD service accounting stops. To enable
individual accounting, run the value-added-service accounting individual command in
the AAA view.
Accounting Schemes
BOD services support three accounting schemes: non-accounting, RADIUS accounting, and
COPS accounting.
l Non-accounting
This accounting scheme is used for a monthly package.
To configure non-accounting, run the value-added-service account-type none
command in the domain view.
If the accounting scheme configured in a BOD service policy is not RADIUS
accounting, the BOD service is not accounted.
l RADIUS accounting
If a CoA message is used to deliver a BOD service, RADIUS accounting must be
configured.
To configure RADIUS accounting, run the value-added-service account-type radius
If the accounting scheme configured in a BOD service policy is RADIUS accounting,
RADIUS accounting is performed for the BOD service.
l COPS accounting
If a BOD service is delivered using the COPS server, COPS accounting must be
configured.
To configure COPS accounting, run the value-added-service account-type cops
NOTE
Value-added service accounting configurations:

l Configure an accounting type in a domain (value-added-service account-type { cops | default |
none | radius } command). The default accounting type is default.
l Configure an accounting scheme in a domain. The default accounting scheme is RADIUS
accounting.
l Configure an accounting scheme in a value-added service policy. The default accounting scheme is
RADIUS accounting.
Policy for BOD Service Accounting Failures

l If accounting start fails for a user's BOD service, the BOD service is uninstalled and the
original rate is used for the user by default. If the accounting start-fail online command
has been run, the BOD service remains online and the delivered BOD bandwidth is used
for the user after accounting start fails.

l If real-time accounting fails for a user's BOD service, the BOD service remains online
and rate limit and statistics are normal by default. If the accounting interim-fail offline
command has been run, the BOD service is uninstalled and the original rate is used for
the user after real-time accounting fails.
BOD Service Quota Management

Quota management is supported for a BOD service. A carrier can monitor and manage
network resources (traffic volume and duration) used by users, and perform policy and
accounting control based on resource usage.
Service package:
Basic package 1 BOD package 1

基本组网网元 Bandwidth: 8 Mbit/s
Bandwidth: 2 Mbit/s
Accounting mode: Accounting mode:
monthly duration
Price: 80 yuan Price: 3 yuan/hour
+
Basic package 2 BOD package 2
基本组网网元
Bandwidth: 512 kbit/s Bandwidth: 8 Mbit/s
Accounting mode: 40 Accounting mode:
hours/month traffic volume
Price: 50 yuan Price: 3 yuan/100 MB
Bill:
User 1 Basic service Monthly 80 yuan
8 Mbit/s BOD 10 hours 30 yuan
Total 110 yuan
512 kbit/s; 40
User 2 Basic service 50 yuan
hours
8 Mbit/s BOD 500 MB 15 yuan
Total 65 yuan
User 3 Basic service Monthly 80 yuan

8 Mbit/s BOD 500 MB 15 yuan
Total 95 yuan
NOTE
BOD quota information can be delivered only during BOD service policy installation or in accounting
response messages. If both BOD duration and traffic volume quotas are delivered, they take effect
together. An action is triggered if either of the quotas is exhausted.
l Duration quota
If the remaining duration is 0, the system performs an action depending on whether a
real-time accounting response carries a quota.

– If a real-time accounting response carries zero quotas, the system logs out the
service. If a real-time accounting response carries a new quota, the system uses the
new quota for the service.
– If a real-time accounting response does not carry a quota, the system determines
whether to log out the service based on the value-added-service quota-out
{ online | offline } command configuration. By default, the service remains online.
If a user has a BOD service and no individual accounting is used for the service, the
user's duration quota can be deducted together with the service's duration quota.
If individual accounting is used for the service, the user's duration quota remains
unchanged and is deducted after the BOD service is deleted.
The RADIUS attribute involved is as follows:

N Attribute Attri Se Description Remarks

o. bute rv
Type er
T
y
pe
2 Session- Intege Al 1. In an Access- The length is 4 bytes.

7 Timeout r l Accept message, the 1. If the initial value of
attribute indicates the the Session-Timeout
remaining time of a attribute is not 0 and
user, in seconds. If the the quota-out { online
remaining time is 0s, | offline | redirect } }
the system logs out command is run in a
the user by default. domain, the system
2. In a Challenge performs an action
message, the attribute based on a specified
indicates the re- parameter when the
authenticating value of the Session-
duration of an EAP Timeout attribute
user. reduces to 0. If the
3. In an Accounting- online parameter is
Request message, the specified, the system
attribute indicates the keeps the user online.
value carried in an If the offline parameter
Authentication is specified, the system
Response message logs out the user. If the
delivered by a redirect parameter is
RADIUS server. An specified, the system
accounting server redirects the user to a
uses the attribute to portal server.
obtain the original 2. If the value of the
remaining duration Session-Timeout
delivered by a user attribute is 0 in an
authentication server, Access-Accept
which is added in message, the
V600R002C07. authening quota-out-
4. In an authentication redirect-enable
request message for command in the
EDSG service quota authentication template
application, the view can be used to
attribute indicates the redirect the user.
duration quota that 3. If the value of the
has been used by a Session-Timeout
service. attribute is 0 in an
Accounting-Response
message, the quota-out
redirect command can
be run in a domain to
redirect the user.

l Traffic volume quota

If the remaining traffic volume is greater than a traffic volume increment, the system
deducts the traffic volume. If the remaining traffic volume is less than or equal to a
traffic volume increment, the system performs real-time accounting.
– If a real-time accounting response carries zero quotas, the system logs out the
service. If a real-time accounting response carries a new quota, the system uses the
new quota for the service.
– If a real-time accounting response does not carry a quota, the system determines
whether to log out the service based on the value-added-service quota-out
{ online | offline } command configuration. By default, the service remains online.
If a user has a BOD service, the user's common traffic volume quota remains unchanged
regardless of whether individual accounting is used for the BOD service.
The RADIUS attribute involved is as follows:
No. Attribute Attri Server Description Remark
bute Type s
Type
26-1 HW-Remanent-Volume Intege Standar Remaining traffic The

5 r d, volume of a user, in length is
Plus11 KB. If the value of 4 bytes.
the HW-Remanent-
Volume attribute is
0, the user is logged
out immediately. If
the value of the
HW-Remanent-
Volume attribute is
0XFFFFFFFF,
there is no traffic
limit.
In an authentication
request message for
EDSG service
quota application,
the attribute can be
used to report the
traffic volume
quota that has been
used by a service.

5.8.2 BOD Service Deployment

5.8.2.1 Deployment Limitation
Table 5-11
Item Description
User type l Static users

l IPoE users
l PPPoE users
l Web users
l 802.1X users
l L2TP LNS users
l Layer 2 leased line users
l Layer 3 leased line users
l Dual-stack access users
Service generation and deletion BOD services can be dynamically added or

deleted using a policy server, but cannot be
configured in a domain or carried in
authentication response messages when a
user goes online.
Service overlapping Each user can have only one BOD service.
Peripheral systems An AAA/policy server must support BOD

services.
A portal server provides an interface for
users to select services.
5.8.2.2 Deployment Roadmap
Deploying a BOD Service

1. Ensure that authorized users can access the network regardless of which authentication
or accounting mode is used.
2. Plan an authentication mode, an accounting mode, a RADIUS server group, and an
address pool for an AAA domain.
3. Plan a BOD service interface and accounting mode.
4. Deploy a BOD service on the BNG.
Precautions
l A user group can be configured in a BOD service policy, and its priority is higher than
the priority of a user group that is configured in a domain. After a BOD service is
uninstalled, the user group that is configured in a domain is used.
l An accounting scheme can be configured in a BOD service policy, and a real-time
accounting mode can be configured in the accounting scheme. The accounting mode

configured for a value-added service in a domain is preferentially used. Real-time

accounting takes effect only for BOD service accounting messages.
l BOD services can be delivered or deleted using RADIUS, COPS, or Diameter servers.
RADIUS servers can deliver only service policies. COPS servers can deliver only
content. Diameter servers can deliver service policies or content.
5.8.2.3 Data Planning
Operation Parameter Planning Guidance
Authentication Names must be able to clearly reflect

scheme name differences between users. A BOD service
Configure an policy invokes an accounting scheme. To
authentication scheme, Accounting prevent possible errors in manual
an accounting scheme, scheme name configurations, a correct mapping must exist
and a RADIUS server RADIUS server between the names of the BOD service
group. group address policy and accounting scheme.
Address pool Address pool names must be able to clearly

name reflect differences between users.
Configure an address Gateway IP Each address segment range must be able to
pool. address completely cover a target user group.
QoS profile
name A BOD service policy invokes a QoS profile.
Upstream and To prevent possible errors in manual
downstream configurations, a correct mapping must exist
Configure a QoS shaping between the names of the BOD service
profile. parameters policy and QoS profile.
BOD service
policy name
Accounting
scheme
QoS profile
name and
Configure a BOD shaping An accounting scheme must have been
service policy. parameters configured.
Domain name
Accounting
scheme A domain name, a user group name, and a
BOD service user group's priority must be configured as
policy name required.
Address pool An accounting scheme must have been
Configure a domain. name configured.
5.8.2.4 Typical Scenarios and Feature Deployment

5.8.2.4.1 A RADIUS Server Delivers the HW-Policy-Name Attribute over CoA
Networking Requirements
A user's bandwidth is 2 Mbit/s. When visiting a video website, the user wants to change the
bandwidth to 5 Mbit/s. The carrier allows the user to request a bandwidth change through the
web server. The web server sends the bandwidth parameter to the RADIUS server, and the
RADIUS server delivers the service bandwidth to the user over CoA. After the user's
bandwidth parameter takes effect, the accounting server performs accounting based on the
new bandwidth.
In this scenario, the RADIUS server delivers the HW-Policy-Name (26-95) attribute over
CoA.
Figure 5-15 BOD service application
DNS server RADIUS server

WEB server 192.168.8.252 192.168.8.249
CoA
GE1/0/1 192.168.8.1
Access GE1/0/2
Internet
Network
user1 BNG
Item Description
Authentication mode RADIUS authentication
Accounting mode RADIUS accounting
RADIUS authentication server IP address: 192.168.8.249; port number: 1812;
RADIUS accounting server IP address: 192.168.8.249; port number: 1813;
1. Configure AAA authentication.
2. Configure an address pool.
3. Enable the value-added service function.
4. Configure a RADIUS authorization server.
5. Configure a QoS profile.

6. Configure a domain from which the user goes online.

7. Configure a value-added service policy.
8. Configure an interface through which the user goes online.
Step Command Description
1 <HUAWEI> system-view Configure an authentication scheme

[HUAWEI-aaa] aaa
[HUAWEI-aaa] authentication-scheme named auth, and specify RADIUS
auth authentication.
[HUAWEI-aaa-authen-auth]
authentication-mode radius
<HUAWEI> system-view Configure an accounting scheme named

[HUAWEI-aaa] aaa
[HUAWEI-aaa] accounting-scheme acct acct, and specify RADIUS accounting.
[HUAWEI-aaa-accounting-acct]
accounting-mode radius
[HUAWEI] radius-server group group1 Configure a RADIUS server group. The

[HUAWEI-radius-group1] radius-
server authentication IP address and port number of the
192.168.8.249 1812 RADIUS authentication server are
[HUAWEI-radius-group1] radius- 192.168.8.249 and 1812, respectively.
server accounting 192.168.8.249
1813
The IP address and port number of the
[HUAWEI-radius-group1] quit RADIUS accounting server are
192.168.8.249 and 1813, respectively.
[HUAWEI] radius-server Configure a RADIUS authorization
authorization 192.168.8.249 shared-
key huawei server. A RADIUS authorization server
must be configured if RADIUS is used
to modify a service policy.
2 [HUAWEI] ip pool isp_pool bas local Configure an address pool.

[HUAWEI-ip-pool-isp_pool] gateway
100.100.100.1 24
[HUAWEI-ip-pool-isp_pool] section
0 100.100.100.2 100.100.100.200
3 <HUAWEI> system-view Enable the value-added service

[HUAWEI] value-added-service enable
function.
By default, the value-added service
function is disabled.
Before you use value-added services,
you must enable the value-added
service function.
4 [HUAWEI] qos-profile 2m Configure a QoS profile named 2m,

[HUAWEI-qos-profile-2m] car cir
2000 cbs 374000 and set the bandwidth to 2 Mbit/s.
[HUAWEI-qos-profile-2m] quit Configure a QoS profile named 5m,
[HUAWEI] qos-profile 5m and set the bandwidth to 5 Mbit/s.
5000 cbs 935000
[HUAWEI-qos-profile-5m] quit

5 [HUAWEI] value-added-service Configuring a BOD service policy.

policy bod bod
[HUAWEI-vas-policy-BoD] qos-
profile 5m
[HUAWEI-vas-policy-BoD] quit
6 [HUAWEI-aaa] domain isp Configure a domain from which the

[HUAWEI-aaa-domain-isp]
authentication-scheme auth user goes online, and set the bandwidth
[HUAWEI-aaa-domain-isp] accounting- to 2 Mbit/s.
scheme acct
[HUAWEI-aaa-domain-isp] ip-pool
isp_pool
[HUAWEI-aaa-domain-isp] qos-
profile 2m inbound
profile 2m outbound
[HUAWEI-aaa-domain-isp] quit
7 [HUAWEI] interface Virtual- Create a virtual template interface.

Template 1
[HUAWEI] interface GigabitEthernet Configure a BAS interface. PPPoE

1/0/0.1
[HUAWEI-GigabitEthernet1/0/0.1] access is used as an example. You can
pppoe-server bind virtual-template use other access types supported by a
1 BOD service as required.
[HUAWEI-GigabitEthernet1/0/0.1]
user-vlan 1000
[HUAWEI-GigabitEthernet1/0/0.1] bas
[HUAWEI-GigabitEthernet1/0/0.1-
bas] access-type layer2-subscriber
bas] default-domain authentication
isp
bas] authentication-method ppp web


[HUAWEI] display access-user user- Check that the user's bandwidth is 2
id 139626 verbose
----------------------------------- Mbit/s after the user goes online.
---------------
ACL&QoS:
Inbound QOS-profile-name :2m
Outbound QOS-profile-name :
2m
Inbound qos configuration :
User-CAR
Inbound cir :
2000(kbps)
Inbound pir :
2000(kbps)
Inbound cbs :
374000(bytes)
Inbound pbs :
374000(bytes)
Outbound qos configuration :
User-CAR
Outbound cir :
2000(kbps)
Outbound pir :
2000(kbps)
Outbound cbs :
374000(bytes)
Outbound pbs :
374000(bytes)
Link bandwidth auto adapt :
Disable
UpPriority :
Unchangeable
DownPriority :
Unchangeable
8 HW-Policy-Name="bod" A service policy named bod is

delivered using the HW-Policy-Name
(26-95) attribute over CoA, and a BOD
service is generated.

9 [HUAWEI] display access-user user- Check that the user's bandwidth

id 139626 verbose
----------------------------------- changes to 5 Mbit/s.
---------------
ACL&QoS:
Inbound QOS-profile-name :
5m
5m
User-CAR
Inbound cir :
5000(kbps)
Inbound pir :
5000(kbps)
Inbound cbs :
935000(bytes)
Inbound pbs :
935000(bytes)
User-CAR
Outbound cir :
5000(kbps)
Outbound pir :
5000(kbps)
Outbound cbs :
935000(bytes)
Outbound pbs :
935000(bytes)
Disable
UpPriority :
Unchangeable
DownPriority :
Unchangeable


[HUAWEI]display value-added- Check BOD service information.
service user bod
-----------------------------------
-----------------------------------
------
The ID table of used user with
BOD are:
139626
-----------------------------------
-----------------------------------
------
Total users 1
display value-added-service user
user-id 139626 bod
-----------------------------------
-----------------------------------
---
Bod user service table:
Service user
id :
139626
Service
type
: Coa user bod
Service
policy
: bod
Account
method
: Radius
Account start
time :
2000-01-13 08:12:36
Normal-server-
group :
login
Flow up
packets(high,low)
: (0,0)
Flow up
bytes(high,low)
: (0,0)
Flow down
packets(high,low)
: (0,0)
Flow down
bytes(high,low)
: (0,0)
IPV6 Flow up
packets(high,low) :
(0,0)
IPV6 Flow up
bytes(high,low) :
(0,0)
IPV6 Flow down
packets(high,low) :
(0,0)
IPV6 Flow down
bytes(high,low) :
(0,0)
Up committed information rate
<kbps> : 5000


Up Peak information rate
<kbps> : 0
Up committed burst size
<bytes> : 935000
Up Peak burst size
<bytes> : 0
Down committed information rate
<kbps> : 5000
Down Peak information rate
<kbps> : 0
Down committed burst size
<bytes> : 935000
Down Peak burst size
<bytes> :
0
Checking the Configurations

l Run the display value-added-service user command to check information about the
value-added service.
– Run the display value-added-service user bod command to check information
about users with a BOD service configured.
– Run the display value-added-service user user-id user-id command to check
value-added service information of a user with a specified ID.
– Run the display value-added-service user username username [ verbose ]
command to check value-added service information of a user with a specified name.
– Run the display value-added-service user ip-address ip-address [ vpn-instance
vpninstance ] command to check value-added service information of a user with a
specified IP address and VPN instance.
l Run the display value-added-service user-information statistics [ history | verbose ]
command to check statistics about BOD users who fail to apply for upstream or
downstream resources.
l Run the display value-added-service policy [ policy-name ] command to check
information about a value-added service policy.
Configuration Check Examples

# Run the display value-added-service user bod command to view information about users
with a BOD service configured.
<HUAWEI> display value-added-service user bod
------------------------------------------------------------------------
The ID table of used user with service are:
13
------------------------------------------------------------------------
Total users:1

Table 5-12 Description of the display value-added-service user command output

Item Description
The ID table of used user with service are ID of the user with a BOD service
configured
# Display value-added service information of a user with a specified ID. (Services with levels
1 to 8 are DAA services, and services with level 9 are BOD services.)
<HUAWEI> display value-added-service user user-id 5
------------------------------------------------------------------------
User access index : 13
State : Used
User name : 123@lsh
User service number : 1
COPS server name : --
DAA rate limit mode outbound : --
-------------------------------------------------------------------------
The used VAS service id table are:
( 13, 9)
-------------------------------------------------------------------------
-------------------------------------------------------------------------
Table 5-13
Item Description
User access index Index of the access user
State Service status
User name User name
User service number User service number
COPS server name Name of the COPS server
DAA rate limit mode outbound Downstream rate limit for the DAA service
The used VAS service id table are Index of the value-added service entry
# Display BOD service information of a user with a specified ID.

<HUAWEI> display value-added-service user user-id 13 BOD
-------------------------------------------------------------------------
BoD user service table:
Service user id : 13
Service type : Coa user BoD
Service policy : BoD
Account method : Radius
Account start time : 2000-01-21 08:05:53
Normal-server-group : BoD
Flow up packets(high,low) : (0,0)
Flow up bytes(high,low) : (0,0)
Flow down packets(high,low) : (0,0)
Flow down bytes(high,low) : (0,0)
Up committed information rate <kbps> : 2048
Up Peak information rate <kbps> : 0

Up committed burst size <bytes> : 382976

Up Peak burst size <bytes> : 0
Down committed information rate <kbps> : 2048
Down Peak information rate <kbps> : 2048
Down committed burst size <bytes> : 0
Down Peak burst size <bytes> : 0
Table 5-14
Item Description
BoD user service table BOD service table
Service user id ID of the user
Service type Service type
Service policy Service policy name
Account method Accounting method
Account start time Time when accounting started
Normal-server-group Name of the policy server that delivers the

service policy
Flow up packets(high,low) Number of upstream accounting bytes (most

significant bits, least significant bits)
Flow up bytes(high,low) Number of upstream accounting packets

(most significant bits, least significant bits)
Flow down packets(high,low) Number of downstream accounting packets

Flow down bytes(high,low) Number of downstream accounting bytes

Up committed information rate <kbps> Upstream committed information rate

(CIR), in kbit/s
Up Peak information rate <kbps> Upstream peak information rate (PIR), in

kbit/s
Up committed burst size <bytes> Upstream committed burst size (CBS), in

bytes
Up Peak burst size <bytes> Upstream peak burst size (PBS), in bytes
Down committed information rate <kbps> Downstream CIR, in kbit/s
Down Peak information rate <kbps> Downstream PIR, in kbit/s
Down committed burst size <bytes> Downstream CBS, in bytes
Down Peak burst size <bytes> Downstream PBS, in bytes
# Display information about users with service generation.

<HUAWEI> display value-added-service user service

----------------------------------------------------------------------------
The ID table of used user with service are:
13
----------------------------------------------------------------------------
Total users 1
# Display service policy information.

<HUAWEI> display value-added-service policy
----------------------------------------------------------------------------------
-------------------------
Index Service Policy Name Used Num type User Num
----------------------------------------------------------------------------------
------------------------
0 BoD 1 BOD 1
1 daa 0 DAA 0
----------------------------------------------------------------------------------
--------------------------
Total 2,2 printed
# Display statistics about users who fail to apply for QoS resources.
<HUAWEI> display value-added-service user-information statistics verbose
Inbound resource insufficient information:
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Total users 0
Outbound resource insufficient information:
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Total users 0
Both resource insufficient information:
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Total users 0
5.8.2.4.2 A RADIUS Server Delivers CAR Attributes over CoA
new bandwidth.
In this scenario, a RADIUS server delivers the HW-QOS-Profile-Name (26-31) attribute or

attributes 26-1 to 26-6 over CoA.
Attribute No. Attribute Name
26-1 HW-Input-Committed-Burst-Size
26-2 HW-Input-Committed-Information-Rate
26-3 HW-Input-Peak-Information-Rate
26-4 HW-Output-Committed-Burst-Size

Attribute No. Attribute Name
26-5 HW-Output-Committed-Information-Rate
26-6 HW-Output-Peak-Information-Rate

WEB server 192.168.8.252 192.168.8.249
CoA
GE1/0/1 192.168.8.1
Access GE1/0/2
Internet
Network
user1 BNG
Item Description
3. Configure RADIUS authentication and accounting servers.
5. Configure a domain from which the user goes online.
6. Configure a QoS profile.


[HUAWEI-aaa] aaa

[HUAWEI-aaa] aaa

1813

100.100.100.1 24
0 100.100.100.2 100.100.100.200

function.
service function.

5000 cbs 935000

6 [HUAWEI-aaa] domain isp Configure a domain.

[HUAWEI-aaa-domain-isp]
authentication-scheme auth
[HUAWEI-aaa-domain-isp] accounting-
scheme acct
[HUAWEI-aaa-domain-isp] ip-pool
isp_pool
profile 2m inbound
profile 2m outbound
[HUAWEI-aaa-domain-isp] quit

Template 1

1/0/0.1
user-vlan 1000
isp

id 139621 verbose
---------------
ACL&QoS:
2m
User-CAR
Inbound cir :
2000(kbps)
Inbound pir :
2000(kbps)
Inbound cbs :
374000(bytes)
Inbound pbs :
374000(bytes)
User-CAR
Outbound cir :
2000(kbps)
Outbound pir :
2000(kbps)
Outbound cbs :
374000(bytes)
Outbound pbs :
374000(bytes)
Disable
UpPriority :
Unchangeable
DownPriority :
Unchangeable

8 HW-QOS-Profile-Name="5m" The HW-QOS-Profile-Name (26-31)

attribute is delivered over CoA to
change the user bandwidth to 5 Mbit/s.

id 139631 verbose
----------------------------------- changes to 5 Mbit/s.
---------------
ACL&QoS:
5m(Radius)
5m(Radius)
User-CAR
Inbound cir :
5000(kbps)
Inbound pir :
5000(kbps)
Inbound cbs :
935000(bytes)
Inbound pbs :
935000(bytes)
User-CAR
Outbound cir :
5000(kbps)
Outbound pir :
5000(kbps)
Outbound cbs :
935000(bytes)
Outbound pbs :
935000(bytes)
Disable
UpPriority :
Unchangeable
DownPriority :
Unchangeable
5.8.2.4.3 A RADIUS Server Delivers the HW-Domain-Name Attribute over CoA
new bandwidth.
In this scenario, the RADIUS server delivers the HW-Domain-Name (26-138) attribute over
CoA.


WEB server 192.168.8.252 192.168.8.249
CoA
GE1/0/1 192.168.8.1
Access GE1/0/2
Internet
Network
user1 BNG
Item Description
3. Configure RADIUS authentication and accounting servers.
4. Configure a domain from which the user goes online and a domain after bandwidth
adjustment.

[HUAWEI-aaa] aaa


[HUAWEI-aaa] aaa

1813

100.100.100.1 24
0 100.100.100.2 100.100.100.200

function.
service function.

5000 cbs 935000

5 [HUAWEI-aaa] domain isp2m Configure a domain from which the

[HUAWEI-aaa-domain-isp2m]
authentication-scheme auth user goes online, and set the bandwidth
[HUAWEI-aaa-domain-isp2m] to 2 Mbit/s. Configure a domain after
accounting-scheme acct bandwidth adjustment, and set the
[HUAWEI-aaa-domain-isp2m] ip-pool
isp_pool
bandwidth to 5 Mbit/s.
[HUAWEI-aaa-domain-isp2m] qos-
profile 2m inbound
profile 2m outbound
[HUAWEI-aaa-domain-isp2m] quit
[HUAWEI-aaa] domain isp5m
authentication-scheme auth
accounting-scheme acct
[HUAWEI-aaa-domain-isp5m] ip-pool
isp_pool
profile 5m inbound
profile 5m outbound
[HUAWEI-aaa-domain-isp5m] redirect-
domain effect-attribute qos-profile
[HUAWEI-aaa-domain-isp5m] quit

Template 1

1/0/0.1
user-vlan 1000
isp2m


id 139635 verbose
---------------
ACL&QoS:
2m
User-CAR
Inbound cir :
2000(kbps)
Inbound pir :
2000(kbps)
Inbound cbs :
374000(bytes)
Inbound pbs :
374000(bytes)
User-CAR
Outbound cir :
2000(kbps)
Outbound pir :
2000(kbps)
Outbound cbs :
374000(bytes)
Outbound pbs :
374000(bytes)
Disable
UpPriority :
Unchangeable
DownPriority :
Unchangeable
7 HW-Domain-Name="isp5m" The HW-Domain-Name (26-138)

attribute is delivered over CoA to
change the user's domain to isp5m.


id 139635 verbose
----------------------------------- changes to 5 Mbit/s.
---------------
ACL&QoS:
5m
5m
User-CAR
Inbound cir :
5000(kbps)
Inbound pir :
5000(kbps)
Inbound cbs :
935000(bytes)
Inbound pbs :
935000(bytes)
User-CAR
Outbound cir :
5000(kbps)
Outbound pir :
5000(kbps)
Outbound cbs :
935000(bytes)
Outbound pbs :
935000(bytes)
Disable
UpPriority :
Unchangeable
DownPriority :
Unchangeable
5.8.3.1 Troubleshooting for BOD Service Failures
Fault Symptom
A BOD service fails to take effect after a user goes online.
Common Causes
l The value-added service function is disabled.
l No RADIUS authorization server is configured, and a BOD service policy fails to be
delivered over CoA.
l A BOD service policy is incorrectly configured.
l BOD resources are exhausted.

Troubleshooting Flowchart

Figure 5-18 Troubleshooting flowchart for BOD service failures after a user goes online
DAA services fail To take

effect after a DAA user goes
online.
Check whether the VASs

No Configure the VASs. Is fault rectified?
are configured.
Yes No
Check whether the DAA

No Configure the DAA traffic policy. Is fault rectified?
traffic policy is configured.
Yes No
Check whether the

DAA traffic policy is correctly No Modify the DAA traffic policy Is fault rectified?
configured.
Yes No
Check whether the DAA

No Deliver the DAA template. Is fault rectified?
template is delivered.
Yes No
Check whether the

DAA template is correctly No Modify the DAA template. Is fault rectified?
configured.
Yes No
Check whether services

to be dynamically switched are
Re-configure services to be
included in those of the delivered DAA No Is fault rectified?
policy when dynamically switched.
going online.
Yes No
Check whether DAA DAA services will not take effect

Yes
resources are exhausted. when DAA resources are exhausted.
No
Troubleshooting Procedure
1. Check that the value-added service function is enabled.
Run the display current-configuration configuration command to check whether the
value-added service function has been enabled.
– If the value-added service function has not been enabled, run the value-added-
service enable command in the system view to enable the value-added service
function.
– If the value-added service function has been enabled, go to the next step.
2. Check that a BOD service policy is delivered over CoA.
Run the display current-configuration configuration command to check whether a
RADIUS authorization server has been configured.
– If a RADIUS authorization server has not been configured, run the radius-server
authorization command in the system view to configure a RADIUS authorization
server.
– If a RADIUS authorization server has been configured, go to the next step.
3. Check the BOD service policy configuration.
Run the display current-configuration configuration command to check whether a
BOD service policy has been configured and whether the QoS profile for the BOD
service policy is correct.
– If a BOD service policy has not been configured or the QoS profile for the BOD
service policy is incorrect:
i. Run the value-added-service policy service-policy-name bod command in the
system view to create a BOD service policy and enter the BOD service policy
view. If a BOD service policy already exists, running the command directly
displays the BOD service policy view.
ii. Run the qos-profile qos-profile-name command to reference a QoS profile in
the BOD service policy.
– If a BOD service policy has been configured and the QoS profile for the BOD
service policy is correct, go to the next step.
4. Check BOD resources.
Run the display value-added-service user-information statistics command to check
statistics about BOD users who fail to apply for upstream or downstream resources.
resource insufficient information:
----------------------------------------------------------------------------
Resource-insufficient Times
----------------------------------------------------------------------------
Inbound 0
Outbound 1
Both 0
Total 1
----------------------------------------------------------------------------
If neither Inbound nor Outbound is 0, BOD resources have been exhausted.

If both Inbound and Outbound are 0, BOD resources are sufficient. Go to the next step.
5. If the fault persists, contact Huawei technical support personnel.
5.8.4 FAQs

Does a BOD Service Support Duration or Traffic Volume Delivery over CoA?
Yes. The available duration can be delivered using the Session-Timeout attribute, and the
available traffic volume can be delivered using the HW-Remanent-Volume attribute.
Can a BOD Service Be Used on a Wi-Fi Network?

Before you use a BOD service on a Wi-Fi network, the following requirements must be met:
l An AC supports CoA messages.
l The network bandwidth on the AC/AP side meets requirements.
What Are the Differences Between User Bandwidth Change Using a BOD
Service Policy and Direct User Bandwidth Change over CoA?
After BOD service polices are delivered, users' basic service traffic is counted into the
generated BOD service and accounting information after bandwidth change is sent to the
server. When a CoA interface is used to deliver attributes to change user bandwidths, no
service is generated but users' real-time accounting packets are sent after bandwidth change.
What Does the Device Do If the QoS Profile Delivered Using the HW-QOS-
Profile-Name Attribute Does Not Exist on a Device?
By default, the device prohibits users from going online. You can run the radius-attribute
qos-profile no-exist-policy { online | offline } command in the RADIUS server group view
to configure an action that the device takes.

DAA destination address accounting
CoA change-of-authorization
BOD bandwidth on demand
DSG dynamic service gateway
EDSG enhanced dynamic service gateway
RUI Redundancy User Information
5.9 CGN
5.9.1 About This Document

Overview
This document describes commonly used Carrier Grade NAT (CGN) techniques, CGN board
deployment on a live network, and CGN solutions.
Intended Audience
This document is intended for:
l Network planners
l Commissioning engineers
l Data configuration engineers
l System maintenance engineers
Change History
Issue Release Date Change History
1.0 2015-12-16 This is the first official

release.
5.9.2 CGN service board
5.9.2.1 Versatile Service Flexible Card (SP80)
Overview
Figure 5-19 shows the appearance of an SP80.
Figure 5-19 Appearance of an SP80
SP80s are used to expand the forwarding capabilities of VSUF-80s. An SP80 provides a
forwarding capability of 40 Gbit/s. A VSUF-80 supports only one SP80.
Panel
Table 5-15 describes the button and indicators on an SP80 panel.

Table 5-15 Button and indicators on an SP160 panel
Component Description
OFL button This button indicates the removal of a board. Before you remove a
board, press and hold the OFL button for 5 seconds until the OFL
indicator turns on.
OFL indicator If the indicator is steady on, the board can be removed.
(red)
STATUS (green) If the indicator blinks every 2 seconds (0.5 Hz), the board is running
properly. If the indicator blinks twice every second (2 Hz), the board
is in the alarm state.
Technical Specifications
Table 5-16 lists the technical specifications of an SP80.
Table 5-16 Technical specifications of an SP80
Item Specifications
Silkscreen of SP80
the board
name
Typical power 81 W
consumption
Heat 262.80 BTU/hour

dissipation
Weight 1.0 kg
Dimensions 37.2 mm x 178.7 mm x 193.3 mm (1.46 in. x 7.04 in. x 7.61 in.)
(H x W x D)
Earliest V600R006C00
software
version
Product Specifications
Table 5-17 lists the product specifications of an SP80.
Table 5-17 Product specifications of an SP80
Item Specifications
Protocol and service VSUF-80 forwarding capability expansion

Item Specifications
NMS Enhanced command-line interface

Support for SNMP and MIBs
Operating conditions Long-term operating temperature: 0°C to 45°C

Short-term operating temperature: -5°C to +55°C
Long-term relative humidity: 5% to 85%
Short-term relative humidity: 5% to 95%
Storage conditions Storage temperature: -40°C to +70°C

Storage humidity: 5% to 100%
5.9.2.2 Versatile Service Flexible Card(SP160)
Overview
Figure 5-20 shows the appearance of an SP160.
Figure 5-20 Appearance of an SP160
SP160s are used to expand the processing capabilities of VSUF-160s. An SP160 provides a
forwarding capability of 40 Gbit/s. A VSUF-160 supports a maximum of two SP160s.
Panel
Table 5-18 describes the button and indicators on an SP160 panel.
Table 5-18 Button and indicators on an SP160 panel

indicator turns on.
OFL indicator If the indicator is steady on, the board can be removed.
(red)

STATUS (green) If the indicator blinks every 2 seconds (0.5 Hz), the board is running
properly. If the indicator blinks twice every second (2 Hz), the board
is in the alarm state.
Table 5-19 lists the technical specifications of an SP160.
Table 5-19 Technical specifications of an SP160

Item Specifications
Silkscreen of SP-160
the board
name
Typical power 81 W
consumption
Heat 262.80 BTU/hour

dissipation
Weight 1.0 kg
Dimensions 37.2 mm x 178.7 mm x 193.3 mm (1.46 in. x 7.04 in. x 7.61 in.)
(H x W x D)
Earliest V600R006C00
software
version
Table 5-20 lists the product specifications of an SP160.
Table 5-20 Product specifications of an SP160

Item Specifications
Protocol and service VSUF-160 forwarding capability expansion
Reliability and availability Hot swap


Item Specifications


5.9.2.3 Versatile Service Board (VSUI-160-E)
Overview
Figure 5-21 shows the appearance of a VSUI-160-E.
Figure 5-21 Appearance of a VSUI-160-E
A VSUI-160-E provides up to 160 Gbit/s value-added service processing capability.
NOTE
On the NE40E-X8 chassis, you are advised to install VSUI-160-Es in slots 3, 4, 5, and 6. On the
NE40E-X16 chassis, you are advised to install VSUI-160-Es in slots 3 through 5 and 10 through 14.
In 70 A PEM scenarios, the fourth partition of an NE40E-X16 chassis supports five LPU/VSU slots but
can support only a maximum of four VSUF-160s/VSUF-160-Es. That is, an NE40E-X16 chassis
supports a maximum of 15 VSUF-160s/VSUF-160-Es. An NE40E-X8 chassis can be fully configured.
VSUI-160Es are supported only on NE40E-X8s and NE40E-X16s and must work with 200G SFUs.
A VSUI-160-E supports the following functions:

l NAT44
NAT44 allows translation between IPv4 addresses.
l DS-Lite
Dual-Stack Lite (DS-Lite) is an IPv6 transition technology that enables an IPv4 over
IPv6 tunnel to be established between the customer premise equipment (CPE) and
Carrier Grade NAT (CGN) device. The CPE performs NAT to translate the private IPv4
addresses of packets from private network hosts to public IPv4 addresses.

l L2NAT
L2NAT is a special NAT technology. The commonly used NAT maps a private IP
address+port to a public IP address+port. L2NAT maps user position information
+private IP address+port to a public IP address+port. The user position information can
be a PPP session ID, MAC address, and VLAN ID.
A VSUI-160-E uses different licenses for NAT, DS-Lite, and L2NAT.

l NAT Session License
NAT session licenses are classified as 2M or 16M NAT session licenses. To enable a
VSUI-160-E to support 10M NAT sessions, configure five 2M NAT session licenses. To
enable a VSUI-160-E to support 16M or more NAT sessions, use the 16M NAT session
license preferentially.
l DS-lite License
One DS-Lite license must be configured for each VSUI-160-E. A VSUI-160-E can
provide the DS-Lite function only after this license is configured.
l L2NAT License
One L2NAT license must be configured for each VSUI-160-E. A VSUI-160-E can
provide the L2NAT function only after this license is configured.
Panel Description
Table 5-21 lists indicators on a VSUI-160-E.
Table 5-21 Description of indicators on a VSUI-160-E

OFL button The button is used to remove or insert a board. Before removing a
board, you need to press and hold the OFL button for 6 seconds until
the OFL indicator is turned on.
OFL indicator (red) If the OFL indicator is steady red, the board is removable.
RUN (green) If the indicator blinks every 2 seconds (0.5 Hz), the system is
running properly. If the indicator blinks twice every second (2 Hz),
the board is in the alarm state, or the board is starting and has not
completed registration.
Specifications
Table 5-22 lists the technical specifications of a VSUI-160-E.
Table 5-22 Technical specifications of a VSUI-160-E

Parameter Description
Silkscreen VSUI-160-E
Dimensions (H x W 40.1 mm x 399.2 mm x 535.6 mm (1.58 in. x 15.72 in. x 21.09 in.)
x D)

Typical power 474 W

consumption
Heat dissipation 1537.9 BTU/hour
Weight 9.45 kg (20.83lb)
Initial software V600R009C00

version
Table 5-23 lists the specifications of a VSUI-160-E.
Table 5-23 Specifications of a VSUI-160-E

Feature Description
Reliability and availability Software features:

l NAT, including integrated NAT444, integrated NAT44,
distributed NAT444, distributed NAT44, and distributed
L2NAT, which provides the following functions:
– Port pre-allocation
– NAT policy template
– Port forwarding
– Inter-board hot backup for NAT
– Limitation on the number of NAT ports
– NAT alarm notification
– PCP
l DS-Lite
l NAT64
l HA
l Hybrid Access
– Packet ordering for packets transmitted along GRE
tunnels
Hardware features
l Hot swap
l Inter-board hot backup and inter-chassis hot backup
NMS Enhanced command line management interface

Support for SNMP and MIB

Feature Description
Operation environment Long-term operating temperature: 0°C to 45°C (32°F to

113°F)
Short-term operating environment: -5°C to 55°C (23°F to
131°F)
Storage environment Storage temperature: –40°C to 70°C (-40°F to 158°F)

5.9.2.4 Flexible Card Value-Added Service Processing Unit (VSUF-160)
Overview
This section describes the structure and specifications of a VSUF-160, as shown in Figure
5-22.
Figure 5-22 Appearance of a VSUF-160
A VSUF-160 has two subslots and can have two SP160s installed. A VSUF-160 can provide a
forwarding capability of 160 Gbit/s.
NOTE
NE40E-X8, installing the VSUF-160s in slots 3, 4, 5, and 6 is recommended. On the NE40E-X16,

installing the VSUF-160s in slots 3, 4, 5, 10, 11, 12, 13, and 14 is recommended.
In 70 A PEM scenarios, the fourth partition of an NE40E-X16 chassis supports five LPU/VSU slots but
can support only a maximum of four VSUF-160s/VSUF-160-Es. That is, an NE40E-X16 chassis
supports a maximum of 15 VSUF-160s/VSUF-160-Es. An NE40E-X8 chassis can be fully configured.
The VSUF-160 is supported only on the NE40E-X8 and NE40E-X16 and must work with the 200G
SFU.
By default, a VSUF-160 provides a forwarding capability of 40 Gbit/s. To increase the

forwarding capability of a VSUF-160, use the following:
l 20G license
A 20G license expands the forwarding capability of a VSUF-160 by 20 Gbit/s. A
VSUF-160 supports a maximum of two 20G licenses.

l SP160
An SP160 provides a forwarding capability of 40 Gbit/s. A VSUF-160 supports a
maximum of two SP160s.
To enable a VSUF-160 to provide a forwarding capability of 160 Gbit/s, install two 20G
licenses and two SP160s on the VSUF-160.
A VSUF-160 provides the following functions:
l NAT44
Network address translation (NAT) is an important technology used in the transition
from IPv4 to IPv6 networks. NAT44 allows an IPv4 address to be translated into another
IPv4 address. NAT444 is NAT44 performed twice, once on a customer premises
equipment (CPE) device and the second time on a carrier-grade NAT (CGN) device.
Because of its efficiency, NAT444, also called large scale NAT (LSN), is utilized in
situations where NAT is used on carrier networks on a large scale.
l DS-Lite
Dual-Stack Lite (DS-Lite) is an IPv6 transition technology. DS-Lite enables an IPv4 in
an IPv6 tunnel to be established between the CPE and CGN devices. Also, a private IP
address can be encapsulated for NAT on the CGN. And, a private IP address can be
translated to a public network IPv4 address.
l L2-Aware NAT
L2-Aware NAT is a special NAT technology that translates private network IP addresses
and port IDs into public network IP addresses and port IDs. In L2-Aware NAT, user
location information (PPP session ID, MAC address, and user VLAN ID), private
network IP addresses, and port IDs are translated into public network IP addresses and
port IDs.
If you want an NE40E&NE80E to provide the NAT44, DS-Lite or L2NAT function, install a
VSUF-160 on the NE40E&NE80E and configure the following licenses.
l NAT session license
NAT session licenses are classified as 2M NAT session licenses and 16M NAT session
licenses. If you want a VSUF-160 to support 10M NAT sessions, configure five 2M NAT
session licenses. If you want a VSUF-160 to support more than 16M NAT sessions, use
the 16M NAT session license in preference.
l DS-Lite license
One VSUF-160 requires one DS-Lite license. A VSUF-160 can provide the DS-Lite
function only after this license is configured.
l L2-Aware NAT license
One VSUF-160 requires one L2-Aware NAT license. A VSUF-160 can provide the L2-
Aware NAT function only after this license is configured.
Panel
Table 5-24 describes the button and indicators on a VSUF-160 panel.

Table 5-24 Button and indicators on a VSUF-160 panel

indicator turns on.
OFL indicator (red) If the indicator is steady on, the board can be removed.
RUN (green) If the indicator blinks every 2 seconds (0.5 Hz), the board is running
properly. If the indicator blinks twice every 1s (2 Hz), the board is in
the alarm state or the board is starting and has not completed
registration.
Table 5-25 lists the technical specifications of a VSUF-160.
Table 5-25 Technical specifications of a VSUF-160

Item Specifications
Silkscreen of the VSUF-160

board name
x D)
Typical power 312 W

consumption
Weight 7.2 kg
Earliest software V600R006C00

version
Table 5-26 lists the product specifications of a VSUF-160.

Table 5-26 Product specifications of a VSUF-160

Item Specifications

L2-Aware NAT, which provides the following functions:
– Port forwarding
– PCP
l DS-Lite
l NAT64
l High availability
l Hybrid Access
– Packet ordering for packets transmitted along the GRE
tunnels
– Load balancing among the VSUF-160 boards and
SP160 packet ordering engines
Hardware features:
l Board hot swap
l FPIC hot swap



Overview
5-23.

NOTE
On the NE40E-8 and NE40E-X8, installing the VSUF-80s in slots 3, 4, 5, and 6 is recommended. On the
NE40E-X16, installing the VSUF-80s in slots 3, 4, 5, 10, 11, 12, 13, and 14 is recommended. On the
NE40E-16, installing the VSUF-80s in the lower slots in the middle is recommended.
The VSUF-80 is supported only on the NE40E-8NE40E and cannot be equipped with any subcard.
A VSUF-80 has one subslot and can have one SP80 installed. A VSUF-80 can provide a
forwarding capability of 80 Gbit/s.
By default, a VSUF-80 provides a forwarding capability of 20 Gbit/s. You can increase the
forwarding capability of a VSUF-80 using the following:
l 20G license
A 20G license expands the forwarding capability of a VSUF-80 by 20 Gbit/s. A
VSUF-80 can be configured with only one 20G license.
l SP80
An SP80 provides a forwarding capability of 40 Gbit/s. A VSUF-80 can have only one
SP80 installed.
To enable a VSUF-80 to provide a forwarding capability of 80 Gbit/s, install one 20G license
and one SP80 on the VSUF-80.
l NAT44
Network address translation (NAT) is an important technology used in the transition
from IPv4 to IPv6 networks. NAT44 allows an IPv4 address to be translated into another
IPv4 address. NAT444 is NAT44 performed twice, once on a customer premises
equipment (CPE) device and the second time on a carrier-grade NAT (CGN) device.
Because of its efficiency, NAT444, also called large scale NAT (LSN), is utilized in
situations where NAT is used on carrier networks on a large scale.
l DS-Lite
Dual-Stack Lite (DS-Lite) is an IPv6 transition technology. DS-Lite enables an IPv4 in
an IPv6 tunnel to be established between the CPE and CGN devices. Also, a private IP
address can be encapsulated for NAT on the CGN. And, a private IP address can be
translated to a public network IPv4 address.
l L2-Aware NAT
L2-Aware NAT is a special NAT technology that translates private network IP addresses
and port IDs into public network IP addresses and port IDs. In L2-Aware NAT, user
location information (PPP session ID, MAC address, and user VLAN ID), private
network IP addresses, and port IDs are translated into public network IP addresses and
port IDs.
If you want an NE40E&NE80E to provide the NAT44, DS-Lite or L2NAT function, install a
VSUF-80 on the NE40E&NE80E and configure the following licenses.
l NAT session license

NAT session licenses are classified as 2M NAT session licenses and 16M NAT session
licenses. If you want a VSUF-80 to support 10M NAT sessions, configure five 2M NAT
session licenses. If you want a VSUF-80 to support more than 16M NAT sessions, use
the 16M NAT session license in preference.
l DS-Lite license

One VSUF-80 requires one DS-Lite license. A VSUF-80 can provide the DS-Lite
function only after this license is configured.
l L2-Aware NAT license
One VSUF-80 requires one L2-Aware NAT license. A VSUF-80 can provide the L2-
Aware NAT function only after this license is configured.
Panel

indicator turns on.
registration.

Item Specifications

board name
x D)

Item Specifications
Typical power 182 W

consumption
Weight 7.15 kg

version

Item Specifications

– Port forwarding
– PCP
l DS-Lite
l NAT64
Hardware features:
l Board hot swap
l FPIC hot swap



Item Specifications

Overview
5-24.
By default, a VSUF-40 provides a forwarding capability of 20 Gbit/s.
l L2-Aware NAT
If you want an NE40E&NE80E to provide the L2-Aware NAT function, install a
VSUF-40 on the NE40E&NE80E and configure the following licenses:
– L2-Aware NAT license
One VSUF-40 requires one L2-Aware NAT license. A VSUF-40 can provide the
L2-Aware NAT function only after this license is configured.
– NAT session license
NAT session licenses are classified as:
n 2M NAT session licenses
n 16M NAT session licenses
If you want a VSUF-40 to support 10M NAT sessions, configure five 2M NAT
session licenses. If you want a VSUF-40 to support more than 16M NAT sessions,
use the 16M NAT session license in preference.
Panel


indicator turns on.
registration.

Item Specifications

board name
x D)
Typical power 182 W

consumption
Weight 7.15 kg

version


Item Specifications

– Port forwarding
l DS-Lite
Hardware features:
l Board hot swap



5.9.3 CGN Overview
5.9.3.1 What Is CGN?
Background
The Internet Assigned Numbers Authority (IANA) allocated the last two /8s of IPv4 address
space in February 2011. With this action, the free pool of available IPv4 addresses is now
fully depleted. The existing solutions, such as IPv4 readdressing and address reusing, cannot
fundamentally resolve the IPv4 address exhaustion problem. Telecom carriers' existing
address space can only support service development in a short term. The industry is in
desperate need of a solution for long-term service development.
The introduction of IPv6 is considered the most fundamental solution to IPv4 address
exhaustion. However, the slow-paced IPv6 implementation has not yet brought new business

opportunities in essence. It only addresses the existing address issues. In addition, the current
substitute solutions can basically meet carriers' deployment requirements, which in turn slows
down their plan in IPv6 transition.
Figure 5-25 IPv6 transition
DS-Lite
IPv6 promote IPv6
intro transition
6RD rapid DS-Lite
duct
ion instroduction to IPv6
IPv6
3 6RD
2
DS-Lite+NAT444
Smooth transition to
IPv6
1
IPv4
NAT alleviates IPv4 address depletion
Concepts
Carrier-grade NAT (CGN) is a large-scale NAT (for details, see Figure 5-26.) that delivers
statistical reuse of public IPv4 addresses through large-scale private IPv4 address deployment.
The use of CGN can improve the usage of IPv4 addresses, which solves IPv4 address
exhaustion to a great extent and leaves more time for IPv6 transition. Mainstream IPv6
evolution solutions, such as dual-stack + NAT444 and DS-Lite solutions, have all introduced
CGN. With this trend, Huawei concludes a series of IPv6 evolution solutions as the CGN
solution.

Figure 5-26 Comparison between NAT and CGN
Conventional
CGN
NAT device
·ÿ Small capacity
·ÿ Large capacity
·ÿ Low performance
·ÿ High performance
·ÿ Low reliability
·ÿ High reliability
·ÿ Blackbox
·ÿ NAT record
·ÿ No user
·ÿ User management
management
5.9.3.2 CGN Transition Techniques
Basically, three CGN transition techniques are widely used: dual stack, tunneling, or
translation. Of the three transition techniques, dual stack is the simplest and most desirable,
and the other two are used only in specific scenarios.
Dual Stack
As defined in RFC 4213, dual stack refers to the technique for providing message
interworking between terminal devices/network nodes and IPv4/IPv6 nodes by installing both
IPv4 and IPv6 protocol stacks on terminal devices and network nodes.
Routers supporting IPv4/IPv6 dual-stack enable the network to act as two parallel logical
networks and enable a smooth transition to IPv6. As shown in Figure 5-27, the router that
supports IPv4/IPv6 dual-stack firstly sends an Authentication, Authorization, Audit, Account
(AAAA) request to the DNS server and turns to send an Authentication, Authorization, Audit,
or Account request to the DNS server only when the AAAA request is not replied.

Figure 5-27 IPv4/IPv6 dual-stack

DNS Server
IPv4 Hosts
Dual Stack Router
IPv4 &IPv6 Network
IPv6 Hosts
[R1] ipv6
[R1] interface GigabitEthernet0/0/0
[R1-GigabitEthernet0/0/0] ip address 10.1.1.1 24
[R1-GigabitEthernet0/0/0] ipv6 enable
[R1-GigabitEthernet0/0/0] ipv6 address 2001:0001::FFFF 64
With good interoperability, the dual stack mechanism is the most direct mode to make IPv6
nodes compatible with IPv4 nodes. Moreover, it is easy to understand. The use of dual stack,
however, increases the occupancy of system resources and decreases the performance of
devices, but cannot solve the problem of address shortage. In addition, this mechanism is
bound to increase the network complexity and costs since it needs double resources. Dual
stack is generally working at two layers: network layer and terminal layer.
Tunneling
Tunneling is used to interconnect isolated IPv6 networks over an IPv4 network or isolated
IPv4 islands over an IPv6 network. As shown in Figure 5-28, the tunneling technique
requires only border nodes to implement dual stack and enables data of an address family to
traverse the network of another address family through a tunnel.
Figure 5-28 Tunneling
10.1.1.1 10.2.2.2
IPv4 Network
Tunnel
R1 R2
IPv6 Network IPv6 Network
At the very beginning of IPv6 development, the tunneling technique worked well in
connecting isolated IPv6 networks and incrementally deploying IPv6 without network-wide
upgrade, which gradually expanded the IPv6 implementation scope. Therefore, tunneling is a
most attractive technology for IPv6 transition at an early stage. As the IPv6 transition
develops, even isolated IPv4 networks can be connected through tunnels.
However, the disadvantages of the tunneling technique are that double IP headers increase
network costs, tunnel endpoints require additional work on scalability and reliability, and
some MTU issues may occur.

Table 5-33 lists the commonly used tunneling techniques and their usage scenarios.
Table 5-33 Comparison of common tunneling techniques

Tunnel Type Technical Feature Usage Scenario
Manual tunneling IP-in-IP or GRE is used for Tunnels of this type are
packet encapsulation. configured manually. They
are easy to implement and
widely supported by
network devices. However,
they are not suitable for
large-scale deployment.
Automatic tunneling The IPv6-in-IP mode is Automatic tunnels are used

used. Stateless automatic as IPv6-in-IPv4 tunnels
tunnel encapsulation is only. They are implemented
implemented through IPv6 through embedded IPv4
addresses with embedded addresses. Relying on the
IPv4 addresses. 6to4 IPv4 topology, automatic
addresses use the well- tunnels are applicable to the
known prefix, 2002:IPv4- early stage of IPv6
globe-Addr:Suffix. transition. Supported by
The feature of an Intra-Site common operating systems,
Automatic Tunnel they are suitable for hosts.
Addressing Protocol 6to4 needs public IPv4
(ISATAP) address is Prefix: addresses for
0:5EFE:IPv4-Addr. interconnection between
IPv6 islands. 6to4 relay
routers are used for
communication with native
IPv6 hosts.
The ISATAP does not have
any restriction on IPv4
addresses. It is more
applicable to enterprise
networks.
MPLS tunnel 6PE/6VPE, IPv6-in-MPLS MPLS tunnels have good

forwarding performance.
They are applicable to the
network cores. MPLS
infrastructures are required.
In addition, 6rd continues to use the 6to4 stateless tunneling mode. 6rd uses provider prefixes
instead of the well-known prefix 2002/16 used in 6to4. Thus, IPv6 prefixes can be released on
the native IPv6 network, which in turn solves the problem of routing through which the native
IP network accesses 6to4 islands.
Translation
Translation is used for interworking between IPv6-only networks and IPv4-only networks.
Translation devices are located on the border of two networks. They need to forcibly

exchange the corresponding fields of the IP header and translate the IP address carried in the
packet body.
Table 5-34 lists the technical feature and usage scenarios of common translation techniques.
Table 5-34 Comparison of common translation techniques

Layer Technique Technical Highlights Usage Scenarios
Networ SIIT (Stateless IP/ICMP SIIT defines the address SIIT is stateless
k layer Translation) translation implemented translation. It faces the
through the following problem of IPv4 address
specific address formats: shortage and therefore is
IPv4 mapping address applicable only to the
0::ffff:a.b.c.d and IPv4 communication from an
translation address IPv6 network to the IPv4
0::ffff:0:a.b.c.d. Internet.
NAT-PT (Network NAT-PT is a type of NAT-PT is stateful

Address Translation- NAT that maps between translation. It is built in a
protocol Translator) IPv4 addresses/ports and router or firewall. It has
IPv6 addresses. higher efficiency than
the techniques used at
the application layer.
BIS (Bump In the Stack) BIS is a kind of NAT-PT BIS is applicable to

implemented in hosts. single-stack hosts.
Transpo TRT (Transport Relay TRT refers to translation TRT is applicable to

rt layer Translator) at the transport layer. routers.
Applica SOCKS64 The SOCKS protocol The host software must

tion allows a SOCKS proxy be upgraded and a
Layer server to implement special SOCKS server
address translation. must be deployed.
SOCKS is applicable to
specific application
scenarios.
BIA (Burned-in MAC BIA is a type of BIA is a host translation

Address) SOCKS64 implemented technique, applicable to
in hosts. the traditional
application programs of
dual-stack hosts.
ALG (Application Level ALG indicates address ALG is used with NAT
Gateway) translation at the to translate messages.
application layer.
Owing to the problems existing in these translation techniques, only NAT-PT is deployed on
products currently. Translation techniques above the network layer have low performance due
to several layers to be processed. The network layer translation faces the problem about the
ALG. The packet bodies of certain protocols contain IP addresses. To implement the ALG,
translation devices must identify the specific application layer protocol.

The IETF has noticed the issues about translation techniques, and described the issues in RFC
4966, including application layer gateway for domain name server (DNS-ALG) issues, NAT
issues, ALG issues, and scalability concerns. On that basis, the Behavior Engineering for
Hindrance Avoidance (BEHAVE) working group of the IETF has re-thought translation
techniques and made the following improvements:
l Stateful translation uses NAT64+DNS64 to simplify and supplant NAT-PT. NAT64
allows only the IPv6 side to initiate connections. Furthermore, NAT-ALG functions are
implemented by a separate DNS64.
l Stateless translation incorporates the notions of SIIT and IVI and uses provider prefixes.
IPv6 addresses are embedded with IPv4 addresses and can be self-mapped and therefore
are easy to manage.
l The mapping between IPv4 and IPv6 header translation and the address translation
formats are re-defined.
l The NAT behavior mode that is helpful for service interworking during IPv4/IPv6
translation is specified.
5.9.3.3 CGN Principles
NAPT
CGN can be implemented in two ways:
l NAPT: Network address port translation (NAPT) translates both source IP addresses and
port numbers between public and private networks. For packets with the same private
source IP address and different source port number, NAPT translates the private source
IP address in each packet into the same public source IP address and each private source
port number into a specific public source port number.
l No-PAT: No-PAT is also called basic NAT, which translates each private source IP
address into a public source IP address, but does not translate source port numbers.
NOTE
CGN works in two modes:

l NAT in 3-tuple mode
When working in 3-tuple mode, a CGN device assigns public IP addresses and filters packets
based on the source/destination IP addresses, source/destination port numbers, and protocol
numbers. NAT in 3-tuple mode is also called NAT in full-cone mode. This mode well supports
interaction between hosts on different CGN devices. Therefore, NAT in 3-tuple mode is commonly
adopted by carriers.
When working in 5-tuple mode, a CGN device assigns public IP addresses and filters packets
based on the combinations of source and destination IP addresses, source and destination port
numbers, and protocol types. NAT in 5-tuple mode is also called NAT in symmetric mode. This
mode elevates the security level. However, it is difficult for the hosts attached to different CGN
devices to communicate with each other.
In NAPT mode, a CGN device translates not only IP addresses but also port numbers in
packets. NAPT extends NAT from "one to one" to "many to one", which saves resources and
therefore is widely used.

Figure 5-29 Basic principles of NAPT

Address group
162.105.178.65
162.105.178.66
162.105.178.67
162.105.178.68
…….
162.105.178.65:16384->
10.1.1.200:1025-
211.100.7.34:80
>211.100.7.34:80
211.100.7.34:80-
211.100.7.34:80- >162.105.178.65:16384
PC >10.1.1.200:1025
10.1.1.200
162.105.178.65:16400->
10.1.1.110:1028- 211.100.7.34:80
Server
>211.100.7.34:80 CGN
211.100.7.34
211.100.7.34:80-
211.100.7.34:80- >162.105.178.65:16400
PC >10.1.1.110:1028
10.1.1.200
NAT Table before NAT after NAT

outbound 10.1.1.200:1025 162.105.178.65:16384
inbound 162.105.178.65:16384 10.1.1.200:1025
outbound 10.1.1.110:1028 162.105.178.65:16400
inbound 162.105.178.65:16400 10.1.1.110:1028
NAPT processes packets as follows:

1. A CGN device receives a public network access request from a PC.
2. If this is a connection requested by the PC, the CGN device selects an idle public
network address and port number from the address pool to set up NAT entries.
3. The CGN device searches for NAPT entries based on the source and destination IP
addresses and source and destination port numbers of the private network, implements
NAT based on the obtained NAPT entries, and sends the request packet to the server.
4. Upon receipt of a response packet from the server, the CGN device searches for reverse
NAPT entries based on the destination IP address, implements NAT, and then sends the
response packet to the PC.
5.9.3.4 Key CGN Techniques
5.9.3.4.1 CGN Port Allocation Mode
Port Pre-Allocation
Port pre-allocation, also called the port range mode, enables a CGN device to pre-allocate a
public IP address and port segment to a private IP address for the CGN device to map the
private IP address to the public IP address and a port in the port segment. If the number of
ports allocated to a user exceeds the pre-allocated port range, no more ports will be allocated
to the user.

Semi-Dynamic Port Allocation

The semi-dynamic port allocation mode extends the port range mode by providing three
parameters: initial port range, extended port range, and maximum number of times a port
range can be extended. Before users go online, a CGN device assigns an initial port segment
and ports in the initial segment to users. If the number of used ports exceeds the initial port
segment size, the CGN device assigns an extended port segment, which can repeat for a
specified maximum number of times.
Dynamic Port Allocation

Dynamic port allocation, also called the Port Dynamic mode, enables a CGN device to pre-
allocate a public IP address and 64-bit port segment to a private IP address. If the number of
ports used by a user exceeds the initial port segment, the CGN device allocates another 64-bit
port segment to the user. In this mode, the maximum number of times a port range can be
extended is not limited.
5.9.3.4.2 NAT ALG
NAT application level gateway (ALG) provides transparent translation for some application
layer protocols.
Packets of many application layer protocols contain user information, including IP addresses
and port numbers. These protocol packets may fail to be forwarded because NAT cannot
identify the IP addresses and port numbers carried in these protocol packets. To address this
problem, the NAT ALG technique is introduced. NAT ALG implements IP address and port
number translation not only for IP packet headers but also application layer protocols.
Table 5-35 Protocols supported by NAT ALG

Scenario NAT ALG DS-Lite ALG NAT64 ALG
Protocols l FTP l FTP l FTP

supported by NAT l ICMP l ICMP l ICMP
ALG
l RTSP l RTSP l HTTP (Only
l SIP l SIP HTTP ALG for
ports 301 and
l PPTP l PPTP 302 is
l STUN supported.)
l DNS
5.9.3.4.3 CGN Security
Sessions' address resources and CPU resources are critical to a CGN device when NAT is
performed. Therefore, they should be protected against attacks.
Port Number Limiting

To prevent individual users from occupying excessive port resources and causing connection
failures for other users, the NAT port number limiting function can be enabled to save port

resources in IP address pools. Devices can check whether the number of TCP, UDP, ICMP, or
all protocol ports monopolized by a user exceeds the threshold; if so, additional connection
requests can be denied.
On the other hand, when the number of TCP, UDP, ICMP, or all protocol ports utilized by a
user is lower than the configured threshold, additional ports can be accessed.
To prevent individual users from occupying excessive session table resources to cause the
connection failure of other users, the NAT session number limit function can be enabled to
protect address pool resources. Therefore, the number of public network ports needs to be
collected. You must check whether the number of TCP/UDP/ICMP ports for a user exceeds
the threshold. If so, confirm whether a new session is prohibited from being initiated over the
involved protocol.
If the number of TCP/UDP/ICMP ports falls below the threshold, the user can re-initiate
connections over the corresponding protocol.
Session limit
Because NAT444 is a stateful address translation technology, session tables are key resources
of a CGN device. If a user launches a DoS attack, such as an SYN Flood attack, flow table
resources of the CGN device may be exhausted. Users are therefore prevented from creating
flow tables and consequently fail to get online. To help prevent this situation, the number of
TCP, UDP, or ICMP sessions established at each IP address needs to be monitored. When the
number of TCP, UDP, or ICMP sessions from a source IP address or to a destination address
reaches the preset threshold, the system suppresses new connections from either address.
When the number of TCP, UDP, or ICMP sessions from a source IP address or to a destination
address falls below the preset threshold, the system allows new connections from the source
address or to the destination address.
NAT is a stateful address translation technology, with session tables as the core CGN
resources. If a user initiates Denial of Service (DoS) attacks, CGN session resources may be
exhausted, causing other users to fail to establish sessions and access the external network.
Therefore, the number of sessions established for a user must be collected. You must check
whether the number of forward and reverse TCP/UDP/ICMP sessions established for a user
exceeds the threshold. If so, confirm whether the user should be limited from initiating new
connections.
If the number of TCP/UDP/ICMP sessions falls down the threshold, the user can re-initiate or
receive the corresponding session connections.
Session Table Aging

The aging time for application-specific NAT session entries in a NAT table can be set on a
NAT device. After the aging time elapses, the NAT device automatically ages the entries and
releases session resources. The NAT device can be configured to forcibly age all session
tables or a specific type of session tables.
User-specific Flow Construction Speed Limiting

A NAT device uses a multi-core structure and allows the flow construction and forwarding
processes to share CPU resources. The NAT device dynamically learns the sizes of flows and
limits the speed and resources used to construct flows.
If the number of user sessions reaches a specified upper limit, construction flows deteriorates
the performance of other services. To minimize the impact, the speed at which the NAT

device constructs flows can be set. Alternatively, the committed access rate (CAR) function
can be configured to limit the speeds at which the NAT device constructs flows for all users to
help properly transmit user services.
5.9.3.4.4 CGN Address Tracing
CGN address tracing is designed to trace the private network users based on the translated
public IP addresses and port numbers. NAT tracing may function in either the RADIUS
tracing or log tracing mode.
Currently, user logs and flow logs take part in CGN address sourcing. The following table
lists log details.
Lo Log Content Log Type Format and Application Scenario

g Sendin
Cl g Time
ass
Us User logs record A user User Both centralized and distributed CGN
er information such log is syslog devices support user syslog logs. User
log as the private IP sent syslog information in text format is sent to
address, public every a log server.
IP address, then a NOTE
public port port is Syslogs are in Huawei format by default and
segment, and the allocated can be configured with the China Telecom
allocation time or format (cn) and China Unicom format (type 2).
and reclaiming released.
RADIU A Remote Authentication Dial In User
time for the
S log Service (RADIUS) logging-enabled NAT
public port
device sends to a RADIUS server
segment.
RADIUS accounting packets carrying
NOTE mappings between private IP addresses
User logs are
supported only in
and the set of public IP addresses and port
port pre- ranges. RADIUS log information helps a
allocation and RADIUS server trace user information.
semi-dynamic
port allocation User Both centralized and distributed CGN
modes. NetStre devices support user NetStream logs. User
am NetStream log information in binary
format is sent to a log server.
Flo Flow logs record A flow Flow Both centralized and distributed CGN
w information such log is syslog devices support flow syslog session logs.
log as the private IP generate Flow syslog information in text format is
address of a d every sent to a log server.
session, public IP time a NOTE
address, public session Syslogs can be configured with the China
port number, and is Telecom format (cn) and China Unicom
destination IP generate format (type 2).
address. d or ages
out.

Lo Log Content Log Type Format and Application Scenario

g Sendin
Cl g Time
ass
Flow e- Both centralized and distributed CGN

log devices support user flow e-logs. Flow e-
log information in binary format is sent to
a log server.
NOTE
E-logs are sent in the v1 format by default and
can be configured to be sent in v2 format.
Flow Both centralized and distributed CGN

NetStre devices support flow NetStream logs.
am Flow NetStream log information in binary
format is sent to a log server.
NOTE
For details about CGN log formats, see Appendix CGN Log Format Description.
5.9.3.4.5 CGN Reliability
?.1. Intra-chassis Backup
When a CGN device has multiple service boards, active and standby service boards can be
configured on the CGN device for backup. The standby service board synchronizes data from
the active service board so that it can take over services immediately when the active service
board fails. Services are not interrupted during the switchover, and users do not know the
fault.
The NE40E&NE80E supports the following CGN board backup modes:
Table 5-36 Intra-chassis Backup

Supported Supported Supported Switchover process
Backup Scenarios Backup Tables
Modes
Inter-board Centralized NAT mapping If the master service board fails, user
code backup CGN entries are not traffic is temporarily switched over
scenario backed up between to the slave service board, NAT
the master and slave session entries are re-established, and
service boards. then NAT services are restored.

Supported Supported Supported Switchover process

Backup Scenarios Backup Tables
Modes
Inter-board Distributed Only the user table During an active/standby switchover,

warm CGN is backed up. the NAT relationship between public
backup scenario and private addresses does not
change and sessions do not need to
be re-established.
Inter-board Distributed Both user and During an active/standby switchover,

hot backup CGN and session tables are the NAT relationship between public
centralized backed up. and private addresses does not
CGN change but sessions need to be re-
scenario established.
The board master/slave relationships can be statically configured for inter-board backup.
After a NAT session table is established on the master service board, service traffic is
transmitted only from the master service board. In the event of a fault on the master VSUF/
multi-core CPU/SP subcard, a fault can be detected on the chassis, and the LPU switches
traffic to the slave service board.
In hot backup mode, the slave service board automatically synchronizes NAT session tables
with the master service board. The traffic switching process does not require re-establishment
of NAT sessions. Therefore, traffic switching takes a short period of time, usually less than
100 ms. Figure 5-30 displays the path of internal processing: multi-core CPU (master) <->
TM (master) <-> SFU <-> TM (slave) <-> multi-core CPU (slave).
Figure 5-30 Inter-board backup in hot backup
Single-chassis
同一机框 Primary service
主业务板
board
SFU Multi-
多核CPU
core cpu
TM
同
Synchr
步 Slave service
onize
NAT board
备业务板
NAT
会
tables
话 Multi-
多核CPU
core cpu
TM
In cold/warm backup mode, the slave service board does not synchronize NAT session tables
with the master service board. When traffic is switched to the slave service board, NAT

session tables need to be re-established. The time spent in re-establishment depends on the
number of NAT session tables. Figure 5-31 displays the path of internal processing: multi-
core CPU (master) <-> TM (master).
Figure 5-31 Inter-board backup in cold/warm backup mode
Single-chassis
同一机框 Primary service
主业务板
board
SFU
Multi-
多核CPU
core cpu
TM
TM
同
步 Slave service
NAT board
备业务板
会
话 Multi-
多核CPU
core cpu
TM
?.2. Inter-chassis Redundancy
When two CGN devices are deployed, the master and slave service boards can be configured
for the CGN devices to achieve inter-chassis redundancy. Such a mechanism ensures data
consistency between different boards on the two CGN devices. Any fault on the master
service board will automatically trigger a master/slave switchover, ensuring service continuity
and freeing users from becoming aware of faults.
Inter-chassis redundancy uses VRRP to determine the master/slave relationship. As shown in
Figure 5-32, CPU 1 in slot 1 on CGN1 belongs to HA backup 1 on CGN1, and CPU0 in slot
2 on CGN 2 belongs to HA backup group 1 on CGN2. The service information about CPU0
in slot 1 on CGN1 is synchronized to CPU0 in slot 2 on CGN2.
Figure 5-32 Inter-chassis redundancy

CGN1 CGN2
Master Backup
Slot 1 Slot 2
CPU1 CPU2 CPU1 CPU2
CPU0 CPU3 CPU0 CPU3
HA backup group/VRRP backup group

NOTE
This function is developed based on Huawei HRP protocol.

Virtual Router Redundancy Protocol (VRRP) is a fault tolerant protocol that groups several chassis into
a virtual router. If the next hop router of a host fails, VRRP switches traffic to another chassis, ensuring
continuous and reliable communication. In the group of chassis, usually there are two chassis, one
master and the other slave. And the determination of the master and slave is based on the priority
configured for each chassis. The VRRP can detect the failure of VSUF board and chassis and switch the
slave to master.
Bidirectional forwarding detection (BFD) is a well-adopted technique used to detect link faults on both
the public and private network sides. Currently, the NE40E&NE80E supports a minimum detection
delay of 10 ms and a minimum convergence time of 250 ms. VRRP associates with BFD in link or peer
mode. When BFD detects a link fault, the VRRP is changed accordingly, resulting in a master/slave
VRRP switchover. BFD is not a must for the inter-chassis redundancy mechanism as VRRP can be used
to detect link failure as well. In comparison, BFD detects failures faster than VRRP.
Currently, NE40E&NE80Es support a minimum convergence time of 250 ms for switching, which
requires entry consistency between the master and slave boards.
Three modes are supported:
Table 5-37 Inter-chassis redundancy

Backup Supported Support for Table Processing Troubleshooting
Mode Scenarios Backup
Inter-chassis Centralized The user table and During a master/slave switchover,

cold backup CGN session table are not the NAT relationship between public
scenario backed up. and private addresses does change
and sessions need to be
reestablished.
Inter-chassis Distributed Only the user table During a master/slave switchover,

warm CGN is backed up. the NAT relationship between public
backup scenario and private addresses does not
change but sessions need to be
reestablished.
Inter-chassis Distributed Both user and During a master/slave switchover,

hot backup and session tables are the NAT relationship between public
centralized backed up. and private addresses does not
CGN change and sessions do not need to
scenarios be reestablished.
The working mechanism of inter-chassis redundancy in different failure scenarios is as

follows:
l Private link failure
Figure 5-33 shows a private link failure. Such a failure can be detected by VRRP, and a
switchover will be triggered. On the private network side, the master device (CGN1)
detects the link failure and switches traffic to slave device (CGN2). In this case, CGN2
becomes the master device. On the public network side, CGN2 advertises the routes with
a higher priority, and traffic from the public network is switched to CGN2. The traffic
convergence takes about 250 ms. After such a traffic switchover, it takes milliseconds to
refresh the public IP address. The exact time depends on the number of routes.

Figure 5-33 Private link failure
CGN1 CGN2
(Master) VRRP (Slave)
VRRP+BFD
Switch
Primary traffic
path
Post-switchover
PC path
l Public link failure

Figure 5-34 shows a public link failure. Such a failure can be detected by VRRP, and a
switchover will be triggered. On the public network, IGP/BGP convergence will be
triggered and traffic will be switched to the new master device (CGN2). On the private
network, this failure cannot be detected, and private-to-public traffic will still be sent to
CGN1 and then CGN2 over the bypass link.
The CGN convergence takes about 250 ms, but IGP/BGP convergence requires traffic
switching to CGN2. If no specific reliability technique is deployed, traffic switching will
take a long time (several seconds). Using BFD or other techniques is recommended to
reduce the convergence time to 250 ms. The final convergence time will be longer as
both IGP/BGP and CGN failures are triggered at almost the same time.

Figure 5-34 Public link failure
CGN1 CGN2
VRRP+BFD
Switch
Primary traffic
path
Post-switchover
path
l VSUF failure (CPU engine or subcard failure)

Figure 5-35 shows a service board failure. Such a failure can be detected by VRRP, and
a switchover will be triggered. For a private network, the failure cannot be detected so
traffic can still be sent to CGN1 and then CGN2 over a bypass link for NAT processing.
In this case, CGN2 becomes the master device to advertise routes with a higher priority,
and public network traffic is switched to CGN2, instead of passing through CGN1. The
switchover takes about 250 ms. After the switchover, the cost of public IP addresses will
be refreshed. The refreshment time depends on the number of routes.

Figure 5-35 VSUF failure
CGN1 CGN2
VRRP+BFD
Switch
Primary traffic
path
Post-switchover
path
5.9.3.5 Common CGN deployment scenarios

Figure 5-36 Common CGN deployment scenarios

Centralized (Standalone) Centralized (Board)
CR CR CR CR
CGN CGN
BRAS BRAS BRAS BRAS
Distributed (Board)
CR CR
BRAS BRAS
l CGN can be classified as standalone CGN or integrated CGN in terms of device patterns.
For details, see Figure 5-36.
– Standalone CGN refers to the use of a separate device to take over CGN functions.
Standalone CGN has its own space in a chassis and requires cables to connect to a
BRAS or CR. In addition, two extra interfaces need to be configured for the CGN
device and CR/BRAS each, so that private IPv4 traffic can be diverted to the CGN
device and public IPv4 traffic can be sent back to the CR/BRAS after NAT is
implemented. A standalone CGN device requires a specific unit for network
management. Considering that address translation and user management are
performed on the CGN device and BRAS respectively, user tracing becomes
difficult.
– Integrated CGN indicates the insertion of a CGN board into a device, such as
BRAS, SR, or CR.
Integrated CGN uses only one device slot, with no need for extra chassis space,
forwarding interface, or cable layout. Integrated CGN has a big advantage in
scalability and does not require a specific unit for network management.
In comparison, standalone CGN has no impact on services on the BRAS but requires an
independent BRAS interface to divert traffic, whereas integrated CGN features a
combination of CGN and BRAS and provides better user management. For details, see
Table 5-38.

Table 5-38 Comparison between standalone CGN and integrated CGN
Dep Standalone CGN Integrated CGN

loy
men
t
met
hod
Depl l Excellent performance, multi- l Small occupancy, low requirements on

oym core CPU processing power dissipation, low investment
ent l Excellent capacity and l Interworking between the network
char scalability, support for layer and application layer, support for
acte expansion in multi-chassis or multiple routing protocols, integrated
risti cascading mode access, and CGN management
cs
l Flexibility in device l Excellent scalability, support for
placement online deployment
l Occupancy of BRAS l Using a BRAS service slot
interfaces to divert traffic to
the standalone CGN device
l CGN can be classified as centralized CGN and distributed CGN in terms of deployment
positions. For details, see Figure 5-36.
– For centralized CGN, a standalone CGN device or a CGN board can be deployed at
the CR position, such as where a P router is located on the metro or backbone
network.
– For distributed CGN, a standalone CGN device or a CGN board can be deployed at
the BRAS or SR position.
Table 5-39 outlines a comparison between centralized CGN (taking a standalone CGN
device connected to a CR as an example) and distributed CGN (taking a CGN board
inserted into a BRAS as an example).
Table 5-39 Comparison between centralized CGN and distributed CGN
Item Centralized CGN Distributed CGN
Deploym A standalone CGN device is A CGN board is inserted into a

ent deployed on the metro network BRAS.
position egress to connect to a CR.
Deploym An independent CGN device is No new device is required. All you

ent required. The other things new need to do is insert a CGN board
complexi items are two extra 10GE into a BRAS. CGN deployment or
ty interfaces on the CGN device and expansion does not require
CR each, cable layout, and a adjustment of metro network routes,
traffic diversion policy. In case of and no log server needs to be
CGN expansion or policy deployed.
adjustment, network-wide routes
need to be readjusted, and a
designated log server is required.

Impact Private network routes need to be The metro network architecture is

advertised on the metro network. unchanged as private network routes
Private IP address and metro are not advertised on the metro
network routes need to be network. The BRAS can report a
replanned. Centralized CGN NAT mapping table to the AAA
expansion requires readjustment server by means of RADIUS and
of metro network routes, which is supports online tracing.
complex in networking. In
addition, centralized CGN
supports only offline tracing.
Service Service traffic within a single city The metro network structure is
traffic is transferred to CRs and CGN unchanged, and therefore the traffic
devices for processing. This model remains. The forwarding
causes the traffic volume on CRs efficiency is high and performance
to increase. CGN easily becomes a requirements are low.
performance bottleneck.
Reliabilit CGN devices are maintaining a CGN devices are maintaining a few
y great number of sessions, sessions, and therefore a CGN
requiring high reliability. A CGN device failure affects a small number
device failure may affect a large of users. The distributed networking
number of users and is prone to minimizes the risk of attacks on
vulnerabilities. The centralized CGN subcards.
networking will evolve to the
distributed networking along with
the ever-increasing number of
metro network users.
Network Centralized CGN triggers The BRAS gets aware of user online
security management of NAT flow tables and offline. The user NAT flow table
upon receipt of packets. After a will be immediately deleted upon
user goes offline, the NAT flow user offline.
table ages out for a Before the
NAT flow table completely ages
out, the host corresponding to the
offline user exists on the private
network and
Network An agent needs to be deployed on The existing NMS can be reused.

managem the CGN device, and a CGN NE
ent needs to be added to the NMS
workstation. The NMS needs to be
redeployed, regardless of in-band
or out-of-band management. For
out-of-band NMS, cable layout is
also required.

Costs The new items include chassis Inserting a CGN board on a BRAS
space, two forwarding interfaces does not require extra hardware
(LPUs may also be required) on deployment or reconstruction. The
the CGN and CR each, cable deployment and maintenance are
layout, and log server. In the event simple.
of capacity expansion, network
reconstruction is also required.
The deployment and maintenance
are complex.
Simply put, the distributed CGN solution outperforms the centralized CGN solution in terms
of network impact, traffic model, reliability, and network management and therefore is
recommended. When a CGN board is installed on a BRAS, the network architecture and
traffic model remain unchanged, which makes it easy to perform private network route
planning, MAN route management, user policy control, and source tracing. However,
centralized CGN can be a choice for areas with a few number of users.
5.9.4 CGN Solution Design
5.9.4.1 CGN Solutions Overview
Smooth IPv6 transition takes into consideration all the levels and various factors, such as user,
service, network, and costs. Proper planning allows for comprehensive IPv6 transition step by
step.
As shown in Figure 5-37, NAT444 is a solution to address IPv4 exhaustion at the early stage
of IPv6 transition. The NAT64 and DS-Lite are introduced for the latter stage of IPv6
transition. IPv6 has been stably developed. With the gradual recognition of carriers, the dual-
stack+NAT444 and DS-Lite are more widely used.
Figure 5-37 CGN solution positions
NAT64
IPv6
NAT444
IPv4
DS-Lite
Low IPv6 evolution High

Table 5-40 lists five CGN solutions.

l NAT444 solution
l Dual-stack+NAT444 solution
l DS-Lite solution
l Dual-stack+L2NAT solution
l IPv6+NAT64 solution
Table 5-40 Deployment elements of all solutions

Deployme NAT444 Dual- DS-Lite Dual-Stack IPv6+NAT64
nt Node/ Stack +L2NAT
Solution +NAT444
Name
CPE IPv4-IPv4 l Dual- l Dual- l Dual- IPv6

requiremen NAT stack stack stack
ts l IPv4- l IPv4 over l L2-NAT
IPv4 IPv6
NAT tunnel
BRAS IPv4 user Dual-stack l IPv6 user Dual-stack IPv6 user

requiremen manageme user managem user management
ts nt manageme ent management
nt l DHCPv6
option64
CGN IPv4-IPv4 IPv4-IPv4 l IPv4-IPv4 Layer 2 IPv6-IPv4 NAT

NAT NAT NAT information
l 4in6 +IPv4-IPv4
tunnel NAT
Number of Twice Twice Once L2NAT Once

NAT times replacing a
NAT44
5.9.4.1.1 NAT444 Solution Overview
The NAT444 solution effectively alleviates IPv4 address shortage and is suitable for IPv6
migration at an early stage.
On the network shown in Figure 5-38, if the CPE is a routed device, the BRAS assigns a
private IP address (such as 10.1.1.1) to the CPE and then a private IP address (such as
192.168.1.1) to the terminal after NAT is performed on the CPE. In this case, double NAT is
performed, and this is where the name NAT444 comes from. If the CPE is a bridged device,
only one level of NAT44 is required.

Figure 5-38 NAT444 solution

Terminal Access Metro Core Internet
CGN P
CR
CPE DSLAM BRAS
PE IPv4
OLT PE
BRAS
CR
CGN P
2G/3G/LTE
NAT44
IPv4 PPPoE/IPoE Public IPv4 Bridged CPE
NAT44 NAT44
IPv4 PPPoE/IPoE Public IPv4 Routed CPE
The NAT444 solution has the following characteristics:

l A CGN device can be either separately deployed on the metro network or integrated into
a BRAS to perform NAT.
l If a terminal device (such as a PC) connects to the network through a CPE, a BRAS
assigns private IP addresses to the terminal device and CPE, and a CGN device performs
NAT on the user traffic.
5.9.4.1.2 Dual-stack+NAT444 Solution Overview
The dual-stack+NAT444 solution supports IPv6 address extension by providing IPv4/IPv6

dual-stack on terminal devices and network nodes and addresses IPv4 address shortage by
deploying carrier-grade NAT (CGN) devices. Thanks to the mature technologies used, the
dual-stack + NAT444 solution is a popular IPv6 deployment solution among global carriers.
On the network shown in Figure 5-39, the dual-stack+NAT444 solution is used, with IPv4/
IPv6 dual-stack enabled on terminal devices (such as the PC and routed CPE) and MAN
devices (such as the BRAS, CGN, and CR).

Figure 5-39 Dual-stack+NAT444 Solution

P
CPE DSLAM
IPv4
CGN-NAT44
PE
OLT PE
BRAS
with
CGN IPv6
P
2G/3G/LTE
NAT44
IPv4 Public IPv4 Bridged CPE
PPPoE/IPoE
IPv6 IPv6+NAT444
NAT44 NAT44
IPv4 Public IPv4 Routed CPE
PPPoE/IPoE
IPv6+NAT444
IPv6
Dual Stack
NOTE
In distributed deployment scenarios, the BRAS enabled with NAT must support dual-stack user
management.
In centralized deployment scenarios, a CGN device can be deployed either on the metro egress or the
backbone network.
The dual-stack + NAT444 solution has the following characteristics:

l IPv6 packets are transparently transmitted over Layer 2 between the CPE and BRAS.
During PPPoE access, a PPPoE tunnel is established between a terminal device and the
BRAS, with transit nodes unaware of IPv6 packets. During IPoE access, transit nodes
need to be upgraded to get aware of IPv6 packets and support lightweight DHCPv6 relay
agent (LDRA).
l Metro network devices are enabled with IPv4/IPv6 dual-stack to support both IPv4 and
IPv6 route forwarding.
l In the event of public IPv4 address insufficiency, private IPv4 addresses are allocated to
the user host, and NAT44 is implemented on the carrier network side.

l The existing service model remains unchanged, except that IPv6 attributes are added.
The user authentication, authorization, and accounting mechanisms also remain
unchanged.
l If IPv4 users are unavailable, a dual-stack solution is indeed used. If IPv6 users are
unavailable, a NAT444 solution is indeed used.
5.9.4.1.3 DS-Lite Solution Overview
Dual stack lite (DS-Lite) involves translation between address families. In comparison with
IPv4-in-IPv4 NAT, DS-Lite is more complex. DS-Lite allows IPv6 service transmission
simply over an IPv6 network and IPv4 service transmission over an IPv6 network through
IPv4-in-IPv6 tunnels.
Figure 5-40 shows the networking of DS-Lite for PPPoE access. The routed CPE functions as
the Base Bridging Broad Band Element (B4), and the BRAS functions as an IPv6 node. A
standalone CGN device or a CGN board inserted into a BRAS can function as the address
Family Transition Router element (AFTR) on the MAN. The IPv6-only network exists
between the CPE, BRAS, and CGN device, whereas an IPv4/IPv6 dual-stack network exists
between the CGN device and CR. In comparison with the dual-stack+NAT444 solution, the
DS-Lite solution requires dual-stack deployment only on some devices on the MAN, which is
lightweight dual-stack.
Figure 5-40 DS-Lite solution

AFTR(CGN)
CR P
BRAS
DSLAM
CPE(B4) PE PE
IPv4
Dual-
IPv6-only Dual- stack/6PE
stack /6vPE
OLT
BRAS
P
CR
IPv6
AFTR(CGN)
NAT44
Private IPv4 DS-Lite Tunnel(4in6) Public IPv4 Routed CPE

DS-
IPv6 PPPoE Lite+NAT+PPP
oE

NOTE
l B4 (Basic Bridging Broadband Element)

l B4 has the dual-stack capability and is usually a host or CPE. The CPE is usually a home
gateway on the carrier network.
l An IPv4-IPv6 tunnel is created on the AFTR.
l AFTR (DS-Lite Address Family Transition Router Element)
The AFTR terminates the IPv4-in-IPv6 tunnel and achieves the NAT IPv4-IPv4 function. The AFTR
is usually a CGN device on the carrier network. Such a CGN device can be either a standalone
device or a CGN board inserted into a service control node. For details, see RFC 6333.
The DS-Lite solution has the following characteristics:

l In comparison with the dual-stack+NAT444 solution, the DS-Lite solution is a light-
weight NAT solution that involves the IPv6-only network between the CPE and BRAS.
l On the IPv6 network between the CPE and CGN device, the BRAS is responsible for
IPv6 user management and AFTR-NAME (DHCPv6 option 64) deployment, with the
AFTR-NAME stores the domain name of the CGN address.
l The CPE is responsible for assigning private IP addresses to the terminal, and the CGN
device identifies the user to implement NAT based on the tunnel information and private
IP address.
l The CPE works as a DHCPv4 server to allocate private IPv4 addresses space (such as
192.168.0.0/16) to residential users, and the BRAS implements only IPv6 address
allocation. If a residential user needs to access the IPv4 service, the private IPv4 address
reaches the CGN device over the IPv4-in-IPv6 tunnel, and the CGN device translates the
private IPv4 address into a public IPv4 address.
l An IPv4-in-IPv6 tunnel is deployed between the CPE and CGN device, and this tunnel is
used to access the IPv4 service. DS-Lite can be deployed on a standalone CGN device or
a CGN board inserted into a BRAS.
l The WAN interface of the CPE functions as the B4. DS-Lite does not require NAT
between the internal CPE interface and WAN interface, and the CGN device functions as
the AFTR (NAT IPv4-IPv4). Therefore, DS-Lite avoids double NAT (one on the CPE
and the other on the CGN device).
5.9.4.1.4 Dual-Stack+L2-NAT Solution
In Figure 5-41, the dual-Stack+L2-NAT solution requires that NAT is performed once, with a
shorter delay. PPPoE and IPoE assign the same address to the CPE, without private IP address
planning.

Figure 5-41 Dual-stack+L2-NAT solution

P
DSLAM
CPE
IPv4
PE
OLT PE
BRAS
with
CGN IPv6
P
2G/3G/LTE
IPv4 Public IPv4 Routed CPE

PPPoE/IPoE The CPE
IPv6 does not
perform NAT.
Dual Stack
The dual-Stack+L2-NAT solution has the following characteristics:

l Unlike L2-NAT or NAT44, dual-stack+L2-NAT performs NAT only once. The
deployment of this solution is based on the IPv4/IPv6 dual-stack, and IPv4 and IPv6
protocol stacks run separately.
l A CPE assigns private addresses to users and forwards packets over Layer 3 routes.
l CGN devices distinguish user packets based on the CPE's MAC+PPPoE session
information and perform NAT on user packets.
l Since L2-NAT only supports distributed deployment, L2-NAT can only be deployed on
BRASs and work in distributed mode.
5.9.4.1.5 NAT64 Solution
NAT64 applies to the latter phase of IPv6 transition in which IPv6 is the mainstream
application. New users connected to an IPv6 network can access the remaining IPv4 services
across the IPv6 network.
On the network shown in Figure 5-42, the CGN device is deployed on the SR/CR side, and
the CPE, CR, and CGN device communicate with each other over an IPv6 network. The
terminal users of the Ipv6 access translates IPv6 addresses into public IPv4 addresses to
access the IPv4 service.

Figure 5-42 NAT64 solution

Terminal Access Metro Servers Core Internet
P
SR
CGN-
NAT64
CPE DSLAM DNS-
>DNS64 IPv4
PE
OLT Accounting/R PE
ADIUS
NAT64
SR
P IPv6
2G/3G/LTE GGSN/MME
NAT64
IPv6 PPPoE/IPoE Public IPv4
IPv6
IPv6 network
The NAT64 solution has the following characteristics:

l A CGN device can be deployed to the SR or CR.
l The IPv6 terminal sends an AAAA request to a website URL to the DNS64 server over
the IPv6 network. As the IPv6 network does not have the AAAA address of the website
URL, the DNS64 server obtains the parsing result of address A of the URL address. The
DNS64 server adds an IPv6 prefix (such as 64:FF9B::/96) to the IPv4 address returned in
the A request and adds the IPv6 AAAA parsing result to the IPv6 prefix to the terminal.
l After obtaining the DNS response, the terminal accesses the IPv6 address of the Ipv6
prefix.
l Based on the IPv6 prefix route, the NAT64 CGN device removes the IPv6 prefix of the
IPv6 packet destination address and performs NAT64 on the source IP address and port
number and translate to Ipv4 addresses before forwarding them to the IPv4 network.
l IPv4 packets are forwarded to the NAT64 device and then to the terminal user after the
IPv4-IPv6 stateful translation.
l If the NDS64 server is unavailable, DNS ALG needs to be enabled for the NAT64
instance.
5.9.4.2 Key Elements for Solution Design
5.9.4.2.1 CGN Traffic Diversion
Traffic Diversion Principle

A CGN device uses the multi-core VSUF that has no outbound interface to process services.
Figure 5-43 shows the traffic diversion procedure of CGN services.

l Upstream direction (user-side traffic)

a. LPU->SFU->VSUF: Traffic is diverted from the SFU to the VSUF over the LPU.
Users can configure a traffic policy to import the packets that hit the traffic policy
to the service board for processing.
b. VSUF->SFU->LPU: The VSUF performs NAT on user-side traffic, and the traffic
is sent to the LPU over the SFU.
l Downstream direction (network-side traffic)
a. LPU->SFU->VSUF: Traffic is diverted from the SFU to the VSUF over the LPU
using the routing table of the public address pool.
b. VSUF->SFU->LPU: The VSUF performs NAT on network-side traffic, and the
traffic is sent from the SFU to the LPU.
Figure 5-43 CGN service processing
LPU SFU LPU
VSUF
Inbound traffic
Outbound traffic
Figure 5-43 shows the internal processing among components. Figure 5-44 shows the
upstream and downstream CGN forwarding at each stage.
l Upstream direction (user-side traffic)
a. A packet is transmitted from a PIC interface.
b. PIC->PFE (Packet Forward Engine): Layer 2 CRC is performed on the PIC.
c. PFE->TM: The PFE searches for the TCAM for ACL matching. Users can
configure a traffic policy for traffic diversion. The search result contains the
position information of the NAT instance (board and multi-core CPU information).
These information is encapsulated and then sent to the TM. Layer 3 CRC is
performed on the PFE.
d. TM->SFU: The packet is fragmented into several units for exchange so that NAT
position information can be sent to the SFU.
e. SFU->TM: The SPF sends packet fragments to the subsequent board.
f. TM->Multi-core CPU: Packet fragments are reassembled and then sent to the
corresponding multi-core CPU.

g. Multi-core CPU->TM: The multi-core CPU processes NAT to allocate public IP

addresses and ports as well as establishing NAT sessions. The device then searches
for FIB entries based on the destination IP address. The search result contains the
next-hop outbound interface information. This information is sent to the TM.
h. TM->SFU: Upon receipt of the encapsulated next-hop information, the TM
fragments the packet and sends the packet that includes the next-hop information to
the SFU.
i. SFU->TM: The SFU sends packet fragments to the corresponding board.
j. TM->PFE: The TM reassembles packet fragments and sends the packet to the PFE.
The next-hop information is contained in the packet header.
k. PFE->PIC: The PFE sends the packet to the PIC interface.
l. The PIC forwards the packet.
l Downstream direction (network-side traffic)
a. A packet is transmitted from the PIC interface.
b. PIC->PFE: Layer 2 CRC is performed on the PIC.
c. PFE->TM: The PFE searches for the TCAM for ACL matching. Users can
configure a traffic policy for traffic diversion. The search result contains the
position information of the NAT instance (board and multi-core CPU information).
These information is encapsulated and then sent to the TM. Layer 3 CRC is
performed on the PFE.
d. TM->SFU: The packet is fragmented into several units for exchange so that NAT
position information can be sent to the SFU.
e. SFU->TM: The SPF sends packet fragments to the subsequent board.
f. TM->Multi-core CPU: Packet fragments are reassembled and then sent to the
corresponding multi-core CPU.
g. Multi-core CPU->TM: The multi-core CPU searches for the destination IP address
(public IP address) of NAT session entries based on hash algorithm. If the mappings
between the public and private IP address and port of the NAT session are obtained,
the destination IP address and port of the packet can be processed and translated
into the corresponding private IP address and port. The TCAM searches for the FIB
entries of the private IP address and the next-hop outbound interface. The next-hop
information is encapsulated into the packet before the packet is forwarded to the
TM.
h. TM->SFU: Upon receipt of the encapsulated next-hop information, the TM
fragments the packet and sends the packet that includes the next-hop information to
the SFU.
i. SFU->TM: The SFU sends packet fragments to the corresponding board.
j. TM->PFE: The TM reassembles packet fragments and sends the packet to the PFE.
The next-hop information is contained in the packet header.
k. PFE->PIC: The PFE sends the packet to the PIC interface.
l. The PIC forwards the packet.

Figure 5-44 CGN service processing in the upstream and downstream directions
LPU
Control CPU
Management bus
SFU
MAC PFE
TM
1 Framer 2 3 4
TCAM
Interfaces
VSUF
5
Control CPU
Management bus
Multi-core
TM CPU TM
8 7 6
TCAM
LPU
Control CPU
Management bus
SFU
PFE MAC
TM
9 10 11 Framer 12
TCAM
Interfaces
5.9.4.2.2 NAT Modes Supported by CGN Boards
A CGN board supports two NAT modes:

l Full-cone mode: also known as the 3-tuple mode that is not concerned with destination
addresses or port numbers. In this mode, a CGN device assigns IP addresses and filters
packets based on the source address, source port number, and protocol type. This mode
supports a wide range of NAT traversal applications.

Figure 5-45 Full-cone mode
S:N/3011 Host B
S:A/2011 D:B/2012 Port
D:B/2012 2012
Port
2013
Port
Port
Host A 2011 2012
Port
2013
Host C
l Symmetric mode: also known as the 5-tuple mode in which a CGN device assigns public
IP addresses and filters packets based on the source and destination IP addresses, source
and destination port numbers, and protocol type. This mode has higher network security
but cannot support NAT traversal through STUN or P2P. The symmetric mode is usually
deployed on firewall.
Figure 5-46 Symmetric mode
S:N/3011 Host B
S:A/2011 D:B/2012 Port
D:B/2012 2012
Port
2013
Port
2011 Port
Host A 2012
Port
2013
Host C
Currently, the full-cone mode is recommended because it supports a wide array of NAT
applications. The default 5-tuple mode can be changed to the full-cone mode in the NAT, DS-
Lite, or NAT64 instance view.
5.9.4.2.3 CGN Port Pre-allocation
Table 5-41 Comparison between port allocation modes

Port Allocation Advantage Disadvantage
Mode
Port pre-allocation A fixed port range is pre- Whether the port range meets
allocated to the users who are the requirement cannot be
using the same public IP guaranteed.
address.

Port Allocation Advantage Disadvantage

Mode
Semi-dynamic port A fixed port range is pre- This mode is preferred to the
allocation allocated to the users who are dynamic port allocation mode
using the same public IP although it also cannot ensure
address. In this mode, if the that all users have sufficient
port range exceeds the limit, port allocation.
you can configure the number
of extension times within a
specified range.
Dynamic port A fixed port range is pre- If a user needs to use a lot of
allocation allocated to the users who are ports, the number of ports
using the same public IP allocated to other users may be
address. In this mode, if the insufficient. In this scenario,
port range exceeds the limit, the semi-dynamic port
you can set the number of allocation mode has an
extension times to any value. advantage because it allows for
even port allocation to each
user.
Taking the port pre-allocation mode as an example, after the port-range command is run in
the NAT, DS-Lite, or NAT64 instance view, the system pre-allocates a port range to private
network users to perform NAT. Running the port-range command in the NAT, DS-Lite, or
NAT64 instance view indicates that this instance uses the port pre-allocation mode. The port-
range command also specifies the size of a port range. The start and end port numbers are
automatically generated.
As shown in Figure 5-47, after port-range 1024 is configured on the CGN device, port
segment [1024,2047] is allocated to CPE1 and port segment [2048,3071] is allocated to
CPE2.
Figure 5-47 CGN port pre-allocation
IPv4
Public Address Pool:204.49.1.2-204.49.1.24

IPv4 Private IPv4 10.112.1.2 Port-range ports：1024
CPE1
I n t e r n et
IPv4
BRAS CGN CR
IPv4 Private IPv4 10.112.1.10

Private IPv4 Public IPv4 Port range
CPE2
User 1:10.112.1.2 204.49.1.2 1024~2047
User 2:10.112.1.10 204.49.1.2 2048~3071
…… …… ……

Port pre-allocation can be used in two scenarios:

l If a CGN board is inserted into a BRAS, the CGN board pre-allocates a port segment
upon user online and releases the port segment upon user offline.
l If a standalone CGN device is deployed, the CGN device allocates a port segment (for a
specific source IP address) upon receipt of data flows and releases a port segment
through the aging mechanism.
If a large number of ports need to be used within a specific period of time, new connections
may fail to be set up for users after the first-time port allocation, and the use of some
applications will be affected. In this case, users have to either shut down some applications or
go online again, which is quite complex. To address this issue, incremental port allocation is
introduced. Currently, the system supports three incremental port allocations, with the number
of ports allowed to be allocated each time ranging from 64 to 8192. If a NAT, DS-Lite, or
NAT64 instance does not have port pre-allocation configuration, the semi-dynamic port
allocation mode is used.
The CGN solution recommends the port pre-allocation and semi-dynamic port allocation
mode as these two modes can save port resources and easy for user management.
5.9.4.2.4 Public Address Pool and Route Advertisement
A public network address pool can be configured in either of the following methods:
l Configure multiple public IP address segments for a public address pool.
– Run the section mask command to configure a public IP address segment.
[HUAWEI-nat-instance-nat1] nat address-group addr-group group-id 3
[HUAWEI-nat-instance-nat1-nat-address-group-add-group] section 2
213.1.1.0 mask 24
If the NAT public address pool is set to work in mask mode, the master and slave
devices will generate the same number of routes as the section value, and the routes
have the same mask as the mask value.
<Master> display nat instance test
nat instance nat1 id 1
service-instance-group 1
nat address-group addr-group group-id 1
section 0 213.1.1.0 mask 24
nat outbound any address-group addr-group
<Master> display ip routing-table
-------------------------------------------------------------------------
-----
Routing Tables: Public
Destinations : 10 Routes : 10
Destination/Mask Proto Pre Cost Flags NextHop

Interface
213.1.1.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0

<Slave> display nat instance nat1
nat address-group addr-group group-id 1
<Slave> display ip routing-table
-------------------------------------------------------------------------
-----


Interface
213.1.1.0/24 Unr 64 255 D 127.0.0.1

InLoopBack0
– Run the section start-end command to configure a public IP address segment.

[HUAWEI-nat-instance-nat1] nat address-group addr-group3 group-id 2
[HUAWEI-nat-instance-nat1-nat-address-group-add-group] section 1
213.1.2.195 213.1.2.200
If the NAT public address pool is set to work in start-end mode, the master and
slave devices will generate the same number of routes as the number of public IP
addresses, and the routes all have a 32-bit mask.
<Master> display nat instance nat1
nat address-group addr-group3 group-id 2
section 1 213.1.2.195 213.1.2.200
<Master> display ip routing-table
-------------------------------------------------------------------------
-----

Interface
213.1.2.195/32 Unr 64 10 D 127.0.0.1

InLoopBack0
213.1.2.196/32 Unr 64 10 D 127.0.0.1
InLoopBack0
213.1.2.197/32 Unr 64 10 D 127.0.0.1
InLoopBack0
213.1.2.198/32 Unr 64 10 D 127.0.0.1
InLoopBack0
213.1.2.199/32 Unr 64 10 D 127.0.0.1
InLoopBack0
213.1.2.200/32 Unr 64 10 D 127.0.0.1
InLoopBack0
<Slave> display nat instance nat1
nat address-group addr-group3 group-id 2
section 1 213.1.2.195 213.1.2.200
<Slave> display ip routing-table
-------------------------------------------------------------------------
-----

Interface
213.1.2.195/32 Unr 64 255 D 127.0.0.1

InLoopBack0
213.1.2.196/32 Unr 64 255 D 127.0.0.1
InLoopBack0
213.1.2.197/32 Unr 64 255 D 127.0.0.1
InLoopBack0
213.1.2.198/32 Unr 64 255 D 127.0.0.1
InLoopBack0
213.1.2.199/32 Unr 64 255 D 127.0.0.1
InLoopBack0

213.1.2.200/32 Unr 64 255 D 127.0.0.1

InLoopBack0
l Configure a public IP address segment for a public address pool.

– Run the nat address-group mask command to configure a public IP address
segment.
[HUAWEI-nat-instance-nat1] nat address-group addr-group group-id 1
213.1.1.0 mask 24
To view the generated public routing table, refer to the section mask mode.
– Run the nat address-group start-end command to configure a public IP address
segment.
213.1.2.195 213.1.2.200
To view the generated public routing table, refer to the section start-end mode.
If a NAT/DS-Lite/NAT64 public network address pool is configured using the mask mode
(recommended), the length of the advertised routes is the same as configured. If a NAT/DS-
Lite/NAT64 public network address pool is configured using the start-end mode, the length
of the advertised routes is 32 bits.
5.9.4.2.5 User-based CGN Resource Management Solution
The following configuration can be performed to control CGN resources for users:
l Restriction on the number of ports used by a user
l Maximum number of user-to-network NAT sessions
l Maximum number of network-to-user NAT sessions
l ALG
l Number of ports in the port range
NOTE
Performing device configuration to control CGN resources for users is applicable to all CGN solutions.
A policy template can be configured to control CGN resources for users.

l Maximum number of user-to-network NAT sessions
l Maximum number of network-to-user NAT sessions
l ALG
l Number of ports in the port range
NOTE
l The RADIUS server deploys a policy template to a specific user.

l The NAT policy template delivered by the RADIUS server has a higher priority than the policy
template bound to a specific user group in the domain.
l Using a policy template to control CGN resources for users is applicable only to distributed CGN
deployment.
5.9.4.2.6 External-to-Internal Network Access Solution
l NAT Server
Generally, NAT allows only private-to-public network access. As shown in Figure 5-48,
the NAT server allows a public network host to access an internal server by configuring

the internal server function on the CGN device. In this manner, the public IP address and
port number of the external network host can be mapped to the internal server.
Figure 5-48 Accessing an internal server through a NAT server

Assigns a public IPv4 address.
Host A
Server CPE DSLAM BRAS
Host B
l Port Forwarding
When the IP addresses of internal servers frequently change, you can configure a port
forwarding policy to dynamically associate each internal server with a public IP address
and port.
As shown in Figure 5-49, the port forwarding mechanism allows for access to an
internal server as follows:
a. A public IP address and port segment are pre-configured.
b. A port forwarding policy is specified for the CPE during user authentication.
c. The BRAS fills in the port forwarding policy with a public IPv4 address specified
for the user and then generates the associated NAT entry.
d. During accounting, the BRAS sends packets carrying the port forwarding policy to
the RADIUS server.
e. The RADIUS server monitors the user's NAT status through the NAT-Port-
Forwarding-Info(26–164) attribute.
Figure 5-49 Using the port forwarding mechanism to access an internal server
⑤
RADIUS Server
② ④ Host A
Server CPE DSLAM BRAS
① ③
Host B

The RADIUS server specifies a port forwarding policy for the server and configures the
mapping between the URL and public IPv4 address for the DNS service system.
The NAT Server mechanism has simpler configuration than the Port Forwarding mechanism
and therefore is recommended for an external network host to access an internal server.
NOTE
The Port Forwarding mechanism is applicable to distributed CGN deployment and works for the
distributed NAT444 and DS-Lite solutions. The NAT Server mechanism is applicable to all CGN
solutions.
5.9.4.2.7 CGN User Source Tracing Solution
CGN address source tracing supports user logs and flow logs. User logs are recommended for
an advantage of saving the space. RADIUS source tracing is recommended for distributed
CGN deployment. Syslog based on user is recommended for centralized CGN deployment.
l RADIUS Source Tracing

RADIUS tracing is applicable only to scenarios where a CGN board is inserted to a
BRAS and ports are pre-allocated.
NOTE
The L2NAT solution supports only RADIUS source tracing.

l Syslog based on user
Syslog based on user is applicable to both distributed CGN deployment and centralized
CGN deployment.
Table 5-42 Syslog Source Tracing
Port Allocation
Syslog based on user Syslog based on NAT session
Mode
One log for each

One log for each NAT session
user(with same source IP)
Port Range mode Usually used for ports

Usually used for ports used by
used by services can be
services can be estimated well, and
estimated well, and need
accurate source tracing
low pressure on log server
One log for each user

(with same source IP) for
the first time of port
allocation, and one more One log for each NAT session
log for each time of
Semi-Dynamic expansion of the port
mode allocation.
Usually used for ports

Usually used for ports used by
used by services cannot be
services cannot be estimated well or
estimated well or change a
change a lot, needing accurate
lot, needing low pressure
source tracing as well
on log server as well

Port Allocation
Syslog based on user Syslog based on NAT session
Mode
Port Dynamic
Not supported One log for each NAT session
mode
NOTE
For syslog based on user, the maximum send speed is: 256K log/s/Multi-core CPU.
For syslog based on NAT session, the maximum send speed is: 512K log/s/ Multi-core CPU.
5.9.4.2.8 CGN Reliability
CGN devices support carrier-grade reliability design that ensures service continuity in the
event of a board fault. Currently, CGN reliability comes in two modes: inter-board backup and
inter-chassis backup.
NOTE
The service-ha hot-backup enable command enables CGN HA hot backup. Without this function
enabled, centralized backup is cold backup, and distributed backup is warm backup.
l If a CGN device has slots for two or more VSUF-40s, VSUF-80s or VSUF-160s and provides access
services for a limited number of users, you can apply inter-board or inter-chassis 1:1 backup. In
inter-chassis 1:1 backup, when the service board on the master device processes services, the service
board on the backup device does not work. The service board on the master device backs up the user
tables, session tables, and address pool entries to the service board on the backup device. Once the
master service board fails, the slave service board takes over services.
l If a CGN device has slots for two or more VSUF-40s, VSUF-80s or VSUF-160s and provides access
services for a large number of users, you can apply inter-board or inter-chassis 1+1 backup. In inter-
board 1+1 backup, both the master and backup service boards process services and back up their
user tables, session tables, and address pool entries to each other. Once a service board fails, the
other service board processes all services.
?.1. Inter-board Backup
When slots on a CGN device are sufficient, two or more VSUF–80/160s can be configured.
You can run the location slot slot-id { card card-id | engine engine-id } [ backup slot slot-id
{ card card-id | engine engine-id } ] command to configure the master and slave CPUs.
Inter-board backup can be categorized into 1:1 or 1+1 inter-board backup.

l The 1:1 inter-board backup applies to scenarios where user capacity is not large and
service board usage is not high. Once the master service board fails, the slave service
board takes over services. In this scenario, only one NAT instance is bound to an HA
service instance group. The configuration of 1:1 inter-board backup is as follows:
service-location 1
location slot 2 engine 1 backup slot 7 engine 1
service-instance-group nat444-1
service-location 1
nat instance nat444-1 id 1

port-range 4096

l The 1+1 inter-board backup applies to scenarios where user capacity is large and service
board usage is high. Once a service board fails, the other service board processes all
services. The configuration of 1:1 inter-board backup is as follows:
service-location 1
service-location 1
service-location 1
service-location 2

port-range 4096
port-range 4096
NOTE
Run the service-ha hot-backup enable command to enable the CGN HA hot backup function. If this
function is not enabled, centralized backup is cold backup, and distributed backup is warm backup.
?.2. Inter-chassis Redundancy
When different NAT pools or instances are used on NE40E&NE80E, they can have different
master chassis.
Each VSUF-160 has 4 CPUs (two SP-160 subcards sharing a CPU). Each CPU can be bound
to multiple several NAT instances, but only one CPU can be configured as the master for each
NAT instance. The master/slave status of each NAT instance is determined based on inter-
chassis Virtual Router Redundancy Protocol (VRRP). Therefore, the VSUF service board can
be either the master for one NAT instance or the slave for another NAT instance.
In inter-chassis redundancy mode, one device functions as the master, and the other device
functions as the slave. The master/slave relationships of NAT/DS-Lite/NAT64 instances are
determined based on VRRP. Figure 5-50 shows the NAT instance relationships in inter-
chassis redundancy mode.
Figure 5-50 Inter-chassis redundancy
Chassis 1 Chassis 2
VRRP1
NAT/DS-Lite/NAT64 NAT/DS-Lite/NAT64
instance 1 instance 1
VRRP2
NAT/DS-Lite/NAT64 NAT/DS-Lite/NAT64
instance 2 instance 2
Multi-core Current working Backup

cpu instance instance

As shown in Figure 5-51, BRAS1 and BRAS2 are deployed for RUI dual-device hot backup,
and the primary and secondary address pools are configured. The primary private network
address pool of BRAS1 is the same as the secondary private network address pool of BRAS2.
The primary private network address pool of BRAS2 is the same as the secondary private
network address pool of BRAS1. An LSW is dual-homed to BRAS1 and BRAS2 for backup.
To implement CGN HA dual-device backup on the BRASs, a CGN board is installed on each
BRAS, and the same public address pool is configured on both BRASs (CGN boards). Both
BRASs advertise the network segment routes of the CGN public address pool. The master
BRAS advertises routes with a smaller cost, and the backup BRAS advertises the routes with
a larger cost. This allows returned traffic to automatically travel through the master BRAS. A
VRRP group is configured on the BRASs and on the user sides of the BRASs. Configuring
the same VRRP association is recommended. If a link to a BRAS, a BRAS, or a CGN board
fails, the master/backup BRAS or CGN board switchover will be triggered.
Figure 5-51 CGN reliability
BRAS1(CGN1) BFD for IGP CR1
Peer BFD+mVRRP
LSW
BRAS2(CGN2) CR2
The inter-chassis redundancy solution includes:

l How does VRRP work?
– VRRP Association Object
NE40E&NE80Es support association related attributes, such as an interface's link
status. If the status of an object is changed, VRRP performs operations based on the
association with the specified object, such as changing the priority.
The VRRP association objects supported by NE40E&NE80E include an interface's
link status, BFD session status, and CGN HA backup group (multi-core CPU
working state), etc. Once the working state of a object changes, the change will be
reported to VRRP and VRRP will take corresponding actions.
The corresponding commands are as follows:
n Tracking interface status: vrrp vrid virtual-router-id track interface
interface-type interface-number [ increased value-increased | reduced value-
reduced ]
n Tracking BFD session status: vrrp vrid virtual-router-id track bfd-session
{ bfd-session-id | session-name bfd-configure-name } [ { increased |
reduced } value-reduced ]
n Tracking CGN HA backup group status: vrrp vrid virtual-router-id track
service-location service-location-id [ reduced value-reduced ]

For inter-chassis redundancy, one VRRP can be associated with only one CGN HA
backup group but multiple interfaces or BFD sessions.
These commands are typically configured on the master device. If the status of an
associated object is changed, a error occurs or a switchover is needed. The priority
of VRRP packets send by the master device will decrease to be smaller than that
sent by the slave device. The default decrease value is 10 and can be configured. If
the objects are tracked on slave, the increase value parameter will be used.
– Network Design Limitations on VRRP
A direct link must be established between the master and slave BRASs (CGN
boards). As defined in RFC 3768, the destination IP address of VRRP packets is the
multicast IP address 224.0.0.18 and TTL must be 255. In this context, VRRP
packets cannot be transmitted over Layer 3 networks, but can be transmitted over
Layer 2 networks (such as VLAN, VLL, and VPLS). Therefore, the network
between the master and slave must be a directly connected network or a Layer 2
network.
l How Huawei Redundancy Protocol (HRP) Works
– Basic HRP Mechanism
HRP is Huawei's proprietary protocol defined to synchronize information between
the master and slave. As shown in Figure 5-50, only NAT session information
needs to be synchronized. HRP is based on UDP, and the information to be
synchronized is encapsulated in the payload of a UDP packet.
HRP provides two ways of synchronization:
n Bulk synchronization: Synchronizes the entire active table to the slave device
when the VRRP peer comes up and auto backup is enabled.
n Incremental synchronization: Synchronizes newly established NAT sessions
after the VRRP peer comes up.
The synchronization is processed over the direct link between the master and slave
where VRRP is running. You can run the service-ha hot-backup enable command
to enable hot backup. The bulk synchronization and incremental synchronization
take effect simultaneously. After this command is run and the VRRP peer comes up,
the NE40E&NE80E will automatically synchronize NAT session information.
HRP traffic will have a higher priority than normal traffic. If traffic congestion
occurs on the inter-chassis link, HRP traffic will go first.
– Network Design Limitations on HRP
When traffic is transmitted over a direct inter-chassis link shown in Figure 5-51,
the link bandwidth must be included as a part of traffic bandwidth. Regarding the
inter-chassis redundancy bandwidth and link reliability requirements, using the
inter-board trunk interface (LAG) is recommended.
– How VRRP and HRP Work Together with NAT Instances
VRRP will track the service location (multi-core CPU) of VSUF board. All the
NAT instances using this service location will use the corresponding VRRP. Usually
we configure only one NAT instance on one service location, so the NAT instance
and VRRP will be one-to-one related. If needed, several NAT instance will use the
same service location, and then share the same VRRP. So we need a VRRP for each
service location and a VLAN for each VRRP.
After VRRP peer is up, HRP will sync NAT information via the link VRRP
working on. ALL NAT instances in the service location will be synchronized.

l How BFD Works

– Basic BFD Mechanism
BFD is used to detect faults of communication with adjacent devices in efforts to
minimize the impact on devices. VRRP is not good at detection performance,
whereas BFD provides a rapid method of failure detection on connections between
two devices. Currently the minimum time supported by NE40E&NE80E of detect
link failure is 10ms.
– Link Types for BFD Association
BFD can be associated with various links, including IP links (both single-hop and
multi-hop), Eth-Trunk, MPLS LSP, TE, and PW.
– BFD Performance
BFD is implemented by hardware. Once a BFD session is configured, the PFE will
send BFD detection packets at a minimum interval of 3.3 ms. The BFD sessions is
considered Down if three detection packets fail to be received consecutively.
Therefore, the minimum BFD detection interval is 10 ms. BFD implementation is
on the forwarding plane (PFE) and therefore has no impact on the performance of
the control plane.
– BFD+VRRP
BFD works on the forwarding plane to rapidly detect link failures. Once a BFD
session detects a failure, such a failure notification will be instantly reported to
VRRP, and VRRP will send packets with a decreased priority to notify the slave
device of a switchover. This detection mechanism is much faster than VRRP-based
detection.
Inter-chassis backup over direct links is recommended for CGN devices, and BFD+VRRP is
deployed to achieve fast switching.
5.9.5 CGN Solution Deployment Guide
5.9.5.1 Distributed NAT444 Solution Deployment Guide
5.9.5.1.1 Solution Overview
Networking Description
In Figure 5-52, two pieces of customer premises equipment (CPE) dial up through the
broadband remote access server (BRAS) equipped with Carrier Grade NAT (CGN) boards,
and the BRAS assigns private IP addresses, post-NAT IP addresses, and port number
segments for the CPEs. After receiving a packet from a PC, CPEs perform the first-level
Network Address Translation (NAT) for the packet and then sends the packet to the BRAS.
After receiving the packet, the BRAS performs the second-level NAT for the packet. In the
distributed NAT444, two NAT processes exist on the network and CGN is enabled on the
BRAS inbound interfaces.

Figure 5-52 Distributed NAT444 solution based on port pre-allocation

PC1 User IP:10.10.10.12
192.168.1.1 NAT IP:125.3.12.25
Port-range:2048-6143
Syslog RADIUS
Access Server Server
Manages the
network
10.10.0.0 network
segment.
CPE1 BRAS1
PC2 10.10.10.12 (CGN)
192.168.1.2 ISP Core
PC3
192.168.2.1 BRAS2 SR
(CGN) Manages the
Access 10.20.0.0 network DHCP Web
network segment. Server Server
User IP:10.20.10.12
CPE2
NAT IP:121.22.22.52
10.20.10.12
PC4
192.168.2.2
Address Allocation
The CPE assigns a private IP address to a residential user. The BRAS assigns a private IP
address to the CPE, as well as a NAT public IP address and a public port mapped to the
private IP address of the CPE.
NAT Process
The PC1 and PC2 performs NAT on IP packets through the CPE. In this case, the PC's IP
address is replaced with the CPE1's IP address 10.10.10.12 assigned by the BRAS1. A second
NAT is performed when the IP packets are transmitted over the BRAS1. The BRAS1 then
changes CPE1's IP address 10.10.10.12 with the public NAT address 125.3.12.25. The NAT
processing for PC3 and PC4 is not detailed here.
Advantages
l Seamlessly integration of user login and NAT
With this solution, NAT ports are pre-allocated for Point-to-Point Protocol over Ethernet
(PPPoE), IP over Ethernet (IPoE), Layer 2 Tunneling Protocol (L2TP), and web users.
NAT resource allocation and IP address translation information can be checked based on
user IDs and user domains. The Remote Authentication Dial In User Service (RADIUS)
server can perform user tracing based on information about NAT port number segments
carried in accounting request packets.
l Log management based on orderly port pre-allocation
In the traditional NAT implementation, a port is allocated for each traffic flow to perform
NAT. As a result, some users may occupy excessive resources. In addition, NAT logs are
reported based on traffic flows, consuming a large amount of system resources. To solve
these problems, the distributed NAT444 solution provides port number pre-allocation.
After port number pre-allocation is enabled, a port number segment is allocated for a
user when the user goes online and the port number segment is reclaimed when the user
goes offline, ensuring fair resource allocation. Moreover, only one NAT log is reported
once the user goes online or offline. The user tracing is performed based on the log.

Real-time user tracing can be performed by sending the public IP address and port
number segment of the user to the RADIUS server.
l Flexible and controllable service rollback
If the RADIUS server has assigned a private IP address for a user but the user needs a
public IP address, the RADIUS server can roll the user back to the public network
domain. Then, the RADIUS server obtains a public IP address, meeting requirements for
various types of users.
l Networking planning and management without public and private IP address
mixing
Private network routes are terminated on the BRAS. The BRAS stores private network
routes and public network routes separately, facilitating networking planning and
management.
l Inter-board cold and hot backups
5.9.5.1.2 Deployment Preparation
?.1. License Preparation
Table 5-43 shows license information related to VSUF-80s or VSUF-160s.
Table 5-43 License functions

License Control Item Control Level Configuration Item
NE40E&NE80E PCP Board PCP is not supported by default. To

function license enable PCP, run the following
command:
[HUAWEI] license
[HUAWEI-license] active pcp
vsuf slot 1

NE40E&NE80E 20 Gbit/s VSUF-40/80/160 l A VSUF-40 supports the 40

capacity license mother board CPU Gbps forwarding capacity
(including both upstream and
downstream bandwidth) and
provides a mother board CPU
without a subcard. Each CPU
supports 40 Gbps bandwidth,
and a mother board CPU
supports 20 Gbps forwarding
bandwidth by default. To
increase the forwarding
bandwidth to 40 Gbps, run the
following command:
[HUAWEI] license
[HUAWEI-license] active nat
bandwidth-enhance slot 1
engine 0
l A VSUF-80 supports the 80

Gbps forwarding capacity
provides a mother board CPU for
a subcard. Each CPU supports
40 Gbps bandwidth, and a
mother board CPU supports 20
Gbps forwarding bandwidth by
default. To increase the
forwarding bandwidth to 40
Gbps, run the following
command:
[HUAWEI] license
engine 0

Gbps forwarding capacity and
provides two mother board
CPUs for two subcards. Each
CPU supports 40 Gbps
bandwidth, and a mother board
forwarding bandwidth by
command:
[HUAWEI] license
engine 0

NE40E&NE80E NAT Board's mother By default, the maximum number of

session number license board or subcard session tables on a VSUF-40,
CPU VSUF-80 or VSUF-160 CPU is
zero. In addition, a board only
assigns an even number of session
resources of the CPU, in millions.
On a VSUF-40/80/160, a CPU
supports a maximum of 16 millions
NAT sessions. On a VSUI-160-E, a
CPU supports a maximum of 32
millions NAT sessions. To assign
the maximum number of NAT
sessions on a mother board or
subcard CPU, run the following
command:
[HUAWEI] license
session-table size 16 slot 1
engine 0
?.2. Version Preparation
The Table 5-44 lists version mapping of the NE40E&NE80E.
Table 5-44 Version mapping

Product Version
NE40E&NE80E V600R009C10
iManager U2000
?.3. Device Evaluation
Pay attention to the following restrictions on capacity expansion of the VSUF-40/80/160:
Power consumption
l The VSUF-40/80 supports only 10 Gb/s capacity on the old NE40E&NE80E-16 SFU
(ME01SFUA1). If the VSUF-40/80 needs to support 20 Gb/s capacity, the old SFU
(ME01SFUA1) needs to be replaced with the 40 Gb/s SFU (ME0D00SFUG20), and a
8000 W power supply must be used.
l In a chassis with the VSUF, the available slots and subslots with no subcards installed
are equipped with a filler panel in order to form a qualified air channel. Note that the
NE40E&NE80E-X8/X16 has different air channel design from NE40E&NE80E-8/16
and their filler panels must be different. The NE40E&NE80E-X8/X16 provides the U-
shaped air channel, and therefore a filler panel with air baffle must be used.

l The VSUF-40/80/VSUF-160 can be used in a NE40E&NE80E-8/16/X8/X16 chassis and

has no limits on subcard positions. The recommendations for inserting the VSUF-80/
VSUF-160 are as follows:
a. In an NE40E&NE80E-8 or NE40E&NE80E-X8 chassis, inserting the VSUF-40/80/
VSUF-160 into slot 3, 4, 5, or 6 is recommended.
b. In an NE40E&NE80E-X16 chassis, inserting the VSUF-40/80/VSUF-160 into slot
3, 4, 5, or 10 through 14 is recommended.
c. In an NE40E&NE80E-16 chassis, inserting the VSUF-40/80/VSUF-160 into a slot
locating in the middle of the bottom is recommended.
NOTE
l After the boards and subcards are inserted into the chassis, check whether they are well
positioned and the screws of the panel are tightened.
l A VSUF-160 cannot be used on a NE40E&NE80E-8/16.
l The NE40E&NE80E-8/16 supports the VSUF-40/80, but not subcards.
l The NE40E&NE80E-X3/X8/X16 supports the VSUF-40/80/VSUF-160. The VSUF-160
can be used only on devices equipped with 200G SFUs.
l The VSUF-80 can be used in an NE40E&NE80E-X3, but subcards are allowed to be
installed.
Subcard Application
The NE40E&NE80E-X8/X16 supports the hot swapping of the SP80/SP160 on the VSUF-80/
VSUF-160.
NOTE
You can simply insert a VSUF-80/VSUF-160 with a subcard installed into a chassis. Alternatively, you
can insert a VSUF into a chassis and then the subcard after the VSUF registration succeeds.
?.4. Performance Evaluation
The Table 5-45 lists the forwarding capabilities supported by the NE40E&NE80E
VSUF-40/80/160 after the bandwidth license is loaded.

Table 5-45 Forwarding capacity of the VSUF-40/80/160

Platfo Prod Servic Maximu Maximum Maximum Maximum
rm uct e m Forwarding Throughput Forwarding
Board Through Capacity of the Base Capacity
put of (512-Byte) of Board Fully (512-Byte) of
the Base the Base Configured the Base
Board Board with Board Fully
(Gbit/s) (Gbit/s) Subcards Configured
(Gbit/s) with
Subcards
(Gbit/s)
200 NE40 VSUF 40/40/80 25/25/50 NA/80/160 NA/50/100

Gbit/s E&NE -40/80
platfor 80E- /160
m X8
NE40
E&NE
80E-
X16
40 NE40 VSUF 40 25 NA/80 NA/50

Gbit/s E&NE -40/80
platfor 80E-
m X8
NE40
E&NE
80E-
X16
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-
X3
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-1
6
20 NE40 VSUF 15 15 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-8
m
10 NE40 VSUF 10 10 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-1
m 6

?.5. User Quantity Evaluation
l Traffic evaluation
If an NMS has been deployed on the live network, the performance statistics of the NMS
can be used to obtain the traffic model. If no NMS is deployed on the live network, you
can collect interface traffic statistics for evaluation.
– Method 1: calculation based on the sum of the upstream and downstream
traffic during peak hours
The traffic statistics during peak hours can be calculated based on the sum of the
user-side upstream and downstream traffic. It is recommended to use a number
greater than the evaluated one. The total traffic needs to be within the scope of the
VSUF-40/80/160 specification.
– Method 2: calculation based on average user traffic statistics
The number of online users (excluding the number of online management users,
such as ITMS users) and the sum of user-side upstream and downstream traffic
need to be collected. The sum of the user-side upstream and downstream traffic is
divided by the number of online users to obtain the average traffic per user. Then,
the average traffic per user is multiplied by the maximum number of users after
cutover for an evaluation of the bidirectional traffic on the CGN board during peak
hours. It is recommended to use a number greater than the evaluated one. The total
traffic needs to be within the scope of the VSUF-40/80/160 specification.
l Session evaluation
In actual situations, the average number of sessions ranges from 200 to 400. After the
VSUF is configured with the license indicating the maximum number of sessions, a
VSUF can support a maximum of 32M sessions. Before service cutover, the number of
users must be planned based on the number of NAT sessions supported on the VSUF. In
CGN load balancing scenarios, whether the board specification can still meet service
requirements after the backup board becomes faulty must be taken into consideration
during service planning.
If the NE40E&NE80E is installed with two VSUF-80s, with each supporting 16M NAT
sessions, the NE40E&NE80E supports a total of 32M NAT sessions. In CGN load
balancing mode, if each user is planned with 300 sessions, a total of 106666 users are
supported (16M*2/300=106666). If the number of NAT sessions exceeds 16M, the
backup VSUF will carry over 16M NAT sessions whenever a VSUF becomes faulty, and
some NAT sessions on the NE40E&NE80E may be lost. Therefore, the number of users
cannot exceed the maximum number of NAT sessions supported by the VSUF divided
by the number of user sessions (16M/300=53333).
?.6. Service Evaluation
?.1. NAT Services
Distributed NAT444 can be overlapped with the following services:

l Web Authentication
In the Web authentication solution, an address is allocated to a user for visiting a portal
website. After the user enters the login user name and password, the RADIUS server
authenticates the client. If the authentication succeeds, the client requests another address

for the user to access the external network. When the user needs to go offline, the client
also initiates an offline request.
l BoD
Bandwidth on Demand (BoD) is a value-added service featuring dynamic bandwidth
allocation. When users need to adjust their subscribed bandwidths, they can dynamically
activate or deactivate the BoD service through the Portal server. In this manner,
subscribed bandwidths are dynamically changed without the intervention of operators.
This also allows a more flexible service-based accounting mode for operators.
l DAA
Destination address accounting (DAA) implements differentiated accounting, rate limit,
and priority scheduling based on traffic destination addresses.
DAA can be used in the following scenarios in NAT444:
– DAA is used to change service types, and the user group is correspondingly
changed. For example, DAA can be used to accelerate the bandwidth for users of
Xiamen Telecom who would like to switch to the eCloud service.
– DAA is used to accelerate the bandwidth, with the user group not changed. Instead,
user bandwidth is adjusted using the DAA service template, such as the double-
speed network of Wuhan Telecom.
l EDSG
Enhanced dynamic service gateway (EDSG), an enhancement to DAA, independently
identifies a user's a piece of traffic and implements independent rate limit, accounting,
and management for the traffic.
l CoA
The RADIUS server changes service attributes of online users by sending the Change of
Authorization (CoA) packets. The CoA packets have the same format as common
RADIUS packets. For details, see Figure 1. The value of the Code field in a CoA packet
can be any of the following:
– 40 - Disconnect Request
– 41 - Disconnect ACK
– 42 - Disconnect- NAK
Figure 5-53 shows the process of dynamic authorization.

Figure 5-53 Flowchart of dynamic authorization

User Router RADIUS server Portal server
1. User subscribes to
a service
2. Information about
the ordered service
3. CoA-Request
packet
4. CoA-ACK/CoA-
NAK packet
5. Updated policy
The process of dynamic authorization is as follows:

a. During user online, the portal server is customized with a DAA service.
b. The portal server sends the customized service information to the RADIUS server.
c. The RADIUS server changes or customizes the service policy based on the service
and user information and sends a CoA-Request packet to the router to request for a
change of the user's authorization information.
d. Upon receipt of the CoA-Request packet, the router changes the user's authorization
information while the user keeps online. If such change succeeds, the router sends a
CoA-ACK packet back to the RADIUS server. Otherwise, the router sends a CoA-
NAK packet to the RADIUS server.
e. If such authorization succeeds, the router uses the dynamically changed
authorization attributes to control the DAA service.
The restrictions that NAT444 has on the DAA service are as follows:
l When NAT444 and DAA are overlapped, the user group delivered by DAA and the one
bound to the NAT instance are different. Therefore, the NAT function fails to take effect.
l During web authentication, the same NAT444 instance must be bound to both the pre-
authentication and authentication domains.
l In the Web authentication scenario, the NAT policy template cannot be delivered and
PortForwarding cannot be configured.
?.2. NAT Service Restrictions
l VPN NAT
Combined use of NAT and VPN:
– In VPN NAT scenarios where the LPUF-21/LPUF-40 is on the user side, if VPN is
configured on the user side, the vpn-nat enable must be run in the NAT instance.

– In VPN NAT scenarios, the QoS profile of NAT users cannot be switched after the
users go online. Otherwise, traffic statistics fail to be collected.
– In VPN NAT scenarios, the LPUF-21/LPUF-40 does not support redirection, CAR,
and SQ on upstream traffic for BAS users.
– VPN NAT private network users fail to connect to the CGN device through Telnet
or FTP.
– VPN NAT supports inter-chassis warm backup and inter-chassis hot backup but has
only one VPN on either the user side or network side.
l Port pre-allocation
In port-range mode, the CGN device randomly allocates the public IP address and port
segment to users to ensure that the sessions connected to the same host use the same
external IP address after NAT is implemented and to minimum the possibility that the
users who go online concurrently obtain the same external IP address.
Relationship between the port-range configured for a policy template and that for a NAT
instance:
– If the port-range has been configured for a policy template but not for a NAT
instance, the port-range configured for the policy template takes effect.
– If the port-range has been configured for a NAT instance but not a policy template,
the port-range configured for the NAT instance takes effect.
– If the port-range has been configured for both the policy template and NAT
instance, the port-range configured for the policy template takes effect.
l Log tracing
When distributed NAT444 is deployed, source tracing is not supported on the RADIUS
because Layer 3 leased line users or Layer 3 access to a web server can only go online in
integrated mode. In this manner, you can only configure Syslog tracing.
?.7. Peripheral Systems
?.1. RADIUS Server
If you want to use a Remote Authentication Dial In User Service (RADIUS) server to trace
user information, configure the RADIUS server to identify Huawei-specific protocols. If you
do not want to use the RADIUS server to trace users, the RADIUS server does not need to be
adjusted.
l RADIUS source tracing can only be implemented if the RADIUS server identifies HW-
NAT-IP-Address (21-161), HW-NAT-Start-Port (21-162), and HW-NAT-End-Port
(21-163) attributes.
No. Attribute Attribute Description
Type
26-1 HW-NAT-IP- Address Public Network Address Translation (NAT)

61 Address address assigned to a user.
When a BRAS equipped with Carrier Grade
NAT (CGN) boards performs port pre-
allocation or semi-dynamic port allocation,
the BRAS sends accounting packets each
with this attribute to a RADIUS server.


Type
26-1 HW-NAT-Start- Integer Start public port number that has been
62 Port translated from a private port number.
26-1 HW-NAT-End- Integer End public port number that has been
When a BRAS equipped with CGN boards
performs port pre-allocation or semi-
dynamic port allocation, the BRAS sends
accounting packets each with this attribute to
a RADIUS server.
26-1 HW-NAT-Port- Integer Changed port number range. When a BRAS

65 Range-Update performs semi-dynamic port allocation, the
BRAS sends accounting packets each with
this attribute to a RADIUS server.
l NAT444 and public IPv4 or IPv6 users need to be managed in different domains.
The RADIUS server must be able to deliver newly planned domain names to NAT444
users. To support this, the RADIUS server must be able to deliver the HW-Domain-
Name (26-138) attribute and identify NAT444 users by domain.
Type
26-1 HW-Domain- String Name of the domain used for NAT444 user
38 Name authentication, with the RADIUS system
reconstruction involved
l NAT policy.
The following table lists the Huawei-specific attributes supported by the RADIUS server
for delivering NAT policy template names.
Type
26-1 HW-NAT- String NAT policy template delivered in the user

60 Policy-Name authentication response packet.
This template is saved locally.
l Port forwarding attribute.

The following table lists the Huawei-specific attributes supported by the RADIUS server
for delivering port forwarding attributes.


Type
26-1 HW-NAT-Port- String Port forwarding information delivered and

64 Forwarding reported by the RADIUS.
?.2. Log Server
If Syslogs are used on the live network, a Syslog server is required. If Elogs are used on the
live network, an Elog server is required.
NOTE
If session logs in e-log format are required, connect the VSUFs to a Huawei log server.
?.3. Portal Server
Web+Portal authentication is in most cases used for WLAN services. In comparison with
PPPoE services, the portal server implements authentication after address assignment. The
assignment of private IP addresses can prevent automatic address obtaining after the host Wi-
Fi function is enabled but there is not online requirement. As a result, a lot of public IP
addresses are used invalidly. The following figures shows the typical VLAN service process
in CGN scenarios.

Figure 5-54 Typical scenarios of WLAN services in CGN scenarios

BRAS equipped with a
WLAN terminal AP CGN board
AC Portal server AAA server
The AC assigns a
private IPv4 address to
Discovers an AC that manages the AP. the terminal.
DHCP Discovery
1 The AC intercepts and returns the HTTP

DHCP offer
packet that is redirected to the portal
3 authentication page to the user. That is,
2 HTTP access
The private IPv4 address assigned to the WLAN terminal adds the private
the terminal is inserted into the URL. IPv4 address to the HTTP packet.
The terminal sends
a request to
access a web The CGN board converts the
page. private IPv4 address to a public The AC encapsulates the user
IPv4 address and forwards the name and password into a
5 packet to the portal server. Portal packet and the private
IPv4 address obtained from the
On the portal page, the user name and password are entered.
4 HTTP packet into the UserIP
The HTTP packet carries the The Portal protocol is field of the Portal packet. The
The terminal resends a private IPv4 address that the AC forwards the Portal packet
used to send the private
request to access the BRAS assigns to the terminal. 4 to the AAA server for
IPv4 address, user name,
portal authentication After the AC receives the portal and password to the AC. authentication.
page. packet, the AC obtains information,
converts information, such as the Access Request
user name and password, into a
RADIUS authentication packet, 5 Access Accept
and sends the packet to the AAA
The user accesses network resources.
server for authentication.

Authentication results
Authentication results
The AC sends an Accounting
6 Accounting Request (Accounting starts.)
Request packet carrying the
private IPv4 address to the Accounting Response
AAA server.
The user sends a request to log out.
The portal server
sends a logout request.
The AC sends a logout
response packet.
Accounting Request (Accounting ends.)
Accounting Response
The portal server needs to have the following constructions:

l If the AC can actively insert its own IP address in the HTTP URL, the AC must be able
to obtain the "ACip" field to guide traffic return. On the other side, the portal server rust
maintain the table of mapping users' private IPv4 addresses with AC IP addresses.
l The portal server encapsulates the user name and password into portal servers and
abstract private IPv4 addresses from HTTP packets and encapsulate them to the UserIP
field in portal servers. The portal server then obtains the UserIP field in portal packets.
5.9.5.1.3 Deployment Planning
?.1. Port Pre-allocation Scheme
Common Usage Scenarios

l Port range configuration

Based on existing deployment, some users are assigned about 4000 ports. A small port
range that contains insufficient ports may cause some applications, such as P2P
application, to function abnormally, which deteriorates user experience. A port rage that
contains 4096 ports is recommended. A single public IP address mapped to 65536 ports
can be assigned to 15 private network users. To reserve and efficiently use some public
IP addresses, the ratio of 1 public IP address to 14 private IP addresses is recommended.
NOTE
The port range value must be a multiple of 64. A single public IP address is mapped to 65536 ports. The
NE40E&NE80E reserves port numbers 0 to 1023, which cannot be assigned to private network users.
Therefore, set the port range size to 4096 so that a single public IP address can be assigned to a
maximum of 15 private network users.
Other Usage Scenarios

The recommended port range value in the common usage scenario provides insufficient
ports for private network users. Increase the value by increasing the ratio of private IP
addresses to public IP address. A smaller port range value more adversely affects user
experience.
port-range 2048: 30 (private IP addresses):1 (public IP address)
?.2. Public Network Address Pool Scheme
The number of public IP addresses can be calculated based on the specified port-range.
Generally, the number of public IP addresses can be calculated based on the following
formula:
Number of public IP addresses = Number of users for cutover/Ratio of public IP addresses to
private IP addresses
For example, if a total of 28K private users are waiting for service cutover and the port-range
value is 4096 (public-to-private ratio of 1:14), the number of public IP addresses is 2K (28K/
14).
[HUAWEI-nat-instance-nat1-nat-address-group-add-group3] section 2
213.1.1.0 mask 24

213.1.2.0 213.1.2.200

segment.
213.1.3.0 mask 24

segment.


213.1.40.0 213.1.40.20
Configuring multiple public IP address segments for a public address pool us recommended
for a NAT address group, which allows public addresses to be easily added by section.
If a NAT public network address pool is configured using the mask mode (recommended), the
length of the advertised routes is the same as configured. If a NAT public network address
pool is configured using the start-end mode, the length of the advertised routes is 32 bits.
?.3. ACL Matching Scheme
After receiving user traffic, the CGN board performs NAT for the traffic in the following
modes:
l Matching traffic against ACL rules (recommended)
Run the nat outbound acl-number address-group address-group-name command to
specify an ACL and NAT address pool so that only the packets matching the ACL rules
and with a permit action can implement NAT using the allowed public network
addresses.
l Not match ACL rules:
Run the nat outbound any address-group address-group-name command to specify a
NAT address pool so that packets do not need to match ACl rules. By default, addresses
from a specified NAT address pool are used for NAT implementation.
In most cases, you are recommended to configure ACL rules to configure ACL rules so
that private IP addresses matching an ACL rule are translated by NAT to public IP
addresses in the corresponding public address pool. If any (not match ACL rules) is
specified, NAT will be implemented for all the traffic diverted to the service board based
on a specified address pool.
If any (not match ACL rules) is specified for NAT, the CGN device assigns IP addresses from
the same address pool for the all traffic. This fails to be achieved if a carrier plans to allocate
public IP address based on residential areas or regions. Therefore, matching traffic against
ACL rules is recommended for NAT.
As shown in Figure 5-55, the ACL matching mode is used. Specifically, a private IP address
pool is configured, and then NAT is implemented for the private IP addresses in this address
pool. Then the permit network segment and ip pool network segment are matched, and the
ACL rules in the NAT instance huawei1 are bound to the public network group add-group1.

Figure 5-55 Configuration process of ACL matching
ip pool pppoe_nat bas local

Configure a private
gateway 10.3.0.1 255.255.0.0
address. section 0 10.3.0.2 10.3.15.255
Configure an ACL to
acl 2080
import traffic. rule 15 permit source 10.3.0.0 0.0.15.255
Configure an HA
service-location 1
backup group. location slot 1 engine 0 backup slot 4 engine 0
Configure an HA service-instance-group ser-group1

instance group. service-location 1
nat instance huawei1 id 1

Configure basic NAT nat filter mode full-cone
functions. port-range 4096
service-instance-group ser-group1
nat address-group add-group1 group-id 1
section 0 210.210.4.0 mask 24
nat outbound 2080 address-group add-group1
?.4. NAT Scheme
Two NAT modes are available for a NAT444 instance.

NAT in 5-tuple mode is also called symmetric NAT. In this mode, the NAT device
assigns public IP addresses and filters packets based on the combinations of source and
destination IP addresses, source and destination port numbers, and protocol types.
NAT in 3-tuple mode is also called NAT in full-cone mode. In this mode, the NAT device
assigns public IP addresses and filters packets based on the combinations of the source
IP address, source port number, and protocol type.
The symmetric mode has higher network security but cannot support the NAT traversal like
STUN and P2P. The full-cone mode degrades network security but allows more types of
protocol packets to traverse the NAT device. The 3-tuple mode (full-cone mode) is
recommended, whereas the 5-tuple mode (symmetric mode) is used by default. To change the
5-tupe mode to the 3-tuple mode, run the nat filter mode full-cone command in the NAT
instance view.
#
nat filter mode full-cone

?.5. Reliability Scheme
As shown in Table 5-46, distributed NAT444 supports the following backup modes:
l Warm backup
The slave service board only backs up entries in user tables, not in session tables, saved
on the master service board. Warm backup is the default mode. To reduce the solution
complexity, 1:1 master/slave service board backup is recommended.
l Hot backup
The slave service board backs up entries in both user tables and session tables saved on
the master service board. In hot backup, high availability (HA) hot backup must be
enabled. For the procedure of configuring hot backup, see Figure 5-56. Either 1:1
master/slave service board backup or 1+1 load balancing mode can be used to deploy
NAT444 services based on your network plan.
NOTE
If Redundancy User Information (RUI) is not deployed, inter-board warm backup is used. If RUI
is deployed, inter-chassis warm backup is implemented by directly connected chassis.
1+1 load balancing warm or hot backup indicates that two devices implementing 1:1 backup back
up each other.

Figure 5-56 Process of configuring hot backup
Start
Enabling HA Hot HA Backup

Standby Feature
Configuration
HA Backup Between Scenario of HA Backup

Service Boards on a Single Between Two CGN Devices
CGN Device
Creating an HA Creating an HA
Backup Group Backup Group
Configuring Members in the HA

Creating and
Backup Group and Active/Standby
configuring a VRRP
Relationship for the Single CGN
Backup Group
Device
HA Backup
Configuration
Binding an HA Scenarios
Setting the Backup
Backup Group to a
Delay
VRRP Backup Group
Configuring
Setting the Revertive
Association Between
Switching Delay
HA and VRRP
Configuring Service
Instances and Service
Instance Group
HA Service Feature
Configuration
Binding Service
Instances to a
Service Instance
Group
Binding a Service
Instance Group to an
HA Backup Group
Compulsory Step
Optional Step
End

Table 5-46 Distributed NAT444 backup

Deployment Transition Backup Mode Warm Backup Hot Backup
Mode Technique
Distributed NAT444 Inter-board Supported Supported

(recommended)
NAT444 Inter-chassis Supported Supported

(recommended)
?.6. Log Source Tracing Solution
Distributed NAT444 supports the following log formats:

l User log
Logs are recorded only when users go online or offline. Therefore, only a small volume
of log information is generated. The user log mode is used when the semi-dynamic port
segment pre-allocation mode or the port pre-allocation mode is used.
– Configure the user log function and the syslog or NetStream log format.
i. (Optional) Run:
nat syslog descriptive format { cn | type2 | type3 [ local-
timezone ] | type10 }
The Network Address Translation (NAT) syslog log format is set in the system
view.
ii. Run:
nat log user enable [ syslog | netstream ]
The user log function is enabled in the NAT instance view.

iii. Run:
nat log host host-ip-address host-port source source-ip-address
source-port [ name host-name ] [ vpn-instance vpn-instance-name ]
A log host is configured in the NAT instance view.

– Configure the user log function and the Remote Authentication Dial In User Service
(RADIUS) log format.
In port pre-allocation mode, the RADIUS source tracing packets can be sent by
default or using the nat log radius enable command in the system view.
NOTE
When a Carrier Grade NAT (CGN) device uses syslog log information to perform the source
tracing function, run the undo nat log radius enable command to disable the CGN device
from sending RADIUS source tracing packets, which maintains system performance.
l Flow log
Every user flow is logged. This log mode, however, brings a huge volume of log
information.
Configure the flow log function.
a. Run:
The flow log function is enabled in the NAT instance view.
nat log session enable [ elog | syslog ]

b. Run:
nat log host host-ip-address host-port source source-ip-address source-
port [ name host-name ] [ vpn-instance vpn-instance-name ]
c. (Optional) Run:
nat session-log elog-version v2
The device is enabled to send flow logs in version 2 format in the system view.
In distributed NAT444 scenarios, RADIUS user logs are recommended in log source tracing.
?.7. User Management Scheme
l Limit on the number of forward (network-to-user) and reverse (user-to-network)

Network Address Translation (NAT) sessions
The maximum number of NAT sessions that can be established is set. This limit prevents
individual users from occupying excessive session entries. If a user occupies excessive
session entries, NAT connections cannot be established for other users.
a. Run:
nat instance instance-name [ id id ]
The NAT instance view is displayed.

b. Run:
nat session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based forward NAT sessions that can be established
is set.
c. Run:
nat reverse-session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based reverse NAT sessions that can be established
is set.
l Limit on the number of ports
The maximum number of ports that a device can assign to each user can be set. This
function helps prevent port allocation failures stemming from port resource
overconsumption by a specific user.
a. Run:

b. Run:
nat port-limit enable
The user-based port number limit function is enabled.

c. Run:
nat port-limit { tcp | udp | icmp | total } port-number
The maximum number of user-based ports that can be assigned to each user is set.
l Non-NAT service packet processing
You can configure a NAT board to discard non-NAT service packets after the NAT board
receives them.
– Run:
nat session-miss mode drop

The NAT board is enabled to discard non-NAT service packets.

By default, non-NAT service packets are transmitted transparently.
l Limit on the number of NAT users who share a public IP address
Such a maximum number can be set to prevent excessive users from going online using
the same public IP address to cause traffic forwarding failures.
a. Run:
nat instance instance-name id id

b. Run:
nat ip access-user limit max-number
The maximum number of private network users who can get online using the same
public IP address is set.
NOTE
The limit on the number of private network users sharing a public IP address is primarily used
when no port range is specified. Without a port range specified, if a device creates a large number
of NAT sessions for each of private network users sharing a public IP address, user traffic may fail
to be forwarded. As a result, the number of users who attempt to use single public IP addresses to
get online is reduced.
l Rate at which flows for users are created
If a user initiates an attack, for an example, a denial of service (DDoS) attack or
incorrectly initiates an attack on a device, the device creates a great number of links for
the user within a short period of time, which consumes lots of resources, adversely
affecting other user services.
a. Run:

b. Run:
nat user-session create-rate rate
The rate at which packets are sent to create a flow is set.

c. Run:
quit
The system view is displayed.

d. (Optional) Run:
nat flow-defend { forward | reverse | fragment } rate rate slot slot-id
{ engine engine-id | card card-id }
The rate at which the first packet is sent to the CPU of a service board to create a
flow is set.
NOTICE
Set the rate at which packets are sent to create a flow based on the suggestions of
Huawei technique support personnel.
l Port number and range filtering

A port number or range can be specified so that NAT does not translate them, which
prevents packet forwarding failures.
a. Run:

b. Run:
exclude-port { port [ to port ] } & <1–10>
A port number and range are specified.
NOTICE
To maintain network security and prevent viruses, the port number and range filtering
function is configured. Exercise caution when configuring this function because it
adversely affects user access to the Internet.
5.9.5.1.4 Example for Configuring Distributed NAT444
In Figure 5-57, a broadband remote access server (BRAS) is equipped with two NAT444
boards in slots 1 and 9, respectively. The CPUs with ID 0 on the NAT444 boards in slots 1
and 9 perform single-chassis inter-board hot backup for NAT444 services. A Point-to-Point
Protocol over Ethernet (PPPoE) user goes online through the BRAS. The BRAS assigns a
private IP address to the customer premises equipment (CPE). The CPE assigns a private
address range to a PC of the user. Both the CPE and BRAS perform NAT processes for the
user.

Figure 5-57 Typical distributed NAT444 networking
DNS Server RADIUS Server
Internet
CSR1 CSR2
BRAS
CPE1 CPE2
Networking Solution
l Traffic guidance policy: The routes from the public address pool are advertised in
network mode by means of BGP.
l Port allocation policy: The semi-dynamic port allocation mode is used, which allows for
flexible extension of the number of ports.
l Source tracing policy: RADIUS user logs are used to relieve the pressure on BRASs and
the RADIUS server.
l Backup policy: The 1:1 inter-board hot backup is used to achieve reliability of CGN
services.
The roadmap of configuring distributed NAT444 solution is as follows:
1. Apply for the Global Trotter License (GTL) of NAT resources and configure the NAT
session resources of service boards.
2. Configure a RADIUS server group named nat-pppoe-radius.

3. Configure a private address pool named nat-pppoe-pool-1.

4. Create a basic access control list (ACL) to match the private address pool.
5. Configure basic functions of a NAT instance named nat444-1.
6. Configure a distributed NAT traffic distribution policy.
7. Enable the NAT device to advertise public routes.
8. Configure a private network domain and bind it to the NAT instance.
1. Apply for the GTL license of NAT resources and configure the NAT session resources of
service boards.
<BRAS> display license
Item name Item type Value Description
-------------------------------------------------------------
LME0CONN01 Resource 64 Concurrent Users(1k)
LME0NATDS00 Resource 16 2M NAT Session
Item name (View)Resource License Command-line

-------------------------------------------------------------
LME0NATDS00 (Sys)nat session-table size table-size slot slot-id
Master board license state: Normal.

<BRAS> system-view
[BRAS] license
[BRAS-license] active nat session-table size 16 slot 1 engine 0
[BRAS-license] quit
2. Configure a RADIUS server group named nat-pppoe-radius.

[BRAS] radius-server group nat-pppoe-radius
[BRAS-radius-nat-pppoe-radius] radius-server authentication 202.10.10.10 1824
weight 0
[BRAS-radius-nat-pppoe-radius] radius-server accounting 202.10.10.10 1825
weight 0
[BRAS-radius-nat-pppoe-radius] radius-server shared-key huawei@123
[BRAS-radius-nat-pppoe-radius] quit
3. Configure a private network address pool named nat-pppoe-pool-1.

[BRAS] ip pool nat-pppoe-pool-1 bas local
[BRAS-ip-pool-nat-pppoe-pool-1] gateway 10.1.0.1 255.255.0.0
[BRAS-ip-pool-nat-pppoe-pool-1] section 0 10.1.0.2 10.1.0.255
[BRAS-ip-pool-nat-pppoe-pool-1] dns-server 202.103.224.68 202.103.225.68
[BRAS-ip-pool-nat-pppoe-pool-1] quit
NOTE
Considering the number of online private network users, configure an IP address pool and multiple
sections. You can add sections or a new private network address pool for capacity expansion.
4. Create a basic ACL to match the private address pool.
[BRAS] acl number 2011
[BRAS-acl-basic-2011] rule permit source 10.1.0.0 0.0.255.255
[BRAS-acl-basic-2011] quit
5. Configure the basic functions of the NAT instance named nat444-1.

a. Configure a service-location and bind a CPU of a service board to it.
[BRAS] service-location 1
[BRAS-service-location-1] location slot 1 engine 0 backup slot 9 engine 0
[BRAS-service-location-1] quit
b. Create a service instance group.

[BRAS] service-instance-group nat444-group1
[BRAS-service-instance-group-nat444-group1] service-location 1

[BRAS-service-instance-group-nat444-group1] quit
c. Create a NAT instance and bind it to the service instance group nat444-group1 to
specify the associated service board resources.
[BRAS] nat instance nat444-1 id 1
[BRAS-nat-instance-nat444-1] service-instance-group nat444-group1
d. Start the semi-dynamic port allocation mode. Each user is pre-allocated with 4096
ports, with 1024 ports allowed to be incrementally allocated. The allowed number
of incremental allocation times is 3.
[BRAS-nat-instance-nat444-1] port-range 4096 extended-port-range 1024
extended-times 3
e. Configure a private network address pool using the pppoe-public-1 command.

[BRAS-nat-instance-nat444-1] nat address-group pppoe-public-1 group-id 1
f. Configure public IP addresses.

[BRAS-nat-instance-nat444-1-nat-address-group-pppoe-public-1] section 0
171.10.1.0 mask 24
[BRAS-nat-instance-nat444-1-nat-address-group-pppoe-public-1] quit
NOTE
Public IP addresses can be configured in mask mode to advertise user network routes
(UNRs) of the corresponding network segment. In this manner, route convergence is not
required, and UNRs in network segment 171.10.1.0/24 are advertised.
g. Configure a NAT policy.
[BRAS-nat-instance-nat444-1] nat outbound 2011 address-group pppoe-
public-1
h. Enable all application level gateway (ALG) functions, including FTP, PPTP, RTSP,
and SIP ALG.
[BRAS-nat-instance-nat444-1] nat alg all
i. Configure the 3-tuple mode.

[BRAS-nat-instance-nat444-1] nat filter mode full-cone
[BRAS-nat-instance-nat444-1] quit
6. Configure a distributed NAT traffic distribution policy.

a. Configure a user group for online users.
[BRAS] user-group pppoe-nat-1
b. Create an ACL for distributed traffic diversion.

[BRAS] acl 7001
[BRAS-acl-ucl-7001] rule permit ip source user-group pppoe-nat-1
[BRAS-acl-ucl-7001] quit
c. Configure a traffic classifier.

[BRAS] traffic classifier pppoe-nat-1 operator or
[BRAS-classifier-pppoe-nat-1] if-match acl 7001
[BRAS-classifier-pppoe-nat-1] quit
d. Configure a traffic behavior.

[BRAS] traffic behavior pppoe-nat-1
[BRAS-behavior-pppoe-nat-1] nat bind instance nat444-1
[BRAS-behavior-pppoe-nat-1] quit
e. Bind the classifier-behavior (C-B) pair to the global traffic distribution policy.
NOTE
If no traffic policy is globally used, you need to create a traffic policy and apply it in the
system view. If a traffic policy has been configured globally, bind the C-B pair to this traffic
policy. If multiple C-B pairs exist in the global traffic diversion policy, ensure that the
configuration order is from top to down.

[BRAS] traffic policy global-policy

[BRAS-trafficpolicy-global-policy] classifier pppoe-nat-1 behavior pppoe-
nat-1
[BRAS-trafficpolicy-global-policy] quit
7. Enable the NAT device to advertise public routes. In the following example, Border
Gateway Protocol (BGP) is used.
[BRAS] bgp 64640
[BRAS-bgp-64640] network 171.10.1.0 24
[BRAS-bgp-64640] quit
NOTE
The advertised public network routes can use different routing protocols as required. The public IP
address pool routes are advertised in network mode through BGP. If the public network address
pool is configured through masks, the routes can be advertised in network mode. Do not configure
black-hole routes. Otherwise, reverse traffic will be interrupted.
8. Configure a private network domain and bind it to the NAT instance.
[BRAS] aaa
[BRAS-aaa] domain nat-pppoe
[BRAS-aaa-domain-nat-pppoe] ip-pool nat-pppoe-pool-1
[BRAS-aaa-domain-nat-pppoe] user-group pppoe-nat-1 bind nat instance nat444-1
[BRAS-aaa-domain-nat-pppoe] radius-server group nat-pppoe-radius
Verifying the Configuration

# Run the display device command to view the status of the master and slave service boards.
<BRAS> display device
NE40E&NE80E-X16's Device status:
Slot Type Online Register Status Primary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 VSU Present Registered Normal NA
8 LPU Present Registered Normal NA
17 MPU Present NA Normal Master
18 MPU Present Registered Normal Slave
19 SFU Present Registered Normal NA
23 CLK Present Registered Normal Master
24 CLK Present Registered Normal Slave
25 PWR Present Registered Normal NA
27 FAN Present Registered Normal NA
# Run the display ip routing-table command to verify the advertised public routes.
<BRAS> display ip routing-table
-----------------------------------------------------------------
10.1.0.0/16 Unr 61 10 D 127.0.0.1 NULL0

171.10.1.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0
# Run the display service-location command to verify the master and slave status in the
service location.
<BRAS> display service-location 1
service-location 1
Location slot ID: 1 engine ID: 0
Current location slot ID: 1 engine ID: 0

Backup slot ID: 9 engine ID: 0

Current backup slot ID: 9 engine ID: 0
Bound service-instance-group number: 1
Batch-backup state: finished
# Run the display nat session-table size command to verify resources defined in the license.
<BRAS> display nat session-table size
----------------------------------------------------
TotalSize :64M
UsedSize :32 M
FreeSize :32 M
SlotID CpuID CurSessTblSize CfgSessTblSize ValidFlag

1 0(engine) 16 M 16 M Valid
--------------------------------------------------------------------------------
# Run the display nat user-information command to view user table information on the
master and slave service boards.
<BRAS> display nat user-information slot 1 engine 0 verbose
This operation will take a few minutes. Press 'Ctrl+C' to break
Slot: 1 Engine: 0
Total number: 1.
----------------------------------------------------------
User Type : NAT444
CPE IP : 10.1.0.253
User ID : 1132
VPN Instance : -
Address Group : pppoe-public-1
NAT Instance : nat444-1
Public IP : 171.10.1.183
Start Port : 1024
Port Range : 4096
Port Total : 4096
Extend Port Alloc Times : 0
Extend Port Alloc Number : 0
First/Second/Third Extend Port Start : 0/0/0
Total/TCP/UDP/ICMP Session Limit : 8192/10240/10240/512
Total/TCP/UDP/ICMP Session Current : 709/0/709/0
Total/TCP/UDP/ICMP Rev Session Limit : 8192/10240/10240/512
Total/TCP/UDP/ICMP Rev Session Current: 0/0/0/0
Total/TCP/UDP/ICMP Port Limit : 0/0/0/0
Total/TCP/UDP/ICMP Port Current : 709/0/709/0
Nat ALG Enable : ALL
Token/TB/TP : 0/0/0
Port Forwarding Flag : Non Port Forwarding
Port Forwarding Ports : 0 0 0 0 0
Aging Time(s) : -
Left Time(s) : -
Port Limit Discard Count : 0
Session Limit Discard Count : 0
Fib Miss Discard Count : 0
-->Transmit Packets : 5041
-->Transmit Bytes : 2272053
-->Drop Packets : 0
<--Transmit Packets : 3330
<--Transmit Bytes : 1794897
<--Drop Packets : 0
---------------------------------------------------------
Slot: 9 Engine: 0
Total number: 1.
----------------------------------------------------------
User Type : NAT444
CPE IP : 10.1.0.253
User ID : 1132
VPN Instance : -

Address Group : pppoe-public-1

Public IP : 171.10.1.183
Start Port : 1024
Port Range : 4096
Port Total : 4096
Token/TB/TP : 0/0/0
Aging Time(s) : -
Left Time(s) : -
-->Drop Packets : 0
<--Drop Packets : 0
------------------------------------------------------------
# Run the display nat session table command to view session table information on the master
and slave service boards.
<BRAS> display nat session table slot 1
Slot: 1 Engine: 0
Current total sessions: 709.
udp: 10.1.0.253:28195[171.10.1.183:1723]-->*:*
udp: 10.1.0.253:20069[171.10.1.183:1727]--> *:*
udp: 10.1.0.253:59556[171.10.1.183:1085]--> *:*
udp: 10.1.0.253:28384[171.10.1.183:2047]--> *:*
<BRAS> display nat session table slot 9

Slot: 9 Engine: 0
udp: 10.1.0.253:28195[171.10.1.183:1723]-->*:*
udp: 10.1.0.253:20069[171.10.1.183:1727]--> *:*
udp: 10.1.0.253:59556[171.10.1.183:1085]--> *:*
udp: 10.1.0.253:28384[171.10.1.183:2047]--> *:*
# Run the display nat statistics command to view the number of sent and received packets on
the master service board.
<BRAS> display nat statistics received slot 1
Slot: 1 Engine: 0
-------------------------------------------------------------------
Packets received from interface :632014772
Packets received from mainboard :29450
Packets received by nat entry :255587842
receive hrp packets from peer device :0
receive boardhrp packets from peer board :0
-------------------------------------------------------------------
<BRAS> display nat statistics transmitted slot 1
Slot: 1 Engine: 0

--------------------------------------------------------------
Packets transmitted to interface :159142427
Packets transmitted to mainboard :22219
Seclog packets transmitted :0
Syslog packets transmitted :0
Userinfo log msg transmitted to cp :0
Transparent packet with nat :65080312
Transparent packet without nat :0
sessions sent by hrp :0
UserTbl sent by hrp :0
UserTbl sent by Boardhrp :0
sessions sent by Boardhrp :0
--------------------------------------------------------------
5.9.5.1.5 Live Network Deployment Examples
?.1. 1+1 CGN Board Solution Deployment Example
Solution Overview
As shown in Figure 5-58, two CGN boards are inserted into the BRAS chassis, and NAT load
balancing is deployed for common HSI services.
Figure 5-58 1+1 CGN board solution deployment
Internet
CSR1 CSR2
BRAS (CGN)
DSLAM DSLAM
CPE CPE

Configuration Scheme
Table 5-47 1+1 CGN board solution deployment

No Configura Description
. tion
Procedure
1 Configure license
active nat session-table size 16 slot 4 engine 0
the license active nat session-table size 16 slot 14 engine 0
function.
2 Create a acl number 2011

rule permit source 10.1.0.0 0.0.255.255
basic ACL
to match
the private
address
pool.
3 Configure service-location 1
basic service-location 2
functions location slot 14 engine 0 backup slot 4 engine 0
of NAT. service-instance-group nat444-1
service-location 1
service-location 2

port-range 4096
nat address-group pppoe-public-1 group-id 1
section 0 171.10.1.1 mask 24
nat outbound 2011 address-group pppoe-public-1
nat alg all

port-range 4096
section 0 171.10.2.1 mask 24
nat alg all
4 Configure a user-group pppoe-nat-1

user-group pppoe-nat-2
user group.

. tion
Procedure
5 Configure a acl 7001

rule permit ip source user-group pppoe-nat-1
UCL. acl 7002
traffic classifier pppoe-nat-1 operator or

if-match acl 7001
if-match acl 7002
traffic behavior pppoe-nat-1

nat bind instance nat444-1
traffic policy global-policy

classifier pppoe-nat-1 behavior pppoe-nat-1
6 Configure bgp 64640

network 171.10.1.0 24
BGP to network 171.10.2.0 24
advertise
public
network
routes.
7 Specify the aaa

domain nat-pppoe
domain to authentication-scheme radius
which users accounting-scheme acct-radius
belong. ip-pool nat-pppoe-pool-1
user-group pppoe-nat-1 bind nat instance nat444-1
radius-server group rad-server
?.2. 2:1 CGN Board Solution Deployment Example
Solution Overview
As shown in Figure 5-59, service board 14 is newly added in slot 13 to expand the capacity in
response to soaring traffic. In this solution, service board 4 is the master one, and service
board 14 is the slave one.

Figure 5-59 2:1 CGN board solution deployment
Internet
CSR1 CSR2
BRAS (CGN)
DSLAM DSLAM
Table 5-48 2:1 CGN board deployment configuration

. tion
Procedure
1 Configure license
function. active nat session-table size 16 slot 13 engine 0

basic ACL
to match
the private
address
pool.

. tion
Procedure
basic service-location 2
functions of location slot 13 engine 0 backup slot 14 engine 0
NAT.
service-location 1
service-location 2

port-range 4096
section 0 171.10.1.0 mask 24
nat alg all

port-range 4096
section 0 171.10.2.0 mask 24
nat alg all

user group.
5 Configure a
acl 7001
UCL. rule permit ip source user-group pppoe-nat-1
acl 7002

if-match acl 7001
if-match acl 7002



network 171.10.1.0 24
advertise
public
network
routes.

. tion
Procedure
7 Specify the aaa

domain nat-pppoe
domain to ip-pool nat-pppoe-pool-1
which users user-group pppoe-nat-1 bind nat instance nat444-1
belong. user-group pppoe-nat-2 bind nat instance nat444-2
?.3. 2+1 CGN Board Solution Deployment Example
Solution Overview
As shown in Figure 5-60, service board 14 is newly added in slot 13 to expand the capacity in
response to soaring traffic. In this solution, service boards 4 and 14 back up each other.
Figure 5-60 2+1 CGN board solution deployment
Internet
CSR1 CSR2
BRAS (CGN)
DSLAM DSLAM

Table 5-49 2+1 CGN board solution deployment

. tion
Procedure
1 Configure license
function. active nat session-table size 16 slot 13 engine 0

basic ACL
to match
the private
address
pool.
3 Configure a service-location 1
NAT service-location 2
instance. location slot 14 engine 0 backup slot 4 engine 0
service-location 3
service-location 1
service-location 2
service-location 3

port-range 4096
nat alg all

port-range 4096
nat alg all

port-range 4096
nat alg all

user group. user-group pppoe-nat-3

. tion
Procedure
5 Configure acl 7001

UCL. acl 7002
acl 7003

if-match acl 7001
if-match acl 7002
if-match acl 7003



network 171.0.1.0 24
advertise network 171.0.3.0 24
public
network
routes.
7 Specify the aaa

domain nat-pppoe
domain to ip-pool nat-pppoe-pool-1
which users user-group pppoe-nat-1 bind nat instance nat444-1
belong. user-group pppoe-nat-2 bind nat instance nat444-2
?.4. NAT444+CoA Solution Deployment in Load Balancing Mode Example
Solution Overview
As shown in Figure 5-61, NAT444+CoA is deployed on HSI services, and two VSUF-80s are
installed on the BRAS to achieve CGN load balancing.

Figure 5-61 NAT444+CoA in load balancing mode
Internet
CSR1 CSR2
BRAS (CGN)
DSLAM DSLAM
CPE CPE
Table 5-50 Deployment configuration of NAT444+CoA in load balancing mode

. tion
Procedure
1 Configure license
function.

. tion
Procedure
basic
functions service-location 2
of NAT. location slot 14 engine 0 backup slot 10 engine 0
service-instance-group nat-1
service-location 1
service-location 2
acl number 2050

rule 5 permit source 172.16.0.0 0.0.255.255
nat instance nat-1 id 1

port-range 4096
nat address-group nat-public-1 group-id 1
section 0 125.41.249.0 mask 24
nat outbound 2050 address-group nat-public-1
nat alg all
nat instance nat-2 id 2

port-range 4096
nat address-group nat-public-2 group-id 2
section 0 125.41.250.0 mask 24
nat outbound 2050 address-group nat-public-2
nat alg all
3 Configure a user-group nat_user_1

user-group nat_user_2
user group. user-group nat_coa

. tion
Procedure
4 Configure a acl number 7001

rule permit ip source user-group nat_user_1
UCL.
acl number 7002
rule permit ip source user-group nat_user_2
traffic classifier nat_user_1 operator or

if-match acl 7001
traffic classifier nat_user_2 operator or

if-match acl 7002
traffic behavior nat_user_1

nat bind instance nat-1
traffic behavior nat_user_2

acl number 8010

rule 5 permit tcp source user-group nat_coa destination ip-
address 220.0.150.124 0
rule 10 permit ip source user-group nat-coa destination ip-
address 220.0.150.103 0
acl number 8011

rule 5 permit tcp source user-group nat_coa destination-port
eq www
rule 10 permit tcp source user-group nat_coa destination-
port eq 8080
acl number 8012

rule 5 permit ip source user-group nat_coa destination ip-
address any
traffic classifier traffic-nat-permit operator or

if-match acl 8010
traffic classifier traffic-nat-redirect operator or

if-match acl 8011
traffic classifier traffic-nat-deny operator or

if-match acl 8012
traffic behavior traffic-nat-permit

traffic behavior traffic-nat-redirect

http-redirect
traffic behavior traffic-nat-deny

deny

classifier nat_user_1 behavior nat_user_1
classifier nat_user_2 behavior nat_user_2
classifier traffic-nat-permit behavior traffic-nat-permit
classifier traffic-nat-redirect behavior traffic-nat-redirect
classifier traffic-nat-deny behavior traffic-nat-deny

. tion
Procedure

network 125.41.249.0 24
advertise
public
network
routes.
6 Specify the ip pool nat-private-1 bas locall

gateway 172.16.0.1 255.255.0.0
domain to section 0 172.16.0.1 172.16.255.254
which users dns-server 202.102.224.68 202.102.227.68
belong.
aaa
http-redirect enable
domain nat
authentication-scheme radius
accounting-scheme cy-accountingtime
ip-pool nat-private-1
user-group nat_user_1 bind nat instance nat-1
user-group nat_user_2 bind nat instance nat-2
radius-server group nat
web-server 221.13.223.133 //Specify the IP address of
the server that forcibly displays the CoA web page.
web-server url http://www.sample.cn/pushportal //Specify
the URL of the CoA web page.
domain nat_coa //Bind the filter-id attribute delivered
by COA to a separate domain.
user-group nat_coa bind nat instance nat-1 //Bind
the filter-id attribute delivered by COA to a NAT instance.
?.5. Master/Slave NAT444+DAA Solution Deployment Example
Solution Overview
As shown in Figure 5-62, NAT444 over DAA is deployed on HSI services, and inter-board
warm backup 1:1 is used to achieve NAT backup.

Figure 5-62 Master/slave NAT444+DAA solution deployment
Internet
CSR1 CSR2
BRAS (CGN)
DSLAM DSLAM
CPE CPE
Table 5-51 Master/slave NAT444+DAA deployment configuration

. tion
Procedure
1 Configure license
function.

. tion
Procedure
basic
functions service-instance-group 1
of NAT. service-location 1
acl number 2011

nat instance nat444_1 id 1

port-range 4096
nat address-group address-group1 group-id 1
section 0 171.10.1.0 mask 24
nat outbound 2011 address-group address-group1
nat alg all
2 Configure user-group nat444_1

user-group nat444_daa //Identify DAA users in the DAA
the DAA template.
service
function. value-added-service enable //Enable DAA.
qos-profile qos-prof10m //Run this command on an LPUA to

speed up the access speed in the DAA template.
car cir 10486 cbs 1960882 green pass red discard inbound
car cir 10486 cbs 1960882 green pass red discard outbound
value-added-service policy vp_default daa //Configure a

default DAA template.
user-group nat444_1 bind nat instance nat444_1 //Configure
the same user group as that in the domain.
accounting-together enable
traffic-separate enable
accounting-service-policy inbound auto
accounting-service-policy outbound auto
value-added-service policy nat444_1_daa daa //Configure the

DAA template for value-added services.
user-group nat444_daa bind nat instance nat444_1 //If a
user is assigned this DAA template, the user group to which
the user belongs uses the configuration in the DAA template.
traffic-separate enable
tariff-level 5 qos-profile qos-prof10m
tariff-level 5 flow-queue-shaping inbound 10486 outbound
10486
3 Configure a aaa
domain private_dual
user group authentication-scheme radius
and bind a accounting-scheme radius
NAT ip-pool nat444_pool
value-added-service account-type none
instance to value-added-service policy vp_default //Configure a default
the user DAA template, which only changes the user attribute to DAA
group. and does not limit the access rate.
radius-server group radius_ipv6
user-group nat444_1 bind nat instance nat444_1

. tion
Procedure
4 Configure acl number 7301

description DAA-NAT444
traffic rule 0 permit ip source user-group nat444_daa destination ip-
diversion. address 183.56.x.x 0.0.0.255
rule 5 permit ip source ip-address 183.56.x.x 0.0.0.255
destination user-group nat444_daa
acl number 7302

description DAA-NAT444-any
rule 0 permit ip source user-group nat444_daa destination any
rule 5 permit ip source any destination user-group nat444_daa
//Match packets of users who do not access the website that
provides a higher access rate.
acl number 9301

description DAA-nat444_1-default
rule 0 permit ip source user-group nat444_1
traffic classifier daa-tianyiyun operator or

if-match acl 7301
traffic classifier daa-tianyiyun-any operator or
if-match acl 7302
traffic classifier nat444_1_daa_any operator or
if-match acl 9301
traffic behavior nat444_1_daa

nat bind instance nat444_1
tariff-level 5
car
traffic-statistic
traffic behavior nat444_1_daa_any

nat bind instance nat444_1
traffic policy daa

share-mode
classifier daa behavior nat444_1_daa
classifier daa-any behavior nat444_1_daa_any
classifier nat444_1_daa_any behavior nat444_1_daa_any
accounting-service-policy daa //Apply the DAA policy.

traffic-policy daa inbound
5 Configure N/A
route
summary
for a public
route
group,
enable the
device to
advertise
public
routes, and
filter
private
routing
information
.

?.6. Example for Deploying the Distributed NAT444 Inter-chassis Hot Backup Solution
Solution Overview
As shown in Figure 5-63, NAT+RUI is deployed on common HSI services, and the CGN
board uses a combination of 1:1 inter-chassis hot backup, VRRP and BFD protocol to
determine the master/slave CGN, achieving high reliability.
Figure 5-63 Deployment of the distributed NAT444 inter-chassis hot backup solution
CR1 CR2
GE6/0/0 GE6/0/0
GE7/0/0 GE7/0/0
CGN1 CGN2
GE5/0/0 GE5/0/0

Table 5-52 Configuration for the deployment of the distributed NAT444 inter-chassis hot
backup solution
N Config Configuration on the Master Configuration on the Slave
o. uratio Device (CGN1) Device (CGN2)
n
Proced
ure
1 Allocat license license

active nat session-table size active nat session-table size
e 6 slot 9 engine 0 6 slot 9 engine 0
resourc
es to
NAT
session
s
2 Create user-group nat444-rui user-group nat444-rui

a user
group.
3 Enable service-ha hot-backup enable service-ha hot-backup enable

hot-
standby
backup
4 Config interface interface

GigabitEthernet7/0/0.11 GigabitEthernet7/0/0.11
ure the undo shutdown undo shutdown
VRRP vlan-type dot1q 2 vlan-type dot1q 2
master/ ip address 218.201.100.42 ip address 218.201.100.43
255.255.255.248 255.255.255.248
slave vrrp vrid 11 virtual-ip vrrp vrid 11 virtual-ip
relation 218.201.100.41 218.201.100.41
ship for admin-vrrp vrid 11 ignore-if- admin-vrrp vrid 11 ignore-if-
down down
interme vrrp vrid 11 priority 200 vrrp vrid 11 priority 150
diate vrrp vrid 11 preempt-mode vrrp vrid 11 track service-
links. timer delay 600 location 1 reduced 60
vrrp vrid 11 track interface
GigabitEthernet6/0/0 reduced 60
vrrp vrid 11 track interface
GigabitEthernet5/0/0.1 reduced
60
vrrp vrid 11 track service-
location 1 reduced 60


n
Proced
ure
5 Create service-location 1 service-location 1

location slot 9 engine 0 location slot 9 engine 0
an HA remote-backup interface remote-backup interface
backup GigabitEthernet7/0/0.11 peer GigabitEthernet7/0/0.11 peer
group 218.201.100.43 218.201.100.42
vrrp vrid 11 interface vrrp vrid 11 interface
on GigabitEthernet7/0/0.11 GigabitEthernet7/0/0.11
CGN1
and
CGN2,
add
member
s to the
group,
and
configu
re a
VRRP
backup
channel
.
6 Create service-instance-group nat444- service-instance-group nat444-

rui rui
a service-location 1 service-location 1
service
instance
group
on
CGN1
and
CGN2
and
bind it
to the
HA
backup
group.
7 Create ip pool pool-nat444-rui-1 bas ip pool pool-nat444-rui-1 bas

local local
a public
address gateway 10.5.0.1 gateway 10.5.0.1
pool. 255.255.0.0 255.255.0.0
section 0 10.5.0.2 section 0 10.5.0.2
10.5.255.254 10.5.255.254
dns-server 218.201.100.132 dns-server 218.201.100.132
218.201.100.3 218.201.100.3


n
Proced
ure
8 Config acl number 2051 acl number 2051

description for nat444-rui description for nat444-rui
ure rule 5 permit source 10.5.0.0 rule 5 permit source 10.5.0.0
private 0.0.255.255 0.0.255.255
IP
address
es to
match
the
ACL.
9 Config acl number 6200 acl number

rule 10 permit ip source user- 6200
ure group nat444-rui
UCLs
and rule 10 permit ip source user-
group nat444-rui
UCL
rules.
10 Create nat instance nat444-rui id 1 nat instance nat444-rui id 1

nat filter mode full-cone nat filter mode full-cone
a NAT port-range 4096 port-range 4096
instance service-instance-group nat444- service-instance-group nat444-
on rui rui
nat address-group nat444-rui nat address-group nat444-rui
CGN1 group-id 1 group-id 1
and section 0 183.100.184.0 mask section 0 183.100.184.0 mask
CGN2 22 22
section 1 183.100.188.0 mask section 1 183.100.188.0 mask
and 22 22
bind it nat outbound 2051 address- nat outbound 2051 address-
to the group nat444-rui group nat444-rui
service nat alg all nat alg all
instance
group.
11 Config traffic classifier nat444-rui traffic classifier nat444-rui

operator operator
ure or or
traffic
policy. if-match acl if-match acl
6200 6200
traffic behavior nat444-rui

nat bind instance nat444-rui traffic behavior nat444-rui
nat bind instance nat444-rui
traffic policy wlan_pre

share-mode traffic policy wlan_pre
classifier nat444-rui behavior share-mode
nat444-rui classifier nat444-rui behavior
nat444-rui


n
Proced
ure
12 Config radius-server group rad-group1 radius-server group rad-group1

radius-server authentication radius-server authentication
ure a 218.100.22.7 1812 weight 0 218.100.22.7 1812 weight 0
RADIU radius-server accounting radius-server accounting
S server 218.100.22.7 1813 weight 0 218.100.22.7 1813 weight 0
radius-server shared-key-ciper radius-server shared-key-ciper
group. huawei@123 huawei@123
radius-server class-as-car radius-server class-as-car
radius-server source interface radius-server source interface
LoopBack0 LoopBack0
undo radius-server user-name undo radius-server user-name
domain-included domain-included
13 Specify aaa aaa

the
domain
to domain nat444-rui domain nat444-rui
authentication-scheme auth1 authentication-scheme auth1
which accounting-scheme accounting-scheme
the user acct1 acct1
belongs
. ip-pool pool-nat444- ip-pool pool-nat444-
rui-1 rui-1
radius-server group rad- radius-server group rad-

group1 group1
user-group nat444-rui bind user-group nat444-rui bind
nat instance nat444-rui nat instance nat444-rui
14 Config interface GigabitEthernet5/0/0.1 interface GigabitEthernet5/0/0.1

vlan-type dot1q 2 vlan-type dot1q 2
ure a ip address 10.72.16.252 ip address 10.72.16.253
VRRP 255.255.255.0 255.255.255.0
interfac vrrp vrid 1 virtual-ip vrrp vrid 1 virtual-ip
10.72.16.254 10.72.16.254
e. admin-vrrp vrid 1 admin-vrrp vrid 1
vrrp vrid 1 priority 200 vrrp vrid 1 priority 150
vrrp vrid 1 preempt-mode timer vrrp vrid 1 track interface
delay 600 GigabitEthernet6/0/0 reduced 100
vrrp vrid 1 track interface vrrp vrid 1 track bfd-session
GigabitEthernet6/0/0 reduced 60 2000 peer
vrrp vrid 1 track bfd-session vrrp vrid 1 track service-
1000 peer location 1
location 1 reduce 60
15 Config remote-backup-service backup remote-backup-service backup

peer 218.100.3.28 source peer 218.100.3.27 source
ure 218.100.3.27 port 10000 218.100.3.28 port 10000
RBS. track bfd-session 1000 track bfd-session 2000
track interface track interface
GigabitEthernet6/0/0 GigabitEthernet6/0/0
protect redirect ip-nexthop protect redirect ip-nexthop
218.201.100.43 interface 218.201.100.42 interface


n
Proced
ure
16 Config remote-backup-profile backup remote-backup-profile backup

service-type bras service-type bras
ure backup-id 1 remote-backup- backup-id 1 remote-backup-
RBP. service backup service backup
peer-backup hot peer-backup hot
vrrp-id 1 interface vrrp-id 1 interface
nas logic-ip 218.100.3.27 nas logic-ip 218.100.3.27
17 Config interface interface GigabitEthernet5/0/0.3

GigabitEthernet5/0/0.3 user-vlan 2001 2019
ure an user-vlan 2021 2100
interfac user-vlan 2001 2019 remote-backup-profile backup
e user-vlan 2021 2100 description nat444-rui
remote-backup-profile backup bas
through description nat444-rui access-type layer2-
which bas subscriber default-domain
the user access-type layer2- authentication nat444-rui
subscriber default-domain
goes authentication nat444-rui
online.
18 Config N/A N/A

ure
route
aggrega
tion of
public
IP
address
es,
public
route
advertis
ement,
and
filtering
of
private
network
routes.
5.9.5.2 Centralized NAT444 Solution Deployment Guide

In Figure 5-64, if the BRAS and CGN functions cannot be integrated on a device, a CGN
device can be separately deployed on a CR or SR in standalone mode. The CPE dials up and
gets online through the BRAS, and the BRAS assigns an IP address to the CPE. When a PC
attempts to access an external network, the CPE performs NAT for the user PC's IP address,
and the CGN device also performs NAT for the CPE's IP address. Then packets are routed to
the CR, and the CR forwards them to the ISP core network. In the preceding scenario, two
NAT operations are performed, and CGN is deployed on the CR. This networking shows a
typical centralized NAT444 solution.
Figure 5-64 Centralized NAT444 solution based on port pre-allocation

PC1
192.168.1.2 Manages the User IP:10.10.10.12
10.10.0.0 network NAT IP:125.3.12.25
10.10.10.12 segment. Port-range:2048-6143
CPE1 BRAS1
Access
network Syslog
NE (CGN)
server
PC2
192.168.1.3
ISP core
PC3
192.168.2.2
CR
10.20.10.12
CPE2 DHCP Web
User IP:10.20.10.12
Access server server
NAT IP:121.22.22.52
network
BRAS2
Manages the
10.20.0.0 network
PC4 segment.
192.168.2.3
Address Assignment Scheme

A BRAS assigns a private IP address to the CPE, and the CPE assigns an IP address to a PC.
A CGN device assigns a public IP address and port range to the CPE.
NAT Process
The CPE performs NAT for packets sent by the PC and translates the PC's IP address
192.168.1.2/32 to the CPE's IP address 10.10.10.12. After receiving the packets forwarded by
the CPE, the CGN device also performs NAT for them and translates the CPE's IP address
10.10.10.12 to a public IP address 125.3.12.25.
?.1. License Support

Table 5-53 shows license information related to VSUF-80s or VSUF-160s.

NE40E&NE80E PCP Board PCP is not supported by default. To

function license enable PCP, run the following
command:
[HUAWEI] license
vsuf slot 1

NE40E&NE80E 20 Gbit/s VSUF-40/80/160 l A VSUF-40 supports the 40

capacity license mother board CPU Gbps forwarding capacity
following command:
[HUAWEI] license
engine 0

Gbps forwarding capacity
provides a mother board CPU for
a subcard. Each CPU supports
40 Gbps bandwidth, and a
mother board CPU supports 20
Gbps forwarding bandwidth by
command:
[HUAWEI] license
engine 0

Gbps forwarding capacity and
provides two mother board
CPUs for two subcards. Each
bandwidth, and a mother board
forwarding bandwidth by
command:
[HUAWEI] license
engine 0

NE40E&NE80E NAT Board's mother By default, the maximum number of

session number license board or subcard session tables on a VSUF-40,
CPU VSUF-80 or VSUF-160 CPU is
zero. In addition, a board only
assigns an even number of session
resources of the CPU, in millions.
On a VSUF-40/80/160, a CPU
supports a maximum of 16 millions
NAT sessions. On a VSUI-160-E, a
CPU supports a maximum of 32
millions NAT sessions. To assign
the maximum number of NAT
sessions on a mother board or
subcard CPU, run the following
command:
[HUAWEI] license
engine 0

Product Version
NE40E&NE80E V600R009C10
iManager U2000
Power consumption


NOTE
installed.
Subcard Application
VSUF-160.
NOTE


(Gbit/s) with
Subcards
(Gbit/s)
200 NE40 VSUF 40/40/80 25/25/50 NA/80/160 NA/50/100

Gbit/s E&NE -40/80
platfor 80E- /160
m X8
NE40
E&NE
80E-
X16
40 NE40 VSUF 40 25 NA/80 NA/50

Gbit/s E&NE -40/80
platfor 80E-
m X8
NE40
E&NE
80E-
X16
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-
X3
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-1
6
20 NE40 VSUF 15 15 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-8
m
10 NE40 VSUF 10 10 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-1
m 6

Log Server
When source tracing is required, the source tracing system needs to identify the log packets
sent by the CGN device and specify the log format. When source tracing is not required, the
source tracing system does not need to be reconstructed. If a CGN device is configured to
support syslogs, a new syslog server needs to be added. If the CGN device is configured to
support elogs, an elog server needs to be added.

NOTE
If the CGN device is configured to support session logs in e-log format, the CGN device needs to be
connected to a Huawei log server.
?.1. Design Solution to Port Pre-allocation

NOTE

experience.
formula:
Number of public IP addresses = Number of users for cutover/Ratio of public IP addresses to
private IP addresses
For example, if a total of 28K private users are waiting for service cutover and the port-range
value is 4096 (public-to-private ratio of 1:14), the number of public IP addresses is 2K (28K/
14).

213.1.1.0 mask 24

213.1.2.0 213.1.2.200

segment.
213.1.3.0 mask 24

segment.
213.1.40.0 213.1.40.20
Configuring multiple public IP address segments for a public address pool us recommended
for a NAT address group, which allows public addresses to be easily added by section.
If a NAT public network address pool is configured using the mask mode (recommended), the
length of the advertised routes is the same as configured. If a NAT public network address
pool is configured using the start-end mode, the length of the advertised routes is 32 bits.
After receiving user traffic, a CGN board performs NAT for traffic in the following modes:

Run the nat outbound acl-number address-group address-group-name command to
specify an ACL and NAT address pool so that only the packets matching the ACL rules
and with a permit action can implement NAT using the allowed public network
addresses.
l Not match ACL rules
Run the nat outbound any address-group address-group-name command to specify a
NAT address pool so that packets do not need to match against ACL rules. By default,
addresses from a specified NAT address pool are used for NAT implementation.
that private IP addresses matching an ACL rule are translated by NAT to public IP
specified, NAT will be implemented for all the traffic diverted to the service board based
on a specified address pool.
If any (not match ACL rules) is specified for NAT, the CGN device assigns IP addresses from
the same address pool for the all traffic. This fails to be achieved if a carrier plans to allocate
public IP address based on residential areas or regions. Therefore, matching traffic against
ACL rules is recommended for NAT.
In Figure 5-65, a user pre-allocates a private network segment of 10.3.1.0/24 and configures a
ACL to match against packets with the private network segment address for NAT translation
on a CGN device. The CGN device matches a network segment allowed in the ACL against
the private network segment. The CGN device then forwards packets matching the ACL to a
specified public address group in the NAT instance view.

Configure an ACL to
acl 2080
import traffic. rule 15 permit source 10.3.0.0 0.0.0.255
Configure an HA
service-location 1
Configure an HA service-instance-group ser-group1

nat instance huawei1 id 1

Configure basic DS- nat filter mode full-cone
Lite functions. port-range 4096
service-instance-group ser-group1
nat address-group add-group1 group-id 1
section 0 210.210.4.0 mask 24
nat outbound 2080 address-group add-group1
?.4. NAT Scheme

protocol packets to traverse the NAT device. The 3-tuple mode (full-cone mode) is
5-tupe mode to the 3-tuple mode, run the nat filter mode full-cone command in the NAT
instance view.
#
As shown in Table 5-56, centralized NAT444 supports the following backup modes:

l Cold backup
The slave service board does not back up entries in user tables or session tables saved on
the master service board. The cold backup mode is used by default. To reduce the
solution complexity, 1:1 master/slave service board backup is recommended.
l Hot backup
the master service board. When hot backup is used, high availability (HA) hot backup
must be enabled. For the procedure of configuring hot backup, see Figure 5-66. Either
1:1 master/slave service board backup or 1+1 load balancing mode can be used to deploy
NAT444 services based on your network plan.

Figure 5-66 Process of configuring hot backup
Start

Standby Feature
Configuration

CGN Device

Creating and
configuring a VRRP
Backup Group
Device
HA Backup
Configuration
Setting the Backup
Backup Group to a
Delay
VRRP Backup Group
Configuring
Association Between
Switching Delay
HA and VRRP
Configuring Service
Instance Group
HA Service Feature
Configuration
Binding Service
Instances to a
Service Instance
Group
Binding a Service
HA Backup Group
Compulsory Step
Optional Step
End

Table 5-56 Centralized NAT444 backup

Deployment Evolution Backup Mode Cold Backup Hot Backup
Mode Technique
Centralized (a NAT444 Inter-board Supported Supported

CGN device or
a CGN board NAT444 Inter-chassis Supported Supported
installed on a
BRAS)
Centralized NAT444 supports the following log formats in source tracing:

l User log
Configure the user log function.
a. (Optional) Run:
nat syslog descriptive format { cn | type2 | type3 [ local-timezone ] |
type10 }
The syslog log format is set in the system view.

b. Run:
The user log function is enabled in the NAT instance view.

c. Run:

l Flow log
information.
a. Run:
nat log session enable [ elog | syslog ]
The flow log function is enabled in the NAT instance view.

b. Run:

c. (Optional) Run:
nat session-log elog-version
v2

In centralized NAT444 scenarios, syslog logs are recommended in log source tracing.
?.7. User Management Solution

Network Address Translation (NAT) sessions
The maximum number of NAT sessions that can be established is set. This limit prevents
individual users from occupying excessive session entries. If a user occupies excessive
session entries, NAT connections cannot be established for other users.
a. Run:

b. Run:
nat session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based forward NAT sessions that can be established
is set.
c. Run:
nat reverse-session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based reverse NAT sessions that can be established
is set.
l Limit on the number of ports
a. Run:

b. Run:
nat port-limit enable

c. Run:
nat port-limit { tcp | udp | icmp | total } port-number
l Non-NAT service packet processing
You can configure a NAT board to discard non-NAT service packets after the NAT board
receives them.
– Run:
The NAT board is enabled to discard non-NAT service packets.

By default, non-NAT service packets are transmitted transparently.
l Limit on the number of NAT users who share a public IP address
a. Run:
nat instance instance-name id id


b. Run:
nat ip access-user limit max-number
public IP address is set.
NOTE
l Rate at which flows for users are created
If a user initiates an attack, for an example, a denial of service (DDoS) attack or
incorrectly initiates an attack on a device, the device creates a great number of links for
the user within a short period of time, which consumes lots of resources, adversely
affecting other user services.
a. Run:

b. Run:
nat user-session create-rate rate

c. Run:
quit

d. (Optional) Run:
flow is set.
NOTICE

A port number or range can be specified so that NAT does not translate them, which
a. Run:

b. Run:

NOTICE
5.9.5.2.4 Example for Configuring Centralized NAT444
Networking Diagram
In Figure 5-67, a Carrier Grade NAT (CGN) device is attached to a core router (CR) and
equipped with two service boards in slots 1 and 9, respectively. The CPUs with ID 0 on the
NAT444 boards in slots 1 and 9 perform single-chassis inter-board hot backup for NAT444
services. A broadband remote access server (BRAS) assigns the customer premises equipment
(CPE) three private IP address segments: 10.0.0.0/20, 10.0.16.0/20, and 10.0.32.0/20. A user
PC with IP address 192.168.1.1 accesses the Internet. CPE1 uses NAT44 to translate the PC's
IP address to 10.0.1.253 in user packets. After the CR directs the user packets to the CGN
device, the CGN device also performs NAT to translate 10.0.1.253 to 171.10.40.183 and
forwards the user packets to the Internet.
Figure 5-67 Typical centralized NAT444 networking

Syslog Server
10.78.10.91:514
CGN
PC GE2/0/0
192.168.1.1/32 CPE1 100.100.100.2
192.168.1.1:101- GE1/0/0
>10.0.0.1:1025 100.100.100.1
PC CPE2 BRAS CR
CR
192.168.2.1/32 192.168.2.1:100-
>10.0.16.1:1025
CPE3
PC 192.168.3.1:102-
>10.0.32.1:1025
192.168.3.1/32
Networking Solution
l Traffic guidance policy: The routes from the public address pool are advertised in
network mode by means of BGP.
l Port allocation policy: The semi-dynamic port allocation mode is used, which allows for
flexible extension of the number of ports.
l Source tracing policy: Syslogs are used to relieve the pressure on CGN devices and the
Syslog server.
l Backup policy: The 1:1 inter-board hot backup is used to achieve reliability of CGN
services.

The configuration roadmap is as follows:
1. Apply for a Global Trotter License (GTL) for NAT resources and assigns resources of 16
million NAT sessions to service boards.
2. Enable high availability (HA) hot backup.
3. Create a NAT instance and bind it to a service instance group.
4. Configure a NAT traffic distribution policy to distribute user traffic to NAT boards.
6. Configure the NAT log function.
7. Enable the NAT device to advertise public routes.
1. Apply for a GTL license for NAT resources and assigns resources of 16 million NAT
sessions to service boards.
<HUAWEI> display license
.....
-------------------------------------------------------------
LCR5NATDS00 Resource 32 2M NAT Session

LME04020G00 Resource 32 20G NAT BandWidth
[HUAWEI] sysname CGN

[CGN] License
[CGN-license] active nat session-table size 16 slot 1 engine 0
[CGN-license] quit
2. Enable HA hot backup.

[CGN] service-ha hot-backup enable
3. Create a NAT instance and bind it to a service instance group.

[CGN] service-location 1
[CGN-service-location-1] location slot 1 engine 0 backup slot 9 engine 0
[CGN-service-location-1] quit
[CGN] service-instance-group nat444-1
[CGN-instance-group-nat444-1] service-location 1
[CGN-instance-group-nat444-1] quit
[CGN] nat instance nat444-1 id 1
[CGN-nat-instance-nat444-1] service-instance-group nat444-1
[CGN-nat-instance-nat444-1] quit
4. Configure a NAT traffic distribution policy to distribute user traffic to NAT boards.
a. Configure an ACL rule.
[CGN] acl number 3011
[CGN-acl-adv-3011] rule 0 permit ip source 10.0.0.0 0.0.15.255
[CGN-acl-adv-3011] quit
NOTE
The number of private network users assigned public IP addresses must be greater than the
number of private IP addresses defined in an ACL. A total of 12,288 (48 x 256) private IP
addresses can be defined in an ACL.
b. Configure a traffic classifier.
[CGN] traffic classifier nat444-1 operator or

[CGN-traffic-classifier-nat444-1] if-match acl 3011

[CGN-traffic-classifier-nat444-1] quit
c. Configure a traffic behavior.

[CGN] traffic behavior nat444-1
[CGN-traffic-behavior-nat444-1] nat bind instance nat444-1
[CGN-traffic-behavior-nat444-1] quit
d. Configure a traffic distribution policy.

[CGN] traffic policy nat444-1
[CGN-traffic-policy-nat444-1] classifier nat444-1 behavior nat444-1
[CGN-traffic-policy-nat444-1] quit
e. Bind the traffic distribution policy named nat444-1 to an inbound interface of the
CGN device.
[CGN] interface GigabitEthernet 2/0/0
[CGN-GigabitEthernet2/0/0] ip address 100.100.100.2 255.255.255.0
[CGN-GigabitEthernet2/0/0] traffic-policy nat444-1 inbound
[CGN-GigabitEthernet2/0/0] quit

[CGN] nat instance nat444-1 id 1
[CGN-nat-instance-nat444-1] port-range 4096 extended-port-range 1024 extended-
times 3
[CGN-nat-instance-nat444-1] nat address-group nat444-1 group-id 1
[CGN-nat-instance-nat444-1-nat-address-group-nat444-1] section 0 171.10.40.0
mask 24
mask 24
mask 24
mask 24
NOTE
In the design solution to port pre-allocation, the recommended ratio of public IP addresses to
private IP addresses is 1:14. Therefore, public IP addresses can be used by 14,336 (4 x 256 x 14)
users.
[CGN-nat-instance-nat444-1-nat-address-group-nat444-1] quit
[CGN-nat-instance-nat444-1] nat outbound 3011 address-group nat444-1
[CGN-nat-instance-nat444-1] nat alg all
[CGN-nat-instance-nat444-1] nat filter mode full-cone
6. Configure the NAT log function.

a. Configure the telecom format for NAT logs.
[CGN] nat syslog descriptive format cn
NOTE
Configure a NAT log format based on the log server type. In this example, a telecom log
server is used.
b. Set the user log format for NAT logs and configure a log server.
[CGN] nat instance nat444-1
[CGN-nat-instance-nat444-1] nat log user enable syslog
[CGN-nat-instance-nat444-1] nat log host 10.78.10.91 514 source
10.78.215.90 514 name log-server
7. Enable the NAT device to advertise public routes. In the following example, BGP is
used.
[CGN] bgp 200
[CGN-bgp] ipv4-family unicast
[CGN-bgp-af-ipv4] network 171.10.40.0 255.255.255.0


NOTE
Configure the CR to use match private user packets against an ACL and to redirect the matching packets
to the CGN device.
[CR] acl number 2011
[CR-acl-basic-2011] rule 0 permit ip source 10.0.0.0 0.0.15.255-acl-
basic-2011] rule 5 permit ip source 10.0.16.0 0.0.15.255
[CR-acl-basic-2011] rule 10 permit ip source 10.0.32.0 0.0.15.255
[CR-acl-basic-2011] quit
[CR] traffic classifier nat-redirect operator or
[CR-classifier-nat-redirect] if-match acl 2011
[CR-classifier-nat-redirect] quit
[CR] traffic behavior nat-redirect
[CR-behavior-nat-redirect] redirect ip-nexthop 100.100.100.2 interface
[CR-behavior-nat-redirect] quit
[CR] traffic policy global-policy
[CR-policy-global-policy] classifier nat-redirect behavior nat-redirect
[CR-policy-global-policy] quit
[CR] interface GigabitEthernet 1/0/0
[CR-GigabitEthernet1/0/0] ip address 100.100.100.1 255.255.255.0
[CR-GigabitEthernet1/0/0] traffic-policy global-policy inbound
[CR-GigabitEthernet1/0/0] quit

<CGN> display device
NE40E&NE80E-X16's Device status:
Slot Type Online Register Status Primary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<CGN> display ip routing-table
-------------------------------------------------------------------------
171.10.40.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0

171.10.41.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0
171.10.42.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0
# Run the display service-location 1 command to verify the master and slave status in the
server location.
<CGN> display service-location 1

service-location 1
<CGN> display nat session-table size
------------------------------------------------------------
TotalSize :64M
UsedSize :32 M
FreeSize :32 M

---------------------------------------------------------------------------
<CGN> display nat user-information slot 1 engine 0 verbose
Slot: 1 Engine: 0
Total number: 1.
-------------------------------------------------------------------
User Type : NAT444
CPE IP : 10.1.0.253
User ID : -
VPN Instance : -
Address Group : nat444-1
Public IP : 171.10.40.183
Start Port : 1024
Port Range : 4096
Port Total : 4096
Token/TB/TP : 0/0/0
Aging Time(s) : -
Left Time(s) : -
-->Drop Packets : 0
<--Drop Packets : 0
-------------------------------------------------------------------------
Slot: 9 Engine: 0
Total number: 1.
---------------------------------------------------------------
User Type : NAT444

CPE IP : 10.0.1.253
User ID : -
VPN Instance : -
Address Group : nat444-1
Public IP : 171.10.40.183
Start Port : 1024
Port Range : 4096
Port Total : 4096
Token/TB/TP : 0/0/0
Aging Time(s) : -
Left Time(s) : -
-->Drop Packets : 0
<--Drop Packets : 0
-----------------------------------------------------------
<CGN> display nat session table slot 1
Slot: 1 Engine: 0
udp: 10.0.1.253:28195[171.10.40.183:1723]-->*:*
udp: 10.0.1.253:20069[171.10.40.183:1727]--> *:*
udp: 10.0.1.253:59556[171.10.40.183:1085]--> *:*
udp: 10.0.1.253:28384[171.10.40.183:2047]--> *:*
......
Slot: 9 Engine: 0
Current total sessions: 709
udp: 10.0.1.253:28195[171.10.40.183:1723]-->*:*
udp: 10.0.1.253:20069[171.10.40.183:1727]--> *:*
udp: 10.0.1.253:59556[171.10.40.183:1085]--> *:*
udp: 10.0.1.253:28384[171.10.40.183:2047]--> *:*
......
<CGN> display nat statistics received slot 1
Slot: 1 Engine: 0
-----------------------------------------------------------------------
-----------------------------------------------------------------------

<CGN> display nat statistics transmitted slot 1

Slot: 1 Engine: 0
-----------------------------------------------------------------------
-----------------------------------------------------------------------
5.9.5.2.5 Live Network Deployment Examples
?.1. Centralized NAT444 User Capacity Expansion Solution
Solution Overview
As shown in Figure 5-68, a CR is connected to a CGN device, and the NAT444 service is
deployed in inter-board cold backup mode and syslog tracing. The ratio of private IP
addresses to public IP address cannot be less than 14:1.
Figure 5-68 Centralized NAT444 User Capacity Expansion Solution

PC1
CGN
PC2
I n t e r n et
PC3
BRAS CR CR
PC4
Configuration Solution
l Solution 1: Expand the capacity of private IP addresses when the ratio of private IP
addresses to public IP address is less than 14:1.
If the ratio of private IP addresses to public IP address is 10:1, there are 10 class C
private IP addresses and 1 class C public IP address. In this case, four class C private IP
addresses can be added with no public IP address added. The following table lists the
configuration procedure.

N Configuration Description
o. Procedure
1 Add four class C An example assumes that the customer has eight class C
private IP private IP addresses ranging from 10.103.24.2 to
addresses in the 10.103.31.255. In this case, add four class C private IP
private address addresses ranging from 10.103.32.0 to 10.103.35.255.
pool.
2 Add rule 15 acl number 2053

configuration in rule 10 permit source 10.103.28.0 0.0.3.255
the original ACL rule 15 permit source 10.103.32.0 0.0.3.255
traffic
nat instance nat444
distribution view ……
to match the nat address-group nat-3
newly added four section 1 10.1.133.0 mask 24
nat outbound 2053 address-group nat-3
class C private IP ……
addresses.
l Solution 2: Expand the capacity of public IP addresses when the ratio of private IP
addresses to public IP address is 14:1.
In this case, if 28 class C private IP addresses are to be added, two class C public IP
addresses need to be added. The following table lists the configuration procedure.
o. Procedure
1 Add 28 class C Add 28 class C private IP addresses ranging from

private IP 10.103.24.0 to 10.103.51.255.
addresses in the
private address
pool.
2 Add acl number 2052

...........................
configurations rule 20 permit source 10.103.24.0 0.0.3.255
for ACL rules rule 25 permit source 10.103.28.0 0.0.3.255
numbered 20 to rule 30 permit source 10.103.32.0 0.0.3.255
50 in the original rule 40 permit source 10.103.40.0 0.0.3.255
ACL traffic rule 45 permit source 10.103.44.0 0.0.3.255
distribution view rule 50 permit source 10.103.48.0 0.0.3.255
to match the
newly added 28
class C private IP
addresses.

o. Procedure
3 Add two class C nat instance nat444 id 1

public IP nat address-group nat-2 id 1
addresses in the section 1 10.1.133.0 mask 24
original NAT section 2 10.1.134.0 mask 24
section 3 10.1.135.0 mask 24
address pool and section 4 10.1.136.0 mask 24
use ACL 2052 to nat outbound 2052 address-group nat-2
match the private
and public IP
addresses.
4 Configure routes. Configure route aggregation of public IP addresses, public

route advertisement, and filtering of private network routes.
?.2. Centralized VPN+NAT444 Solution Deployment
Solution Overview
As shown in Figure 5-69, the CR is connected to the CGN device in a VPN scenario, and the
CGN device is equipped with two CGN boards for inter-board cold backup. The VPN
instance configured for the private network is different from that for the public network, and
the NAT444 service is deployed.
Figure 5-69 Centralized VPN+NAT444 solution deployment
PC1
CGN
PC2
I n t e r n et
PC3
BRAS CR CR
PC4

Table 5-57 Centralized VPN+NAT444 solution deployment

. tion
Procedure
1 Configure license
NAT active nat session-table size 16 slot 9 engine 0
session
resources
for CGN
boards.
2 Configure a ip vpn-instance public-vpn

ipv4-family
network- route-distinguisher XX:XX
side VPN vpn-target 100:100 export-extcommunity
instance vpn-target 100:100 import-extcommunity
named ip vpn-instance intranet-vpn
public-vpn ipv4-family
and a user- route-distinguisher X.X.X.X:XX
vpn-target 101:100 export-extcommunity
side VPN vpn-target 101:100 import-extcommunity
instance
named
intranet-
vpn.
basic
functions service-instance-group nat-pppoe-1
for the service-location 1
NAT nat instance nat-pppoe-1 id 1
instances. vpn-nat enable //Enable the VPN NAT function.
In order to port-range 4096
service-instance-group nat-pppoe-1
enhance nat address-group nat-pppoe-1 group-id 1 vpn-instance public-
live vpn
network //Configure the public address pool for the VPN instance
reliability, public-vpn.
section 0 10.10.40.0 mask 24
you are section 1 10.10.41.0 mask 24
advised to section 2 10.10.42.0 mask 24
deploy section 3 10.10.43.0 mask 24
nat outbound 3012 address-group nat-pppoe-1
inter-board nat alg all
warm nat filter mode full-cone
backup for
centralized
NAT444
deployment
.

. tion
Procedure
4 Configure acl number 3011

rule 0 permit ip source 10.0.0.0 0.0.15.255
an ACL for rule 5 permit ip source 10.0.16.0 0.0.15.255
traffic rule 10 permit ip source 10.0.32.0 0.0.15.255
distribution //Configure an ACL to match 48 (48 x 256 = 12288) class C
private IP addresses (which is less than the number of
. private users supported by the public address pool.
acl number
3012
rule 0 permit ip vpn-instance intranet-vpn source 10.0.0.0

0.0.15.255
0.0.15.255
0.0.15.255
//The number of private network users supported by the public

IP address must be greater than the number of private IP
addresses.
5 Configure a traffic classifier nat-pppoe-1 operator or

if-match acl 3011
traffic
policy and traffic behavior nat-pppoe-1
bind traffic nat bind instance nat-pppoe-1
behavior to traffic policy nat-pppoe-1
the traffic share-mode
classifier. statistics enable
classifier nat-pppoe-1 behavior nat-pppoe-1
6 Configure //Bind the network-side interface to the private VPN instance.

the vlan-type dot1q 1
network- ip binding vpn-instance intranet-vpn
side and ip address 10.11.11.1 255.255.255.0
traffic-policy nat-pppoe-1 inbound
user-side //Bind the user-side interface to the public VPN instance.
interface IP interface GigabitEthernet2/0/0.2
addresses vlan-type dot1q 2
ip binding vpn-instance public-vpn
and bound ip address 212.100.205.106 255.255.255.0
VPN
information
.
7 Configure N/A
IBGP to
advertise
public
network
routes.
?.3. Centralized NAT444 Dual-Device Hot Backup Deployment Example

Solution Overview
As shown in Figure 5-70, NAT444 dual-device hot backup is configured for the common HSI
service, and a VRRP channel is established between the two CGN devices through GE
interfaces for HA inter-chassis backup.
Figure 5-70 Centralized NAT444 dual-device hot backup deployment
Internet
IGW-1 IGW-2
GE3/0/1 GE3/0/1
GE3/0/0
CGN-1 CGN-2
GE3/0/2 GE3/0/2
N Configuratio Configuration on the Master Configuration on the Backup
o n Procedure Device Device
.
1 Configure license license

active nat session-table active nat session-table
session size 16 slot 4 engine 0 size 16 slot 4 engine 0
resources.
2 Enable CGN service-ha hot-backup enable service-ha hot-backup enable

HA hot
backup.


.
3 Configure an acl number acl number

2021 2021
ACL for traffic
distribution.
rule 5 permit source rule 5 permit source
10.192.0.0 0.0.127.255 10.192.0.0 0.0.127.255
4 Configure interface interface

VRRP for undo shutdown undo shutdown
intermediate vlan-type dot1q 2002 vlan-type dot1q 2002
backup links. ip address 10.0.0.1 ip address 10.0.0.2
255.255.255.0 255.255.255.0
vrrp vrid 20 virtual-ip vrrp vrid 20 virtual-ip
10.0.0.3 10.0.0.3
admin-vrrp vrid 20 ignore- admin-vrrp vrid 20 ignore-
if-down if-down
//This configuration must vrrp vrid 20 priority 120
be performed; otherwise, the vrrp vrid 20 track service-
VRRP status may be incorrect. location 21 reduced 50
vrrp vrid 20 preempt-mode
timer delay 400
vrrp vrid 20 track
interface
GigabitEthernet3/0/1 reduced
50
//VRRP associated network-
side interface
vrrp vrid 20 track
interface
GigabitEthernet3/0/2 reduced
50
//VRRP associated user-side
interface
location 21 reduced 50
5 Configure a service-location 21 service-location 21

location slot 4 engine 0 location slot 4 engine 0
CGN HA remote-backup interface remote-backup interface
backup group. GigabitEthernet3/0/0.1 peer GigabitEthernet3/0/0.1 peer
10.0.0.2 10.0.0.1
//Local interface of the
intermediate VRRP link
6 Configure a service-instance-group ser- service-instance-group ser-

group1 group1
CGN HA
service service-location 21 service-location 21
instance group.


.
7 Configure nat instance nat444-1 id 21 nat instance nat444-1 id 21

port-range 4096 port-range 4096
basic NAT service-instance-group ser- service-instance-group ser-
functions. group1 group1
nat address-group addr- nat address-group addr-
group1 group-id 21 group1 group-id 21
section 0 100.192.1.0 section 0 100.192.1.0
mask 24 mask 24
section 1 100.192.2.0 section 1 100.192.2.0
mask 24 mask 24
nat outbound 2021 address- nat outbound 2021 address-
group addr-group1 group addr-group1
nat alg all nat alg all
nat filter mode full-cone nat filter mode full-cone
8 Configure a traffic behavior traffic- traffic behavior traffic-

behavior1 behavior1
traffic nat bind instance nat444-1 nat bind instance nat444-1
behavior.
9 Configure a traffic classifier traffic- traffic classifier traffic-

classifier1 classifier1
traffic if-match acl 2021 if-match acl 2021
classifier.
1 Configure a traffic policy traffic- traffic policy traffic-

policy1 policy1
0 traffic policy.
share- share-
mode mode
classifier traffic- classifier traffic-

classifier1 behavior traffic- classifier1 behavior traffic-
behavior1 behavior1
5.9.5.3 Distributed DS-Lite Solution Deployment Guide

Figure 5-71 Distributed DS-Lite solution
CPE1
PC1 MAC:2000::1
->192.168.1.1-5172 BRAS DNS RADIUS
MAC:69.1.1.1-1001 Server Server
MAC:69.1.1.1-1002
CPE1 CPE1
MAC:2000::1
->192.168.1.2-5172
Access ISP core
PC2
network
CPE2 BRAS
MAC:2000::2 BRAS
->192.168.2.1-5172 MAC:69.1.1.1-2001 DHCP Web
PC3 MAC:69.1.1.1-2002 Server Server
CPE2
CPE2 MAC:2000::2
->192.168.2.2-5172
PC4
Figure 5-71 shows a distributed Dual-Stack Lite (DS-Lite) scenario. The routed customer
premises equipment (CPE) runs Point-to-Point Protocol over Ethernet IPv6 (PPPoEv6) or
IPv6 over Ethernet (IPoEv6) to dial up to log in to a broadband remote access server (BRAS)
equipped with Carrier Grade NAT (CGN) boards. The BRAS assigns an IPv6 address to the
CPE's WAN interface, an IPv6 address prefix to the CPE's LAN interface, a related public IP
address, and a related public port range. The CPE assigns a private IPv4 address to a
residential terminal and uses the IPv6 address prefix to assign an IPv6 address to the
residential terminal. The CPE uses the IPv6 address of the WAN interface to establish a tunnel
to the BRAS.
The CPE directly forwards user IPv6 packets over routes. The CPE encapsulates user IPv4
packets into IPv4 over IPv6 packets before forwarding them, in which the source IP address is
set to the CPE's WAN interface address and the destination address is set to the BRAS's IPv6
address.
Upon receipt of the IPv4 over IPv6 packets, the BRAS decapsulates them, replaces the source
IPv4 addresses and port numbers with public ones, and forwards them to an IPv4 network. In
such a scenario, DS-Lite functions are deployed on DS-Lite service boards equipped on
BRASs. Therefore, this scenario is a distributed DS-Lite solution.
Address Translation Solution

The CPE assigns a private IPv4 address to each terminal. The BRAS assigns an IPv6 address,
a public IPv4 address, and a public port number range, to the CPE.
DS-Lite Translation
The CPE functions as a Dynamic Host Configuration Protocolv4 (DHCPv4) server to assign
an IPv4 address (for example, 192.168.0.0/16) to each residential user, and the BRAS assigns

IPv6 addresses only. Before a residential user accesses IPv4 services, the user sends a packet
with a private IPv4 address along an IPv4-in-IPv6 tunnel to a CGN device. The CGN device
translates the private IPv4 address to a public IPv4 address. The CGN device forwards the
user packet along an IPv4 over IPv6 tunnel to the CPE. Upon receipt of the user packet, the
CPE forwards it to the IPv4 network to access IPv4 services.
Solution Advantages
l Seamless integration of user access and DS-Lite
DS-Lite pre-allocates ports to various access users, such as Point-to-Point Protocol over
Ethernet (PPPoE) users, IPoE users, and Layer 2 Tunneling Protocol (L2TP) users.
Information about DS-Lite resource allocation and entry translation of users can be
queried based on access information, such as domains and user IDs. User accounting
packets carrying DS-Lite port ranges are sent to a Remote Authentication Dial In User
Service (RADIUS) server, and the RADIUS server performs source tracing for users.
l Log management based on orderly port pre-allocation
The conventional Network Address Translation (NAT) process is performed on demand.
Each user flow is assigned a port. An individual user is prone to consuming a lot of
resources on peripheral devices, especially when DS-Lite log information is sent for each
flow in source tracing. To reduce resource consumption, port pre-allocation is used so
that DS-Lite assigns a port range to a logged-in user and releases the port range after the
user is logged out, achieving even resource allocation for users. In source tracing, only a
single DS-Lite log message needs to be sent when a user goes online or offline. In
addition, users' DS-Lite addresses and port ranges can be sent to the RADIUS server and
used to perform real-time source tracing.
l Flexible and controllable service rollback
A user who needs a public IP address can be rolled back to a public domain based on the
domain name delivered by a RADIUS server. In the public domain, the user can be
assigned a public IP address before accessing a public network.
l High reliability
CGN boards within a chassis perform inter-board hot backup, and CGN devices perform
inter-chassis hot backup.
Table 5-58 lists the license functions related to the VSUF-40/80/160.

Control Item Control Level Configuration Item
NE40E&NE80E PCP Board The PCP function is disabled by

function default. To enable the PCP function,
perform the following operations:
[HUAWEI] license
vsuf slot 1

NE40E&NE80E NAT Board The NAT function is enabled by

function default.
NE40E&NE80E DS-Lite Board The DS-Lite function is disabled by

function default. To enable the DS-Lite
function, perform the following
operations:
[HUAWEI] license
[HUAWEI-license] active ds-lite
vsuf slot 1

NE40E&NE80E 20 Gbps Base board CPU of l A VSUF-40 supports the 40

capacity the VSUF-40/80/160 Gbps forwarding capacity
following command:
[HUAWEI] license
engine 0
l For the VSUF-80 that supports

80 Gbps forwarding bandwidth
(sum of the upstream bandwidth
and downstream bandwidth),
two base board CPUs are
available for two subcards. Each
base board CPU supports 40
Gbps bandwidth. By default, 20
Gbps bandwidth is supported. If
the forwarding bandwidth needs
to be upgraded to 40 Gbps,
perform the following
operations:
[HUAWEI] license
engine 0

operations:
[HUAWEI] license
engine 0

NE40E&NE80E NAT Base board CPU or By default, no CPU session table

session number subcard CPU exists on the VSUF-40/80/160, and
2M session tables are allocated each
time.
For the VSUF-40/80/160, each CPU
supports a maximum of 16M NAT
sessions. For the VSUI-160-E, each
CPU supports a maximum of 32 M
NAT sessions. To configure the
number of NAT sessions allocated
to the base CPU or subcard CPU,
[HUAWEI] license
engine 0

Product Version
NE40E&NE80E V600R009C10
iManager U2000
Power consumption


NOTE
installed.
Subcard Application
VSUF-160.
NOTE

(Gbit/s) with
Subcards
(Gbit/s)
200 NE40 VSUF 40/40/80 25/25/50 NA/80/160 NA/50/100

Gbit/s E&NE -40/80
platfor 80E- /160
m X8


(Gbit/s) with
Subcards
(Gbit/s)
NE40
E&NE
80E-
X16
40 NE40 VSUF 40 25 NA/80 NA/50

Gbit/s E&NE -40/80
platfor 80E-
m X8
NE40
E&NE
80E-
X16
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-
X3
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-1
6
20 NE40 VSUF 15 15 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-8
m
10 NE40 VSUF 10 10 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-1
m 6


?.1. RADIUS Server
adjusted.


Type

a RADIUS server.
a RADIUS server.
26-1 HW-NAT-Port- Integer Changed port number range.

65 Range-Update When a BRAS performs semi-dynamic port
allocation, the BRAS sends accounting
packets each with this attribute to a RADIUS
server.
26-1 HW-DS-LITE- String Destination IP address name of a DS-Lite

66 TUNNEL- tunnel.
NAME A CGN device sends this attribute carrying
the destination IP address name to the CPE.
Upon receipt of the attribute, the CPE
resolves it into a destination IPv6 address.
l Management of DS-Lite tunnels' domain names delivered by the RADIUS server is

implemented using the following attributes.


Type

66 TUNNEL- tunnel.
l Domain management is implemented based on NAT444 and public single stack users.
The RADIUS server delivers separately planned domain names to NAT444 users. Before
implementing domain management, the RADIUS server must be able to deliver the HW-
Domain-Name (26-138) attribute, support the business and operation support system
(BOSS), and identify NAT444 users based on domains.
Type
reconstruction involved.
l NAT policies are managed by the RADIUS server. Before the RADIUS server delivers
NAT policy templates, the RADIUS server must support the following attributes.
Type

l The port forwarding attribute must be supported by the RADIUS server before the server
delivers it.
Type
26-1 HW-NAT-Port- String Port forwarding information is delivered and

64 Forwarding reported by the RADIUS server.
?.2. Log Server
NOTE

?.3. DNS Server
In Figure 5-72, a domain name server (DNS) needs to be upgraded to support the following
functions:
l Records and queries AAAA resources based on IPv6 addresses.
l Supports the IPv4/IPv6 dual-stack and provides the IPv6 address-based communication
capability.
l Resolves an AAAA resource record in each DNS query packet into an IPv6 address and
an A resource record in each DNS query packet into an IPv4 address.
l Enables a broadband remote access server (BRAS) to run Dynamic Host Configuration
Protocolv6 (DHCPv6) to deliver IPv6 DNS configurations to the customer premises
equipment (CPE). The CPE sends the DNS IPv6 address to a PC. Alternatively, the CPE
functions as a proxy DNS server and delivers DNS configuration to the PC.
Figure 5-72 DNS server upgrade

DNS server AAA server
Server farm
I n t e r n et
IPv4 www.a4.com
Internet 74.125.43.160
PC CPE BRAS
The DNS server is upgraded to I n t e r n et
Query = "www.a4.com" Type = "A" support AAAA resource
records based on IPv6 IPv6 www.a6.com
addresses. Internet 2404:6800:8003
Resp = "74.125.43.160" TYPE = "A" www.a4.com in A 74.125.43.160
www.a6.com in AAAA
Query = "www.a4.com" TYPE = "AAAA" 2404:6800:8003::63
Resp = "None" TYPE = "AAAA"
Query = "www.a6.com" TYPE = "A"

An application sends a
request to the DNS server
Resp = "None" TYPE = "A" to query the IPv4 or IPv6
address mapped to a
Query = "www.a6.com" TYPE = "AAAA" specified domain name.
Resp = "2404:6800:8003::63" TYPE = "AAAA"
?.4. CPE
Before customer premises equipment (CPE) is used, the IPv4/IPv6 dual stack must be
supported so that address family transition router (AFTR) addresses can be used to establish
IPv4 over IPv6 tunnels.


NOTE

experience.
formula: Number of public IP addresses = Number of users for cutover/ratio of public IP
addresses to private IP addresses. For example, if a total of 28K private users are waiting for
service cutover and the port-range value is 4096 (public-to-private ratio as 1:14), the number
of public IP addresses is 2K (28K/14=2K).
[HUAWEI-ds-lite-instance-ds-lite1] ds-lite address-group addr-group4
group-id 3
[HUAWEI-ds-lite-instance-ds-lite1-ds-lite-address-group-add-group3]

group-id 2
section 1 213.1.2.0 213.1.2.200

– Run the ds-lite address-group mask command to configure a public IP address
segment.
group-id 1 213.1.3.0 mask 24

– Run the ds-lite address-group start-end command to configure a public IP address

segment.
group-id 0 213.1.40.0 213.1.40.20
The first method is recommended for online capacity expansion of the public network address
pool. The configuration commands are as follows:
ds-lite instance huawei1 id 1
ds-lite filter mode full-cone
port-range 4096
ds-lite address-group addr-group3 group-id 1
section 0 210.x.x.x mask 24
ds-lite outbound 2080 address-group addr-group3
If a DS-Lite public network address pool is configured using the mask mode (recommended),
the length of the advertised routes is the same as configured. If a DS-Lite public network
address pool is configured using the start-end mode, the length of the advertised routes is 32
bits.
After receiving user traffic, the CGN board performs DS-Lite for the traffic in the following
modes:
Run the ds-lite outbound acl-number address-group address-group-name command to
specify an ACL and DS-Lite address pool so that only the packets matching the ACL
rules and with a permit action can implement DS-Lite using the allowed public network
addresses.
Run the ds-lite outbound any address-group address-group-name command to specify
a DS-Lite address pool so that packets do not need to match ACL rules. By default,
addresses from a specified DS-Lite address pool are used for DS-Lite implementation.
that private IP addresses matching an ACL rule are translated by DS-Lite to public IP
specified, DS-Lite will be implemented for all the traffic diverted to the service board
based on a specified address pool.
If any (not match ACL rules) is specified for DS-Lite, the CGN device assigns IP addresses
from the same address pool for the all traffic. This fails to be achieved if a carrier plans to
allocate public IP address based on residential areas or regions. Therefore, matching traffic
against ACL rules is recommended for DS-Lite.
As shown in Figure 5-73, the ACL matching mode is used to implement DS-Lite.
Specifically, a private IPv6 private address pool is configured, and then DS-Lite is
implemented for the private IP addresses in this address pool. Then the permit network
segment and ip pool network segment are matched, and the ACL 2222 in the DS-Lite instance
huawei1 are bound to the public network group add-group.

Configure an IPv6 ipv6 prefix ipv6-prefix local

prefix. prefix 33::/64
Configure a private ipv6 pool ip-pool bas local

IPv6 address. prefix ipv6-prefix
Configure an ACL to acl ipv6 number 2222

import traffic. rule 0 permit source 33::/64
Configure an HA service-location 1
Configure an HA service-instance-group group1


Configure basic DS- ds-lite filter mode full-cone
service-instance-group group1
ds-lite address-group add-group group-id 1
section 0 210.210.4.0 mask 24
ds-lite outbound 2222 address-group add-group
?.4. NAT Scheme
Two NAT modes are available for a DS-Lite instance.

protocol packets to traverse the DS-Lite device. The 3-tuple mode (full-cone mode) is
5-tupe mode to the 3-tuple mode, run the ds-lite filter mode full-cone command in the DS-
Lite instance view.

#
ds-lite instance huawei id 1
……
……
#
As shown in Table 5-61, distributed Dual-Stack Lite (DS-Lite) supports the following backup
modes:
l Warm backup
on the master service board. Warm backup is the default mode. In warm backup, high
availability (HA) hot backup cannot be enabled. For the procedure of configuring warm
backup, see Figure 5-74. To reduce the solution complexity, 1:1 master/slave service
board backup is recommended.
l Hot backup
the master service board. In hot backup, HA hot backup must be enabled. For the
procedure of configuring hot backup, see Figure 5-74. Either 1:1 master/slave service
board backup or 1+1 load balancing mode can be used to deploy DS-Lite services based
on your network plan.
NOTE
If Redundancy User Information (RUI) is not deployed, inter-board warm backup is used. If RUI
is deployed, inter-chassis warm backup is implemented by directly connected chassis.
1+1 load balancing warm or hot backup indicates that two devices implementing 1:1 backup back
up each other.

Figure 5-74 Process of configuring backup
Start

Standby Feature
Configuration

CGN Device

Creating and
configuring a VRRP
Backup Group
Device
HA Backup
Configuration
Setting the Backup
Backup Group to a
Delay
VRRP Backup Group
Configuring
Association Between
Switching Delay
HA and VRRP
Configuring Service
Instance Group
HA Service Feature
Configuration
Binding Service
Instances to a
Service Instance
Group
Binding a Service
HA Backup Group
Compulsory Step
Optional Step
End

Table 5-61 Distributed DS-Lite backup

Deployment Evolution Backup Mode Warm Backup Hot Backup
Mode Technique
Distributed DS-Lite Inter-board Supported Supported

(recommended)
DS-Lite Inter-chassis Supported Supported

(recommended)
?.6. Usermanagement Scheme

Dual-Stack Lite (DS-Lite) sessions
The maximum number of DS-Lite sessions that can be established is set. This limit
prevents individual users from occupying excessive session entries. If a user occupies
excessive session entries, DS-Lite connections cannot be established for other users.
a. Run:
ds-lite instance instance-name [ id id ]
The DS-Lite instance view is displayed.

b. Run:
ds-lite session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based forward DS-Lite sessions that can be

established is set.
c. Run:
ds-lite reverse-session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based reverse DS-Lite sessions that can be

established is set.
l Limit on the number of DS-Lite ports
a. Run:

b. Run:
ds-lite port-limit enable

c. Run:
ds-lite port-limit { tcp | udp | icmp | total } port-number
l Mode of processing non-DS-Lite packets
A service board can be enabled to discard non-DS-Lite packets.
– Run:


By default, non-DS-Lite packets are transmitted transparently.
l Limit on the number of private network users who can get online using the same
DS-Lite public IP address
a. Run:
ds-lite instance instance-name id id

b. Run:
ds-lite ip access-user limit max-number
DS-Lite public IP address is set.
NOTE
l Traffic creation rate control
The rate at which packets are sent to create a flow can be set. If a user initiates an attack,
for an example, a denial of service (DDoS) attack or incorrectly initiates an attack on a
device, the device creates a great number of links for the user within a short period of
time, which consumes lots of resources, adversely affecting other user services.
a. Run:

b. Run:
ds-lite user-session create-rate rate

c. Run:
quit

d. (Optional) Run:
flow is set.
NOTICE


A port number or range can be specified so that DS-Lite does not translate them, which
a. Run:

b. Run:
NOTICE
5.9.5.3.4 Example for Configuring Distributed DS-Lite in a Typical Scenario
Networking Diagram
In Figure 5-75, a terminal user assigned a private IPv4 address accesses an IPv6 metropolitan
area network (MAN) through the customer premises equipment (CPE). The CPE establishes a
Dual-Stack Lite (DS-Lite) tunnel to a DS-Lite device. The CPE transmits traffic with the
private IPv4 address along the DS-Lite tunnel to the DS-Lite device. The DS-Lite device
decapsulates traffic, uses a Network Address Translation (NAT) technique to translate the
private IPv4 address to a public IPv4 address, and forwards traffic to the IPv4 Internet. The
DS-Lite device is equipped with DS-Lite boards in slots 1 and 9, respectively. The DS-Lite
device's GE 2/0/0 is connected to an IPv6 MAN, and POS 1/0/0 is connected to the Internet.
IPv4 residential users need to access the IPv4 Internet through the IPv6 MAN. The broadband
remote access server (BRAS) performs DS-Lite translation for user packets. The users log in
to the BRAS using IPv6. The CGN boards on the BRAS perform 1:1 inter-board warm
backup.

Figure 5-75 Typical distributed DS-Lite networking
Dual Stack Host

ISIS 1000
Level-2
GE1/0/0
172.16.1.1/24
Tunnel IPv4
Network
CPE GE2/0/0
BRAS
IPv6-only SP Network
IPv4 Host
1. Load a Global Trotter License (GTL) that enables DS-Lite and configure DS-Lite
sessions on service boards.
2. Enable IPv6 and set a DHCP unique ID (DUID) for a Dynamic Host Configuration
Protocolv6 (DHCPv6) server.
3. Create an IPv6 neighbor discovery (ND) address pool and an IPv6 prefix delegation
(PD) address pool.
4. Create a Carrier Grade NAT (CGN) high availability (HA) backup group and bind it to
service boards.
5. Create a CGN HA instance group and bind it to the CGN HA backup group.
6. Create a DS-Lite instance and bind it with the service instance group.
7. Configure basic DS-Lite functions.
8. Configure a user group of which users access the Internet.
9. Configure a domain from which users access the Internet.
10. Configure a distributed DS-Lite traffic distribution policy.
11. Enable the DS-Lite device to advertise public routes.
1. Load a GTL license that enables DS-Lite and configure DS-Lite sessions on service
boards.
<BRAS> display license
-------------------------------------------------------------
..............................................................
..............................................................
LME0DSLITE01 Resource 2 DS-Lite License for VSUF
..............................................................
<BRAS> system-view

[BRAS] License
[BRAS-license] active ds-lite vsuf slot 1
[BRAS-license] active ds-lite vsuf slot 9
[BRAS-license] quit
2. Configure a RADIUS server group named rad-ser.

[BRAS] radius-server group rad-ser
[BRAS-radius-rad-ser] radius-server authentication 202.10.10.10 1824 weight 0
[BRAS-radius-rad-ser] radius-server accounting 202.10.10.10 1825 weight 0
[BRAS-radius-rad-ser] radius-server shared-key-cipher huawei@123
[BRAS-radius-rad-ser] quit
3. Enable IPv6 and set a DUID for a DHCPv6 server.

[BRAS] ipv6
[BRAS] dhcpv6 duid llt
4. Create an IPv6 ND address pool and an IPv6 PD address pool.

a. Set an IPv6 ND prefix pool.
[BRAS] ipv6 prefix ipv6-pppoe-nd-1 delegation
[BRAS-ipv6-prefix-ipv6-pppoe-nd-1] prefix 240E:A3:D000::/41
[BRAS-ipv6-prefix-ipv6-pppoe-nd-1] slaac-unshare-only
[BRAS-ipv6-prefix-ipv6-pppoe-nd-1] quit
b. Create an IPv6 ND address pool.

[BRAS] ipv6 pool ipv6-pppoe-nd-1 bas delegation
[BRAS-ipv6-pool-ipv6-pppoe-nd-1] dns-server 240E:5E:8000::10
[BRAS-ipv6-pool-ipv6-pppoe-nd-1] prefix ipv6-pppoe-nd-1
[BRAS-ipv6-pool-ipv6-pppoe-nd-1] quit
c. Set an IPv6 PD prefix pool.

[BRAS] ipv6 prefix ipv6-pppoe-pd-1 delegation
[BRAS-ipv6-prefix-ipv6-pppoe-pd-1] prefix 240E:A3:D080::/41 delegating-
prefix-length 56
[BRAS-ipv6-prefix-ipv6-pppoe-pd-1] pd-unshare-only
[BRAS-ipv6-prefix-ipv6-pppoe-pd-1] quit
d. Create an IPv6 PD address pool and specify an address family transition router
(AFTR) name.
[BRAS] ipv6 pool ipv6-pppoe-pd-1 bas delegation
[BRAS-ipv6-pool-ipv6-pppoe-pd-1] dns-server 240E:5E:8000::10
[BRAS-ipv6-pool-ipv6-pppoe-pd-1] aftr-name zj-hz-aftr1.dualstack-lite.com
[BRAS-ipv6-pool-ipv6-pppoe-pd-1] prefix ipv6-pppoe-pd-1
[BRAS-ipv6-pool-ipv6-pppoe-pd-1] quit
5. Create a CGN HA backup group and bind it to service boards.

[BRAS] service-location 1
[BRAS-service-location-1] location slot 1 engine 0 backup slot 9 engine 0
[BRAS-service-location-1] quit
6. Create a CGN HA instance group and bind it to the CGN HA backup group.
[BRAS] service-instance-group service-instance-group1
[BRAS-instance-group-service-instance-group1] service-location 1
[BRAS-instance-group-service-instance-group1] quit
7. Create a DS-Lite instance and bind it with the service instance group.
[BRAS] ds-lite instance ds-lite-1 id 100
[BRAS-ds-lite-instance-ds-lite-1] service-instance-group service-instance-
group1
[BRAS-ds-lite-instance-ds-lite-1] quit

[BRAS] acl ipv6 3000
[BRAS-acl6-adv-3000] rule 5 permit ipv6 source 240E:A3:D000::/41 destination
240E:3:D000::12/128
[BRAS-acl6-adv-3000] quit

[BRAS] ds-lite instance ds-lite-1 id 100

[BRAS-ds-lite-instance-ds-lite-1] ds-lite tunnel prefix-length 64
[BRAS-ds-lite-instance-ds-lite-1] port-range 4096
[BRAS-ds-lite-instance-ds-lite-1] ds-lite address-group dt-addr-group group-
id 1
[BRAS-ds-lite-instance-ds-lite-1-ds-lite-address-group-dt-addr-group] section
0 60.20.1.1 mask 24
[BRAS-ds-lite-instance-ds-lite-1-ds-lite-address-group-dt-addr-group] quit
[BRAS-ds-lite-instance-ds-lite-1] ds-lite outbound 3000 address-group dt-addr-
group
[BRAS-ds-lite-instance-ds-lite-1] local-ipv6 240E:3:D000::12 prefix-length 128
[BRAS-ds-lite-instance-ds-lite-1] remote-ipv6 240E:A3:D000:: prefix-length 41
[BRAS-ds-lite-instance-ds-lite-1] ds-lite alg all
[BRAS-ds-lite-instance-ds-lite-1] ds-lite filter mode full-cone
Warning: The command will rebuild all session tables of this instance.
Continue? [Y/N]: Y
[BRAS-ds-lite-instance-ds-lite-1] quit
9. Configure a user group of which users access the Internet.

[BRAS] user-group ds-lite-1
Info: Create a new user group
10. Configure a domain from which users access the Internet.

[BRAS] aaa
[BRAS-aaa] authentication-scheme auth1
[BRAS-aaa-authen-auth1] quit
[BRAS-aaa-accounting-acct1] accounting-scheme acct1
Info: Create a new accounting scheme.
[BRAS-aaa-accounting-acct1] accounting start-fail online
[BRAS-aaa-accounting-acct1] quit
[BRAS-aaa] domain ds-lite-domain
[BRAS-aaa-domain-ds-lite-domain] authentication-scheme auth1
[BRAS-aaa-domain-ds-lite-domain] accounting-scheme acct1
[BRAS-aaa-domain-ds-lite-domain] prefix-assign-mode unshared
[BRAS-aaa-domain-ds-lite-domain] ipv6-pool ipv6-pppoe-nd-1
[BRAS-aaa-domain-ds-lite-domain] ipv6-pool ipv6-pppoe-pd-1
[BRAS-aaa-domain-ds-lite-domain] radius-server group rad-ser
[BRAS-aaa-domain-ds-lite-domain] user-group ds-lite-1 bind ds-lite instance
ds-lite-1
[BRAS-aaa-domain-ds-lite-domain] user-basic-service-ip-type ipv6
[BRAS-aaa-domain-ds-lite-domain] quit
[BRAS-aaa] quit
11. Configure a distributed DS-Lite traffic distribution policy.

# Configure a classifier-behavior (C-B) pair to distribute user traffic in a user group
named ds-lite-1 to a DS-Lite instance named ds-lite-1.
[BRAS] acl ipv6 number 9001
[BRAS-acl6-ucl-9001] rule 5 permit ipv6 source user-group ds-lite-1
destination ipv6-address 240E:3:D000::12/128
[BRAS-acl6-ucl-9001] quit
[BRAS] traffic classifier ds-classifier1 operator or
[BRAS-classifier-ds-classifier1] if-match ipv6 acl 9001
[BRAS-classifier-ds-classifier1] quit
[BRAS] traffic behavior ds-behavior1
[BRAS-behavior-ds-behavior1] ds-lite bind instance ds-lite-1
[BRAS-behavior-ds-behavior1] quit
[BRAS] traffic policy service-control
[BRAS-trafficpolicy-service-control] share-mode
[BRAS-trafficpolicy-service-control] classifier ds-classifier1 behavior ds-
behavior1
[BRAS-trafficpolicy-service-control] quit
[BRAS] traffic-policy service-control inbound
12. Enable the DS-Lite device to advertise public routes. In the following example,
Intermediate System to Intermediate System (IS-IS) is used.
a. Configure IS-IS.
[BRAS] isis 100

[BRAS-isis-100] network-entity 10.1000.1000.1000.00

[BRAS-isis-100] quit
[BRAS] isis 1000
[BRAS-isis-1000] network-entity 10.1000.1000.1002.00
[BRAS-isis-1000] ipv6 enable
b. Configure the DS-Lite device's interface connected to the IPv6 network.

[BRAS] interface gigabitethernet2/0/0
[BRAS-GigabitEthernet2/0/0] ipv6 enable
[BRAS-GigabitEthernet2/0/0] isis ipv6 enable 1000
[BRAS-GigabitEthernet2/0/0] quit
c. Configure the DS-Lite device's interface connected to the IPv4 network.

[BRAS] interface gigabitethernet1/0/0
[BRAS-GigabitEthernet1/0/0] ip address 172.16.1.1 24
[BRAS-GigabitEthernet1/0/0] isis enable 100
[BRAS-GigabitEthernet1/0/0] quit
d. Import the local IP route and address pool route to the IS-IS routing table. Enable
the DS-Lite device to advertise the local IP route to the IPv6 network and the
address pool route to the IPv4 network.
[BRAS] isis 1000
[BRAS-isis-1000] ipv6 import-route unr
[BRAS] isis 100
[BRAS-isis-100] import-route unr
NOTE
If a public address pool is configured using a mask, run the network command to advertise a
route. Do not configure a black-hole summary route, which prevents a failure to forward reverse
traffic.

<BRAS> display device
NE40E&NE80E's Device status:
Slot # Type Online Register Status Primary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<BRAS> display ip routing-table
------------------------------------------------------------------------------



Interface
60.20.1.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0

172.16.1.0/24 Direct 15 20 D 172.16.1.2
172.16.1.1/32 Direct 0 0 D 127.0.0.1
<BRAS> display ipv6 routing-table 240E:3:D000::12:100

Routing Table :
Summary Count : 1
Destination : 240E:A3:D000:: PrefixLength : 128

NextHop : ::12:100 Preference : 64
Cost : 10 Protocol : Unr
Interface : GigabitEthernet2/0/0 Flags : D
service location.
service-location 1
<BRAS> display nat session-table size
--------------------------------------------------------------------------------
TotalSize :64M
UsedSize :32 M
FreeSize :32 M

--------------------------------------------------------------------------------
Slot: 1 Engine: 0
Total number: 1.
---------------------------------------------------------------------------
User Type : Ds-Lite
IPv6Address : 240E:3:D000::12:200/128
User ID : -
VPN Instance : -
Address Group : dt-addr-group
DS-Lite Instance : ds-lite-1
Public IP : 60.20.1.1
Start Port : 1024
Port Range : 4096
Port Total : 4096
MTU : 1500


Token/TB/TP : 0/0/0
Aging Time(s) : -
Left Time(s) : -
-->Drop Packets : 0
<--Drop Packets : 0
---------------------------------------------------------------
<BRAS> display nat session table slot 1 verbose
This operation will take a few minutes. Press 'Ctrl+C' to break ...
Slot: 1 Engine: 0
udp: 192.168.1.2:1024[60.20.1.1:1024]--> *:*
*:* -->60.20.1.1:1024[192.168.1.2:1024]
DS-Lite Instance: ds-lite-1
VPN:--->-
Tag:0x2,FixedTag:0x1, Status:hit, Create:2015-9-30 11:37:04,TTL:00:04:00 ,Left:
00:04:00 , Master
AppProID: 0x0, CPEIP:240E:3:D000::12, FwdType:DSLITE
Dest-ip:16.16.1.2,Dest-port:1024
<BRAS> display nat session table slot 9 verbose
Slot: 9 Engine: 0
udp: 192.168.1.2:1024[60.20.1.1:1024]--> *:*
*:* -->60.20.1.1:1024[192.168.1.2:1024]
DS-Lite Instance: ds-lite-1
VPN:--->-
Tag:0x2,FixedTag:0x1, Status:hit, Create:2015-9-30 11:37:04,TTL:00:04:00 ,Left:
00:04:00 , Master
AppProID: 0x0, CPEIP:240E:3:D000::12:200, FwdType:DSLITE
Dest-ip:16.16.1.2,Dest-port:1024
<BRAS> display nat statistics received slot 1
Slot: 1 Engine: 0
------------------------------------------------------------------------
---------------------------------------------------------------------------
<BRAS> display nat statistics transmitted slot 1
Slot: 1 Engine: 0
----------------------------------------------------------------


---------------------------------------------------------------
5.9.5.4 Centralized DS-Lite Solution Deployment Guide
Figure 5-76 shows a centralized Dual-Stack Lite (DS-Lite) scenario. Each routed customer
premises equipment (CPE) runs Point-to-Point Protocol over Ethernet IPv6 (PPPoEv6) or
IPv6 over Ethernet (IPoEv6) to dial up to log in to a broadband remote access server (BRAS).
The BRASs are not equipped with Carrier Grade NAT (CGN) boards. Each BRAS assigns an
IPv6 address to the connected CPE's WAN interface and an IPv6 address prefix to the CPE's
LAN interface. Each CPE assigns a private IPv4 address to a residential terminal and uses the
IPv6 address prefix to assign an IPv6 address to the residential terminal. The CPE uses the
IPv6 address of the WAN interface to establish a tunnel to a CGN device.
A CPE directly forwards user IPv6 packets over routes. The CPE encapsulates user IPv4
packets into IPv4 over IPv6 packets before forwarding them, in which the source IP address is
set to the CPE's WAN interface address and the destination address is set to the CGN device's
IPv6 address specified in a DS-Lite instance.
Upon receipt of the user packets along the IPv4 over IPv6 tunnel, the BRAS forwards them at
Layer 3 to the CGN device. The CGN device decapsulates the packets, replaces the source
IPv4 address and port number in each packet, and forwards the packets to the IPv4 network.
Since DS-Lite functions are deployed on a CGN device attached to the BRAS, this solution is
called centralized DS-Lite.

Figure 5-76 Centralized DS-Lite solution

BRAS MAC-69.1.1.1-1001
BRAS MAC-69.1.1.1-1002
192.168.1.1
BRAS MAC-69.1.1.1-2001
CPE1 MAC-2000::1 BRAS MAC-69.1.1.1-2002
->192.168.1.1-5172
CPE1 BRAS Syslog
PC1 CGN
Access Server
192.168.1.2 network
Tunnel:IPv4 In IPv6
CPE1 MAC-2000::1
PC2 ->192.168.1.2-5172 ISP
Core
192.168.1.1 CPE1 MAC-2000::2
->192.168.1.2-5172
CR
Tunnel:IPv4 In IPv6
CPE2
Access
PC3 network DHCP Web
Server Server
BRAS
CPE1 MAC-2000::2
->192.168.1.2-5172
PC4
192.168.1.2
Address Allocation Solution

A BRAS assigns an IPv6 address to the CPE, and the CPE assigns a private IPv4 address to a
PC. A CGN device assigns a public IPv4 address and port range to the CPE.
DS-Lite Translation
The CPE functions as a Dynamic Host Configuration Protocolv4 (DHCPv4) server to assign
an IPv4 address (for example, 192.168.0.0/16) to each residential user, and the BRAS assigns
IPv6 addresses only. Before a residential user accesses IPv4 services, the user sends a packet
with a private IPv4 address along an IPv4-in-IPv6 tunnel to a CGN device. The CGN device
translates the private IPv4 address to a public IPv4 address. The CGN device forwards the
user packet along an IPv4 over IPv6 tunnel to the CPE. Upon receipt of the user packet, the
CPE forwards it to the IPv4 network to access IPv4 services.


NE40E&NE80E PCP Board The PCP function is disabled by

function default. To enable the PCP function,
[HUAWEI] license
vsuf slot 1
NE40E&NE80E NAT Board The NAT function is enabled by

function default.
NE40E&NE80E DS-Lite Board The DS-Lite function is disabled by

function default. To enable the DS-Lite
operations:
[HUAWEI] license
[HUAWEI-license] active ds-lite
vsuf slot 1


following command:
[HUAWEI] license
engine 0

operations:
[HUAWEI] license
engine 0

operations:
[HUAWEI] license
engine 0


2M session tables are allocated each
time.
For the VSUF-40/80/160, each CPU
supports a maximum of 16M NAT
sessions. For the VSUI-160-E, each
CPU supports a maximum of 32 M
NAT sessions. To configure the
number of NAT sessions allocated
to the base CPU or subcard CPU,
[HUAWEI] license
engine 0

Product Version
NE40E&NE80E V600R009C10
iManager U2000
Power consumption


NOTE
installed.
Subcard Application
VSUF-160.
NOTE

(Gbit/s) with
Subcards
(Gbit/s)
200 NE40 VSUF 40/40/80 25/25/50 NA/80/160 NA/50/100

Gbit/s E&NE -40/80
platfor 80E- /160
m X8


(Gbit/s) with
Subcards
(Gbit/s)
NE40
E&NE
80E-
X16
40 NE40 VSUF 40 25 NA/80 NA/50

Gbit/s E&NE -40/80
platfor 80E-
m X8
NE40
E&NE
80E-
X16
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-
X3
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-1
6
20 NE40 VSUF 15 15 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-8
m
10 NE40 VSUF 10 10 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-1
m 6


?.1. RADIUS Server
adjusted.


Type

a RADIUS server.
a RADIUS server.
26-1 HW-NAT-Port- Integer Changed port number range.

65 Range-Update When a BRAS performs semi-dynamic port
allocation, the BRAS sends accounting
packets each with this attribute to a RADIUS
server.

66 TUNNEL- tunnel.
l Management of DS-Lite tunnels' domain names delivered by the RADIUS server is

implemented using the following attributes.


Type

66 TUNNEL- tunnel.
l Domain management is implemented based on NAT444 and public single stack users.
The RADIUS server delivers separately planned domain names to NAT444 users. Before
implementing domain management, the RADIUS server must be able to deliver the HW-
Domain-Name (26-138) attribute, support the business and operation support system
(BOSS), and identify NAT444 users based on domains.
Type
reconstruction involved.
l NAT policies are managed by the RADIUS server. Before the RADIUS server delivers
NAT policy templates, the RADIUS server must support the following attributes.
Type

l The port forwarding attribute must be supported by the RADIUS server before the server
delivers it.
Type
26-1 HW-NAT-Port- String Port forwarding information is delivered and

64 Forwarding reported by the RADIUS server.
?.2. Log Server
NOTE

?.3. DNS Server
In Figure 5-77, a domain name server (DNS) needs to be upgraded to support the following
functions:
l Records and queries AAAA resources based on IPv6 addresses.
l Supports the IPv4/IPv6 dual-stack and provides the IPv6 address-based communication
capability.
l Resolves an AAAA resource record in each DNS query packet into an IPv6 address and
an A resource record in each DNS query packet into an IPv4 address.
l Enables a broadband remote access server (BRAS) to run Dynamic Host Configuration
Protocolv6 (DHCPv6) to deliver IPv6 DNS configurations to the customer premises
equipment (CPE). The CPE sends the DNS IPv6 address to a PC. Alternatively, the CPE
functions as a proxy DNS server and delivers DNS configuration to the PC.
Figure 5-77 DNS server upgrade

DNS server AAA server
Server farm
I n t e r n et
IPv4 www.a4.com
Internet 74.125.43.160
PC CPE BRAS
The DNS server is upgraded to I n t e r n et
Query = "www.a4.com" Type = "A" support AAAA resource
records based on IPv6 IPv6 www.a6.com
addresses. Internet 2404:6800:8003
Resp = "74.125.43.160" TYPE = "A" www.a4.com in A 74.125.43.160
www.a6.com in AAAA
Query = "www.a4.com" TYPE = "AAAA" 2404:6800:8003::63
Resp = "None" TYPE = "AAAA"
Query = "www.a6.com" TYPE = "A"

An application sends a
request to the DNS server
Resp = "None" TYPE = "A" to query the IPv4 or IPv6
address mapped to a
Query = "www.a6.com" TYPE = "AAAA" specified domain name.
Resp = "2404:6800:8003::63" TYPE = "AAAA"
?.4. CPE
Before customer premises equipment (CPE) is used, the IPv4/IPv6 dual stack must be
supported so that address family transition router (AFTR) addresses can be used to establish
IPv4 over IPv6 tunnels.


NOTE

experience.
group-id 3

group-id 2
section 1 213.1.2.0 213.1.2.200

– Run the ds-lite address-group mask command to configure a public IP address
segment.
group-id 1 213.1.3.0 mask 24

– Run the ds-lite address-group start-end command to configure a public IP address

segment.
group-id 0 213.1.40.0 213.1.40.20
port-range 4096
ds-lite address-group addr-group3 group-id 1
ds-lite outbound 2080 address-group addr-group3
If a DS-Lite public network address pool is configured using the mask mode (recommended),
the length of the advertised routes is the same as configured. If a DS-Lite public network
bits.
After receiving user traffic, the CGN board performs DS-Lite for the traffic in the following
modes:
Run the ds-lite outbound acl-number address-group address-group-name command to
specify an ACL and DS-Lite address pool so that only the packets matching the ACL
rules and with a permit action can implement DS-Lite using the allowed public network
addresses.
Run the ds-lite outbound any address-group address-group-name command to specify
a DS-Lite address pool so that packets do not need to match ACL rules. By default,
addresses from a specified DS-Lite address pool are used for DS-Lite implementation.
that private IP addresses matching an ACL rule are translated by DS-Lite to public IP
specified, DS-Lite will be implemented for all the traffic diverted to the service board
If any (not match ACL rules) is specified for DS-Lite, the CGN device assigns IP addresses
against ACL rules is recommended for DS-Lite.
As shown in Figure 5-78, the ACL matching mode is used to implement DS-Lite.
Specifically, a private IPv6 private address pool is configured, and then DS-Lite is
implemented for the private IP addresses in this address pool. Then the permit network
segment and ip pool network segment are matched, and the ACL 2222 in the DS-Lite instance
huawei1 are bound to the public network group add-group.

Configure an IPv6 ipv6 prefix ipv6-prefix local

prefix. prefix 33::/64
Configure a private ipv6 pool ip-pool bas local

IPv6 address. prefix ipv6-prefix
Configure an ACL to acl ipv6 number 2222

import traffic. rule 0 permit source 33::/64
Configure an HA service-location 1
Configure an HA service-instance-group group1


Configure basic DS- ds-lite filter mode full-cone
service-instance-group group1
ds-lite address-group add-group group-id 1
section 0 210.210.4.0 mask 24
ds-lite outbound 2222 address-group add-group
?.4. NAT Scheme
Two NAT modes are available for a DS-Lite instance.

protocol packets to traverse the DS-Lite device. The 3-tuple mode (full-cone mode) is
5-tupe mode to the 3-tuple mode, run the ds-lite filter mode full-cone command in the DS-
Lite instance view.

#
ds-lite instance huawei id 1
……
……
#
As shown in Table 5-65, centralized Dual-Stack Lite (DS-Lite) supports the following backup
modes:
l Cold backup
l Hot backup
the master service board. In hot backup, high availability (HA) hot backup must be
enabled. For the procedure of configuring hot backup, see Figure 5-79. Either 1:1
master/slave service board backup or 1+1 load balancing mode can be used to deploy
DS-Lite services based on your network plan.

Start

Standby Feature
Configuration

CGN Device

Creating and
configuring a VRRP
Backup Group
Device
HA Backup
Configuration
Setting the Backup
Backup Group to a
Delay
VRRP Backup Group
Configuring
Association Between
Switching Delay
HA and VRRP
Configuring Service
Instance Group
HA Service Feature
Configuration
Binding Service
Instances to a
Service Instance
Group
Binding a Service
HA Backup Group
Compulsory Step
Optional Step
End

Table 5-65 Centralized DS-Lite backup

Mode Technique
Centralized (a DS-Lite Inter-board Supported Supported

CGN device or
a CGN board Inter-chassis Supported Supported
installed on a
BRAS)
Centralized Dual-Stack Lite (DS-Lite) supports the following log formats in source tracing:
l User log
a. (Optional) Run:
type10 }
The DS-Lite syslog log format is set in the system view.

b. Run:
The user log function is enabled in the DS-Lite instance view.

c. Run:
ds-lite log host host-ip-address host-port source source-ip-address
A log host is configured in the DS-Lite instance view.

l Flow log
information.
a. Run:
ds-lite log session enable [ elog | syslog ]
The flow log function is enabled in the DS-Lite instance view.

b. Run:
ds-lite log host host-ip-address host-port source source-ip-address
A log host is configured in the DS-Lite instance view.

c. (Optional) Run:
In centralized DS-Lite scenarios, syslog logs are recommended in log source tracing.


Dual-Stack Lite (DS-Lite) sessions
The maximum number of DS-Lite sessions that can be established is set. This limit
excessive session entries, DS-Lite connections cannot be established for other users.
a. Run:

b. Run:
ds-lite session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based forward DS-Lite sessions that can be

established is set.
c. Run:
ds-lite reverse-session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based reverse DS-Lite sessions that can be

established is set.
l Limit on the number of DS-Lite ports
a. Run:

b. Run:
ds-lite port-limit enable

c. Run:
ds-lite port-limit { tcp | udp | icmp | total } port-number
l Mode of processing non-DS-Lite packets
– Run:

By default, non-DS-Lite packets are transmitted transparently.
DS-Lite public IP address
a. Run:
ds-lite instance instance-name id id

b. Run:
ds-lite ip access-user limit max-number
DS-Lite public IP address is set.
NOTE
l Traffic creation rate control
The rate at which packets are sent to create a flow can be set. If a user initiates an attack,
for an example, a denial of service (DDoS) attack or incorrectly initiates an attack on a
device, the device creates a great number of links for the user within a short period of
time, which consumes lots of resources, adversely affecting other user services.
a. Run:

b. Run:
ds-lite user-session create-rate rate

c. Run:
quit

d. (Optional) Run:
flow is set.
NOTICE

A port number or range can be specified so that DS-Lite does not translate them, which
a. Run:

b. Run:

NOTICE
5.9.5.4.4 Example for Configuring Centralized DS-Lite in a Typical Scenario
Networking Diagram
Figure 5-80 shows centralized DS-Lite networking. A Carrier Grade NAT (CGN) device is
attached to a metropolitan area network (MAN) core router (CR) and equipped with two CGN
boards to implement 1:1 inter-board backup. A terminal user assigned a private IPv4 address
accesses an IPv6 metropolitan area network (MAN) through the customer premises equipment
(CPE). The CPE establishes a Dual-Stack Lite (DS-Lite) tunnel to the CGN device. The CPE
transmits traffic with the private IPv4 address along the DS-Lite tunnel to the CGN device.
The CGN device decapsulates traffic, uses a Network Address Translation (NAT) technique to
translate the private IPv4 address to a public IPv4 address, and forwards traffic to the IPv4
Internet.
Figure 5-80 Typical centralized DS-Lite networking
IPv4 Internet
CR
GE2/0/0
V4/V6双栈
CGN
BRAS
Access
network
OLT OLT
CPE CPE

2. Add the CPU of the master service board to a DS-Lite instance.
3. Configure a local IPv6 address and a remote IPv6 address for a DS-Lite tunnel.
4. Configure a traffic distribution policy for the DS-Lite tunnel.
6. Enable the CGN device to advertise routes.
<CGN> display license
-------------------------------------------------------------
LCR5NATDS00 Resource 256 2M NAT Session
LCR5DSLITE01 Resource 32 DS-Lite License for VSUF
[CGN] License
[CGN-license] active ds-lite vsuf slot 1
[CGN-license] active ds-lite vsuf slot 9
[CGN-license] quit
2. Add the CPU of the master service board to a DS-Lite instance.

[CGN] service-instance-group 1
[CGN-instance-group-1] service-location 1
[CGN-instance-group-1] quit
[CGN] ds-lite instance ds-lite-1 id 1
[CGN-ds-lite-instance-ds-lite-1] service-instance-group 1
[CGN-ds-lite-instance-ds-lite-1] quit
3. Configure a local IPv6 address and a remote IPv6 address for a DS-Lite tunnel.
[CGN] ds-lite instance ds-lite-1
[CGN-ds-lite-instance-ds-lite-1] local-ipv6 240E:3:D000::12 prefix-length 128
[CGN-ds-lite-instance-ds-lite-1] remote-ipv6 240E:A3:D000:: prefix-length 41
[CGN-ds-lite-instance-ds-lite-1] quit
4. Configure a traffic distribution policy for the DS-Lite tunnel.

[CGN] acl ipv6 3500
[CGN-acl6-basic-3500] rule permit ipv6 source 240E:A3:D000:: 41 destination
240E:3:D000::12 128
[CGN-acl6-basic-3500] quit
[CGN] traffic classifier c1
[CGN-classifier-c1] if-match ipv6 acl 3500
[CGN-classifier-c1] quit
[CGN] traffic behavior b1
[CGN-behavior-b1] ds-lite bind instance ds-lite-1
[CGN-behavior-b1] quit
[CGN] traffic policy p1
[CGN-trafficpolicy-p1] classifier c1 behavior b1
[CGN-trafficpolicy-p1] quit
[CGN] interface gigabitethernet 2/0/0
[CGN-GigabitEthernet2/0/0] traffic-policy p1 inbound
[CGN-GigabitEthernet2/0/0] quit


[CGN] ds-lite instance ds-lite-1 id 21
[CGN-ds-lite-instance-ds-lite-1] port-range 4096
[CGN-ds-lite-instance-ds-lite-1] ds-lite address-group group1 group-id 1
[CGN-ds-lite-instance-ds-lite-1-ds-lite-address-group-group1] section 0
10.111.1.1 mask 24
[CGN-ds-lite-instance-ds-lite-1-ds-lite-address-group-group1] quit
[CGN-ds-lite-instance-ds-lite-1] ds-lite outbound 3500 address-group group1
[CGN-ds-lite-instance-ds-lite-1] ds-lite alg all
[CGN-ds-lite-instance-ds-lite-1] ds-lite filter mode full-cone
6. Enable the CGN device to advertise routes.

If a public address pool is configured using a mask, run the network command to
advertise a route. Do not configure a black-hole summary route, which prevents a failure
to forward reverse traffic.

NE40E&NE80E's Device status:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
----------------------------------------------------------------------
10.111.1.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0
<CGN> display ipv6 routing-table 240E:3:D000::12
Routing Table :
Summary Count : 1
Destination : 240E:3:D000::12 PrefixLength : 128

NextHop : ::1 Preference : 64
Interface : InLoopBack0 Flags : D
service location.
service-location 1


<CGN> display nat session-table size slot 1
------------------------------------------------------
TotalSize :64M
UsedSize :32 M
FreeSize :32 M

---------------------------------------------------------------
Slot: 1 Engine: 0
Total number: 2.
---------------------------------------------------------------------------
User Type : Ds-Lite
IPv6Address : 240E:A3:D000::0221:0:0200:0001/128
User ID : -
VPN Instance : -
Address Group : group1
DS-Lite Instance : ds-lite-1
Public IP : 10.111.1.2
Start Port : 1024
Port Range : 4096
Port Total : 4096
Rbp Index/Rbp Status : 0/0/0
Token/TB/TP : 0/0/0
Aging Time(s) : -
Left Time(s) : -
-->Drop Packets : 0
--------------------------------------------------------------
Slot: 1 Engine: 0
udp: 192.168.1.2:28195[10.111.1.2:1723]--> *:*
udp: 192.168.1.2:20069[10.111.1.2:1727]--> *:*
udp: 192.168.1.2:59556[10.111.1.2:1085]--> *:*
Slot: 9 Engine: 0

udp: 192.168.1.2:28195[10.111.1.2:1723]--> *:*

udp: 192.168.1.2:20069[10.111.1.2:1727]--> *:*
udp: 192.168.1.2:59556[10.111.1.2:1085]--> *:*
Slot: 1 Engine: 0
----------------------------------------------------------------------
----------------------------------------------------------------------
Slot: 1 Engine: 0
----------------------------------------------------------------------
---------------------------------------------------------------------
5.9.5.4.5 Live Network Deployment Example
?.1. Deployment Solution of Dual-Device Cold Backup in a Centralized DS-Lite

Scenario
Solution Overview
In Figure 5-81, the deployment of centralized Dual-Stack Lite (DS-Lite) dual-device cold
backup is as follows:
l Traffic distribution policy:
Address family transition router (AFTR) addresses are advertised. The priority of the
AFTR address advertised by the master CGN device is higher. Policy-based routing does
not need to be configured on core routers (CRs). The master CGN device advertises
Network Address Translation (NAT) address pool routes.
l Backup policy:
CPUs of two CGN devices form a high availability (HA) backup group.
l Fault-triggered switchover:
An HA Virtual Router Redundancy Protocol (VRRP) switchover is performed if the
CGN link, interface board, or CGN board fails. The switchover process is similar to that
in a NAT444 scenario.
In the case of a link or interface board failure, route convergence takes place prior to an
HA VRRP switchover. During the traffic switchover, traffic is diverted to the master
CGN device for NAT processing.

Figure 5-81 Deployment of dual-device cold backup in a centralized DS-Lite scenario
Master AFTR
Local-IPv6
BRAS1 CR1 PE1

IGW
P
HA/VRRP Core
network
BRAS2 CR2 PE2 IGW
Local-IPv6
Slave AFTR

No. Configurati Master Device Slave Device
on
Procedure
1 Configure interface interface

VRRP on an undo shutdown undo shutdown
intermediate ip address 10.0.0.1 ip address 10.0.0.2
link. 255.255.255.0 255.255.255.0
vrrp vrid 20 virtual-ip vrrp vrid 20 virtual-ip
10.0.0.3 10.0.0.3
admin-vrrp vrid 20 admin-vrrp vrid 20
ignore-if-down ignore-if-down
//This command must be vrrp vrid 20 priority 100
run to prevent the VRRP vrrp vrid 20 preempt-
status from becoming mode timer delay 400
abnormal. vrrp vrid 20 track
vrrp vrid 20 priority 150 interface
vrrp vrid 20 preempt- GigabitEthernet3/1/6
mode timer delay 400 reduced 50
vrrp vrid 20 track //The VRRP group is
interface associated with a network-
GigabitEthernet3/1/6 side interface.
reduced 60 vrrp vrid 20 track
//The VRRP group is interface
associated with a network- GigabitEthernet1/0/1
side interface. reduced 50
vrrp vrid 20 track //The VRRP group is
interface associated with a user-
GigabitEthernet1/0/1 side interface.
reduced 60 vrrp vrid 20 track
//The VRRP group is service-location 21
associated with a user- reduced 50
side interface.
vrrp vrid 20 track
service-location 21
reduced 50
2 Configure an service-location 21 service-location 21

location slot 4 card 0 location slot 4 card 0
HA backup remote-backup interface remote-backup interface
group. GigabitEthernet3/1/7.1 GigabitEthernet3/1/7.1
peer 10.0.0.2 peer 10.0.0.1
//The local interface of
an intermediate VRRP link.
3 Configure an service-instance-group service-instance-group

service-group service-
HA instance service-location 21 group
group and
bind it to the service-location 21
backup
group.

No. Configurati Master Device Slave Device

on
Procedure
4 Configure ds-lite instance ds- ds-lite instance ds-

lite-2 id 21 lite-2 id 21
basic DS-Lite port-range 4096 port-range 4096
functions. service-instance-group service-instance-group
service-group service-group
ds-lite address-group ds-lite address-group
group1 group-id 1 group1 group-id 1
section 0 60.1.1.1 section 0 60.1.1.1
mask 24 mask 24
ds-lite outbound any ds-lite outbound any
address-group group1 address-group group1
local-ipv6 240E: local-ipv6 240E:
3:D000::12 prefix-length 3:D000::12 prefix-length
128 128
remote-ipv6 remote-ipv6
240E:A3:D000:: prefix- 240E:A3:D000:: prefix-
length length
41 41
ds-lite alg all ds-lite alg all

ds-lite filter mode full- ds-lite filter mode full-
cone cone
acl ipv6 3500 acl ipv6 3500

rule permit ipv6 source rule permit ipv6 source
240E:A3:D000:: 41 240E:A3:D000:: 41
destination 240E: destination 240E:
3:D000::12 128 3:D000::12 128
5.9.5.5 Centralized NAT64 Solution Deployment Guide
NAT64 supports only centralized deployment, that is, NAT64 is deployed on the CR side.
According to whether the DNS64 server exists on the network, NAT64 can be deployed in the
following modes:
l Centralized NAT64 on a network with a DNS64 server deployed
If the DNS64 server exists on the network, you do not need to enable NAT64 DNS ALG.
Figure 5-82 shows the networking and data traffic path.

Figure 5-82 DNS64 server deployment on the network
IPv4 Network
DNS64 Server
IPv6 Netwok IPv4 Service Server
IPv6 PC SWITCH BRAS NAT64 CGN/CR

IPv6 Network
IPv6 Service Server
The data traffic path when an IPv6 PC accesses the IPv4 service server
– When an IPv6 PC accesses the IPv4 service server, data traffic path and processing
are described as follows:
i. IPv6 PC sends DNS request packet to DNS4 Server and IPv6 data traffic
passes SWITCH, BRAS, DNS64 Server.
ii. DNS64 Server sends DNS resolution packet to IPv6 PC and IPv6 data traffic
passes BRAS, switch, IPv6 PC.
iii. IPv6 PC sends DNS request packet to DNS64 Server and IPv6 data traffic
passes switch, BRAS, DNS64 Server.
iv. DNS64 Server sends DNS resolution packet to IPv6 PC and IPv6 data traffic
v. IPv6 data traffic is sent from the IPv6 PC and passes through the switch,
BRAS, and NAT64 CGN/CR.
vi. On the NAT64 CGN/CR device, NAT64 is performed to convert IPv6 data
traffic into IPv4 data traffic.
vii. IPv4 data traffic is sent by the NAT64 CGN/CR device to the IPv4 service
server.
– When the IPv6 PC accesses the IPv6 service server, data traffic path and processing
are described as the same as that when an IPv6 PC assess the IPv4 service server.

l Centralized NAT64 on a network without a DNS64 server deployed

When the DNS64 server does not exist on the network, you need to enable NAT64 DNS
ALG. Figure 5-83 shows the networking and data traffic path.
Figure 5-83 NAT64 DNS ALG networking
IPv4 Network
DNS4 Server
IPv6 Network
IPv4 Service Server
IPv6 PC SWITCH BRAS NAT64 CGN/CR

IPv6 Network
IPv6 Service Server
DNS6 Server
– When an IPv6 PC accesses the IPv4 service server, data traffic path and processing
are described as follows:
i. IPv6 PC sends DNS request packet to DNS4 Server and IPv6 data traffic
passes switch, BRAS, DNS4 Server.
ii. DNS4 Server sends DNS resolution packet to IPv6 PC and IPv6 data traffic
iii. IPv6 data traffic is sent from the IPv6 PC and passes switch, BRAS, and
NAT64 CGN/CR.
iv. On the NAT64 CGN/CR device, NAT64 is performed to convert IPv6 data
v. IPv4 data traffic is sent from the NAT64 CGN/CR device to the DNS4 server.
vi. IPv4 data traffic is returned to the DNS4 server and forwarded to the NAT64
CGN/CR device.
vii. On the NAT64 CGN/CR device, NAT64 is performed to convert IPv4 data

viii. IPv6 data traffic is sent from the IPv6 PC and passes through BRAS, switch,
and IPv6 PC.
ix. IPv6 data traffic is sent from the IPv6 PC and passes through switch, BRAS,
and NAT64 CGN/CR.
x. On the NAT64 CGN/CR device, NAT64 is performed to convert IPv6 data
xi. IPv4 data traffic is sent from the NAT64 CGN/CR device to the IPv4 service
server.
– When the IPv6 PC accesses the IPv6 service server, data traffic path and processing
are described as the same as that when an IPv6 PC assess the IPv4 service server.
Item Solution 1: Centralized NAT64 Solution 1: Centralized NAT64 on

on a Network With a DNS64 a Network Without a DNS64
Server Deployed Server Deployed
Deploymen 1. A new NE40E&NE80E A new NE40E&NE80E equipped

t equipped with an interface with an interface board and two
board and two NAT64 boards is NAT64 boards is deployed.
deployed.
2. An existing DNS server is
upgraded to a DNS64 server.
Advantage 1. A CGN device does not need to The DNS server does not need to be
be enabled with the DNS ALG upgraded.
function, and the DNS64 server
independently processes
DNS64 packets, providing high
performance.
2. The CPE only initiates a single
DNS request to relieve the CPE
burden.
Disadvanta The DNS server must be upgraded. 1. The CGN device needs to be
ge enabled with the DNS ALG
function and process both NAT64
and DNS64 packets, which
reduces performance.
2. The CPE performs two times of
DNS query, which reduces
efficiency.
3. The CPE must support multiple
DNS servers.
The comparison shows that solution 1 has more advantages and therefore is recommended. If
a customer does not want to deploy a DNS64 server, solution 2 can be used.




following command:
[HUAWEI] license
engine 0

operations:
[HUAWEI] license
engine 0

operations:
[HUAWEI] license
engine 0

NE40E&NE80E NAT64 Board The NAT64 function is disabled by

function default. To enable the NAT64
operations:
[HUAWEI] license
[HUAWEI-license] active nat64
slot 1

2M session tables are allocated
each time.
For the VSUF-40/80/160, each
CPU supports a maximum of 16M
NAT sessions. For the VSUI-160-E,
each CPU supports a maximum of
32 M NAT sessions. To configure
the number of NAT sessions
allocated to the base CPU or
subcard CPU, perform the
following operations:
[HUAWEI] license
engine 0

Product Version
NE40E&NE80E V600R009C10
iManager U2000
Power consumption

NOTE
installed.
Subcard Application
VSUF-160.
NOTE


(Gbit/s) with
Subcards
(Gbit/s)
200 NE40 VSUF 40/40/80 25/25/50 NA/80/160 NA/50/100

Gbit/s E&NE -40/80
platfor 80E- /160
m X8
NE40
E&NE
80E-
X16
40 NE40 VSUF 40 25 NA/80 NA/50

Gbit/s E&NE -40/80
platfor 80E-
m X8
NE40
E&NE
80E-
X16
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-
X3
NE40 VSUF 40 25 NA/80 NA/50

E&NE -40/80
80E-1
6
20 NE40 VSUF 15 15 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-8
m
10 NE40 VSUF 10 10 N/A N/A

Gbit/s E&NE -40/80
platfor 80E-1
m 6

?.6. Service Evaluation
A specific solution must be provided when Network Address Translation IPv6-to-IPv4

(NAT64) is used process some services.
Since IPv6 services are not mature and a few software applications support IPv6. Table 5-69
describes limitations on IPv6 applications.

Table 5-69 Limitations on IPv6 applications

No. Restrictions Impact Impact
Severit
y
1 NAT64 HTTP application Mediu Users cannot access video resources on

level gateway (ALG) m some web pages.
limitations:
1. Only allows a video
website to use port 301
or 302 to send
response packets to
redirect users to video
resources.
2. Supports video
websites on the public
network side only.
2 Does not support Session Mediu Voice over Internet Protocol (VoIP) software
Initiation Protocol (SIP) m or RTSP-supported video software are
ALG or Real-Time unavailable.
Streaming Protocol
(RTSP) ALG.
3 Does not support other Mediu P2P download software or chatting tools are
ALG applications, such as m unavailable.
P2P or MSN applications.
4 NAT64 DNS ALG does Mediu NAT64 is unavailable if a DNS server is on

not support a DNS server m the user-side of a NAT64 server.
on the user-side of a
NAT64 server.
Port Pre-Allocation
In port range mode, a CGN device randomly assigns a user a public IP address and a port
range so that NAT sessions of the same host can share an external IP address and the
possibility that users concurrently going online are assigned the same external IP address is
minimized.
ALG
Most application layer protocol packets carry user IP addresses and port numbers. NAT
translates only network layer addresses and transport layer ports. Therefore, an ALG can be
configured to translate IP addresses and port numbers carried in the Data field of application
layer packets. The NAT ALG function implements transparent translation for some
application layer protocols.
3-Tuple
A device creates 3-tuple entries, including the source IP address, source port number, and
protocol type, to allocate IP addresses and filter packets. This mode does not involve the

translation of the destination IP address and port number. A device uses NAT64 to translate
packets carrying the same source IP address and port number to the same public IP address
and port number. In addition, the device allows public network hosts to use the translated IP
address and port number to visit the internal network host.
The 3-tuple mode addresses NAT issues of P2P services.
?.1. DNS64 Server
Network Address Translation IPv6-to-IPv4 (NAT64) can be configured if a domain name

system IPv6&IPv4 (DNS64) server is used to convert between DNS AAAA and AAA
requests.
?.2. Log Server
NOTE

NOTE

experience.


[HUAWEI-nat64-instance-nat64-1] nat64 address-group addr-group4 group-id
3
[HUAWEI-nat64-instance-nat64-1-nat64-address-group-add-group3] section 2
213.1.1.0 mask 24

2
[HUAWEI-nat64-instance-nat64-1-nat64-address-group-add-group3] section 1
213.1.2.0 213.1.2.200

– Run the nat64 address-group mask command to configure a public IP address
segment.
1 213.1.3.0 mask 24
– Run the nat64 address-group start-end command to configure a public IP address

segment.
0 213.1.40.0 213.1.40.20
nat64 instance huawei1 id 1
nat64 filter mode full-cone
port-range 4096
nat64 address-group addr-group3 group-id 1
nat64 outbound 2080 address-group addr-group3
If a NAT64 public network address pool is configured using the mask mode (recommended),
the length of the advertised routes is the same as configured. If a NAT64 public network
bits.
After receiving user traffic, the Carrier Grade NAT (CGN) board performs Network Address
Translation IPv6-to-IPv4 (NAT64) for traffic in the following modes:


Run the nat64 outbound acl-number address-group address-group-name command to
specify an access control list (ACL) and NAT64 address pool so that only the packets
matching the ACL rules and with a permit action can implement NAT64 using the
allowed public network addresses.
Run the nat64 outbound any address-group address-group-name command to specify
a NAT64 address pool so that packets do not need to match ACL rules. By default,
addresses from a specified NAT64 address pool are used for NAT64 implementation.
that private IP addresses matching an ACL rule are translated by NAT64 to public IP
specified, NAT64 will be implemented for all the traffic diverted to the service board
If any (not match ACL rules) is specified for NAT64, the CGN device assigns IP addresses
against ACL rules is recommended for NAT64.
If ACL rules are used to match traffic in the NAT process, specify a private IPv6 network
segment in an IP address pool. Enable the device to match the network segment permitted in
ACL rules against the network segment in the IP address pool. Bind the ACL numbered 2222
to a public address group named add-group in a NAT64 instance named huawei1.
Matching traffic against ACL rules is used when NAT64 processes packets matching ACL
rules that define source IP addresses and a NAT64 IPv6 address prefix used as the destination
IP address. The following example describes how to configure NAT64 to process packets
matching ACL rules.
#
acl ipv6 number 3000
rule 10 permit ipv6 source 2068::/64 destination 64:FF9B::/
96
#
service-location 1
service-location 1
#
nat64 instance huawei id 1
port-range 4096
nat64 address-group 1 group-id 1
section 0 210.210.X.0 mask 24
nat64 outbound 3000 address-group 1
nat64 prefix 64£ºff9b:: prefix-length 96 1
#
?.4. NAT Scheme



protocol packets to traverse the NAT64 device. The 3-tuple mode (full-cone mode) is
5-tupe mode to the 3-tuple mode, run the nat64 filter mode full-cone command in the
NAT64 instance view.
#
nat64 instance huawei id 1
……
……
#

As shown in Table 5-70, centralized Network Address Translation IPv6-to-IPv4 (NAT64)
supports the following backup modes:
l Cold backup
NOTE
Cold backup is used only in inter-chassis backup scenarios.

l Warm backup
on the master service board. In warm backup, a few resources are used on the slave
service board. If warm backup is used, bind each service board to two service instances
to perform 1+1 load balancing.
l Hot backup
the master service board. In hot backup, the volume of resources used on the slave
service board is the same as that on the master service board. In hot backup, high
availability (HA) hot backup must be enabled. For the procedure of configuring hot
backup, see Figure 5-84. Either 1:1 master/slave service board backup or 1+1 load
balancing mode can be used to deploy NAT64 services based on your network plan.

Start

Standby Feature
Configuration

CGN Device

Creating and
configuring a VRRP
Backup Group
Device
HA Backup
Configuration
Setting the Backup
Backup Group to a
Delay
VRRP Backup Group
Configuring
Association Between
Switching Delay
HA and VRRP
Configuring Service
Instance Group
HA Service Feature
Configuration
Binding Service
Instances to a
Service Instance
Group
Binding a Service
HA Backup Group
Compulsory Step
Optional Step
End

Table 5-70 Centralized NAT64 backup

Mode Technique
Centralized (a NAT64 Inter-board Supported Supported

CGN device or
a CGN board Inter-chassis Supported Supported
installed on a
BRAS)
Centralized Network Address Translation IPv6-to-IPv4 (NAT64) supports the following log
formats in source tracing:
l User log
a. (Optional) Run:
type10 }
The NAT64 syslog log format is set in the system view.

b. Run:
The user log function is enabled in the NAT64 instance view.

c. Run:
nat64 log host host-ip-address host-port source source-ip-address source-
A log host is configured in the NAT64 instance view.

l Flow log
information.
a. Run:
nat64 log session enable [ elog | syslog ]
The flow log function is enabled in the NAT64 instance view.

b. (Optional) Run:
nat64 log host host-ip-address host-port source source-ip-address source-
A log host is configured in the NAT64 instance view.

c. Run:

In centralized NAT64 scenarios, syslog logs are recommended in log source tracing.
l Limit on the number of forward (user-to-network) and reverse (network-to-user)

Network Address Translation IPv6-to-IPv4 (NAT64) sessions that can be
established
The maximum number of NAT64 sessions that can be established can be set. This limit
excessive session entries, NAT64 connections cannot be established for other users.
a. Run:
nat64 instance instance-name [ id id ]
The NAT64 instance view is displayed.

b. Run:
nat64 session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based forward NAT64 sessions that can be

established is set.
c. Run:
nat64 reverse-session-limit { tcp | udp | icmp | total } session-number
The maximum number of user-based reverse NAT64 sessions that can be

established is set.
NAT64 public IP address
a. Run:
nat64 instance instance-name id id

b. Run:
nat64 ip access-user limit max-number
NAT64 public IP address is set.
NOTE
of NAT64 sessions for each of private network users sharing a public IP address, user traffic may
fail to be forwarded. As a result, the number of users who attempt to use single public IP addresses
to get online is reduced.
A port number or range can be specified so that NAT64 does not translate them, which
a. Run:
nat64 instance instance-name [ id id ]

b. Run:

NOTICE
The port number and range filtering function is configured only if needed. Configuring
this function affects user access to the Internet.
5.9.5.5.4 Example for Configuring Centralized NAT64 in a Typical Scenario
Networking Diagram
Figure 5-85 shows a centralized NAT64 network. A Carrier Grade NAT (CGN) device is
attached to a metropolitan area network (MAN) core router (CR) and equipped with two CGN
boards. IPv6 users access the IPv4 network through a BRAS, CR, and NAT64 CGN device in
sequence. The NAT64 CGN device translates IPv6 addresses of enterprise users to external
IPv4 addresses so that the enterprise users can access the IPv4 Internet.
Figure 5-85 Typical centralized NAT64 networking
IPv4 Core Network
DNS64 Server
CR
NAT64
CGN
BRAS
Metro-E
CPE CPE
PC PC

1. Load a Global Trotter License (GTL) that enables NAT64 and configure NAT64 sessions
on service boards.
2. Add the CPU of the master service board to a NAT64 instance.
3. Configure an ACL.
4. Configure basic NAT64 functions.
5. Configure a traffic classification rule, a NAT64 traffic behavior, and a NAT64 traffic
distribution policy, and apply the NAT64 traffic distribution policy.
6. Enable the NAT64 device to advertise public routes.
1. Load a GTL that enables NAT64 and configure NAT64 sessions on service boards.
<CGN> display license
-------------------------------------------------------------
LME0NAT6401 Resource 32 NAT64 License for VSUF
..................................................
Item name (View)Resource License Command-line
-------------------------------------------------------------
LME0NATDS00 (Sys)nat session-table size table-size slot slot-id
Master board license state: Normal.
[CGN] License
[CGN-license] active nat64 vsuf slot 4
[CGN-license] active nat64 vsuf slot 14
[CGN-license] quit
2. Add the CPU of the master service board to a NAT64 instance.

[CGN] service-instance-group 1
[CGN-instance-group-1] service-location 1
[CGN-instance-group-1] quit
[CGN] nat64 instance nat64-1 id 1
[CGN-nat64-instance-nat64-1] service-instance-group 1
[CGN-nat64-instance-nat64-1] quit
3. Configure an ACL.
[CGN] acl ipv6 number 3000
[CGN-acl6-adv-3000] rule 5 permit ipv6 source 2001:e68::1:1112/126
destination 64:FF9B::C0A8:85/96
[CGN-acl6-adv-3000] quit
NOTE
A NAT64 user packet's destination IP address is a combination of an IPv4 address and a NAT64
prefix. Therefore, specify the source and destination IP addresses in the ACL rule.
4. Configure basic NAT64 functions.
[CGN] nat64 instance nat64-1 id 1
[CGN-nat64-instance-nat64-1] port-range 4096
[CGN-nat64-instance-nat64-1] nat64 alg ftp
[CGN-nat64-instance-nat64-1] nat64 alg http
[CGN-nat64-instance-nat64-1] nat64 address-group nat64-group1 group-id 1
[CGN-nat64-instance-nat64-1-nat64-address-group-nat64-group1] section 0
10.38.160.0 mask 24

[CGN-nat64-instance-nat64-1-nat64-address-group-nat64-group1] quit
[CGN-nat64-instance-nat64-1] nat64 outbound 3000 address-group nat64-group1
[CGN-nat64-instance-nat64-1] nat64 log host 138.78.100.5 514 source 2.2.2.2
514 name loghost
[CGN-nat64-instance-nat64-1] nat64 log user enable
[CGN-nat64-instance-nat64-1] nat64 filter mode full-cone
[CGN-nat64-instance-nat64-1] nat64 prefix 64:FF9B:: prefix-length 96 1
5. Configure a traffic classification rule, a NAT64 traffic behavior, and a NAT64 traffic
distribution policy, and apply the NAT64 traffic distribution policy.
a. Configure an ACL-based traffic classification rule so that only hosts on internal
network segment 64:FF9B/96 can access the network segment 192.168.0.133/30 on
the IPv4 Internet.
[HUAWEI] acl ipv6 number 3003
[HUAWEI-acl6-adv-3003] rule 5 permit ipv6 source 2001:e68::1:1112/126
destination 64:FF9B::C0A8:85/96
[HUAWEI-acl6-adv-3003] quit
b. Configure a traffic classifier.

[HUAWEI] traffic classifier c1
[HUAWEI-classifier-c1] if-match ipv6 acl 3003
[HUAWEI-classifier-c1] quit
c. Configure a traffic behavior and bind the traffic behavior to a NAT64 instance.
[HUAWEI] traffic behavior b1
[HUAWEI-behavior-b1] nat64 bind instance nat64-1
[HUAWEI-behavior-b1] quit
NOTE
If multiple behavior settings are configured, packets are matched against them in a top-to-
bottom order.
d. Configure a NAT64 traffic policy and associate the ACL-based traffic classification
rule with the traffic behavior.
[HUAWEI] traffic policy p1
[HUAWEI-trafficpolicy-p1] classifier c1 behavior b1
[HUAWEI-trafficpolicy-p1] quit
e. Configure an IPv6 address in the user-side interface view.

[HUAWEI] interface GigabitEthernet 2/0/1
[HUAWEI-GigabitEthernet2/0/1] ipv6 enable
[HUAWEI-GigabitEthernet2/0/1] ipv6 address 2001:e68::1:110e 126
f. Apply the NAT64 traffic distribution policy in the user-side interface view.
[HUAWEI] interface GigabitEthernet 2/0/1
[HUAWEI-GigabitEthernet2/0/1] traffic-policy p1 inbound
[HUAWEI-GigabitEthernet2/0/1] quit
6. Enable the NAT64 device to advertise public routes.

The NAT64 device must advertise private prefix routes and public address pool rules.
VPNs are not supported.

NE40E-X16's Device status:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


---------------------------------------------------------------------
10.38.160.0/24 Unr 64 10 D 127.0.0.1 InLoopBack0
<BRAS> display ipv6 routing-table 64:FF9B::

Summary Count : 1
Destination : 64:FF9B:: PrefixLength : 96

NextHop : ::1 Preference : 64
Interface : InLoopBack0 Flags : D
service location.
<CGN> display service-location 1
dis service-location 1
service-location 1
<CGN> display nat session-table size slot 1
-----------------------------------------------------------------
TotalSize :64M
UsedSize :32 M
FreeSize :32 M

--------------------------------------------------------------
<CGN> display nat user-information slot 1 verbose
Slot: 1 engine: 0
Total number: 2.
--------------------------------------------------------
User Type : NAT64

IPv6Address : 2068::0002/128
User ID : -
VPN Instance : -
Address Group : nat64-group1-1
NoPAT Address Group : -
NAT64 Instance : nat64-1
Public IP : 10.38.160.10
NoPAT Public IP : 0.0.0.0
Start Port : 1024
Port Range : 4096
Port Total : 4096
MTU : 1500
Nat ALG Enable : FTP/HTTP
Token/TB/TP : 0/0/0
Aging Time(s) : -
Left Time(s) : -
-->Drop Packets : 0
<--Drop Packets : 0
---------------------------------------------------------------
Slot: 4 engine: 0
Current total sessions:3.
icmp: [2068::0002]:200(10.38.160.10:200)--> *:32768
udp: [2068::0002]:-( 10.38.160.10:-)-->[2091::]:-(0.0.0.0:-), frag_ID:100
udp: [2068::0002]:1024(10.38.160.10:1024)--> *:*
Slot: 1 Engine: 0
-----------------------------------------------------------------
----------------------------------------------------------------
Slot: 1 Engine: 0
-------------------------------------------------------------------
SYSLOG packets transmitted :0
--------------------------------------------------------------------

5.9.6 Appendix
5.9.6.1 CGN Log Format
In comparison with BRAS-based user access, CGN-based user access fails to precisely locate
the host or user that initiates a login attempt because the source IP address of data packets is
processed using NAT. Therefore, using CGN devices to access the network may lead to
security vulnerabilities. To solve this problem, CGN logs are used. CGN logs record the
mapping between private and public IP addresses used for NAT, which helps to trace the
source private IP address mapped to the source public IP address and subsequently query and
track network activities and operations. The use of CGN logs improves network availability
and security.
The CGN logs supported by CGN devices can be categorized as user logs and flow logs.
User Logs
User logs are generated when a user goes online or offline and when public ports are being
incrementally allocated to users or the incrementally allocated ports are being reclaimed.
Generally, user logs record the time when a user goes online or offline, the private and public
IP addresses of the user, and the range of NAT ports allocated to the user.
Flow Logs
Flow logs, which are generated based on sessions, record the behaviors that a user accesses
network applications. A flow creation log is generated when a new session is created, and a
flow aging log is generated when a session ends. Generally, flow logs record the time a
session is created, the time a session ages, the source and destination IP addresses and port
numbers of a session, the public source IP address and port number after NAT, and the
application layer protocol.
NOTE
A user can connect to or disconnect from multiple network applications at a time or the same network
application for multiple times. Therefore, the number of flow logs would be far greater than the number
of user logs. When user tracing is performed based on logs, you are advised to use user logs.
5.9.6.1.1 User Log Format

User logs are generated when a user goes online or offline and when public ports are being
incrementally allocated to users or the incrementally allocated ports are being reclaimed.
CGN user logs can be divided into three types: syslog, RADIUS log, and NetStream log.
?.1. User Syslog Formats

User syslogs are sent by CGN devices deployed in either distributed or centralized mode.
User syslogs are sent to log servers in text format.

Example User Syslog in cn Format
Table 5-71 Log syntax

Scenario Log Syntax
NAT444/L2NAT <PRI> VERSION TIMESTAMP

HOSTNAME APPNAME -
NAT444:MSGID [- INNERIP - OUTERIP -
STARTPORT ENDPORT]
DS-Lite <PRI> VERSION TIMESTAMP

HOSTNAME APPNAME -
DSLITE:MSGID [- - INNERIP OUTERIP -
STARTPORT ENDPORT]
NAT64(NO-PAT) <PRI> VERSION TIMESTAMP

HOSTNAME APPNAME - NAT64:MSGID
[- - INNERIP OUTERIP - - -]
NAT64(PAT) <PRI> VERSION TIMESTAMP

HOSTNAME APPNAME - NAT64:MSGID
[- - INNERIP OUTERIP - STARTPORT
ENDPORT]
LAFT6 <PRI> VERSION TIMESTAMP

HOSTNAME APPNAME -
LAFT6:MSGID [- - INNERIP OUTERIP -
STARTPORT ENDPORT]
Table 5-72 Description of log syntax fields

Field Description
PRI Priority. It is fixed at 134.
VERSION Version number. It is fixed at 1.
TIMESTAMP Timestamp defined in RFC 3339 in the

format of <year> <month> <day>
<hour:minute:second>.
HOSTNAME Source IP address of the device sending user

syslog packets.
APPNAME Name of the device sending user syslog

packets.
MSGID Packet type
INNERIP Private network address of a subscriber.
OUTERIP Public IP address of a subscriber.

Field Description
STARTPORT Start port number. The value is 0 if the nat-

server-only command is run to support only
the internal NAT server services in a NAT
instance.
ENDPORT End port number. The value is 65535 if the

nat-server-only command is run to support
only the internal NAT server services in a
NAT instance.
Example NAT444-based user syslog in cn format:

l <134> 1 2014 Aug 11 10:50:39 190.93.11.225 _nohostname - NAT444:SessionA [-
192.0.100.11 - 16.0.101.2 -1024 1103]
Example User Syslog in Type2 Format

Scenario Log Syntax
NAT444/L2NAT/DS-Lite/NAT64(PAT)/ <PRI> VERSION TIMESTAMP

NAT64(NO-PAT)/LAFT6 HOSTNAME APPNAME -
<SCENARIO>:<MSGID> STARTTIME |
INNERIP|OUTERIP|STARTPORT|
ENDPORT

Field Description
TIMESTAMP Timestamp defined in RFC 3339 in the


syslog packets.
APPNAME Name of the device sending user syslog

packets.

Field Description
SCENARIO NAT scenario:

l NAT444
l L2NAT
l DSLITE
l NAT64
l LAFT6
MSGID Packet type:

l PortA: The user is applying for a public
IP address and port.
l PortW: The user is releasing a public IP
address and port.
STARTTIME Number of seconds since January 1, 1970,

00:00 (UTC).
INNERIP Private IP address of a user.
OUTERIP Public IP address of a subscriber
STARTPORT Start port number. In a NAT64 (no-PAT)

scenario, the value is 0. The value is 0 if the
NAT instance.
ENDPORT End port number. In a NAT64 (no-PAT)

scenario, the value is 0. The value is 65535
if the nat-server-only command is run to
support only the internal NAT server
services in a NAT instance.
Example NAT444-based user syslog in type2 format:

l <142> 1 <2012> <May> <05> <12:05:01> 15.15.15.1 _nohostname -
<NAT444>:<PortA> 1336190701|172.100.1.250|33.33.11.2|1088|2111


Scenario Log Syntax
NAT444/L2NAT <PRI>VERSION TIMESTAMP1

HOSTNAME - - NAT444userbased - %
%SYSLOGVERMODULENAME/
LOGLEVEL/
LOGINFOMNEM(LOGTYPE):
USERORINCTYPE, in SCENARIO scene.
privateip='PRIVATEIP' srcvrfid='VRFID'
publicip='PUBLICIP'
publicportrange='STARTPORT~ENDPORT'
time='TIMESTAMP2'
DS-Lite <PRI>VERSION TIMESTAMP1

HOSTNAME - - DS-LITEuserbased - %
LOGLEVEL/
privateip='PRIVATEIP/LEN'
srcvrfid='VRFID' publicip='PUBLICIP'
time='TIMESTAMP2'
NAT64 <PRI>VERSION TIMESTAMP1

LOGLEVEL/
privateip='PRIVATEIP/128'
time='TIMESTAMP2'
LAFT6 <PRI>VERSION TIMESTAMP1

HOSTNAME - - LAFT6userbased - %
LOGLEVEL/
privateip='PRIVATEIP/LEN'
time='TIMESTAMP2'


Field Description
PRI Priority. It is fixed to 134.
VERSION Version number. It is fixed to 1.
TIMESTAMP1 Timestamp defined in RFC 3339 in the


syslog packets.
SYSLOGVER The fixed value is 1.
MODULENAME The fixed value is SEC.
LOGLEVEL Log level. The fixed value is 6.
LOGINFOMNEM The value is fixed to BIND.
LOGTYPE The value is fixed to L.
USERORINCTYPE The available options are as follows:

l "An initial port range is assigned"
l "An initial port range is freed"
l "An increase port range is assigned"
l "An increase port range is freed"
l "An initial portrange keepalive"
l "An increase portrange keepalive"

l nat444
l l2nat
l dslite
l nat64
l laft6
privateip Private IP address of a user.
LEN Length of an IPv6 prefix.
VRFID VRF index.
publicip Public IP address of a subscriber
STARTPORT Start port number. In a NAT64 (no-PAT)

scenario, the value is 0. The value is 0 if the
NAT instance.

Field Description
ENDPORT End port number. In a NAT64 (no-PAT)

scenario, the value is 0. The value is 65535
if the nat-server-only command is run to

<hour:minute:second>. The default value is
UTC time. If the local-timezone command
is specified in the nat syslog descriptive
format type3 command, this parameter
specifies the local device time.

l <134>1 2012-10-22T15:55:03Z 10.21.1.2 - - NAT444userbased - %%01SEC/6/
BIND(L): An increase portrange is freed, in nat444 scene. privateip='192.85.1.2'
srcvrfid='0' publicip='11.11.11.1' publicportrange='1152~1279' time='2012-10-22
15:55:03'
Example User Syslog in type4 Format

Scenario Log Syntax
NAT444/L2NAT/DS-Lite/ Port allocation <PRI>TIMESTAMP

NAT64 [FWNAT]:MSGID:
INNERIP ->
OUTERIP:STARTPORT-
ENDPORT\n
Port reclaim <PRI>TIMESTAMP

[FWNAT]:MSGID:
INNERIP ->
OUTERIP:STARTPORT-
ENDPORT STARTTIME\n

Field Description
PRI Priority. The fixed value is 150.

Field Description
TIMESTAMP Timestamp in the format of <year>

<month> <day> <hour:minute:second>,
defined in RFC 3339.
FWNAT Fixed value.
MSGID Packet type:

l ASP_NAT_PORT_BLOCK_ALLOC: A
user requests the outer IP address and
port number.
l ASP_NAT_PORT_BLOCK_RELEASE:
A user releases the outer IP address and
port number.
INNERIP A user's private network address
OUTERIP A user's public network address
STARTPORT Start public network port number. The value

is 0 in the NAT64(NO-PAT) scenario. The
value is 0 if the nat-server-only command
is run to support only the internal NAT
server services in a NAT instance.
ENDPORT End public network port number. The value

is 0 in the NAT64(NO-PAT) scenario. The
value is 65535 if the nat-server-only
command is run to support only the internal
NAT server services in a NAT instance.
STARTTIME Number of seconds since January 1, 1970,

00:00 (UTC), indicating the time when
address/port release is implemented. The
value is in hexadecimal notation.

l <150>2015-01-11 15:09:11 [FWNAT]:ASP_NAT_PORT_BLOCK_ALLOC:
100.118.72.212 -> 213.24.126.212:35008-35071\n
l <150>2015-01-11 15:16:39 [FWNAT]:ASP_NAT_PORT_BLOCK_RELEASE:
100.118.72.212 -> 213.24.126.212:35008-35071 0x54b29217\n

Example User Syslog in type5 Format

Scenario Log Syntax
NAT444/L2NAT/DS-Lite PRI VERSION HOSTNAME

TIMESTAMP APPNAME PROCID
MSGID STARTTIME|INNERIP|OUTERIP|
STARTPORT|ENDPORT|CGNIP

Field Description
HOSTNAME IP address of the device sending user syslogs.
TIMESTAMP Timestamp in the format of <year> <month> <day>

APPNAME Name of the device sending user syslogs.
PROCID ID of a log group, which consists of digits and

characters. This field is mandatory and specifies the
interworking logs in a device, such as the logs for
assigning ports and the logs for reclaiming ports. It
is fixed to 0000000000.
MSGID Device type: message type:

l Device type: NAT444, DS-Lite, L2NAT
l Message type: PortA, PortW
NOTE
l In NAT444 scenarios, the device type is NAT444.
l In L2NAT scenarios, the device type is NAT444.
l In DS-Lite scenarios, the device type is DS-Lite.
l For a port assignment segment, the message type is
PortA.
l For a port reclaiming segment, the message type is
PortW.
STARTTIME Time when port assignment starts, number of

seconds since January 1, 1970, 00:00 (UTC).
INNERIP Private network address of a subscriber.
OUTERIP Public IPv4 address.

Field Description
STARTPORT Start port number of the public network. The value

is 0 if the nat-server-only command is run to
support only the internal NAT server services in a
NAT instance.
ENDPORT End port number of the public network. The value is

65535 if the nat-server-only command is run to
support only the internal NAT server services in a
NAT instance.
CGNIP Management IP address of the CGN device. This

field can be empty if the logs are simply forwarded
from the CGN device. This field is mandatory if the
logs are forwarded from an intermediate device.

l 142 1 6.6.6.6 2015 May 1 16:51:22 ne40elog 0000000000 NAT444:PortA 1430499082|
5.5.4.6|104.3.0.22|1024|2047|6.6.6.6

Usage Scenario Log Syntax
NAT444 <PRI>VERSION TIMESTAMP1

LOGLEVEL/
sequence ='SEQUENCE' sessionid ='
SESSSIONID' privateip='PRIVATEIP'
publicportrange='STARTPORT
~ENDPORT ' time='TIMESTAMP2'

Field Description

Field Description

HOSTNAME IP address of a source device that sends

syslog packets.
SYSLOGVER Syslog version. It is fixed at 1.
MODULENAME Module name. The value is fixed to SEC.
LOGLEVEL Log level. It is fixed at 6.
LOGINFOMNEM The value is fixed to BIND.
LOGTYPE The value is fixed to L.
USERORINCTYPE Port range operation:

l An initial portrange is assigned.
l An initial portrange is freed.
l An increase portrange is assigned.
l An increase portrange is freed.
l "An initial portrange keepalive"
l "An increase portrange keepalive"

l nat444
SEQUENCE Sequence number of a syslog packet. This

field is 64 bits.
l Among 32 high-order bits, the 16 high-
order bits are reserved, and the 16 low-
order bits indicate the instance type (4
high-order bits) and instance ID (12 low-
order bits). The instance type value is
fixed at 1, indicating NAT444. The
instance ID is an integer ranging from 1
to 4095.
l The 32 low-order bits are the sequence
number of a log packet related to a
specified NAT instance.
A log server parses 32 high- and then low-
order bits in the SEQUENCE field.
SESSSIONID Session ID. The value is the timestamp

assigned when a user goes online. The
session ID uniquely identifies a user.
privateip User private IP address.
LEN Inner IPv6 prefix length.

Field Description
VRFID VRF index.
publicip User public IP address.
STARTPORT Start public port number. The value is 0 in a

NAT64 (no-PAT) scenario. The value is 0 if
the nat-server-only command is run to
ENDPORT End public port number. The value is 0 in a

NAT64 (no-PAT) scenario. The value is
65535 if the nat-server-only command is
run to support only the internal NAT server

format of <year>-<month>-<day>
<hour:minute:second>. The default value is
UTC time.

l <134>1 2015-02-05T11:55:48Z 2.0.0.1 - - NAT444userbased - %%01SEC/6/BIND(L):
An initial portrange is assigned, in nat444 scene. sequence='0x0000106f00000002'
sessionid='0x00000005' privateip='1.1.1.2' srcvrfid='0' publicip='133.1.1.10'
publicportrange='1024~65535' time='2015-02-05 11:55:48'
?.2. RADIUS Log Format

RADIUS logs are deployed in distributed mode. RADIUS logs record mappings between the
public and private IP addresses and between public and private port numbers. A CGN device
then sends accounting packets carrying the mappings to a RADIUS server. You can use the
RADIUS logs saved on the RADIUS server to trace user information.
RADIUS logs are sent to the RADIUS server using the AAA module on a CGN device.
Table 5-83 Description of some RADIUS log attributes

Attribute No. Description
HW-NAT-Public-Address(26-161) Public IP address
HW-NAT-Start-Port(26-162) Start port number
HW-NAT-End-Port(26-163) End port number
HW-NAT-Port-Forwarding(26-164) Port forwarding

Attribute No. Description
HW-Nat-Port-Range-Update(26-165) The attribute carried in RADIUS accounting

packets when ports on the CGN service
board are deleted or added. The attribute
value can be: 0: A port range is added for
the CGN service board. 1: A port range is
deleted from the CGN service board.
HW-DS-Lite-Tunnel-Name(26-166) Tunnel name
NOTE
For description about all RADIUS log attributes, see RADIUS Attributes.
Example RADIUS log format:
Figure 5-86 Example RADIUS log format
?.3. User NetStream Log Format

User NetStream logs are sent in binary format by CGN devices deployed in either distributed
or centralized mode.
NOTE
Only NAT444 and DSLITE scenario support user NetStream log format.


Remark
Field Description Length in Bytes
s
Version number. The value

version 2
is fixed to 9.
Sum of the number of

template FlowSet records
count 2
and the number of data
FlowSet records.
It is
Time used since the service carried
sysUpTime board is powered on, in 4 in the
milliseconds. header
Number of seconds since of a user
UNIX Secs January 1, 1970, 00:00 4 NetStrea
(UTC). m log
packet.
Sequence number of a
Sequence Number 4
packet.
The value is calculated

based on the CPU ID, slot
Source ID 4
ID, scenario, and instance
ID.
FlowSet ID The value of this field is 0. 2
Length of a NetStream log

Length template. It is expressed in 2
bytes.
ID of a NetStream log
template:
l The value is 257 in an
Template ID 2
online scenario.
It
l The value is 258 in an identifies
offline scenario. a
Number of fields: NetStrea
m log
l The value is 7 in an template.
Field Count online scenario. 2
l The value is 8 in an
offline scenario.
NAT_LOG_FIELD
_IDX_CONTEXT_ ID of a NAT instance. 2
ID
Length of a NAT instance

length 2
ID.

Remark
s
NAT_LOG_FIELD
_IDX_CONTEXT_ Name of a NAT instance. 2
NAME
Length of a NAT instance

length 2
name.
NAT_LOG_FIELD
Online duration. It is
_IDX_ASSIGN_TS 2
expressed in seconds.
_SEC
Time (seconds) elapsed

length 2
since the last login.
NAT_LOG_FIELD
Offline duration. It is
_IDX_UNASSIGN 2
_TS_SEC
Time (seconds) elapsed

length 2
since the last logout.
NAT_LOG_FIELD
_IDX_IPV4_INT_ Private IP address of a user. 2
ADDR
Length of the private IP

length 2
address of a user.
NAT_LOG_FIELD
_IDX_IPV4_EXT_ Public IP address of a user. 2
ADDR
Length of the public IP

length 2
address of a user.
NAT_LOG_FIELD Start port number.

_IDX_EXT_PORT 2
_FIRST
Length of the start port

length 2
number.
NAT_LOG_FIELD End port number.

_IDX_EXT_PORT 2
_LAST
Length of the end port

length 2
number.
FlowSet ID ID of a FlowSet record. 2 It is the

body of
Length of the sum of data a
Length 2
FlowSet records. NetStrea

Remark
s
VPNID VPN ID. 4
VpnName VPN name. 64
Online duration. It is
AssignTime 4
Offline duration. It is
UnassignTime 4
l In a NAT444 m log
scenario, the value of packet.
this field is 4.
INNERIP Private IP address of a user.
l In a DSLITE
scenario, the value of
this field is 16.
OUTERIP Public IP address of a user. 4
StartPort Start port number. 2
EndPort End port number. 2
Example user NetStream log format:
Figure 5-87 Example user NetStream log format(parsed)

5.9.6.1.2 Flow Log Format

Flow logs, which are generated based on sessions, record the behaviors that a user accesses
network applications. A flow creation log is generated when a new session is created, and a
flow aging log is generated when a session ends. Flow logs can be divided into three types:
syslog, elog, and Netstream log.
?.1. Flow Syslogs Format

Flow syslogs are sent in text format by CGN devices deployed in either distributed or
centralized mode.
Example Flow Syslog in cn format

Scenario Log Syntax
NAT444, and L2NAT <PRI> VERSION TIMESTAMP HOSTNAME APPNAME -

MSGID [L4 INNERIP - OUTERIP INNERPORT
OUTERPORT -]
DS-Lite, and NAT64 <PRI> VERSION TIMESTAMP HOSTNAME APPNAME -

MSGID [L4 - INNERIP OUTERIP INNERPORT
OUTERPORT -]

Field Description
PRI Priority. The value is fixed to 134.
VERSION Version number. The value is fixed to 1.
TIMESTAMP Timestamp of a packet and the format is YEAR MONTH DAY

HOUR:MINUTE:SECOND.
HOSTNAME IP address of a device sending flow syslogs.
APPNAME Name of a device sending flow syslogs.

Field Description
MSGID Message ID in the format of device-type:message-type.

l Device type: NAT444, DSLITE, or NAT64
l Message type: SessionbasedA or SessionbasedW
NOTE
l In a NAT444 scenario or an L2NAT scenario, the device type must
be set to NAT444.
l In a DS-Lite scenario, the device type must be set to DSLITE.
l In a NAT64 scenario, the device type must be set to NAT64.
l In a flow table creation scenario, the message type must be set to
SessionbasedA.
l In a flow table aging scenario, the message type must be set to
SessionbasedW.
L4 ID of an application.
l 1: ICMP
l 6: TCP
l 17: UDP
INNERIP Private IP address:

l In a NAT444 or L2NAT scenario, the value of this field is a
private IPv4 address.
l In a DS-Lite or NAT64 scenario, the value of this field is a
private IPv6 address.
OUTERIP Public IPv4 address after NAT is implemented.
INNERPORT Private port number
OUTERPORT Public port number after NAT is implemented.
Example flow syslog in cn format:
l <134> 1 2014 Oct 8 14:04:17 1.1.1.31 cnelog - NAT444:SessionbasedW [17

172.100.178.228 - 215.20.17.234 1024 4097 -]
Example Flow Syslog in type2 format
Table 5-87 Log Syntax
Scenario String Formatting
NAT Flow table <PRI> VERSION TIMESTAMP HOSTNAME APPNAME -

444, creation MSGID STARTTIME|-|INNERIP|OUTERIP|OUTERPORT|
L2N DESTINATIONIP|DESTINATIONPORT|L4
AT,
DS-
Lite,

Scenario String Formatting
and Flow table aging <PRI> VERSION TIMESTAMP HOSTNAME APPNAME -

NAT MSGID STARTTIME|ENDTIME|INNERIP|OUTERIP|
64 OUTERPORT|DESTINATIONIP|DESTINATIONPORT|L4

Field Description
PRI The value is fixed to 142.
VERSION The value is fixed to 1.
TIMESTAMP Timestamp of a packet and the format is <YEAR> <MONTH>

<DAY> <HOUR:MINUTE:SECOND>.
HOSTNAME IP address of a device sending flow syslogs.
APPNAME Name of a device sending flow syslogs.
MSGID Message ID in the format of device-type:message-type.

l Device type: NAT444, DS-Lite, L2NAT, and NAT64
l Message type: SessionA and SessionW
NOTE
l In a NAT444 scenario, the device type is set to NAT444.
l In an L2NAT scenario, the device type is set to L2NAT.
l In a DS-Lite scenario, the device type must be set to DSLITE.
l In a NAT64 scenario, the device type is NAT64.
l In a flow table creation scenario, the message type is
SessionbasedA.
l In a flow table aging scenario, the message type is SessionbasedW.
STARTTIME Time elapsed since a flow table starts being created. It is

expressed in UTC seconds.
ENDTIME Time elapsed since a flow table ages. This field is displayed as -
when a flow table is being created. It is expressed in UTC
seconds.
INNERIP Source private IP address:

l In a NAT444, L2NAT, or DS-Lite scenario, the value of this
field is a private IPv4 address.
l In a NAT64 scenario, the value of this field is a private IPv6
address.
OUTERIP Public IPv4 address after NAT is implemented.
OUTERPORT Public port number after NAT is implemented.
DESTINATIONIP Destination IP address.

Field Description
DESTINATIONPORT Destination port number.
L4 ID of an application.
l 1: ICMP
l 6: TCP
l 17: UDP
Example flow syslog in type2 format:

l <142> 1 <2014> <Oct> <08> <14:00:14> 1.1.1.31 cnelog - <NAT444>:<SessionW>
1412804760|1412805614|172.100.252.153|215.20.2.160|2048|31.36.1.2|1024|17
Customized Flow Syslog

Scenario Log Syntax Description
NAT444, L2NAT, DS- <PRI> VERSION TIMESTAMP MSG is a customized

Lite, and NAT64 HOSTNAME APPNAME – part, which is composed
MSGID MSG of the STARTTIME,
ENDTIME, INNERIP,
INNERPORT, OUTERIP,
OUTERPORT,
DESTINATIONIP,
DESTINATIONPORT,
and L4 fields. You can
use commands to specify
the fields to be displayed
in a flow Sylog. The order
of these fields and the
separators between these
fields can also be adjusted
using commands.
Currently, four types of
separators are used
between fields: space,
vertical bar, slash, and
backslash.

Field Description Remarks
PRI 142 Fixed
VERSION 1

TIMESTAMP Timestamp, in the format of

<YEAR> <MONTH> <DAY>
<HOUR:MINUTE:SECOND>
HOSTNAME IP address of the device sending

flows
APPNAME Name of the device sending flows
MSGID <Device type>:<Message type>

l Device type: NAT444, DS-Lite,
L2NAT, or NAT64
l Message type: SessionA or
SessionW
NOTE
l The device type is NAT444 in a
NAT444 scenario.
l The device type is L2NAT in an
L2NAT scenario.
l The device type is DS-Lite in a
DS-Lite scenario.
l The device type is NAT64 in a
NAT64 scenario.
l The message type is SessionA
when a flow table starts being
created.
l The message type is SessionW
when a flow table starts aging.
STARTTIME Time elapsed since a flow table This is a customized part.

starts being created. It is expressed
in UTC seconds.
ENDTIME Time elapsed since a flow table

starts aging. It is expressed in UTC
seconds. The value is displayed as
"-" when a flow table starts being
created.
INNERIP l The value is a private IPv4

address in the NAT444, L2NAT,
and DS-Lite scenarios.
l The value is a private IPv6
address in the NAT64 scenario.
INNERPORT Source private port number
OUTERIP Public IPv4 address translated by

the source IP address
OUTERPORT Public port number translated by

the source port number

DESTINATIONIP Destination IP address for user

access
DESTINATIONPORT Destination port number for user

access
L4 Application tag
l 1: ICMP
l 6: TCP
l 17: UDP
Example customized flow syslog:

l <142> 1 <2014> <Dec> <25> <11:41:00> 10.136.118.184 userdefinedsysloghost -
<NAT444>:<SessionA> 1419507660/-/
192.85.2.2/6552/12.12.12.12/1033/192.85.3.2/23/17
Example Flow Syslog in type5 Format

Scenario Log Syntax
NAT444/L2NAT/DS-Lite PRI VERSION HOSTNAME

TIMESTAMP APPNAME PROCID
MSGID STARTTIME|ENDTIME|
INNERIP|OUTERIP|OUTERPORT|
DESTINATIONIP|DESTINATIONPORT|
L4|CGNIP

Field Description
HOSTNAME IP address of the device sending flow syslogs
TIMESTAMP Timestamp in the format of YEAR MONTH DAY

HOUR:MINUTE:SECOND
APPNAME Name of the device sending flow syslogs

Field Description
PROCID ID of a log group, which consists of digits and

characters. This field is mandatory and specifies the
interworking logs in a device, such as the logs for
assigning ports and the logs for reclaiming ports.
MSGID Device type: message type

l Device type: NAT444, DS-Lite, L2NAT
l Message type: SessionA, SessionW
NOTE
l In NAT444 scenarios, the device type is NAT444.
l In L2NAT scenarios, the device type is NAT444.
l In DS-Lite scenario, the device type is DS-Lite.
l For flow table creation, the message type is SessionA.
l For flow table aging, the message type is SessionW.
STARTTIME Time when NAT starts, number of seconds since

January 1, 1970, 00:00 (UTC)
ENDTIME Time when NAT ends, number of seconds since

January 1, 1970, 00:00 (UTC)
NOTE
This field is displayed as - when a flow table is being
created.
INNERIP Private network address of a subscriber
OUTERIP Public IPv4 address
OUTERPORT Number of the public port converted from the source

port
DESTINATIONIP Destination IP address for user access
DESTINATIONPORT Destination port for user access
L4 Application identifier
l 1: ICMP
l 6: TCP
l 17: UDP
CGNIP Management IP address of the CGN device. This

field can be empty if the logs are simply forwarded
from the CGN device. This field is mandatory if the
logs are forwarded from an intermediate device.
Example NAT444–based flow syslog in type5 format:

l 142 1 6.6.6.6 2015 May 1 16:51:22 ne40elog NAT444:SessionA 1430470282|-|5.5.4.6|
104.3.0.22|1024|6.6.6.7|1024|17|6.6.6.6

l 142 1 6.6.6.6 2015 May 1 16:51:22 ne40elog NAT444:SessionW 1430470249|

1430470282|5.5.4.6|104.3.0.22|1024|6.6.6.7|1024|17|6.6.6.6
?.2. Flow Elogs Format

Flow elogs are sent in binary format by CGN devices deployed in either distributed or
centralized mode.
V1 Format (NAT444)

Version number: 1
l For a VSUF-40/80/160 and
version
VSUI-160-E, the value is 0x10.
l For a VSUI-20-A, the value is 0x06.
log_type Log type. The value is fixed to 0x04. 1
Number of flow records in an existing 2

count
packet.
Number of seconds since January 1, 4

unix_sec
1970, 00:00 (UTC).
Sequence number of a packet (5-bit NAT 4

flow_sequence
instance type + 24-bit sequence number).
cpu_id ID of CPU. 4 (Length in bits)
instance_type Type of a NAT instance. 4 (Length in bits)
instance_id ID of a NAT instance. 4 (Length in bits)
Slot ID of a service board on which a 1

slot flow elog is generated. The value is fixed
to 0x00.
ucSeqCarreid Carry flag 1 (Length in bits)
Reserv Reserved 7 (Length in bits)
Type of the protocol running on the IP 1

prot
network.
operator Operation string. 1
ip_ver IP version number. 1
tos_ipv4 IP ToS. 1
sip Source IP address. 4
Source IP address after NAT is 4

natsip
implemented.

dip Destination IP address. 4
Destination IP address after NAT is 4

natdip
implemented.
sport Source port number. 2
Source port number after NAT is 2

natsport
implemented.
dport Destination port number. 2
Destination port number after NAT is 2

natdport
implemented.
stime Start time of a flow. 4
etime End time of a flow. 4
inpkt Number of user-to-network flow packets. 4
Number of bytes of user-to-network flow 4

inbyte
packets.
outpkt Number of network-to-user flow packets. 4
Number of bytes of network-to-user flow 4

outbyte
packets.
svpn Source VPN ID. 2
dvpn Destination VPN ID. 2
pad1 Reserved. 4
pad2 Reserved. 4
Example flow elog in V1 format (NAT444):
Figure 5-88 Example flow elog in V1 format (NAT444)

V1 Format (NAT64)

version Version number. The value is 0x10. 1
log_type Log type. The value is 0x15. 1

count
packet.
Number of seconds since January 1, 1970, 4

unix_sec
00:00 (UTC).

flow_sequence

to 0x00.

prot
network.
IP version number. The value is fixed to 1

ip_ver
0x21.
Flag The value is fixed to 03. 1
ucReserved1 Reserved. 1
V6sip Source IPv6 address. 16
V6dip Destination IPv6 address. 16

inbyte
packets.


outbyte
packets.

natsport
implemented.

natdport
implemented.
Source IP address after NAT is 4

natsip
implemented.

natdip
implemented.
TunnelID Reserved. The default value is used. 4
DsliteinstID Reserved. The default value is used. 2
pad Reserved. The default value is used. 2
pad1 Reserved. 4
pad2 Reserved. 4
Example flow elog in V1 format (NAT64):
Figure 5-89 Example flow elog in V1 format (NAT64)

V2 Format (NAT444 and DS-Lite)
Version number: 1
l For a VSUF-40/80/160 and
version
VSUI-160-E, the value is 0x10.
l For a VSUI-20-A, the value is 0x03.
log_type Log type. The value is fixed to 0x14. 1

count
packet.
Number of seconds since January 1, 1970, 4

unix_sec
00:00 (UTC).

flow_sequence

to 0x00.

prot
network.
operator Operation string. 1
ip_ver IP version number. 1
tos_ipv4 IP TOS. 1
sip Source IP address. 4
natsip IP address after NAT is implemented. 4
dip Destination IP address. 4

natdip
implemented.

natsport
implemented.


natdport
implemented.

inbyte
packets.

outbyte
packets.
pad1 Reserved. 4
pad2 Reserved. 4
instanceID ID of a NAT instance. 2
Encapsulation type: 2
usEncapSultion
l For an IPinIP tunnel, the value is 4.
Type
l For a GRE tunnel, value is 47.
Source IP address of an IPv6 tunnel in 16

stIpv6SrcAddr
DS-Lite mode.
Destination IP address of an IPv6 tunnel 16

stIpv6DestAddr
in DS-Lite mode.
Example flow elog in V2 format (NAT444 and DS-lite):
Figure 5-90 Example flow elog in V2 format (NAT444 and DS-lite)

?.3. Flow NetStream Log Format

Flow NetStream logs are sent in binary format by CGN devices deployed in either distributed
or centralized mode.
NOTE
Only NAT444 and L2NAT scenario support flow NetStream log format.

Field Description Length in Bytes Remarks
Version number. The value is

version 2
fixed to 9.
Sum of the number of template

count FlowSet records and the number 2
of data FlowSet records.
Time used since the service It is carried in

sysUpTime board is powered on, in 4 the header of
milliseconds. a flow
Number of seconds since January NetStream
UNIX Secs 4 log packet.
1, 1970, 00:00 (UTC).
Sequence
Sequence number of a packet. 4
Number
It is calculated based on the CPU

Source ID ID, slot ID, scenario, and 4
instance ID.
FlowSet ID The value of this field is 0. 2
Length of a NetStream log

Length 2
template. It is expressed in bytes.
ID of a NetStream log template:

l In a session creation scenario,
Template ID the value is 259. 2
l In a session deletion scenario,
the value is 260. It identifies a
NetStream
Field Count The value of this field is 13. 2 log template.
timeStamp Timestamp of a packet. 2
Length Length of the timestamp. 2
vlanID VPN ID. 2
Length Length of the VPN ID. 2
Source IPv4
Source IPv4 address. 2
Address

Length of the source IPv4

Length 2
address.
Post NAT
Source IPv4 address after NAT is
Source IPv4 2
implemented.
Address
Length of the source IPv4

Length address after NAT is 2
implemented.
Protocol
Identifier of an IP protocol. 2
Identifier
Length Length of the IP protocol. 2
Source
Source port number. 2
Transport Port
Length of the source port

Length 2
number.
Post NAT
Source port number after NAT is
source 2
implemented.
Transport Port
Length of the source port number

Length 2
after NAT is implemented.
Destination Destination IPv4 address.

2
IPv4 Address
Length of the destination IPv4

Length 2
address.
Post NAT
Destination IPv4 address after
Destination 2
NAT is implemented.
IPv4 Address
Length of the destination IPv4

Length address after NAT is 2
implemented.
Destination
Destination port number. 2
Transport Port
Length of the destination port

Length 2
number.
Post NAT
Destination port number after
destination 2
NAT is implemented.
Transport Port

Length of the destination port

Length number after NAT is 2
implemented.
Initiator of a session:
l For an access from a private
network to a public network,
Nat Originating
the value is 1. 2
Address Realm
l For an access from a public
network to a private network,
the value is 2.
Length of the initiator of a

Length 2
session.
Nat Event Type of a NAT event. 2
Length of the type of a NAT

Length 2
event.
FlowSet ID ID of a FlowSet record. 2
Length of the sum of data

Length 2
FlowSet records.
timeStamp Timestamp of a packet. 8
vlanID VPN ID. 4
Source IPv4
Source IPv4 address. 4
Address
Post NAT
Source IPv4 address after NAT is
Source IPv4 4
implemented.
Address
Protocol It is the body

Identifier of an IP protocol. 1 of a
Identifier
NetStream
Source log packet.
Source port number. 2
Transport Port
Post NAT
Source port number after NAT is
source 2
implemented.
Transport Port
Destination
Destination IPv4 address. 4
IPv4 Address
Post NAT
Destination IPv4 address after
Destination 4
NAT is implemented.
IPv4 Address
Destination
Destination port number. 2
Transport Port

Post NAT
Destination port number after
destination 2
NAT is implemented.
Transport Port
Initiator of a session:
l For an access from a private
network to a public network,
Nat Originating
the value is 1. 1
Address Realm
l For an access from a public
network to a private network,
the value is 2.
Nat Event Type of a NAT event. 1
Example flow NetStream log:
Figure 5-91 Example flow NetStream log (parsed)
ALG Application layer gateway

AFTR Address Family Transition Router
B4 Basic Bridging BroadBand
BFD Bidirectional Forwarding Detection
BRAS Broadband remote access server
BOD Dandwidth on Demand
CPE Customer-premises equipment
CoA Change-of-authorization message
CR Core router
DAA Destination Address Accounting
DNS Domain name system
DS-Lite Dual-Stack-Lite
EDSG Enhanced dynamic service gateway
FTP File Transfer Protocol
HA High Availability
HSI High Speed Internet
HTTP Hypertext Transfer Protocol
ICMP Internet Control Message Protocol
L2NAT
NAT Network Address Translation

MAC Media access control
PCP Port Control Protocol
PPPoE PPP over Ethernet
RADIUS Remote authentication dial in user service
SR Service Router
TCP Transmission Control Protocol
UDP User Datagram Protocol
URL Uniform resource locator
VPN Virtual private network
VRRP Virtual Router Redundancy Protocol

NE Series Router Maintenance Guide 6 Trouble Case
6 Trouble Case
About This Chapter
6.1 Boards Cannot Be Registered

6.2 The CPU Usage Is High
6.3 Clock Synchronization Troubleshooting
6.4 Telnet Troubleshooting
6.5 SSH Troubleshooting
6.6 NetStream
6.7 GTL License Troubleshooting
6.8 GE Interface Troubleshooting
6.9 ARP Troubleshooting
6.10 IP Forwarding
6.11 OSPF Troubleshooting
6.12 IS-IS Troubleshooting
6.13 BGP Troubleshooting
6.14 L3VPN Troubleshooting
This chapter describes common causes of L3VPN faults and provides the corresponding
troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
6.15 VPLS Troubleshooting
This chapter describes common causes of VPLS faults and provides the corresponding
6.16 QoS
6.17 BFD Troubleshooting
6.18 VRRP Troubleshooting

6.19 URPF Troubleshooting

6.20 Local Attack Defense Troubleshooting
6.21 User Fails to Get Online Troubleshooting

6.1 Boards Cannot Be Registered
6.1.1 The ALM Indicator on the LPU Is On and the Log SRM/2/
TMLINEERR Is Displayed
The ALM indicator on the LPU is always On and the log SRM/2/TMLINEERR is displayed.
NOTE
This troubleshooting case comes from a live network and is for reference only. The device version
involved is V600R002C09. When you troubleshoot similar problems, take into consideration your
particular network conditions and device versions.
Fault Analysis
1. The system displays the following alarm messages. Through analysis, you can find that
the system generates an alarm due to packet loss on LPU2.
Jul 31 2008 15:54:01 TZ-XQ-R-01 %%01SRM/2/TMLINEERR(l): LPU2 occur line
error! Error Code=2.2!
Jul 31 2008 15:53:01 TZ-XQ-R-01 %%01SRM/2/TMLINEERR(l): LPU2 occur line
error! Error Code=2.1!
2. Run the display interface interface-type interface-number command to check

information about interfaces on LPU2, and you can find that GE 2/0/0 transmits packets
at a rate close to the line rate. The command output is as follows:
Last 30 seconds output rate: 968093056 bits/sec, 209961 packets/sec
3. After checking the configuration of GE 2/0/0, you can find that port mirroring is
configured on the device where GE 2/0/0 functions as an observing port and GE 2/0/1
and GE 2/0/2 function as mirrored ports.
a. Run the display this command in the view of GE 2/0/0, and you can find that port
mirroring is configured on the device.
#
undo shutdown
port-observing observe-index 2
#
return
b. Run the display port-observing slot command to obtain the slot ID of the mirrored
port through the reference slot item.
[HUAWEI] display port-observing slot
slot 2
observe-port : GigabitEthernet2/0/0
reference slot : 2
c. Run the display port-mirroring interface slot slot-id command to view the
mirrored port number.
[HUAWEI] display port-mirroring interface slot 2
-------------------------------------------------------------------------
-----
Interface Local/Remote CAR Type In/Out WithLinkHeader
Instance
-------------------------------------------------------------------------
-----

GI2/0/1 Local - Port In - -

GI2/0/2 Local - Port In - -
-------------------------------------------------------------------------
-----
Procedure
Step 1 You can cancel the observing port or decreases the number of mirrored ports to clear the fault.
NOTE
The fault occurs because traffic from two mirrored ports is mirrored to one observing port. In this case,
there is too much traffic on the observing port, which causes the generation of an alarm and packet loss.
If port mirroring is configured to monitor traffic on the mirrored ports, you can reduce the number of
mirrored ports or mirror the traffic to other ports in addition to the observing port.
Step 2 Canceling the observing port

1. Run the system-view view to enter the system view.
2. Run the interface interface-type interface-number command to enter the interface view.
In this step, the view of the observing port, that is, GE 2/0/0, is displayed.
3. Run the undo port-observing observe-index observe-index-number command to cancel
port mirroring.
Step 3 Reducing the number of mirrored ports
1. Run the system-view view to enter the system view.
In this step, the view of a mirrored port, that is, GE 2/0/1 or GE 2/0/2, is displayed.
3. Run the undo port-mirroring { inbound | outbound } command to cancel port
mirroring.
Step 4 After the preceding operations, the ALM indicator on the LPU recovers and no logs are
displayed any longer.
----End
Summary
When traffic from multiple mirrored ports is mirrored to one observing port, traffic on the
observing port may reach line rate and packet loss occurs. Before configuring port mirroring,
ensure that the traffic can be processed on the observing port.
6.1.2 1GB Memory of the NE40E&NE80E MPU Remains the Same

After the Memory Is Expanded to 2GB
The MPU on the NE40E&NE80E is currently installed with a 1GB memory bar manufactured
by vendor A. The MPU memory now needs to be expanded to 2GB through additional
installation of another 1GB memory bar. After one 1GB memory bar manufactured by vendor
B is installed in the MPU, it is displayed that the MPU memory is still 1GB.
NOTE

Fault Analysis
NOTE
This troubleshooting case is not applicable to the NE40E&NE80E-X1/X2.
1. Remove and then install the memory bar manufactured by vendor B from or in the MPU.
Then, run the display memory-usage command, and you can find that the memory is
still 1GB. This rules out the possibility that the memory bar manufactured by vendor B is
improperly installed.
2. Replace the memory bar manufactured by vendor B with another memory bar
manufactured by vendor B. The display memory-usage command displays that the
memory of the MPU is still 1GB. This rules out the possibility of failures of the memory
bars manufactured by vendor B.
3. Remove the memory bar manufactured by vendor B, and then install two 1GB memory
bars to the MPU. Then, the display memory-usage command displays that the memory
on the MPU is 2GB. The fault is therefore rectified.
The memory of the NE40E&NE80E MPU is currently 1GB. To meet service requirement,
another 1GB memory bar must be installed. The newly installed memory bar, however, is
incompatible with the existing memory bar of the MPU. Therefore, the newly installed
memory bar cannot be identified. After a 1GB memory bar of the same vendor with that of
the existing memory is installed to the MPU, the memory of the MPU is displayed as 2GB.
Procedure
Step 1 Remove the memory bar manufactured by vendor B, and then install two 1GB memory bars
manufactured by vendor A to the MPU.
After the operations, run the display memory-usage command displays that the memory on
the MPU is 2GB. The fault is therefore rectified.
----End
Summary
When the memory on the MPU is expanded, ensure that the MPU must be installed with two
memory bars manufactured by the same vendor.
6.1.3 A TCAM Chip Failure Causes All MPLS Tunnels to Go

Down
NOTE
Fault Symptom
The network of an area has two planes. In normal situations, when the master plane fails,
services are automatically switched to the slave plane.
Once, all services on the bearer network are interrupted. Through analysis, it is found that all
primary/backup tunnels between the bearer network and backbone network go Down, causing

a failure in establishing LSPs between nodes in this area and nodes in other areas. In this case,
Fault Analysis
1. All primary/backup tunnels are established on interfaces of the LPU in slot 1. Run the
display interface tunnel interface-number command to view the status of tunnels
established on interfaces of LPUs in other slots, and you can find that these tunnels are
normal.
2. IS-IS runs on the current network. Run the display isis route command to view the
status of IS-IS on the LPU in slot 1, and you can find that IS-IS runs normally.
Because tunnels are established through RSVP or LDP that needs to search the FIB
table, it can be preliminarily inferred that a fault occurs when RSVP or LDP searches the
FIB table.
3. The control plane delivers FIB entries to all LPUs. Run the display fib command to
check whether the FIB entries on the LPUs other than the LPU in slot 1 are normal.
If the FIB entries on the other LPUs are normal, it indicates that the control plane
properly delivers the FIB entries. In this case, it can be inferred that a fault occurs on the
TCAM chip that stores FIB entries.
Procedure
Step 1 Replace the LPU in slot 1. The fault is therefore rectified and services are restored.
----End
Summary
The possible causes for the failure in searching the FIB table are as follows:
l The control plane improperly delivers FIB entries.
l A fault occurs on the TCMP chip that stores FIB entries.
6.1.4 Slave MPU Cannot Be Registered Because the System

Software Package and the Master MPU Do Not Match
NOTE
Fault Symptom
The slave MPU cannot be registered.
Fault Analysis
Log in to the device through Telnet, and then run the display startup command to view the
system software package loaded to the master MPU.
MainBoard:
Configured startup system software: cfcard:/V600R002C00.cc


Startup saved-configuration file: cfcard:/vrpcfg.cfg
Next startup saved-configuration file: cfcard:/vrpcfg.cfg
Startup paf file: cfcard:/paf-V600R002C00.txt
Next startup paf file: cfcard:/paf-V600R002C00.txt
Startup license file: cfcard:/license-V600R002C00.txt
Next startup license file: cfcard:/license-V600R002C00.txt
Startup patch package: cfcard:/patch.bat
Next startup patch package: cfcard:/patch.bat
Connect the console port of the slave MPU to a PC, and then check the system software
version displayed in the field "The start file is" in the feedback information of the console
port. The result shows that the configuration file for startup of the slave MPU is different from
that of the master MPU. This is why the slave MPU cannot be registered.
Procedure
Step 1 Run the board-channel-check disable command in the user view to disable the self-check of
the channel.
NOTE
Without this operation, the slave MPU may be reboot during the upgrade.
Step 2 Connect the console port of the slave MPU to the COM port of the PC, and configure the
HyperTerminal.
You can configure a PC to function as both an FTP server and a terminal.
In this troubleshooting example, it is presumed that the operating system of the PC is
Windows XP.
1. Choose Start > Programs > Accessories > Communications > HyperTerminal. Then,
in the displayed window, enter a name for the connection, for example, test.
2. Click OK. The following window is displayed. Select a COM port. It is recommended to
select COM1.

3. Click OK. The following window is displayed. Set the properties of COM1. In the Bits
per second drop-down list, choose 9600. For the other parameters, use the default
settings.
Click OK. The configurations of the HyperTerminal are complete.

Step 3 Run the FTP server program on the PC and create an FTP user.
NOTE
In this step, the window displayed may vary with the FTP software.
Set parameters of the FTP server program, including the directory, username, and password.

Figure 6-1 Configuration of FTP parameters
Step 4 Restart the slave MPU. Press Ctrl+B within 3 seconds after Press Ctrl+B to enter Main
Menu... 3 is displayed on the HyperTerminal.
****************************************************
* *
* 8090 boot ROM, Ver 214.00 *
* *
****************************************************
Copyright 2001-2010 Huawei Tech. Co., Ltd.

Creation date: Mar 27 2010, 17:47:31
CPU type : MPC7447A

CPU L2 Cache : 512KB
CPU Core Frequency : 1GHz
Step 5 Enter the password to enter the main menu.

password:
NOTE
The default password is WWW@HUAWEI. You can change the password by selecting 5. Modify boot
ROM password in the main menu.
Main Menu(bootload ver: 36.07)
1. Boot with default mode

2. Boot from CFcard
3. Enter ethernet submenu
4. Set boot file and path
5. Modify boot ROM password
6. Chkdsk CFcard
7. Format CFcard
8. List file in CFcard
9. Delete file from CFcard
10. Set patch mode
11. Set version back signal
12. Reboot
Step 6 Select 3. Enter ethernet submenu to enter the Ethernet interface submenu.
Ethernet Submenu



Step 7 Select 3. Modify ethernet interface boot parameters to set booting parameters.
te: two protocols for download, tftp & ftp.
You can modify the flags following the menu.
tftp--0x80, ftp--0x0.
'.' = clear field; '-' = go to previous field; ^D = quit
boot device : mgi0 \\ mgi0 or mgi2. If it is set to mgi0 but files

cannot be loaded, set it to mgi2.
processor number : 2 \\If mgi0 is adpoted, set the processor number to 2; if
mgi2 is adopted, set the processor number to 0.
host name : host \\No action is required.
file name : V300R006C01.cc \\Enter the system software name on the
server.
inet on ethernet (e) : 10.1.1.100:FFFFFF00 \\Set the IP address and mask that
can be used to communicate with the FTP server.
inet on backplane (b): \\This indicates the backup interface used to communicate
with the FTP server. It can be set or not.
host inet (h) : 10.1.1.3 \\This indicates the address of the FTP server.
gateway inet (g) \\This indicates the gateway used to communicate with the FTP
server, which is set as required.
user (u) : mpu \\This indicates the FTP user name, which must have
been configured on the FTP server.
ftp password (pw) (blank = use rsh): mpua \\This indicates the password of the
FTP user.
flags (f) : 0x0 \\Set FTP or TFTP upgrade. By default, FTP upgrade
is adopted. To use TFTP upgrade, enter 0x80.
This case uses FTP upgrade, and therefore this
value does not need to be changed.
target name (tn) \\No action is required.

startup script (s) \\No action is required.
other (o) : \\No action is required.
Ethernet Submenu


The configuration is now completed. The system returns to the Ethernet interface submenu.
Step 8 Select 2. Download file to CFcard through ethernet interface to download the system
software to the CF card.
C address:0xa 0xb 0xc 0x0 0x9 0x0
Attached TCP/IP interface to mgi2.
Attaching network interface lo0... done.
boot device : mgi

unit number : 2
processor number : 0
host name : host
file name : V300R006C01.cc
inet on ethernet (e) : 10.1.1.100:FFFFFF00
host inet (h) : 10.1.1.3

user (u) : mpu

ftp password (pw) : mpua
flags (f) : 0x0
target name (tn) :
Loading
...Done!
Writing to CFcard...Done!
Ethernet Submenu


After the system software is loaded, the system returns to the Ethernet interface submenu.
Step 9 Select 4. Return to main menu. The system returns to the main menu.

2. Boot from CFcard
3. Enter serial submenu
8. Chkdsk CFcard
9. Set patch mode
11. Reboot
Step 10 Select 5. Set boot file and path to specify the configuration file for startup.
Boot Files Submenu

Step 11 Select 1. Modify the boot file to modify the configuration file for startup.
boot file is cfcard:/V300R006C01.cc, modify the file name if needed.
Please input correctly, e.g.: cfcard:/V300R006C01.cc cfcard:/v300r006c01.cc \
\Enter the name of the system software that has just been loaded, and then press
Enter. The absolute path of the system software must be specified
The file name you input is cfcard:/v300r006c01.cc.
Are you sure? Yes or No(Y/N)y
NOTE
The method of specifying the PAF and license files is the same as the method of specifying the
configuration file, and is not mentioned here.
Step 12 Enter y, and then press Enter. After files are successfully loaded, the system returns to the
Boot Files Submenu.
Setting ...
Read flag rec from nvram ......................OK!
Write descriptor to nvram ......................OK!

Done!
Clear version back signal...Done!
Boot Files Submenu

Step 13 Select 7. Return to main menu. The system returns to the main menu.

2. Boot from CFcard
3. Enter serial submenu
8. Chkdsk CFcard
9. Set patch mode
11. Reboot
Select 2. Boot from Cfcard to start from the CF card. The slave MPU restarts using the
newly-loaded system software.
The slave MPU is successfully registered. The fault is rectified.
Step 14 Run the board-channel-check enable command in the user view to enable the self-check of
the channel.
----End
Summary
Each MPU is loaded with a system software package when being produced. This software
package is inconsistent with that running a device on the existing network in most cases.
Therefore, you need to replace the system software loaded to the MPU.
6.1.5 NE40E&NE80E Is Registered Repeatedly But No Trap

Information About the Registration Failure Is Sent to the NMS
NOTE
involved is V300R003C02B697. When you troubleshoot similar problems, take into consideration your
Problem Description
The board in slot 3 of an NE40E&NE80E running V300R003C02B697 is registered
repeatedly. The logs show that trap information is generated and sent to the NMS when the

board is re-registered, but no trap information is generated and sent to the NMS when the
board fails to be registered. The following shows the log information:
Log recording registration failures of the board in slot 3 (No trap is generated and sent to the
NMS.)
#Feb 14 11:01:13 2012 NE40E&NE80E SRM/3/EntityInvalid:LPU3 is failed, loopback
heartbeats have lost for 30 seconds
Log recording re-registrations of the board in slot 3 (A trap is generated and sent to the NMS.)
#Feb 14 10:58:27 2012 NE40E&NE80E SRM_DC/4/HWBRDUP:OID
1.3.6.1.4.1.2011.5.25.37.2.16 INDEX: 196608 LPU slot 3 , Board register.
Problem Analysis
This problem is likely to be caused by the following issues:
1. SNMP is configured on the device incorrectly.

2. The NMS is configured incorrectly.
3. The duration of the trap message set using the snmp-agent trap life command expires
and the message is discarded.
4. A lot of trap messages are generated and exceed the queue length set using the queue-
size command and are discarded.
The fault locating process is as follows:
l These is a low probability that the trap message is discarded because the duration of the
trap message expires and too many trap messages are generated.
l Check the configurations of the NMS and find no fault.
l Check the SNMP configurations on the NE40E&NE80E and find that trap messages are
configured to be sent to the NMS in dc-trap mode.
#
snmp-agent trap type dc-trap
#
In dc-trap mode, a device sends part of alarm information to the NMS. In base-trap
mode, a device sends all the alarm information displayed in the display alarm all
command output to the NSM. In this case, dc-trap mode is configured to send trap
messages to the NMS. Therefore, trap information fails to be sent to the NMS when the
board fails to be registered.
NOTE
V300R001 only supports sending trap messages in dc-trap mode. When a device is upgraded from
V300R001 to a later version, the trap-sending mode is changed to base-trap automatically.

Procedure
Step 1 Run the snmp-agent trap type base-trap command to change the trap-sending mode to base-
trap. All the alarm information is sent to the NMS and the fault is rectified.
----End
Conclusion
To enable the NMS to monitor the overall running status of a device, configure the trap-
sending mode to base-trap.
6.1.6 NE5000E Fails to Collect Traffic Statistics

NOTE
involved is NE5000E V200R003C02. When you troubleshoot similar problems, take into consideration
your particular network conditions and device versions.
Problem Description
A carrier replaces MAN's egress core router NE40Es with NE5000Es. The core egress traffic
needs to be reported to the telecommunication administration bureau. Therefore, NetStream
boards need to be specified. When the ip netstream sampler to slot ? command is run to
configure the NetStream sampling mode, however, no board can be used as the NetStream
board. As a result, the core egress traffic fails to be reported to the telecommunication
administrative bureau.
[HUAWEI-slot-6]ip netstream sampler to slot ?
no current active IO board
self self
Problem Analysis
NE5000Es provide flexible authorization for service modules. To enable NetStream services
on a NetStream board, a specific GTL license is needed.
Procedure
Step 1 Obtain the ESN number of the NetStream board and apply for the GLT file.
Step 2 Install the GTL file.
Step 3 Run the license active filename command to activate the GTL license.
Step 4 Run the display license command to view information about the GTL license.
Active License on master board: cfcard:/license.dat
Huawei Technologies Co., Ltd.
All rights reserved.
Product name : NetEngine5000E
Product version : V200R003
License Serial No : LIC20110614006110
Creator : Huawei Technologies Co., Ltd.
Created Time : 2011-06-14 11:54:18
Feature name : CRFEA2
Authorize type : COMM
Expired date : 2011-09-10
Trial days : 60

Expired date of software maintain : 0000-00-00

Expired date of hardware maintain : 0000-00-00
Expired date of free software update : 0000-00-00
Configure items :
Item name : LCR5NETSTM07 value : 2
Step 5 Run the set board-type slot slot-id1 netstream command to set the board to a NetStream
board.
Setting succeed,please reset slot< 16 > to make the new configuration enable.
Step 6 Run the reset slot slot-id1 command to restart the NetStream service processing board.
Caution!!! Confirm to reset slot 16! Continue?[Y/N]?y

Info: The LPU16 is being reset.
Run the display device slot-id1 command to check whether the SPU is set to a NetStream
service processing board.
SPU16's detail information:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Description: Line Processing Unit - Netstream
Board status: Normal
Register: Registered
Uptime: 2011/06/15 00:35:10
CPU Utilization(%): 5%
Mem Usage(%): 56%
Clock information:
State item State
Current line-clock: 46
Line-clock 46 state: activated
Line-clock 47 state: activated
Statistic information:
Statistic item Statistic number
Mpu switchs: 0
Line-clock switchs: 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Step 7 Collect NetStream traffic statistics.

1. Run the system-view command to enter the system view.
2. Run the ip netstream export version version origin-as command to set the output
version for NetStream original flows.
3. Run the ip netstream sampler fix-packets packet-interval inbound command to
configure NetStream sampling functions.
4. Run the ip netstream export source ip-address command to configure the source IP
address of the output NetStream flows.
5. Run the ip netstream export host ip-address command to configure the destination IP
address of the output NetStream flows.
6. Run the slot slot-id command to enter the slot view.
7. Run the ip netstream sampler to slot slot-id1 command to configure the integrated
NetStream service processing mode and NetStream board.
8. Run the return command to return to the system view.
10. Run the ip netstream inbound command to enable the device to collect statistics about
incoming data flows.
Step 8 Run the display ip netstream statistics slot slot-id command to view the NetStream
statistics.
Netstream statistic information on slot 16:
--------------------------------------------------------------------------------

length of packets Number Protocol Number

--------------------------------------------------------------------------------
1 ~ 64 : 33673 IPV4 : 97312
65 ~ 128 : 13402 IPV6 : 0
129 ~ 256 : 3668 MPLS : 0
257 ~ 512 : 1199 Total : 97312
513 ~ 1024 : 4173
1025 ~ 1500 : 40764
longer than 1500 : 433
Velocity Of Creating Streams (streams/second): 383
--------------------------------------------------------------------------------
srcprefix = source-prefix, srcpretos = source-prefix-tos,
dstprefix = destination-prefix, dstpretos = destination-prefix-tos,
protport = protocol-port, protporttos = protocol-port-tos,
all-aggre = all aggregation streams,
"---" means that the current board is not supported.
----End
Conclusion
NE5000Es use GTLs to control MVPN, GRE, and NetStream functions. To use specific
functions, apply for the corresponding GTLs.
6.1.7 A Fan Fails to Be Registered Because Versions of

MonitorBus on the Master and Slave MPUs of an NE40E are
Incompatible
Context
NOTE
involved is NE40E V600R001C00SPC800. When you troubleshoot similar problems, take into
consideration your particular network conditions and device versions.
Fault Symptom
The status of a fan in an NE40E is displayed as Unregistered Abnormal, and the alarm
information displays the slot of the fan as MonitorBUS node failed. The fan runs normally.
<HUAWEI> display device
NE40E-X3's Device status:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
10 FAN Present Unregistered Abnormal NA
<HUAWEI> display alarm all
----------------------------------------------------------------------------
Index Level Date Time Info
1 Emergency 11-03-24 14:07:34 SlotID:10 is failed, MonitorBUS node failed
----------------------------------------------------------------------------

Fault Analysis
1. The display temperature command output shows that the temperature of each part of
the device is normal. However, the slave MPU in slot 5 and the fan in slot 10 fail to
display the temperature but display abnormal information.
SlotID1 :
Base-Board, Unit:C, Slot1
PCB I2C Addr Chl Status Minor Major Fatal Adj_speed Temp
TMin Tmax (C)
-----------------------------------------------------------------
LPUK 1 0 0 NORMAL 70 80 90 65 70 38
LPUK 1 1 0 NORMAL 76 85 95 65 75 44
LPUK 1 2 0 NORMAL 73 83 93 63 73 43
LPUK 1 4 0 NORMAL 70 80 90 60 70 43
LPUK 1 5 0 NORMAL 70 80 90 60 70 35
LPUK 1 6 0 NORMAL 70 80 90 60 70 41
LPUK 1 7 0 NORMAL 66 75 80 60 66 43
LPUK 2 76 2 NORMAL 90 96 102 80 90 56
EBGFB 3 73 0 NORMAL 75 85 91 60 70 19
EBGFB 3 74 0 NORMAL 80 90 96 65 75 27
EBGFB 4 73 0 NORMAL 75 85 91 60 70 20
EBGFB 4 74 0 NORMAL 80 90 96 65 75 26
SlotID4 :
Base-Board, Unit:C, Slot4
PCB I2C Addr Chl Status Minor Major Fatal Adj_speed Temp
TMin Tmax (C)
-----------------------------------------------------------------
MPUD 0 0 0 NORMAL 73 79 90 56 67 25
MPUD 0 1 0 NORMAL 73 79 90 56 67 20
MPUD 0 2 0 NORMAL 73 79 90 56 67 23
SlotID5 : MonitorBUS not work.
SlotID10 : MonitorBUS communicate fail.
2. However, the fan is running normally. After the backup fan replaces the fan, the problem
still exists.
3. Based on the command output about the temperature, it is suspected that MonitorBUS of
the slave MPU results in the registration failure of the fan. Pull out the slave MPU and
run the display device command. The fan succeeds to be registered and runs normally.
Therefore, the problem is caused by MonitorBUS of the slave MPU.
Procedure
Step 1 Insert the slave MPU back and run the upgrade mpu 5 startup monitorbus force command.
Upgrade MonitorBus of the slave MPU.
After the preceding operations are complete, the fan succeeds to be registered and the fault is
rectified.
----End
Summary
The fan mbusnode communicates with the main MonitorBus module of the MPU to control
the fan module, and deliver the status of the fan module and the fault information. If
MonitorBUS of the master MPU does not work and fails to communicate with the fan, the
versions of MonitorBus on the master and slave MPUs are probably incompatible.

6.2 The CPU Usage Is High
6.2.1 LDP Flapping Causes High CPU Usage on a Router
NOTE
involved is NE5000E V300R007. When you troubleshoot similar problems, take into consideration your
Fault Symptom
NE5000Es serve as core LSRs on an MPLS network. IS-IS and MPLS LDP are deployed on
the NE5000Es. Packets are discarded on an NE5000E. When Telnet is used to log in to the
NE5000E, the NE5000E often does not respond to inputs.
Fault Analysis
1. Check the CPU status of the NE5000E. The results show that the CPU usage reaches
99%. The CPU usage for the route task process is 50%, and the CPU usage for the LDP
task process is 13%. The log information is as follows:
ISIS/6/LDP_ENTER_ACHIEVED:An interface of the ISIS process 1 entered the ldp-
sync-achieved state.(IfName=Eth-Trunk0)
ISIS/6/RCV_ERR_LSP:ISIS 1 received an incorrect LSP packet on the interface
from SNPA. (Reason=UPDT:Extended Nbr metric excced MAX_LINK_METRIC.,
InterfaceName=Eth-Trunk0, SnpaAddress=0025.ba72.61c4,
NeighborSystemId=0000.0000.0000, LspId=XXXX.XXXX.XXX3.00-00,
LspSequenceNumber=0x1be5, PduType=
20, TlvType=22, Offset=50)
RM/4/IPV4_DEFT_RT_CHG:IPV4 default Route is changed.
(ChangeType=Delete,InstanceId=0,Protocol=ISIS,ExitIf=Eth-
Trunk0,Nexthop=XXX.XXX.XXX.
9,Neighbour=0.0.0.0,Preference=18,Label=4294967295,Metric=16777253)
LDP/4/SSNHOLDTMREXP:Sessions were deleted because the session hold timer
expired and the notification of the expiry was sent to the peer XXX.XXX.XXX.21
ISIS/6/LDP_ENTER_HMC:An interface of the ISIS process 1 entered the ldp-sync-
holdMaxCost state.(IfName=Eth-Trunk0)
According to the log information, high CPU usage is caused by IS-IS LSP flapping. The
IS-IS process receives a packet with the maximum cost from a neighbor (Reason=UPDT:
Extended Nbr metric excced MAX_LINK_METRIC).
2. Check interface configurations. The results show that isis cost 16777215 has been
configured on the interface.
mtu 9212
ip address X.X.X.X 255.255.255.252
isis enable 1
isis circuit-level level-2
isis cost 16777215
When the IS-IS cost is 16777215, the neighbor TLV generated on the link can be used
only for the transmission of LDP/TE information. When the received link cost is the
maximum value 16777215, the initial status of the LDP session is Up. However, when
the route module indicates that the IS-IS link status is unavailable, the LDP session
status becomes Down. Then an LDP session is reestablished.

Procedure
Step 1 Change the IS-IS cost to 16777214.
After the preceding operations, the NE5000E runs properly. The fault is rectified.
----End
Summary
Do not set the IS-IS cost to the maximum value. That is, set the IS-IS cost to a value ranging
from 1 to 16777214.
6.2.2 A Large Number of UDP Attack Packets with a TTL Value of

1 Cause High CPU Usage on the LPU
NOTE
involved is V600R001. When you troubleshoot similar problems, take into consideration your particular
network conditions and device versions.
Fault Symptom
The CPU on the LPU in slot 7 has high usage. The highest usage reaches 90%, which exceeds
the default alarm threshold. The SOCK, PES, and NonDopraTask processes have high CPU
usage. The alarm information is as follows:
VOSCPU/4/CPU_USAGE_HIGH(l):Slot=7;The CPU is overloaded, and the tasks with top
three CPU occupancy are SOCK, PES, NonDopraTask. (CpuUsage=83%, Threshold=80%)
VOSCPU/4/CPU_USAGE_HIGH(l):Slot=7;The CPU is overloaded, and the tasks with top
three CPU occupancy are SOCK, PES, NonDopraTask. (CpuUsage=90%, Threshold=80%)
Fault Analysis
1. Run the display attack-source-trace slot 7 verbose command to view packet attacks on
the LPU in slot 7. The command output shows the detailed information about three UDP
attack packets. In fact, the device receives a large number of UDP attack packets. These
packets have distributed source and destination addresses, and their TTL values are all 1.
<HUAWEI>display attack-source-trace slot 7 verbose
Info: Please waiting......
No 1 Packet Info:
PeVlanid : 0
CeVlanid : 0
Attack Type : CPCAR
Attack Packet Time: 2012-03-11 14:43:37
L3 Type: IP
Version : 4
Header Length : 5 byte
Type Of Service: 0
Total Length : 28
Identification : 5123
Fragment Offset: 16384
TTL : 1
Protocol Num : 17
Checksum : 52658
Source Ip : 10.10.2.1
Dest Ip : 10.8.1.2

L4 Type: UDP
Source Port : 46526
Dest Port : 25903
Header Length: 8 byte
Checksum : 19668
Attack Trace Data:

00 18 82 38 86 5c 00 18 82 b1 77 27 08 00 45 00 00 1c 14 03 40 00 01 11
cd
b2 de 36 3e c2 7c ee fe 34 b5 be 65 2f 00 08 4c d4 00 00 00 00 00 00 00
00
00 00 00 00 00 00 00 00 00
----------------------------------
No 2 Packet Info:

PeVlanid : 0
CeVlanid : 0
Attack Type : CPCAR
L3 Type: IP
Version : 4
Type Of Service: 0
Total Length : 48
Fragment Offset: 0
TTL : 1
Protocol Num : 17
Checksum : 19325
Source Ip : 10.10.5.4
Dest Ip : 10.18.11.10
L4 Type: UDP
Source Port : 1055
Dest Port : 52978
Checksum : 29677
Attack Trace Data:

00 18 82 38 86 5c 00 18 82 b1 77 27 08 00 45 00 00 30 ed 0e 00 00 01 11
4b
7d de 36 62 6c 77 3b c9 53 04 1f ce f2 00 1c 73 ed 80 00 82 c0 e6 7c 00
80
0c 12 80 00 01 00 00 00 62 b4 5e
----------------------------------
No 3 Packet Info:

PeVlanid : 0
CeVlanid : 0
Attack Type : CPCAR
L3 Type: IP
Version : 4
Type Of Service: 0
Total Length : 48
Fragment Offset: 0
TTL : 1
Protocol Num : 17
Checksum : 19684
Source Ip : 10.10.5.4
Dest Ip : 10.18.11.10

L4 Type: UDP
Source Port : 1055
Dest Port : 52978
Checksum : 29677
Attack Trace Data:

00 18 82 38 86 5c 00 18 82 b1 77 27 08 00 45 00 00 30 eb a7 00 00 01 11
4c
e4 de 36 62 6c 77 3b c9 53 04 1f ce f2 00 1c 73 ed 80 00 82 c0 e6 7c 00
80
0c 12 80 00 01 00 00 00 62 b4 5e
----------------------------------
2. The destination address of attack packets is not the device. The packets are forwarded by
the NP and are not sent to the CPU on the LPU. Because the TTL values of the packets
are 1, the packets are sent to the CPU on the LPU for processing. As a result, a large
number of attack packets causes high CPU usage on the LPU.
3. UDP attack packets with a TTL value of 1 are sent to the CPU at 2 Mbit/s. When the
CPU processes a large number of UDP attack packets, its usage becomes high. As a
result, the CPU cannot process normal protocol packets properly. To reduce the impact
of unknown or attack packets on the CPU on the LPU, configure an attack defense policy
to limit the rates of the packets.
Procedure
Step 1 Run the cpu-defend policy 4 command to enter the attack defense policy view.
Step 2 Run the car index 39 cir 200 command to limit the rate at which protocol packets are sent to
the CPU to 200 kbit/s.
After the configuration is complete, the rates of all UDP packets with a TTL value of 1 are
limited to 200 kbit/s. Even if the packets are used for attacking, too many CPU resources are
also not occupied. The protocols on the device are still secure. The rate 200 kbit/s is
recommended to prevent normal protocol packets from being discarded.
----End
Summary
l The display attack-source-trace slot verbose command can be used to trace attack
sources. The command output shows attack sources and types.
l The packets with a TTL value of 1 are still sent to the CPU on the LPU for processing,
even if their destination address is not the device.
l The following table describes common protocol processing methods for attack defense.
Protocol Channel ID Processing Method
1 The rate of IPv4 OPTION packets is

limited to 200 kbit/s.
55 The rate of packets that cannot be

recognized by Layer 3 protocols is

Protocol Channel ID Processing Method
39 The rate of IPv4 TTL timeout packets is

limited from the default 2 Mbit/s to 200
kbit/s.
40 The rate of IPv4 MTU fragmentation

packets is limited to 100 kbit/s.
43 The rate of MPLS TTL timeout packets is

limited from the default 2 Mbit/s to 200
kbit/s.
44 The rate of MPLS MTU fragmentation

packets is limited to 100 kbit/s.
17 The rate of DHCP response packets is

6.3 Clock Synchronization Troubleshooting

6.3.1 Bit Errors Occur on NodeBs
NOTE
Fault Symptom
On an IP RAN, PPP services are transmitted between RSGs and NodeBs. The clock slave
command is configured on the CPOS interface that connects an RSG to a transport device. A
large number of pointer adjustment events occur on the transport devices and bit errors occur
on the NodeBs.

Fault Analysis
1. Judging from the fault symptom, the possible cause is clock asynchronization. Run the
display clock config and display clock source commands on the primary and secondary
RSGs to check clock configurations. The command output shows that the clock
synchronization function is disabled.
Enable the clock synchronization function on each RSG for them to be synchronized
with connected transport devices.
Procedure
Step 1 Run:
system-view
Step 2 Run:
clock ethernet-synchronization enable
Enable the clock synchronization function globally.
Step 3 Run:
controller cpos controller-number
The view of the CPOS interface that connects the RSG to the transport device is displayed.
Step 4 Run:
clock synchronization enable
The clock synchronization function is enabled on the CPOS interface.
After the clock synchronization function is enabled on the primary and secondary RSGs, the
fault is resolved.
----End
Summary
Ensure clock synchronization across an IP RAN for services to run properly.
6.4 Telnet Troubleshooting

6.4.1 Users Are Forced Offline 10-plus Seconds After They Log In
Fault Symptom
On the network shown in Figure 6-2, users access the network through Router B, which
authenticates, authorizes, and charges the users.
Originally, Router B uses the RADIUS protocol to perform authentication and accounting.
After the RADIUS server fails, the administrator adopts local authentication temporarily.

Figure 6-2 Networking diagram of user access
Domain huawei
RouterB
Network
129.7.66.66/24
RouterA
Destination 129.7.66.67/24
network
After the configurations, users are forced offline 10-plus seconds after they log in.
Fault Analysis
1. Run the display trapbuffer and display logbuffer commands on Router B to check
whether a trap or a log indicating that users are forced offline is recorded. The following
trap information is displayed:
AAA cut user!
2. Run the display current-configuration command on Router B to check the AAA

configuration. The command output shows that local authentication and RADIUS
accounting are adopted. Details are as follows:
radius-server template provera
radius-server shared-key xxxxxx
radius-server authentication 129.7.66.66 1645
radius-server accounting 129.7.66.66 1646
undo radius-server user-name domain-included
#
aaa
local-user telenor password cipher xxxxxxx
authentication-scheme default
#
authentication-scheme provera
authentication-mode radius local
#
authorization-scheme default
#
accounting-scheme default
accounting-scheme provera
#
domain default
#

domain huawei
authentication-scheme provera
accounting-scheme provera
radius-server provera
#
user privilege level 15
set authentication password cipher $1a$.]U;PI9EtF$%$qzNQb7:,PNeT*K+i_#UYW
%@qVRrNa0`\.t*^%@$
history-command max-size 256
screen-length 15
Because the RADIUS server is unavailable, real-time accounting fails. You can run the
accounting interim-fail command to configure a real-time accounting failure policy to
determine whether to keep users online or force users offline after the real-time
accounting fails.
The period after which login users are forced offline is determined by the retransmission
timeout period and retransmission times, which are configured by using the radius-
server timeout and radius-server retransmit commands respectively. By default, data
is retransmitted every 5 seconds for three consecutive times. If data fails to be
retransmitted 15 seconds after login, users are forced offline.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the aaa command to enter the AAA view.
Step 3 Run the domain huawei command to enter the Huawei domain view.
Step 4 Run the undo accounting-scheme provera command to configure the default accounting
scheme for users in the domain, that is, non-accounting.
You can select any of the following methods to clear the fault:
l Run the accounting-mode { local | none } command to change the accounting mode to
local accounting or non-accounting.
– For common users that are charged when they access the network, such as PPPoE
users, you can change the accounting mode to local accounting to continue charging
login users.
– Administrator users such as Telnet users and FTP users are not charged, and
therefore you can change their accounting mode to non-accounting.
l Run the accounting interim-fail online command to configure to keep users online
when real-time accounting fails.
l Run the undo accounting-scheme provera command to configure the default
accounting scheme for the domain, that is, non-accounting.
In this troubleshooting case, Router B mainly authenticates Telnet users that do not need to be
charged, and therefore the non-accounting scheme is applicable. You can run the undo
accounting-scheme provera command to configure the non-accounting scheme.
After the preceding configurations, users can log in without being forced offline. The fault is
cleared.
----End

Summary
On the access network using AAA authentication, if the remote server is unavailable and local
authentication is adopted, the accounting scheme must be local accounting or non-accounting.
Otherwise, users are forced offline.
6.5 SSH Troubleshooting

6.5.1 The Administrator Cannot Log in to the router Through SSH
Due to Inconsistent Key Lengths
NOTE
Fault Symptom
In the networking shown in Figure 6-3, the administrator needs to log in to the router through
SSH. After the configuration, the administrator fails to log in.
Figure 6-3 The administrator failing to log in to the router through SSH
SSH Client SSH Server
Fault Analysis
1. Check information about user login, and you can find the following information:
$ ssh -l client001 10.1.1.1
ssh_rsa_verify: RSA modulus too small: 512 < minimum 768 bits
key_verify failed for server_host_key
The preceding information shows that the key generated on the server is less than 768
bits. Therefore, the SSH connection cannot be set up.
Procedure
Step 1 Run the system-view view to enter the system view.
Step 2 Run the rsa local-key-pair create command to change the length of the key to 1024, in bits.
After entering the rsa local-key-pair create command, the system prompts you to enter the
number of bits of the host key. If the RSA key exists, the system prompts you to confirm
whether to change the original key. The procedure is as follows:
[HUAWEI]rsa local-key-pair create
The key name will be: HUAWEI_Host
% RSA keys defined for HUAWEI_Host already exist.

Confirm to replace them? [Y/N]:y

The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus[default = 512]:1024
Generating keys...
.................++++++++++++
...++++++++++++
.................................++++++++
.............++++++++
After the preceding operations, the administrator can log in to the router through SSH. The
fault is cleared.
----End
Summary
The lengths of keys configured on the SSH server should be consistent with the requirements
of SSH clients.
6.5.2 Login to the SSH Server Fails Because a Local RSA Key Pair
Is Not Configured
NOTE
Fault Symptom
The Router functions as an SSH server. The Router and a client are configured with SSH to
allow the client to log in to the SSH server.
Figure 6-4 Networking Diagram of SSH Server Fails

GE1/0/0
10.1.1.1/32
GE1/0/1
10.1.1.2/32
SSH Client SSH Server
After the configurations, the client cannot log in to the SSH server.
Fault Analysis
1. Run the display current-configuration configuration command on the Router to check
configurations.
#
protocol inbound ssh authentication-mode aaa
#
aaa local-user abc password cipher $1a$1V%k5k!LRL$,cPI9'[Qc6b0vrQ7T<`;/
4.wOMtWY0=pLY#Ma.vE$ ssh user huawei
authentication-type password

The preceding information shows that the Router is configured with SSH that requires
password authentication but no local RSA key pair is generated.
If the user interface adopts the SSH protocol, the rsa local-key-pair create command
must be used to create a local RSA key pair after SSH is enabled.
Procedure
Step 2 Run the rsa local-key-pair create command to generate a local RSA key pair.
After the operations, the client can log in to the SSH server. The fault is therefore rectified.
----End
Summary
Creating a local RSA key pair is a prerequisite to SSH login. That is, the rsa local-key-pair
create command must be used to create a local RSA key pair before the other SSH-related
configurations.
6.6 NetStream
NOTE
NetStream cannot be configured on the X1 and X2 models of theNE40E&NE80E.
NOTE
The NetStream function conforms to IETF RFC3954. For security risks, see IETF RFC3954. This
function involves analyzing the communications information of terminal customers. Before enabling the
function, ensure that it is performed within the boundaries permitted by applicable laws and regulations.
Effective measures must be taken to ensure that information is securely protected.
6.6.1 NetStream Sampling Fails
NOTE
Fault Symptom
In the networking shown in Figure 6-5, network A connects to a wide area network (WAN)
through Router A; NetStream is enabled on Router A so that the NetStream SPU performs
integrated flow aggregation and output and then sends the aggregated flow to the NetStream
Collector (NSC). The NSC is responsible for collecting the statistics data from the router. The
NetStream Data Analyzer (NDA) analyzes the statistics data.
After the configurations, the NSC fails to receive sampled data.

Figure 6-5 Networking diagram for the scenario that netstream sampling fails
NSC&NDA
Network A WAN
RouterA
Fault Analysis
1. Run the display device command on Router A to check whether the NetStream SPU
functions properly. It is found that the Status item is Normal, which indicates that the
NetStream SPU runs normally.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
3 SPU Present Registered Normal NA
21 LCD Present Registered Normal NA
2. Run the display netstream all command to check NetStream configurations, and you
can find that no NetStream SPU is specified. Therefore, Router A cannot output sampled
packets properly.
ip netstream sampler fix-packets 1000 inbound
ip netstream sampler fix-packets 1000 outbound
ip netstream export source 192.168.2.1
ip netstream export host 192.168.2.2 9001
Procedure
Step 1 Run the set board-type slot slot-id netstream command on Router A to configure the SPUC
as a NetStream SPUC.
After the configuration, run the display device slot-id command. The Description item in the
command output is Service Processing Unit - Netstream.

Step 3 Run the slot slot-id command to enter the slot view of the LPU for NetStream sampling.
Step 4 Run the ip netstream sampler to slot slot-id command to configure integrated NetStream
and specify the NetStream SPU for sampling.
The Router supports more than one NetStream SPU. In this case, you need to specify a
NetStream SPU on which sampled packets are processed.
After the preceding operations, the NSC can normally receive sampled packets. The fault is
therefore rectified.
----End
Summary
Integrated NetStream indicates that the LPU samples packets and then sends the sampled
packets to the NetStream SPU for integrated flow aggregation and output. In integrated
NetStream, the NetStream SPU needs to be specified through a command. Otherwise,
sampled packets cannot be output.
6.6.2 NetStream Original Traffic Sampling on a VLANIF Interface

Fails
NOTE
Faulty Symptom
NetStream is configured on VLANIF 2051 of the NE40E&NE80E to sample upstream traffic
and output traffic as original flows. The sampled packets, however, are not received on the
packet analyzer, which indicates that original traffic sampling fails.
Fault Analysis
1. Run the display ip netstream cache command to view information about the specified
NetStream packets.
[HUAWEI] display ip netstream cache origin slot 1
Info: No required stream can be found in the cache.
The command output shows that the cache for original traffic is empty and no NetStream
packets are output.
2. Run the display interface vlanif 2051 command to check whether VLANIF 2051
receives any packet.
[HUAWEI] display interface vlanif 2051
...
Last 300 seconds input rate: 1392 bits/sec, 0 packets/sec
Input: 11501041 bytes, 7726 packets
Output: 50618185 bytes, 40620 packets
Input:
Unicast: 15 packets, Multicast: 7664 packets
Broadcast: 47 packets, JumboOctets: 0 packets
CRC: 0 packets, Symbol: 0 packets

Overrun: 0 packets, InRangeLength: 0 packets

LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets
Fragment: 0 packets, Undersized Frame: 0 packets
RxPause: 0 packets
....
The Last 300 seconds input rate and input items displayed in the command output
show that there are packets received on VLANIF 2051.
3. Run the display netstream all command to check whether NetStream is properly
configured.
[HUAWEI]display netstream all
system
ip netstream sampler random-packets 1000 inbound
ip netstream export source 10.1.1.2
ip netstream export host 60.1.1.1 20
slot 0
Vlanif2051
ip netstream inbound
slot 2
ip netstream sampler to slot self
This command output shows that the source and destination addresses of NetStream
packets are correct and upstream NetStream is enabled on VLANIF 2051.
In addition, the sampling mode is random packet sampling. VLANIF interfaces,
however, support fixed packet sampling rather than random packet sampling. In this
case, there is no packet in the cache for original traffic.
Procedure
Step 1 Run the ip netstream sampler fix-packets 1000 inbound command in the view of VLANIF
2051 to configure the sampling mode as fixed packet sampling.
Step 2 Run the display ip netstream cache command to check the cache for original traffic.
[HUAWEI] display ip netstream cache origin slot 1
Show information of IP and MPLS cache of slot 1 is starting.
get show cache user data success.
DstIf DstP Msk Pro Tos Flags Packets

SrcIf SrcP Msk NextHop
DstIP DstAs
SrcIP SrcAs
BGP: BGP NextHop TopLabelType Direction
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2
Label3 Exp3 Bottom3
TopLabelIpAddress VlanId
--------------------------------------------------------------------------
Null 179 0 6 192 24 72
VL2501 51971 0 0.0.0.0
50.1.1.2 0
50.1.1.1 0
0.0.0.0 0 in
0 0 0
0 0 0
0 0 0
0.0.0.0 2501
The command output shows that there is original traffic in the cache. The fault is therefore
rectified.
----End

Summary
Logical interfaces such as VLANIF interfaces support only fixed packet sampling rather than
random packet sampling in NetStream.
6.7 GTL License Troubleshooting
6.7.1 The Slave MPU Resets Because the GTL File Does Not
Comply With the Specification
NOTE
Fault Symptom
The slave MPU of the device resets because of an exception. Run the display device
command to check the reason why the slave MPU resets. The command output is as follows:
<HUAWEI>display device 9
Mpu9's detail information:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Date of slot9 is reset: 2000-01-01
Time of slot9 is reset: 00:01:19
Sequence of event occur: 1
Reason is:Cold Start
reset code:f000b,Module:MPU.
Fault Analysis
The GTL file may not comply with the specification, or the hardware of the slave MPU is
faulty.
Check information about the GTL file.
1. Run the display license command to check the GTL file.
<HUAWEI>display license
Active License on master board: cfcard:/on1049656.dat
Huawei Technologies Co.,Ltd.
2. Run the more file-name command to check the ESN information about MPUs in the
GTL file.
<HUAWEI>more on1049656.dat
LicenseSerialNo=LIC20100125000E00
Creator=Huawei Technologies Co.,Ltd.
CreatedTime=2010-01-25 10:12:38
Product=NetEngine80E
Feature=CRFEA1
Esn="030DGS1099000227"
Attrib="DEMO, 2010-03-31, 60, NULL, NULL, NULL"
Resource="LCR5TUNNEL05=32, LCR5BTOA00=32"
Function="LCR5BSVC00=1"

Comment="ON1049656-A0D27B59001-0123456789ABCD"
Sign=
26D1DE252A0F6AFDC2C97D4F1C866FD558E672A715BE4D12E3DA212E00C9BA19BA25B061C0CF53
AF5107EF02089359E8C74338DF46265BD991675E12683602
9CFE0DF2ED2C21DA057E44D1C1E9C3A9BA3A9D2B6103F1346365D50356C34CC2953348227648B7
9FF2F7D26E15DAFBF059810E61FC7E1607ED1A5C7741017A79DD
3. Run the display esn command to check the ESN information on the MPU.
<HUAWEI>display esn
ESN of master: 030DGS1099000227
ESN of slave: 030DGS1099000226
The command output shows that the GTL file contains only the ESN (030DGS1099000227)
of the master MPU, not the ESN (030DGS1099000226) of the slave MPU. The cause of this
fault is that the current GTL file supports the ESN of the master MPU rather than the ESN of
the slave MPU. As a result, the slave MPU enters the trial period. After the trial period
expires, the slave MPU is restarted, and the master/slave MPU relationship is deleted.
Procedure
Step 1 Apply for a GTL file that can be activated on both the master and slave MPUs.
Step 2 Activate the new GTL file.
Step 3 Restart the slave MPU.
----End
Summary
None.
6.7.2 The Statuses of the Master and Slave MPUs of an NE5000E

Are Asynchronous Caused by the Invalid GTL of the Slave MPU
NOTE
Fault Symptom
The statuses of the master and slave MPUs are displayed as asynchronous using the display
switchover state command.
<HUAWEI>display switchover state
Slot clc1/18 HA FSM State(master): The slave has been inserted

Slot clc1/17 HA FSM State(slave): ready
The display device command output shows that the MPUs are registered correctly.
<HUAWEI>display device
17 MPU Present Registered Normal System Slave

18 MPU Present NA Normal System Master

Fault Analysis
1. The relevant log indicates that the slave MPU resets because the GTL becomes invalid.
Mar 31 2011 01:42:10 NE5KE %%01LCS/4/STATECHANGED(l):License state changed
from demo to inactive.
Mar 31 2011 01:42:10 NE5KE %%01LCS/4/RESETSLAVE(l):GTL will reset the slave
board, because the License file in demo mode on the slave board expires but
the License file on the master board is fully active.
Mar 31 2011 01:45:49 Quidway %%01LCS/4/S2MDISABLE(l)[23]:The relationship of
the master board and the slave board has been deleted by GTL, because the
License file on the slave board is deactivatedbut that on the master board is
active or in demo.
2. It is suspected that the ESN in the GTL file does not match that in the slave MPU,
causing the slave MPU to reset and close the master/slave connection. The display esn
command output shows that the ESN in the GTL file does not match that of the device.
3. The display license command output shows that no GTL file is activated on the device.
The log of the master MPU indicates that the user deactivated the GTL before.
Apr 1 2011 18:49:20 NE5KE %%01SHELL/5/CMDRECORD(l):Record command
information. (Task=VT0 , Ip=10.10.10.1, User=xxxx Command="undo license
active")
After replacing the slave MPU, the user did not update the ESN in the GTL file, causing
the slave MPU to reset because of the invalid GTL and close the master/slave
connection. As a result, the statuses of the master and slave MPUs are asynchronous.
After the GTL of the master MPU is deactivated, the statuses of the master and slave
MPUs are still asynchronous.
Since the master/slave connection is closed when the slave MPU resets, the problem can
be solved only by restarting the slave MPU before its GTL is activated.
Procedure
Step 1 After the GTL file is deactivated, restart the slave MPU.
If you want to keep the GTL file valid, change the ESN in the license center.
After the preceding operations, the statues of the master and slave MPUs are asynchronous.
The fault is rectified.
----End
Summary
After replacing the slave MPU, change the ESN in the license center. Otherwise, the slave
MPU restarts after the license is invalid, causing the statues of the master and slave MPUs to
be asynchronous.
If the invalid GTL file of the slave MPU does not affect the device service, you need to
deactivate the license and restart the slave MPU and change the ESN in the license center.
6.8 GE Interface Troubleshooting

6.8.1 The 10GE Interfaces Connecting Two Devices Cannot Be Up

NOTE
Fault Symptom
When two NE40E&NE80Es are connected through 10GE interfaces, the interfaces cannot be
Up.
Fault Analysis
1. Run the display interface GigabitEthernet 1/0/0 command in the system view in order
to view the interface information.
GigabitEthernet1/0/0 current state : DOWN
Line protocol current state : DOWN
Description:TO[HUAWEI-A1]-10G-14/0/0
Route Port,The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
0018-82b1-7c2d
The Transceiver Vendor Name is FINISAR CORP.
The Transceiver Vendor PN is FTLX1412M3BCL
BW: 10G, Transceiver Mode: SingleMode
WaveLength: 1310nm, Transmission Distance: 10km
The receiving optical power and transmitting optical power displayed through the Rx
Power and Tx Power items respectively are both in the normal range, which indicates
that the fault is not caused by optical power.
2. Replace the optical fiber. The fault persists, which indicates that the fault is not caused
by the optical fiber.
3. Replace the optical module. The fault persists, which indicates that the fault is not caused
by the optical module.
4. Check the boards on the two interconnected devices. It is found that the 10GE interface
on the local device is in the LAN transmission mode whereas the 10GE interface on the
remote device is in the WAN transmission mode. Therefore, it can be inferred that the
10GE interfaces cannot be Up because their transmission modes do not match.
Procedure
Step 2 Run the interface interface-type interface-number command to enter the interface view.
Step 3 Run the set transfer-mode wan command to set the transmission mode of the interface to
WAN so that the transmission modes of the two interfaces match.
----End
Summary
When two interfaces are connected through the 10GE interfaces the 10GE interfaces cannot
be Up. Check the following items to correct the fault:

1. Optical power
2. Optical fiber
3. Optical module
4. Transmission modes of the two interconnected interfaces
The 10GE interfaces can work in either WAN or LAN transmission mode. In different modes,
physical frames are encapsulated in different manners. Therefore, a 10GE interface working
in the WAN transmission mode cannot communicate with a 10GE interface working in the
LAN transmission mode. In this case, when the two devices are connected through 10GE
interfaces, ensure that their transmission modes are the same.
6.8.2 Interconnected Interfaces Alternate Between Up/Down

States
NOTE
Fault Symptom
Two devices are directly connected through GE interfaces by optical fibers. The GE
interfaces, however,alternate between Up/Down states. The following log messages are
displayed:
%Nov 12 11:00:10 2007 RouterA PHY/2/PHY:Slot=2;GigabitEthernet2/0/0: change
status to down
%Nov 12 11:00:11 2007 RouterB PHY/2/PHY:Slot=2;GigabitEthernet2/0/0: change
status to up
Fault Analysis
1. Run the display interface [ interface-type interface-number ] command in any view on
the two interconnected interfaces, and you can find that both interfaces receive CRC
error packets. The possible causes are as follows:
a. Data transmission is interfered and error codes occur.
b. The optical power is unstable.
c. The transmit interface on the peer device fails.
d. An error occurs during packet resolution on the local device.
2. Through the preceding log messages, you can find that the two interfaces do not turn Up
or Down at the same time.
If auto-negotiation is configured, the interconnected interfaces automatically send
negotiation frames after receiving optical signals. If both interfaces receive negotiation
frames, they both go Up. In this troubleshooting case, the two interfaces do not turn Up
or Down at the same time, which indicates that one interface receives negotiation frames
while the other interface does not receive any. Therefore, it can be inferred that a fault
occurs during packet transmission over the link.
Through the preceding analysis, it can be determined that a fault occurs on the
transmission link. In this case, the following information describes how to locate the
fault on the transmission link:

3. Through on-site measurement, it is found that the receive optical power of the two
interfaces is -20db, which is within specification for the optical module. Therefore, the
possibility of a module or optical fiber fault is ruled out.
4. Check the optical fibers and optical modules for other anomalies; in so doing, it can be
determined that the fiber end is contaminated.
It can be identified that error codes occur on the receive interface due to contamination of the
fiber end.
Procedure
Step 1 After the fiber end is cleaned, the receive interface goes Up.
The fault is therefore corrected.
----End
Summary
In the case of long-distance transmission, ensure that the optical fiber is bent at less than 90
degrees, free from damage or contamination, and is properly connected.
6.8.3 Severe Packet Loss Occurs After the FE Optical Module Is

Mistakenly Inserted into a GE Optical Interface
NOTE
Fault Symptom
Users connected to GE 1/0/0 on the board of the NE40E&NE80E report that the Internet is
slow and severe packet loss occurs.
Fault Analysis
1. Check logs on the NE40E&NE80E. No exception is displayed.
2. Run the display interface gigabitethernet1/0/0 command to check the interface status.
It is found that the interface and protocol are both Up and no CRC error occurs.
The maximum bandwidth of the interface is 1 Gbit/s whereas the maximum bandwidth
of the optical module is 155 Mbit/s. It can be inferred that the optical module
mismatches the interface, which causes severe packet loss.
Procedure
Step 1 Replace the FE optical module with a GE optical module and insert the GE optical module
into the interface. Then, users can access the Internet normally and the fault is corrected.
----End

Summary
Mismatch between the optical module and the interface causes severe packet loss. The
appearance of the FE optical module and the GE optical interface module are the same. It is
therefore necessary to carefully check the parameters of the optical module before inserting
the optical module into the interface.
6.8.4 Interface Rate of an NE40E&NE80E-X2 Decreases from 10

Gbit/s to 10 Mbit/s When the License Expires
NOTE
Problem Description
The interface rate of an NE40E&NE80E decreases suddenly from 10 Gbit/s to 10 Mbit/s and
Problem Analysis
This problem is likely to be caused by the following issues:
1. The interface is faulty.

2. The board is faulty.
3. The license has expired.
Identify the cause by verifying the preceding issues one by one:
1. Run the display interface brief main command to view brief information about all
interfaces and find that all but the processing rate is normal. Replace the optical module
and the problem persists. Therefore, the problem is not caused by an interface or optical
module fault.
2. When a board is faulty, the alarm indicator turns on and alarm information is generated
on the device. In this case, the alarm indicator does not turn on and no alarm information
is generated. Therefore, the problem is not caused by a board fault.
3. Because the device uses a temporary license, there is a possibility that the license has
expired. Run the display license command to check the license file:
<NE40E&NE80E-X2>display license
Info: No license activated.
The output displays no license file. Therefore, the problem occurs because the license
has expired.
Procedure
Step 1 Install a formal license file and then check the interface rate. The interface rate remains at 10
Mbit/s.
Step 2 Run the slot slot-id command. The specified slot view is displayed.

Step 3 Run the active 10ge-interface command in the slot view to activate the interface and then
check the interface rate. The interface rate increases to 10 Gbit/s. The problem is resolved.
----End
Conclusion
If the interface rate of an NE40E&NE80E-X1/X2 decreases from 10 Gbit/s to 10 Mbit/s,
check whether the license has expired. If the license has expired, contact Huawei technical
support personnel to obtain a new license.
6.9 ARP Troubleshooting
6.9.1 PCs on the Same Network Segment Cannot Access Each

Other Because ARP Proxy Is Not Enabled
NOTE
Fault Symptom
On the network shown in Figure 6-6, PC1 and PC2 reside on the same network segment
192.168.0.0/16. The two routers have static routes to the network segment of each other.
After the configuration is complete, PC1 fails to ping PC2.
Figure 6-6 Networking diagram for the scenario that the PCs on the same network segment
cannot access each other
RouterA RouterB
Network Network
PC1 PC2
192.168.1.2/16 192.168.1.1/24 192.168.2.1/24 192.168.2.2/16

00e0-fc39-80aa 00e0-fc39-80bb
Fault Analysis
1. Run the arp -a command on PC1 to check all ARP entries. You can find that there is no
mapping between the IP address and MAC address of PC2. It indicates that the ARP
entry is not learned when the ping command is run. When Router A receives the ARP
Request packet from PC1, it finds that the destination IP address in the packet is not the
IP address of the local interface. Therefore, Router A discards the ARP Request packet.

NOTE
Usually, when the router receives an ARP Request packet, it checks whether the packet is for itself. If
yes, the router sends an ARP Reply packet; if no, the router discards the ARP Request packet.
If routed proxy ARP is enabled, the router does not directly discard a received ARP Request packet that
is not for itself. Instead, it checks its own routing table to see if there is a route to the intended
destination of the ARP Request packet. If there is such a route and conditions permit, the router offers
its own MAC address to the sender of the ARP Request packet in reply as a proxy. Then, the sender of
the ARP Request packet sends the packets to the router, which will forward the packets to the intended
destination.
Procedure
Step 1 Run the system-view command to enter the system view on RouterA (or RouterB).
Step 2 Run the interface interface-type interface-number command to enter the view of the
customer-facing interface.
Step 3 Run the arp-proxy enable command to enable routed proxy ARP on the interface.
Step 4 Run the ping 192.168.2.2 command on PC1 to ping the IP address of PC2. Then, run the arp
-a command on PC1. You can find that the MAC address corresponding to the IP address of
PC2 is the MAC address of the interface connected to PC1 on RouterA.
C:\Documents and Settings\Administrator>arp -a
Interface: 192.168.1.2 --- 0x2
Internet Address Physical Address Type
192.168.2.2 00e0-fc39-80aa dynamic
When the configuration is complete, PC1 can successfully ping PC2, and the fault is rectified.
----End
Summary
Proxy ARP is a technique by which a device serving as a proxy on a given network answers
the ARP requests for a network address that is not on that network. There are three proxy
ARP modes that can be applied in different situations:
l Routed proxy ARP: enables the communications between computers on the same
network segment but on different physical networks.
l Proxy ARP within a VLAN: enables the communications between computers within a
VLAN configured with user isolation.
l Proxy ARP between VLANs: enables Layer 2 communications between computers in
different VLANs.
6.9.2 The Webpage Cannot Be Opened After Service Cutover Due

to Improper Static ARP Configurations
NOTE

Fault Symptom
Users access the backbone network through Router A and Router B. Traffic from the access
network is sent to Router A through Eth-Trunk 1.
Router A then sends the traffic to a packet analyzer to which Router A is connected through
GE 1/0/2. The packet analyzer is deployed to analyze the packets from the access network and
packets from the backbone network. After analyzing the packets, the packet analyzer returns
the packets through the interface from which the packet analyzer receives the packets.
Figure 6-7 The Webpage Cannot Be Opened After Service Cutover Due to Improper Static
ARP Configurations
Backbone
Network
192.168.100.50 RouterA RouterB
Packets GE 1/0/2
Analyzer
Eth-Trunk 1
SwitchA SwitchB
Access
Network
After service cutover, it is found that the webpage cannot be opened.
Fault Analysis
1. Check the routing table on Switch A.
You can find that the routing table of Switch A is correct. Packets destined for the target
network are load balanced to Router A.
2. Run the display current-configuration command on Router A to check the current
configuration. You can find that a traffic policy is configured on the associated interface.
[RouterA] display current-configuration
#

description HUAWEI-RouterA
ip address 10.1.1.1 255.255.255.252
traffic-policy Fivedai inbound
pim sm
ospf cost 1000
mpls
mpls ldp
#
traffic policy Fivedai
classifier Fivedai behavior Fivedai
traffic classifier Fivedai operator or
if-match acl 3100
traffic behavior Fivedai
redirect ip-nexthop 192.168.100.50
acl number 3100
rule 5 permit tcp destination-port eq www
All packets sent by Switch A for accessing the webpage are redirected to the packet
analyzer.
3. Run the display traffic policy statistics command to check the packets matching the
traffic policy. You can find that all the packets match the traffic policy.
[RouterA] display traffic policy statistics interface GigabitEthernet 1/0/0
inbound verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet1/0/0
Traffic policy inbound: Fivedai
Traffic policy applied at 2009-07-02 21:04:40
Statistics enabled at 2009-07-10 02:39:28
Statistics last cleared: Never
Rule number: 5 IPv4, 0 IPv6
Current status: OK!
Classifier: Fivedai operator or

if-match ACL 3100
584,574,637 bytes, 4,505,760 packets
Last 30 seconds rate 1,858 pps, 2,270,232 bps
4. Run the display current-configuration command on Router A to check the related

configurations of GE 1/0/2 and the packet analyzer.
[RouterA] display current-configuration
#
arp static 192.168.100.50 00e0-1111-1111
You can find that Router A has a static ARP entry with the MAC address being the MAC
address of the packet analyzer and the IP address being the IP address of the packet
analyzer.
When a packet is sent from GE 1/0/2 to the packet analyzer, the destination MAC
address of the packet is 00e0-1111-1111. After the packet analyzer returns the analyzed
packet, the MAC address of the packet received on GE 1/0/2 is still 00e0-1111-1111, not
the MAC address (2222-2222-2222) of GE 1/0/2. As a result, the packet is discarded.
So far, the fault has been located.
Procedure
Step 1 Run the system-view command on Router A to enter the system view.
Step 2 Run the undo arp static 192.168.100.50 00e0-1111-1111 command to delete the original ARP
configurations.
Step 3 Run the arp static 192.168.100.50 2222-2222-2222 command to reconfigure a static ARP
entry and change the MAC address of the ARP entry to the MAC address of GE 1/0/2.

After the configuration, the MAC address of a packet sent by GE 1/0/2 to the packet analyzer
is the MAC address of GE 1/0/2. Therefore, the MAC address of the packet returned by the
packet analyzer is the MAC address of GE 1/0/2, and the packet can be received and
forwarded. The user can normally open the webpage. Therefore, the fault is rectified.
----End
Summary
When configuring static ARP on a device connected to a special device, fully consider the
impacts of packet processing by the special device.
6.9.3 ARP Entries on the NE40E&NE80E Fail to Be Updated in

Time Because the Received Gratuitous ARP Packets Do Not
Comply with the RFC Standard
NOTE
Fault Symptom
A CE, which is a non-Huawei device, is connected to two switches for accessing two
NE40E&NE80Es that are in a VRRP backup group. Router A serves as the master device,
and Router B serves as the backup device. GE 1/0/0 and GE 1/0/1 on the CE are connected to
the two switches respectively. The networking diagram is as follows:
Figure 6-8 Typical Network Diagram for VRRP

Router A Router B
GE1/0/0 GE1/0/0
GE2/0/0 GE2/0/0
Switch A Switch B
GE1/0/0 GE1/0/1
0007-7243-8778 0007-7266-c77a
CE
168.1.1.1 168.1.1.2
After the link between Switch A and the CE is disconnected, services are interrupted
immediately and then restored 20 minutes later. During service interruption, packets are lost
in the ping from the CE to an extranet server or to the master device in the VRRP backup
group.

Fault Analysis
1. To check the connectivity between Router A and the CE, first change the MTUs on GE
1/0/0 of Router A, and GE 1/0/0 and GE 2/0/0 of Router B to 2000. Then, send 100
jumbo frames longer than 1518 bytes from Router A to GE 1/0/1 on the CE. One jumbo
frame is found lost.
NOTE
Since the jumbo frames on the network are only a few, using jumbo frames in the ping operation
facilitates checking the connectivity between devices. So, the MTU is increased to allow the
transmission of jumbo frames. Before changing the MTU, you need to evaluate whether the
change has any impact on the existing services. If the change will affect the existing services, do
not change the MTU.
<RouterA>ping -c 100 -s 2000 -m 10 -vpn cnc_signal 168.1.1.2
PING 168.1.1.2: 2000 data bytes, press CTRL_C to break
Request time out
--- 168.1.1.2 ping statistics ---

100 packet(s) transmitted
99 packet(s) received
1.00% packet loss
round-trip min/avg/max = 4/15/928 ms
2. Check the status of GE 1/0/0 and GE 2/0/0 on Router B. The statistics on the two
interfaces show that Router B has received all the 100 jumbo frames and forwarded them
to the CE. In the reverse direction, however, only 99 packets have been returned to
Router B, and Router B has forwarded all the packets to Router A. It indicates that the
forwarding between the two devices is normal and packet loss occurs on the CE.
<RouterB>display interface GigabitEthernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Description : Cc-Cc#GE#2585.2/0/8-HX.1/0/4-B, Switch Port
The Maximum Transmit Unit is 2000 bytes
Statistics last cleared: 2009-08-04 04:18:10
Input:
Unicast: 354, Multicast: 471
Broadcast: 85, Jumbo: 100
CRC: 0, Symbol: 0
Overrun: 0 , InRangeLength: 0
LongPacket: 0 , Jabber: 0, Alignment: 0
Fragment: 0, Undersized Frame: 0
RxPause: 0
Output:
Lost: 0, Overflow: 0, Underrun: 0
TxPause: 0
<RouterB>display interface GigabitEthernet 2/0/0
Description : CC-CC#GE#2585.H40.1/0/4-2511.H7810.0/0/11-B, Switch Port
The Maximum Transmit Unit is 2000 bytes
Statistics last cleared: 2009-08-04 04:18:10
Input:
CRC: 0, Symbol: 0
Overrun: 0 , InRangeLength: 0
LongPacket: 0 , Jabber: 0, Alignment: 0
Fragment: 0, Undersized Frame: 0

RxPause: 0
Output:
Lost: 0, Overflow: 0, Underrun: 0
TxPause: 0
3. Run the display arp interface gigabitethernet 2/0/0 command on Router B to check the
dynamic entries in the ARP mapping table on GE 2/0/0. The command output shows that
the MAC address of GE 1/0/1 on the CE is not contained in the mapping table.
4. Get packets head on Router B. It is found that gratuitous ARP packets are continuously
sent by the CE, but the format of the packets does not comply with the relevant RFC
standard. Therefore, the Router A directly discards such packets and does not update the
ARP entries in the ARP mapping table. After 20 minutes, services are restored when the
ARP entries are aged out and updated automatically.
Procedure
Step 1 Run the reset arp all command in user view to reset ARP entries and force the device to learn
ARP entries again. The CE successfully responds to the ARP Request packet and services are
restored.
The preceding operations are performed on Router A and Router B.
Step 3 Run the interface gigabitethernet 1/0/0 command to enter the view of GE 1/0/0.
Step 4 Run the mtu command to restore the original MTU setting.
----End
Summary
If the format of gratuitous ARP packets does not comply with the relevant standard, the ARP
entries on the connected devices cannot be updated in time.
6.10 IP Forwarding
6.10.1 Improper Static Route Configuration Causes Service

Interruption After Any of Multiple Links Fails
Networking Environment
On the network shown in Figure 6-9, there are three links between Router A and Router B.
On Router A, three static routes to 10.1.3.0/24 are configured for traffic load balancing.
After one of the three links is interrupted, services between Router A and Router B are all
interrupted, and traffic is not switched to the other two links for being forwarding.
Figure 6-9 Networking diagram for traffic load balancing among static routes
10.1.3.0/24
RouterA RouterB RouterC

Table 6-1 Interfaces and IP addresses

Local Device Local Interface Remote Interface Remote Device
and Its IP and Its IP
Address Address
Router A GE 1/0/0.1 GE 1/0/0.1 Router B

172.168.68.46/27 172.168.68.54/27

172.168.68.110/27 172.168.68.118/27

172.168.68.174/27 172.168.68.180/27
Router B GE 1/0/1 GE 1/0/0 Router C

10.1.3.1/24 10.1.3.2/24
Fault Analysis
1. Run the display ip routing-table ip-address [ mask | mask-length ] command on Router
A to view detailed information about the routes to 10.1.3.0/24. The command output
shows that a route becomes a blackhole route.
<HUAWEIA> display ip routing-table 10.1.3.0 24
------------------------------------------------------------------------------
Summary Count : 3
10.1.3.0/24 Static 60 0 RD 172.168.68.54 NULL0

Static 60 0 RD 172.168.68.118
GigabitEthernet1/0/0.2
Static 60 0 RD 172.168.68.180
GigabitEthernet1/0/0.3
If a device has multiple routes working in load balancing mode and one of the routes is a
blackhole route, the device forwards packets based on the first routing entry in the
routing table, but does not perform traffic load balancing among multiple routes. Based
on the sequence in which Forwarding Information Base (FIB) entries are delivered, the
FIB entry with NULL0 as an outbound interface is always the first entry. As a result, all
packets are forwarded based on the blackhole route and are discarded, causing all
services to be interrupted.
2. Run the display current-configuration command on Router A to view the static route
configuration.
#
ip route-static 10.1.3.0 255.255.255.0 NULL0 preference 100
ip route-static 10.1.3.0 255.255.255.0 172.168.68.54
ip route-static 10.1.3.0 255.255.255.0 172.168.68.118
ip route-static 10.1.3.0 255.255.255.0 172.168.68.180
ip route-static 172.168.68.0 255.255.255.0 NULL0 preference 100
#
In normal situations, a router forwards packets based on the second route in the routing
table, and finds an outbound interface GE 1/0/0.1 based on the next hop address of the

direct route 172.168.68.54/27 of GE 1/0/0.1. When GE 1/0/0.1 is faulty, this direct route
is withdrawn. The router needs to iterate another route to find another outbound interface
based on the next hop address 172.168.68.54, and finally selects the fifth route in the
routing table. The outbound interface of the fifth route is NULL0. In the route iteration
process, the route preference is the default value 60, not the route preference 100 after
iteration. Therefore, the iterated route is selected to forward packets and traffic is sent
out from NULL0, causing service interruption.
Procedure
Step 2 Run the undo ip route-static ip-address { mask | mask-length } nexthop-address command to
delete all static route configurations.
[HUAWEIA] undo ip route-static 10.1.3.0 255.255.255.0 172.168.68.54
Step 3 Run the ip route-static ip-address { mask | mask-length } interface-type interface-number

nexthop-address command to configure a static route and specify a next hop and an outbound
interface.
[HUAWEIA] ip route-static 10.1.3.0 255.255.255.0 GigabitEthernet 1/0/0.1
172.168.68.54
172.168.68.118
172.168.68.180
Step 4 Run the display ip routing-table ip-address [ mask | mask-length ] command to view detailed
routing information. The command output shows that the blackhole route is deleted and the
traffic is switched to the other two links that are working properly.
----End
Summary
If an outbound interface is specified for a configured static route, this static route will be
deleted when a link is faulty. This prevents incorrect route iteration.
6.11 OSPF Troubleshooting
6.11.1 OSPF Neighbor Relationship Cannot Become Full Due to

Redirection Configured on the Interface
NOTE

Fault Symptom
As shown in Figure 6-10, Router A is dual-homed to Router C and Router D. After link and
IP address adjustment, GE 1/0/2 on Router A is connected to Router C, as shown in Figure
6-11.
Figure 6-10 Networking diagram of the fault that OSPF neighbor relationship cannot become
Full (before link adjustment)
Router C Router D
GE1/0/5
GE1/0/4 GE1/0/5
GE1/0/4
GE1/0/1 GE1/0/2
GE1/0/2 GE1/0/1
Router A Router B
Figure 6-11 Networking diagram of the fault that OSPF neighbor relationship cannot become
Full (after link adjustment)
Router C Router D
GE1/0/5
GE1/0/4 GE1/0/5
GE1/0/4
GE1/0/1 GE1/0/2
GE1/0/2
GE1/0/1
Router A Router B
After the adjustment, the OSPF neighbor relationship cannot be established between Router A
and Router C, and the neighbor relationship on Router C remains in the ExStart state.
Fault Analysis
1. Run the display ospf peer command on Router C to view the State field. The command
output shows that the OSPF neighbor relationship is in the ExStart state.
It indicates that Router C has received a Hello packet from the neighbor and replied with
a DD packet but not received any DD packet from the neighbor.
2. Receiving the Hello packet from the neighbor indicates that the link between Router A
and Router C works properly. Therefore, the fault may have occurred because Router C
discarded received DD packets instead of sending them to the CPU.

Run the interface interface-type interface-number command to enter the interface view.
Then, run the display this command. The command output shows that the interface is
configured with a traffic policy as shown below.
[HUAWEI] interface gigabitethernet 1/0/4
#
undo shutdown
ip address 10.61.1.185 255.255.255.252
traffic-policy Redirect inbound
#
Based on the traffic policy and the corresponding traffic classifier and traffic behavior,
the IP address of GE 1/0/3 on Router A matches ACL 3000. Therefore, packets are
redirected to GE 1/0/3 instead of being sent to the CPU.
[HUAWEI] display traffic policy user-defined Redirect
User Defined Traffic Policy Information:
Policy: Redirect
Share-mode
Classifier: default-class
Behavior: be
-none-
Classifier: user
Behavior: toCR
Redirecting:
Redirect Ip-NextHop 10.61.1.241 Interface GigabitEthernet1/0/3
[HUAWEI] display traffic classifier user-defined user
User Defined Classifier Information:
Classifier: user
Operator: OR
Rule(s) : if-match acl 3000
[HUAWEI] display acl 3000
Advanced ACL 3000, 1 rule
Acl's step is 5
rule 15 permit ip source 10.61.0.0 0.0.63.255
Because the destination address of Hello packets is a reserved multicast address, Hello
packets are not redirected but are sent to the CPU for further processing. A DD packet is
a unicast packet carrying an interface address, and therefore it is redirected to another
interface and fails to be sent to the CPU.
Procedure
Step 3 Run the undo traffic-policy inbound command to delete the traffic policy.
After deleting the traffic policy, you can run the display ospf peer command to view the
OSPF neighbor relationship. The command output shows that the OSPF neighbor relationship
is Full. The fault is rectified.
NOTE
After the OSPF neighbor relationship becomes Full, you can run the traffic-policy command to re-apply
the traffic policy to the interface. Running this command does not affect the OSPF neighbor relationship.
If the OSPF neighbor relationship becomes Down due to link changes or removal of optical fibers, the
OSPF neighbor relationship cannot become Full again.
----End

Summary
The destination address of a Hello packet is a reserved multicast address, whereas a DD
packet is a unicast packet. Hello packets whose destination addresses are reserved multicast
addresses will not be redirected and therefore can be sent to the CPU; DD packets are
redirected to another interface, which causes the OSPF neighbor relationship to remain in the
ExStart state.
6.11.2 Routes Are Abnormal Because the FA Fields in Type 5

LSAs Are Set Incorrectly
Fault Symptom
On the network shown in Figure 6-12, Router C is a non-Huawei device. Router A and
Router B are two routers. Router A and Router B have two upstream GE interfaces and are
configured with two static routes.
l Router A
[RouterA] ip route-static 0.0.0.0 0.0.0.0 192.168.0.69
[RouterA] ip route-static 0.0.0.0 0.0.0.0 192.168.0.65
l Router B
[RouterB] ip route-static 0.0.0.0 0.0.0.0 192.168.0.5
[RouterB] ip route-static 0.0.0.0 0.0.0.0 192.168.0.1
Router A and Router B advertise default routes to Router C in an unforced manner. Normally,
Router C has a default external route to Router A and another default external route to Router
B. Router C, however, has a route to only one of Routers A and B in the following situations:
l The static route 192.168.0.65 on Router A is deleted, and other configurations remain
unchanged. In this case, Router C has an OSPF default route to only Router B.
l The static route 192.168.0.1 on Router B is deleted, and other configurations remain
unchanged. In this case, Router C has an OSPF default route to only Router A.
Figure 6-12 Network diagram of the networking where routes on a device are abnormal
GE1/0/0 GE1/0/1 GE1/0/0 GE1/0/1
RouterA RouterB
192.168.1.253 192.168.1.254
RouterC
Fault Analysis
1. Run the undo ip route-static 0.0.0.0 0.0.0.0 192.168.0.65 command on Router A, and
then view the details about the corresponding LSA on Router C. The FA field of the LSA
is incorrectly set by Router A. In this case, Router C has an OSPF default route to only
Router B, because Router C finds that the route to address 192.168.0.69 is unreachable
when performing SPF calculation.

2. Run the undo ip route-static 0.0.0.0 0.0.0.0 192.168.0.1 command on Router B, and
then view the details about the corresponding LSA on Router C. The FA field of the LSA
is incorrectly set by Router B. In this case, Router C has an OSPF default route to only
Router A, because Router C finds that the route to address 192.168.0.5 is unreachable
when performing SPF calculation.
3. The preceding analysis shows that the root cause of the fault is that Router A and Router
B incorrectly set the FA fields in the corresponding LSAs.
The rules the router uses to fill in the FA fields of LSAs and calculate routes are as
follows:
– When the value of the FA field of a Type 5 LSA is 0.0.0.0, the router that receives
the LSA knows that the router sending the LSA is an advertising router (that is, an
ASBR), and calculates the next hop.
– When all of the following conditions are met, an ASBR fills in an address other
than 0.0.0.0 in the FA field of a Type 5 LSA, and the router that receives the LSA
calculates the next hop based on the value of the FA field:
i. The route to the interface of the ASBR's next hop is reachable.
ii. The interface connecting the ASBR to an external network is not configured as
a silent interface.
iii. The network type of the interface connecting the ASBR to an external network
is not P2P or P2MP.
iv. The address of the interface connecting the ASBR to an external network is
within the network address range advertised by OSPF.
If none of the preceding conditions are met, the FA field of an LSA is set to 0.0.0.0.
Procedure
Step 1 Do as follows to rectify the fault:
l Check the data configuration on Router A and Router B, the following information can
be found:
– The network 192.168.0.68 0.0.0.3 command rather than the network 192.168.0.64
0.0.0.3 command is run in the OSPF process on Router A.
– The network 192.168.0.4 0.0.0.3 command rather than the network 192.168.0.0
0.0.0.3 command is run in the OSPF process on Router B.
l In the OSPF process on Router A, delete the network command used to advertise the
network segment to which the next hop of the configured static route corresponds.
Perform the same operation on Router B. Then, the fault is rectified.
l Run the ospf network-type p2p command on the interface specified in the network
command run on the Router A to change the network type of the interface. Then,
perform the same operation on Router B. After that, the fault is rectified.
l Set the corresponding interface on Router A to be a silent interface, or enable the routes
from Router C to all the next hops of the static routes of Router A to be reachable.
Perform the same operation on Router B. Then, the fault is rectified.
----End

Summary
The network segment addresses and interface types of OSPF interfaces must be correctly
configured. This allows the router to correctly fill in the FA field in a Type 5 LSA and
calculate routes based on defined rules.
6.11.3 The router Receives Two LSAs with the Same LS ID but
Fails to Calculate a Route Based on One of the LSAs
Fault Symptom
On the network shown in Figure 6-13, traffic is unevenly distributed between the path from
Router A to the BAS and the path from Router B to the BAS. Load balancing between the
path Router A -> BAS -> destination and the path Router A -> RouterB -> BAS-> destination
must be configured for the traffic transmitted from Router A to the network segment to which
the BAS is connected.
Figure 6-13 Network diagram of the router receiving two LSAs with the same LS ID but fails
to calculate a route based on one of the LSAs
RouterA RouterB
10.1.2.26
Static route
destined for
BAS 10.1.1.0
10.1.3.1
10.1.1.0
The following uses traffic sent to network segment 10.1.1.0 as an example.

On Router B, a static route to 10.1.1.0 is configured and OSPF is configured to import static
routes. Router A receives an ASE LSA with the LS ID 10.1.1.0 from Router B and an ASE
LSA with the same LS ID from the BAS. Router A can calculate a route based on the LSA
received from the BAS, but fails to calculate a route based on the LSA received from Router
B.
Fault Analysis
The possible causes are as follows:
1. Device configurations are incorrect.
2. The FA field in the LSA sent by Router B is 10.1.2.26. The LSA is not calculated
because the FA field of the LSA is incorrect.
3. The conditions required to generate routes for load balancing are not met.
Based on the analysis of the preceding possible causes, it can be concluded:
1. The configurations of the devices are normal.
2. The LSA whose FA field meets the condition of route calculation.
<RouterA> ping 10.1.3.1


Reply from 10.1.3.1: bytes=56 Sequence=1 ttl=255 time=1 ms

0.00% packet loss
<RouterA> display ip routing-table 10.1.3.1
------------------------------------------------------------------------------
Summary Count : 2
10.1.3.1/32 O_ASE 150 1 D 10.1.2.45

O_ASE 150 1 D 10.1.2.49

0.00% packet loss

<RouterA> display ip routing-table 10.1.2.26
10.1.2.24/30 OSPF 10 101 D 10.1.2.45

OSPF 10 101 D 10.1.2.49
3. On this network, the costs of LSAs are 1. Compare the cost of the route to the ASBR and
the cost of the route to the FA.
For Type 2 ASE LSAs, OSPF equal-cost routes can be generated when the following
conditions are met:
a. The costs of LSAs are the same.
b. The cost of the route to the ASBR is the same as the cost of the route to the FA.
On the network, the cost of the route to the FA is 101.
– For the LSA with the FA field 0.0.0.0, the cost of the route to ASBR at 10.1.3.1 is
1.
– For the LSA with an FA field other than 0.0.0.0, the cost of the route to the FA at
10.1.2.26 is 101.
The LSA with the FA field being set is not calculated because the priority of the LSA is
lower. As a result, equal-cost routes cannot be formed.
Procedure
Step 1 To form equal-cost routes on the network, do as follows:
On the BAS, run the network command to enable OSPF on the next-hop interface of the
route to 10.1.1.0. Run the ospf cost command to set the cost of the interface to 100 so that the
interface advertises LSAs with the FA field as the address of the interface.

Then, there will be two LSAs with FA fields on Router A. The cost of the route to one FA and
the cost of the route to the other FA are both 101. Therefore, equal-cost routes can be formed.
----End
Summary
To form equal-cost routes, set the same cost on the interfaces so that the interfaces advertise
LSAs with the same FA field, the addresses of the interfaces.
6.11.4 The OSPF Neighbor Relationship Cannot Be Established

Between Two Devices Because the Link Between the Devices Is
Faulty
Fault Symptom
In the networking shown in Figure 6-14, the OSPF neighbor relationship cannot be
established between Router A and its neighbor, and the neighbor is in the Exchange state.
Figure 6-14 Network diagram of the networking where the neighbor relationship cannot be
established between two devices
10.1.1.0
RouterA RouterB
Fault Analysis
l The OSPF configurations are improper.
l Parameters of the two devices are incorrectly set.
l The OSPF packets are lost.
Check the configuration of Router A and find that Router A is correctly configured.
Check the OSPF parameters on the corresponding interfaces and find that the OSPF
parameters on the interfaces are set correctly.
Run the related debugging command on Router B and find that MTU negotiation fails.
The MTUs on the two devices are 4470. The debugging ospf packet dd command, however,
shows that the MTU contained in the packet received by Router B is 0, which indicates that
the MTU is not set on the peer device. It is concluded that the link is not working normally.
Run the following command on Router A to ping the peer device. Packet loss occurs.
Request time out

Request time out

40.00% packet loss
Ensure that the link between intermediate transmission devices is normal. Collect traffic
statistics from Router A. It is found that packet loss does not occur on Router A. Therefore,
packet loss may be occurring on the board of the peer device or on the link.
Collect traffic statistics on the peer device. It is found that packet loss occurs on the board on
Router B because the board is faulty
Procedure
Step 1 Replace the faulty board on Router B.
----End
Summary
Sometimes, OSPF packets are not received. In this case, check connectivity at the link layer
first. Enable OSPF debugging with the commands such as the debugging ospf packet and
debugging ospf event commands to locate the fault, or run the display ospf error command
to view the various OSPF error statistics. If the OSPF configuration is correct, run the
debugging ip packet command to check whether packets are successfully forwarded at the IP
layer.
6.11.5 An OSPF Routing Loop Occurs Because Router IDs of

Devices Conflict
Fault Symptom
In the networking shown in Figure 6-15, OSPF multi-instance is run between PEs and CEs.
The CEs are Layer 3 switches of other manufacturers. The PEs deliver OSPF default routes to
interwork the networks of two cities. PE1 and PE2 are connected to the same UMG. The same
IP address, 10.1.1.33, is set for the interface connecting PE1 to the UMG and the interface
connecting PE2 to the UMG, and the two interfaces are bound to the VPN instance of the
UMG. Normally, the link between the UMG and PE2 is Down. The two interfaces with the IP
address 10.1.1.33 on the two PEs cannot both be in the Up state simultaneously.
CE1 can successfully ping PE1, and CE2 can successfully ping PE2. When a CE pings a
remote peer or a device on the remote network, packet loss occasionally occurs.

Figure 6-15 Network diagram of an OSPF routing loop that occurs because router IDs of the
devices conflict
PE1 PE2
City A City B
CE1 CE2
Fault Analysis
1. 10.1.1.33 is the largest IP address in the VPN instance to which the two PEs are bound,
and the following command is run to configure OSPF multi-instance:
<PE1> ospf 4 vpn-instance www
PE1 and PE2 select 10.1.1.33 as their router ID.

2. On CE1, the router ID of PE1 is 10.1.1.33; on CE2, the router ID of PE2 is also
10.1.1.33.
3. Debugging information on the CEs shows that a device with the router ID 10.1.1.33
sends LSAs every five seconds and the sequence numbers of LSAs are incremental and
unstable.
4. The CEs receive LSAs sent by two devices with the same router ID. This causes the
OSPF default routes in the routing tables of the CEs constantly change. When the default
route of CE1 is learned by CE2 and the default route of CE2 is learned by CE1, a routing
loop occurs. As a result, routes are unreachable and packet loss occurs.
Procedure
Step 1 Run the ospf 4 router-id 10.2.2.9 vpn-instance www command on PE1 to specify the router
ID of the OSPF multi-instance as the unique address of PE1, and run the ospf 4 router-id
10.2.2.10 vpn-instance www command on PE2 to specify the router ID of the OSPF multi-
instance as the unique address of PE2.
[PE1] ospf 4 router-id 10.2.2.9 vpn-instance www
[PE2] ospf 4 router-id 10.2.2.10 vpn-instance www
Step 2 Restart the OSPF process associated with the VPN instance on PE1, and then perform the
same operation on PE2. Services are restored after both OSPF processes restart.
----End
Summary
Specify the router ID of OSPF multi-instance as the unique addresses of the PEs.

6.11.6 Services on the Master Plane Are Interrupted Because a

Device on the Slave Plane Performs Master/Slave Switchover on a
Bearer Network
Fault Symptom
On the bearer network shown in Figure 6-16, there are two planes working in master and
slave mode. The traffic model of the master plane is
UMG→CE1→AR1→BR1→AR1'→CE1', which is the same as the return path.
During the master/slave switchover of AR2 on the slave plane, packet loss (which lasts 1
second) occurs on the master plane. Similarly, during the master/slave switchover of AR1 on
the master plane, packet loss also occurs on the slave plane.
Figure 6-16 Diagram of that the services on the master plane are interrupted because a device
on the slave plane performs master/slave switchover on a bearer network
CE1 AR1 BR1 AR1' CE1'
UMG UMG'
CE2 AR2 BR2 AR2' CE2'
Fault Analysis
The analysis about the topology and routes of the current network shows that the master and
slave planes are independent of each other. Therefore, it is impossible that the master/slave
switchover of a device on one plane affects the services on the other plane. By viewing the
configurations of the devices on the current network, you can find that the route aggregation
command is run in the OSPF multi-instance on all ARs.
ospf 1 vpn-instance 123
asbr-summary 10.0.0.0 255.0.0.0
The network command is run to configure BGP to advertise routes. The routes to the remote
end are therefore aggregated into a route 10.0.0.0/8. Based on the route aggregation rules on
the ABR, the cost of the aggregated route is the largest among the costs of the routes that are
aggregated (after route aggregation, the ASBR and the ABR send the aggregated route with
the largest cost). For example, there are the following routes to be aggregated:
l 10.1.1.1/24 cost 10
l 10.2.1.1/24 cost 100
l 10.3.1.1/24 cost 1000
The aggregated route is 10.0.0.0/8 with the cost being 1000.
After AR1 on the master plane performs the master/slave switchover, AR2 needs to
reconverge private network routes. If AR2 receives a route 10.x.x.x with the cost smaller than

200, the cost of the aggregated route 10.0.0.0/8 advertised by AR2 to CE2 become smaller,
and the aggregated route is advertised to CE1 by OSPF. The traffic model on the master plane
becomes UMG→CE1→CE2→AR2→BR2→AR2'→CE2'.
Because the network scale is large, AR2 has not completed route convergence yet, that is,
AR2 has no specific route to the destination. As a result, the fault occurs.
Procedure
Step 1 When using the asbr-summary command in OSPF view to configure route aggregation,
specify the cost of the aggregated route to prevent route re-selection when a route with a
smaller cost is received.
ospf 1 vpn-instance 123
asbr-summary 10.0.0.0 255.0.0.0 cost 300
After the preceding operations, no traffic passes through the link between CE1 and CE2, and
traffic on the master plane is always forwarded on the master plane.
----End
Summary
During the planning of a network with dual planes, prevent the two planes from affecting each
other due to the factors such as IS-IS checksum errors, incorrect costs of OSPF routes, and
incorrect costs of IS-IS routes.
6.11.7 User with the Correct User Name and Password Fails to
Pass HWTACACS Authentication
During network configuration adjustment, the new routing protocol does not advertise
loopback addresses. As a result, a user who uses a loopback address as the source IP address
cannot communicate with the TACACS server.
Fault Symptom
On the core network shown in Figure 6-17, Routing protocol, AAA, QoS, and SNMP are
configured on Router A, Router B, Router C, and Router D. The four devices belong to the
same AS and are configured with IBGP and IS-IS. IS-IS advertises the IP addresses of
loopback interfaces and interconnected interfaces. The devices are re-configured based on a
new private AS number, IBGP is replaced by EBGP and IS-IS is replaced by OSPF.

Figure 6-17 Networking diagram of HWTACACS authentication on a core network
Loopback0 Loopback0
RouterA
RouterB
TACACS
server
RouterD
RouterC
Loopback0 Loopback0
After the configurations, an HWTACACS user with the correct user name and password can
no longer pass the HWTACACS authentication.
Fault Analysis
1. Check whether the user name and password of the user are the same as those recorded on
the TACACS server. The user name and password are correct.
2. Run the ping command on Router A to check whether Router A can ping the TACACS
server. The ping succeeds.
3. Run the display current-configuration command on Router A to check whether the
HWTACACS configuration is correct. The following command is found in the
HWTACACS server template:
hwtacacs-server source-ip 192.168.1.227
In this command, 192.168.1.227 is the loopback address of Router A.

As the deleted IS-IS configuration includes loopback addresses and HWTACACS uses
the loopback address of Router A as the source IP address, it is possible that
HWTACACS authentication fails because Router A cannot receive authentication
response packets with the destination address being 192.168.1.227 from the TACACS
server.
4. Run the ping -a 192.168.1.227 10.1.1.245 command on Router A (10.1.1.245 is the IP
address of the TACACS server) to check whether the loopback address can ping the
TACACS server address. The ping fails.
5. Run the display ip routing-table command on Router A to check whether routing
protocols have advertised this loopback address. The command output shows that the IP
address of Loopback0 is not advertised.
Therefore, it can be concluded that the loopback address is deleted when the IS-IS
configuration is deleted during network configuration adjustment. Because OSPF does
not advertise this loopback address, Router A cannot receive authentication response
packets from the TACACS server, and as a result, HWTACACS authentication fails.

Procedure
Step 2 Run the ospf process-id command to enter the OSPF view.
Step 3 Run the area area-id command to enter the OSPF area view.
Step 4 Run the network address wildcard-mask command to advertise the loopback address.
After the preceding configurations, the user can successfully log in. The fault is cleared.
----End
Summary
Before changing protocols on network devices, you need to record the original configurations.
After the configuration of new protocols , ensure that the new configurations meet all the
service requirements before the change and whether the new configurations affect other
configurations.
6.11.8 Why Cannot the OSPF Neighbor Relationship Be

Established Between Two Devices Enabled with the Opaque-LSA
Capability?
Fault Symptom
As shown in Figure 6-18, Router A and Router B attempt to set up an OSPF neighbor
relationship and run MPLS TE services. Router A is a non-Huawei device, and is enabled
with the Opaque-LSA capability by default. Router B is a Huawei device. The opaque-
capability enable command is run in the OSPF process of Router B. Router A and Router B
fail to set up an OSPF neighbor relationship. The OSPF neighbor relationship on Router A
reaches the Full state, whereas the neighbor relationship on Router B is always in the Loading
state.
Figure 6-18 Diagram of the networking where the OSPF neighbor relationship cannot be set
up between devices enabled with the Opaque-LSA capability
RouterA RouterB

Fault Analysis
1. Run the display ospf peer command on Router B to check the status of the neighbor
relationship. The command output shows that the OSPF neighbor relationship is in the
Loading state (the State field is displayed as Loading), indicating that the LSA
requested from the neighbor exists in the request list.
2. Run the display ospf request-queue command to check whether Router B is always
requesting an Opaque LSA. The command output shows that Router B is always
requesting an Opaque-Area LSA.
3. Run the debugging ospf packet update filter src acl-number command on Router B.
The command output shows that Router A is always sending LSAs carrying only header
information.
Router B is a Huawei device, and cannot process any LSA carrying only header information.
During the establishment of an OSPF neighbor relationship between a Huawei device and a
non-Huawei device, if the DD packets sent by the non-Huawei device carry Opaque LSAs
that have only header information, the Huawei device will request the Opaque LSAs from the
non-Huawei device. Then, the non-Huawei device sends the requested LSAs by using LSUs.
The Huawei device, however, discards the requested LSAs because it cannot process these
LSAs, and continues to request LSAs from the non-Huawei device. As a result, the neighbor
relationship on the Huawei device is always in the Loading state.
Procedure
Step 2 Run the ospf process-id command to enter the view of a specified OSPF process.
Step 3 Run the undo opaque-capability enable command to disable the Opaque-LSA capability.
The fault is then rectified.
----End
Summary
When a Huawei device enabled with the Opaque-LSA capability is connected to a non-
Huawei device, check whether the non-Huawei device is enabled with the Opaque-LSA
capability by default.
6.11.8.1 Inappropriate OSPF Costs Cause Traffic Interruption During a Link

Switchover
Fault Symptom
Figure 6-19 shows the cost of each link. On the network shown in Figure 6-19, OSPF is
running on each device. The primary link is Router M -> Router A -> Router B -> Router C -
> Router D -> Router E -> Router N. The secondary link is Router M -> Router A -> Router F
-> Router G -> Router H -> Router I -> Router J -> Router E -> Router N. If a fault occurs on
the primary link or a master device, traffic on Router A is immediately switched to the
secondary link. If a fault occurs on the link between Router B and Router A (for example, the
shutdown command is run on Router B), traffic from Router M to Router N is interrupted for
5 seconds.

Figure 6-19 Networking of traffic interruption caused by inappropriate OSPF costs during a
link switchover
RouterA RouterB RouterC RouterD RouterE
1 1 1 1
RouterM RouterN
10 20 30 21 11
1 1 1 1
RouterF RouterG RouterH RouterI RouterJ
Fault Analysis
1. Run the display ip routing-table ip-address command on Router A to check its IP
routing table. In this example, the next hop of the route to Router N is Router F. This
indicates that traffic is switched to Router F after a fault occurs on the link between
Router B and Router A.
2. Run the tracert host command on Router A. In this example, Router A and Router N are
reachable. Traffic is switched to the secondary link Router A -> Router F -> Router G ->
Router H -> Router I -> Router J -> Router E -> Router N. This indicates that the fault is
temporary rather than a continuous packet loss.
3. Run the undo shutdown command and the shutdown command on Router B so that a
fault occurs on the link between Router B and Router A. Then, run the tracert host
command on Router A immediately. In this example, Router A and Router N are not
reachable. A loop has occurred between Router A and Router F. The further analysis
shows that the link Router A -> Router B -> Router C -> Router D -> Router E has the
lowest cost before the fault occurs. Traffic between Router M and Router N is forwarded
through the primary link. The link Router F -> Router A -> Router B -> Router C ->
Router D -> Router E has the lowest cost between Router F and Router E. The next hop
of the route from Router F to Router E is Router A. Therefore, if a fault occurs on the
link between Router B and Router A, Router A switches traffic to its outbound interface
connected to Router F. Router F is a device that has low performance. Before Router F
completes route convergence, it forwards the traffic received from Router A back to
Router A. As a result, a loop occurs between them. After Router F completes route
convergence, traffic between Router M and Router N is forwarded through the secondary
link. Therefore, this fault is caused by inappropriate OSPF costs.
Procedure
Step 1 Run the system-view command on Router A, Router B, Router C, Router D, and Router E to
enter the system view.
Step 3 Run the ospf cost cost command for multiple times to configure the costs of Router A ->
Router B -> Router C -> Router D -> Router E to be 2, 2, 2, and 2 respectively. This ensures

that traffic between Router M and Router N is forwarded through the primary link if no fault
occurs and is forwarded through the secondary link if a fault occurs.
----End
Summary
If users want to determine the primary and secondary links by configuring the costs of these
links, note to consider the route next hops during and after the route convergence.
6.11.8.2 Downstream Traffic Cannot be Load Balanced Due to the Inappropriate

Routing Protocol Route Preference
Fault Symptom
On the network shown in Figure 6-20, IS-IS is running on Router A, Router B, and Router C.
These devices belong to Area 1. The configuration is as follows:
l Two default static routes are configured on Router D with next hops Router A and
Router B respectively. Upstream traffic is forwarded through and load balanced along the
link Router D -> Router A -> Router C and the link Router D -> Router B -> Router C.
l Configure two static routes with next hops being Router D on Router A and RouterB
respectively. Downstream traffic is forwarded through and load balanced between the
link Router C -> Router A -> Router D and the link Router C -> Router B -> Router D.
l Import the static routes configured on Router A and Router B to IS-IS.
After the configuration is complete, upstream traffic is load balanced, but downstream traffic
is forwarded only through the link Router C -> Router B -> Router D.
Figure 6-20 IS-IS networking on which downstream traffic cannot be load balanced
RouterC
Area1
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24
RouterA RouterB
GE2/0/0
GE2/0/0
10.2.1.1/24
10.3.1.1/24/30
RouterD
Segment: 10.4.1.0/24

Fault Analysis
1. Upstream traffic is load balanced and downstream traffic is forwarded through one link,
so the problem is not caused by a link failure.
2. Run the display ip routing-table command on Router A to check its IP routing table.
The command output shows that the route destined for 10.4.1.0/24 is a static route. Run
the display ip routing-table command on Router B to check its IP routing table. The
command output shows that the route destined for 10.4.1.0/24 is an imported IS-IS route.
The static route has a lower preference than the IS-IS route, so this problem is caused by
the inappropriate IS-IS route preference.
<RouterA> display ip routing-table
------------------------------------------------------------------------------
1.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0

2.2.2.2/32 ISIS 15 10 D 10.1.1.2 GigabitEthernet1/0/0
10.4.1.0/24 Static 60 0 RD 10.2.1.2 GigabitEthernet2/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1 GigabitEthernet1/0/0
<RouterB> display ip routing-table
------------------------------------------------------------------------------

Procedure
Step 1 Run the system-view command on Router A and Router B to enter the system view.
Step 2 Run the ip route-static default-preference preference command to configure the default
preference of static routes.
NOTE
The default preference value of static routes must be lower than the IS-IS preference value.
----End
Summary
l Static routes are configured on both devices. After these routes are imported to IS-IS,
they are sent to the neighbors. Because static routes have a lower preference than the IS-

IS routes, the static routes configured on both devices do not take effect and are both
withdrawn. After that, the imported IS-IS routes are automatically removed. Then, the
static routes take effect again. This process is repeated and therefore route flapping
occurs. In the end, one static route takes effect on one device and one IS-IS route takes
effect on the other device due to the intervals when Update and Withdraw messages are
sent.
l The default preference of static routes is 60 and that of IS-IS routes is 15 on Huawei
devices. The configurations on non-Huawei devices are different than Huawei devices.
Therefore, if you use Huawei devices to communicate with non-Huawei devices, pay
attention to preference differences when you run a routing protocol on these devices.
6.12 IS-IS Troubleshooting

6.12.1 An Upper-layer Device Cannot Learn IS-IS Routes Due to
Differences in the Types of Routes Imported by IS-IS on a
Huawei Device and a Non-Huawei Device
Fault Symptom
On the network shown in Figure 6-21, Router B and Router C are located at the core layer
and are connected to two SR devices, that is, Router A, and Router D. Router D is a non-
Huawei device. To implement load balancing, Router A and Router D are configured to the
same network, and direct routes and static routes are imported to IS-IS in related IS-IS
processes. After the configuration, you can find that Router B and Router C can learn routes
from only Router D.
Figure 6-21 Diagram of the network where devices cannot learn IS-IS routes
RouterA
Router B Route rC
Route rD
Fault Analysis
By default, the type of static routes imported by IS-IS on Router D is internal and the cost of
the routes equals to the original cost of the imported route, whereas the type of static routes

imported by IS-IS on Router A is external and the cost of the routes equals to the sum of
original cost of the imported route and 64. Router B, and Router C selects routes only from
Router D rather than Router A because the costs are different.
NOTE
The trouble occurs only when the cost-style is narrow.
Procedure
Step 2 Run the isis process-id command to enter the IS-IS view.
Step 3 Run the import-route direct cost-type internal command to configure IS-IS to import direct
routes and set cost-type to internal.
Step 4 Run the import-route static cost-type internal command to configure IS-IS to import static
routes and set cost-type to internal.
NOTE
Modify the cost-type from external to internal, the cost of the imported routes equals to the original
cost of the imported route, rather than the sum of original cost of the imported route and 64.
After the preceding operations, run the display isis route command on Router B and Router
C to view routing information. You can find that there are two IS-IS routes to the same
network segment and that load balancing is performed by Router A and Router D.
----End
Summary
In the networking with devices of different manufacturers, note the implementation
differences between the devices.
6.12.2 A device Fails to Establish IS-IS Peer Relationships with an

MA5200 Because an Intermediate Transmission Device Goes
Down
NOTE
Fault Symptom
On the Figure 6-22 network, the device and MA5200 run IS-IS to connect to each other.
After the configurations are complete, the IS-IS peer relationships fail to establish between
the device and MA5200. However, the IS-IS status on GE 1/0/0 of the device is normal and
GE 1/0/0 can receive LSPs sent from the MA5200.

Figure 6-22 Networking diagram of the device failing to establish IS-IS peer relationships
with the MA5200 because the transmission device is faulty
GE1/0/0 GE1/0/0
MA5200 Intermediate transmission NE80E

device
Fault Analysis
1. Run the display current-configuration command on the device to check the device
configurations. The configurations are normal.
2. The optical power received on GE 1/0/0 of the device is close to the critical value, and
CRC error packets occur on GE 1/0/0 of the MA5200 and the number of CRC error
packets keeps increasing rapidly. After the optical connectors on both ends of the link are
cleaned, the device receives the optical power at a normal speed, and no CRC error
packets occur on GE 1/0/0 of the MA5200. However, the IS-IS peer relationships still
cannot be established.
3. Run the display traffic policy statistics interface gigabitethernet 1/0/0 inbound
command on the device. The command output shows that GE 1/0/0 of the device
receives no IS-IS multicast packets from the peer, possibly caused by a faulty link on the
switch or the faulty transmission device.
Procedure
Step 1 Replace the transmission device. The IS-IS peer relationships can be established and the fault
is rectified.
----End
Summary
None
6.13 BGP Troubleshooting
6.13.1 Traffic Traverses the Egress Device of an AS Because BGP

Delivers Default Routes with Different MEDs
Fault Symptom
In Figure 6-23, Router A and Router B reside on the backbone network. EBGP peer
relationships are established between devices in AS 100 and AS 200. IBGP peer relationships
are established between devices inside each AS. After Router A and Router B advertise BGP
default routes, detailed information about BGP default routes on Router C shows that
outgoing traffic from AS 200 is directed to Router D. That is, the next hop of BGP default
routes is Router D. Consequently, outgoing traffic from AS 200 traverses Router C.

Figure 6-23 Outgoing traffic traversing the egress device of an AS
AS100
RouterA RouterB
0.0.0.0 is delivered 0.0.0.0 is delivered

(MED 88) (MED 80)
RouterC RouterD
AS200
Default route
Outgoing traffic
Fault Analysis
Run the display bgp routing-table 0.0.0.0 command on Router C to view detailed
information about BGP default routes. The command output will show that different MEDs
are set for Router A and Router B. As a result, outgoing traffic from AS 200 traverses Router
C.
Procedure
Step 1 Run the system-view command on Router B or Router A to enter the system view.
Step 2 Run the bgp { as-number-plain | as-number-dot } command to enter the BGP view.
Step 3 Run the ipv4-family unicast command to enter the BGP-IPv4 unicast address family view.
Step 4 Run the default med med command to modify the default MED of the BGP routes, and make
sure the MED of BGP routes on Router A matches the MED of BGP routes on Router B.
After performing the preceding operations, run the display bgp routing-table 0.0.0.0
command on Router C to view detailed information about BGP default routes. The command
output will show that outgoing traffic from AS 200 is transmitted through Router C. This
indicates that the fault has been cleared.
----End

Summary
When there are multiple egress devices between two ASs, set the same MED for the
advertised default routes. BGP prefers routes learned from EBGP peers because the delivered
default routes have the same route attributes, such as the local-preference and MED.
6.13.2 MAN Users Fail to Access the Internet Because of BGP

Route Flapping
Fault Symptom
Figure 6-24 shows how a specific carrier's MAN is connected to its backbone network.
Figure 6-24 Networking of the MAN before service cutover
RouterE RouterF
RouterA RouterD
Backbone
network
MAN
RouterC RouterB
A Site B Site
The carrier optimizes the MAN and the backbone network to better facilitate the growing
service requirements. Networking of the MAN after service cutover is shown in Figure 6-25.
l Router A in Site A changes from the backbone network's egress router to the MAN's
egress router, connects to Router E, and establishes the EBGP peer relationship with
Router E.
l Router D in Site B is directly connected to Router F and establishes the EBGP peer
relationship with Router G.
l The IBGP peer relationship is established between Router A and Router D.
l Router C and Router B are removed from the networking.

Figure 6-25 Networking of the MAN after service cutover
RouterE RouterF
Backbone
network
EBGP EBGP
MAN
IBGP
RouterA RouterD
A Site B Site
Service cutover is successfully performed in Site A, and then service cutover begins to be
performed in Site B. During service cutover in Site B, the version of Router D needs to be
upgraded first. After Router D is restarted during version upgrade, a large number of users in
internet café and PPPoE users fail to access the Internet.
Fault Analysis
1. Users in the MAN cannot ping the carrier's DNS and then run the tracert command to
tracert the carrier's DNS. The result shows that traffic is interrupted after reaching Router
A.
2. Run the display bgp peer on Router A to check the BGP peer relationship. The
command output shows that the BGP peer relationship is normal. Then, ping the carrier's
DNS from Router A. The result shows that the ping succeeds.
3. Run the display ip routing-table statistics command on Router A repeatedly to check
the number of updated BGP routes and then check whether routing loops exist. The
command output shows that no routing loops exist.
4. Run the display ip routing-table command on Router E of the backbone network to
check routes. The command output shows that there are no BGP routes to the MAN.
5. Run the display bgp peer command on Router E to check the BGP peer relationship.
The command output shows that the EBGP peer relationship between Router E and
Router A is not in the Established state.
6. Check logs on Router E. The log information shows that EBGP routes to Router A are
suppressed because BGP routes are updated frequently, which causes MAN traffic
unable to be sent outside the MAN.
BGP routes are suppressed because the BGP routes are updated frequently. Possible
causes of frequent route updates are as follows:
a. Router A advertises BGP routes to Router E by using the network command. Then,
these routes are updated one by one and this update process is recorded.
b. Router D is restarted during version upgrade, causing the BGP routes to be updated
again. Consequently, the number of BGP route updates reaches the route
suppression threshold set on Router E.

Procedure
Step 1 Run the system-view command on Router E to enter the system view.
Step 2 Run the bgp as-number command on Router E to enter the BGP view.
Step 3 Run the undo dampening command on Router E to cancel BGP route suppression.
Step 4 Run the display bgp peer command on Router E. The command output shows that the EBGP
peer relationship between Router E and Router A is in the Established state. Then, the BGP
routes are reconverged, indicating that the fault is cleared.
Step 5 Run the dampening [ half-life-reach reuse suppress ceiling | route-policy route-policy-
name ] * command on Router E to restore the configuration of BGP route suppression.
----End
Summary
Route instability is reflected by route flapping. That is, a route in a routing table disappears
and reappears frequently. Generally, BGP is applicable to complex networks where routes
change frequently. Frequent route flapping, however, consumes lots of bandwidths and CPU
resources and even seriously affects the normal operation of networks. BGP route suppression
helps to avoid the impact of frequent route flapping.
During network adjustment, if there are a large number of updated BGP routes, canceling
BGP route suppression is recommended. This operation helps to prevent services from being
affected by route suppression that is caused by frequent route flapping. After network
adjustment, BGP route suppression needs to be restored.
There are three methods of implementing BGP route suppression: route summarization, route
dampening, and setting the minimum interval for updating routes.
6.13.3 Routing Policies Delivered by a PE Do Not Take Effect

Because There Are Multiple Routing Policies with the Same
Name
Fault Symptom
As shown in Figure 6-26, a PE is connected to VPN 1 and is connected to GSR1 in the
upstream direction. VPN 1 routes of the PE need to be advertised to the backbone network.
The PE controls which routes to be advertised to GSR1 using routing policies. According to
the configured routing policies, GSR1 needs to learn only the VPN 1 summary route
advertised by the PE instead of specific routes. After the routing policies are configured,
GSR1 learns both the VPN 1 summary route and specific routes.

Figure 6-26 Routing policies delivered by a PE failing to take effect
PE GSR1
VPN1
Backbone
VPN
RouterA GSR2
Fault Analysis
1. Run the display current-configuration command on the PE to view the routing policy
configuration. The command output shows that no fault occurs.
2. According to the fault symptom, it is possible that GSR1 learns the specific VPN 1
routes advertised by the PE because the delivered routing policies do not take effect.
3. Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer peer-
address { advertised-routes | received-routes [ active ] } command on the PE to view
the routes of other VPNs to which the PE is connected. Routes learned on GSR1 are
summary routes of these VPNs. Therefore, it can be concluded that the routing policies
for VPN 1 are incorrect.
4. Check the configuration file of the PE. The result shows that there are three routing
policies with the same name for the PE to advertise the routes of VPN 1. The ip-prefix
NGN-A referenced by the first routing policy is defined, and this routing policy is valid.
The ip-prefix NGN-A1 and ip-prefix NGN-A2 referenced by the other two routing
policies are not defined, and therefore the two routing policies are invalid. The following
is the detailed configuration:
ipv4-family vpn-instance CDMA-NGN
peer 10.247.0.1 route-policy PE_NGN_OUT_MASTER export
route-policy PE_NGN_OUT_MASTER permit node 10
if-match ip-prefix NGN-A
if-match ip-prefix NGN-A1
if-match ip-prefix NGN-A2
ip ip-prefix NGN-A index 10 permit 10.247.0.0 21
The rules for referencing routing policies dictate that the relationship between the three
routing policies with the same name must be OR. That is, VPN 1 routes can be correctly
advertised as long as one of the routing policies with the same name is valid. However,
the redundant invalid routing policies with the same name can still cause VPN 1 routes
to be incorrectly advertised.
5. After deleting the other two invalid routing policies, GSR1 learns only one summary
route, namely, the route with a prefix that is in the IP prefix list NGN-A. The fault is
cleared.

Procedure
Step 1 Run the system-view command on the PE to enter the system view.
Step 2 Run the undo route-policy route-policy-name [ node node ] command to delete the two
redundant routing policies.
Step 3 Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer peer-
address advertised-routes command to view the routes of VPN 1 to which the PE is
connected. Only one summary route is found. The fault is cleared.
----End
Summary
According to the rules for referencing routing policies, the relationship between routing
policies with the same name must be OR. However, redundant routing policies still need to be
deleted to prevent routes from being incorrectly advertised.
6.13.4 A PE Fails to Establish the Public Network LSP Because the

Path of IGP Routes Is Incorrect
Fault Symptom
As shown in Figure 6-27, PE1 can receive VPNv4 routes reflected from RR1, but these
routes cannot be installed in the routing table of the VPN instance. That is, there is associated
routing information in the BGP VPNv4 routing table but not in the routing table of the IPv4
VPN instance on PE1.
Figure 6-27 Failure to establish a public network LSP on a PE
OSPF Area
P P
(RR1) (RR2)
PE1 PE2
Fault Analysis
1. Run the display bgp vpnv4 all routing-table command on PE1 to view the BGP routing
table. The routing table contains the routes learned from the peer PE. This indicates that
the BGP neighbor relationship is normal and that VPN labels are assigned properly.
2. Run the display ip routing-table vpn-instance vpn-instance-name ip-address verbose
command on PE1 to view detailed information about VPN routes. The Interface field is

displayed as NULL0. This indicates that VPN routes do not have a correct iterated
outbound interface on the public network. That is, these VPN routes are invalid and
therefore are not included in the routing table of the VPN instance.
3. Run the display mpls ldp session command on PE1 to view the LDP session on the
public network. The LDP session works normally. This indicates that an LDP session
can be established between the Ps.
4. Run the display mpls ldp lsp destination-address mask-length command on PE1 to view
the assignment of public network labels. The In/OutLabel field is displayed as Null and
the Next-Hop field is empty. This indicates that LDP sessions can be established between
the PEs and the Ps, but labels cannot be assigned.
5. Run the display ip routing-table ip-address command on PE1 to view IGP routes to the
loopback interface address of the P. The 32-bit loopback interface address is learned
from PE2 instead of the P. Therefore, the assignment of public network labels cannot be
triggered although the LDP LSP can be established. In addition, no LDP is configured
between the two PEs. (If LDP is configured between the two PEs, public network labels
can be assigned and routes of the VPN instance can be generated.)
6. Run the display current configuration and display ip routing-table ip-address
commands to view IGP configurations and IGP routes of devices. OSPF is not correctly
configured on the interface that connects RR1 to PE1.
Procedure
Step 1 Re-configure OSPF on the interface that connects RR1 to PE1 to ensure that the path of IGP
routes is correct. Then, routing information can be learned from the interfaces that connect the
PEs to the Ps.
Step 2 Run the display ip routing-table vpn-instance vpn-instance-name ip-address verbose
command on PE1 to view the assignment of MPLS labels and the iteration of the outbound
interface of VPN routes. MPLS labels are assigned properly and the outbound interface of
VPN routes is iterated properly. The Interface field shows a correct iterated outbound
interface on the public network.
Step 3 Run the display mpls ldp lsp destination-address mask-length command on PE1 to check the
assignment of public network labels. Public network labels are assigned properly.
Step 4 Run the display ip routing-table vpn-instance vpn-instance-name command on PE1 to
check the routing table of the VPN instance. The routing table of the VPN instance contains
the associated VPN routes. This indicates that the fault is cleared.
----End
Summary
A public network LSP must be established to install VPN routes in the routing table of a VPN
instance. If public network labels fail to be assigned and LSPs cannot be established, check
whether the path of IGP routes can trigger label assignment and whether IGP routes are
correct.

6.13.5 Next Hop of the Incoming Traffic Changes After a Master/

Slave Switchover of the Attached Non-Huawei Devices
Fault Symptom
As shown in Figure 6-28, VRRP is configured on Router A and Router B. Router A and
Router B are connected through a heartbeat link. The other devices are all non-Huawei
devices. Router C and Router D, which are attached to Router A and Router B, respectively,
are load-balancing devices and provide redundancy for each other. A routing policy is
configured on the interface that connects Router A to Router C to enable incoming traffic to
be forwarded by the specified interface and specifies Router G as the next hop.
After the master device Router C becomes faulty, CPU usage on Router C reaches 100%.
Because redundancy backup and automatic master/slave switchover are configured, incoming
traffic is switched to Router D. However, the next hop of the incoming traffic on Router A is
Router E. Therefore, the incoming traffic is not forwarded to the next hop specified by the
configured routing policy.
Figure 6-28 Change in the next hop of incoming traffic
RouterE RouterF RouterG RouterH
RouterA RouterB
RouterC RouterD
Data path before master/slave

switchover of attached devices
Data path after master/slave
switchover of attached devices
Fault Analysis
After a master/slave switchover of the non-Huawei devices, the path of incoming traffic is
Router D->Router B->heartbeat link->Router A. Because route redirection is not configured
on the interface of the heartbeat link, the next hop of the incoming traffic is not Router G as
specified but Router E. This indicates that the configured routing policy becomes invalid.
To clear the fault, configure a routing policy on the interface of the heartbeat link between
Router A and Router B to enable incoming traffic to be forwarded along the specified path,
which is the same as the path before the master/slave switchover. That is, configure route

redirection on the interface of the heartbeat link to forcibly change the next hop of the
incoming traffic to Router G.
Procedure
Step 2 Configure an ACL rule.

1. Run the acl number acl-number command to create an ACL and enter the ACL view.
2. Run the rule command to configure an ACL rule.
3. Run the quit command to quit the ACL view.
Step 3 Match the ACL rule for route redirection.

1. Run the traffic classifier classifier-name operator or command to define a traffic
classifier and enter the traffic classifier view.
2. Run the if-match acl acl-number command to match the ACL.
3. Run the quit command to quit the traffic classifier view.
4. Run the traffic behavior behavior-name command to define a traffic behavior and enter
the traffic behavior view.
5. Run the redirect ip-nexthop ip-address command to perform route redirection,
specifying the next-hop address as the address of the interface that connects Router G to
Router A.
6. Run the quit command to quit the traffic behavior view.
7. Run the traffic policy policy-name command to define a traffic policy and enter the
traffic policy view.
8. Run the classifier classifier-name behavior behavior-name command to specify a traffic
behavior for the traffic classifier in the traffic policy.
Step 4 Apply the traffic policy to the interface of the heartbeat link on Router A.
1. Run the interface eth-trunk trunk-id command to enter the view of the interface of the
heartbeat link.
2. Run the traffic-policy policy-name inbound command to apply the traffic policy.
Step 5 Run the display ip routing-table command to check incoming traffic of Router A. The next
hop of the incoming traffic is Router G. This indicates that the fault is cleared.
----End
Summary
After a master/slave switchover is performed on network devices, pay attention to the impact
of the switchover on network traffic.
If incoming traffic fails to be forwarded along the path specified by the configured routing
policy, configure route redirection to specify the next hop of a link to solve the problem.
6.13.6 The Outgoing Traffic Is Not Balanced Because BGP Load

Balancing Is Not Enabled

Fault Symptom
As shown in Figure 6-29, Router A, Router B, Router C, and Router D are four egress
devices on the MAN; Router E, Router F, Router G, and Router H are four devices on the
provincial backbone network. Before service cutover, the four egress devices on the MAN are
connected to the four devices on the provincial backbone network by using EBGP as shown
in Figure 6-29.
The networking is adjusted to meet service requirements. After service cutover, the four
egress devices on the MAN are connected to the four devices on the provincial backbone
network through EBGP as shown in Figure 6-30. Traffic fails to be balanced between the two
outbound interfaces of each egress device on the MAN, and most traffic is transmitted over
one link.
Figure 6-29 Networking before service cutover
RouterG RouterH
RouterF
RouterE
RouterC RouterD
RouterA RouterB
MAN A MAN B

Figure 6-30 Networking after service cutover
RouterG RouterH
RouterF
RouterE
RouterC RouterD
RouterA RouterB
MAN A MAN B
Fault Analysis
Two equal-cost routes are generated on each egress device on the MAN. Because BGP load
balancing is not enabled, most traffic is transmitted over one link. To solve this problem, you
need to enable BGP load balancing on the four egress devices on the MAN.
Procedure
Step 2 Run the bgp { as-number-plain | as-number-dot } command to enter the BGP view.
Step 3 Run the maximum load-balancing number command to set the maximum number of equal-
cost routes to 2 or a larger value.
After the preceding operations, perform the same operations on Router B, Router C, and
Router D.
----End
Summary
With the rapid development of networks, MANs and backbone networks as shown in Figure
6-29 are widely deployed. When devices on two MANs access each other, equal-cost routes
are generated. If BGP load balancing is not enabled on egress devices on the MAN, the route
advertised by the device with the smallest router ID is preferred according to BGP route
selection rules. Consequently, the fault described in this case occurs.
It is recommended to enable load balancing on egress devices on the MAN and set the
maximum number of equal-cost routes to the maximum value to facilitate capacity expansion.
If there are both Huawei devices and non-Huawei devices on a network, take the maximum
number of equal-cost routes supported on non-Huawei devices into consideration.

6.13.7 Summary Routes Advertised by EBGP Flap Frequently

Because Routing Protocols Are Configured with Improper
Preferences
Fault Symptom
As shown in Figure 6-31, Router C and Router D are two egress devices on a MAN and are
connected to Router A and Router B on the backbone network through EBGP. Route
suppression is configured on devices on the backbone network to suppress EBGP routes from
egress devices on the MAN. On the MAN, Router C and Router D are connected to their
attached devices through IS-IS and IBGP peer relationships are established between them.
Some traffic traverses egress devices on the MAN. Therefore, to prevent link faults from
causing routing loops, Router C and Router D establish the IBGP peer relationship by using
interface addresses and advertise MAN routes to devices on the backbone network through
static blackhole routes imported by the network command.
After a fault occurs on a board or a link, the IBGP peer relationship between Router C and
Router D alternates between Up and Down states frequently and therefore all MAN services
are interrupted.
Figure 6-31 Summary routes advertised by EBGP peer flapping frequently
Backbone
network
RouterA RouterB
RouterC RouterD
MAN

Fault Analysis
Possible causes of route flapping are as follows:
l Associated routing policies, including local and remote routing policies, are changed
manually.
l Routes (mainly refer to the advertised summary routes) are added and then deleted for
two consecutive times.
l Static and dynamic routing protocols are configured with improper preferences. As a
result, some BGP summary routes cannot be advertised through the blackhole route
imported by the network command.
By checking logs on devices, you can find that no associated routing policies are changed
manually and no routes are added and then deleted.
Egress devices on the MAN advertise routes through blackhole routes imported by the
network command. Therefore, route addition or deletion is not involved. By checking
summary routes, you can find that the lifetime of these routes is very long. This indicates that
service interruption is unlikely to occur.
On Router C and Router D, the preference of the BGP protocol is set to 20, and the preference
of static blackhole routes defaults to 60. Therefore, if both IBGP routes and static routes exist,
IBGP routes are advertised as summary routes first. As a result, when the IBGP peer
relationship between Router C and Router D alternates between Up and Down states, the
advertised summary routes flap, therefore causing MAN services to be interrupted.
To solve this problem, you need to change the preferences of BGP routes and static routes so
that IBGP routes have a lower preference than static routes.
Procedure
Step 1 Run the system-view command on Router C to enter the system view.
Step 2 Run the bgp { as-number-plain | as-number-dot } to enter the BGP view.
Step 3 Run the preference preference command to set the preference for the BGP protocol to a value
greater than 60.
After the preceding operations, perform the same operations on Router D to change the
preference of the BGP protocol. In this manner, MAN service transmission recovers.
----End
Summary
Theoretically, MAN routes, which are advertised through blackhole routes imported by the
network command, do not flap. In this case, however, devices on the MAN do not advertise
routes as required because routing protocols are configured with improper preferences.

6.13.8 A Router Does Not Receive the Route Advertised by Its

IBGP Peer Because the AS_PATH Attribute of the Route Carries
the AS Number of the Peer
Fault Symptom
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 6-32, Router A is in AS 65008, and
Router B and Router C are in AS 65009. The routing tables of these routers have many routes,
and the routes change frequently. After BGP is enabled on these routers, the routers can
exchange routing information. When routes of one router change, this router will send Update
messages to its peers carrying only changed routing information. This greatly reduces
bandwidth consumption.
After the configuration is complete, Router A cannot ping Router C.
Figure 6-32 Networking on which a router does not receive routes advertised by its IBGP
peer
AS 65009
10.2.1.1/24 10.1.1.1/24
10.1.1.2/24
RouterB RouterC
RouterA
AS 65008
Fault Analysis
1. Run the ping host command on Router A. In this example, Router A can ping Router B,
which indicates that the link between Router A and Router B functions properly.
2. Run the ping host command on Router B. In this example, Router B can ping Router C,
which indicates that the link between Router B and Router C functions properly.
3. Run the display bgp routing-table command on Router B to check its BGP routing
table. In this example, Router B has learned the route 10.2.1.1 from its EBGP peer
Router A.
4. Run the display ip routing-table command on Router C to check its IP routing table. In
this example, Router C has not learned the route 10.2.1.1. The possible causes are as
follows:
– Cause 1: The routing policy of Router B prevents Router C from learning this BGP
route.

– Cause 2: AS_PATH attribute of the route that Router B advertised to Router C has
the AS number of Router C. BGP loop prevention mechanism prevents Router C
from learning this route.
5. Run the display current-configuration command on Router B to check its BGP
configuration information. In this example, Router B does not have any routing policy
configured for its IBGP peer. Therefore, cause 1 can be ruled out.
6. Run the display bgp routing-table peer ipv4-address advertised-routes command on
Router B to check the route that it advertised to its IBGP peer Router C. In this example,
the AS_PATH attribute of the route has the same AS number as Router C.
7. Run the display current-configuration command on Router B to check its BGP
configuration information. In this example, a routing policy is configured on Router B
and enables it to add its local AS number to the AS_PATH attribute of the route received
from its EBGP peer. Therefore, cause 2 caused this problem.
Procedure
Step 1 Run the system-view command on Router B to enter the system view.
Step 2 Run the route-policy route-policy-name permit node node command to enter the route-
policy view.
Step 3 Run the apply as-path as-number additive command to add AS number 65008 of Router A
to the route received from Router A.
After the preceding configuration is complete, Router A can ping Router C.
NOTE
In this example, you can also run the peer ipv4-address route-policy import command on Router B in
the BGP-IPv4 unicast address family view to delete the routing policy configured for the route that
Router B receives from its EBGP peer.
----End
Summary
To modify the AS_PATH attribute on a router, run the apply as-path as-number additive
command. Note the following points: a. Add the AS number of its peer to the route that it
receives from its peer; b. Add its local AS number to the route that it advertises to its peer. By
doing so, this router's IBGP peer can receive the route advertised by its EBGP peer.
6.13.9 Why Does Configuring BGP in an Incorrect Sequence

Causes a National Backbone Network Service Interruption?
Fault Symptom
Router C is a provincial backbone device, an egress on metropolitan area network (MAN) A.
Enabling the External Border Gateway Protocol (EBGP) allows Router C to communicate
with the national backbone devices Router A and Router B on the network shown in Figure
6-33. The provincial device Router D accesses the network and communicates with Router A
using EBGP after service cutover. Services running on MAN B on which Router D resides are
severely congested. Meanwhile, services running between Router A and a non-Huawei device
Router E are interrupted.

Figure 6-33 Networking diagram for frequent flapping of summarized routes advertised by an
EBGP peer
Before service cutover After service cutover

RouterE RouterE
Network Network
backbone backbone
RouterA RouterB
RouterA RouterB
RouterC RouterC RouterD
MAN A MAN A MAN B
Fault Analysis
1. The provincial backbone device Router C advertises summarized routes to Router A and
Router B. An EBGP peer relationship is established between Router D and Router A
after Router D accesses the network. Router D advertises provincial specific routes to
Router A. The route advertisement causes burst traffic on the inbound interface of Router
D and the provincial traffic is severely blocked.
2. After receiving the provincial specific routes from Router D, Router A advertises them to
the national backbone device Router E. A route number limit has been configured on
Router E. The specific routes to Router E exceed the route number limit, which causes
the EBGP peer relationship to be torn down. For example, the route number limit
configured on Router E is set to 1,000. Before the service cutover (Router D accesses the
network), Router C advertises 500 summarized routes to Router A. After the service
cutover (Router D accesses the network), Router D advertises 600 provincial specific
routes to RouterA. In this case, Router A receives more than 1,000 routes, which leads to
the teardown of the EBGP peers.
Procedure
Step 1 Before configuring an EBGP peer on Router D, configure a routing policy to prevent Router
D from advertising provincial specific routes. Run the system-view command to enter the
system view.
1. Run the route-policy route-policy-name permit node node command to configure a
routing policy. The matching mode for the routing policy node is permit.

1. Run the if-match ip-prefix ip-prefix-name command to configure a matching rule based
on the IP prefix list.
2. Run the apply cost cost command to configure a route cost.
3. Run the quit command to exit from the Route-Policy view and enter the system view.
4. Run the ip ip-prefix ip-prefix-name index index-number permit greater-equal equal-
value less-equal less-equal-value command to configure an IP prefix list.
Step 2 Configure a routing policy for BGP advertisement and establish a BGP peer relationship.
1. Run the bgp as-number command to enable BGP and enter the BGP view.
2. Run the peer ipv4-address route-policy route-policy-name export command to
configure a routing policy for advertising routes to the BGP peer.
Services on MAN B and the national backbone network will recover after the preceding
configurations are complete.
----End
Summary
You must configure a routing policy before establishing a BGP peer relationship in a scenario
in which either a MAN is cut over to a provincial backbone network or a provincial backbone
network is cut over to a MAN. Configuration in this sequence prevents a device from
advertising all routes to interrupt traffic.
6.14 L3VPN Troubleshooting

This chapter describes common causes of L3VPN faults and provides the corresponding
6.14.1 VPNs Configured with the Same VPN Target Cannot

Communicate
NOTE
Fault Symptom
As shown in Figure 6-34, BGP/MPLS VPN services are deployed on the network. CE1 and
CE3 belong to VPN-A, and CE2 belongs to VPN-B. VPN-A and VPN-B are configured with
the same VPN target to ensure that they can communicate with each other.
After the configurations, CE1 can ping the IP address 4.4.4.9 in VPN-A successfully, but CE2
fails to ping the IP address 4.4.4.9 in VPN-A. This indicates that the communications between
VPN-A and VPN-B fail.

Figure 6-34 Networking diagram of BGP/MPLS VPN
AS: 65410 AS: 65430

VPN-A VPN-A
Loopback1
CE1 CE3
4.4.4.9/32
GE1/0/0 GE1/0/0
Loopback1
GE1/0/0 2.2.2.9/32 GE1/0/0
PE1 POS1/0/0 POS2/0/0 PE2
Loopback1 172.1.1.2/24 172.2.1.1/24 Loopback1
1.1.1.9/32 POS3/0/0 POS3/0/0 3.3.3.9/32
172.1.1.1/24 172.2.1.2/24
GE2/0/0 P
MPLSbackbone
AS: 100
GE1/0/0
CE2
VPN-B
AS: 65420
Fault Analysis
1. Run the display bgp peer or display bgp vpnv4 all peer command on PE1. You can
find that the BGP peer relationship between PE1 and PE2 is in the Established state.
2. Sequentially run the display mpls ldp session command on PE1, P, and PE2. You can
find that the Status field in the command output is displayed as Operational, indicating
that the LDP sessions between PE1 and P and between P and PE2 have been established.
3. Run the display ip vpn-instance verbose command on PE1 and PE2. You can find that
the VPN targets of VPN-A and VPN-B are the same.
4. Sequentially run the display mpls ldp lsp command on PE1, P, and PE2 to check
information about label allocation. You can find that public network labels and VPN
labels are allocated to all the nodes along the LSP between PE1 and PE2.
5. Run the display ip interface brief command on the PEs to check IP addresses assigned
to the interfaces. You can find that VPN-B and VPN-A are bound to the same IP address.
[PE1] display ip interface brief
......
Interface IP Address/Mask Physical Protocol
......
Gigabitethernet1/0/0 10.1.1.2/30 up up
Gigabitethernet2/0/0 10.1.1.2/30 up up
......
In the process of route cross on the PEs, VPN-B only selects the local direct route
instead of the BGP route destined for VPN-A. In addition, no prompt will be displayed
when you bind VPNs to the same IP address. After the binding, the VPNs fail to
communicate with each other.

Procedure
Step 1 On PE1 and CE2, run the system-view command to enter the system view.
Step 2 Run the interface interface-type interface-name command to enter the interface view.
Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the
interface.
NOTE
Bind VPN-A and VPN-B to different IP addresses.
Step 4 Run the quit command to quit the interface view.
Step 5 Run the bgp command to enter the BGP view.
Step 6 Run the ipv4-family vpn-instance vpn-instance-name command to enter the BGP VPN
instance view. Note that you do not need to perform this step on CE2.
Step 7 Run the undo peer ipv4-address command to delete the original BGP peer.
Step 8 Run the peer ipv4-address as-number command to configure a new BGP peer.
After the preceding configurations, CE2 can ping CE3 successfully. The fault is cleared.
----End
Summary
A PE can learn routes of different VPNs from the local CE. If the next hop of a route with this
type is reachable or can be iterated, the PE matches the route with the Import VPN target of
another VPN instance. If the match operation succeeds, the PE adds the route to the routing
table of the VPN instance. This process is called route cross.
In this troubleshooting case, IP addresses to which two VPNs are bound are the same. As a
result, the route exchanged between the VPNs is not preferentially selected. Therefore,
although the VPN targets of these VPNs are matched, the VPN cannot communicate with
each other. To rectify the fault, ensure that the VPNs are bound to different IP addresses.
6.14.2 Ping Between the PEs on a VPN Fails

NOTE
Fault Symptom
On the BGP/MPLS VPN network shown in Figure 6-35, VPN routes fail to be exchanged
between PE1 and PE2, and both PEs cannot ping each other successfully.
Two loopback interfaces are configured on each PE. Loopback 1 interfaces on the two PEs are
assigned public IP addresses, 1.1.1.1/32 and 1.1.1.2/32, respectively. Loopback 2 interfaces
on the two PEs are bound to the VPN instance named test and assigned private network IP
addresses, 10.1.1.1/24 and 10.1.1.2/24, respectively.

Figure 6-35 Networking diagram of BGP/MPLS VPN

Loopback 1 Loopback 1
PE1 PE2
P1
Fault Analysis
1. Run the display ip routing-table command on PE1 and PE2 to check whether both PEs
have routes destined for each other's loopback1 interfaces. You can find that both PEs
have such routes.
2. Run the display mpls ldp peer command on P1, and you can find that P1 establishes the
LDP sessions, with PeerID being 1.1.1.1 and 1.1.1.2. Run the display mpls lsp
command on P1, and you can find that P1 establishes LSPs with FECs being 1.1.1.1 and
1.1.1.2.
3. Run the display bgp peer command on PE1 or PE2 to check BGP peer relationships.
You can find that PE1 or PE2 establishes IBGP peer relationships with 1.1.1.2 or 1.1.1.1,
as indicated by Established in the command output.
4. Run the display bgp vpnv4 all peer command on PE1 or PE2 to check VPNv4 peer
relationships. You can find that PE1 or PE2 establishes VPNv4 peer relationships with
1.1.1.2 or 1.1.1.1, indicating that VPN routes can be properly advertised.
5. After the preceding steps, run the display ip routing-table vpn-instance command on
PE1 and PE2 to check the routes in the VRF, and you can find only one route destined
for each other's loopback2 interfaces, that is, 10.1.1.0/24 Direct with a 24-bit mask
instead of a 32-bit mask.
This indicates that both loopback2 interfaces are on the same network segment, which is
obviously incorrect. In fact, both PEs have received the VPN routes (BGP routes)
destined for each other's loopback2 interfaces. The received VPN routes, however, are on
the same network segment as that of the route 10.1.1.0/24 Direct. In this case, both PEs
consider that the received VPN routes are the same as 10.1.1.0/24 Direct, and therefore
import only 10.1.1.0/24 Direct to their VPN routing tables because the direct route has a
higher preference than the BGP route. As a result, both VPN routing tables do not
contain the BGP routes, and the PEs cannot ping each other successfully.
Procedure
Step 1 On PE1 and PE2, run the system-view command to enter the system view.
Step 2 Run the interface loopback loopback-number command to enter the loopback interface view.
loopback interface.
NOTE
Change the mask length of the loopback address to 32 bits.

After the preceding configurations, the PEs can ping each other successfully. The fault is
cleared.
----End
Summary
If two routes of different protocols are destined for the same network segment, the device
only adds the one with a higher preference to the routing table.
6.14.3 Communications Between the VPN and the Public Network

Fail on a Device
NOTE
Fault Symptom
As shown in Figure 6-36, the network is divided into two areas, Area-A and Area-B. Each
area has two PEs, which are configured with VRRP for the application system and Internet
services, as shown by the dotted blue line.
Interworking between VPNs and the Internet is enabled on PEs in each area. After GE 1/0/2
on B-PE1 fails, the VPN and Internet fail to communicate in Area-B. However, after GE 1/0/2
on A-PE1 fails, the VPN and Internet can still communicate in Area-A. Area-A and Area-B
have the same service model, except that Layer 2 transparent transmission is implemented
between PEs in Area-A and the application system through two switches.
NOTE
The servers in Area-A and Area-B respectively have two interfaces. One functions as the master and the
other the backup. The backup interface is in the inactive state and does not respond to any protocol
packet.

Figure 6-36 Networking diagram of communications failure between the VPN and the public
network on a device
Server
10.1.1.1/27
VLAN10 VLAN10
Trunk
VRRP for server

I n te rn e t
Area-A
10.1.3.1/27
GE1/0/1
10.1.2.1/27
VLAN20
GE
2
1 /0 / 20 VL 1/0 /
GE ANIF AN 2 GE1/0/1
GE1/0/1 IF 2
VLANIF10 VL VRRP for Internet 0 VLANIF10
A-PE1 A-PE2
Trunk(slot 2)
Trunk Trunk WAN
Trunk(slot 2)
B-PE1 B-PE2
VRRP for server GE1/0/1
GE1/0/1 GE
VLANIF11 1 VRRP for Internet 2 VLANIF11
VL /0 /
AN 2 1/0 / F 21
I
IF 2 GE AN
1 VL
VLAN21
GE1/0/1 Area-B
10.1.5.1/27
I n te rn e t
10.1.6.1/27
Server
10.1.4.1/27

NOTE
All IP addresses are configured as 10.X.X.X in the two areas. IP addresses bound to the VPN are
considered as IP addresses of the VPN.
Fault Analysis
Communications between the VPN and the public network can be easily implemented. You
can analyze the fault in the following steps.
1. Run the display current-configuration command to check configurations of the PEs.

You can find that the PEs are correctly configured.
Details are shown in Table 6-2.
Table 6-2 Key configurations of the PEs

A-PE1 A-PE2 B-PE1 B-PE2
Route # # # #
ip route- ip route- ip route- ip route-
config static static static static
uration 10.1.1.0 10.1.1.0 10.1.4.0 10.1.4.0
255.255.255.224 255.255.255.224 255.255.255.2 255.255.255.224
vpn-instance vpn-instance 24 vpn- vpn-instance
Media 10.1.1.10 Media 10.1.1.10 instance Media 10.1.4.10
ip route- ip route- Media ip route-
static vpn- static vpn- 10.1.4.10 static vpn-
instance Media instance Media ip route- instance Media
10.1.3.0 10.1.3.0 static vpn- 10.1.6.0
255.255.255.224 255.255.255.224 instance 255.255.255.224
10.1.2.1 10.1.2.1 Media 10.1.5.1
public public 10.1.6.0 public
# # 255.255.255.2 #
24 10.1.5.1
public
#
VLAN # # - -
interface interface
IF10 Vlanif10 Vlanif10
ip binding ip binding
vpn-instance vpn-instance
Media Media
ip address ip address
10.1.1.2 10.1.1.3
255.255.255.224 255.255.255.224
vrrp vrid 10 vrrp vrid 10
virtual-ip virtual-ip
10.1.1.10 10.1.1.10
vrrp vrid 10 #
priority 120
#
VLAN # # - -
interface interface
10.1.2.2 10.1.2.3
255.255.255.224 255.255.255.224
vrrp vrid 20 vrrp vrid 20
virtual-ip virtual-ip
10.1.2.10 10.1.2.10
vrrp vrid 20 #
priority 120
#

A-PE1 A-PE2 B-PE1 B-PE2
VLAN - - # #
interface interface
ip binding ip binding
vpn-instance vpn-instance
Media Media
10.1.4.2 10.1.4.3
255.255.255.2 255.255.255.224
24 vrrp vrid 11
vrrp vrid virtual-ip
11 virtual- 10.1.4.10
ip 10.1.4.10 #
vrrp vrid
11 priority
120
#
VLAN - - # #
interface interface
10.1.5.2 10.1.5.3
255.255.255.2 255.255.255.224
24 vrrp vrid 21
vrrp vrid virtual-ip
21 virtual- 10.1.5.10
ip 10.1.5.10 #
vrrp vrid
21 priority
120
#
You can find that configurations of Area-A and Area-B are similar. Because devices in
Area-A function normally, you can conclude that the configuration principle for Area-B
is correct.
2. Run the display ip routing-table command on B-PE2 to check the route destined for
10.1.4.1. You can find that the route is a network segment route, with the outgoing
interface as VLANIF11, and B-PE2 selects a member interface of VLAN 11, that is, GE
1/0/1, as the actual outgoing interface.
3. Run the display arp slot 1 command to check ARP entries of GE 1/0/1. You can find
that there is no ARP entry for 10.1.4.1.
4. Run the display arp slot 2 command to check ARP entries of the interface board in slot
2. You can find that the outgoing interface of the ARP entry for 10.1.4.1 is an Eth-Trunk
(the Eth-Trunk connects B-PE1 and B-PE2 and transmits VRRP protocol packets). After
the preceding steps, you can conclude that the missing of the ARP entry leads to the
failure of the communications between the VPN and the public network (to be specific,
from the public network to the VPN).
5. The cause for the missing of the ARP entry on the interface board in slot 1 is shown as
follows:
a. After GE 1/0/2 on B-PE1 fails, B-PE2 becomes the master device in the VRRP
backup group. The static route configured on B-PE2 is the network segment route
10.1.4.0 with the next hop address 10.1.4.10, and the outbound interface of the
route is VLANIF 11. Therefore, the specific host route cannot be obtained on the
public network.

b. When a device in the public network needs to access 10.1.4.1, B-PE2 finds that the
outgoing interface is VLANIF11. Because the static route (ip route-static 10.1.4.0
255.255.255.224 vpn-instance Media 10.1.4.10) is configured, B-PE2 randomly
selects a member interface of VLANIF11 as the outgoing interface (in this
troubleshooting case, the selected member interface is GE1/0/1), and sends ARP
requests and learns corresponding ARP entries through the member interface.
c. The server 10.1.4.1 has two interfaces (master and backup). The master interface is
in the Active state and connects to B-PE1, and the backup interface is in the
Inactive state and connects to B-PE2. The backup interface does not process any
protocol packet. Therefore, after the server 10.1.4.1 receives an ARP request from
B-PE2 through the backup interface, the application system does not respond to this
ARP request. In this case, although the interface of B-PE2, that is, GE 1/0/1, is
directly connected to 10.1.4.1, it cannot receive the ARP response from 10.1.4.1,
and consequently no corresponding ARP entry can be generated on GE 1/0/1. Since
the ARP entry is missing, communications from the public network to the VPN fail.
d. The ARP response of the server 10.1.4.1 can only be sent to GE 1/0/1 of B-PE1
through the master interface. The master interface is added to VLAN 11, and the
Eth-Trunk of B-PE1 is also added to VLAN 11; therefore, the ARP response is sent
to B-PE2 through the Eth-Trunk. As a result, when checking the ARP entries of the
interface board in slot 2 on B-PE2, you can find that the outgoing interface of the
ARP entry for 10.1.4.1 is the Eth-trunk, as shown in Figure 6-37.

Figure 6-37 Networking diagram of ARP request and response

Server
10.1.1.1/27
Active Inactive
VLAN10 VLAN10
Trunk
I n t e rn e t
Area-A
10.1.3.1/27
GE1/0/1
10.1.2.1/27
VLAN20
/2 G
E1/0 F20 VL E1/
GE1/0/1 G A NI AN 0/2 GE1/0/1
IF2
VLANIF10 VL 0 VLANIF10
A-PE1 A-PE2
Trunk(slot 2)
Trunk Trunk WAN
Trunk(slot 2) VLAN 11
B-PE1 B-PE2
GE1/0/1 G GE1/0/1
/ 2
VLANIF11 VL E1/0 0
1/ 21 VLANIF11
AN /2 E
G NIF
IF2 A
1 VL
VLAN21
GE1/0/1 Area-B
10.1.5.1/27
I n t e rn e t
10.1.6.1/27
Active Inactive
Server
10.1.4.1/27
ARP request
ARP reply

The cause for the successful communications between the VPN and the public
network in Area-A is that switches are placed in Area-A to transparently transmit
Layer 2 services, as shown in Figure 6-37.
Usually, after learning an ARP entry, a VLANIF interface generates a 32-bit host route for
selecting the outgoing interface. If a PE is configured with a static route, the VLANIF
interface has to randomly select an outgoing interface, and cannot correctly generate a 32-bit
host route.
To sum up, in this troubleshooting case, after a static network segment route is configured on
B-PE2, B-PE2 randomly selects a member interface of the outgoing interface (VLANIF11) to
forward packets. If the member interface is incorrectly selected, the communications between
the VPN and the public network fail. In the troubleshooting case, the ARP entry learning
process is normal; therefore, the fault is caused by the configuration of the static network
segment route.
Procedure
Step 1 Run the system-view command on B-PE2 to enter the system view.
Step 2 Run the undo ip route-static 10.1.4.0 255.255.255.224 vpn-instance Media 10.1.4.10
command on B-PE2 to delete the static route for communications between the VPN and the
public network.
Step 3 Run the ip route-static 10.1.4.1 255.255.255.255 vpn-instance Media 10.1.4.1 command on
B-PE2 to reconfigure the static route for communications between the VPN and the public
network.
After the preceding configuration, you can find that communications between the VPN and
the public network are implemented. The fault is therefore rectified.
----End
Summary
When configuring the function of communications between the VPN and the public network,
you can only configure a 32-bit host route if a VLANIF interface functions as the outgoing
interface, instead of a network segment route. Otherwise, a member interface of the VLANIF
interface is randomly selected as the outgoing interface, and the preceding fault occurs.
6.14.4 VPN Services Are Interrupted Because the Link Between an

ABR and a BAS Fails in a Full-meshed NSSA
NOTE
Fault Symptom
As shown in Figure 6-38, ABR1, ABR2, BAS1, and BAS2 form a full-meshed network. All
routers run OSPF, and the AS is divided into two areas, area 0 and area 1. Area 0 functions as
the backbone area, consisting of ABR1 and ABR2. Area 1 is configured as an NSSA,
consisting of two ABRs and two BASs.

All links are configured with MPLS LDP to transmit MPLS L3VPN services. Considering the
limited capability of the BASs, an upper limit on LSPs is set on the BASs and the BASs are
configured not to function as transit nodes.
When the link between ABR1 and BAS1 fails, VPN services between them are interrupted.
Figure 6-38 Networking diagram of the OSPF NSSA

Loopback0 Loopback0
1.1.1.1/32 2.2.2.2/32
Area0
ABR1 ABR2
Area1
NSSA
BAS1 BAS2
Loopback0 Loopback0
3.3.3.3/32 4.4.4.4/32
Fault Analysis
1. Run the display ospf routing command on ABR1 to check OSPF routing information.
You can find that Loopback0 of ABR1 is added to area 0. The rule for selecting OSPF
routes defines that intra-area OSPF routes are preferentially selected. Therefore, the IGP
path from ABR1 to BAS1 is ABR1 -> BAS2 -> ABR2 -> BAS1.
2. Run the display mpls ldp lsp command on BAS2 to check information about label
allocation. You can find that the incoming/outgoing label (In/OutLabel) of the LSP is
NULL/**, indicating that BAS2 does not allocate a label to the previous hop ABR1.
This is because BAS2 does not function as a transit node to allocate a label to Loopback0
of ABR1. BAS2 cannot receive the public network label from ABR1 and therefore VPN
Procedure
Create separate sub-interfaces on ABR1 and ABR2, assign IP addresses to the two sub-
interfaces, and add the sub-interfaces to area 1 (an NSSA).
Step 2 Run the interface interface-type interface-number.subinterface-number command to create a

sub-interface.
Step 3 Run the ip address command to assign an IP address to the sub-interface.
Step 4 Run the quit command to return to the system view.

Step 5 Run the ospf process-id command to enter the OSPF view.
Step 6 Run the area area-id command to enter the view of OSPF area 1.
Step 7 Run the network ip-address wildcard-mask command to add the sub-interfaces to area 1.
Step 8 Run the nssa command to configure area 1 as an NSSA.

After the preceding configurations, ABR1 can ping BAS1 successfully. The fault is cleared.
----End
Summary
Loopback interfaces should be added to the correct area.
6.14.5 A Routing Loop Occurs After a Sham Link Is Established

Between PEs
NOTE
Fault Symptom
As shown in Figure 6-39, OSPF runs on the network, and CE1 and CE2 respectively access
PE1 and PE2. A sham link is established between PE3 and PE4 to transmit LSAs.PE1 and
PE2 are not connected through Layer 3 interfaces. On CEs, GE1/0/0 is configured to belong
to area 0, and GE2/0/0 is configured to belong to area 1. The cost of the link between CE2 and
PE2 is set larger, ensuring that the traffic is preferentially transmitted through the link
between CE1 and PE1. Other links adopt the default cost value. VRRP runs on GE2/0/0 of
CE2, with CE1 as the VRRP gateway.
In the preceding networking, it is found that devices on the network segment 10.1.1.0/24 can
access PE3 and PE1, but cannot access PE4 and PE2, and devices on the office network can
access PE4, PE2, PE3, and PE1.

Figure 6-39 Networking diagram of the OSPF sham link

Cost 1
PE3 PE4
GE2/0/0 sham link GE2/0/0
20.1.2.6/24 20.1.2.1/30
Cost 1 GE1/0/0 GE1/0/0 Cost 1
20.1.2.5/30 20.1.2.9/30
Exit PE1 Cost 10 PE2 Exit
Cost 1
Network Network
Office GE2/0/0 GE2/0/0 Office
GE1/0/0 172.16.1.1/24 172.17.1.1/24 GE1/0/0
20.1.2.13/30 10.1.2.17/30
Cost 10 Cost 20
CE1 CE2
GE2/0/0 Area1 GE2/0/0

10.1.1.1/24 10.1.1.2/24
Cost 10 Cost 20
Fault Analysis
l A firewall exists on the network and packets are filtered by the firewall.
l A link fault occurs on the network.
l The routing planning is improper.
l A device fails.
Sequentially check whether the preceding faults exist, and you can find the following:
1. No firewall exists on the network.
2. The ping operation succeeds on all direct links of the network, indicating that these links
are in the normal state.
3. Run the tracert [ -a source-ip-address ] host command to determine the gateways
through which the packets sent from a device on the network segment 10.1.1.0/24 to
CE2. You can find that a loop is formed between PE2 and PE4. Theoretically, OSPF is a
loop-free protocol. Why does the loop occur?
4. Run the display ip routing-table command to view routing information about PE2. You
can find that the next hop of the route destined for the network segment 10.1.1.0/24 is
PE4, and the cost is 32. In addition, you can find that the cost of the link between PE2
and CE2 is 20. In this case, why does PE2 preferentially select the route with CE2 as the
next hop?
5. Run the ping [ -a source-ip-address ] host command to check the connectivity between
PE2 and CE2, and you can find that the ping operation succeeds and the link is normal.
Run the display ospf peer command to check information about the OSPF peer
relationships in each OSPF area. You can find that all OSPF peer relationships (including
the OSPF peer relationship between PE2 and CE2) are in the full state.

6. Run the display ospf lsdb command to check the OSPF LSDB on PE2, and you can find
that the LSDB contains the LSAs that are advertised by CE1 and CE2 and destined for
10.1.1.0/24. The LSA advertised by CE2 has the metric of 20; the metric value, however,
only indicates the cost of CE2 to reach 10.1.1.0/24, instead of the cost of PE2 to reach
10.1.1.0/24. After being added with the cost value between CE2 and PE2, that is, 20, the
cost of PE2 to reach 10.1.1.0/24 is 40 (20+20), which is larger than the cost of the path
PE2 -> PE4 -> PE3 -> PE1 -> CE1, that is, 32 (10+1+1+10+10).
Similarly, you can find that the cost of the path PE4 -> PE3 -> PE1 -> CE1, that is, 22, is
smaller than the cost of the path PE4 -> PE2 -> CE2, that is 41. In this case, PE4 must
select PE3, instead of CE2, as the next hop.
7. Run the display ospf lsdb command to check the OSPF LSDB on PE4. You can find the
LSA that is advertised by CE1 and destined for 10.1.1.0/24. Nevertheless, run the
display ip routing-table 10.1.1.0 24 verbose command on PE4, and you can find two
routes destined for 10.1.1.0/24. One is an OSPF route in the active state, with the next
hop being PE2, and the other is a BGP route in the inactive state, with the next hop being
PE2.
The cause for the route PE4 -> PE3 -> PE1 -> CE1 not being selected is that the sham
link is established between PE3 and PE4, and the route learnt from the sham link is
considered as a BGP route. The preference of BGP routes is 255, whereas the preference
of OSPF routes is 10. Therefore, PE4 preferentially selects the route learnt from PE2.
To sum up, the sham link is handled specially on PEs, and the type of the route learnt
from the sham link is BGP, leading to the routing loop between PE2 and PE4 on the
network.
Procedure
l Solution 1:
a. Run the system-view command to enter the system view.
b. Run the bgp command to enter the BGP view.
c. Run the ipv4-family unicast command to enter the IPv4 unicast address family
view.
d. Run the preference { external internal local | route-policy route-policy-name }
command to modify the BGP preference on PE4, enabling PE4 to preferentially
select the route learnt from the sham link.
NOTE
This solution eliminates the existing loop, but cannot prevent loops if the networking is changed.
l Solution 2:
b. Run the ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name
command to enter the OSPF view.
c. Run the area area-id command to enter the OSPF area view.
d. Run the sham-link source-ip-address destination-ip-address [ smart-discover ]
[ simple [ [ plain ] plain-text | cipher cipher-text ] | { md5 | hmac-md5 } [ key-id
{ plain plain-text | [ cipher ] cipher-text } ] | authentication-null ] [ cost cost ]
command to modify the cost of the sham link on PE4, disabling PE2 from
preferentially learning the route from PE4 and therefore eliminating the loop.
NOTE
Similar to solution 1, solution 2 cannot prevent loops if the networking is changed.

l Solution 3:
a. This solution is to add a VPN route between PE3 and PE4, which fundamentally
prevents loops.
NOTE
This solution actually takes PEs as MCEs and does not use MPLS VPN, which is inconvenient for
MPLS domain expansion.
l Solution 4:
This solution is to optimize the existing OAM network. The specific measure is to set up
a Layer 3 link between PE1 and PE2 and add this link to area 0. This solution can not
only solve the current problem, but also prevent the traffic on the network (such as the
traffic between CE1 and PE2) from being transmitted between the PEs. Details are as
follows:
b. Run the ospf process-id command to enter the OSPF view.
c. Run the area 0 command to enter the view of OSPF area 0.
d. Run the network ip-address wildcard-mask command to add the Layer 3 link to
area 0.
NOTE
You can adopt the second solution at the beginning because this solution causes less network change.
Later, you can adopt the fourth solution to completely solve the problem.
You can change the cost of the sham link to 100 on PE3 and PE4, and on PE2, change the next hop of
the route destined for 10.1.1.0/24 to 10.1.2.17/30. After the preceding change, devices on the network
segment 10.1.1.0/24 can access CE2, PE2, and PE4. Devices on other network segments can also access
CE2, PE2, and PE4.
----End
Summary
It is recommended that the sham link be avoided in network planning to prevent routing
loops.
6.14.6 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN

Option B Setup Because the Mask of the Loopback Address on an
Intermediate Router Is Incorrect
NOTE
Fault Symptom
As shown in Figure 6-40. The Inter-AS VPN Option B is Setup, and the EBGP peer
relationship is established between PE2 and CE2. It is found that CE2 can learn the route to
2.2.2.5 from CE1, but CE1 cannot learn the route to 1.1.1.5 from CE2.

Figure 6-40 Networking diagram of inter-AS VPN Option B mode
Loopback0 Loopback0
AS 100 1.1.1.2/32 AS 200
1.1.1.3/32
Loopback0 Loopback0
1.1.1.1/32 ASBR1 ASBR2 1.1.1.4/32
PE1 PE2
CE1 CE2
Loopback0 Loopback0
2.2.2.5/32 1.1.1.5/32
AS 300 AS 300
Fault Analysis
NOTE
In normal situations, routes are learnt in a bidirectional manner. With inter-AS VPN Option B, VPN
routes are saved on intermediate ASBRs. To locate the fault, you need to check BGP VPNv4 routes on
devices along the path to the device where the route to 1.1.1.5 is lost.
1. Run the display bgp vpnv4 all routing-table command sequentially on PE2, ASBR2,
ASBR1, and PE1 to identify the device on which the VPNv4 route to 1.1.1.5 is lost. You
can find that all the devices have this route, but PE1 does not take this route as an
optimal route.
2. Run the display current-configuration command on ASBR1. You can find that the IP
address of Loopback0 on ASBR1 is configured as 1.1.1.2 255.255.255.252. LDP labels
are allocated only to host routes with a 32-bit mask by default. Loopback0 on ASBR1
has an IP address with a 30-bit mask and therefore it is not assigned an LDP label and
the corresponding LSPs cannot be established. When PE1 learns a VPNv4 route, it
checks whether the corresponding LSP is valid. If the LSP is not fully established
because of incomplete label allocation, the VPNv4 route cannot be added to the VPN
routing table.
Procedure
Step 2 Run the interface loopback loopback-number command to enter the loopback interface view.
loopback interface.

NOTE
Change the mask length of the loopback address to 32 bits.
Step 4 Run the reset mpls ldp vpn-instance vpn-instance-name command to reset vpna. In this
manner, all interfaces, peers, sessions, LSPs, and CR-LSPs of vpna are deleted and re-created.
After the preceding configurations, run the display ip routing-table vpn-instance vpn-
instance-name command, and you can find that the routing table of vpna contains the route to
1.1.1.5. Run the ping -vpn-instance vpn-instance-name -a source-ip-address command on
PE1. You can find the ping operation succeeds. The fault is cleared.
----End
Summary
When LDP is used to establish LSPs, LDP labels are allocated only to the host routes with a
32-bit mask by default. If the corresponding route is not a host route, the LDP labels cannot
be correctly allocates and the LSP cannot be established.
6.14.7 PEs Cannot Learn Routes After the policy vpn-target

Command Is Configured on an RR
NOTE
Fault Symptom
As shown in Figure 6-41, the same VPN instance, vpna, is configured on PE1, PE2, PE3, and
PE4. To improve network reliability, double RRs are selected from Ps in the same AS for the
VPN instance. In this manner, the two RRs back up each other and respectively reflect public
network routes and VPNv4 routes. After the configurations, PE1 and PE2 cannot learn routes
from PE3 and PE4, and PE3 and PE4 cannot learn routes from PE1 and PE2.
Figure 6-41 Networking diagram of the VPN with double RRs
RR1 RR2
PE1 PE2 PE3 PE4

Fault Analysis
1. Check whether a routing policy that limits route advertisement is configured on the RRs.
Run the display route-policy command on RR1 and RR2, and you can find that no RR
is configured with a routing policy that restricts route reflection and reception.
2. Check whether route conflict occurs. Run the display ip routing-table vpn-instance
vpna command on the PEs, and you can find that there is no route conflict in vpna.
3. Check whether the RRs are incorrectly configured. Run the display current-
configuration command on the RRs to view BGP configurations. You can find that one
RR is configured with the policy vpn-target command in the BGP-VPNv4 address
family view.The policy vpn-target command is used to enable the VPN-Target filtering
function for received VPNv4 routes. Only the VPNv4 route whose Export VPN target
attribute matches the local Import VPN target attribute can be added to the routing table.
The RR is not configured with the VPN instance vpna; as a result, the RR does not
receive the routes with the VPN target as vpna.
Procedure
l Solution 1: Disable the VPN-Target filtering function for received VPNv4 routes on the
RR.
b. Run the bgp command to enter the BGP view.
c. Run the ipv4-family vpnv4 command to enter the BGP-VPNv4 address family
view.
d. Run the undo policy vpn-target command to cancel VPN target filtering for
VPNv4 routes. In this manner, all VPNv4 routes can be received.
After the preceding configurations, run the display ip routing-table command on

PE1 and PE2. You can find that the two PEs have routes destined for PE3 and PE4.
Similarly, you can find that PE3 and PE4 have routes destined for PE1 and PE2.
The fault is therefore rectified.
l Solution 2: Configure the VPN instance vpna on the RR.
b. Run the ip vpn-instance vpn-instance-name command to create the VPN instance
vpna.
c. Run the vpn-target vpn-target command to associate the VPN target with vpna.
NOTE
The vpn-target must be the same as that of vpna configured on the PEs.
After the preceding configurations, run the display ip routing-table command on

PE1 and PE2. You can find that the two PEs have routes destined for PE3 and PE4.
Similarly, you can find that PE3 and PE4 have routes destined for PE1 and PE2.
----End
Summary
The policy vpn-target command needs to be used with caution.

6.14.8 VPN Routing Table on the PE Does Not Contain Any Route
Sent from the Peer PE
NOTE
Fault Symptom
Figure 6-42 Networking diagram of BGP/MPLS IPv6 VPN
Loopback0 Loopback0 Loopback0

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE1/0/0
12.1.1.2/30 23.1.1.2/30
PE1 PE2
GE1/0/0 GE2/0/0
GE2/0/0 12.1.1.1/30 P 23.1.1.1/30 GE2/0/0
2001:db8:1:: 2001:db8:2::
12/64 22/64
GE1/0/0 GE1/0/0
2001:db8:1:: 2001:db8:2::
11/64 21/64
CE1 CE2
The configuration in Figure 6-42 is as follows:
l EBGP runs on the PEs and the CEs.

l An IBGP adjacency is established between PE1 and PE2 to transmit VPNv6 routing
information that contains inner labels.
l An arbitrary IGP runs on PE1, the P, and PE2 to transmit routing information about the
public network.
l MPLS and MPLS LDP are enabled on PE1, the P, and PE2
After the configuration is complete, PE1 can receive private network routes from CE1, but
PE2 and CE2 cannot do that.
Fault Analysis
1. Run the display bgp vpnv6 all peer command on each PE. The command output shows
that the BGP peer relationship is in the Established state, which indicates that the peer
relationship is set up.
2. Run the display bgp vpnv6 all routing-table peer ipv4-address received-routes
command on PE2. The command output shows that PE2 has received the VPNv6 route
sent from PE1.

3. Run the display bgp vpnv6 vpn-instance vpn-instance-name routing-table ipv6-

address [ mask-length ] command on PE2 to view information about the tunnel to which
the specified route is iterated.
If the Relay token is 0x0, it indicates that the route to ip-address does not find the
associated tunnel. The cause is that the setup of LSP for the next hop of the route fails.
<PE2> display bgp vpnv6 vpn-instance vpna routing-table 2001:db8:66::66 128
BGP local router ID : 3.3.3.3
Local AS number : 100
Paths: 1 available, 0 best, 0 select
BGP routing table entry information of 2001:db8:66::66/128
Label information (Received/Applied): 105472/NULL
From: 1.1.1.1 (1.1.1.1)
Route Duration: 00h02m17s
Relay Tunnel Out-Interface:
Relay token: 0x0
Original nexthop: ::FFFF:1.1.1.1
Qos information : 0x0
Ext-Community:RT <1 : 1>
AS-path 65420, origin igp, MED 0, localpref 100, pref-val 0, internal, pre
255
Not advertised to any peer yet
4. Check whether there is an LSP to the next hop (1.1.1.1).

<PE2> display mpls lsp include 1.1.1.1 32
If the display is blank, it indicates that there is no LSP to 1.1.1.1, and the LSP tunnel is
not established successfully.
5. Check whether MPLS LDP is enabled on the interfaces between PE1 and P, and on the
interfaces between P and PE2.
[PE1] interface gigabitethernet 1/0/0
[PE1-GigabitEthernet1/0/0] display this
#
ip address 12.1.1.1 255.255.255.252
mpls
#
The preceding display shows that MPLS LDP is not enabled in the interface view.
Procedure
Step 1 Run the interface gigabitethernet 1/0/0 command on PE1 to enter the interface view.
Step 2 Run the mpls ldp command in the interface view to enable LDP on the interface.
----End
Summary
To transfer the traffic of private network across the public network, a public network tunnel is
required.
If the setup of a public network tunnel fails, the possible reason is that MPLS LDP is not
enabled on the interface, or an LDP session is not established. As a result, the PE does not
choose the private network route sent from the peer PE as the optimal route.

6.14.9 CEs Cannot Ping Through Each Other

NOTE
Fault Symptom
BGP/MPLS IPv6 VPN services are configured in the network shown in Figure 6-43. CE1 and
CE2 belong to the same IPv6 VPN. After the configuration, CE1 cannot ping through CE2.

PE1 PE2
P1 P2
CE1 CE2
Fault Analysis
NOTE
Take the configuration of PE2 as an example. The configuration of PE1 is similar to that of PE2, and is
not mentioned here.
1. Run the display bgp vpnv6 all peer command on PE2 to check the IBGP peer
relationship between PE2 and PE1. You can find that the IBGP peer relationship is not
set up successfully.
2. Check the BGP configuration. You can find that the loopback interface is not specified as
the outbound interface of the local IBGP peer session by using the peer peer-ip-address
connect-interface loopback interface-number command when the two PEs set up the
IBGP connection.
If the outbound interface is not specified for the local IBGP session, the outbound
interface of the data stream is the outbound interface of the session by default.The IBGP
peer relationship between PEs is usually set up by using the loopback interface addresses
with each having a 32-bit mask, and the source interface through which BGP packets are
sent is also set to the loopback interface.
Procedure
Step 1 Run the interface loopback interface-number in the system view.
Step 2 Run the ip address ip-address 32 command to configure an IP address for the loopback
interface.

Step 4 Run the bgp as-number command to display the BGP view.
Step 5 Run the peer peer-ip-address connect-interface loopback interface-number command to

specify the loopback interface as the outbound interface to the IBGP peer session.
Step 6 Save the configuration.
On the local CE, ping the remote CE. If the ping succeeds, it indicates that the fault is
rectified.
----End
Summary
Specify the local loopback interface as the outbound interface of the local IBGP session when
configuring PE peers.
6.14.10 Failed to transmit Large Packets of the Private Network

NOTE
Fault Symptom
When the Huawei device networks with devices from other vendors deploy Layer 3 MPLS
IPv6 VPN service by using the Ethernet interface, it is found that the packet larger than 1492
bytes cannot be transmitted between private network users. Users cannot access certain
websites or download files through FTP.
Run the ping command, and find that the ping fails when the payload of the specified ICMP
is larger than 1464 bytes.
Fault Analysis
1. The default MTU of an Ethernet interface is 1500 bytes. When forwarding data, MPLS
IPv6 VPN inserts a 4-byte or 8-byte MPLS packet header between the IP header and the
Layer 2 frame header. That is, a 4-byte label is added during the forwarding between the
penultimate hop and the tail-end hop; an 8-byte label is added in data forwarding
between other P devices.
2. The link layer does not know the MPLS processing. By default, the link layer still
receives data packets with the maximum size of 1500 bytes. Then, packets of 1492 to
1500 bytes is too long after the MPLS packet header is added to the packets.
Consequently, the link layer cannot receive them, and data forwarding is adversely
affected.
Procedure
Step 1 Adjust the MTU value of the physical interfaces on other vendors' devices. The MTU value
should be at least 1508 bytes.

Step 2 By default, an Ethernet interface on the Huawei device can send and receive large frames. No
adjustment is required on the Huawei device.
----End
Summary
When large packets cannot be received, check whether the MTU of the inbound interface is
too small.
6.14.11 PE Fails to Ping Through the Remote CE Network

Segment
NOTE
Fault Symptom
vpn1
Site1
CE1
vpn1
GE1/0/0 Backbone GE1/0/0
2001:db8:1:: 2001:db8: Site3
1/64 2::1/64
PE1 CE3
GE2/0/0
2001:db8:1:: P PE2
2/64
CE2
Site2
vpn1
As shown in Figure 6-44, after binding multiple private network interfaces to the same VPN,
run the ping ipv6 2001:db8:2::1 command on CE1 and CE2. CE1 and CE2 can ping through
the remote network segment where CE3 resides. Run the ping ipv6 vpn-instance vpn1
2001:db8:2::1 command on PE1. PE1, however, cannot ping though the network segment
where CE3 resides.

Fault Analysis
Multiple private network interfaces on the ingress node (a PE) are bound to the same IPv6
VPN instance. When the PE pings or traces the remote CE network segment, the source
address of the ICMP packet is the lowest private network address that is Up on the local PE; if
the remote CE does not import the private network address, the ICMPv6 packet cannot return.
Therefore, to ping through the remote CE segment by using the ping ipv6 vpn-instance vpn-
instance-name dest-ipv6-address command, ensure that the remote CE has all the Up private
network addresses of the local PE. If the source IP address is specified as a private network
address in the Up state on the local PE by using the ping command, and the private network
address is imported to the remote CE, the PE can ping through the remote CE network
segment.
Procedure
Step 1 Ensure that the remote CE has all the private network addresses in the Up state that belong to
the local PE.
Step 2 Run the import-route direct command in BGP VPN instance view of the local PE. Ensure
that all private routes on the local PE can be advertised through MP-BGP. You can also
replace the ping ipv6 vpn-instance vpn-instance-name dest-ip-address command with the
ping ipv6 -a source-ipv6-address vpn-instance vpn-instance-name dest-ipv6-address
command.
----End
Summary
When you ping the remote CE network segment from the local CE, it is recommended to
specify the source address of the ping packet; otherwise, the ping may fail.
6.14.12 L2VPN IP RAN Troubleshooting

This chapter describes common causes of L2VPN IP RAN faults and provides the
corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.
6.14.13 Packets Are Lost or Duplicate Packets Are Received on an

Integrated IP RAN with the Networking of HVPLS + L3VPN/IP
This section describes the troubleshooting flowchart and provides a step-by-step
troubleshooting procedure for the fault that packets are lost or duplicate packets are received
on the CSG in an IP RAN with the networking of HVPLS + L3VPN/IP.
6.14.14 Private Route Flapping Occurs Frequently When a

Physical Interface Alternates Between Up and Down
NOTE

Fault Symptom
On the network shown in Figure 6-45, Router A, Router B, and Router C run IS-IS and are
configured with L3VPN services. After the configurations, services between Router A and
Router C flap.
Figure 6-45 Networking diagram of frequent route flapping caused by alternation between
Up and Down of a physical interface
RouterA RouterB
GE1/0/0 GE1/0/0
RouterC
Fault Analysis
1. Run the display ip routing-table 1.1.1.1 and display fib 1.1.1.1 commands on Router A
to view the route type. It is found that routes are generated by IS-IS and LDP over TE is
configured.
------------------------------------------------------------------------------
Summary Count : 1
1.1.1.1/32 ISIS 15 10 D 1.1.1.2 Tunnel1/0/1

Route Entry Count: 1
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID
1.1.1.1/32 1.1.1.2 DGHU t[17635149] Tun1/0/1 0x1008e
2. Run the display isis lsdb verbose command to view the IS-IS neighborship of the
device. It is found that the IS-IS neighbor relationship is established for a long time and
is stable. This indicates that the IS-IS neighbor relationship is normal.
Database information for ISIS(100)
----------------------------------
LSPID Seq Num Checksum Holdtime Length
ATT/P/OL
0000.0255.0239.00-00 0x00003038 0xd401 867 367 0/0/0
INTF ADDR 1.1.1.1
Router ID 1.1.1.1
3. Run the display isis lsdb 0000.0255.0239.00-00 command to check whether the specific
LSP changes.
----------------------------------
ATT/P/OL
------------------------------------------------------------------------------
-
0000.0255.0239.00-00 0x00003038 0xd401 831 367 0/0/0


----------------------------------
ATT/P/OL
------------------------------------------------------------------------------
-
0000.0255.0239.00-00 0x00003038 0xd401 829 367 0/0/0
According to the preceding information, the LSP is normal with the length and hold-time
parameters unchanged. Therefore, route flapping is not caused by IS-IS.
4. Run the display mpls lsp include 1.1.1.1 32 command to check whether the TE tunnel
flapping occurs. It is found that the LSP to the IP address does not flap. The LDP LSP is
Up for a short time, which indicates that the LDP LSP flaps. As a result, route flapping
occurs.
------------------------------------------------------------------------------
-
LSP Information: RSVP LSP
------------------------------------------------------------------------------
-
No : 1
SessionID : 12
IngressLsrID : 1.1.1.3
LocalLspID : 32778
Tunnel-Interface : Tunnel1/0/2
Fec : 1.1.1.1/32
Nexthop : 1.1.2.1
In-Label : 65542
Out-Label : 65686
In-Interface : GigabitEthernet2/0/0
Out-Interface : GigabitEthernet3/0/0
LspIndex : 2123
Token : 0x700bef8
LsrType : Transit
Bypass In Use : Not Exists
Bypass Tunnel Id : 0x0
BypassTunnel : Tunnel Index[---]
Mpls-Mtu : 1600
TimeStamp : 309526sec
Bfd-State : ---
No : 2
SessionID : 12
LocalLspID : 1
Fec : 1.1.1.1/32
Nexthop : 1.1.2.1
In-Label : NULL
Out-Label : 65817
In-Interface : ----------
LspIndex : 2181
Token : 0x700bf18
LsrType : Ingress
Mpls-Mtu : 1600
Bfd-State : ---

No : 3
SessionID : 12
LocalLspID : 32773
Fec : 1.1.1.1/32
Nexthop : 1.1.2.2
In-Label : NULL
Out-Label : 65581
LspIndex : 2827
Token : 0x80094a9
LsrType : Ingress
Mpls-Mtu : 1600
Bfd-State : ---
------------------------------------------------------------------------------
-
LSP Information: LDP LSP
------------------------------------------------------------------------------
-
No : 4
VrfIndex :
Fec : 1.1.1.1/32
Nexthop : 1.1.1.2
In-Label : 1102
Out-Label : 3
Out-Interface : Tunnel1/0/2
LspIndex : 72894
Token : 0x1008f
FrrToken : 0x0
LsrType : Transit
Outgoing token : 0x0
Label Operation : SWAP
Mpls-Mtu : ------
TimeStamp : 10sec
Bfd-State : ---
No : 5
VrfIndex :
Fec : 1.1.1.1/32
Nexthop : 1.1.1.2
In-Label : NULL
Out-Label : 3
Out-Interface : Tunnel1/0/2
LspIndex : 72897
Token : 0x1008e
FrrToken : 0x0
LsrType : Ingress
Outgoing token : 0x0
Label Operation : PUSH
Mpls-Mtu : ------
TimeStamp : 10sec
Bfd-State : ---
5. Run the display mpls ldp session command to view the status of the LDP neighbor. It is
found that the LDP neighbor is flapping.
LDP Session(s) in Public Network
------------------------------------------------------------------------------
Peer-ID Status LAM SsnRole SsnAge KA-Sent/Rcv
------------------------------------------------------------------------------

......
1.1.1.1:0 Operational DU Passive 000:00:00 20492/20493
......
------------------------------------------------------------------------------
TOTAL: 36 session(s) Found.
LAM : Label Advertisement Mode SsnAge Unit : DDD:HH:MM
6. Run the display mpls ldp peer command to view information about the LDP peer. The
command output shows two LDP peers, namely, a remote LDP peer and a local LDP
peer.
------------------------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
------------------------------------------------------------------------------
1.1.1.1:0 1.1.1.1 Remote Peer : otb-to-trg
------------------------------------------------------------------------------
TOTAL: 36 Peer(s) Found.
------------------------------------------------------------------------------
Peer-ID Transport-Address Discovery-Source
------------------------------------------------------------------------------
1.1.1.1:0 1.1.1.1 GigabitEthernet1/0/0
------------------------------------------------------------------------------
TOTAL: 36 Peer(s) Found.
7. Run the display interface gigabitEthernet1/0/0 command to view the status of the
interface. It is found that the interface frequently alternates between Up and Down. As a
result, route flapping occurs.
Description:10G_Link_to-TRG_Through_ODF 23/24
Internet protocol processing : disabled
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-82d7-
b2e5
The Vendor PN is SXP3101SV-H12
Rx Power: -4.50dBm, Tx Power: 1.14dBm
Loopback:none, LAN full-duplex mode, Pause Flowcontrol:Receive Enable and
Send Enable
Last physical up time : 2010-05-20 21:33:42
Last physical down time : 2010-05-20 21:31:58
Statistics last cleared:2010-04-25 02:10:55
Input:
Overrun: 0 packets
InRangeLength: 0 packets
LongPacket: 0 packets, Jabber: 0 packets,
RxPause: 0 packets
Output:
System: 0 packets, Overruns: 0 packets

TxPause: 0 packets
Unknown Vlan: 0 packets
Description:10G_Link_to-TRG_Through_ODF 23/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-82d7-
b2e5
The Vendor PN is SXP3101SV-H12
Rx Power: -4.50dBm, Tx Power: 1.14dBm
Loopback:none, LAN full-duplex mode, Pause Flowcontrol:Receive Enable and
Send Enable
Input:
Overrun: 0 packets
LongPacket: 0 packets, Jabber: 0 packets,
RxPause: 0 packets
Output:
TxPause: 0 packets
Procedure
Step 2 Run the interface interface-type interface-number command on Router A to enter the
interface view.
Step 3 Run the shutdown command on Router A. Packets are transmitted from Router A through
Router C to Router B instead of from Router A to Router B. Then, services are running
normally.
After the preceding operations, the fault is rectified. Then, check the link between Router A
and Router B.
----End
Summary
When route flapping occurs, you need to check the route type, and then check whether the
relevant protocols flap. If the protocols do not flap, you need to check whether IP address
collision occurs.

6.14.15 CE Cannot Access Some Web Servers Due to the MTU

Configuration
NOTE
Fault Symptom
On the network shown in Figure 6-46, BGP/MPLS VPN is configured on the PEs. CE1, Web
server A, and Web server B are in the same VPN. PE3 and Web server A are connected
through a firewall. After the configuration is complete, the CE cannot access some Web
servers.
Figure 6-46 Networking diagram of the CE failing to access some Web servers
CE2
PE2 Web Server B
PE1 P
Switch
PE3 Firewall Web Server A

CE3
CE1
Fault Analysis
1. Run the display bgp vpnv4 all peer command on PE1 and PE2. It is found that the BGP
peer relationships are set up between the PEs and between the PE and CE and are in the
Established state.
2. Run the ping -vpn-instance vpn-instance-name command on PE1, PE2, and PE3. The
accessed CEs can be pinged successfully from the PEs.
3. Run the display current-configuration configuration vpn-instance vpn-instance-name
command on PE1, PE2, and PE3 to view the configurations of the VPN instances. It is
found that the VPN instances on the PEs are configured correctly and the import VPN
target on one PE matches the export VPN target on another PE.
4. Get packets head on an interface of the PE. It is found that the length of an IP packet sent
from the Web server is 1496 bytes and the IP packet cannot be fragmented. The length of

the packet becomes 1504 bytes (1496+8(length of double MPLS labels)) after the packet
enters the MPLS network.
5. Run the display mpls interface command on PE1, PE2, and the P to view the MTU of
MPLS packets on an interface. It is found that the MTU value for MPLS packets on the
P is 1500. As the MPLS packets are longer than 1504 bytes, they are discarded on the PE
or P.
Procedure
Step 1 Run the system-view command on the P to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the interface view of the
interface connecting the P to the PE.
Step 3 Run the mtu mtu command to reconfigure the MTU value on the interface.
Step 4 Run the mpls mtu 1600 command to re-configure the MTU value for MPLS packets on the
interface.
NOTE
The relationship between the MPLS MTU on an interface and the interface MTU is as follows:
l If the MPLS MTU is not configured on the interface, the MTU on the interface is used.
l If the MTU of the MPLS packets is set, the MPLS MTU is compared with the MTU on the interface
and the smaller one is adopted.
Step 5 Run the restart command to restart the current interface.
After the preceding operations, it is found that CE1 can access Web server A and Web server
B. The fault is rectified.
----End
Summary
The cause of this troubleshooting case is as follows:
l The packet sent from the Web server cannot be fragmented, and the packet length
exceeds the MPLS MTU on the P after two MPLS labels are added. As a result, the
packet is discarded on the P.
l The Firewall prevents ICMP packets, causing the path MTU discovery mechanism to be
invalid.
The basic principle of the path MTU discovery mechanism is as follows:
1. The source initially adopts the MTU on the first hop interface as the MTU of the path to
the destination and sets the value of the Don't Fragment (DF) bit in all IP packets sent to
the destination to 1.
2. When a device along the path receives the packet and forwards the packet on an
outbound interface, the device discovers that the packet length exceeds the MTU on the
outbound interface and the value of the DF bit is 1. In this case, the device discards the
packet and responds with an ICMP unreachable packet (type=3, code=4, fragment
needed but don't-fragment bit set) to the source.
3. After receiving the ICMP unreachable packet, the source decreases the path MTU value
and re-sends the IP packet.

This problem is caused by an incorrect MTU value. To resolve the problem, re-configure the
MTU.
6.14.16 The RR Fails to Reflect VPN Routes

NOTE
Fault Symptom
On the network shown in Figure 6-47, a Route Reflector (RR) is configured to optimize
BGP/MPLS VPN services. CE1 and CE2 are in the same VPN. After the configuration is
complete, it is found that the RR can learn a VPNv4 route advertised by PE1 but PE2 fails to
learn this route.
Figure 6-47 Networking diagram of the RR failing to reflect VPN routes
Route Reflector
PE1 PE2
(Client1) (Client2)
CE1 CE2
Fault Analysis
1. Run the display current-configuration configuration bgp command on the RR and
PEs. It is found that route reflection relationships are correctly set up between the RR
and two PEs.
2. Run the display bgp vpnv4 all peer command on the RR. It is found that the IBGP peer
relationships between the RR and the PEs are in the Established state ( BGP current
state: Established, Up for 00:21:15).
3. Run the display ip extcommunity-filter command on the RR to view information about
the extended community attribute filter.
Extended Community filter Number 1
deny rt : 100:1
permit rt : 200:1

The output of the display ip extcommunity-filter command indicates that the routes
with the RT being 100:1 are filtered out.
4. Run the display ip vpn-instance verbose command on PE1 to view detailed information
about all VPN instances.
Total VPN-Instances configured : 1
VPN-Instance Name and ID : a, 1

Create date : 2010/06/23 20:18:40 UTC+08:00 DST
Up time : 0 days, 00 hours, 02 minutes and 27 seconds
Route Distinguisher : 1:1
Export VPN Targets : 100:1
Import VPN Targets : 111:1
Label Policy : label per route
Import Route Policy : p1
Export Route Policy : p2
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
The VPN QoS configuration information : based on VPN
CIR: 10000000 PIR: 10000000 QoS-profile name: profile1
Tunnel Policy : tnlpolicy1
Description : This is a VPN for company1.
Maximum Routes Limit : 100
Log Interval : 5
Interfaces : GigabitEthernet1/0/0
The output of the display ip vpn-instance verbose command indicates that the packets
with the Export VPN Targets field being 100:1 are filtered out on the RR. As a result,
the RR does not reflect routes to PE2.
Procedure
Step 1 Run the system-view command on the RR to enter the system view.
Step 2 Run the ip extcommunity-filter 1 permit rt 100:1 command on the RR to make the Export
RT on PE1 and the RT of the extended community filter on the RR the same.
Step 3 Run the bgp as-number command on the RR to enter the BGP view.
Step 4 Run the ipv4-family vpnv4 command on the RR to enter the BGP-VPNv4 address family
view.
Step 5 Run the undo rr-filter command on the RR to delete the original reflection policy of the RR.
Step 6 Run the rr-filter 1 command on the RR to specify a new reflection policy for the RR.
After the preceding operations, PE2 can learn the VPNv4 routes advertised by PE1. The fault
is rectified.
----End
Summary
When configuring an RR, ensure that the Import VPN target and Export VPN target match the
RTs on PE1 and PE2.
To minimize the impact of incorrect configurations, you can run the undo policy vpn-target
command to permit all VPNv4 routes.

6.14.17 CE1 Cannot Register with CE2 Because the Maximum

Number of Routes Exceed the Upper Threshold
NOTE
Fault Symptom
On the network shown in Figure 6-48, the PE is configured with BGP/MPLS VPN services,
which are classified into signaling VPN services and media VPN services. CE1 is an Access
Gateway (AG) device; CE2 is a Softswitch device (Soft3000); CE1 and CE2 are in the same
VPN. After the configuration is complete, it is found that CE1 cannot register with CE2.
Figure 6-48 Networking diagram of an AG device failing to register with a Softswitch device
PE1 P PE2
CE1 CE2
Fault Analysis
1. Run the display bgp vpnv4 all peer command on PE1 and PE2. It is found that the BGP
peer relationships between the PEs and between the PEs and CEs are in the Established
state.
2. Run the ping -vpn-instance vpn-instance-name command on PE1 and PE2. It is found
that the PEs can ping the corresponding CEs successfully.
3. Run the display ip routing-table vpn-instance vpn-instance-name command on PE1
and PE2. It is found that PE1 and PE2 have VPN instance routes that are destined for
each other.
4. Run the display bgp vpnv4 all routing-table 10.1.1.1 command on PE1 to view the
information about the BGP routes to the network segment 10.1.1.1/24. It is found that
there are two routes in the signaling VPN and no route in the VPN instance.
Total routes of Route Distinguisher(65029:2995): 2
BGP routing table entry information of 10.1.1.1/24:


From: 11.1.1.1 (11.1.1.1)
Original nexthop: 12.1.1.1
Ext-Community: <65029 : 2995>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid,
internal, best, pre 255
Originator: 12.1.1.1
Cluster list: 11.1.1.1

From: 11.1.1.2 (11.1.1.2)
Ext-Community: <65029 : 2995>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid,
internal, pre 255
Originator: 12.1.1.1
Cluster list: 11.1.1.2
5. Run the display current-configuration configuration vpn-instance vpn-instance-name

command on PE1 to view the configurations of the VPN instance. It is found that route
restriction is configured in the signaling VPN of PE1.
ip vpn-instance ngn-signal
route-distinguisher 65029:2995
apply-label per-instance
routing-table limit 100 80
vpn-target 65029:2995 export-extcommunity
vpn-target 65029:2995 import-extcommunity
6. Run the display ip routing-table vpn-instance vpn-instance-name statistics command

on PE1 to view the statistics on the routes of the VPN instance. It is found that the
number of the routes of the VPN instance exceed the threshold of route restriction.
Proto total original active original added deleted freed
routes routes routes active routes routes routes
DIRECT 10 10 10 10 10 0 0
STATIC 1 1 1 1 2 1 1
RIP 0 0 0 0 0 0 0
OSPF 8 8 6 6 13 5 5
IS-IS 0 0 0 0 0 0 0
BGP 81 81 34 34 0 0 0
Total 100 100 51 51 25 6 6
The number of actual VPN instance routes exceeds the threshold of route restriction.
Therefore, new VPN instance routes from PE2 cannot be added to the VPN routing table
on PE1. As a result, the AG cannot register with the softswitch.
Procedure
Step 1 Run the system-view command on PE1 to enter the system view.
Step 2 Run the ip vpn-instance vpn-instance-name command on PE1 to enter the VPN instance
view.
Step 3 Run the routing-table limit 200 80 command on PE1 to re-configure the maximum number
of routes supported by the current VPN instance.
After the preceding operations, CE2 can be pinged successfully from CE1, and CE1 can
register with CE2. The fault is rectified.
----End

Summary
If the maximum number of routes supported by the VPN instance is configured, you need to
check whether the actual routes in an VPN instance exceed the configured upper threshold.
6.14.18 Users Attached to a CE Cannot Access the Internet After

BGP/MPLS IP VPN Services Are Deployed
NOTE
Fault Symptom
As shown in Figure 6-49, a PE is connected to an SPE and the SPE is connected to a UPE to
form a layered network. Each PE is deployed with multiple VPN instances, each of which
configured with multiple export RTs and import RTs. The PE is configured with logical
interfaces, each of which is bound to a VPN instance and connected to the firewall. The SPE
delivers default routes of each VPN instance to the UPE to guide the forwarding of traffic sent
from the CE to the SPE. After the configurations, users attached to the CE cannot access the
Internet.
Figure 6-49 Networking diagram of the case where users attached to a CE cannot access the
Internet
PE Firewall
Internet
SPE
UPE
CE
Fault Analysis
1. Run the display ip routing-table vpn-instance command on the UPE. Each VPN
instance has learned two default routes.

2. Run the display current-configuration configuration vpn-instance command on the

UPE to view the configurations of VPN instances. Each VPN instance has been
configured with multiple export RTs and import RTs.
3. Run the display current-configuration configuration vpn-instance command on the
SPE to view the configurations of VPN instances. RTs of two VPN instances are the
same, and therefore the default routes learned from two VPN instances are advertised to
the UPE through the same export RT. In addition, the export RT matches multiple import
RTs of one VPN instance on the UPE. As a result, the UPE learns multiple default routes
from the same VPN instance. In this case, the traffic received by the SPE from the CE
has multiple BGP next hops, and therefore status entries cannot be created on the
firewall. Consequently, users attached to the CE cannot access the Internet.
Procedure
Step 1 Run the system-view command on the UPE to enter the system view.
Step 2 Run the ip vpn-instance vpn-instance-name command on the UPE to enter the VPN instance
view.
Step 3 Run the vpn-target vpn-target &<1-8> import-extcommunity command on the UPE to
configure VPN-target extended community attribute for the VPN instance.
Ensure that each VPN instance on the UPE is configured with only one import RT so that only
one default route can be learned. After the preceding operations, users attached to the CE can
access the Internet. The fault is rectified.
----End
Summary
Different from PEs or SPEs, a UPE on a layered network only use default routes to guide
upstream traffic. Therefore, the UPE can be configured with multiple export RTs as required
but should be configured with only one import RT. Otherwise, the fault occurs.
6.14.19 VPNv4 Routes on a PE Cannot Take Effect

NOTE
Fault Symptom
On the network shown in Figure 6-50, three PEs are configured with BGP/MPLS VPN
services. Traffic from a CE is balanced between PE1 and PE2. PE2 is connected to PE1, and
PE1 is connected to PE3 over a Metropolitan Area Network (MAN). After the configurations,
PE1 learns the route to the network segment 10.1.2.0, and the BGP VPNv4 routing table of
PE2 contains this route entry, but the VPN instance routing table of PE2 does not.

Figure 6-50 Networking diagram of the case where VPNv4 routes on a PE cannot take effect
PE3
10.1.2.1/24
MAN
10.1.1.1/24 10.1.1.2/24
PE1 PE2
CE
Fault Analysis
1. Run the display bgp vpnv4 all routing-table command on PE2 to view BGP VPNv4
routes. PE2 has learned the route to the network segment 10.1.2.0 but the route is not
optimal.
Network NextHop MED LocPrf PrefVal 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
*i 10.1.2.0/24 10.1.1.1 100 0 no-
export
2. Run the display ip routing-table vpn-instance vpn1 10.1.2.0 verbose command on

PE2 to view the routing table of the VPN instance.
Routing Table :
vpn1
Summary Count :
1
Destination:
10.1.2.0/24
Protocol: BGP Process ID:
0
Preference: 255 Cost:
0
NextHop: 10.1.1.1 Interface:
NULL0

RelayNextHop: 0.0.0.0 Neighbour:

10.1.1.1
Label: 109568 Tunnel ID:
0x0
SecTunnel ID:
0x0
BkNextHop: 0.0.0.0
BkInterface:
BkLabel: NULL Tunnel ID:
0x0
SecTunnel ID:
0x0
State: Inactive Adv WaitQ Age:
22h35m37s
The preceding routing information shows that the outbound interface of the next hop is
Null0, and therefore packets are discarded.
If VPNv4 routes are used to forward traffic, LSP labels of the public network will be
added to the routes. Before adding a VPNv4 route to the routing table of a VPN instance,
the system checks whether the route contains a corresponding LSP label of the public
network. If no such LSP label corresponding to the VPNv4 route exists, the route will
not be added to the routing table.
3. Run the display mpls lsp command on PE2. No route to 10.1.1.1 is displayed, indicating
that no neighbor relationship has been established between PE1 and PE2.
Procedure
Step 2 Run the mpls command to enable MPLS and enter the MPLS view.
Step 4 Run the mpls ldp command to enable LDP globally and enter the MPLS LDP view.
Step 5 (Optional) Run the lsr-id lsr-id command to set the LSR ID for the LDP instance.
Step 7 Run the interface interface-type interface-number command to enter the view of the interface
connecting PE1 to the peer.
Step 8 Run the mpls command to enable MPLS on this interface.
Step 9 Run the mpls ldp command to enable LDP on this interface.
Perform all the preceding operations on PE2. After the operations, PE1 will have learned the
route to the network segment 10.1.2.0 and both the BGP VPNv4 routing table of PE2 and the
routing table of the VPN instance have routes to the network segment 10.1.2.0. The fault is
rectified.
----End
Summary
If VPNv4 routes are used to forward traffic, LSP labels of the public network will be added to
the routes. Before adding a VPNv4 route to the routing table of a VPN instance, the system
checks whether the route contains a corresponding LSP label of the public network. If there is
no such LSP label corresponding to the VPNv4 route, the route will not be added to the
routing table.

6.14.20 MPLS VPN Convergence Is Slow

NOTE
Fault Symptom
The protocols of IS-IS and BGP and MPLS VPN services are configured on six PE devices.
All the PEs use the same RD; PE1 and PE2 serve as RRs. The router ID of PE1 is smaller
than that of PE2; the router ID of PE3 is smaller than that of PE4; the router ID of PE5 is
smaller than that of PE6. The two CEs belong to the same VPN.
Figure 6-51 Typical Network Diagram for MPLS VPN
PE1 PE2
PE3 PE4 PE5 PE6
CE1 CE2
After PE3 is restarted, PE5 and PE6 have to wait for 2 minutes before learning the route to the
segment where CE1 resides.
Fault Analysis
PE5 and PE6 learn two equal-cost MPLS VPN routes to CE1 through PE3 and PE4. IGP
selects the route passing through PE3 as the optimal route to CE1 because the router ID of
PE3 is smaller than that of PE4.
After PE3 is restarted, the two RRs (PE1 and PE2) forward another route to the segment
where CE1 resides to PE5 and PE6 when confirming that they cannot establish BGP neighbor
relationships with PE3. After IGP convergence is complete, MPLS VPN convergence starts.
MPLS VPN convergence is rather slow because its time depends on the number of routing
entries in the routing tables of the routers. Usually, MPLS VPN convergence takes about 2
minutes.

Procedure
Step 2 Run the ip vpn-instance vpn-access command to enter the view of the corresponding VPN
instance.
Step 3 Run the route-distinguisher 22:1 command to change the RD for the VPN instance on PE3
to be different from that on the other PEs.
After the configuration, PE5 and PE6 learn two MPLS VPN routes with different next hops to
CE1 through PE3 and PE4. One of the routes is active, and the other is inactive.
When PE3 is restarted again, the active route is removed from the MPLS VPN routing table.
In this case, the inactive route quickly switches to be an active route without waiting for the
finding of a reachable IGP route. Therefore, the convergence speed is rather quick. The fault
is rectified.
----End
Summary
MPLS VPN convergence may become slow due to slow IGP convergence. In this case, you
can set different RDs on PEs to configure two MPLS VPN routes for backup or alternatively
configure VPN FRR to rectify the fault.
6.14.21 One-way Audio Occurs Between the CEs Because the vpn-
target import-extcommunity Command Is Not Configured
NOTE
Fault Symptom
On the network shown in Figure 6-52, each CE (UMG) is dual-homed to two PEs. The PEs
on the network belong to different planes:
l PE1 and PE2 belong to plane A.

l PE3 and PE4 belong to plane B.
In normal situations, the traffic between the CEs, which are in the same VPN, is transmitted
on plane B.
Different VPN instances are configured on the PEs to separately carry signaling traffic and
media traffic between the CEs.
When the configuration is complete, call tests are conducted. In the first try, one-way audio
occurs: Voices from Phone1 can be heard on Phone2, but voices from Phone2 cannot be heard
on Phone1. In the second try, voices can be heard on both phones.

Figure 6-52 Networking diagram of one-way audio between the CEs
Network
CE 1 CE 2
(UMG1) PE 1 PE 2 (UMG2)
Plane A
Plane B
PE 3 PE 4
Network
Phone1 Phone2
Fault Analysis
1. Calls can be successfully set up between the CEs, it indicates that the problem is not on
the VPN instance bearing signaling traffic but on the VPN instance bearing media traffic
between the CEs.
2. Run the display current-configuration configuration vpn-instance command on PE3
to check the configurations of the VPN instance bearing media traffic. You can find that
the vpn-target import-extcommunity command is not configured.
As a result, PE3 does not receive the VPN route that is used to transmit media traffic
from PE4. So, the media traffic from CE2 is not sent to CE1. That is the reason why
there is one-way audio from Phone1 to Phone2 in the first call try.
On the CE side, media traffic is sent to both the PEs to which the CE is dual-homed. In
the first call, media traffic is transmitted on plane B. Once the transmission on plane B
has problems (that is, one CE does not receive the traffic from the other CE), media
traffic enters plane A for transmission in the next dial-up. That is the reason why voices
can be heard on both Phone1 and Phone2 in the second call try.
Procedure
Step 1 Run the system-view command to enter the system view on PE3.
Step 2 Run the ip vpn-instance vpn-instance-name command to enter the view of the VPN instance
that carries the media traffic between the CEs.
Step 3 Run the vpn-target vpn-target &<1-8> import-extcommunity command to configure VPN-
target of the extended community attribute to receive the routing information that carries the
specified VPN-target.
When the configuration is complete, the audio communication between Phone1 and Phone2 is
normal in call tests.
----End

Summary
In the application of BGP/MPLS VPN on the Next Generation Network (NGN), different
VPN instances are used to separately bear signaling traffic and media traffic. If a fault occurs,
first determine based on the fault symptom whether it is due to the VPN instance bearing
signaling traffic or the VPN instance bearing media traffic.
In addition, VPN-target has no default value. Therefore, you need to manually configure
VPN-target when creating a VPN instance. You can specify "both", "export", or "import" to
associate a VPN instance with one or more VPN-targets. By default, "both" is used.
6.14.22 PEs Fail to Exchange Private Network Routes Because the

Mask Set for the Loopback Interface Is Not a 32-bit Mask
NOTE
Fault Symptom
On the network shown in Figure 6-53, BGP/MPLS IP VPN services and OSPF are
configured on the two PEs and the P. A loopback interface is created on each PE and bound to
a VPN instance named vpn1. The IP address of the loopback interface on PE1 is 1.1.1.1; the
IP address of the loopback interface on PE2 is 1.1.1.2.
When the configuration is complete, the two PEs cannot exchange private network routes, and
the ping between them fails.
Figure 6-53 Networking diagram for the failure in exchanging private network routes
between PEs
Loopback1 Loopback1
GE1/0/2 GE1/0/1
PE 1 PE 2
GE1/0/2 GE1/0/1
P
Fault Analysis
1. Run the display ospf peer command on each PE, and you can view that the neighbor
status is Full. Run the display ip routing-table command on each PE, and you can view
that each PE has learned the route to Loopback1 on the peer PE.
2. Run the display mpls ldp session command on the P. You can view that the LDP peer
relationships between the P and PEs are established.
3. Run the display mpls lsp command on both PEs to check label allocation. You can find
that the PEs have LSPs to each other.

4. Run the display this command in the BGP-VPNv4 address family view on each PE. You
can find that the peer ipv4-address enable command has been configured. Run the
display bgp vpnv4 all peer command on each PE. You can find that the BGP peer
relationships are established between the PEs and between the PE and CE.
5. Run the display ip routing-table vpn-instance vpn1 command on each PE to check the
VPN routing table. A route, 1.1.1.0/24 direct, with Loopback1 being the outbound
interface, is found in the routing table. The mask of the route is a 24-bit value rather than
a 32-bit value.
1.1.1.0/24 Direct 0 0 D 1.1.1.1 LoopBack1
6. Run the display ip interface brief command on each PE. You can find that a 24-bit
mask (not a 32-bit mask) is configured for the IP address of Loopback1.
Interface IP Address/Mask Physical Protocol
LoopBack1 1.1.1.1/24 up up(s)
In this manner, the IP addresses of loopback interfaces on the two PEs belong to the
same network segment (1.1.1.0/24). In fact, the PEs have learned private network routes
from each other. On each PE, the learned private network route and local Loopback1,
however, belong to the same network segment. Then, there are two routes to Loopback1
on the peer PE: One is a direct route; the other is a BGP route. In this case, the PE places
the direct route in its routing table, and there are no private network routes in the VPN
routing table. As a result, Loopback1 on the peer PE fails to be pinged.
Procedure
Step 2 Run the interface loopback1 command to enter the view of Loopback1 bound to the VPN
instance.
Step 3 Run the ip address ip-address { mask | mask-length } command to configure an IP address
with a 32-bit mask on each PE.
When the configuration is complete, the PEs can successfully ping Loopback1 on each other,
and the fault is rectified.
----End
Summary
When configuring BGP/MPLS IP VPN services, ensure that the IP addresses of the interfaces
bound to the same VPN instance but residing on different PEs belong to different network
segments.
6.14.23 Some MPLS VPN Services on a Device Become Abnormal

After the Service Cutover
Fault Symptom
On the carrier's MAN shown in Figure 6-54, all devices except Router A are non-Huawei
devices. Router C and Router D (two non-Huawei devices) function as MAN's egress core
routers at Site A and Site B respectively. The total outbound bandwidth of the egress device of

the MAN is 3 x 2.5 GB. The bandwidth of the link from Router C at Site A to Router A on the
backbone network is 1 x 2.5 GB, and the bandwidth of the link from Router D at Site B to
Router B on the backbone network is 2 x 2.5 GB. Outbound bandwidths of Router E to
Router A and Router G to Router B are both 2 x 10 GB.
Figure 6-54 Networking of the MAN before service cutover
Backbone
RouterA RouterB network
MAN
Site A Site B
RouterD
RouterC
10G
2.5G
The carrier optimizes the MAN and the backbone network to better facilitate the growing
service requirements. As shown in Figure 6-55, backbone nodes Router A and Router B
function as MAN's egress core routers and directly establish EBGP peer relationships with
Router E and Router G on the backbone network respectively. Router C and Router D
(previously core routers on the MAN) are removed from the networking for other purpose.
The MAN continues to use the private AS number. The IBGP peer relationship is established
between Router A and Router B (two core routers on the MAN). The SR and the BRAS that
are previously attached to Router C and Router D respectively are now attached to Router A
and Router B respectively.

Figure 6-55 Networking of the MAN after service cutover
Backbone
network
MAN
Site B
Site A RouterB
RouterA
10G
2.5G
As shown in Figure 6-56, after service cutover, service tests are performed on Router A. It is
found that MPLS VPN services of some users in the same VPN instance work normally but
some MPLS VPN services on the BRAS become abnormal.

Figure 6-56 Networking of the MAN during service cutover
Backbone
RouterB network
MAN
Site B
Site A RouterD
RouterA
10G
2.5G
Fault Analysis
1. Run the display current-configuration configuration command on Router A to check
current configurations, and you can find that current configurations are correct.
2. Check configurations about the interface MTU and the BRAS on Router A, and you can
find that these configurations are correct.
3. Run the ping lsp -a source-ip command (source-ip specifies the loopback interface
address of Router A) on Router A to ping the loopback interface address of the BRAS.
The ping succeeds, indicating that packet forwarding between Router A and the BRAS is
normal.
4. Run the ping lsp -a source-ip command (source-ip specifies the loopback interface
address of the BRAS) on the BRAS to ping the loopback interface address of the
inaccessible PE in the VPN. It is found that the ping fails.
5. Run the display mpls ldp peer command on the BRAS to check information about LDP
peers. You can find that the address used to establish the LDP peer relationship between
Router D and the BRAS is the address of Loopback1 rather than Loopback0. Because
customers have special requirements, the address of Loopback1 on Router C is set to the
same as the address of Loopback1 on Router A.

6. Run the display mpls ldp peer command on Router A to check information about LDP
peers. You can find that the address used to establish the LDP peer relationship between
Router D and Router A is also the address of Loopback1 rather than Loopback0.
7. Run the display current-configuration configuration command on Router D to check
current configurations. You can find that the address of Loopback1 is mistakenly used to
establish the LDP peer relationship on Router D. The fact is that the address of
Loopback0 should be used to establish the LDP peer relationship on Router D. As a
result, some MPLS VPN services forwarded by Router D cannot be accessed. Before
service cutover is implemented on Router A, traffic is transmitted through previous core
routers on the MAN. During service cutover, the traffic is switched to Router D. After
service cutover, the traffic is not switched back to Router A, therefore causing the fault.
Procedure
Step 1 Set the address of Loopback0 as the address used to establish the LDP peer relationship on
Router D.
----End
Summary
The major cause of the fault is that MPLS LSP forwarding is abnormal. If the fault occurs,
run the ping lsp commands with source addresses on the PEs to ping each other.
6.15 VPLS Troubleshooting

This chapter describes common causes of VPLS faults and provides the corresponding
6.15.1 VPLS Services Fail

NOTE
Fault Symptom
As shown in Figure 6-57, after a Huawei device replaces another vendor's device and
functions as PE1, only VPLS services fail.

Figure 6-57 Networking diagram of Martini VPLS
Outbound Inbound
MAN
CE2
PE1 PE2
CE1 （Huawei device） (Another vendor's device)
Server
Martini VPLS
Fault Analysis
NOTE
After a Huawei device replaces another vendor's device, only VPLS services fail. You can exclude the
possibility of a link failure or the failure of another device.
1. Run the display current-configuration command on PE1 to check whether the

configurations are correct and consistent with those of PE2. You can find that
configurations of PE1 are correct and consistent with those of PE2.
2. Run the display vpls connection command on PE1 to check the VCState field. You can
find that VCState is Up, indicating that a Layer 2 tunnel is established.
3. When CE1 pings Server, run the display traffic-statistics vsi vsi-name [ peer peer-
address [ negotiation-vc-id vc-id ] ] command on PE1 to check whether the packet
sending and receiving process is normal. You can find that packets can be correctly sent
and received.
4. When CE1 pings Server, you can obtain VPLS packets in the inbound and outbound
directions of PE1 on another device of the MAN.
A obtained VPLS packet in the inbound direction of PE1 is shown as follows:
0018 821D 2010 0014 1CD2 FC06 8847 22C0
01FE 0019 E019 0D9E 0019 21D5 5FD6 0806
0001 0800 0604 0002 0019 21D5 5FD6 0303
0301 0019 E019 0D9E 0303 0302 0000 0000
As indicated by the 0806 field, the obtained VPLS packet sent from PE2 carries no
VLAN tag and is just a common ARP packet. PE1 and PE2, however, are configured
with the encapsulation mode of VLAN, causing PE1 to add a VLAN tag to the VPLS
packet. After adding a VLAN tag to the VPLS packet, PE1 forwards the packet in the
outbound direction.
A obtained VPLS packet in the outbound direction of PE1 is shown as follows:
0019 E019 0D9E 0019 21D5 5FD6 8100 019b
0800 0604 0002 0019 21D5 5FD6 0303 0301
0019 E019 0D9E 0303 0302 0000 0000 0000
You can find that PE1 replaces the 0806 field (ARP packet identifier) with the 8100 field
(VLAN packet identifier). As a result, VPLS services fail. If the VLAN encapsulation
mode of PE2 (another vendor's device) is modified to send VLAN tags, or PE1 and PE2
are configured with the encapsulation mode of Ethernet, the fault can be rectified.

Procedure
l Solution 1: Modify the VLAN encapsulation mode of another vendor's device to send
VLAN tags.
l Solution 2: Change the encapsulation mode on PE1 and PE2 to Ethernet. The Huawei
device (PE1) can be configured as follows:
b. Run the vsi vsi-name command to enter the VSI view.
c. Run the encapsulation ethernet command to set the VSI encapsulation mode as
Ethernet.
After the preceding configurations, CEs can ping each other successfully, and VPLS
services become normal.
----End
Summary
Why can the Layer 2 tunnel be Up when PE1 has incorrectly parsed packets?
To answer this question, check the configurations of PE2. You can find that the VPLS sending
and receiving on PE2 is in the hybrid mode. That is, PE2 can process any types of packets;
when receiving a VPLS packet carrying a VLAN tag, PE2 removes the VLAN tag and then
forwards the VPLS packet. This is the cause for the problem.
As defined by RFC 4448, if a packet transmitted on a PW is encapsulated to the tagged mode,

the packet must carry a VLAN tag.
6.15.2 VSIs Cannot Be Up in LDP Signaling Mode

NOTE
Fault Symptom
Figure 6-58 Networking diagram of VPLS

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS2/0/0 POS2/0/0
168.1.1.1/24 169.1.1.1/24
PE1 PE2
POS1/0/0 POS1/0/0
Ethernet1/0/0 168.1.1.2/24 P 169.1.1.2/24 Ethernet2/0/0
CE1 CE2

VPLS in LDP signaling mode is configured on both PE1 and PE2. After the configuration, the
VSI on both PEs cannot be Up.
Then PE1 initiates CE-Ping to detect the IP address of CE2, but the detection fails. Locating
the fault, you find that the VSI cannot go Up.
Fault Analysis
1. Check the VSI status on PE1 and PE2.
Run the display vsi verbose command.
The display on PE1 is as follows.
VSI Name : v1
VSI Index : 0
PW Signaling : ldp
Member Discovery Style : static
PW MAC Learn Style : unqualify
Encapsulation Type : vlan
MTU : 1500
VSI State : down
Resource Status : Valid
VSI ID : 1
*Peer Router ID : 3.3.3.9
VC Label : 17409
Session : up
Tunnel ID : 0x6002002,
Interface Name : Ethernet1/0/0
State : up

VSI Name : v1
VSI Index : 0
PW Signaling : ldp
MTU : 1500
VSI State : down
VSI ID : 1
*peer Router ID : 2.2.2.9
VC Label : 17408
Session : up
State : up
ACs on both ends are Up. The tunnel on both ends of a PW is in existence, and the
tunnel ID is not 0x0.
2. According to the displayed PW information, you can find that the designated remote
LDP peer of the PE2 is not correct. It should be 1.1.1.9 rather than 2.2.2.9. Then modify
the peer.
Procedure
Step 1 Run the display vsi verbose command on PEs.
Step 2 Check the status of VSI and AC. Find that the VSI is Down, but AC is Up.
Step 3 Check the status of the PW. Find that the PW cannot be set up.

Step 4 Check whether the tunnel is available. Find that the tunnel is ready.
Step 5 Find that the designated remote LDP peer of the PE2 is not correct according to the displayed
PW information. The incorrectness makes the PW establishment failed. It should be
designated as 1.1.1.9 rather than 2.2.2.9. Modify the peer.
Step 6 Reconfigure the remote LDP peer of the PE2, which means to designate it as 1.1.1.9. Then the
PW is established successfully.
----End
Summary
If the signaling protocol is LDP and the VSI cannot be Up, the errors related to the peer are as
follows:
l The peer is specified incorrectly.
l The address of the peer is not the peer LSR-ID. The LDP remote session then cannot be
established.
l The LSR-ID of the peer is re-defined. Then the LDP remote session cannot be set up.
If a VSI is Up, there must be at least two ACs are Up, or at least one AC is Up and one PW is
Up.
To locate the fault, you can check the status of the AC and PW first.
l It is simple to let an AC go Up. You must bind the AC with a physical interface, and the
line protocol state of the interface must be Up.
l There are many conditions for a PW to go Up, such as the correct configurations of
MTU, encapsulation type, VSI ID, and remote peer. The key is that the local and the
remote ends can receive labels from each other.
You can run the display vsi remote { ldp | bgp } command to find which device is faulty
according to the label receiving.
6.15.3 Packets Cannot Be Forwarded Successfully Between Two

PEs Though VSIs Are Up
NOTE
Fault Symptom
After configuring VPLS, check the VSI status on PEs. You find that both VSIs are Up, but the
packets cannot be forwarded successfully between two PEs.
Fault Analysis
1. Check whether the PW is available.
Run the display vsi verbose command to check whether the PW is available.
If the PW is not available, check whether the delivering status of the PW is "up", as
shown below:

– If the status is not "up", it shows that the forwarding information is not delivered to
the interface board, which leads to the failure of the forwarding.
– If the status is "up" but the forwarding still fails, check the operating status of the
interface board.
2. Check the MAC limit.
If the PW is available, but packets cannot be forwarded between PEs, run the display
current-configuration | begin vsi vsi-name command to check the MAC limit. If the
number of MAC address entries exceeds the MAC limit, re-configure the MAC limit.
3. Check whether the BGP peer is reestablished.
If the number of MAC address entries does not exceed the MAC limit, run the display
bgp peer peer-address command to check whether the BGP peer is set up. When the
BGP peer is being re-established, the VSI status remains Up in this short period.
4. Check the encapsulation types of PEs on both ends.
If the BGP peer is set up, run the display current-configuration | begin vsi vsi-name
command to check the encapsulation types of PEs on both ends. If the types are
different, re-configure them to be the same.
If the fault persists, contact Huawei technical support personnel.
Procedure
Step 1 Run the display vsi command to check whether the status of the PW is up.
Step 2 Run the display vpls connection command to check whether the PW is available.
Step 3 If the status is "up", check whether the operating status of the interface board is normal.
----End
Summary
The fault occurs when one of the following conditions is met:
l The PW information is not delivered to the forwarding chip.

l The number of MAC address entries exceeds the MAC limit.
l When the BGP peer is being re-established, the VSI state remains Up in this short
period.
l The encapsulation types on PEs of both ends are different.
6.15.4 VSIs Cannot Be Up in BGP Signaling Mode

NOTE
Fault Symptom
PE1 and PE2 establish IBGP, and are configured with VSIs respectively. After the
configuration, you find that VSIs on both PEs cannot go Up.


1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS2/0/0 POS2/0/0
168.1.1.1/24 169.1.1.1/24
PE1 PE2
POS1/0/0 POS1/0/0
CE1 CE2
Fault Analysis
1. Check the VSI status on PE1 and that on PE2.
***VSI Name : bgp1
VSI Index : 0
PW Signaling : bgp
Member Discovery Style : auto
MTU : 1500
VSI State : down
BGP RD : 1:1
SiteID/Range/Offset : 1/10/0
Import vpn target : 2:2,
Export vpn target : 2:2,
Local Label Block : 19456/10/0,
State : up
***VSI Name : bgp1
VSI Index : 0
PW Signaling : bgp
MTU : 1500
VSI State : down
BGP RD : 1:2
State : up
2. Check whether PEs can receive the remote label.
Run the display vsi remote bgp command on PE1 and PE2. No information is
displayed, which indicates that PEs have not received the remote label.

In this case, the BGP configuration may be faulty.
Procedure
Step 1 Check the AC status on both PEs, finding that both ACs are Up.
Step 2 Run the display vsi remote bgp command, and find no display. This indicates that the label is
not received.
Step 3 Check whether the VPN targets match.
Step 4 If the VPN targets match, check whether a tunnel is available.
Step 5 If the tunnel is available, run the display bgp peer command to check whether the BGP
neighbor relationship is established.
Step 6 If the BGP neighbor relationship is set up, run the display bgp vpls all command to check
whether the remote label block is received.
Step 7 If the remote label block is not received, check the BGP configuration. You can find that the
VPLS address family is not configured. After configuring the VPLS address family, you can
rectify the fault.
----End
Summary
VPLS in BGP mode and VPLS in LDP mode are configured differently. The major difference
is that VPLS address family need to be configured, and the peer in the address family need to
be enabled in BGP mode.
When using the BGP signaling, check whether the BGP VPLS peer is specified and the
remote label block can be received. The VSI status is still determined by the status of the AC
and PW. In addition, you need to pay attention to the setting of the encapsulation type and
MTU.
6.15.5 PEs Cannot Interwork Though VSIs Are Up

NOTE

Fault Symptom

1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS2/0/0 POS2/0/0
168.1.1.1/24 169.1.1.1/24
PE1 PE2
POS1/0/0 POS1/0/0
CE1 CE2
VPLS in BGP mode is configured on PE1 and PE2. Although VSIs go Up, PEs cannot
interwork.
Fault Analysis
1. Check the VSI status on PE1 and PE2.
The display on PE1 is as follow:
***VSI Name : v1
VSI Index : 0
PW Signaling : bgp
MTU : 1500
VSI State : up
BGP RD : 168.1.1.1:1
Remote Label Block : 141293/10000/0,
Interface Name : Vlan100
State : up
*Peer Ip Address : 3.3.3.9
PW State : up
Local VC Label : 140289
Remote VC Label : 141296
PW Type : label
Local VCCV : alert lsp-ping
Remote VCCV : alert lsp-ping
Tunnel ID : 0x1009,
PW Type : label
Tunnel ID : 0x1009,
The display on PE2 is as follows:

***VSI Name : v1
VSI Index : 0

PW Signaling : bgp
Encapsulation Type : ethernet
MTU : 1500
VSI State : up
BGP RD : 169.1.1.2:1
Remote Label Block :, 140288/10000/0
Interface Name : Vlan100
State : up
PW State : up
PW Type : label
Tunnel ID : 0x1009,
The status of ACs on both ends is Up. Check the PW information on PE and find the
tunnel information exists. The tunnel ID is not 0x0. See the display of Tunnel ID as
above.
2. Run the display vsi remote bgp command on PE2.
The display is as follows:
Total Number : 1
**BGP RD : 169.1.1.2:1 Number : 1
NextHop : 200.200.200.12
EncapType : vlan
MTU : 1500
SiteID : 3
Remote Label Block : 140288/10000/0,
The preceding display shows that after receiving a VPLS packet, PE2 assumes that the
encapsulation type of this packet is ethernet. However, according to Step 1, the
encapsulation type of the VPLS packet sent by PE1 is vlan. PE1 and PE2 cannot agree
on the encapsulation type of the VPLS packet. PEs, hence, cannot interwork.
Procedure
Step 1 Run the display vsi verbose command on PEs.
Step 2 Check VSI and AC, finding that both are in the Up state.
Step 3 Check whether the tunnel is available, finding that the tunnel is ready.
Step 4 Run the display vsi remote bgp command on one PE to check the encapsulation type of the
VPLS packet to be received by the PE, finding that the encapsulation type is different from
that sent by the peer PE.
----End
Summary
The sender and the receiver should agree on the encapsulation type of the VPLS packet.
Otherwise, interworking between PEs cannot be realized when a Huawei device
communicates with a non-Huawei device.

6.16 QoS
6.16.1 Packets Are Not Discarded After Traffic Policy Is

Configured
NOTE
Fault Symptom
On the network shown in Figure 6-61, two ACL rules in a traffic policy is configured in
sequence on GE 1/0/0 of the router to implement the following functions:
l Discards UDP packets with the destination address being 10.1.1.1/30 and interface
numbers smaller than 1023.
l Applies a CAR policy to other packets with the destination address being 10.1.1.1/30
and interface numbers equal to or larger than 1023 to limit the transmission rate to 400
Mbit/s.
After the configurations, the router applies the CAP policy to the UDP packets with the
destination address being 10.1.1.1/30, therefore implementing traffic control; however, it does
not discards the UDP packets with the destination address being 10.1.1.1/30 and interface
numbers smaller than 1023.
Figure 6-61 Packets not discarded after traffic policy is configured
GE1/0/0
Network
Router
Fault Analysis
1. Run the display current-configuration command to check the global configurations of
acl and traffic policy. The configurations are as follows:
acl 3010 match-order auto
rule 5 permit ip destination 10.1.1.1 0.0.0.3
acl 3011
rule 5 permit udp destination 10.1.1.1 0.0.0.3 destination-port lt 1023
traffic classifier c1 operator or
if-match acl 3010
if-match acl 3011
traffic behavior b1

car cir 400000 cbs 400000 pbs 0 green pass yellow pass red discard
traffic behavior b2
deny
traffic policy tp
classifier c1 behavior b1
traffic-policy tc inbound
2. The command output shows that UDP packets first attempt to match the ACL rule
associated with the classifier that is first configured in a traffic policy. After the UDP
packets match the ACL rule, the packets do not match the other ACL rule. In this case,
the UDP packets with the destination address being 10.1.1.1/30 and the interface number
smaller than 1023 match ACL 3010, allowing the traffic limit to take effect on the
packets. After this, the UDP packets, however, do not match the other ACL rule and
therefore are not discarded.
Procedure
Step 1 Run the undo traffic-policy inbound command in the interface view to delete the associated
policy applied to an interface.
Step 3 Run the undo traffic policy tp command to delete the traffic policy.
Step 4 Run the traffic policy tp command to create a traffic policy and enter the traffic policy view.
Step 5 Run the classifier c2 behavior b2 command and then the classifier c1 behavior b1 command
to change the sequence for applying ACL rules in the traffic policy.
Step 6 Run the traffic-policy policy-name inbound command to apply the associated policy on the
interface.
After the preceding operations, the UDP packets with the destination address being
10.1.1.1/30 and the interface numbers smaller than 1023 are discarded, traffic control is
performed on other packets with the destination address being 10.1.1.1/30. The fault is then
rectified.
----End
Summary
The sequence for applying ACL rules must be correct. During traffic classification, packets
match the ACL rules in the sequence from an ACL associated with the classifier that is first
configured in a traffic policy. If the packets match an ACL rule, the packets are processed
based on the ACL rule and do not match other ACL rules.
When configuring a traffic policy, ensure that the sequence in which traffic classifiers are
applied is correct.
6.16.2 Packets of VPN Services Are Lost Because the IP

Precedence of a Device Is Incorrectly Set
NOTE

Fault Symptom
On the network shown in Figure 6-62, Layer 3 MPLS VPN is run between the router and the
switch, and the Soft 3000 belongs to the Layer 3 MPLS VPN. The router and the switch are
configured with QoS to protect services. After the configuration, it is found that packet loss
occurs when Switch A pings the Soft 3000 and the other services are normal.
Figure 6-62 Diagram of the networking where packets of VPN services are lost because the
IP precedence of a device is Incorrectly set
Soft 3000 Router Switch A
Switch B
Fault Analysis
1. Run the display current-configuration command on the router to check the current
configuration.
acl number 10001
rule ip
traffic classifier any-ngn
if-match acl 10001
traffic behavior action-ef
remark ip-precedence 4
traffic policy eacl-ef
classifier any-ngn behavior action-ef precedence 0
port-queue af4 shaping 10 outbound
port-queue ef shaping 100 outbound
trust upstream default
The command output shows that the IP precedence value is set to 4 (corresponding to
AF4), the committed bandwidth for AF4 on the interface is 10 Mbit/s, and packet loss
occurs when the traffic volume is greater than 10 Mbit/s. In this case, the volume of
NGN traffic on Switch A exceeds 10 Mbit/s.
2. Run the display port-queue statistics interface gigabitethernet 1/0/0 af4 outbound
command. You can find that a large number of packets in the AF queue are discarded.
[af4]
Current usage percentage of queue: 0
Total pass:
0 packets, 0 bytes
Total discard:
13,608,926
packets, 39,502,685,409 bytes
Drop tail discard:
0 packets, 0 bytes

Wred discard:
0 packets, 0 bytes
Last 30 seconds pass rate:
453,631 pps,
1,316,756,180 bps
Last 30 seconds discard rate:
0 pps, 0 bps
Drop tail discard rate:
0 pps, 0 bps
Wred discard rate:
0 pps, 0 bps
Peak rate:
0000-00-00 00:00:00 0 bps
The command output shows that the IP precedence value of the router is set to 4
(corresponding to AF4) and packet loss occurs when the traffic volume exceeds 10
Mbit/s. As a result, packet loss occurs when Switch A pings the Soft 3000.
Procedure
Step 2 Run the traffic behavior behavior-name command to enter the traffic behavior view.
Step 3 Run the remark ip-precedence 5 command to re-mark the IP precedence and specify the ToS
of VPN NGN services to EF.
After the preceding operations, the IP precedence value is set to 5, which corresponds to EF
set with the port-queue ef shaping 100 outbound command on the interface. Therefore, the
committed bandwidth of VPN NGN services is changed to 100 Mbit/s.
----End
Summary
After the remark ip-precedence precedence command is run on a device, the device maps
the re-marked IP precedence with a ToS.
The mappings between IP precedences and ToSs are as follows:
0 be
1 af1 green
2 af2 green
3 af3 green
4 af4 green
5 ef green
6 ef green
7 ef green

6.16.3 Slow Web Page Loading for Some ADSL Users

NOTE
Fault Symptom
On the network shown in Figure 6-63, ADSL users access the Internet either by directly
dialing through a modem on PCs or by using a broadband router as an agent dialer connected
to a modem. After the configuration, when ADSL user access the Internet by using the agent
dialer, Web pages are loaded during a period from 17:00 to 23:30 slower than during daytime
and some Web pages fail to be loaded. When ADSL users access the Internet by dialing
through a modem, Web pages are loaded at a normal rate.
Figure 6-63 Networking diagram of slow web page loading for some ADSL users
I n t e r ne t
RouterA
Broadband
Access Router
Modem Modem
User User User User
Fault Analysis
1. After packets are obtained, information shows that the port numbers used by ADSL users
dialing through a modem range from 1000 to 10000, but the port numbers used by
ADSL users dialing through an agent dialer are translated by NAT into port numbers
larger than 10000.
2. Run the display current-configuration command on the device to check the traffic limit
configured on the interface. The command output shows that a P2P traffic policy has

been configured. Based on the traffic policy, the transmission rate of services with the
interface number larger than 10000 is within 20 Mbit/s. In this case, insufficient
bandwidth causes slow Web page loading when ADSL users dialing through an agent
dialer attached to the modem access the Internet during the period from 19:00 to 23:30.
Procedure
Step 3 Run the undo traffic-policy { inbound | outbound } command to delete the traffic policy.
After the preceding operations, allowing the ADSL users using the agent dialer to experience
normal Web pages loading. The fault is rectified.
----End
Summary
Do check interface numbers used for transmitting a service before setting a traffic limit for the
service. In addition, if the service passes through a NAT device, such as a firewall or a NAT-
enabled router, consider the impact of the NAT process before setting the traffic limit,
preventing an incorrect setting from affecting user traffic over an entire network.
6.16.4 Rate Limit Does Not Take Effect When Both Rate Limit and
Access Control Are Configured
NOTE
Fault Symptom
Access control is configured on the Router A to discard UDP packets destined for specific
interfaces and rate limit is configured to limit the rate of the other data packets. After the
configuration is complete, it is found that rate limit does not take effect.
Figure 6-64 Networking diagram for Rate Limit Does Not Take Effect
Network Network
RouterA

Fault Analysis
1. Run the display current-configuration command on the Router A.
acl number 3300
rule 0 deny udp destination-port eq dns
rule 1 deny udp destination-port eq snmp
rule 2 deny udp destination-port eq snmptrap
rule 3 deny udp destination-port eq syslog
traffic classifier udp-limit operator and
if-match acl 3300
traffic behavior udp-limit
car cir 1360000 cbs 1360000 pbs 0 green pass yellow discard red discard
traffic policy udp-limit
classifier udp-limit behavior udp-limit
traffic-policy udp-limit inbound
The preceding command output shows that after a data packet enters an interface, the packet
is matched against ACL rules. If the packet matches an ACL rule whose action is deny, the
packet is discarded. Packets that do not match any ACL rule are directly forwarded.
Therefore, to limit the rate of the data packets that do not match any ACL rule, you need to
add an ACL rule to implement the permit action on these packets. Then, rate limit takes
effect with these data packets.
Procedure
Step 1 Run the undo traffic-policy command in the interface view to cancel the traffic policy that is
applied to the interface.
Step 3 Run the undo traffic policy policy-name command to delete the traffic policy from the
device.
Step 4 Run the traffic behavior udp-limit command to enter the traffic behavior view.
Step 5 Run the undo car command to cancel the configured traffic rate limit.
Step 7 Run the acl [ number ] acl-number command to add an ACL.
Step 8 Run the rule rule-id permit any command to implement the permit action on the packets
other than the UDP packets destined for specific interfaces.
Step 10 Run the traffic classifier classifier-name command to configure a traffic classifier.
Step 11 Run the if-match acl acl-number command to define an ACL matching rule.
Step 13 Run the traffic behavior behavior-name command to configure a traffic behavior.
Step 14 Run the car cir 1360000 cbs 1360000 pbs 0 green pass yellow discard red discard
command to configure a rate limit for the packets that are allowed to pass.

Step 16 Run the traffic policy policy-name command to create a traffic policy and then run the
classifier classifier-name behavior behavior-name command to associate the traffic classifier
with the traffic behavior in the traffic policy.
Step 17 Run the traffic-policy policy-name inbound command on the interface to apply the traffic
policy to the interface.
Step 18 Run the display current-configuration command to check the corresponding configurations.
acl number 3300
acl number 3301
rule 4 permit any
traffic classifier udp-limit operator or
if-match acl 3300
traffic classifier udp-limit1 operator or
if-match acl 3301
traffic behavior udp-limit1
classifier udp-limit1 behavior udp-limit1
interface gigabitEthernet 1/0/0
traffic policy udp-limit inbound
After the preceding operations, both access control and rate limit take effect. The fault is
rectified.
----End
Summary
When configuring access control, you can use the parameter deny to discard packets. The
other packets that are not discarded are directly forwarded without rate limit by default. To
limit the rate of the packets that are not denied, you need to first configure an ACL rule to
allow them to pass. Then, configure traffic behaviors to limit the rate at which these packets
are forwarded.
6.16.5 The DNS Server Cannot Be Accessed Due to Incorrect

Configurations of Traffic Classification
NOTE
Fault Symptom
On the network shown in Figure 6-65, Router A functions as the egress. Rate limit is
configured for UDP packets other than DNS, SNMP, SNMP Trap, and Syslog packets in the
inbound direction of GE 1/0/0 on Router A. The rate of these UDP packets is limited to 1.3
Gbit/s. After the configuration, a user on another network cannot access the DNS server on
this network.

Figure 6-65 Networking diagram of DNS service interruption caused by incorrect

configurations of traffic classification
RouterA
GE1/0/0 GE1/0/1
GE1/0/0
GE1/0/1
RouterB RouterC
Fault Analysis
1. After configurations of rate limit are deleted by using the undo car command in the
traffic behavior view on Router A, a user on another network can access the DNS server
on this network. Therefore, it can be concluded that the fault is caused by incorrect
configurations.
2. Run the display current-configuration command on Router A to check its
configurations:
acl number 3300
rule 4 permit udp
traffic classifier udp-limit operator and
if-match acl 3300
The preceding information indicates that DNS, SNMP, SNMP Trap, and Syslog packets
are all denied. This is because these packets match the ACL rules whose action is deny.
As a result, these packets are directly discarded on Router A, and therefore are not
processed based on the configured traffic behaviors.
Therefore, the actions in the rules of ACL 3300 need to be set to permit for DNS,
SNMP, SNMP Trap, and Syslog packets, and an ACL rule needs to be added to
implement rate limit on the other types of UDP packets.
Procedure
Step 1 Define ACL 3300 for DNS, SNMP, SNMP Trap, and Syslog packets, configure a traffic
classifier through the traffic classifier udp-limit command, configure a traffic behavior by
using the traffic behavior udp-limit command, and create a traffic policy by using the traffic
policy udp-limit command.

Step 2 Define ACL 3301 for UDP packets other than DNS, SNMP, SNMP Trap, and Syslog packets,
configure a traffic classifier through the traffic classifier udp-limit1 command, configure a
traffic behavior by uing the traffic behavior udp-limit1 command, and create a traffic policy
by uing the traffic policy udp-limit1 command.
Step 3 Run the display current-configuration command on Router A to check the corresponding
configurations:
acl number 3300
rule 0 permit udp destination-port eq dns
rule 1 permit udp destination-port eq snmp
rule 2 permit udp destination-port eq snmptrap
rule 3 permit udp destination-port eq syslog
acl number 3301
rule 0 permit udp
traffic classifier udp-limit operator or
if-match acl 3300
traffic classifier udp-limit1 operator or
if-match acl 3301
traffic behavior udp-limit1
classifier udp-limit1 behavior udp-limit1
After matching ACL 3300, DNS, SNMP, SNMP Trap, and Syslog packets are forwarded
based on the traffic behavior configured through the traffic behavior udp-limit command.
After matching ACL 3301, UDP packets other than DNS, SNMP, SNMP Trap, and Syslog
packets are forwarded based on the traffic behavior configured in the traffic behavior udp-
limit1 command.
After the preceding operations, a user on another network can access the DNS server on this
network and rate limit takes effect. The fault is rectified.
----End
Summary
An ACL not only classifies traffic but also permits or denies traffic, that is, forwards or
discards traffic. Therefore, make sure that packets that need to be rate limited are not
discarded.
6.16.6 System Informs That the Outbound Queues' CIRs Exceed

the Upper Limit When the cir-percentage Value Configured for
the EF Queue Exceeds 31
NOTE
Problem Description
On an NE5000E, when the cir-percentage value (percentage of the committed access rate of
a queue accounting for the interface bandwidth, an integer ranging from 0 to 100) configured
for the EF queue exceeds 31 and the cir-percentage values of other queues remain at their
default setting, the system informs that the outbound queues' CIRs exceed the upper limit.

When the cir-percentage value of the EF queue is configured as 31, the system informs that
the outbound queues' CIRs exceed the upper limit.
[HUAWEI-GigabitEthernet3/0/0]qos queue ef priority 1 cir cir-percentage 31
outbound
Error: The summation of outbound queues' CIR exceed the bandwidth of interface
When the cir-percentage value of the EF queue is configured as 30 or a smaller value, the
configuration succeeds.
[HUAWEI-GigabitEthernet3/0/0]display this
#
undo shutdown
ip address x.x.x.x 255.255.255.252
qos queue ef priority 1 cir cir-percentage 30 outbound
Problem Analysis
Check the configurations and specifications of the device and finds no exceptions.
By default, the respective cir-percentage values of BE, AF1, AF2, AF3, AF4, EF, CS6 and
CS7 queues are 10, 10, 10, 15, 15, 10, 5 and 5. The remaining 20% bandwidth is reserved by
the system. The total of cir-percentage values of all queues must not exceed 100. If the total
value exceeds 100, the system informs that the CIRs exceed the upper limit. When the cir-
percentage values of other queues remain at their default setting, the maximum bandwidth
that can be configured for the EF queue is 30% (20% bandwidth reserved by the system +
default 10% bandwidth of EF queues).
Procedure
Step 1 Check the traffic flow conditions on the live network and find that the AF1 traffic volume is
small. Run the qos queue af1 priority priority cir cir-percentage cir-percentage outbound
command in the interface view to reduce the bandwidth for the AF1 queue to a smaller value.
Then the maximum value that can be configured for the EF queue increases.
Step 2 Run the qos queue ef priority priority cir cir-percentage cir-percentage outbound
command in the interface view to configure the bandwidth for the EF queue.
----End
Conclusion
To reallocate bandwidths for queues, first reduce the bandwidth of not existent queues to a
smaller value or 0. Ensure that the total bandwidth does not exceed 100. If the network does
not have a certain type of queue, set the value of cir-percentage for this type of queue to 0 so
that the system does not reserve bandwidth for this type of queue.
6.17 BFD Troubleshooting

6.17.1 Traffic Loss Occurs in a Network Enabled with BFD-based

IP FRR
NOTE
Fault Symptom
On the network shown in Figure 6-66, the link between Router A and Router B is an active
link; the link between Router A and Router C is a standby link. A BFD session is configured
on Router A and Router B to detect the direct link between Router A and Router B; the other
BFD session is configured on Router A and Router C to detect the direct link between Router
A and Router C. If the active link between Router A and Router B fails, traffic switches to the
standby link. User traffic is lost during the 15-second switchover.
Figure 6-66 Networking diagram of traffic loss on a network enabled with BFD-based IP
FRR
RouterB RouterD
GE1/0/0
10.1.1.1 /24
GE1/0/0
10.1.1.2 /24
RouterA
GE2/0/0
20.1.1.2 /24
GE1/0/0
20.1.1.1/24
RouterC RouterE
Fault Analysis
1. Run the display bfd session all verbose command on Router B and Router C to check
the State field and the Process PST field. The State field is Up, the BFD session type is
(Multi Hop), and the Process PST field is Disable. The command output indicates that
the configurations on Router B and Router C are incorrect. In the case of correct
configurations, the State field should be Up and the BFD session type should be (One
Hop); the Process PST field should be Enabled.
2. Run the display bfd session all verbose command on Router A to check the State field
and the Process PST field. The State field is Up, the BFD session type is (Multi Hop),
and the Process PST field is Disable. The command output indicates that the
configurations on Router A are incorrect. In the case of correct configurations, the State
field should be Up and the BFD session type should be (One Hop); the Process PST
field should be Enabled.

Procedure
l Configure a single-hop BFD session on Router A to detect the direct link between Router
A and Router B.
b. Run the undo bfd bfd-name command to delete the BFD session between Router A
and Router B.
c. Run the bfd bfd-name bind peer-ip peer-ip interface interface-type interface-
number [ source-ip source-ip ] command to configure a single-hop BFD session to
detect the direct link between Router A and Router B.
d. Run the process-pst command to bind a BFD session with the interface status in the
port status table (PST).
e. Run the discriminator local discr-value command to set the local discriminator.
f. Run the discriminator remote discr-value command to set the remote
discriminator.
g. Run the commit command to make the BFD session configurations take effect.
l Configure a single-hop BFD session on Router A to detect the direct link between Router
A and Router C.
b. Run the undo bfd bfd-name command to delete the BFD session between Router A
and Router C.
c. Run the bfd bfd-name bind peer-ip peer-ip interface interface-type interface-
number [ source-ip source-ip ] command to configure a single-hop BFD session to
detect the direct link between Router A and Router C.
d. Run the process-pst command to bind a BFD session with the interface status in the
port status table (PST).
e. Run the discriminator local discr-value command to set the local discriminator.
f. Run the discriminator remote discr-value command to set the remote
discriminator.
g. Run the commit command to make the BFD session configuration take effect.
----End
Summary
During the configuration of BFD-based IP FRR, the process-pst command must be run to
bind a BFD session with the interface status in the port status table (PST). The process-pst
command is only applicable to a single-hop BFD session that has been bound to an interface.
The parameter interface interface-type interface-number must be specified before a single-
BFD session is configured.
6.17.2 VoIP Services Are Interrupted After a Board Recovers from

a Fault
NOTE

Problem Description
As shown in Figure 6-67, PE1, PE2, CE1, CE2, and MGW constitute a bearer network. They
are configured as follows:
l MGW is dual-homed to CE1 and CE2.
l VRRP backup group 1 is configured on GE 1/0/0 on CE1 and CE2. CE1 is the master
device, and CE2 is the backup device. The traffic from MGW goes to the core network
through CE1.
l Eth-Trunk 1 is configured on CE1 and CE2. GE 2/0/0 and GE 2/0/1 are added to Eth-
Trunk 1. A single-hop BFD session is established between Eth-trunk 1 on CE1 and CE2.
BFD can rapidly detect faults in the link connecting CE1 and CE2 directly.
The downstream and upstream traffic is transmitted properly after the configuration is
complete. When a fault occurs on the board in slot 2 on CE2, the downstream and upstream
traffic is transmitted properly. When the board in slot 2 on CE2 recovers from the fault,
however, part of downstream traffic is lost.
Figure 6-67 Networking diagram
Backbone
Network
RouterA
PE1 PE2
Eth-Trunk1
GE2/0/0.1 GE2/0/0.1
GE2/0/0 GE2/0/0
CE1 CE2
Master GE2/0/1 GE2/0/1 Backup
GE1/0/0 GE1/0/0
VRRP backup group 1
GE1/0/0 GE1/0/0
Audio server MGW

Problem Analysis
1. The upstream and downstream traffic is transmitted properly before a fault occurs on the
board in slot 2 on CE2. Therefore, the problem is not caused by a link fault.
2. Because CE1 is the master device and CE2 is the backup device, the upstream traffic
path is MGW–>CE1–>PE1–>RouterA before and after the board in slot 2 on CE2
recovers from the fault. Therefore, the traffic from MGW to PE1 is transmitted properly.
3. The downstream traffic is load-balanced on two paths after the board in slot 2 on CE2
recovers from the fault.
– Path 1: RouterA->PE1–>CE1–>MGW. Because CE1 is the master device, this
path is not affected by the fault on the board in slot 2 on CE2 and traffic is
transmitted properly on this path.
– Path 2: RouterA->PE2–>CE2–>CE1–>MGW. Because CE2 is the backup
device, GE 1/0/0 on CE2 is in the backup status. When the downstream traffic
reaches CE2, CE forwards the traffic to CE1 through Eth-Trunk 1. Because a BFD
session is established on the Eth-Trunk link connecting CE1 and CE2 and WTR
configured on the BFD session is five minutes, the protocol status of Eth-Trunk 1 is
Down for five minutes after the board is recovered from the fault. Therefore, part of
downstream traffic is lost.
Procedure
Step 1 Run the system-view command on CE1 and CE2 to enter the system view.
Step 2 Run the bfd bfd-name to enter the BFD session view.
Step 3 Run the undo wtr command to delete the WTR value configured on the BFD session and
restore the default value 0.
After the preceding operations, the VoIP services are running properly. The fault is rectified.
----End
Conclusion
If a BFD session is configured and VoIP services are interrupted for 1 to 60 seconds, WTR
may be configured. To prevent traffic interruption, cancel the WTR function on the BFD
session.
6.18 VRRP Troubleshooting
6.18.1 Pinging a VRRP Interface Address Fails

NOTE
Fault Symptom
On the network shown in Figure 6-68, VRRP backup group 1, functioning as the gateway of
a service server, is configured on GE 1/0/0 of Router A and GE 1/0/0 of Router B. Router A

functions as a master device and Router B functions as a backup device. After the
configurations, the service server fails to ping GE 1/0/0 of Router A.
Figure 6-68 Networking diagram of a failure in pinging the IP address of a VRRP interface
VRRP backup group 1

RouterA
GE1/0/0
Eth-Trunk1
Service
server Eth-Trunk1
GE1/0/0
RouterB
Fault Analysis
1. Run the display arp all command on Router A to check the MAC ADDRESS field.
Router A has learned the MAC address of the service server. It indicates that the problem
is not caused by a link failure.
2. Run the display vrrp command on Router A and Router B to check the State field. The
state of Router A is Master and the state of Router B is Backup, indicating that the
VRRP backup group has been successfully created.
3. Configure STP on Router A, Router B, and the switch to eliminate loops on the network.
After the configuration, the service server still fails to ping GE 1/0/0 of Router A. It
indicates that the problem is not caused by the loop on the network.
4. After running the ping command on the service server to ping GE 1/0/0 of Router A, run
the debug arp packet command to get an ARP packet in the user view on Router A.
Information about the ARP packet sent by Router A is as follows:
*0.3964282271 XJ-WLMQ-HBL-CE-1.CDMA ARP/7/arp_send:Slot=1;Send an ARP Packet,
op
eration : 1, sender_eth_addr : 0018-8288-2cba,sender_ip_addr : 10.255.192.66,
ta
rget_eth_addr : 0000-0000-0000, target_ip_addr :
10.255.192.90
Information about the ARP packet received by Router A is as follows:

*0.3964282271 XJ-WLMQ-HBL-CE-1.CDMA ARP/7/arp_rcv:Slot=4;Receive an ARP
Packet,
operation : 2, sender_eth_addr : 0012-3f1c-8649, sender_ip_addr :
10.255.192.90,
target_eth_addr : 0018-8288-2cba, target_ip_addr : 10.255.192.66

The preceding packet information shows that the ARP packet is sent by the interface
board in slot 1 and received by the interface board in slot 4. Run the display current-
configuration command. The command output shows that the arp learning strict
command has been configured on Router A, causing the service server to fail to ping GE
1/0/0 of Router A. In this case, run the arp learning strict force-disable command to
disable the strict MAC address learning function on GE 1/0/0 of Router A. The fault is
then cleared.
Procedure
Step 3 Run the arp learning strict force-disable command to disable the strict MAC address
learning function.
----End
Summary
The strict MAC address learning function may cause a ping operation to fail. Therefore,
configure this function with caution.
6.18.2 Data Packets Are Discarded on a Network Configured with

VRRP
NOTE
Fault Symptom
On the network shown in Figure 6-69, a VRRP backup group is configured on Router A and
Router B. Router A functions as a master device and Router B functions as a backup device.
Router C functions as a switch connecting Router A and Router B.
Figure 6-69 Networking diagram of a VRRP backup group

RouterA
GE4/0/2 GE1/0/7
RouterC RouterD
GE2/0/4 GE2/0/3 GE1/0/7 GE1/0/2
GE2/0/5
RouterB
Eth-trunk
GE3/0/3
RouterE

After the configurations, a large number of packets sent from Router E to Router D are
discarded.
Fault Analysis
1. Run the display vrrp [ interface interface-type interface-number ] [ virtual-router-id ]
statistics command on Router A and then Router B to check traffic on GE4/0/2 of
Router A and GE3/0/3 of Router B. A small volume of traffic is transmitted on GE4/0/2
of Router A connected to Router C, and no traffic is transmitted on GE3/0/3 of Router B
connected to Router C.
Run the display interface-statistics interface-type interface-number command on
Router C to check traffic on GE 2/0/4, GE 2/0/3, and GE 2/0/5. A small volume of traffic
is transmitted on GE 2/0/3 connected to GE4/0/2, and no traffic is transmitted on GE
2/0/5 connected to GE3/0/3. A large amount of traffic is transmitted on GE 2/0/4. The
statistics show that traffic is dropped on Router C.
2. Run the display mac-address dynamic command on Router C to check MAC
addresses. The learned MAC address of Router A is sent by GE 2/0/4, but not GE 2/0/3
connected to Router A or GE 2/0/5 connected to Routerr B, indicating that the learned
MAC address is incorrect. For example:
MAC address table of slot
2:
------------------------------------------------------------------------------
-
MAC Address VLAN/ PEVLAN CEVLAN Port Type
LSP/
VSI/SI MAC-
Tunnel
------------------------------------------------------------------------------
-
0000-0a0a-0102 1 - - GE2/0/4 dynamic
-
0000-5e00-0101 1 - - GE2/0/4 dynamic
-
0098-0113-0005 1 - - GE2/0/4 dynamic
-
0018-824f-f5d1 1 - - GE2/0/3 dynamic
-
------------------------------------------------------------------------------
-
3. Run the display current-configuration interface interface-type interface-number

command on Router C to check the configuration on GE 2/0/4. For example:
#
undo shutdown
loopback local
portswitch
port default vlan 1
The loopback function has been configured on GE 2/0/4, indicating that GE 2/0/4 loops
traffic back after receiving it.
4. Run the display interface-statistics interface-type interface-number command on
Router C to check traffic on GE 2/0/3, GE 2/0/4, and GE 2/0/5. A great amount of traffic
is transmitted on GE 2/0/4. A small volume of traffic is transmitted on GE 2/0/3. This
indicates that traffic loss is caused by the loopback function on GE 2/0/4.

5. Run the display mac-address dynamic command multiple times on Router C to check
MAC addresses. Router C learns different MAC addresses at different times. For
example:
[RouterC] display mac-address dynamic
2:
------------------------------------------------------------------------------
-
LSP/
VSI/SI MAC-
Tunnel
------------------------------------------------------------------------------
-
0000-0a0a-0102 1 - - GE2/0/4 dynamic
-
0000-5e00-0101 1 - - GE2/0/4 dynamic
-
0098-0113-0005 1 - - GE2/0/5 dynamic
-
0018-824f-f5d1 1 - - GE2/0/4 dynamic
-
------------------------------------------------------------------------------
-
Total matching items on slot 2 displayed =
4
[RouterC] display mac-address dynamic
2:
------------------------------------------------------------------------------
-
LSP/
VSI/SI MAC-
Tunnel
------------------------------------------------------------------------------
-
0000-0a0a-0102 1 - - GE2/0/4 dynamic
-
0000-5e00-0101 1 - - GE2/0/3 dynamic
-
0098-0113-0005 1 - - GE2/0/5 dynamic
-
0018-824f-f5d1 1 - - GE2/0/4 dynamic
-
------------------------------------------------------------------------------
-
Total matching items on slot 2 displayed=4
In a VRRP backup group, a router with a higher priority functions as a master device. If
the IP address of a router is the same as the virtual IP, the router priority is considered
highest and always functions as the master device. The master device sends a VRRP
packet to the backup device every one second by default. If a backup device fails to
receive three consecutive packets from the master device, the backup device preempts to
be the master device and sends a VRRP packet indicating that it becomes the master. In
normal situations, the backup device does not send VRRP packets.
NOTE
If a router is assigned an IP address the same as the virtual IP address, the router always functions
as the master router.

On this network, a packet sent by the master device arrives at the switch. The switch
learns the source MAC address (in this example, 0000-5e00-0101), VLAN ID, and
interface connected to the master device, and adds them to the MAC address table. The
switch searches the MAC address table for the interface connected to the master device,
therefore forwarding the packet to the backup device. If a VRRP switchover occurs, the
backup device becomes the master device and then sends a VRRP packet. After
receiving the VRRP packet, the switch learns the MAC address and maps it to another
interface connected to the new master device.
On this network, after receiving a VRRP packet that is sent every one second, Router C
learns the MAC address of Router A and forwards the VRRP packet to all interfaces
belonging to VLAN 1. GE 2/0/4 of VLAN 1 receives the VRRP packet, and then loops
the VRRP packet back using the loopback function. After receiving the returned VRRP
packet, Router C adds the mapping between GE 2/0/4 and 0000-5e00-0101 to the MAC
address table to overwrite the previous mapping. In this manner, the newly-learned MAC
address overwrites the previous one repeatedly, causing traffic loss.
Procedure
Step 3 Run the undo loopback command to disable the loopback function on the interface.
After the preceding operations, no traffic is discarded. The fault is cleared.
----End
Summary
Do not enable the loopback function on an interface of a Layer 2 device; otherwise, incorrect
MAC addresses are learned.
6.18.3 The VRRP Non-preemption Mode Does Not Take Effect
NOTE
Fault Symptom
On the network shown in Figure 6-70, Router A and Router B are connected with a switch
through Eth-Trunk sub-interfaces. VRRP is run on the Eth-Trunk sub-interfaces. The VRRP
status of Router B is Master and the VRRP status of Router A is Backup. VRRP adopts the
non-preemption mode.
After the configuration, it is found that the backup device preempts to be the master device.
After Router B is restarted or the shutdown and undo shutdown commands are run on the
Eth-Trunk sub-interface of Router B, the backup device still preempts to be the master device.

Figure 6-70 The VRRP non-preemption mode failing to take effect

RouterA RouterB
Backup Master
ETH-Trunk10.200 VRRP200 ETH-Trunk11.200
Switch
Fault Analysis
1. Check the log information on Router B.
a. After Router B is restarted or the interface connecting Router B to the switch is shut
down, VRRP enters the Init state.
VRRP/4/STATEWARNING(l): Virtual Router state CREATED changed to
INITIALIZE, because of create INITIALIZE. (Interface=Eth-Trunk11.200,
VrId=200)
b. After the interface connecting Router B to the switch goes Up, VRRP enters the
Backup state.
VRRP/4/STATEWARNING(l): Virtual Router state INITIALIZE changed to
BACKUP, because of interface UP. (Interface=Eth-Trunk11.200, VrId=200)
c. After the VRRP timer times out, VRRP enters the Master state.
VRRP/4/STATEWARNING(l): Virtual Router state BACKUP changed to MASTER,
because of protocol timer expired. (Interface=Eth-Trunk11.200, VrId=200)
The preceding information shows that VRRP preemption does not occur. Because Router
B does not receive any VRRP packet from the Router A , after the VRRP timer times
out, Router B considers that there is no master on the network, and therefore enters the
master state.
2. Check the information about Router A and the switch. You can find that Router A sends
VRRP packets but the switch does not forward the VRRP packets to Router B. View the
log information of the switch. You can find that the interface connecting the switch to
Router B is not in the Forwarding time during the timeout period of the VRRP timer and
therefore discards the packets.
As defined in STP, after the interface becomes Up, the interface enters the Forwarding
state after 50s. As a result, the VRRP packets are discarded, and it is shown that Router
B preempts to be the Master device.

Procedure
Step 1 Adjust the STP parameters of the switch so that the interface connecting the switch to Router
B can immediately enter the Forwarding after going Up.
After the preceding operations, the backup device does not preempt to be the master device.
Therefore, the fault is rectified.
----End
Summary
VRRP has the following modes:
l Preemption mode: In this mode, if the backup device receives a VRRP packet carrying a
priority lower than the priority of the backup device, the backup device preempts to be
the master device.
l Non-preemption mode: In this mode, the backup device does not preempt to be the
master device.
The non-preemption mode, however, does not mean that the backup device does not become
the master device. After the link between router B and the switch goes Down or Up, the
interface connecting the switch to router B does not enter the Forwarding state immediately.
As a result, VRRP packets are not forwarded in time. Consequently, the VRRP timer times
out, VRRP master/slave switchover occurs, and there are two master devices on the network.
Therefore, when deploying VRRP, fully consider the network environment.
6.18.4 A Master/Slave MPU/SRU Switchover Fails Because the

Master/Slave Switchover Function Is not Enabled
NOTE
Problem Description
Two NE40E&NE80Es, Router A and Router B, are connected using POS interfaces. A
master/slave MPU/SRU switchover fails to be performed on Router A. The following
information is displayed:
[RouterA] slave switchover
Caution!!! Confirm switch slave to master[Y/N]?y
Error:Slave is not ready, try the command again after a while!
Problem Analysis
A master/slave MPU/SRU switchover can be performed only when the following three
conditions are satisfied:
l The slave MPU/SRU is installed and running properly.

l The master MPU/SRU has backed up data to the slave MPU/SRU in batches.
l The master/slave switchover function is enabled.

Procedure
Step 1 Run the display switchover state command to check whether the current device meets the
master/slave switchover requirements.
<RouterA> display switchover state
Error:The command is disabled, you must enable it first.
The preceding information indicates that the master/slave switchover function is not enabled.
Step 2 Run the slave switchover enable command to enable a master/slave switchover.
Step 3 Run the display switchover state command to check whether the current device meets the
master/slave switchover requirements.
<RouterA> display switchover state
Info:HA FSM State, Realtime and routine backup.
The preceding information indicates that the master MPU/SRU is ready for master/slave
switchover: the slave MPU/SRU has been installed and works properly, and master MPU has
backed up files to the slave MPU/SRU in batches.
Step 4 Run the slave switchover command to perform a master/slave switchover.
[RouterA] slave switchover
Caution!!! Confirm switch slave to master[Y/N]?Y
The switchover is performed successfully and the fault is rectified.
----End
Conclusion
None.
6.18.5 VRRP Heartbeat Packets Are Lost After the hub mode
enable Command Is Run
This section provides a case on VRRP Heartbeat packet loss after the hub mode enable
command is run.
NOTE
Context
NOTE
This case is derived from a live network problem. The software version running on the participating
device is V600R001C00SPC200. To resolve a live network problem based on the actual topology and
software versions running on the live network. This case is only for reference.
Fault Symptom
On the network shown in the following picture, the NE40E&NE80E running
V600R001C00SPC200 is attached to S9300-1 and S9300-2. The two VRRP-enabled switches
form a VRRP backup group that functions as a gateway. Both S9300-1 and S9300-2 work in
the Master state, and the VRRP backup group fails to ping the VRRP-enabled interfaces A

and B. After the preliminary analysis of the fault symptoms, the on-site Huawei technical
support personnel think that VRRP Heartbeat packet loss may cause this problem.
Figure 6-71 Networking Diagram for VRRP Heartbeat Packet Loss
NodeB
S9300-1
NodeB
A
Transmission
Upper Network
Ring
B
NodeB
S9300-2
The following command outputs display the VRRP configurations on S9300-1 and S9300-2.
[TS-9300-01]disp vrrp int Vlanif 1000
Vlanif1000 | Virtual Router 1
state : Master
Virtual IP : 10.60.69.62
PriorityRun : 100
PriorityConfig : 100
MasterPriority : 0
Preempt : YES Delay Time : 0
Accept_mode : NO
V2v3interop : NO
Timer : 1
Master adver Timer : 1
Auth Type : NONE
Check TTL : YES
[TS-9300-02]disp vrrp int Vlanif 1000

state : Master
Virtual IP : 10.60.69.62
PriorityRun : 120
PriorityConfig : 120
MasterPriority : 0
Preeept : YES Delay Time : 60
Accept_mode : NO
V2v3interop : NO
Timer : 1
Master adver Timer : 1
Auth Type : NONE
Check TTL : YES
The following command outputs show information about the ping operations on S9300-1 and
S9300-2.
<TS-9300-01>ping 10.60.69.60
Request time out
Request time out
Request time out

Request time out

Request time out

100.00% packet loss
<TS-9300-02>ping 10.60.69.61
Request time out
Request time out
Request time out
Request time out
Request time out

100.00% packet loss
Fault Analysis
Analysis results are as follows:
1. The sub-interfaces on CX600 interfaces A and B belong to the same VSI.
2. The sub-interfaces were configured as sub-interfaces for QinQ VLAN tag termination
and the hub-mode enable command was run on them, causing the sub-interfaces to fail
to communicate with the remote interfaces in the same VSI as the sub-interfaces. As a
result, the VRRP Heartbeat packets are lost, and the two switches in the VRRP backup
group are both in the Master state.
NOTE
After the hub-mode enable command is run on a sub-interface for QinQ VLAN tag termination,
the two VLAN tags are removed from packets that are forwarded through this sub-interface. If this
case occurs, two interfaces in the same VSI cannot ping each other.
3. The log information on S9300-2 is recorded as follows.
Jul 10 2012 14:04:53 TS-9300-02 %%01VRRP/4/STATEWARNING(l): Virtual Router
state BACKUP changed to MASTER, because of protocol timer expired.
(Interface=Vlanif1005,
VrId=11)
VrId=1)
VrId=9)
state BACKUU changed to MASTER, because of protocol timer expired.
(Interface=Vlanif1003, VrId=7)
The log information shows that S9300-2 changes from a backup device to a master
device in the VRRP backup group.
Procedure
Step 1 Enter the view of the sub-interface for QinQ VLAN tag termination and run the undo hub-
mode enable command. After the configuration is complete, the VRRP Heartbeat packets are
transmitted properly and the VRRP status recovers. The VRRP-enabled interfaces can ping
each other.

----End
Summary
VRRP Heartbeat packets can be forwarded only within the same broadcast domain, such as a
VSI or a VLAN. Two interfaces that belong to different VSIs cannot exchange VRRP
Heartbeat packets, which causes Heartbeat packet loss.
6.19 URPF Troubleshooting
6.19.1 Ping Fails After URPF Strict Check Is Configured
NOTE
Fault Symptom
On the network shown in Figure 6-72, Router C is dual-homed to two routers in load
balancing mode. The cost of the link between Router A and Router B is 500; the cost of the
link between Router C and Router A is 800; the cost of the link between Router C and Router
B is 800. Strict URPF is configured on Router A and Router B to protect them from DDoS
attacks from Router C. After the configurations, Router B can ping GE 1/0/1 on Router C
successfully but cannot ping GE 1/0/0 of Router C.
Figure 6-72 Ping failure after URPF is configured
GE1/0/0
RouterA
800
GE1/0/0 500
GE1/0/1
RouterC
800 RouterB
GE1/0/1
Fault Analysis
1. Run the display ip routing-table command on Router B to check routing entries. The
command output shows that routing information is correct.
2. The ping failure occurs after URPF is enabled. Therefore, it is suspected that URPF
discards ping packets. You can disable URPF and then check whether the ping operation
succeeds.

Run the undo ip urpf command in the interface view on Router A and Router B to
disable URPF.
3. Analyze the path along which a ping request packet travels.
When Router B pings GE 1/0/1, two paths are available: B-C with the cost being 800 and
B-A-C with the cost being 2100. The first path is preferentially used. For the ping
response packet, two paths are available: C-B with the cost being 800 and C-A-B with
the cost being 1300. The first path is preferentially used.
When Router B pings GE 1/0/0, two paths are available: B-C with the cost being 1600
and B-A-C with the cost being 1300. The second path is preferentially used. For the ping
response packet, two paths are available: C-B with the cost being 800 and C-A-B with
the cost being 1300. The first path is preferentially used.
The URPF check is available in two forms: URPF loose check and URPF strict check.
– In the URPF loose check, a packet can pass the URPF check as long as the
forwarding table has a routing entry whose destination address is the source address
of the packet. The URPF loose check does not require that the inbound interface of
the packet be the same as the outbound interface in the routing entry.
– In the URPF strict check, a packet can pass the URPF check only if the forwarding
table has a routing entry whose destination address is the source address of the
packet and whose outbound interface is the same as the inbound interface of the
packet.
It can therefore be concluded that this problem is caused by the URPF strict check. In
this troubleshooting case, when Router B pings GE 1/0/0, the paths of ping request
packets and ping response packets are different. As a result, ping response packets
cannot pass the URPF strict check, and the ping fails.
Procedure
Step 1 Run the system-view command on Router A and Router B to enter the system view.
Step 2 Run the interface interface-type interface-number command on Router A and Router B to
enter the view of GE 1/0/0 on Router A and the view of GE 1/0/1 on Router B.
Step 3 Run the ip urpf loose command on Router A and Router B to enable the URPF loose check
function.
After the preceding operations, Router B can ping both GE 1/0/0 and GE 1/0/1 on Router C.
----End
Summary
On the network where a device has two uplink paths, do not configure the URPF strict check
function on the device.
6.19.2 Ping Between Two Interconnected Interfaces Sometimes

Fails
On a network, URPF is configured on interconnected interfaces and two links have the same
cost. Under certain circumstances, a ping packet cannot pass the URPF check, and the ping
fails.

Fault Symptom
On the network shown in Figure 6-73, OSPF is configured on the devices and URPF is
configured on interconnected interfaces. The cost of the link between Router A and Router B
is 800; the cost of the link between Router C and Router A and between Router C and Router
B is 1000 each.
Figure 6-73 URPF networking diagram
RouterA RouterB
GE1/0/0 GE1/0/0
800
GE1/0/1 GE1/0/1
1000 1000
GE1/0/0 GE1/0/1
RouterC
On Router A, ping the IP address of GE 1/0/1 on Router C after the configurations. The ping
sometimes fails.
Fault Analysis
1. Run the display ip routing-table command on Router C to check OSPF routing entries.
The command output shows that the OSPF routing table is correct.
2. Analyze the path along which ping packets travel. When a ping packet is sent from
Router A to GE 1/0/1 on Router C, it can travel along the path of A->B->C (costs are
800 + 1000 = 1800) or along the path of A->C (costs are 1000 + 1000 = 2000).
Therefore, the path of A->B->C is preferentially selected. The ping packet can travel
back along the path of C->A or along the path of C->B->A, and the total cost of both
paths is 1800 (1000 + 800).
– If a ping packet travels to the destination and then travels back along the same path
(in the opposite direction), it can pass the URPF check, and the ping can succeed.
– If a ping packet travels to the destination and then travels back along a different
path, it cannot pass the URPF check. As a result, the ping packet is discarded and
the ping fails.
NOTE
Generally, upon receiving a packet, the NE40E&NE80E first obtains the destination IP address of
the packet and then searches the forwarding table for a route to the destination. If the
NE40E&NE80E finds such a route, it forwards the packet; otherwise, it discards the packet. After
URPF is configured, the NE40E&NE80E obtains both the source IP address and the inbound
interface of a packet and then searches the forwarding table for an entry in which the destination
address is the source address of the packet. Then, URPF checks whether the outbound interface
recorded in the entry is the same as the inbound interface of the packet. If these two interfaces are
different, URPF considers the source IP address invalid and discards the packet. In this manner,
URPF discards packets with false source IP addresses, therefore protecting network devices
against malicious attacks.

In this troubleshooting case, interconnected interfaces are configured with URPF and
two links have the same cost. When a ping packet travels back along the path of A-B-C,
it can pass the URPF check, and the ping succeeds. However, when a ping packet travels
back along the path of A-C, it cannot pass the URPF check, and as a result, the ping fails.
Procedure
Step 3 Run the undo ip urpf command to delete the URPF configuration on the interface.
On Router A, ping the IP address of GE 1/0/1 on Router C after the preceding configurations.
The ping succeeds. The fault is cleared.
----End
Summary
On the NE40E&NE80E, do not configure URPF on the interfaces connecting the
NE40E&NE80E to other devices. Configure URPF on network-side and user-side interfaces
of the NE40E&NE80E.
6.20 Local Attack Defense Troubleshooting
6.20.1 Files Are Uploaded Slowly Using FTP Because of the

Security Protection Configured on Upstream LPUs
NOTE
Fault Symptom
100 MB version files need to be uploaded to more than 10 devices on the network for
upgrading the devices. However, it takes more than 20 hours to finish uploading those files to
all devices.
Fault Analysis
1. The ping operation shows that the network delay is not long. Therefore, the network is
not congested.
2. The speed of uploading version files using the maintenance port on the MPU is normal.
Therefore, the CF card is running normally.
3. On the same network, files are uploaded to other devices at a normal speed. Therefore,
the other devices are set with no restriction for uploading files.

4. Check upstream LPUs of these devices and find that a bandwidth restriction is set to
process FTP packets for security. Therefore, the problem occurs because the devices
restrict the rate at which protocol packets are sent to the CPU.
Procedure
Step 1 Run the cpu-defend policy 14 command to create an attack defense policy.
Step 2 Run the car index 61 cir 10000 command to adjust the CIR.
Step 4 Run the slot 3 command to enter the slot 3 view.
Step 5 Run the cpu-defend-policy 14 command to apply the attack defense policy.
After preceding operations, the bandwidth for processing FTP packets of the board in slot 3 is
adjusted to 10 MB. The fault is rectified.
----End
Summary
By default, the device restricts the rate at which protocol packets are sent to the CPU. If the
rate at which protocol packets are sent to the CPU is greater than the CIR of the current
system, the packets are discarded. Therefore, if the protocol packets cannot be normally
uploaded to the CPU by default, you need to adjust the CIR to a larger value to protect the
packets from being discarded or restricted.
6.20.2 Ping Packets Are Discarded After the Device Upgrades

Caused by the LPU cpu-defend car Configuration
NOTE
Fault Symptom
The NE40E on the backbone network of a carrier upgrades from V600R001C00SPCc00 to
V600R001C00SPCf00. After the upgrade, packet loss occurs when access devices ping the
NE40E. This fault never occurs before the upgrade. In addition, no packet loss occurs when
access devices ping the other devices on the same network before and after the upgrade.
Fault Analysis
1. It is confirmed that the size of the ping packet is 1900 bytes, and the rate of sending ping
packets is 80 packets per second. Since packet loss occurs when several access devices
ping the NE40E using different physical links, the physical interfaces may be faulty. By
checking physical interfaces, there is no error packet and the CRCs do not increase. The
fault is not caused by faulty physical links. The analysis about the NE40E configurations
shows no configuration about the rate limit. However, the display cpu-defend
application-apperceive statistics command output shows that the number of discarded
ICMP packets is increasing.

<NE40E>display cpu-defend application-apperceive statistics slot 2

Slot Attack-Type Total-Packets Passed-Packets Dropped-Packets
------------------------------------------------------------------------------
--
2 Application-Apperceive 837917 834765 3152
------------------------------------------------------------------------------
--
FTP SERVER 0 0 0
SSH SERVER 0 0 0
SNMP 0 0 0
TELNET SERVER 25 25 0
OSPF 811666 811666 0
ISIS 0 0 0
ICMP 25014 21862 3152 //keep increasing
802.1AG 0 0 0
FTP CLIENT 0 0 0
TELNET CLIENT 1212 1212 0
2. Run the display icmp statistics command to check ICMP traffic statistics. The statistics
about destination unreachable are displayed as follows:
<NE40E>display icmp statistics
Input: bad formats 0 bad checksum 0
echo 292101 destination unreachable 234900//keep increasing
source quench 0 redirects 0
echo reply 240 parameter problem 0
timestamp 0 information request 0
mask requests 0 mask replies 0
time exceeded 26
Mping request 0 Mping reply 0
Output:echo 611 destination unreachable 0
source quench 0 redirects 0
echo reply 292101 parameter problem 0
timestamp 0 information reply 0
mask requests 0 mask replies 0
time exceeded 718
Mping request 0 Mping reply 0
It is suspected that the packet loss is caused by the CAR function. The information about
packet drop caused by the ICMP CAR function on the LPU is displayed as follows:
<NE40E>display cpu-defend car protocol icmp statistics slot 2
Slot : 2
--------------------------------------------
ICMP packet
Protocol switch: Open
Packet information:
Priority : high
Calculate the rate of sending ping packets: 1900 bytes x 8 x 80 = 1216 kbit/s. Since the
rate is greater than 1000 kbit/s, the CAR function enabled on the LPU causes the packets
to be discarded. On V600R001C00SPCc00 before the upgrade, since the CIR of the LPU
CAR function is 4000 kbit/s, ping packets are not discarded. After the upgrade, ping
packets are discarded.
Procedure
Step 1 Run the cpu-defend policy 2 command to create an attack defense policy.
Step 2 Run the car icmp cir 4000 command to modify the CAR configuration on the LPU and
change the CIR to 4000 kbit/s.

Step 3 Run the cpu-defend-policy 2 command in the slot 2 view to apply the attack defense policy.
After the preceding operations, packet loss does not occur when access devices ping the
NE40E.
----End
Summary
Problems often occur because the default configurations are changed during the system
version upgrade on routers. Ping is a common method used to check the network connectivity.
If ping packets are discarded, you can locate the problem by checking details about discarding
packets by application layer association.
6.21 User Fails to Get Online Troubleshooting
6.21.1 Level 3 Telnet Users Have Only Level 0 Authority Because

the RADIUS Server Is Unreachable
NOTE
Fault Symptom
Users access network devices through Telnet. RADIUS authentication and then local
authentication are implemented for the users. The default domain is used. A level 3 authority
is configured for both RADIUS and local users.
aaa
authentication-scheme default0
local-user cs password simple cs
local-user cs service-type telnet
local-user cs level 3
After the user logs in to the device, the relevant command output shows that the user has only
a level 0 authority.
Login authentication
Username:cs
Password:
Info: The max number of VTY users is 20, and the number
of current VTY users on line is 4.
<HUAWEI>?
User view commands:
cluster Run cluster command
display Mfib proxy module
hwtacacs-user HWTACACS user
language-mode Specify the language environment
local-user Local user
ping Ping function
quit Exit from current command view
return Exit to user view
save Save file

super Privilege current user a specified priority level

telnet Establish a Telnet connection
trace Trace route (switch) to host on Data Link Layer
tracert Trace route to host
Fault Analysis
1. The user has a level 0 authority, which indicates that the user has passed authentication
and has been authorized. The authorization level of the user, however, is not as
authorized by the RADIUS server. The possible cause is that the user has not passed
RADIUS authentication and authorization.
2. The login user name does not contain a domain name, which indicates that the system
performs authentication and authorization based on the scheme set for the default
domain. Check the authentication and authorization configurations. The RADIUS
authentication and the local authentication are used in sequence in the default domain.
The authorization mode is set to if-authenticated.
<HUAWEI>display current configuration aaa
#
aaa
local-user cs password simple cs
local-user cs service-type telnet
local-user cs level 3
#
authorization-scheme default
authorization-mode if-authenticated
#
accounting-scheme default
accounting-scheme huawei
#
domain default
If the RADIUS server is unreachable, the user uses the local authentication. Since the
configured authorization mode if-authenticated is invalid to the local authentication, the
system returns the VTY default authorization (level 0) to the user who has passed the
authentication.
If the local authorization is used, the system returns an authorization level that is set
locally for the user.
Procedure
Step 1 Run the authorization-scheme default command to enter the authorization scheme view.
Step 2 Run the authorization-mode if-authenticated local command to configure the authorization
mode that if-authenticated authentication and then local authentication are implemented for
the users.
Otherwise, perform the following operations to change the user level to level 3.
1. Run the user-interface vty number1 number2 command to enter the VTY user interface
view.
2. Run the authentication-mode aaa command to configure AAA authentication.
3. Run the user privilege level 3 command to modify the user level to level 3.
After the preceding operations, the user has a level 3 authority and the fault is rectified.
----End

Summary
If the login name does not contain a domain name, the system performs authentication and
authorization in the default domain. If the local authentication is used, the system returns an
authorization level that is set locally for the user only when the local authorization is used.
Otherwise, the system returns the VTY default authorization (level 0) to the user. By default,
users logging in through the console interface can use the command at level 3, and users
logging in through other interfaces can use the command at level 0.
6.21.2 The Telnet User Is Logged Out Because the Accounting

Function Is Not Enabled on the RADIUS Server
NOTE
Fault Symptom
The RADIUS server authenticates the Telnet user. However, the Telnet user is forced to log
out about 1 minute after logging in to the device. The fault persists after the user re-logs in to
the device.
Fault Analysis
1. Delete the authentication-mode aaa command configured on the user-interface vty 0 4
command and use local authentication. No fault occurs.
2. Configure the authentication-mode aaa command again and find that the user still goes
offline.
3. Enable the debugging of the RADIUS, the following information is displayed.
[Acct-Status-Type(40) ] [6 ] [2]
Acct-Status-Type(40) indicates the type of accounting request packets; 2 indicates that

the accounting is stopped. The accounting function is disabled by the RADIUS server.
4. Check AAA configurations:
domain default
authentication-scheme admin
accounting-scheme admin //Accounting scheme
radius-server admin
accounting-scheme admin
accounting-mode radius //The accounting mode is the RADIUS accounting.
The accounting function is not enabled on the RADIUS server. As a result, the RADIUS
server fails to charge the Telnet user and sends the offline packet to the device. The user
is logged out.
Procedure
Step 1 Delete the accounting mode of the device, or run the accounting-mode none command in the
accounting scheme view to set the accounting mode to none.
After the preceding operation, the Telnet user logs in to the device and keeps online. The fault
is rectified.
----End

Summary
AAA needs to be correctly configured based on the actual situation. The user may fail to go
online if irrelevant functions are configured.
6.21.3 Logs About Login Failures Are Generated Continuously

After Old Devices Are Replaced with New Ones
NOTE
Fault Symptom
After a carrier replaces old routers with NE5000Es and NE80Es, the new devices send alarms
to the NMS continuously, which affects monitoring services. Log information is as follows:
Nov 24 2011 08:45:09 Router %%01SHELL/4/TELNETFAILED(l)0]:Failed to login through
telnet. (Ip=x.x.x.x, Times=3)
Fault Analysis
1. The preceding log information indicates that the login through Telnet fails. If the log
information is continuously generated on all devices, a fault occurs.
Devices receive Telnet request packets continuously but the user fails to log in to the
devices through Telnet. The possible causes are as follows:
a. Devices are attacked. Illegitimate users crack passwords to obtain the access rights
to devices.
b. The login user name and password are not correctly configured on the devices or
the AAA server.
c. The NMS accesses the devices regularly to detect the device connectivity. The user
fails to log in to devices because the user name and password are configured
incorrectly.
Analyzing procedure:
a. Since device management is implemented in a closed network, and the IP address in
the log information is that of the NMS, devices are not attacked.
b. The authentication mode configured for devices is the local authentication first and
the TACACS authentication second. The user name and password are configured on
the AAA server.
c. The NMS accesses all devices through Telnet regularly to detect the device
connectivity, and the user name and password configured on the NMS are tested
correct.

Check the authentication mode of the devices and find that the authentication mode
before the replacement is TACACS authentication first and Local authentication second.
However, the authentication mode of the new devices is Local authentication first and
TACACS authentication second, and the sequence cannot be changed.
authentication-mode local hwtacacs
2. Using this authentication mode, an alarm is generated only when all authentication
modes fail. Therefore, no matter the user is a local user or AAA server user, no alarm is
generated if the user name and password are correct. If a user logs in to a device through
Telnet but inputs no user name or password, alarms are generated continuously.
The analysis shows that one of the NMS software packages is not updated, causing the
NMS to initiate two Telnet connections each time. However, one of the two connections
is in suspension state.
Procedure
Step 1 The carrier upgrades the software package.
After the preceding operations, all new devices generate no alarms and the fault is rectified.
----End
Summary
None.
6.21.4 RADIUS Authentication Failure Causes an ME60 User to

Fail to Log In to the Directly Connected NE40E&NE80E That
Functions as the FTP Server
NOTE
involved is V600R001C00SPC800. When you troubleshoot similar problems, take into consideration
your particular network conditions and device versions.
Network Environment
The ME60 functions as the FTP client is directly connected to the FTP server. An ME60 user
fails to log in to the FTP server. Error messages on ME06 are as follows:
Error: Failed to run this command because the connection was closed by remote
host.
Figure 6-74 Networking Diagram of the Case
Server Client

Fault Analysis
This problem commonly results from one of the following causes:
1. The route is not reachable.
2. FTP configurations are incorrect.
3. An ACL rule is configured to deny packets from FTP port 20 or 21.
4. The FTP user name or password is incorrect.
5. RADIUS authentication fails.
The troubleshooting methods for each cause are as follows:
1. For cause 1: Ping the ME60 from the NE40E&NE80E. If the ping operation succeeds,
the route is reachable.
2. For cause 2:
Check whether the ftp server enable command is configured in the system view of the
NE40E&NE80E. If it is configured, the FTP server is started.
Check whether the local-user user-name ftp-directory directory command is configured
in the AAA view of the NE40E&NE80E. If it is configured, the directory to which an
ME60 user can access is configured correctly.
Therefore, if both the preceding two commands are configured, the FTP configuration is
correct.
3. For cause 3: Check whether an ACL rule is configured to deny packets from FTP port 21
or 22. If no such a rule is configured, this problem is not caused by the ACL
configuration.
4. For cause 4: Enter the correct FTP server user name and password again.
5. For cause 5: Check the configuration of the authentication scheme and the authentication
domain:
Authentication scheme on the NE40E&NE80E:
authentication-scheme telecom
RADIUS authentication takes precedence over local authentication.

Configuration of default domain on the NE40E&NE80E:
domain default
authentication-scheme telecom
radius-server telecom
This means that the default domain is bound to an authentication template named
telecom.
If remote authentication takes precedence over local authentication and the login user
name and password are not created on the remote server but created on the local device,
the remote authentication will fail and local authentication will not start. Local
authentication takes effect only if the remote authentication server is Down. Because
RADIUS authentication takes precedence over local authentication in this case, local
authentication will not take effect after remote authentication fails. Therefore, an ME60
user fails to log in to the FTP server.
Procedure
Step 1 Run the authentication-mode local command in the authentication scheme view named
telecom of the NE40E&NE80E. Configure the current authentication mode as local

authentication. The authentication is successful. An ME60 user can login NE40E&NE80E by

using FTP.
----End
Summary
If several authentication modes are used in an authentication scheme, these authentication
modes take effect in the sequence of their configurations.
l When local authentication takes precedence over remote authentication:
If the login user name and password are not created on the local device but created on
the remote server, remote authentication takes effect instead of local authentication.
If the login account is available on both the local and remote server and the incorrect
password causes the local authentication to fail, the remote authentication will not start.
l When remote authentication takes precedence over local authentication:
If the login user name and password are not created on the remote server but created on
the local device, the remote authentication will fail and local authentication will not start.
Local authentication takes effect only if the remote authentication server is Down.
6.21.5 User Login Fails When User Names Carry Domain Names
During HWTACAS Authentication
NOTE
Fault Symptom
The device uses HWTACAS authentication. When a user enters a user name including a
domain name, the login fails. The debugging hwtacacs all command output shows the
information "status:AUTHEN_STATUS_FAIL."
Fault Analysis
1. Check the HWTACACS server configurations. The results show that the configurations
are correct.
#
aaa
authentication-scheme tacacs
authentication-mode hwtacacs local
authentication-super hwtacacs super
#
authorization-scheme tacacs
authorization-mode hwtacacs local
authorization-cmd 3 hwtacacs
#
accounting-scheme tacacs
accounting-mode hwtacacs
#
domain default_admin
authentication-scheme tacacs
authorization-scheme tacacs
accounting-scheme tacacs

hwtacacs-server tacacs
#
hwtacacs-server template tacacs
hwtacacs-server authentication 10.6.1.25
hwtacacs-server authorization 10.6.1.25
hwtacacs-server accounting 10.6.1.25
hwtacacs-server source-ip 10.1.1.1
hwtacacs-server shared-key simple hello
2. The user name is huawei@default_admin and including the domain name

"default_admin." However, the HWTACACS server does not support a user name
including a domain name. As a result, the authentication fails. Therefore, you must
configure a user name not to include a domain name. After the configuration is complete,
the client deletes the domain name from the user name when requesting the
HWTACACS server for authentication or authorization.
Procedure
Step 1 Run the hwtacacs-server template tacacs command to enter the HWTACACS server
template view.
Step 2 Run the undo hwtacacs-server user-name domain-included command to configure a user
name not to include a domain name.
After the preceding operations, users can log in to the device. The fault is rectified.
----End
Summary
A user name is usually in the format of "user name@domain name." If the HWTACACS
server does not support a user name including a domain name, delete the domain name and
then send the user name without the domain name to the HWTACACS server.

NE Series Router Maintenance Guide 7 FAQ
7 FAQ
About This Chapter
7.1 Hardware
7.2 System
7.3 How Can I Use the Self-Loop Function to Detect the Ping Failure on an Interface?
7.4 Layer 2 Networks
7.5 IP Services
7.6 IP Routing
7.7 Multicast
7.8 QoS
7.9 MPLS
7.10 VPN
7.11 Security
7.12 Reliability
7.13 User Access
7.14 Video Service

7.1 Hardware
7.1.1 Boards
7.1.1.1 How to Differentiate Between the LAN LPU and WAN LPU?
According to the PIC information, you can differentiate between the LAN board and WAN
board:
PIC0's version information:
PCB Version : CR52E1XX REV C
EPLD Version : 004
E1XX indicates a LAN board; W1XX indicates a WAN board; L1XX indicates a board which
can work in either LAN or WAN mode. For L1XX board, you can use the set transfer-mode
command to configure the transmission mode of the board to LAN or WAN.
7.1.1.2 Does the CF Card on the NE40E&NE80E Support Hot Swap?

In the NE40E&NE80E, all CF cards on the MPU/SRU do not support hot swap. In the
NE40E-X8 and NE40E-X16 chassis, the CF cards support hot swap after the offline buttons
of CF cards are pressed.
NOTE
CF card cannot be supported on the X3 models of the NE40E&NE80E.
7.1.1.3 Can the Optical Module on the WAN Board Receive Optical Signals With
Different Wavelengths?
The XFP optical module whose center wavelengths are 1310 nm and 1550 nm can receive
optical signals with wavelengths ranging from 1260 nm to 1600 nm (The ranges vary with the
optical module type).
The XFP optical modules certified are as follows:
BOM Description Single-mode or Remarks

Multimode
34060362 Optical Multimode Applied to the 10

Transceiver,XFP, Gbit/s Ethernet LAN
850nm,10.3Gb/ only
s,-7.3dBm,-1.3dBm,
-7.5dBm,LC,MM,
0.3km

BOM Description Single-mode or Remarks

Multimode
34060313 Optical Single-mode Applied to the 10

Transceiver,XFP, Gbit/s POS, 10
1310nm, Gbit/s Ethernet
9.95~10.71Gb/ LAN, and 10 Gbit/s
s,-6dBm~-1dBm,-14 Ethernet WAN
.4dBm,LC,SM,
10km

Transceiver,XFP, Gbit/s POS, 10
1550nm,9.95Gb/s to Gbit/s Ethernet
11.1Gb/s, LAN, and 10 Gbit/s
+2dBm,-1dBm,-15d Ethernet WAN
Bm,LC,Single-
mode,40km

transceiver,XFP, Gbit/s POS, 10
1550nm,9.95Gb/s to Gbit/s Ethernet
11.1Gb/s, LAN, and 10 Gbit/s
0~4dBm,-24dBm,L Ethernet WAN
C,Single-mode,
80km
7.1.1.4 Can a Multimode Optical Module Be Applied to a 10G POS Board?

No. The multimode optical module is generally applied to the 10G LAN board rather than the
10G POS board or 10G WAN board.
7.1.1.5 What Do the "Non-Convergence Mode" and "Convergence Mode" Mean in

the Board Description?
The sub-card in non-convergence mode supports line-rate forwarding; the sub-card in
convergence mode does not support line-rate forwarding when being fully configured. A logic
on the board can be used to preferentially guarantee bandwidth for the sub-card in non-
convergence mode.
Currently, some sub-cards can be configured to work either in convergence mode or in non-
convergence mode. For detailed specification, see HUAWEI NetEngine40E/80E Router
Hardware Description. After a sub-card is configured to work in non-convergence mode, the
sub-card that is installed afterward cannot be registered if the remaining bandwidth is
insufficient.
For example, the inserted 8GE sub-card preempts 8 Gbit/s bandwidth. Then, the remaining
bandwidth is 2 Gbit/s, which is insufficient for a new sub-card. In this case, the newly inserted
sub-card cannot be registered. If the inserted sub-card is configured to work in convergence
mode, the newly inserted sub-card can be registered even if it can be assigned only 2 Gbit/s
bandwidth.

7.1.1.6 What Services Does the E1 Interface on the NE40E&NE80E Support?

The E1 interface supports the following services:
l TDM E1 transparent transmission (CESop/SATop)
E1 frames are transparently transmitted on the PSN network. That is, the E1 frames on
the inbound interface are encapsulated into PWE3 packets, and then are added with
MPLS labels before traversing the PSN network. Then, the remote end decapsulates the
PWE3 packets into E1 frames and sends the E1 frames to the line side.
l ATM Cell Relay
ATM cells are transparently transmitted on the PSN network. That is, the E1 frames are
parsed into ATM cells. The ATM cells are then encapsulated into PWE3 packets and are
added with MPLS labels before traversing the PSN network.
l Multiple ATM E1 interfaces can be configured as an IMA group interface.
l If PWE3 emulation services are not adopted, the E1 channel can be configured with
common PPP/HDLC/MP to bear IP services.
The preceding configurations can be configured on different E1 interfaces of a sub-card. That
is, one sub-card can support all the preceding services.
7.1.1.7 The Slave MPU/SRU Is Abnormally Reset Due To an Unknown Reason

Run the display device command, and you can find that the reason why the slave MPU/SRU
is abnormally reset is unknown.
<HUAWEI> display device 9
Mpu9's detail information:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Date of slot9 is reset: 2000-01-01
Time of slot9 is reset: 00:01:19
Sequence of event occur: 1
Reason is:Cold Start
reset code:f000b,Module:MPU.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The cause of this fault is that the current GTL license file supports the ESN of the master
MPU/SRU rather than the ESN of the slave MPU/SRU. As a result, the slave MPU/SRU
enters the trial period. After the trial period expires, the slave MPU/SRU is restarted, and the
master/slave MPU/SRU relationship is deleted. Run the following command to view the GET
license file:
<HUAWEI> display license
Active License on master board: cfcard:/on1049656.dat

<HUAWEI> more on1049656.dat
LicenseSerialNo=LIC20100125000E00
Creator=Huawei Technologies Co.,Ltd.
CreatedTime=2010-01-25 10:12:38
Product=XXXXXXXX
Feature=CRFEA1
Esn="030DGS1099000227"
Attrib="DEMO, 2010-03-31, 60, NULL, NULL, NULL"
Resource="LCR5TUNNEL05=32, LCR5BTOA00=32"
Function="LCR5BSVC00=1"
Comment="ON1049656-A0D27B59001-0123456789ABCD"

Sign=
26D1DE252A0F6AFDC2C97D4F1C866FD558E672A715BE4D12E3DA212E00C9BA19BA25B061C0CF53AF51
07EF02089359E8C74338DF46265BD991675E12683602
9CFE0DF2ED2C21DA057E44D1C1E9C3A9BA3A9D2B6103F1346365D50356C34CC2953348227648B79FF2
F7D26E15DAFBF059810E61FC7E1607ED1A5C7741017A79DD
<HUAWEI> display esn
ESN of master: 030DGS1099000227
ESN of slave: 030DGS1099000226
The command output shows that the GTL license file contains the ESN
(030DGS1099000227) of the master MPU/SRU rather than the ESN (030DGS1099000226)
of the slave MPU/SRU.
To rectify the fault, do as follows:
1. Apply for a GTL license file that can be activated on both the master MPU/SRU and the
slave MPU/SRU.
2. Activate the new GTL license file.
3. Restart the slave MPU/SRU.
7.1.1.8 What Logical Software Should Be Upgraded When the Interface Board Is
Identified as the Slot of the MPU?
The logical software of the FAD should be upgraded.
7.1.1.9 What Logical Software Should Be Upgraded When the CPU of the LPU
Does not Run?
The EPLD logical software of the LPU should be upgraded. If it does not work, you need to
reload Bootrom and Bootload files.
7.1.1.10 When is the LPU powered off automatically?

If a fault in hardware initialization occurs three times continuously in the startup, the LPU is
powered off. If the times of power-off are less than 10, the LPU is powered on again within 3
seconds.
7.1.1.11 When is the LPU powered off permanently?

If powered on and off 10 times due to the failure of hardware initialization, the LPU will be
powered off unless you remove and insert the board.
7.1.1.12 Can the service boards of the device be separately powered on?
It cannot succeed. You have to power on the MPU before the service boards.
7.1.1.13 How to Solve the Problem that the DDR SDRSM of the interface board
Fails the ECC Check?
A hardware fault causes the DDR SDRSM of the interface board to fail the ECC check. If
there is no ECC field in the log after the interface board is restarted, the interface board
memory has been restored during the interface board restart; if the fault persists after the
interface board is restarted, replace the interface board.
For example:

Warning 10-08-20 09:56:15 LPU 1 is failed, DDR SDRAM of MEMORY is

abnormal
Warning 10-08-20 09:56:16 LPU 1 is failed, DDR SDRAM of MEMORY is
abnormal , Resume
Aug 19 2010 16:59:35 XZ1.R1 %%01SRM/2/NODEFAULT(l)[1]:Slot=1;MEMORY of LPU1 is
failed, perhaps ECC of DDR SDRAM is abnormal. (Reason="")
Aug 19 2010 16:59:31 XZ1.R1 %%01SRM/2/NODERESUME(l)[3]:Slot=1;MEMORY of LPU1: ECC
of DDR SDRAM resumed
7.1.1.14 How to Delete a Telnet User That Is Displayed Through the display users
Command?
For example, the Telnet user vty0 is deleted as follows:
User-Intf Delay Type Network Address AuthenStatus AuthorcmdFlag
+ 0 CON 0
00:00:00 Username :
Unspecified
34 VTY 0 00:00:00 TEL 202.100.196.246 pass no
Username : fufu
35 VTY 1 00:00:00 TEL 202.100.196.246 pass no
Username : fufu
36 VTY 2 00:00:00 TEL 202.100.196.246 pass no
Username : fufu
37 VTY 3 00:00:00 TEL 202.100.196.246 pass no
Username : fufu
38 VTY 4 00:00:00 TEL 202.100.196.246 pass no
Username : fufu
To delete a Telnet user, run the free user-interface vty vty-id command in the user view.
7.1.1.15 What Is the Wire Sequence of the E1 Cable Connecting a 24-Port Board
on the NE40E&NE80E?
Pins 1 and 2 are responsible for transmitting packets; pins 4 and 5 are responsible for
receiving packets.
The names of pins are as follows:
l 1: RX+
l 2: RX-
l 4: TX+
l 5: TX-

7.1.1.16 How to query the ESN on the MPU?

Run the display esn command.
7.2 System
7.2.1 Command Line Management
7.2.1.1 What Are the Functions of the display saved-configuration Command and
the display saved-configuration last Command?
The display saved-configuration command is used to check the configuration file for the
next system startup.
The display saved-configuration last command is used to check the configuration file for the
current system startup.

Startup saved-configuration file: cfcard:/vrpcfg.cfg ---->display

saved-configuration last
Next startup saved-configuration file: cfcard:/vrpcfg.cfg ---->display
saved-configuration
7.2.1.2 Which File Does the compare configuration Command Compare the
Current Configuration with?
The compare configuration command is used to compare the current configuration
(displayed by the display current-configuration command) with the current startup
configuration file.
MainBoard:
Configured startup system software: hda1:/vrp5.cc
Startup system software: hda1:/vrp5.cc
Next startup system software: hda1:/vrp5.cc
Startup saved-configuration file: flash:/vrpcfg.cfg
Next startup saved-configuration file: flash:/vrpcfg.cfg
Startup paf file: flash:/paf-b291smk3.txt
Next startup paf file: flash:/paf-b291smk3.txt
Startup license file: flash:/license-b291smk3.txt
Next startup license file: flash:/license-b291smk3.txt
Startup patch package: flash:/patch.bat
Next startup patch package: flash:/patch.bat
7.2.1.3 Which File Does the reset saved-configuration Command Is Used to Clear?
The reset saved-configuration command is used to clear the configuration file for the current
system startup.
l If the same configuration files are used for the current system startup and next system
startup, you can run this command to clear the configuration file.
l If the configuration file for the current system startup is cleared, running this command
will fail, no matter whether the configuration file for the next system startup exists.
Startup saved-configuration file: cfcard:/vrpcfg.cfg
Next startup saved-configuration file: cfcard:/vrpcfg.cfg
7.2.1.4 Which Configuration File Does the save Command Save the
Configuration to?
The save command is used to save the current configurations (activated global configurations
and activated configurations of the installed boards) to the configuration file for the next
system startup.

l When the same configuration file is used for the current and next system startup, running
the save command updates the configuration file.
l When different configuration files are used for the current and next system startup,
running the save command only updates the configuration file for the next system
startup.
7.2.1.5 Which Methods Can Be Adopted to Upgrade or Degrade a Command?

You can run the command-privilege level command to upgrade or degrade a command. The
command-privilege level command takes effect only based on the last keyword; therefore,
different command combinations should be adopted to upgrade or degrade a command.
l To upgrade a command, you need only to attach the command to the command-
privilege level command.
For example, if you want to upgrade the save logfile command (by default, the command
is in level 2) to level 3, you need to run the command-privilege level 3 view shell save
logfile command.
l To degrade a command, you need to attach the command in complete format to the
command-privilege level command.
For example, if you want to degrade the display current-configuration command (by
default, the command is in level 3) to level 2, run the command-privilege level 2 view
shell display current-configuration command.
NOTICE
If you use the command-privilege level 2 view shell display command to degrade the
display current-configuration command, only the display element is degraded to level
2 and the current-configuration element is still in level 3. The command level is the
same as the level of its command element in the highest level. Therefore, the display
current-configuration command is still in level 3, and users in level 2 cannot use the
command. In addition, other display commands will be affected. For example, the
display elements in the display startup command (by default, the command is in level
1) and the display atm service command (by default, the command is in level 0) are
upgraded to level 2 after the command-privilege level 2 view shell display command is
run. As a result, the display startup and display atm service commands are upgraded to
level 2, and users in level 0 and level 1 cannot use the commands. In conclusion, to
degrade a command, you need to attach the command in complete format to the
command-privilege level command.
7.2.1.6 Why Does the System Always Prompt that Configurations Are
Inconsistent After the compare configuration Command Is Run?
The compare configuration command is used to check the difference between the current
configuration and the configuration file for the current system startup.
If the current configuration is inconsistent with the configuration file for the current system
startup, you cannot run the save command to make them consistent, because the save
command is used to save the configuration to the configuration file for the next system
startup.


MainBoard:
Configured startup system software: cfcard:/
v300r008c00b050_jia_tao_zhou.cc
Startup system software: cfcard:/
Next startup system software: cfcard:/
Startup saved-configuration file: cfcard:/test.cfg -----------------
>Configuration file for the current system startup
Next startup saved-configuration file: cfcard:/test.cfg -----------------
>Configuration file for the next system startup
Startup paf file: cfcard:/paf_r7c03b50.txt
Next startup paf file: cfcard:/paf_r7c03b50.txt
Startup license file: cfcard:/license_r7c03b50.txt
Next startup license file: cfcard:/license_r7c03b50.txt
7.2.1.7 How to Collect the Command Running Time?

For versions later than V500R007C03, in order to optimize the startup performance, the
function of restoring command running time statistics is disabled by default. To use this
function to collect the running time of each command, add the following line into the PAF
file, and then reboot the device.
END SPECS SERVICE FOR PPP TEMP DOUBLE ROUTER MODULE
PAF_LCS_CLI_STATISTIC_ENABLE = 1,1 [END SERVICE]
7.2.1.8 a^ Can Match a^. Why Does a(^) Match Neither a^ Nor a(^)?
^ is not the first character of a^, so the special character ^ in a^ functions as a common
character. Therefore, a^ can match a^. In a(^), however, ^ is the first character of the sub-
expression (^). Therefore, ^ in a(^) functions as a special character. Because ^ matches the
beginning character of a string, the a in a(^) will find no match. Therefore, a(^) does not
match any string.
7.2.1.9 $a Matches $a. Why Does ($)a Match Neither $a Nor ($)a?
$ is not the last character of $a, so the special character $ in $a functions as common
character. Therefore, $a can match $a. In ($)a, however, $ is the last character in the sub-
expression in ($). Therefore, $ in ($)a functions as a special character. Because $ matches the
ending character of a string, a in ($)a will find no match. Therefore, ($)a does not match any
string.
7.2.1.10 Why Does abc$) Match Neither abc$) Nor abc?

When ) has no corresponding ( in a regular expression, this special character function as a
common character. Because $ matches the ending character of a string, ) in abc$) will find no
match. Therefore, abc$) does not match any string.
7.2.1.11 Why Does the display current-configuration | include 10.x.x.x Command

Output Include Information About Other IP Addresses?
In IP address 10.x.x.x, '.' is not a command character but a special character. Therefore, '.'
matches any single character.

The correct command should be written as:display current-configuration | include 10\.x\.x

\.x, '\' is an escape character in the regular-expression and marks the following character
(special or common character) as common character. So 10\.x\.x\.x matches 10.x.x.x.
7.2.1.12 Why Is All Configuration Information Displayed When the display

current-configuration | include 123|456| Command Is Executed?
x|y matches x or y. The second | in 123|456| matches null. Therefore, all configuration
information is displayed.
7.2.2 User Management
7.2.2.1 How Many Levels Can Users Logging in to the router Be Classified Into?
What Are Differences Between Them?
By default, users logging in to the router can be classified into four levels, ranging from level
0 to level 3.
l Users of level 0 can only log in to the router or perform ping and tracert operations.
l Users of level 1 can view basic status of the router. By default, users of level 1 cannot
run the display current-configuration command to check configurations of the router.
l Users of level 2 can perform any configuration operations except for AAA.
l Users of level 3 have the highest authority.
User levels and corresponding commands allowed to be used varies with versions. You can
degrade a command as required so that low-level users can use it.
To implement refined right management, you can further classify command levels and user
levels from 4 levels to 16 levels (level 0 to level 15). The level of the command that a user can
run is determined by the level of this user.
You can run the command-privilege level rearrange command to upgrade commands from
level 2 and level 3 to level 10 and level 15 respectively. After that, command levels 0 to 3
correspond to command levels 0, 1 to 9, 10 to 14, and 15.
NOTICE
Before configure this command, ensure that the user of the highest level has been configured.
The command-privilege level rearrange command takes effect once it is configured. If the
level of the current user is 3, after the command is run, the user becomes the low-level user
and is unable to run commands higher than level 3 (including level 3).
7.2.3 FTP
7.2.3.1 Why Does the Compressed Log File That Is Downloaded from the Device
Fail to Be Depressed?
When the name of the compressed file contains ":", the file fails to be depressed. In this case,
you can modify the file name by deleting ":" in WINRAR, and then decompress the file again.

7.2.3.2 Why Cannot a File Be Downloaded After the FTP Connection Is

Established with the Device Through the Relevant Windows Command Line?
The firewall function is enabled for the Windows system, preventing the FTP data connection.
After the firewall function is disabled, the FTP file transfer becomes normal.
7.2.3.3 Which Well-known Port Number Is Used by FTP?

The well-known port number (listening port number) of an FTP server is 21.
7.2.3.4 What Are the Functions of the ftp client-source and ftp server-source
Commands?
The ftp client-source command is used to specify the source IP address of a device when the
device functions as the FTP client. The source IP address can only be a loopback address.
The ftp server-source command is used to specify the source IP address of a device when the
device functions as the FTP server. The source IP address can only be a loopback address.
7.2.3.5 What Is the Function of the ftp timeout Command?

The ftp timeout command is used to set the idle time of the connection. For example, the
command ftp timeout 1 indicates that the system tears down the connection of a user if the
user logs in through FTP and has no action within one minute.
7.2.3.6 Why Does the Size of a File Change After the File Is Uploaded Through
FTP?
There are two FTP transmission modes, namely, binary transmission and text transmission.
When the text transmission mode is adopted, certain contents are automatically transformed
after the FTP transmission. Therefore, it is advised that the binary transmission mode be
adopted to transfer the binary file, such as the system software file.
7.2.3.7 Are application protocols such as FTP are disabled by default?

By default, application protocols such as FTP are disabled.
7.2.3.8 Why Does a PC, Working as an FTP Client, Fail to Upload a File?
1. The file name contains spaces, which divide the file name into multiple segments. The
device, however, cannot identify spaces and therefore cannot identify the file name.
2. The file name contains Chinese characters, which need to be changed to English
characters. The device does not support Chinese characters. Therefore, there is a
possibility that a Chinese file fails to be created.
3. The FTP client is faulty, causing a file transmission failure. After getting packets through
tools or enabling the TCP debugging function on the FTP client, you can view the
following information:
<HUAWEI> display debugging
TCP:
TCP packet source *.*.*.*:20 destination

*.*.*.*:*
TCP packet source *.*.*.*:* destination *.*.*.*:20
If the following information is output,

608 Oct 29 2010 10:59:28.250.1 HUAWEI SOCKET/7/TCP PACKET:
609 Checksum error, destroyed.
the network card is properly verified on the PC, or the PC is faulty. It is recommended to
replace the network card or PC.
4. If the file transmission failure is not caused by any of the preceding fault, check the
network. After got packets through tools, check whether packets are discarded during
transmission or other causes. Then contact the Huawei technical personnel.
7.2.4 Telnet
7.2.4.1 Why Does the Telnet Connection Fail on the Device?

Possible causes are:
l The route is unreachable, and the TCP connection cannot be established. In this case,
you can run the ping command to check whether the route is reachable.
l The number of users that log in to the device reaches the upper threshold. In this case,
you can log in to the device through a serial interface, and then run the display users
command to check whether the current VTY channels are all used.
l An ACL is bound in the VTY user interface view. In this case, you can add a rule in the
bound ACL to allow the user access.
l The access protocol is incorrectly specified in the VTY user interface view. For example,
when the protocol inbound ssh command is run in the VTY interface user view, the
telnet operation will fail.
7.2.4.2 Why Does a Client Fail to Telnet the Device When the IP Address of the
Client Is Not Denied in an ACL That Is Configured in a VTY User Interface
View?
If an ACL is configured in a VTY user interface view on the device, and the IP address of a
client is not specified in the ACL, the client is not allowed to telnet the device. To allow the
client to telnet the device, you need to permit the IP address of the client in the ACL.
7.2.4.3 Why Cannot the VTY Channels 16 to 20 (user-interface vty 16 20) Be

Logged in to?
The VTY channels 16 to 20 are reserved for the NMS. When the VTY channels 0 to 14 (user-
interface 0 14) are not used up, users will not log in to the VTY channels 16 to 20. In
addition, only the users with the net-manager type can log in to the VTY channels 16 to 20.
7.2.4.4 Why Does the Telnet Connection Fail After the Terminal Prompts that the
Password Is Not Set?
Before logging in to a device using Telnet, you must pass password authentication. You can
set a password in interactive mode for the first login. Alternatively, you can run the
authentication-mode aaa command to change the authentication mode to AAA.

7.2.4.5 Why Cannot the Commands Such as system-view Be Run After the
Password Authentication or Non-password Authentication Is Configured for the
Telnet Connection?
The cause is that the configuration is incorrect in the VTY user interface view. To be specific,
the privilege level of a user is low, and the user cannot run the high-level commands. To
rectify the fault, you need to run the user privilege level 3 command to change the user
privilege level to level 3.
7.2.5 TFTP
7.2.5.1 How Can TFTP Be Used to Upload and Download Files?

The device can only function as a TFTP client. If the device needs to function as a TFTP
server, you need to install a third-party software on the PC, and then run the tftp [ -a source-
ip-address | -i interface-type interface-number ] tftp-server [ public-net | vpn-instance vpn-
instance-name ] { get | put } source-filename [ destination-filename ] command to upload and
download files.
7.2.5.2 Why Does the TFTP File Downloading Stop After the Size of the
Downloaded File Reaches a Certain Size?
TFTP is a simple file transfer protocol. Each UDP datagram of TFTP carries 512-byte data
and a 16-bit serial number. If the number of UDP datagrams cannot be expressed by the 16-bit
serial number, the overflow of the serial number will occur. Certain types of third-party
software, however, cannot identify the overflow. As a result, only about 32 MB file can be
transferred. To rectify the fault, you need to change the problematic third-party software.
7.2.6 Info Center
7.2.6.1 How to View the Configuration of the Information Center Function?

You can run the display current-configuration | include info-center command to view the
configuration of the information center function.
7.2.6.2 How to Enable and Disable the Information Center Function?

The information center function is enabled by default. You can run the following commands
in the system view to change the status of the information center function.
l To disable the information center function, run:
[HUAWEI] undo info-center enable
After the information center function is disabled, the log function becomes unavailable.
l To enable the information center function, run:
[HUAWEI] info-center enable
You can run the following command to check the status of the information center function.
[HUAWEI] display info-center
The command output in the following example shows that the information center function is
enabled.

Information Center:enabled
Log host:
Console:
channel number : 0, channel name : console
Monitor:
channel number : 1, channel name : monitor
SNMP Agent:
channel number : 5, channel name : snmpagent
Log buffer:
enabled,max buffer size 1024, current buffer size 512,
current messages 512, channel number : 4, channel name : logbuffer
dropped messages 0, overwritten messages 43993
Trap buffer:
current messages 256, channel number:3, channel name:trapbuffer
logfile:
channel number : 9, channel name : channel9, language : English
Information timestamp setting:
log - date, trap - date, debug - date
Sent messages = 12373, Received messages = 691222
IO Reg messages = 91 IO Sent messages = 678850
7.2.6.3 How to Identify the CF Card Directory for Log Files

Usually, a device has two CF cards. By default, log files are stored in CF card 2. You can run
the following command to identify the CF card in which log files are stored.
<HUAWEI>display logfile-path slot 9
Info: Current log file path is "cfcard:/log".
7.2.6.4 How to Configure a Log Host?

You can run the following command to configure a log host:
info-center loghost ip-address [ channel { channel-number | channel-name } | facility local-

number | { language { english | chinese } ] *
You can run the following command to delete a log host:
undo info-center loghost ip-address
After a log host is configured, you can send logs in the standard format of SYSLOG to the log
host for parsing and display.
It is recommended that the default setting of the channel and language are adopted.
Parameters are described as follows:
l ip-address: indicates the IP address of the log host.

l channel: indicates the channel through which log messages are sent to the log host. The
channel can be specified by name or number. Each channel is configured with a filtering
table used to control the type of output messages (output log, alarm, or debugging) and
their levels. You can modify the filtering table of a channel as required, thus changing
the type of output messages and their levels.
l channel-number: indicates the channel number.
l channel-name: indicates the channel name.
l facility: sets the tool through which the log host stores log messages.

l local-number: indicates the tool through which the log host stores log messages. The
value ranges from local 0 to local 7. The default value is local 7. Based on the value of
the tool (from local 0 to local 7) and the log level, information center constructs the
identifier of the SYSLOG message and sends the SYSLOG message to the log host. The
log host parses the value of the tool and the log level according to the identifier. local-
number is optional and needs to be set when the log host has special focus on the
identifier and the log level.
l language: indicates the language in which log messages are recorded.
l english: indicates that log messages are recorded in English.
l chinese: indicates that log messages are recorded in Chinese.
If no parameter is specified, log messages are sent to the log host through channel 2 by
default, with the channel name being loghost, local-number being local 7, and language being
english.
The info-center loghost ip-address [ channel { channel-number | channel-name } | facility
local-number | { language { english | chinese } ] * command makes sense only when the
information center function is enabled.
You can assign an IP address to the log host and configure the IP address as the destination of
log messages. You can configure a maximum of eight log hosts for backup.
For example:
# Configure the HUAWEI NetEngine40E/80E to send log messages to the log host with its IP
address being 202.38.160.1.
[HUAWEI] info-center loghost 202.38.160.1
7.2.6.5 How to Filter Out a Log Message?

You can filter out log messages by module and log level.
Before filtering out a log message, you need to first identify the module from which the log
message is generated and the level of the log message. The following example describes how
to filter out a specific log message.
Mar 14 2009 18:48:11 HUAWEI %%01CFM/4/SAVE(l): When deciding whether to save
configuration to the device, the user chose N.
l CFM: indicates the module from which the log message to be filtered out is generated.
l 4: indicates the level of the log message to be filtered out.
After the module and log level are specified, you need to identify the destination of the log
message, for example, the log host.
You can run the following command to filter out the log message:
[HUAWEI] info-center source CFM channel 9 log level errors
After the command is run, only log messages with their levels being errors or higher than
errors and generated by the CFM are prevented from passing through channel 9. Log
messages passing through channel 9 are recorded and Buildrun information is displayed.
l CFM: indicates that log messages generated only by the CFM are filtered out. When
CFM is replaced by Default, log messages generated by all modules are filtered out.
l 9: indicates that log messages are prevented from passing through channel 9 to reach the
log host. Log messages passing through other channels are not affected.

l log: indicates that log messages are to be filtered out. Trap and debugging messages can
be output normally.
l errors: indicates that log messages with their levels being lower than errors are filtered
out. Log messages with their levels being errors and higher than errors are output. The
log level is inversely proportional to its corresponding digit. For example, 0 represents
the highest log level; 7 represents the lowest log level.
The channel number ranges from 0 to 9. You can run the display channel command to view
the channel number and its output destination.
<HUAWEI> display channel
channel number:0, channel name:console
MODU_ID NAME ENABLE LOG_LEVEL ENABLE TRAP_LEVEL ENABLE DEBUG_LEVEL
ffff0000 default Y warning Y debugging Y debugging
channel number:1, channel name:monitor

ffff0000 default Y warning Y debugging Y debugging
channel number:2, channel name:loghost

ffff0000 default Y informational Y debugging N debugging
channel number:3, channel name:trapbuffer

ffff0000 default N informational Y warning N debugging
channel number:4, channel name:logbuffer

ffff0000 default Y warning N debugging N debugging
channel number:5, channel name:snmpagent

ffff0000 default N debugging Y warning N debugging
channel number:6, channel name:channel6

ffff0000 default Y debugging Y debugging N debugging



For example, the output destination of channel 0 is a serial interface. If channel 0 is specified,
log messages to the serial interface are filtered out. You can specify the channel number as
required. Channels independently output log messages without affecting each other.
Channel numbers and corresponding output destinations are as follows:
l 0: a serial interface
l 1: a terminal, such as VTY
l 2: a log host
l 3: a trap buffer
l 4: a log buffer

l 5: an SNMP agent
l 6: reserved
l 7: reserved
l 8: reserved
l 9: a log file
After the configuration, you can run the display current-configuration | include info
command to check whether the specified log message is filtered out.
<HUAWEI> display current-configuration | include info
info-center filter-id bymodule-alias CFM CLEAR
snmp-agent sys-info version v3
Alternatively, you can run the display channel command to check whether the specified log
message is filtered out.
Parameters are described as follows:
l MODU_ID: indicates the module number. The value varies with modules. ffff0000
specifies all modules. If a module is specified, log messages generated by the module are
filtered out. If the module is not configured with a filtering table, the settings of ffff0000
are taken.
l NAME: indicates a module. The value default indicates all modules.
l ENABLE: indicates whether a channel is enabled. Y indicates that the channel is
enabled; N indicates that the channel is disabled.
l LOG_LEVEL: indicates the type of log messages to be output and their levels. This
parameter makes sense only after the channel is enabled.
l TRAP_LEVEL: indicates the type of alarm messages to be output and their levels. This
parameter makes sense only after the channel is enabled.
l DEBUG_LEVEL: indicates the type of debugging messages to be output and their
levels. This parameter makes sense only after the channel is enabled.
7.2.6.6 How Many Log Messages Can a Log Buffer Store?

At present, a log buffer can store a maximum of 512 log messages by default. You can run the
info-center logbuffer size buffersize command to configure a log buffer to store a maximum
of 1024 log messages.
7.2.6.7 How To Configure a HUAWEI NetEngine40E/80E to Log the User Login

Message?
You can run the info-center source { module-name | default } channel { channel-number |
channel-name } [ log { state { off | on } | level severity }* ]command to configure a HUAWEI
NetEngine40E/80E to log the user login message only when the level of the log server is five
or greater than five.
7.2.6.8 What Is the Default Level of Log Messages That Can Be Stored to the Log
Buffer?
By default, the lowest level of log messages that can be stored to the log buffer is four
(warning). That is, log messages of 0 to 4 levels can be stored to the log buffer, and log
messages of 5 to 7 levels cannot be stored to the log buffer.

[HUAWEI] display channel logbuffer

channel number:4, channel name:logbuffer
ffff0000 default Y warning N debugging N debugging
Run the info-center source default channel logbuffer log level severity state on command
in the system view to change the lowest level of log messages that can be stored to the log
buffer.
7.2.6.9 How to Clear a Log Message Through the info-center filter-id Command?
If a log message is repeatedly generated on a HUAWEI NetEngine40E/80E, you can do as
follows to clear it.
huawei %%01CFM/4/SAVE(l)[648]:The user chose Y when deciding whether to save the
configuration to the device.
Run the info-center filter-id id command to clear the specific log message.
[HUAWEI] info-center filter-id bymodule-alias CFM SAVE
7.2.6.10 How Can I Solve the Problem that the Log Host on a Device Fails to
Receive Logs?
Check whether the log host fails to receive all logs or only a single log.
l If the log host fails to receive all logs, do as follows to solve the problem:
a. Run the display info-center command to check the status of the information center
(the Information Center field). If the status is disabled, enable the information
center and check whether the log host can receive logs. If yes, the problem is
solved.
<HUAWEI> display info-center
Information Center:enabled
Log host:
the interface name of the source address:LoopBack0
10.233.50.15, channel number 2, channel name loghost,
language english , host facility local4
10.233.18.15, channel number 2, channel name loghost,
language english , host facility local4
Console:
channel number : 0, channel name : console
Monitor:
channel number : 1, channel name : monitor
SNMP Agent:
channel number : 5, channel name : snmpagent
Log buffer:
current messages 518, channel number : 4, channel name : logbuffer
Trap buffer:
current messages 46, channel number:3, channel name:trapbuffer
logfile:
channel number : 9, channel name : channel9, language : English
Information timestamp setting:
log - formate-date millisecond, trap - date, debug - date
Sent messages = 3221, Received messages = 3220
IO Reg messages = 8 IO Sent messages = 0
b. Run the display this command in the system view to check the log host
configuration.

info-center loghost source LoopBack0

info-center loghost 10.233.50.15 facility local4
info-center loghost 10.233.18.15
c. Check whether the log host is reachable.

Ping the IP address of the log host from the device. If the log host is unreachable,
check the network.
d. If the fault persists after you perform the preceding steps, contact the Huawei
l If the log host fails to receive only a single log, do as follows to solve the problem:
a. Verify the source module and level of the log that the log host fails to receive.
b. Run the display info-center command to check the current channel number of the
log host (the channel number 2 field).
c. Run the display channel command to check the configuration of the specified
channel.
<HUAWEI> display channel 2
channel number:2, channel name:loghost
MODU_ID NAME ENABLE LOG_LEVEL ENABLE TRAP_LEVEL ENABLE
DEBUG_LEVEL
ffff0000 default Y warning Y warning N
debugging
The command output shows whether the log of the module type and level can be
sent through the channel.
d. If the fault persists after you perform the preceding steps, contact the Huawei
7.2.6.11 Will Running the Command to Disable the Information Center Be

Logged?
Yes, running the command to disable the information center will be logged.
7.2.6.12 How Many Types of Timestamp Formats Does the Information Center
Support and How Can I Configure These Timestamp Formats?
At present, the information center supports five types of timestamp formats. Timestamp
formats are configured based on the information types. For example, if the timestamp format
configured for a certain type of information is log, the timestamp format of the information in
this type is log, regardless of through which channel the information is sent.
[HUAWEI] info-center timestamp ?
debugging Set the time stamp type of the debug information
log Set the time stamp type of the log information
trap Set the time stamp type of the alarm information
[HUAWEI] info-center timestamp log
[HUAWEI] info-center timestamp log ?
boot Information time stamp of relative time type
date Information time stamp of date type
format-date Information time stamp of date another type
none None information time stamp
short-date Information time stamp of short date type: (MM:DD)
The explanation of each timestamp format is as follows. By default, the information center
uses the date format.
l Boot
Information time stamp of relative time type

Indicates the relative time of the start time of the system.

For example: 0.152784750 210 %%01SRM/1/DDRTESTPOWEROFF(l)[0]: (<higher
order 32 bits of the milliseconds>.<lower order 32 bits of the milliseconds>)
l Date
Information time stamp of date type
Indicates the date format (MM DD YY).
For example: Feb 25 2010 08:16:10 210 %%01SRM/1/DDRTESTPOWEROFF(l)[0]
l format-date
Information time stamp of date another type
Indicates the standard time format.
For example: 2010-2-25 08:16:10 210 %%01SRM/1/DDRTESTPOWEROFF(l)
l None
None information time stamp
Indicates that no time information is displayed.
For example: 210 %%01SRM/1/DDRTESTPOWEROFF(l)[0]
l short-date
Information time stamp of short date type: (MM:DD)
Indicates that the year is not displayed.
For example: Feb 25 08:16:10 210 %%01SRM/1/DDRTESTPOWEROFF(l)
7.2.6.13 Why Are Some Old Log Files Uncompressed?

The newest log of a device is stored in the log.log file. If the size of log files reaches 8 MB on
the running device, the system will automatically generate a compressed log file named with
the current timestamp. If the device restarts and the size of log files reaches 8 MB, the system
will automatically generate a log file named with the current timestamp. However, to prevent
the compressed log file from affecting the restart of the device, the system will not compress
the log file. Therefore, when you check the log file after the device restarts, you will find that
some old log files are uncompressed.
7.2.7 SNMP
7.2.7.1 What Does the Log Message Saying "Failed to login through SNMP"
Mean?
The log message saying "Failed to log in through SNMP" indicates that SNMP packets are
failed to be parsed. Causes and workaround for such a log message are as follows:

Cause Workaround
The SNMP version on the NMS sent login 1. Run the display snmp-agent sys-info
requests is not v1, v2c, or v3. version command to check whether the
SNMP version on the host is v1, v2c, or
v3.
l If so, go to Step 2.
l If not, go to Step 3.
2. Run the snmp-agent sys-info version
command to configure the SNMP
version supported by the host. Then,
check whether the problem can be
solved.
3. Contact Huawei technical personnel.
4. End.
Packet bytes received by the host exceeds 1. Run the snmp-agent packet max-size
the threshold. byte-count command in the system view
to modify the maximum packet bytes
allowed on the host, and then check
whether the system still generates logs.
3. End.
The community string is configured 1. Run the display snmp-agent

incorrectly. community command to view the
community string configured for the host
is identical with that configured for the
host and NMS.
2. On the host, run the snmp-agent
community read command to configure
a read community string and the snmp-
agent community write command to
configure a write community string.
3. Check whether the NMS can
successfully log in to the host with the
correct community string.
5. End.

Cause Workaround
Requests sent from the IP address is denied 1. Run the display acl command to view
by the ACL. the ACL configuration. The command
output indicates whether the IP address
from which requests are sent is denied
by the ACL.
2. Run the rule permit source source-ip-
address source-wildcard command in the
ACL view to configure the ACL to
allow the IP address.
3. Check whether the NMS can log in to
the host.
5. End.
7.2.7.2 How to Configure Agent on a Host When the SNMP Version of the
Connected NMS and Host is v1, v2c, or v3?
All parameters are in italics; you can select parameters as required.
Run the following commands to configure agent on a host when the SNMP version of the
connected NMS and host is v1 or v2c.
[HUAWEI] snmp-agent
[HUAWEI] snmp-agent community read public
l Run the [HUAWEI] snmp-agent sys-info version v1 command to configure SNMPv1

on the host.
l Run the [HUAWEI] snmp-agent sys-info version v2c command to configure SNMPv2c
on the host.
The read community string configured for the NMS must be identical with that for the host.
Run the following commands to configure agent on a host when the SNMP version on the
connected NMS and host is v3.
[HUAWEI] snmp-agent
[HUAWEI] snmp-agent sys-info version V3
[HUAWEI] snmp-agent group v3 huawei_group privacy write-view testview notify-view
testview
[HUAWEI] snmp-agent usm-user v3 huawei_userhuawei_group
The user name used by the NMS for login must be identical with that configured on the host.

7.2.7.3 How to Configure an SNMPv3-Enabled Trap Host to Send SNMPv3

Alarm Messages?
You can do as follows to configure an SNMPv3-enabled trap host to send SNMPv3 alarm
messages. All paramters are in italics; you can select parameters as required.
[HUAWEI] snmp-agent
[HUAWEI] snmp-agent sys-info version V3
[HUAWEI] snmp-agent group v3 huawei_group privacy write-view testview notify-view
testview
[HUAWEI] snmp-agent usm-user v3 huawei_user huawei_group
[HUAWEI] snmp-agent target-host trap address udp-domain 1.2.3.4 params
securityname huawei_user v3
7.2.7.4 Why Does the walk Operation Performed by SNMP Agent Time Out on a
Certain Node?
The MIB is in the hierarchical tree structure. Each managed object (MO) is identified by a set
of nodes along the path from the root to the leaf node.
When the MIB browser enables SNMP agent to perform the walk operation on a certain node
having multiple empty tables, the SNMP agent searches for data in these empty tables, thus
causing the walk operation to time out. This problem can be solved by increasing timeout
period of the NMS.
7.2.7.5 Will an Alarm Message Be Generated in the Case of a Telnet Login

Failure?
No alarm message will be generated under either of the following conditions:
l Incorrect user name or password is entered when the NMS attempts to log in to a host
through the Console interface.
l Incorrect user name or password is entered when the NMS attempts to remotely log in to
a host through Telnet.
7.2.7.6 Does SNMP Check Packets Based on an ACL First Or Based on

Communities First?
SNMP first checks whether the community of a packet is null, then checks whether the packet
is permitted by an ACL, and then checks whether the community of the packet is correct.
1. SNMP checks whether the community of a packet is null.
– If the community of a packet is null, the system denies the packet and records a
login failure caused by an incorrect community.
– If the community is not null, go to Step 2.
2. SNMP checks whether the packet is permitted by an ACL.
– If the packet is not permitted by an ACL, the system records a login failure caused
by ACL denial.
– If the packet is permitted by an ACL, go to Step 3.
3. SNMP checks whether the community is correct. If the community is incorrect, the
system records a login failure caused by an incorrect community.

7.2.7.7 Why Are Communication Failure Reasons Different Since Source IP

Addresses Do Not Match the Configured ACL?
ACL rules are configured as follows:
snmp-agent
snmp-agent local-engineid 000007DB7FFFFFFF00002A74
snmp-agent community write Huawei acl 2000
snmp-agent community read GD-CDMA-RO acl 2000
snmp-agent community write GD-CDMA-RW acl 2000
snmp-agent community read JT-CDMA-RO acl 2000
snmp-agent sys-info version all
<HUAWEI> display acl 2000
Basic ACL 2000, 5 rules
ACL's step is 5
rule 35 permit vpn-instance CDMA-Outband source 10.231.152.41 0
rule 40 permit vpn-instance CDMA-Outband source 10.231.152.39 0
May 12 2009 08:39:38 GD-GZ-DGZ-CE-1.CDMA %%01SNMP/4/COMMUNITY_ERR(l): Failed to
login through SNMP, because the community was incorrect. (Ip=113.112.0.36,
Times=6)///The source IP address 113.112.0.36 does not match any of the ACL
rules. Why is a community error alarm displayed?
May 12 2009 08:38:03 GD-GZ-DGZ-CE-1.CDMA %%01SNMP/4/ACL_FAILED(l): Failed to
login through SNMP, because of the ACL filter function. (Ip=59.43.50.100,
Times=6)///The source IP address 59.43.50.100 does not match any of the ACL
rules. It should be a correct record.
Causes are as follows:
If the community contained in the request packet sent to the device is null or does not match
any of the communities configured on the device, the device will directly discard the packet
and displays a community error log, without matching the packet with the configured ACL
rules. The packet sent by the first host 113.112.0.36 does not match any of the configured
ACL rules, but the community in the packet is null. Therefore, a community error log is
displayed.
The packet will be matched with the configured ACL rules only when the community in the
packet is not null. The community in the packet sent by the host 59.43.50.100 is not null, but
the packet does not match any of the configured ACL rules. Therefore, it is recorded that the
packet is filtered out by the ACL.
7.2.7.8 How Are Alarm Types and Alarm Severity Defined? What Are the
Mappings Between Alarm Severity and IC Levels?
Alarms are classified into the following types:
l Alarm: SNMP_TRAP_TYPE_ALARM
l Clear alarm: SNMP_TRAP_TYPE_RESUME_TRAP
l Event (requiring reliability): SNMP_TRAP_TYPE_EVENT
l Event (not requiring reliability): SNMP_TRAP_TYPE_NO_REBILITY
Alarm severity indicates how severe a fault is. Based on the definition in the X.733 standard,
alarm severity in descending order includes:
l Critical
l Major
l Minor

l Warning
l Indeterminate
l Cleared
The mappings between alarm severity and IC are as follows:
l Critical: IC_LEVEL_ALERT
l Major: IC_LEVEL_CRIT
l Minor: IC_LEVEL_ERR
l Warning: IC_LEVEL_WARN
l Indeterminate: IC_LEVEL_NOTICE
l Cleared: IC_LEVEL_INFO
7.2.8 SSH
7.2.8.1 Why Cannot SSH Be Used to Log in to a Device After the CF Card of the
Device Is Replaced?
After the SSH function is enabled, a key pair is used to implement the encrypted
communication. The key pair is saved in the CF card. If the CF card is replaced, the key pair
file is lost, and thus the SSH function is disabled. In this case, you need to run the rsa local-
key-pair create command to regenerate the key pair.
7.2.8.2 Why Does the System Prompt that the Number of Public Keys Reaches the
Upper Threshold When the Device Functions as the STelnet Client?
When the device functions as the STelnet client to access SSH servers for the first time, the
device can save a maximum of 20 public keys of these SSH servers. If the device saves 20
public keys and needs to access other SSH servers, you need to run the following commands.
1. Run the display current-configuration command to check the pubic key information.
2. Run the undo ssh client servername assign rsa-key keyname command to unbind the
SSH servers from the public keys.
3. Run the undo rsa peer-public-key key-name command to delete the saved public keys.
7.2.8.3 How to Configure the router Serving as the SSH Server So That PCs or
Other Network Devices Can Log In to the SSH Server?
For configuration details, refer to "Example for Configuring the PC as the STelnet Client to
Connect to the SSH Server" in the HUAWEI NetEngine40E/80E Router Configuration Guide
- Basic Configurations.
7.2.9 System Clock
7.2.9.1 Why is the information about the daylight saving time lost after router is
upgraded to V600R002?
After router is upgraded to V600R002 from an earlier version, original information about the
daylight saving time is lost. You need to run the clock daylight-saving-time command to

reconfigure the daylight saving time after upgrade. The clock daylight-saving-time command
no longer supports the parameter one-year.
7.2.10 NTP
7.2.10.1 Can the NTP Clock Adjusting Period Be Modified?

No. The algorithm to adjust the NTP clock is implemented according to RFC 1305, and
cannot be modified at present.
7.2.10.2 Why Can Clock Synchronization Still Be Achieved When the

Authentication Key IDs Are Configured Differently on the Client and Server?
There may be different causes, requiring that you check the following configurations:
l Check that the client and server are enabled with the authentication function. That is,
check that the ntp-service authentication enable command is configured.
l On Server/Client mode, check that the authentication key ID is configured on the client.
That is, check that the following commands are configured.
– ntp-service unicast-server ip-address authentication-keyid key-id
– ntp-service unicast-peer ip-address ip-address authentication-keyid key-id
If the authentication key ID is not configured on the client, packets from the client are
transmitted in non-authentication-key mode in NTP, and the server does not authenticate
these packets.
7.2.10.3 What May Cause Clock Unsynchrnization?

After the synchronous connection is established with the clock source in NTP, a one-time
interaction is required after each poll interval (64s to 1024s). If the interaction fails, the
relevant information is recorded into the 8-bit shift register, namely, the reachability register.
When the reachability register is 0, the synchronization is lost; if the connection is dynamic,
the connection is deleted.
Therefore, unsynchronization will occur if network breakdown occurs or certain
configuration, such as the maximum number of dynamic connections, authentication code, or
time of the clock source, is changed. Note that the unsynchronization is not caused
immediately but after a certain period, mostly after eight poll intervals.
7.2.10.4 What Are the Meanings of the Following Logs? If the Following Logs
Repeatedly Appear, What Is the Implication on the Device?
l NTP/4/SOURCE_LOST(l): System synchronization source lost.
l NTP/4/LEAP_CHANGE(l): System leap changes from 3 to 0 after clock update.
l NTP/4/STRATUM_CHANGE(l): System stratum changes from 16 to 4 after clock
update.
l NTP/4/PEER_SELE(l): The peer selected by the system is 222.83.16.34.
The preceding logs show that the clock source is lost and then synchronized.
The repeated clock source loss and synchronization does not affect other services. It only
leads to the frequent NTP status change and affects the status of the local time. If the time of

the clock source is unchanged, the local time is unchanged. If the time of the clock source is
changed, the local time is changed accordingly.
The cause for the symptom may be the unsteady network, packet loss, or repeated time
change in the clock source. To determine the cause for generating these NTP logs, you need to
check the relevant debugging information.
7.2.10.5 What Is the Relationship Between Time Zone/Daylight Saving Time and
NTP?
NTP is only concerned with the UTC time, and the UTC time does not vary according to the
time zone/daylight saving time. Therefore, adjusting the NTP time is adjusting the UTC time.
After the NTP statuses of the server and client are synchronized, the UTC time of the two
devices become consistent.
The display clock command is used to display the local time of the device, that is, UTC + the
offset of time zone/daylight saving time.
7.2.10.6 Is It Normal to Find that the NTP Clock Status Is Unsynchronized?

It depends on the specific configurations:
l If NTP is not configured on a device, it is normal because the default NTP clock status of
the device is unsynchronized.
l If NTP is configured and certain clock source servers are specified on a device, the
unsynchronized clock status may be abnormal, which requires further analysis.
7.2.10.7 Do Huawei Devices Support NTP V4?

Yes. Huawei devices support NTP V1 to V4.
7.2.10.8 What Does the NTP Stratum Mean?

Stratum, as an important concept in NTP, is considered as a metric value for clock accuracy.
Stratum 1 indicates the highest clock accuracy, and clock the accuracy decrease from 1 to 15.
Stratum 16 indicates that the relevant clock is not synchronized.
7.2.10.9 Why Flapping and Unsynchronization Occur After Multiple Clock

Sources Are Specified and the Clock Synchronization State Is Entered?
In the NTP application, an optimal clock source is selected as the system clock source from
multiple synchronized clock sources. The corresponding algorithms are complicated,
involving clock filtering, clock selection, and clock mitigation. After multiple clock sources
pass clock filtering and clock selection and become candidate clock sources, the clock
mitigation algorithm adjusts the local clock based on a weighted average algorithm,
considering offsets of multiple clock sources.
The reason for using the clock mitigation algorithm is that the network environments are
various for the packets of multiple precise clock sources to reach the local clock.
l For example, if a clock source has a high level of precision but is far from the local
clock, or the network environment is harsh, the clock source may provide the clock
reference with a large error for the local clock.
l If another clock source has a low level of precision but is near to the local clock, the
clock source may provide the clock reference with a small error for the local clock.

In such a case, how to calculate a proper error correction value based on multiple clock
sources? The clock mitigation algorithm provides the answer. Note that the algorithm assumes
that multiple remote clock sources are precise.
The clock mitigation algorithm, however, is not a cure-all solution. If multiple clock sources
are not synchronized to the same clock source or these clock sources have large time
differences, the local clock may flap and lose synchronization after running the clock
mitigation algorithm. In another scenario, the precision levels and conditions of multiple
clock sources are almost the same. As a result, clock source switching may occur because it is
difficult for the clock mitigation algorithm to calculate an optimal clock source.
7.2.10.10 How Great the Clock Deviation Is When the Client Loses
Synchronization with the Server?
Strictly speaking, clock deviation is not directly related to clock asynchronization. When the
clock deviation is too great and the weight value is calculated as greater than 16 seconds
based on the NTP clock selection algorithm, the client cannot select an effective clock source.
This failure causes clock asynchronization on the client.
If the clock deviation exceeds 128 ms, the local clock fails to be updated for 15 minutes.
During this period, the following situations may occur:
l If the packets from the server can still pass the validity test, the client will synchronize
with the server, but the client does not update the time. The client will update the time in
15 minutes.
l If the packets cannot pass the verification, the client will change to the asynchronization
state after eight consecutive polling intervals.
NOTE
By viewing the clock status field displayed in the display ntp-service status command output, you can
check whether the NTP is in the synchronization state.
7.2.10.11 How Long Does It Take to Change the Asynchronization State to the
Synchronization State on the Client?
The clock synchronization duration is determined by the polling interval on the client and the
time data from the server. Generally, the duration varies from a few seconds to eight polling
intervals.
If the effective clock source has been selected based on the NTP clock selection algorithm,
the client can change to the synchronization state. If the effective clock source has not been
selected, the clock asynchronization state may last for a long period of time.
7.2.10.12 What Is the Interval at Which the Client Sends Request Packets to or
Receives the Response Packets from the Server?
According to the NTP protocol, the default minimum interval at which the client sends
requests packets to the server is 64 seconds and the default maximum interval at which the
client sends requests packets to the server is 1024 seconds.
You can also specify the minimum and maximum interval by configuring the parameters of
minpoll and maxpoll in the ntp-service unicast-server command.
NOTE
The minpoll and maxpoll are parameters with values as exponents of 2.

The server sends response packets to the client immediately after receiving request packets.
7.2.10.13 How to Maintain the Synchronization State?

The synchronization state is affected by many factors. Of these factors, smooth network
connectivity and a stable clock source are vital to maintaining the synchronization state.
The client periodically sends request packets to the server. If the server responds to the
packets in time, the synchronization state is maintained. The client may change to the
asynchronization state if the following situations occur:
l The client authenticates the identity and connectivity of the server by checking whether
response packets are received. If the response packets are not received at eight
consecutive polling intervals, the client will change to the asynchronization state.
l Clock data carried in the response packets are used to select the clock source. If the
effective clock source cannot be selected, the client will change to the asynchronization
state.
If the client can obtain the effective response packets at two consecutive polling intervals, the
polling interval will double to a maximum of 1024 seconds. The clock will be working
according to the new polling interval.
7.2.11 1588v2
7.2.11.1 What Need to Be Noted on the Access on the BITS Interface?

You can use the display ptp all command to check the access of BITS signals on a device. If
an interface is connected the BITS, the information about the correct BITS configuration
should be as follows:
Clock Pri1 Pri2 Accuracy Class TimeSrc Signal Switch Direction In-Status
------------------------------------------------------------------------
BITS0 128 128 0x20 6 2 dcls on in/out normal
BITS2 128 128 0x20 6 2 1pps on in/- normal
That is, it is required that the format of the BITS input signals is configured, the BITS
interface is added to the election sources, and the GPS is connected to the BITS interface.
7.2.11.2 What Need to Be Noted for the Configuration of a TCandBC Device?

The following should be noted:
l After an interface is configured as a TC interface, you need to configure the domain on
the interface separately. The configured domain must be the same as the configuration on
the user side.
l The domain of the BC interface is the same as the domain configured in the system view.
Therefore, the domain of the BC interface does not need to be configured separately on
the interface.
7.2.12 NetStream

7.2.12.1 Why Cannot GRE Tunnel Interfaces Be Configured with the Command
that Enables NetStream Sampling?
Only GRE tunnel interfaces on the TSU boards can be enabled with the NetStream sampling
function. Boards other than the TSU cannot be enabled with the Netstream sampling function.
7.2.12.2 When the ip netstream mpls-aware ip-only Command Is Configured, the

Message "Error: Please disable mpls-label aggregation first." Is Prompted. Why?
l Running the ip netstream mpls-aware command configures the sampling mode for
MPLS packets. On an MPLS network, the MPLS label carries important information that
users are concerned about. If the ip netstream mpls-aware command is not configured,
the device only collects IP information carried in the inner MPLS packets.
l Running the ip netstream aggregation mpls-label command enables the NetStream
aggregation mode. In NetStream aggregation mode, packets are classified based on six
key values of NetStream flows, that is, the first layer label, second layer label, third layer
label, TopLabelIpAddress, stack bottom symbol of the first layer label, and the EXP
value of the first layer label.
When the sampling mode of MPLS packets is set to ip-only, you cannot enable MPLS-label
aggregation.
7.2.12.3 Why Cannot the VE Interface Be Configured with the NetStream

Sampling Command?
The VE interface may have been configured with the ve-group group-id l3-access command.
The ve-group group-id l3-access command sets the VE interface as the L3VE interface that
accesses the MPLS L3VPN.
7.2.12.4 What Is ACL-based Sampling?

With the ACL-based sampling, only traffic that passes the ACL filtering is sampled.
The configuration process is as follows:
1. Configure traffic classifier.

[HUAWEI] traffic classifier c operator or
[HUAWEI-classifier-c] if-match any
2. Configure a traffic behavior.

[HUAWEI] traffic behavior b
[HUAWEI-behavior-b] ip netstream sampler fix-packets 1
3. Configure a traffic policy.

[HUAWEI] traffic policy p
[HUAWEI-trafficpolicy-p] classifier c behavior b
4. Apply the ACL-based sampling to an interface.

[HUAWEI] interface gigabitethernet11/0/0
[HUAWEI-GigabitEthernet11/0/0] traffic-policy p inbound
7.2.12.5 How About the Output Format of NetStream Packets?

RFC 3954 defines the following output format.

Field Va Leng Description

Type lu th
e (byt
es)
IN_B 1 N Incoming counter with length N x 8 bits for the number of bytes
YTES associated with an IP Flow. By default N is 4.
IN_PK 2 N Incoming counter with length N x 8 bits for the number of packets
TS associated with an IP Flow. By default N is 4.
FLOW 3 N Number of Flows that were aggregated; by default N is 4.

S
7.2.12.6 How many types of licenses are there for NetStream services?
There are two types of license for NetStream services:
l License for the integrate NetStream function
The license for the integrate NetStream function is used to control the number of
NetStream boards enabled with the integrate NetStream function.
The number of registered NetStream board on a device is determined by the license for
the integrate NetStream function. If the number of NetStream board to be registered is
greater than the license requirement, the configuration command does not take effect.
l License for the distributed NetStream function
After the license for the distributed NetStream function is installed, the distribute
NetStream function of the entire device is available. The value 0 indicates that the
license for the distributed NetStream function is not installed; the value 1 indicates that
the distributed NetStream function is installed.
7.2.12.7 How to control NetStream services through a GTL license?

Run the ip netstream sampler to slot { self | slot-id [ backup ] } command in the view of the
slot where the board is enabled with the sampling function to configure the NetStream board
to work in integrate mode or in distributed mode. This command is controlled by a GTL
license.
7.2.12.8 How to check the status of the GTL license?

You can run the display license command to check the status of the GTL license.
l If the information "Info: License activated does not exist on master board." is displayed,
it indicates that the GTL license is not enabled.
l If, the following information is displayed, it indicates that the GTL license is enabled.
<HUAWEI>display license
-------------------------------------------------------------
……
LCR5NETSTM06 Resource 32 ENHANCE_NS
……
l The value of the item LCR5NETSTM06 indicates maximum number of NetStream

boards allowed by the license for the integrated NetStream function.

7.2.12.9 What should be noted when configuring the ip netstream sampler

command?
l This command can be configured only on the interface board rather than the NetStream
service processing board (except for the NetStream service processing board working in
distributed mode).
l When configuring this command on the interface board, ensure that the destination of the
sampling information must be a NetStream service processing board (working in
integrate or distributed mode).
l When the destination of the sampled information is or the NetStream service processing
board working in integrate mode, ensure that the GTL license has been installed.
Otherwise, the command cannot be configured.
7.2.12.10 What is the aging time of a NetStream flow used for and what is the
difference between the active aging time and the inactive aging time?
The aging of a NetStream flow refers to that the NetStream flow in the cache is packed into a
NetStream packet and sent to the NMS.
By configuring an aging time for a NetStream flow, you can determine the time when the
NetStream flow in the cache is packed and output.
The description of the active aging time and inactive aging time is as follows:
l Active aging time: When the active time of a NetStream flow (the time when the flow is
created to the current time) exceeds the set active aging time, the NetStream flow is
aged.
The system does not immediately age a flow in the cache when the active time of the
flow exceeds the active aging time until a new flow enters the cache.
l Inactive aging time: When the inactive time of a NetStream flow (the time when the last
packet of the flow arrives to the current time) exceeds the set inactive aging time, the
NetStream flow is aged.
Once the inactive time of a flow exceeds the set inactive aging time, the system ages the
flow immediately regardless of whether the active aging time of the flow is not expired.
7.2.12.11 Do both the active aging time and the inactive aging time of a
NetStream flow need to be configured with values manually? What are the
configuration notes?
Both the active aging time and the inactive aging time have default values. You can configure
values for them as required. By default, the active aging time is 30 minutes and the inactive
aging time is 30 seconds.
Note the following items when configuring the active aging time and the inactive aging time:
l Packets of the active flow are sent consecutively. You are recommended to increase the
sampling period to obtain more information. Therefore, the active aging time is greater
than the inactive aging time.
l The inactive flow has no packet to be sent and can be directly output. Therefore, the
inactive aging time is smaller than the active aging time.

7.2.12.12 Will services be affected when the ip netstream sampler fix-packets

command is run to change the interval at which packets are sampled?
In the ip netstream samplerfix-packets packet-interval command, packet-interval indicates
the regular packet interval at which packets are sampled.
When this parameter is changed, statistics about the sampling result will be affected.
7.2.12.13 What is the function of specifying a source IP address through the ip

netstream export source command?
The source IP address specified through the ip netstream export source command will be
encapsulated into the NetStream packet header as the source IP address of the NetStream
flow.
You can configure any IP address can be specified as the source IP address of the NetStream
packet without considering the outbound interface of the NetStream packet. The interface
through which the NetStream packet is output is determined by the route between the device
and the packet analysis device.
7.2.12.14 Why the NMS Does Not Receive Template Packets?

Possible causes are as follows:
l The destination address and the destination interface are configured incorrectly.
l The aggregation function is disabled.
l The aggregation function is enabled before the destination address and the destination
interface are configured. As a result, the sending of template packets fails for the first
time. The NMS can receive template packets next time when the template is updated. By
default, the interval for updating the template is 30 minutes. You can change the value by
running the ip netstream export template timeout-rate minute command.
l The NMS runs after the configuration. If the NMS does not receive template packets, it
waits for the template to be refreshed next time.
7.2.12.15 Can the ip netstream mpls-aware ip-only Command and MPLS

Aggregation Be Enabled at the Same Time?
Yes. There is no traffic in the cache for MPLS aggregation. The MPLS aggregation traffic,
however, carries no label information. Therefore, configure the sampling function by running
the ip netstream mpls-aware label-only or ip netstream mpls-aware label-and-ip
command when using MPLS aggregation.
7.2.13 NQA
7.2.13.1 Why Does the NQA Test Result Display the Packet Discard Rate of 100%
When the Network Can Be Pinged?
The default maximum TTL value that NQA tests support is 30. The default maximum TTL
value that the ping command supports is 255. Therefore, testing TTL times out in the NQA
test.

7.2.14 Online Packet Header Obtaining
7.2.14.1 Q: Can Multiple Interfaces Perform Online Packet Header Obtaining at

the Same Time and How Is The Packet Information Displayed?
A: Multiple interfaces can obtain packet headers online in a single direction based on ACL
rules at the same time. All information is saved in a single file. Information about theses
packets on multiple interfaces can be displayed together.
7.2.15 LLDP
7.2.15.1 Why Cannot Neighbors Be Discovered When the Two Devices Are
Enabled with LLDP?
l LLDP is disabled on ports.

l The configured interval for sending LLDP frames is too long.
l Transparent transmission of LLDP frames is configured on routers.
7.2.16 Log and Alarm Files
7.2.16.1 What are modes of sending trap messages to the NMS and what is the
default mode?
Trap messages can be sent to the NMS in base-trap mode or dc-trap mode.
By default, trap messages are sent to the NMS in base-trap mode.
You can run the snmp-agent trap type { base-trap | dc-trap } command to configure the
mode of sending trap messages to the NMS.
7.2.16.2 How to change the storage path of a log message?

You can run the set logfile-path slotslot-id { cfcard | cfcard2 } command in the system view
to change the storage path of a log message.
By default, the log message is saved to CF card 2.
slot-id in the preceding command can only specify the master MPU/SRU. To change the
storage path of a log message on a slave MPU/SRU, you need to first perform the master/
slave switchover of the MPUs/SRUs and then run the set logfile-path slotslot-id { cfcard |
cfcard2 } command.
After log messages are output to a specified CF card, a file named log will be created on the
CF card. All log messages generated by the device will be saved to this file.

7.2.16.3 Why the system prompts a CRC error when the log file is decompressed?
By default, the log file is downloaded to a device from another device through FTP in ASCII
mode. If the operation systems of the two devices are different, the system prompts a CRC
error.
You are recommended to download log files in binary mode.
7.2.16.4 What is the function of the logfilebuf.dat file in the CF card?

The logfilebuf.dat file records information about system startup and is generated during the
system startup. After the startup, no information will be added to the file.
Each time the system starts up, the latest startup information overrides the previous startup
information in the logfilebuf.dat file.
7.2.16.5 By default, the log buffer saves log messages of which levels? Will the
log buffer records log messages about the command execution?
By default, the log buffer saves log messages of levels 0, 1, 2, 3, and 4 and does not save log
messages of levels 5, 6, and 7.
By default, the log buffer does not record log messages about the command execution. Log
messages about the command execution are of level 5 and log messages about the display
command are of level 6.
7.2.17 Tracert
7.2.17.1 In the case that there are multiple equal-cost links and the default per-
destination load balancing mode is adopted, why the tracert test result outputs
the interface IP address of each equal-cost link?
In per-destination load balancing mode, before forwarding a packet, the device calculates a
cost value through the hash algorithm according to the quintuple information of the packet,
including the protocol type, source IP address and mask, destination IP address and mask,
source port number, and destination port number. Then, the device chooses a link according to
the cost value to forward the packet.
UDP packets are used in the Tracert test. The destination port number is sum of the specified
port number and the sequence number of the packet to be sent. By default, the destination port
number is 33433 and the sequence number of the packet starts from 0 and is increased by 1.
The destination port number of the UDP packet in the tracer test changes. As a result, the hash
result changes and the chosen route also changes. Therefore, the Tracert test result outputs the
interface IP address of each equal-cost link.
7.2.17.2 In per-destination load balancing mode, why all hops except the first hop
of packets in the Tracert test are identical?
In per-destination load balancing mode, the hash algorithm is based on the quintuple
information of the packet. The Tracert test sends three UDP packets each time, with the
destination port number in the UDP packet being increased by 1.

The first link for forwarding a UDP packet is calculated according to the quintuple
information of the packet through the hash algorithm. The destination port number of each
UDP packet is different, and therefore the obtained first hop is different.
In per-destination load balancing mode, UDP packets are forwarded as common packets in
the second link and later, and therefore the other hops of UDP packets are identical.
7.2.18 GTL License
7.2.18.1 What is the impact if the GTL license fails to be activated?

If the GTL license is not activated, contact Huawei technical personnel.
7.2.18.2 How to check whether the GTL license is activated?

Run the display license command in the system view to check whether the master MPU/SRU
or the slave MPU/SRU enters the trial period.
If the following prompt is displayed, it indicates that the MPU/SRU has entered the trial
period.
License can't be verified, remain xx hours xx minutes to use current configure,
change for authentic license before time exhaust.
In this case, you need to analyze its causes to avoid the reset of the slave MPU/SRU after the
trial period expiration.
7.2.18.3 What Are the Differences Between PAF/License Files and GTL Files?
What Are the Deployment Scenarios of These Files?
A PAF/license file is suffixed with .text and delivered with the system software package
suffixed with .cc. The file can be customized or modified based on customer requirements.
During startup, the system reads the PAF/license file to obtain device configurations, such as
specifications and attributes. The PAF/license file is provided to customers free of charge.
Deployment scenario of a PAF/license: During system startup, the startup command can be
used to specify a PAF/license file. If no PAF/license file is specified, the device uses the
default PAF/license file of the system software. In this case, the PAF/license field is displayed
as default in the display startup command output.
A GTL file is suffixed with .dat and is not delivered with the system software package. Users
need to apply for GTL files at license.huawei.com based on contract numbers and board
ESNs. The users are charged based on the number of resource items and function items in
their contracts. A GTL file has a digital signature, and the contents of the GTL file cannot be
modified. A GTL file is bound to boards and must be purchased.
Deployment scenario of GTL files: Users purchase GTL files to implement additional
functions, features, and perform capacity expansion.
7.3 How Can I Use the Self-Loop Function to Detect the

Ping Failure on an Interface?
The self-loop function can detect loops on an interface, and block the interface to avoid
broadcast storms.

If the ping operation fails on an interface in the Up state, you can run the display this
interface command to check whether the interface is blocked against loops.
l If Loopback-detect: Loopback is displayed in the command output, self-loop function

is enabled on the interface, and the interface is blocked against loops, causing a ping
failure.
l If Loopback-detect: None is displayed in the command output, self-loop function is
enabled on the interface, but no loop occurs on the interface. The ping failure is not by
the blocking of the interface.
l If Loopback-detect: Loopback and Loopback-detect: None are not displayed, self-
loop function is disabled on the interface. Checking whether a loop occurs on the
interface is recommended.
7.3.1 Ethernet Interfaces
7.3.1.1 What Are Meanings of Fields in the Output of the display interface
Command Displaying Information on a 10GE Interface?
Statistics about a 10GE interface are described as follows:
Statistics About Incoming Traffic
Field Description Cause and Solution
Unicast Indicates the number of unicast These statistics are collected

packets. at the data link layer. This
field indicates the number of
the unicast packets (the
lowest bit in the first byte of
a MAC address is 0) that
pass the check at the physical
layer.
Multicast Indicates the number of correct These statistics are collected

multicast packets. at the data link layer. This
the multicast MAC addresses
(the lowest bit in the first
byte of a MAC address is 1)
that pass the check at the
physical layer.
Broadcast Indicates the number of correct These statistics are collected

broadcast packets. at the data link layer. This
the broadcast MAC
addresses (48 bits of a MAC
address are all 1s) that pass
the check at the physical
layer.

Jumbo Indicates the number of jumbo

Ethernet frames longer than 1518
bytes, including the Layer 2 header.
CRC Indicates the number of packets This is a type of error

whose CRC codes calculated on the counting at the physical
receiving end are different from the layer. CRC errors are
CRC codes carried in the packets. generally caused by link
quality problems, and
therefore you need to check
the link and optical modules
on the two ends of the link.
Symbol Indicates the number of physical

decoding errors where 10-bit data
cannot be converted into 8-bit data at
the PHY chip.
Overrun Indicates the number of packets

overflowing the FIFO queue.
InRangeLength Indicates the number of frames

whose length does not match the
actual length when the value in the
length/type field ranges from 46 to
1500. When the value in the length/
type field ranges from 0 to 45,
statistics about this field are not
collected.
LongPacket Indicates the number of frames

whose length is longer than the
maximum frame length, without
errors of other types.
Jabber Indicates the number of frames

whose length is longer than the
maximum frame length, with CRC
errors.
Alignment Indicates the number of frames

whose length is longer than 64 bytes
but shorter than 1518 bytes, with
CRC errors and alignment errors.
Fragment Indicates the number of frames

whose length is shorter than the
minimum frame length (64 bytes, not
including the 4-byte CRC field), with
CRC errors.

Undersized Frame Indicates the number of frames

whose length is shorter than the
minimum frame length (64 bytes, not
including the 4-byte CRC field),
without errors of other types.
RxPause Indicates the number of received

flow control frames, which may
interrupt packet sending on an
interface.
Statistics About Outgoing Traffic
Type Description Cause and Solution
Unicast Indicates the number of unicast This is a type of packet

packets. counting at the data link
layer. This field indicates the
number of unicast packets
(the lowest bit in the first
byte of the MAC address is
0) sent to the physical layer.
Multicast Indicates the number of multicast This is a type of packet

layer. This field indicates the
number of packets with
multicast MAC addresses
sent to the physical layer
(that is, the lowest bit in the
first byte of the MAC
address is 1).
Broadcast Indicates the number of broadcast This is a type of packet

layer, including the number
of packets with broadcast
MAC addresses sent to the
physical layer (that is, 48 bits
of a MAC address are all 1s).
Jumbo Indicates the number of jumbo

Ethernet frames that are encapsulated
with Ethernet header and longer than
1518 bytes.
Lost Indicates the total number of

discarded frames.

Statistics About Outgoing Traffic
Type Description Cause and Solution
Overflow Indicates the number of packets

overflowing the FIFO queue.
Underrun Indicates that the FIFO becomes

empty before an internal End-Of-
Packet indicator is read.
TxPause Indicates the number of flow control

frames that are sent to instruct the
peer to stop sending packets.
7.3.1.2 Do Traffic Statistics About Sub-interfaces Include Layer 2 Header Length?

Yes, traffic statistics about sub-interfaces include Layer 2 header length.
7.3.1.3 Q: Why Does the VLL Bound to a Sub-interface Change to Down After the
MTU of the Main Interface Is Changed and the shutdown and undo shutdown
Commands Are Run on the Sub-interface?
Two ends of a VLL need to perform MTU negotiation. When the VLL is Up, if the MTU of
one end is changed, you must run the shutdown command and the undo shutdown command
on the interface to validate configuration changes. The device also gives related prompts.
NOTE
Note the following points when changing the MTU:
l The shutdown and then undo shutdown commands must be run on the interface after the MTU of
the interface is changed.
l The MTU of the remote end must be changed accordingly; otherwise, the VLL cannot be Up.
7.3.2 Eth-Trunk Interfaces
7.3.2.1 What Is the MAC Address of an Eth-Trunk Interface?

The MAC address of an Eth-Trunk interface on a device is the MAC address of GE 0/0/0 on
this device.
7.3.2.2 What Is the MAC Address of a VLANIF Interface?
The MAC address of a VLANIF interface on a device is the MAC address of GE 0/0/0 on this
device.
7.3.2.3 Can Interfaces on interface boards of Different Types Be Bundled into a

Trunk Interface on the NE40E&NE80E?

The NE40E&NE80E supports inter-board trunk, and therefore interfaces on interface boards
of different types can be bundled into a trunk interface.
7.3.2.4 Can Optical Interfaces and Electrical Interfaces on the Same LPU Be
Bundled into One Eth-Trunk Interface?
Yes.
7.3.2.5 After Being Bundled into a Trunk Interface, Can Two GE Interfaces
Working in 100 Mbit/s Full-Duplex Mode on the NE40E&NE80E Communicate
with a Trunk Interface with 100 Mbit/s Member Interfaces on Another Device?
Yes. Note that the peer trunk interface must have two GE interfaces working in 100 Mbit/s
full-duplex mode.
7.3.2.6 Can a User Check Statistics About Physical Interfaces of a Trunk Interface
by Using the Network Management Software?
Statistics about physical interfaces of a trunk interface are implemented in Huawei private
MIB. Users using the non-Huawei partner network management system software cannot
check these statistics.
7.3.2.7 Can a GE Interface Working at 100 Mbit/s Full-Duplex Mode and an FE

Interface Working at 100 Mbit/s Be Bundled into the Same Trunk Interface?
Yes.
7.3.2.8 How Many Load Balancing Modes Supported by the Trunk Module?
What Are Differences Between Them?
There are two load balancing modes, namely, per-packet load balancing and per-destination
load balancing.
l Per-packet load balancing ensures high bandwidth usage but not the packet sequence.
l Per-destination load balancing ensure the packet sequence but not high bandwidth usage.
7.3.2.9 What Is the Function of the load-balance { ip | mac | packet-all }

Command in the Eth-Trunk Interface View?
The load-balance command is used to configure a load balancing mode. In this command:
l ip indicates load balancing according to source and destination IP addresses.
l mac indicates load balancing according to MAC addresses.
l packet-all indicates load balancing according to all the packets.
7.3.2.10 Why a Log Is Generated Five Minutes After an Eth-Trunk Interface

Changes from Down to Up?
The problem is described as follows:
After the undo shutdown command is run on Eth-Trunk 1, the following log information is
displayed:

Aug 4 2009 04:40:39 HUAWEI %%01SHELL/5/CMDRECORD(l): Record command information.

(Task=vt0, Ip=115.168.136.17, User=liubao, Command="undo shutdown")
# Eth-Trunk member interfaces report the Up event to the interface board immediately after
the Eth-Trunk interface goes Up.
#Aug 4 04:40:40 2009 HUAWEI IFNET/4/IF_PVCUP:OID 1.3.6.1.6.3.1.1.5
.4 Interface 67109121 turned into UP state.
Aug 4 2009 04:40:40 HUAWEI %%01PHY/4/PHY_STATUS_UP(l):-Slot=1;
GigabitEthernet1/0/0: change status to
up.
Aug 4 2009 04:40:40 HUAWEI %%01PHY/4/PHY_STATUS_UP(l):-Slot=1;
GigabitEthernet1/1/0: change status to up.
# The IFNET module of the main control board reports the Up event five minutes after the
Eth-Trunk interface goes Up.
Aug 4 2009 04:40:47 HUAWEI %%01SHELL/5/LOGOUT(l): liubao logout fr
om 115.168.136.17.
Aug 4 2009 04:40:48 HUAWEI %%01SHELL/5/CMDRECORD(l): Record command information.
(Task=vt0, Ip=**, User=**, Command="undo debugging all")
Aug 4 2009 04:45:42 HUAWEI %%01BFD/6/STACHG_DWNTOUP(l):-Slot=1; Slot BFD session
changed from Down to Up. (SlotNumber=1, Discriminator=8102)
# The L2IF module of the main control board reports the Up event five minutes after the Eth-
Trunk interface goes Up.
Aug 4 2009 04:45:42 HUAWEI %%01L2IF/6/PORT_UP(l): The status of port Eth-Trunk1
turns Up.
# The trunk module of the main control board generates a log to record the Up event five
minutes after the Eth-Trunk interface goes Up.
Aug 4 2009 04:45:42 HUAWEI %%01LSPM/6/SLOTOTHEREVENT(l): Got interface event UP
and address 0.0.0.0 in interface Eth-Trunk1.1000.
Aug 4 2009 04:45:42 HUAWEI %%01IFNET/4/LINKNO_STATE(l): The line protocol on the
interface Eth-Trunk1.1000 has entered the UP state.
Aug 4 2009 04:45:42 HUAWEI %%01LSPM/6/SLOTOTHEREVENT(l): Got interface event UP
and address 0.0.0.0 in interface Eth-Trunk1.1100.
Aug 4 2009 04:45:42 HUAWEI %%01IFNET/4/LINKNO_STATE(l): The line protocol on the
interface Eth-Trunk1.1100 has entered the UP state.
Aug 4 2009 04:45:42 HUAWEI %%01TRUNK/5/TRUNKUP(l): The status of interface Eth-
Trunk1 turns Up.
By analyzing the preceding logs, you can find that the device is configured with BFD for Eth-
Trunk member interfaces. By checking the configuration file, you can find that the wtr 5
command is configured in the BFD view, which causes the trunk module to generate a log
indicating the Up event five minutes later. Details are as follows:
<HUAWEI> display current-configuration | include wtr
wtr 50
7.3.2.11 Which LPUs Support Link Aggregation?

All LPUs support link aggregation.
l In ordinary link aggregation mode (trunk), link aggregation can be implemented on
LPUF-21As, on LPUBs, and between LPUF-21As and LPUBs, that is, inter-board trunk.

l In static LACP link aggregation mode, link aggregation can be implemented between
full-duplex interfaces working at the same rate on LPUF-21As, on LPUBs, and between
LPUF-21As and LPUBs.
NOTE
It is not recommended to add interfaces at different rates to one trunk interface. Otherwise, bandwidths
may be wasted and packet loss may occur.
For detailed configuration methods and configuration examples, see the NE40E&NE80E
Configuration Guide - LAN Access and MAN Access.
7.3.3 ATM Interfaces
7.3.3.1 What Are the Possible Causes When the Status of the ATM Interface Is
Down?
The possible causes are:
l The optical fiber is connected incorrectly.

Check that the optical module matches the optical fiber. For example, the multi-mode
optical module does not match the single-mode optical fiber.
Check that the optical fiber is correctly connected to the ATM interface. There should be
two optical fibers. One sends data and the other receives data. They must be connected
correctly; otherwise, the ATM interface cannot be Up.
l The clock mode of the interface is set incorrectly.
When two routers are directly connected, check that the internal clock is enabled on one
of ATM interfaces. By default, the router uses the line clock. When the routers are
directly connected or connected by the WDM device, the internal clock should be
enabled on one of the routers through the clock master command.
7.3.3.2 Why Are Packets Discarded and Is the CRC Incorrect When the Ping
Succeeds?
The possible cause is that the types of the optical fibers used on the ATM interfaces at both
ends are different. The multi-mode optical fiber is used at one end while the single-mode
optical fiber is used at the other end.
NOTE
In most cases, the multi-mode optical interface and the single-mode optical interface that are directly
connected can communicate with each other. Sometimes, packet loss and CRC errors may occur or the
interface converts between Up and Down continuously.
Check whether the ATM interfaces at both ends are of the same type, that is, multimode
optical fiber interface or single-mode optical fiber interface.
7.3.4 VE Interfaces

7.3.4.1 Why the Directly Connected VE Interfaces Cannot Ping Through Each
Other?

l No PVC is bound to the VE interface or the bound PVC is in the Down state.
l The PVCs that are bound to the VE interfaces at both ends are not the same.
l The IP addresses of the VE interfaces at both ends are not on the same network segment.
7.3.4.2 Why Do Services Become Abnormal When VE Interfaces Reside on the

Private Network Side of the VPLS Network?
VE interfaces cannot be used to directly access the VPLS network. VE interfaces need to be
added to the VLAN so that VLANIF interfaces can be used to access the VPLS network.
7.3.5 10GE LAN Interfaces
7.3.5.1 Can Interfaces on 10GE LAN Boards Be Added to Eth-Trunk Interfaces?

Yes.
7.3.6 10GE WAN Interfaces
7.3.6.1 Can Interfaces on a 10GE LAN Board and Interfaces on a 10GE WAN
Board Be Added to the Same Eth-Trunk Interface?
No.
7.3.7 Loopback Interfaces
7.3.7.1 Can the isis silent Command Be Configured in the Loopback Interface
View?
No, the isis silent command cannot be configured in the loopback interface view in any
version. No neighbor relationship needs to be established between loopback interfaces, and
loopback interfaces do not send or receive IS-IS packets. The isis silent command is used to
configure an interface not to send IS-IS packets, and therefore this command cannot be used
on a loopback interface.
7.3.8 IFNET
7.3.8.1 Why Is the Last Time for Protocol Statuses to Go Up Not Displayed Since
the Physical Layer and Link Layer Statuses of the Interfaces Are Both Up?
On the following interfaces, the last time for protocol statuses to go Up is not displayed:

l Layer 2 interface with the portswitch command or L2VPN configured

l Trunk member interface
l L2VE interface
l Interface bound to a L2VPN configured in the system view, such as the interface with the
cccinterface in-label out-label command or the cccinterface out-interface command
configured
7.3.8.2 Why Is the display this interface Command Output on a Tunnel Interface
Different from That of Another Type of Interface?
Command output on a GE interface:
[HUAWEI-GigabitEthernet1/0/2] display this interface
Line protocol current state : UP
Last line protocol up time : 2011-03-14 20:23:26
Description:HUAWEI, Quidway Series, GigabitEthernet1/0/2 Interface
Internet Address is 99.0.0.2/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc6a-0897
The Vendor PN is FTLF8519P2BNL-HW
The Vendor Name is FINISAR CORP.
Port BW: 1G, Transceiver max BW: 1G, Transceiver Mode: MultiMode
WaveLength: 850nm, Transmission Distance: 500m
Rx Power: -4.39dBm, Tx Power: -4.55dBm
Loopback:none, full-duplex mode, negotiation: disable, Pause Flowcontrol:Receive
Enable and Send Enable
Statistics last cleared:never
Input:
Overrun: 0 packets, InRangeLength: 0 packets
RxPause: 0 packets
Output:
Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
TxPause: 0 packets
Command output on a tunnel interface:

[HUAWEI-Tunnel1/0/0] display this interface
Tunnel1/0/0 current state : UP
Description:HUAWEI, Quidway Series, Tunnel1/0/0 Interface
Encapsulation is TUNNEL, loopback not set
Tunnel protocol is NONE
300 seconds input rate 0 bits/sec, 0 packets/sec
300 seconds output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
0 input error

0 packets output, 0 bytes

0 output error
Input:
Output:
Physical interfaces (such as GE interfaces) and tunnel interfaces forward different types of
data. Physical interfaces forward Layer 2 packets, but tunnel interfaces forward IP packets.
7.3.8.3 Why Is the display this interface Command Output on a TE-tunnel

Interface Different from That on a Tunnel Interface?
Why is the display this interface command output on a TE-tunnel different from that on a
tunnel interface? Why are both the line including "output error" and the line including "output
drop" displayed in this command output?
Command output on a tunnel interface:
Tunnel protocol is NONE
0 packets input, 0 bytes
0 input error
0 output error
Input:
Output:
Command output on a TE-tunnel interface:

Tunnel destination 0.0.0.0
Tunnel up/down statistics 0
Tunnel protocol/transport MPLS/MPLS, ILM disabled
0 output error
0 output drop
The line including "output error" indicates the average rate at which packets are sent out at the
traffic statistics interval; the second line including "output drop"displays the average rate at
which packets are sent out at the interval from the last running of the display this interface
command to the current running of this command.

7.3.8.4 Why Are the Real-time Input Rate and Output Rate Recorded in Interface
Statistics 0 Sometimes?
Run the display interface eth-trunk trunk-id command to check the interface statistics. The
real-time input rate and output rate are 0.
<HUAWEI> display interface eth-trunk 1
Eth-Trunk1 current state : UP
Description:TO HXJF-MSCG01
Route Port,Hash arithmetic : According to flow,Maximal BW: 3G, Current BW: 3G,
The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 286e-d443-92f2
Physical is ETH_TRUNK
Last 300 seconds input rate 629168512 bits/sec, 210359 packets/sec
Last 300 seconds output rate 1701801264 bits/sec, 234574 packets/sec
Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec
Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec
Input: 149195384754 packets,50595825900014 bytes,
149195383808 unicast,946 broadcast,0 multicast
0 errors,0 drops,
Output:171889442623 packets,158461856531822 bytes,
0 errors,0 drops
-----------------------------------------------------
PortName Status Weight
-----------------------------------------------------
GigabitEthernet1/0/0 UP 1
-----------------------------------------------------
The Number of Ports in Trunk : 3
The Number of UP Ports in Trunk : 3
Run the command again. The real-time input rate and output rate are not 0.
<HUAWEI> display interface eth-trunk 1
Eth-Trunk1 current state : UP
Description:TO HXJF-MSCG01
Route Port,Hash arithmetic : According to flow,Maximal BW: 3G, Current BW: 3G,
The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 286e-d443-92f2
Physical is ETH_TRUNK
Last 300 seconds input rate 629168512 bits/sec, 210359 packets/sec
Last 300 seconds output rate 1701801264 bits/sec, 234574 packets/sec
Realtime 0 seconds input rate 3072 bits/sec, 3 packets/sec
Realtime 0 seconds output rate 3136 bits/sec, 3 packets/sec
Input: 149195384754 packets,50595825900014 bytes,
0 errors,0 drops,
Output:171889442623 packets,158461856531822 bytes,
0 errors,0 drops
-----------------------------------------------------
PortName Status Weight
-----------------------------------------------------
-----------------------------------------------------
The Number of Ports in Trunk : 3
The Number of UP Ports in Trunk : 3

Cause: If the interval at which the same command is run twice is 300 seconds, the real-time
input rate and output rate will be cleared. If the interval is less than 300 seconds, the real-time
input rate and output rate are the average traffic statistics within the interval. Therefore, the
preceding information is correct.
NOTE
This circumstance applies to logical interfaces and sub-interfaces only.
7.3.9 Common
7.3.9.1 What Is a Jumbo Frame?

A frame longer than 1518 bytes is called a jumbo frame.
7.3.9.2 What Do Optical Power Values in Optical Module Specifications Mean?

The specifications of an optical module are as follows: Optical Transceiver, XFP, 1310nm,
9.95Gb/s to 10.5Gb/s, -1dBm to -6dBm, -11dBm, LC, 10km.
-1 dBm and -6 dBm indicate the upper limit and lower limit of the output optical power
respectively.
-11 dBm indicates the receiver sensitivity of the input optical power. When the input optical
power falls below -11 dBm, an alarm is generated.
Generally, the maximum input optical power is the same as the output optical power. Setting a
greater maximum input optical power probably damages the optical module.
7.4 Layer 2 Networks
7.4.1 VLAN
7.4.1.1 How to Limit the Packet Rates of Different VLANs on a Physical

Interface?
An ordinary Layer 3 interface can be configured with only one traffic policy. A Layer 2
interface can be configured with VLAN-specific traffic policies, and therefore you can limit
the traffic rate in each VLAN.
For example:
traffic classifier p1 operator or
if-match any
traffic behavior p1
car cir 10000 cbs 10000 pbs 0 green pass yellow pass red discard
traffic policy p1
classifier p1 behavior p1
¡¡
description HUAWEI GE1/0/0
portswitch

port trunk allow-pass vlan 10 20 30

traffic-policy p1 inbound vlan 10
7.4.1.2 Can Sub-VLANs of a Super VLAN Be Separately Configured with Static

ARP?
Yes.
7.4.1.3 Does the NE40E&NE80E Allows a Sub-VLAN of a Super VLAN to Be

Encapsulated with Two Tags?
No.
7.4.1.4 When Do Direct Routes Have 32-bit Masks?

When outgoing interfaces are VLANIF or QinQ interfaces, routes with 32-bit masks are
generated based on ARP to determine physical outgoing interfaces.
7.4.1.5 Can an Interface Be Configured with Both QinQ Termination and dot1q
Termination?
If a user VLAN is configured on the sub-interface, the sub-interface supports both QinQ
termination and dot1q termination. For example:
user-vlan 1
user-vlan 1 qinq 1
A main interface supports both QinQ termination and dot1q termination. Note that the VLAN
ID in the outer VLAN tag set for QinQ termination cannot be identical with the VLAN ID in
the single tag set for dot1q VLAN tag termination.
control-vid 1 qinq-termination
qinq termination pe-vid 1 ce-vid 1
control-vid 2 dot1q-termination
dot1q termination vid 2
7.4.2 QinQ
7.4.2.1 How to Check Statistics About a Sub-interface for QinQ VLAN Tag
Termination?
Create a VLAN group on a sub-interface for QinQ VLAN tag termination and then bind the
VLAN group to the sub-interface. Then, run the statistic enable command in the VLAN
group view.
Run the display interface interface-type interface-number command or the display qinq
statistics interface interface-type interface-number command to check statistics on the sub-
interface.

7.4.2.2 Why Does Not a Configured Sub-interface for QinQ VLAN Tag
Termination Send ARP Requests?
This is because the sub-interface is not configured with ARP broadcast. When this is the case,
the sub-interface only learns ARP entries but does not send ARP requests. To solve this
problem, run the arp broadcast enable command in the sub-interface view.
7.4.2.3 How Many Tags Does a Packet Carry from a QinQ Interface That Accesses
the VPLS Network in an Asymmetrical Manner to the Public Network?
If Ethernet encapsulation is configured, the packet does not carry tags; if VLAN
encapsulation is configured, the packet carries a tag.
7.4.2.4 Do the Control VID Configured on a Sub-interface for QinQ VLAN Tag
Termination and the Global VLAN ID Conflict?
The control VID configured on a sub-interface for QinQ VLAN tag termination is only an
identifier and does not have special functions. Therefore, they do not conflict.
7.4.2.5 Do Sub-interfaces for QinQ VLAN Tag Termination Support DHCP

Relay?
Yes. By default, a pair of PE-VID and CE-VID can be configured. If the PE-VID range or
CE-VID range is specified, packets are broadcast only in the VLAN specified by the smallest
PE-VID and the VLAN specified by the smallest CE-VID. As a result, other VLANs cannot
obtain IP addresses.
For example:
[DHCP-Relay] interface gigabitethernet 2/0/0.1
[DHCP-Relay-GigabitEthernet2/0/0.1] control-vid 1 qinq-termination
[DHCP-Relay-GigabitEthernet2/0/0.1] qinq termination pe-vid 100 ce-vid 10
[DHCP-Relay-GigabitEthernet2/0/0.1] dhcp select relay
[DHCP-Relay-GigabitEthernet2/0/0.1] arp broadcast enable
To configure the PE-VID and CE-VID in one-to-many or many-to-one mode, you need to
enable the Option 82 function on the DHCP server. Option 82 is a private field and common
servers cannot parse this field. router, however, can analyze this field. When an router
functions as a DHCP server, you need to enable DHCP snooping on it.
<DHCP-Relay> system-view
[DHCP-Relay]dhcp snooping enable
[DHCP-Relay] interface gigabitethernet 2/0/0.1
[DHCP-Relay-GigabitEthernet2/0/0.1] control-vid 1 qinq-termination
[DHCP-Relay-GigabitEthernet2/0/0.1] dhcp select relay
[DHCP-Relay-GigabitEthernet2/0/0.1] dhcp option82 rebuild enable
[DHCP-Relay-GigabitEthernet2/0/0.1] arp broadcast enable
7.4.2.6 How to Configure a Sub-interface for Dot1q VLAN Tag Termination with
an IP Address to Access a Remote (Indirectly-Connected) Address?
You need to set the user VID and control VID to the same value; otherwise, traffic cannot be
forwarded. In addition, you can configure only one tag on this sub-interface.

7.4.2.7 Which Sub-interfaces Can Be Used as Access Interfaces in QinQ?

Four types of sub-interfaces can be used as access interfaces in QinQ.
Sub-interface for Dot1q VLAN Tag Termination

Configuration file:
control-vid 1 dot1q-termination
qinq termination l2 asymmetry
dot1q termination vid 10
l2 binding vsi ldp1
Processing procedure:
After a sub-interface for dot1q VLAN tag termination receives a packet that carries one tag, it
strips the tag in the packet and performs subsequent processing.
The processing procedure in the outbound direction is opposite to that in the inbound
direction.
Figure 7-1 Incoming packet processing on a sub-interface for Dot1q VLAN tag termination
10 DATA DATA
QinQ Stacking Sub-interface

Configuration file:
qinq stacking vid 10
l2 binding vsi ldp1
After a QinQ stacking sub-interface receives a packet that carries one tag, it adds another tag
randomly to the packet and performs subsequent processing. Generally, the VLAN ID of the
second tag is the same as that of the source tag carried in the received packet.
direction.
Figure 7-2 Incoming packet processing on a QinQ stacking sub-interface
10 DATA 10 10 DATA

Sub-interface for QinQ VLAN Tag Termination in Asymmetry Mode

Configuration file:
qinq termination l2 asymmetry
l2 binding vsi ldp1
After a sub-interface for QinQ VLAN tag termination in asymmetry mode receives a packet
that carries two tags, it strips two tags in the packet and performs subsequent processing.
direction.
Figure 7-3 Incoming packet processing on a sub-interface for QinQ VLAN tag termination in
asymmetry mode
100 10 DATA DATA
Sub-interface for QinQ VLAN Tag Termination in Symmetry Mode

Configuration file:
qinq termination l2 symmetry
l2 binding vsi ldp1
After a sub-interface for QinQ VLAN tag termination in symmetry mode receives a packet
that carries two tags, it strips the outer tag in the packet and performs subsequent processing.
direction.
Figure 7-4 Incoming packet processing on a sub-interface for QinQ VLAN tag termination in
symmetry mode
100 10 DATA 10 DATA

7.4.2.8 Why Cannot Configure the qinq stacking, control-vid, qinq termination,
or dot1q termination Command on a Created Sub-interface?
The mode user-termination command has not been used to configure user termination on the
main interface of the sub-interface.
7.4.2.9 How to Describe Parameters of the control-vid Command for QinQ

Configurations?
The syntax of the control-vid command is control-vid vid { { dot1q-termination [ rt-
protocol ] } | { qinq-termination [ local-switch | [ rt-protocol | dynamic ] * ] } }.
l What is the relationship between the control-vid command and double tags?
– The control-vid command specifies a sub-interface encapsulation mode, either
QinQ VLAN tag termination or dot1q VLAN tag termination.
– In the case of both Layer 2 and Layer 3 services running on the same network, if a
control VID specified in the control-vid command is equal to a user VID, a conflict
occurs and the configuration is bound to fail.
l If there are two sub-interfaces for QinQ VLAN tag termination who have different inner
tags and the same outer tag, how to configure the control-vid command? Can the
configuration be successful?
The configuration can be successful as long as you specify different values of control-
vid vid for the sub-interfaces of the same main interface.
l What is the meaning of each parameter in the control-vid command?
Table 7-1 lists the description of each parameter.
Table 7-1 Parameter description of the control-vid command

vid Specifies a control VID, which is used for data forwarding.

When receiving packets, the system determines the sub-
interface receiving packets according to control VIDs.
Any two sub-interfaces of the same main interface cannot be
configured with the same control VID.
dot1q-termination Indicates that the encapsulation mode of sub-interfaces is

dot1q termination.
qinq-termination Indicates that the encapsulation mode of sub-interfaces is

QinQ termination.

rt-protocol Indicates one-tag or double-tag limit when a routing protocol

is configured for a termination sub-interface.
l If rt-protocol is configured in the dot1q termination vid
command, the VID specified in this command must be a
single value rather than a value range.
l If rt-protocol is configured for the qinq termination pe-
vid ce-vid command, both the PE VID and the CE VID
specified in this command must be a single value rather
than a value range.
local-switch Indicates that sub-interfaces for QinQ VLAN tag termination

support the local switch function. This function is applicable
to networks that have the following characteristics:
l Different CEs access the same VSI of the same PE.
l Packets from CEs to the PE carry double tags and the
outer tags are the same.
l CEs need to communicate with each other.
Note that if a sub-interface for VLAN tag termination is
configured with local-switch, the peer device connected to
the sub-interface must be disabled from MAC address
learning and all entries in the MAC address table must be
deleted. Otherwise, the peer device may learn the same
MAC address from different interfaces, which causes
incorrect data forwarding.
dynamic Indicates that sub-interfaces for QinQ VLAN tag termination

support dynamic QinQ.
An ordinary sub-interface for QinQ VLAN tag termination
can be configured to terminate user packets with a maximum
of 16 K combinations of inner and outer tags. To process
user packets with more than 16 K combinations of inner and
outer tags, you can configure dynamic to enable dynamic
QinQ on the sub-interface. In this case, the sub-interface is
able to terminate user packets with a maximum of 64 K
combinations of inner and outer tags. A sub-interface for
QinQ VLAN tag termination configured with dynamic QinQ
does not support the commands related to the Virtual Leased
Line (VLL), Pseudo Wire Emulation Edge-to-Edge (PWE3),
or Virtual Private LAN Service (VPLS).
Note that users usually send ARP requests to the gateway.
After configuring dynamic QinQ on an interface, you are
recommended to run the arp learning strict force-disable
command on the interface to disable the interface from
global ARP learning in strict mode so that the interface can
receive ARP requests from users.
If you run the control-vid command without configuring local-switch, or dynamic on

a sub-interface for VLAN tag termination, the sub-interface does not support local
switch, or dynamic QinQ.

7.4.2.10 Why the qinq termination Command or the dot1q termination Command
Cannot Be Configured on a Sub-interface Whose Main Interface Is Configured
with the mode user-termination Command?
Before running the qinq termination command or the dot1q termination command on a
sub-interface, you must run the control-vid command on the sub-interface to specify an
encapsulation mode.
7.4.2.11 What Is the Difference Between QinQ and 802.1Q Packet Formats?
A QinQ packet is an ordinary 802.1Q packet plus four bytes. Figure 7-5 shows their
encapsulation formats.
Figure 7-5 802.1Q encapsulation and QinQ encapsulation
802.1Q Encapsulation
DA SA ETYPE TAG LEN/ETYPE DATA FCS
6 Bytes 6 Bytes 2 Bytes 2 Bytes 2 Bytes 46 Bytes~1500 Bytes 4 Bytes
QinQ
Encapsulation
DA SA ETYPE TAG ETYPE TAG LEN/ETYPE DATA FCS
6 Bytes 6 Bytes 2 Bytes 2 Bytes 2 Bytes 2 Bytes 2 Bytes 42 Bytes~1500 Bytes 4 Bytes
0x8100 Priority CFI VLAN ID
For the ETYPE field in a QinQ packet, different vendors adopt different default values. The
default ETYPE value on Huawei devices is 0x8100. To communicate with non-Huawei
devices, Huawei devices can be configured with different ETYPE values.
7.4.2.12 Which Command Is Used to Query QinQ Statistics on Sub-interfaces for

QinQ VLAN Tag Termination?
You can run the following commands in any view:
l Using the display qinq statistics interface interface-type interface-number
[ .subinterface-number ] vid vid [ ce-vid ce-vid ] [ verbose ], you can view the statistics
on packets based on the tags on a specified sub-interface.
# Display statistics about packets with the outer tag being 10 and inner tag being 100 on
GE 1/0/1.1.
<HUAWEI> display qinq statistics interface gigabitethernet 1/0/1.1 vid 10 ce-
vid 100 verbose
GigabitEthernet1/0/1.1 Tag vid=10/100
QinQ termination tag:10/100
Statistics on VRP:
0 Packets received, 0 bytes
0 Error Packets received
0 Packets transmitted, 0 bytes
0 Error Packets transmitted,

Table 7-2 Description of the display qinq statistics interface vid ce-vid verbose
command output
Item Description
GigabitEthernet1/0/1.1 Tag Name of the sub-interface for QinQ VLAN tag

vid=10/100 termination; values of inner and outer tags added to
packets (The outer tag (pe-vid) and inner tag (ce-vid)
are at the left and right of "/" respectively.)
QinQ termination tag: Value range of tags terminated by sub-interfaces for

10/100 QinQ VLAN tag termination (The outer tag (pe-vid)
and inner tag (ce-vid) are at the left and right of "/"
respectively.)
Statistics on VRP: Statistics on the VRP
0 Packets received, 0 bytes Number of received packets
0 Error Packets received Number of received error packets
0 Packets transmitted, 0 Number of sent packets

bytes
0 Error Packets transmitted Number of sent error packets
# Display statistics about packets with a single tag being 100 on GE 1/0/1.1.
<HUAWEI> display qinq statistics interface gigabitethernet 1/0/1.1 vid 100
verbose
GigabitEthernet1/0/1.1 Outer Tag vid=100
Dot1q termination tag:100
Statistics on VRP:
Table 7-3 Description of the display qinq statistics interface vid verbose command
output
Item Description
GigabitEthernet1/0/1.1 Tag Name of the sub-interface for dot1q VLAN tag

vid=100 termination; value of the tag added to packets
Dot1q termination tag:100 Value range of tags terminated by sub-interfaces for

dot1q VLAN tag termination

bytes

Item Description
# Display packet statistics on GE 1/0/1.1.

<HUAWEI> display qinq statistics interface gigabitethernet 1/0/1.1 verbose
GigabitEthernet1/0/1.1 vlan-group[2]:Single
Stacking tag:20-50
Statistics on VRP:
Total statistics for QinQ on VRP:
Table 7-4 Description of the display qinq statistics interface verbose command output
Item Description
GigabitEthernet1/0/1.1 vlan- Name of the sub-interface; name and mode of the user
group[2]:Single VLAN group on the sub-interface
Stacking tag:20-50 Tag value range for VLAN stacking on the sub-
interface

bytes
l display qinq statistics [ interface interface-type interface-number [ .subinterface-

number ] [ vlan-group group-id ] ] [ verbose ]
# Display statistics about QinQ packets of user VLAN group 1 on GE1/0/1.1.
<HUAWEI> display qinq statistics interface gigabitethernet 1/0/1.1 vlan-
group 1 verbose
Stacking tag:1-4000
Statistics on VRP:
Stacking tag:4002
Statistics on VRP:
Stacking tag:0
Statistics on VRP:


Stacking tag:0
Statistics on VRP:
# Display QinQ statistics about user VLAN groups on all sub-interfaces.

<HUAWEI> display qinq statistics verbose
QinQ termination tag:10/100-200
Statistics on VRP:
Stacking tag:20-50
Statistics on VRP:
Dot1q termination tag:80-90
Statistics on VRP:
Table 7-5 Description of the display qinq statistics command output

Item Description
GigabitEthernet1/0/1.1 vlan- Name of the sub-interface; name and mode of the user
group[1]:Single VLAN group on the sub-interface
QinQ termination tag: Value range of tags terminated by sub-interfaces for

10/100-200 QinQ VLAN tag termination(The outer tag (pe-vid)
and inner tag (ce-vid) are at the left and right of "/"
respectively.)
Dot1q termination tag:80-90 Value range of tags terminated by sub-interfaces for

dot1q VLAN tag termination
Stacking tag:20-50 Tag value range for VLAN stacking on the sub-
interface

Item Description

bytes
Total statistics for QinQ on Statistics about QinQ packets on the VRP
VRP
0 Packets received, 0 bytes Total number of received packets
0 Packets transmitted, 0 Total number of sent packets

bytes
7.4.2.13 What Are Differences Between Symmetry and Asymmetry Sub-interfaces

for QinQ VLAN Tag Termination?
You can run the qinq termination l2 { symmetry [ user-mode ] | asymmetry } command on
a sub-interface for QinQ VLAN tag termination to configure the sub-interface to work in
either symmetry or asymmetry mode.
l symmetry indicates the symmetry mode.
l asymmetry indicates the asymmetry mode.
By default, the asymmetry mode is adopted.
Either of the two modes is configured for a sub-interface for QinQ VLAN tag termination
when the sub-interface accesses an L2VPN.
l In symmetry mode, all nodes must comply with the same VLAN configuration, and
nodes can communicate with each other only through the same VLAN. MAC addresses
are learned based on outer VLAN tags, and inner tags are transparently transmitted to the
peer. In this manner, user VLANs are isolated from each other.
l In asymmetry mode, users can plan their own VLANs as required, and any two nodes
can communicate with each other through any VLAN. Both inner and outer tags are
learned through MAC address learning, and thus user VLANs are not isolated from each
other.
User packets are sent to the L2VPN in different modes after being processed by the PE, as
described in Table 7-6 and Table 7-7.
Table 7-6 Packet processing on the inbound interface
Inbound VLL/PWE3/VPLS VLL/PWE3/VPLS

Interface (Ethernet Encapsulation (VLAN Encapsulation Mode)
Type Mode)
Symmetry Remove the outer tag. Keep both inner and outer tags
mode unchanged.

Inbound VLL/PWE3/VPLS VLL/PWE3/VPLS

Type Mode)
Asymmetry Remove both inner and outer Remove both inner and outer tags and
mode tags. then add one tag.
Table 7-7 Packet processing on the outbound interface

Outbound VLL/PWE3/VPLS VLL/PWE3/VPLS
Type Mode)
Symmetry Add an outer tag. Replace the outer tag.

mode
Asymmetry Add two tags. Remove one tag and then add two tags.
mode
7.4.2.14 What Are the Three Types of QinQ Sub-interfaces and Their
Configuration Commands?
In the QinQ feature, there are three types of sub-interfaces, namely, sub-interfaces for QinQ
VLAN tag termination, sub-interfaces for dot1q VLAN tag termination, and QinQ stacking
sub-interfaces.
l The following command is used to configure sub-interfaces for QinQ VLAN tag
termination:
qinq termination pe-vid pe-vid ce-vid low-ce-vid [ to high-ce-vid ] [ vlan-group group-
id ]
Before running the qinq termination pe-vid command on an Ethernet sub-interface, you
need to run the mode user-termination command on the Ethernet interface to configure
the interface mode as user termination, and then run the control-vid command on the
sub-interface to configure QinQ encapsulation. Otherwise, the qinq termination pe-vid
ce-vid command cannot be configured.
l The following command is used to configure sub-interfaces for dot1q VLAN tag
termination:
dot1q termination vid low-pe-vid [ to high-pe-vid ] [ vlan-group group-id ]
Before running the dot1q termination vid command on an Ethernet sub-interface, you
need to run the mode user-termination command on the Ethernet interface to configure
the interface mode as user termination, and then run the control-vid command on the
sub-interface to configure dot1q VLAN tag termination. Otherwise, the dot1q
termination vid command cannot be configured.
l The following command is used to configure QinQ stacking sub-interfaces:
qinq stacking vid low-ce-vid [ to high-ce-vid ] [ vlan-group group-id ]
Before running the qinq stacking vid command on an Ethernet sub-interface, you need
to run the mode user-termination command on the Ethernet interface to configure the
interface mode as user termination.

If the qinq stacking vid command is used on different sub-interfaces of the same main
interface, value ranges of ce-vid cannot overlap.
7.4.3 LACP
7.4.3.1 What Is the Interval for Sending an LACP Packet?

You can configure a device to send an LACP packet every 1 or 30 seconds. Both sending
frequencies are defined in IEEE 802.3ad. Sending an LACP packet every 30 seconds is
seldom set for the current network.
7.4.3.2 What Is the Function of the Delay for LACP Preemption?

When an Eth-Trunk interface in static LACP mode goes Up and Down frequently due to
unstable physical links, LACP goes Up and Down accordingly. As a result, services
transmitted on the trunk link are affected. After the delay for LACP preemption is set, LACP
negotiation is not performed during the delay period. In this manner, the possibility of LACP
flapping is minimized, and thus services are not affected.
7.4.4 MSTP
7.4.4.1 How MSTP BPDUs Are Transparently Transmitted on a VPLS Network?

As shown in Figure 7-6, multiple switches compose a Layer 2 ring network. The Multiple
Spanning Tree Protocol (MSTP) is enabled on the network to eliminate redundant links. To
connect the Layer 2 network to a VPLS network, you can configure a sub-interface or a
VLANIF interface on the user-side interface of PE1.
Figure 7-6 Networking diagram of the MSTP application
PE1 PE2
VPLS
VLANIF interface/
sub-interface
STP
Switch1 Switch2
Switch3
When the following conditions are met, PE1 can transparently transmit MSTP BPDUs to
another PE over the VPLS network:
l Transmitting untagged BPDUs transparently
When BPDUs from a Layer 2 network do not carry tags, you need to run the following
command on the user-side interface of PE1:

port default vlan vlan-id

stp disable
After receiving an untagged BPDU from the Layer 2 network, PE1 adds a specific tag to
the BPDU and then transparently transmits the BPDU to PE2 over the VPLS network.
After receiving the BPDU, PE2 removes the tag and then sends the BPDU to a specific
attached user.
l Transmitting tagged BPDUs transparently
When BPDUs from a Layer 2 network carry tags, you need to do as follows:
– Run the following command on the user-side interface of a switch on the Layer 2
network:
stp bpdu vlan vlan-id
– Run the following command on the user-side interface of PE1:

port trunk allow-pass vlan { { vlan-id1 [ to vlan-id2 ] } &<1-10> | all }
After receiving a tagged BPDU from the Layer 2 network, PE1 transparently transmits
the BPDU to PE2 over the VPLS network. After receiving the BPDU, PE2 directly sends
the BPDU to the downstream user.
7.4.4.2 When Do You Need to Configure Edge Interfaces?

Devices such as servers and NMSs do not send BPDUs, and thus they do not need to run the
Spanning Tree Protocol (STP). If switches and routers are connected to STP-unaware devices
through ordinary STP interfaces, the interfaces enter the forwarding state 30 seconds after the
interfaces alternate between Up and Down or STP is disabled globally, which are
unacceptable to certain services.
To solve the preceding problem, you can configure these interfaces as edge interfaces. Edge
interfaces can enter the forwarding state immediately after they go Up, which does not affect
services on the STP network.
7.4.4.3 What Are Precautions for Configuring the Formats of Sent and Received
BPDUs on STP Interfaces?
There are two MSTP BPDU formats, namely, standard IEEE 802.1s BPDU and proprietary
protocol BPDU. The NE40E&NE80E supports both BPDU formats and STP interfaces are
auto-sensing by default. In auto-sensing mode, after receiving a BPDU, an interface can parse
and then forward this BPDU.
When the NE40E&NE80E is connected to a device of another vendor, you are recommended
to run the stp config-digest-snoop command to enable digest snooping. After digest snooping
is enabled, the NE40E&NE80E can communicate with a device of another vendor with the
same domain name, revision level, and VLAN mapping table but different BPDU keys.
Digest snooping changes the BPDU key of the NE40E&NE80E to be the same as that of the
connected device.
7.5 IP Services
7.5.1 IP

7.5.1.1 How to Process Tracert Packets When Links Carry Out Equal-Cost Load
Balancing?
When packets are forwarded in per-destination load balancing mode, the device obtains a
value through the hash algorithm based on the quintuple including the protocol type, source
IP address and mask, destination IP address and mask, source port number, and destination
port number. Then, the device selects a link for packet forwarding according to the obtained
value.
UDP packets are used in the tracert operation, and the destination port numbers of the UDP
packets can be obtained in the following manner:
Destination port number = Original destination port number (33434 by default) + Sequence
number of the sent packet (The sequence number starts from 0 and increases by 1 each time a
packet is sent. The destination port number cannot be greater than 65535.)
When links carry out load balancing, the value obtained through the hash algorithm fluctuates
because the destination port numbers of UDP packets change in the tracert operation. As a
result, the system selected according to the value varies each time. This also indicates that
packets are load balanced among different links.
7.5.1.2 What Do the Bad Protocol and No Route Items Denote in the Statistics on
IP Traffic?
l The bad protocol item records the number of IP packets of unknown protocols. The
protocol type fields in the headers of these IP packets cannot be identified by the upper
layer protocol.
After an IP packet reaches the device, the bad protocol item increases by 1 if no
application module receives this IP packet. Generally, unorderly packets or malicious
attack packets on the network are counted when failing the protocol number check. The
correct protocol number for UDP is 17, for TCP is 6, for ICMP is 1, and for Telnet is 23.
l The no route item records the number of the packets discarded when the correct routing
information cannot be found. The packets include the packets forwarded and sent by the
local device.
7.5.2 ARP
7.5.2.1 Why Do ARP Entries Fail to Be Created After Strict ARP Learning Is
Configured?
After a device has strict ARP learning enabled, the device learns or updates ARP entries in the
following situations:
l If the ARP entry with a specified IP address does not exist, the device learns the ARP
entry when it receives the ARP reply packet in response to the ARP request packets sent
by the device.
l If the ARP entry with a specified IP address exists, the device performs operations as
follows:
– The device updates the ARP entry when it receives an ARP reply packet.
– The device sends an ARP request packet to the peer which has sent an ARP request
packet to the device. If the device receives an ARP reply packet from its peer, the
device updates its ARP entry; otherwise, the device does not update the ARP entry.

After rigid ARP learning is enabled on an interface, configuring VLANIF interfaces on

different interface boards may lead to abnormal ARP learning. As a result, host routes cannot
be generated. In such a case, it is recommended not to configure rigid ARP learning.
7.5.3 Socket
7.5.3.1 How to Understand the display tcp status Command Output?

The display tcp status command is used only for locating TCP-related problems, especially
BGP, LDP, FTP, and Telnet disconnections. You can run the display tcp status command to
view the current TCP status when TCP functions as the transmission protocol.
Before viewing the TCP status, you need to know the roles of both ends of the TCP
connection, that is, which end is the client and which end is the server. Generally, the server
adopts a well-known port number. For example:
l BGP port number: 179
l LDP port number: 646
l FTP port number: 20 or 21
l Telnet port number: 23
0c7c6564 79 /1 0.0.0.0:21 0.0.0.0:0 14849 Listening
0bf5a7e4 49 /1 0.0.0.0:23 0.0.0.0:0 14849 Listening
0c80e504 49 /3 19.30.0.202:23 19.30.0.250:4390 0 Established
0b1c57e4 49 /4 19.30.0.202:23 19.60.3.88:3617 0 Established
The preceding information shows that there are four TCP connections, of which three are
Telnet connections which 19.30.0.202 functions as the Telnet server, and one is FTP
connection.
NOTE
TCP states are described as follows:
l Listening: It is the initial state of TCP.
l syn_sent: The client initiates the handshake. That is, the client sends a SYN packet to the server.
l syn_rcvd: The server receives the first SYN packet from the client.
l established: The TCP connection is successfully set up.
l fin_wait_1: The one that intends to tear down the TCP connection sends a FIN packet to the peer.
l fin_wait_2: The one that intends to tear down the TCP connection and sends a FIN packet to the
peer receives the ACK packet from the peer.
l time_wait: The one that intends to tear down the TCP connection receives both the FIN packet and
the ACK packet from the peer.
l close_wait: The peer receives the FIN packet from the one that intends to tear down the TCP
connection.
7.5.3.2 What Does SOCK in the Task List Stand For?

When you run the display cpu-usage command to view the CPU usage or error information
or deadloop information, you can find a SOCK task in the command output. SOCK is short
for SOCKRUN. A SOCK task is responsible for lower-layer packet forwarding. It does not
refer to the SOCKET unified programming interface of the upper-layer application protocols
and transport layer.
Common tasks are described as follows:

BUFM 0% 0/ 292461 It indicates a Dopra task used to record error

information.
VIDL 92% 0/6e7d3cdd It indicates an idle task.
TICK 0% 0/ 826462 It indicates a system clock task used to trigger
a timer.
Ecm 0% 0/ 88061 It indicates a channel management task used to
receive and send packets at the lower layer.
IPCR 0% 0/ 640ec It indicates inter-board communications that IPC
packets are received.
ARQ 0% 0/ 5ade81
RTMR 0% 0/ ac596a
IPCQ 0% 0/ 4c2be7 It indicates inter-board communications that IPC
packets are sent.
VP 0% 0/ 469 It indicates inter-board communications that VP
packets are sent and received.
RPCQ 0% 0/ 50224 It indicates inter-board communications that RPC
packets are sent.
VMON 0% 0/ 38f It indicates a system monitoring task used for
patches and system detections.
STND 0% 0/ 561614 It indicates a standby task.
CFA 0% 0/ 5a139 It indicates a communications agency task.
INFO 0% 0/ 2e3ed It indicates an information center task used for
recording logs and debugging information.
RPR 0% 0/ 59582b It indicates a Resilient Packet Ring (RPR) task.
L2IF 0% 0/ 9b529 It indicates a Layer 2 interface management task.
MINM 0% 0/ 9382f
FIB6 0% 0/ 1b749e It indicates an FIB6 task.
BFD 0% 0/ 13868e It indicates a BFD task.
ROUT 1% 0/ 134ad80 It indicates a route management and routing
protocol task.
LSPM 0% 0/ 734121 It indicates an MPLS LSPM task.
OAM 0% 0/ 1419a6 It indicates an MPLS OAM task.
LDP 0% 0/ 4b04 It indicates an MPLS LDP task.
RSVP 0% 0/ 135dd1 It indicates an MPLS TE RSVP-TE task.
CSPF 0% 0/ 526544 It indicates an MPLS TE CSPF task.
TNLM 0% 0/ 974a5 It indicates a tunnel management task.
SNPG 0% 0/ 15bfb7
ADPT 0% 0/ 4dc It indicates a product adaptation task.
SRM 0% 0/ 6b8590 It indicates a device management main task.
LOAD 0% 0/ 18838 It indicates a loading task.
DIAG 0% 0/ 8f5ad It indicates a diagnosis task.
CAN 0% 0/ b47d1 It indicates a management CAN BUS task.
DNTM 0% 0/ 2b2b6
RFIB 0% 0/ 266b9
FTPS 0% 0/ 855b64 It indicates an FTP server task.
VRRP 0% 0/ 3293 It indicates a VRRP task.
vt0 0% 0/ 666e89 It indicates a console task.
EOAM 0% 0/ 1a530
SOCK 0% 0/ 1a9761 It indicates a packet forwarding task.
VTYD 0% 0/ fc4a3 It indicates the guard task of the task for
creating the console.
IPSP 0% 0/ 1fe0 It indicates an IPSec task.
IKE 0% 0/ 37c3 It indicates an IPSec negotiation task.
L2TP 0% 0/ 28e0e It indicates an L2TP task.
TUNN 0% 0/ df838 It indicates a tunnel task.
TRAP 0% 0/ 703a9d It indicates an SNMP trap task.
MDMT 0% 0/ 5009c1 It indicates a modem task.
NTPT 0% 0/ 9ec2c0 It indicates an NTP task.
TAC 0% 0/ 127fcd It indicates a TACACS task used for AAA
authentication through the TACACS server.
UCM 0% 0/ 7406 It indicates a user control management task used
for AAA authentication.
HS2M 0% 0/ 588a It indicates a backup task.
MSTP 0% 0/ 16a64 It indicates the MSTP task.
RRPP 0% 0/ 328ce It indicates an RRPP task.
COPS 0% 0/ 25920 It indicates a COPS maintenance task.
TEST 0% 0/ 9700
TSTA 0% 0/ 135bec

NE50 0% 0/ 55500
DEFD 0% 0/ 3149
DHCP 0% 0/ 2f0ac It indicates a DHCP task.
RMON 0% 0/ 17809 It indicates an RMON task.
HOT 0% 0/ 6c2ff1 It indicates a hot swap task.
vt1 0% 0/ 5aecb It indicates a console task.
vt4 0% 0/ 4fb16 It indicates a console task.
OS 7% 0/ 0 It indicates an operating system task.
7.5.3.3 Which Ports Can Be Bound by Socket?

In TCP/UDP, if no port number is specified when an upper-layer application protocol calls the
bind function to bind the source port (it is the server in most cases), socket allocates an idle
port in the range of 49152 to 55535.
Ports ranging from 55535 to 65535 are reserved for L2TP. L2TP uses UDP as the
transmission protocol. If a port number is specified, the binding can be successful provided
that; if the port number is smaller than 55535 and is not 1701.
7.5.3.4 Why Does the Upper Layer Application Function Normally When the TCP
Checksum in the Packet Header obtained on the Windows Platform Is Detected
Faulty?
Some network interface cards support the Rx Checksum Offload/Tx Checksum Offload
option. Generally, the TCP/IP protocol suite on the Windows platform calculates the
TCP/UDP/IP checksum. If the Rx Checksum Offload/Tx Checksum Offload option is enabled
on the network card, the network card itself rather than the protocol suite calculates the
checksum. In this case, the TCP checksum calculated by the network card is different from
the one parsed by the packet header obtaining software.
7.5.4 DHCP
7.5.4.1 Can DHCP Services Access a Super VLAN Configured on the

NE40E&NE80E?
Yes.
7.5.4.2 Do Broadcast Ethernet Interfaces on the NE40E&NE80E Support Address

Unnumbered?
Ethernet interfaces do not support address unnumbered.
7.6 IP Routing
7.6.1 Static Route
7.6.1.1 What Are the Differences Between a Static Route Configured with Only
the Next Hop Address and a Static Route Configured with Both the Next Hop
Address and Outbound Interface?
When configuring a static route, you can specify either the next hop address or outbound
interface for the static route. Actually, every routing entry requires a next hop address. This is

because before sending a packet, a device first searches the routing table for a route matching
the destination address of the packet. The device can find the associated link layer address to
forward the packet only when the next hop address of the route is specified.
l For a point-to-point interface, the next hop address is specified after the outbound
interface is specified. That is, the address of the remote interface is the next hop address.
For example, the link-layer protocol of a POS interface is the Point-to-Point protocol
(PPP). The remote IP address is obtained through PPP negotiation. You need to specify
the outbound interface rather than the next hop address.
l 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, the
next hop IP addresses of routes need to be configured.
l For an Ethernet interface, the next hop address of a static route must be specified. This is
because the Ethernet interface is a broadcast interface and is associated with multiple
next hop addresses for the same outbound interface. The next hop therefore fails to be
identified. Therefore, if the broadcast interface (such as an Ethernet interface) or NBMA
interface must be specified as the outbound interface of a route, you must specify the
next hop address of the route.
A static route configured with only the next hop address can participate in route selection only
after the next hop iteration is successful. Otherwise, the static route cannot be preferred. A
static route configured with both the next hop address and the outbound interface, however,
can directly participate in route selection. Only the preferred static route is delivered to the
FIB table to guide packet forwarding.
7.6.1.2 Why Is a Static Route Configured with an Outbound Interface Preferred?

A static route configured with only the next hop address can participate in route selection only
after the next hop iteration is successful. Otherwise, the static route cannot be preferred. A
static route configured with both the next hop address and the outbound interface, however,
can directly participate in route selection. Only the preferred static route is delivered to the
FIB table to guide packet forwarding.
For example, there are two static routes: ip route-static 10.97.32.243 255.255.255.255
Pos1/0/0 10.83.25.49 and ip route-static 10.97.32.243 255.255.255.255 10.83.25.221. The
route configured with an outbound interface is preferred. The static route configured with the
outbound interface does not need to be iterated, and therefore the relay depth of the static
route is 0. The static route that is not configured with an outbound interface needs to be
iterated once, and therefore the relay depth of the static route is 1. Based on next hop iteration,
the static route with the smallest relay depth is preferred.
7.6.1.3 Why Does the Static Route Configured for Interworking Between the
Public Network and Private Network Not Take Effect?
The fault may be caused by incorrect configurations, that is, the parameter public is not
configured. Correct configurations are as follows:
ip route-static vpn-instancevpn-source-name destination-address{ mask| mask-length}

nexthop-address public
To make the configured static route take effect, you need to configure the parameter public.

7.6.2 OSPF
7.6.2.1 What Are OSPF Authentication Types? What Are the Authentication
Principles?
OSPF area authentication types include simple, message digest 5 (md5), and hash message
authentication code (hmac)-md5. OSPF interface authentication types include null, simple,
md5, and hmac-md5.
The OSPF authentication principles are as follows:
l If authentication is configured on the interface, the authentication mode configured on

the interface is adopted.
l If the authentication mode configured on the interface is null, the interface is not
authenticated.
l If no authentication is configured on the interface (the null type does not mean that no
authentication is configured), the authentication mode configured on the area is adopted.
l If no authentication mode is configured on the area either, no OSPF authentication is
performed.
7.6.2.2 How Is the Cost of an OSPF Interface Calculated?

The principles of calculating the cost of an OSPF interface are as follows: The cost configured
on the interface is preferred. If no cost is configured on the interface, the formula for
calculating the cost of the interface is as follows: Cost = Reference bandwidth/Interface
bandwidth. The default reference bandwidth of OSPF is 100 Mbit/s.
For example, the cost of a 10 Mbit/s Ethernet interface = 100 Mbits per second/10 Mbits per
second = 10. If the calculation result is smaller than 1, the cost is set to 1. For example, the
cost of a GE interface is 100 Mbits per second/1000 Mbits per second = 0.1, which is less
than 1. Therefore, the cost of this interface is 1.
The default cost on the loopback interface, which is a virtual interface, is 0.
7.6.2.3 Must Two Interfaces Reside on the Same Network Segment and Have the
Same Subnet Mask Digits to Establish an OSPF Neighbor Relationship?
On a broadcast network, non-broadcast multi-access (NBMA) network, or Point-to-
Multipoint (P2MP) network, two interfaces must reside on the same network segment and
have the same subnet mask digits to establish a neighbor relationship. Such a restriction does
not apply to a peer-to-peer (P2P) network.
7.6.2.4 Must All the Devices on an OSPF NBMA Network Be Fully Meshed?
No.
All the devices on an OSPF Non-Boadcast Multi-Access (NBMA) network do not need to be
fully meshed. Only the designated router (DR), backup designated router (BDR), and all the
neighbors need to be reachable by IP address. Though DR election is not definite, you can set
the priority of another device to 0 to prevent the interface from being elected as DR. For a
robust network, it is recommended that all the devices on an NBMA network be fully meshed.

7.6.2.5 Must the IP Addresses of Interfaces on the Two Ends of a P2P Link Be on
the Same Network Segment?
In the HUAWEI NetEngine40E/80E implementation, on an OSPF P2P network, If the link
layer protocol is Point-to-Point Protocol (PPP) and different network segment addresses are
configured on the interfaces on the two ends of the link, OSPF neighbors are in the Full state
and forward traffic normally. If link layer protocol traffic is encapsulated over High-Level
Data Link Control (HDLC) or another protocol, no neighbor relationship can be established.
The difference in the OSPF neighbor relationship establishment with PPP and HDLC is that
with PPP, the IP address of the peer can be negotiated. This allows the route to the peer to be
obtained without additional operations.
In addition, on an OSPF broadcast network, NBMA network, or P2MP network, the IP

address of the neighbor and that of the local interface must be on the same network segment.
7.6.2.6 What Are the Functions of OSPF Virtual Links?

From the perspective of a protocol, the functions of OSPF virtual links are as follows:
l Areas not physically connected to the backbone area can be connected to the backbone
area through virtual links so that these areas route traffic normally. This function is
mainly used to merge networks.
l Virtual links improve network reliability by allowing for normal routing after the
physical connection to the backbone area is down.
On actual networks, virtual links are seldom used. Generally, networks are planned properly
and backbone areas are seldom physically disconnected from the backbone areas. It is rare
that networks are merged without network re-planning. In addition, on actual networks,
virtual links are seldom used to enhance the robustness of backbone areas.
7.6.2.7 What Are the Common LSA Types of OSPF? Why Is Type 6 LSA
Unavailable?
Common link-state advertisement (LSA) types of OSPF are as follows:
l Type 1 LSA: router LSA;

l Type 2 LSA: network LSA;
l Type 3 LSA: summary LSA;
l Type 4 LSA: ASBR-summary LSA;
l Type 5 LSA: AS-external-LSA;
l Type 7 LSA: NSSA AS-external-LSA
The original OSPF packet coding is not Type Length Value (TLV)-based. For the extension of
OSPF functions, only the LSA types of OSPF can be extended.
Type 6 LSAs are Group-Membership-LSAs used to identify multicast group membership in

the Multicast Open Shortest Path First (MOSPF) protocol. Type 6 LSAs are not supported on
the HUAWEI NetEngine40E/80E.
Type 8 LSAs are External-Attributes-LSAs used to redistribute Border Gateway Protocol

(BGP) routes into OSPF and reserve the BGP autonomous system (AS) path information.
Type 8 LSAs are not supported on the HUAWEI NetEngine40E/80E.

RFC 2370 defines an important LSA type, namely, Opaque LSA, which allows for TLV-like
structures. OSPF applications, such as OSPF traffic engineering, are based on the Opaque
LSA extension abilities:
l Type 9 LSAs are Opaque LSAs that are advertised within the local link only;
l Type 10 LSAs are Opaque LSAs that are advertised within the local area only;
l Type 11 LSAs, similar to Type 5 LSAs, are Opaque LSAs that are advertised within the
local AS.
7.6.2.8 What Does the ToS Field in an OSPF LSA Mean?

The type-of-service (ToS) field in an OSPF LSA was originally intended for Quality of
Service (QoS) routing. To put it simply, with different ToS values, links can be configured
with different costs to achieve ToS-based routing. That is, IP packets with the same
destination IP address but different ToS values are routed differently. In RFC 2328, however,
this application is obsoleted and only ToS 0 is supported. That is, packets are routed based on
destination IP addresses only.
Currently, the HUAWEI NetEngine40E/80E supports only ToS 0.
7.6.2.9 What Does the OSPF LSA Refresh Interval Mean? How Long Is the LSA
Refresh Interval?
When an OSPF link state advertisement (LSA) age reaches the link-state refresh time (1800
seconds), the OSPF updates the LSAs for advertisement. Defined in RFC 2328, the 1800-
second interval cannot be changed.
7.6.2.10 When OSPF Imports External Routes to Generate Type 5 LSAs (ASE
LSAs) or Type 7 LSAs (NSSA LSAs), What Are the Rules of Filling in the
Forwarding Address?
l AS-external (ASE) link-state advertisements (LSAs) are generated through imported
routes. When OSPF is enabled on the output interface on which routes are imported (The
enabled OSPF process must be the same as the OSPF process that generates the ASE
LSAs) and the outbound interface is of the broadcast network type, the forwarding
address is the next hop address of the imported route. Otherwise, the forwarding address
is 0.
l The forwarding address of a not-so-stubby area (NSSA) LSA is non-zero.
When the output interface of the redistributed route is enabled in the same NSSA and the
output interface is of the broadcast network type, the forwarding address is the next-hop
address of the redistributed route. Otherwise:
– If a loopback interface exists in an NSSA area, the forwarding address is the
loopback interface address.
– If no loopback interface exists, the forwarding address is the address of the first
interface that is up in the NSSA.
7.6.2.11 When OSPF Imports Routes as Type 5 LSAs, What Is the Function of the
Input Forwarding Address?
Like in IPv4 RIP version 2 (RIPv2) and Border Gateway Protocol version 4 (BGPv4), the
forwarding address in OSPF Type 5 link-state advertisements (LSAs) is used to notify the

devices in the local routing domain of the faster next hop to the imported AS external network
described by Type 5 LSAs. This prevents an extra hop from being generated when an internal
device routes to itself with itself as the next hop and forwards the traffic to the devices in an
external routing domain on the same broadcast network.
For the Type-5 LSAs generated by an Autonomous System Boundary Router (ASBR), the
forwarding address can be 0 or non-zero.
The rules of inputting the forwarding address are as follows:
l If an ASBR redistributes routes but OSPF is disabled on the next hop interface of these
routes, the forwarding address is set to 0.0.0.0.
When the value of the FA field of a Type 5 LSA is 0.0.0.0, the router that receives the
LSA knows that the router sending the LSA is an advertising router (that is, an ASBR),
and calculates the next hop.
l When the following conditions are met, the forwarding address is set to non-zero:
– The route to the interface of the ASBR's next hop is reachable.
– The next hop interface of the ASBR is not configured as a passive interface (known
as a silent interface on the HUAWEI NetEngine40E/80E and a passive interface
under IOS);
– The type of the next hop interface of the ASBR is not OSPF P2P or P2MP;
– The next hop interface address of the ASBR is on the network segment configured
with the network command in OSPF.
In any other case, the forwarding address is 0.0.0.0.
When all of the conditions are met, an ASBR fills in an address other than 0.0.0.0 in the
FA field of a Type 5 LSA, and the router that receives the LSA calculates the next hop
based on the value of the FA field.
When calculating routes, OSPF needs to check whether any intra-area route or inter-area route
arrives at the ASBR. If there is no intra-area route or inter-area route destined for the
forwarding address, the LSA does not take part in route calculation or calculate routes.
7.6.2.12 What is the LSA Retransmit Interval? How to Set it?

OSPF must send an LSAck packet after receiving a link-state advertisement (LSA). LSAs are
retransmitted until they are acknowledged. The link-state retransmit interval defines the time
between retransmissions. You can run the ospf timer retransmitinterval command to set the
retransmit interval. The default interval is 5 seconds.
7.6.2.13 What Are a DR, a BDR, and a DR Other? What Are the Election Rules?
DR means designated router. BDR means backup designated router. DR Other indicates a
device that is neither a DR or a BDR. The DR advertises link-state advertisements (LSAs) to
all the devices in the network.
The DR election rules are as follows:
1. When going Up, an interface sends Hello messages and enters the waiting state. In the
waiting state, a waiting timer is triggered. The waiting timer duration is the same as the
dead timer duration. By default, the waiting timer duration is 40 seconds, which cannot
be changed.
2. Before the waiting timer is triggered, sent Hello messages carry no DR or BDR field. In
the waiting state, if a received Hello message carries the DR and BDR fields, the DR and

BDR are accepted directly without any election triggered, and neighbor state
synchronization starts, directly exiting the waiting state.
3. Assume that a DR and a BDR exist on the network. Any device newly connected to the
network will accept the DR and BDR that exist on the network regardless of the router
ID of the device.
4. If the DR fails and goes down, the BDR takes over the role of the DR and the remaining
devices whose priority is greater than 0 compete to become the new BDR.
5. DR election rules are used to elect a DR only when devices with different router IDs or
configured with different DR priorities are started at the same time. The election rules
are that the device with the highest DR priority is elected as DR and the device with the
second highest DR priority as BDR. A device with a DR priority of 0 can be a DR Other
only. In the case of the same priority, the device with the greatest router ID is elected as
DR, the device the second greatest router ID becomes the BDR, and other devices are
DR Others.
7.6.2.14 What Is the Function of the Interface MTU in OSPF Database

Description (DD) Packets, and How to Configure it?
As defined in RFC 2328, the Interface Maximum Transmission Unit (MTU) of a DD packet
should be set to the MTU (0 has to be set for a virtual link) of the link. If the Interface MTU
of the DD packet received from the peer is greater than Interface MTU at the local end, the
DD packet is discarded and the neighbor state remains in the Exchange state.
In the HUAWEI NetEngine40E/80E, you can run the ospf mtu-enable command on the
interface to check the MTU of a received DD packet. By default, OSPF does not check the
MTU of DD packets. If the interface MTU check is ignored, the OSPF neighbor relationship
can reach the Full state normally and complete database synchronization even if the MTUs
configured on both ends of the link are the same. Note that the difference between the MTUs
of both ends of the link cannot be too great.
7.6.2.15 What Is the Purpose of a Domain ID?

OSPF domain ID is used in Virtual Private Network (VPN) scenarios.
When the domain ID carried by the packet received from the peer is the same as the local one,
Type 3 link-state advertisements (LSAs) are generated for Type 1, 2, and 3 LSAs, and Type 5
and 7 LSAs are generated for Type 5 and 7 LSAs (depending on area type).
When the Domain ID is the different from the local one, Type 5 or 7 LSAs (depending on area
type) are generated for Type 1, 2, and 3 LSAs, and Type 5 and 7 LSAs are generated for Type
5 and 7 LSAs (depending on area type).
7.6.2.16 What Is the Purpose of an OSPF Route Tag?

OSPF route tags are used in only Virtual Private Network (VPN) scenarios to prevent Type 5
link-state advertisement (LSA) loops in Customer Edge (CE) dual-homing networks.
When OSPF detects that the route tag of a Type 5 LSA is the same as a route tag on the
Provider Edge (PE) router, this route is ignored.
When a CE router is connected to two PEs, PE1 sends the Type 5 LSA generated based on the
redistributed Border Gateway Protocol (BGP) route. The CE then forwards this LSA to PE 2.
Because an OSPF route has a higher priority than a BGP route to the CE, PE 2 replaces the
BGP route with the OSPF route. Therefore, a routing loop occurs. With a route tag

configured, when the PE detects that the route tag of the LSA is the same as that of its route
tag, the PE ignores the LSA, thereby avoiding routing loops.
The default route tag is calculated based on the AS numbers in the BGP. If BGP is not
configured, the default value of route tag is 0.
7.6.2.17 What Is the Purpose of a Tag in an ASE-LSA and NSSA-LSA?

In OSPF VPN multiple instances, a link-state advertisement (LSA) tag is used to prevent
routing loops between PEs.
In OSPF public network instances, the tag field does not prevent routing loops but is used to
set the filtering conditions of routing policies.
The rules of setting the tags of ASE-LSAs and NSSA-LSAs are as follows:
l In OSPF multiple instances, the route tag is set through the route-tag command.
l In OSPF public networks, the route tag is set through the default tag command.
In either of the preceding two cases, you can run the import-route tag command to set the
tag.
7.6.2.18 What Is the Purpose of Setting the DN Bit in an OSPF LSA?

If a Provider Edge (PE) device advertises Type-3, 5, and 7 link-state advertisements (LSAs) to
Customer Edge (CE) devices through area 0, the optional high-order bit of these LSAs must
be set and called the DN bit. If these LSAs are advertised through an area other than area 0,
the DN bit can be set or not set.
The DN bit is used to prevent routing loops. A PE ignores any LSA whose DN bit is set. This
prevents a routing loop caused when a PE learns from the CE the LSA generated by another
PE in CE dual-homing scenarios.
PE sets the DN-bit of Type 3, 5, and 7 LSAs and checks the DN-bit of Type 3, 5, and 7 LSAs.
7.6.2.19 What Is the Function of the vpn-instance-capability simple Command?

For a Customer Edge (CE) device on which multiple Virtual Private Networks (VPNs) need
to be divided, namely, Management CE (MCE), no routing loop is checked. That is, the route
tag and DN-bit are not checked.
7.6.2.20 What Is an OSPF Sham Link and What Is the Function of an OSPF Sham
Link?
In Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) configuration,
OSPF is used as the routing protocol between PEs and CEs so that the sites in a VPN can be
connected through the MPLS backbone network. Though the connectivity between OSPF PEs
and CEs ensures the connectivity between VPN sites, the intra-area link between VPN sites
should also be considered. For two sites to the same site, the path through the intra-area link is
always preferred because, according to OSPF specifications, an intra-area path is always
preferred to an inter-area path. Therefore, when a intra-area link exists, consider controlling
routes through policies.
If the intra-area link is used for backup only but is not used to provide VPN services, the
default processing flow will be unacceptable. For connections to be re-established between

sites through the MPLS VPN backbone area, a logical intra-area link must be established
between the ingress and egress Virtual Routing and Forwarding (VRF) interfaces of the
related PEs. This feature provides a solution to establish an OSPF sham link between two
sites as an intra-area channel so that the two sites communicate with each other through the
MPLS backbone area, while the intra-area link is used for backup. If no intra-area link exists
between the two sites, no sham link is needed.
7.6.2.21 How Does OSPF Filter Received Routes?

As a link state-based routing protocol, OSPF is different from a distance-vector (D-V)
algorithm routing protocol and ensures consistent topological relationship. This is an
important condition for loop-free OSPF routing. You can run the filter-policy import
command to filter routes in OSPF configuration. The link-state advertisement (LSA) of a
route filtered out exists in the OSPF database. OSPF simply does not add the route to the
routing table of the route manager. In addition, the LSA of the route is still advertised. That is,
the neighbors still have this route. Note that the filter-policy export command can be used to
filter routes when external routes are redistributed for advertisement.
OSPF provides another feature: OSPF Area Border Router (ABR) Type 3 LSA filtering. This
feature extends the ability of an ABR that is running the OSPF protocol to filter type 3 LSAs
that are sent between different OSPF areas. This feature allows only packets with specified
prefixes to be sent from one area to another area and restricts all packets with other prefixes.
This type of area filtering can be applied out of a specific OSPF area, into a specific OSPF
area, or into and out of the same OSPF areas at the same time.
7.6.2.22 What Is an ABR? Is a Device Configured with More than Two Areas an
ABR?
According to RFC 2328, the OSPF backbone area contains the Area Border Routers (ABRs)
of all the areas. That is, an ABR must belong to the backbone area. If area 2 and area 3 are
configured on a device but none of the interfaces of the device belongs to the backbone area,
the device is not an ABR.
RFC 3509 defines what is an ABR.
In the HUAWEI NetEngine40E/80E implementation, an ABR can belong to two or more

areas, and one of the areas must be a backbone area. For the configuration of these areas, each
area does not need to contain at least one interface in the Up state.
7.6.2.23 When Multiple ABRs Exist in an NSSA Area, on Which Router Does
OSPF Translate Type-7 LSAs into Type-5 LSAs?
In an OSPF Not-So-Stubby Area (NSSA) area, Type-7 LSAs are translated into Type-5 LSAs
on the router with the greatest Router ID.
7.6.2.24 How Is an OSPF Router ID Selected? How Is the Default Router ID

Obtained?
When configuring an OSPF process, you can specify a router ID.
For example, you can run the ospf 1 router-id 1.1.1.1 command:
[HUAWEI] ospf 1 router-id 1.1.1.1

If no router ID is specified when the OSPF process is configured, the OSPF router ID is
selected according to the following rules:
l If one or more loopback addresses are configured, the router ID is the loopback address
with the highest IP address.
l If no loopback address is configured, the router ID is the physical interface with the
highest IP address.
NOTE
If the current OSPF process is running, the router ID does not take effect immediately even if it is re-
configured manually or recalculated. The router ID takes effect only after the OSPF process is restarted.
7.6.2.25 What Are the OSPF Network-Type Specifications?

If OSPF is enabled on an interface or such OSPF parameters as timer and cost are configured
on the interface (with an OSPF IF instance created), change the link types of interfaces at both
ends. Before a link layer protocol goes up, parameters on the interface, such as ospf timer
hello and network-type, remain unchanged. In this case, when you run the display current-
configuration interface command or the display ospf interface command, the original
values are displayed. After the link layer protocol goes up, the parameters adopt the default
values of the new link types.
If the new link layer protocol on the interface is different from the original protocol, all the
OSPF interface parameters, including timer and cost, change to the default values in the new
link protocol. For example, if the link layer protocol on the interface changes from Point-to-
Point Protocol (PPP) to frame relay (FR), the hello timer interval changes from 10 seconds to
30 seconds.
If the OSPF interface is restarted or the link layer protocol changes, the link layer protocol
remains the same (for example, the link layer protocol changes from FR to PPP and then to
FR again), the original parameter configurations (including manual configurations) remain
unchanged.
As shown in Figure 7-7, a neighbor relationship is established between Router A and Router
B. The link type of the interface between Router A and Router B is configured as FR.
Figure 7-7 OSPF networking diagram
RouterA RouterB
1. If the interface type of Router B changes to PPP, the link layer protocol of the interfaces
on both ends goes down, when you run the display current-configuration interface or
display ospf interface command, ospf network-type nbma is displayed;
2. Then, when you run the undo ospf network-type command on the interface of Router
B, the actual OSPF interface type is PPP. If you run the display current-configuration
interface or display ospf interface command, however, ospf network-type p2p is not
displayed.
3. Restore the type of the interface to FR and bring up the link layer protocol. When you
run the display current-configuration interface or display ospf interface command,
ospf network-type p2p is displayed.

7.6.2.26 In the Case of 50 Thousand OSPF Routes, How Long Does it Take to
Establish an OSPF Neighbor Relationship?
This depends on the number of neighbors and router performance. If the number of routes is
large, the specification file needs to be modified. If there is only one neighbor, OSPF neighbor
relationship establishment takes not more than ten minutes.
7.6.2.27 What Is the Maximum Number of Equal-Cost Routes Supported by

OSPF?
Currently, OSPF supports up to 32 equal-cost routes. This number may vary according to
devices, depending on the specifications. You can run the maximum load-balancing number
command to set the number of equal-cost routes supported by OSPF. This number, however,
cannot be greater than the maximum value defined in the specifications.
7.6.2.28 How Can an OSPF Route Be Hidden so that It Is Not Advertised to Any
Other Area?
A filter list cannot solve this problem. You solve this problem through the following methods:
l Configure route summarization on the Area Border Router (ABR), specifying the no-
advertise keyword in the route summarization command.
l Configure the filtering of OSPF ABR Type-3 LSAs. This feature extends the ABR
capabilities so that an ABR can filter routes when advertising Type-3 LSAs between
OSPF areas. This feature allows only packets with specified prefixes to be sent from one
area to another area and restricts all packets with other prefixes. This type of area
filtering can be applied out of a specific OSPF area, into a specific OSPF area, or into
and out of the same OSPF areas at the same time.
7.6.2.29 Why Can No OSPF Neighbor Relationship Be Established After FR Is

Configured?
On FR-, or ATM-encapsulated links, the default OSPF network type is non-broadcast multi-
access (NBMA). When configuring OSPF on an FR network, you need to run the map ip
command on the interface with the broadcast keyword specified so that broadcast or
multicast packets can be received and transmitted normally.
7.6.2.30 Why Is the OSPF Neighbor Relationship Establishment on an ATM

Interface Slow?
By default, the network type of an Asynchronous Transfer Mode (ATM) interface is Non-
broadcast Multiple Access Network (NBMA), whose Hello interval is 30 seconds by default.
Therefore, neighbor relationship establishment is slow. To speed up OSPF neighbor
relationship establishment on an ATM interface, perform the following steps:
1. On the ATM interface, run the ospf timer hello interval command, for example,
[HUAWEI-Atm1/0/0] ospf timer hello 10
.
2. On the peer interface, configure the same Hello interval.

7.6.2.31 Two Areas Are Configured and the Total Costs of Two Routes Learnt
from These Two Areas Are the Same. However, No ECMP Route Be Generated.
Why?
According to RFC 2328, the following conditions must be met for Equal Cost Multipath
(ECMP) routes to be generated in OSPF:
l The routes are learnt from the same area.

l The priorities and total costs of the routes are the same.
RFC 2328 does not clearly define whether an intra-area or inter-area route is to be chosen
under the same multi-area conditions. On the HUAWEI NetEngine40E/80E, the route last
advertised is not selected. For Type-5 external link-state advertisements (LSAs), RFC 2328
clearly defines that the route with the greatest area ID is preferred.
7.6.2.32 What Are the Common Causes that an OSPF Neighbor Cannot Enter the
Full State or Generate Routes?
The most common causes are as follows:
l The OSPF network type is non-broadcast multi-access (NBMA) but no neighbor is

configured.
l The OSPF network type is NBMA and a neighbor is configured. However, the
broadcast keyword is not specified in a command, such as the map ip command in
frame relay (FR). This prevents multicast packets from reaching the peer.
l The hello intervals and dead intervals of the OSPF neighbors are different.
l In a stub area or not-so-stubby area (NSSA), some routers are not configured as stub or
NSSA routers.
l The OSPF authentication configuration is incorrect.
l The OSPF router ID is the same as that of another router.
l The network types of the two ends of the OSPF link are different.
l The difference between the maximum transmission units (MTUs) of the two ends of the
OSPF link is great.
l OSPF is disabled on the network.
l The area numbers are different; the network addresses of the two ends of the link are
different. Check the masks of the IP addresses of both ends of the link.
l The configuration of IP unnumbered is incomplete. Note that when a device is
configured with IP unnumbered, the peer must also be configured with IP unnumbered.
7.6.2.33 How Can OSPF Faults Be Easily Identified?

Run the debugging ospf event command to solve most OSPF problems. If this command
fails to solve the problem, it is recommended that you enable the debugging of all the packets
by running the debugging ospf packet command to check whether packets are sent and
received normally.
7.6.2.34 How Can Faster OSPF Convergence Be Achieved?

OSPF convergence speed is affected by the following factors:

l A router detects that the peer link is down and the neighbor relationship becomes invalid;
l A new link-state advertisement (LSA) is generated and flooded;
l The Link State Database (LSDB) is updated. A new route is calculated through the
Shortest Path First (SPF) routing algorithm and delivered to the Forwarding Information
Base (FIB) table.
For faster OSPF convergence, you can adjust the following options on the HUAWEI
NetEngine40E/80E:
l Shorten the hello interval and dead interval of the neighbor, or configure Bidirectional
Forwarding Detection (BFD) for fast failure detection;
l Decrease the spf-schedule-interval (five seconds by default) to shorten the time interval
between two SPF algorithm operations;
l Shorten the LSA generation interval;
l Shorten the interval of detecting LSA arrival;
l On the interface, run the ospf trans-delay command to speed up the flooding of LSAs.
7.6.2.35 Can a Full Neighbor Relationship Be Established if the Network Types

of the Two Ends of an OSPF Link Are Different?
Yes. Assume two routers are interconnected through an Ethernet link. On one end of the link,
the default network type, that is, broadcast, is adopted. The other end is configured as OSPF
Peer-to-peer (P2P). Neighbor relationship can be established between these two routers,
which reach the Full state by exchanging their Link State Databases (LSDBs).
However, no route can be learnt because OSPF routers need LSDBs to construct a Shortest
Path Tree (SPT). The LSDBs, however, are problematic. That is, the link-state advertisements
(LSAs) generated by one end consider the peer a broadcast neighbor, while the other end
considers the peer a P2P neighbor. Therefore, no SPT can be constructed correctly and the
Shortest Path First (SPF) cannot calculate the right routes neither.
7.6.2.36 Why Cannot OSPF Inter-Area Route Summarization Take Effect?

According to RFC 2328, the inter-area Type-3 link-state advertisements (LSAs) generated by
an Area Border Router (ABR) are directly processed into corresponding Type-3 LSAs
regardless of the configured range. Summarization configuration is considered only in the
case of intra-area routes.
Such route aggregation, even if achieved, causes more LSAs to be advertised to the backbone
area, making the network unstable.
7.6.2.37 Why Are the Routes with Smaller Costs Passing Through the Backbone
Area Not Preferred?
OSPF defined by RFC 2328 must be backward compatible with RFC 1583. As specified in
RFC 2328, if "RFC1583 Compatibility" is disabled, when routes can be learnt through
common areas and the backbone area, the routes learnt through common areas are preferred
regardless of their costs. This is to reduce the burden on the backbone area.
7.6.2.38 Can the OSPF Network Type Be Configured As P2P or NBMA?

Yes. This configuration, however, is not recommended unless necessary or you are aware of
the consequences of modifying the default network type. A beginner may believe that the

broadcast and P2P networks in OSPF must also be broadcast or P2P at the link layer.
Actually, the OSPF network type is independent of the physical media and link layer protocol.
7.6.2.39 Does the HUAWEI NetEngine40E/80E Support OSPF MD5

Authentication on an Interface?
Yes. For example, if interface POS 1/0/0 of router RT1 and interface POS 2/0/0 of router RT2
are on the same network segment, perform these steps to configure OSPF MD5
authentication:
# Configure RT1.
<RT1> system-view
[RT1] interface pos 1/0/0
[RT1-Pos1/0/0] ospf authentication-mode md5
# Configure RT2.
<RT2> system-view
[RT2] interface pos 2/0/0
[RT2-Pos2/0/0] ospf authentication-mode md5
7.6.2.40 Can OSPF Establish a Neighbor Relationship by Using the Secondary IP

Address?
In OSPF, a neighbor relationship cannot be established by using the secondary IP address;
instead, a neighbor relationship can be established only by using the primary address of an
interface. If the network to which the secondary IP address belongs is added to the OSPF
configuration, however, the corresponding route can be advertised.
7.6.2.41 Two Routers Are Interconnected. After the Shut Down Command Is Run
on One of the Routers, Why Does the Original LSA Still Exist in the LSDB on the
Peer?
A router can flood only the Link-State Advertisements (LSAs) originated by the router itself.
Therefore, once the link is down, the LSA flooding cannot be updated. This LSA does not
take part in the Shortest Path First (SPF) calculation in the Link State Database (LSDB) of the
peer and ages with time.
7.6.2.42 What Are the Precautions for Configuring the Cost of a Virtual Link?
Ensure that the cost is not greater than the maximum value, that is, 65535, defined in the
related RFC. Otherwise, no virtual link can be established.
7.6.2.43 Why Does a Failure Occur in the Configuration of a Network Address/

Mask and Host Address/Mask Combination?
Perform the following steps to solve this problem:
1. Ensure that the host belongs to the same network and has the right mask.
2. Ensure that the host address and mask can be combined into a network address.
3. Ensure that the host address is unique on the network.
4. Ensure that the network address is unique on the network.

7.6.2.44 Why Does Not an LSDB Display Redistributed External Routes?

1. Run the display ospf interface command to check whether the interface on which
external routes are redistributed is in the Up state.
2. Run the display ospf brief command to check whether the router that redistributes
external routes belongs to a stub area.
3. Check whether the external routes are learnt from neighbors and whether the neighbor
relationship is in the Full state.
4. Check whether the lsdb-overflow-limit parameter is configured and whether the total
number of external routes redistributed exceeds the configured upper limit.
5. Check whether the asbr-summary command is configured to summarize external routes.
7.6.2.45 Why Does an ABR Advertise Continuous Network Segment Addresses

of an Area as a Summary Address?
1. Run the display current configuration command to check whether the network
segment addresses of the area are continuous.
2. If the network segment addresses are discontinuous, divide them into several groups of
continuous network segment addresses.
3. Run the abr-summary command to summarize each group of continuous networks into
a single network on the area border router (ABR).
4. In area view, run the filter export command and ensure that the link-state advertisements
(LSAs) summarized by the ABR are not filtered out.
7.6.2.46 Why Cannot an OSPF Route that Exists in the LSDB Be Found in the
Routing Table?
1. Check whether the interface type of one device is P2P while the interface type of the
other device is unnumbered P2P.
2. Check whether the IP address is valid.
3. Check whether the forwarding address is known and reachable.
4. Check whether the routes are summarized or redistributed correctly.
5. Check whether different masks or IP addresses are used in the Peer-to-peer (P2P)
connection.
6. Check whether route lists are advertised.
7. Check whether the backbone area is disconnected.
8. Check whether OSPF is enabled on the secondary address but not on the primary
address.
7.6.2.47 How Can Network Type Problems Be Solved Effectively?

Perform the following steps to solve network type problems:

l On a peer-to-peer (P2P) network, a neighbor relationship is established through Hello

messages.
l On a broadcast network, such as an Ethernet, Token Ring, or Fiber Distributed Data
Interface (FDDI) network, Designated Router (DR)/Backup Designated Router (BDR)
are elected through Hello messages; a neighbor relationship is established through Hello
messages.
l On a non-broadcast network, such as an frame relay (FR), and Integrated Services
Digital Network (ISDN),
– Manually establish a neighbor relationship.
– Run the ospf network-type broadcast command to change the network type to
broadcast.
– Run the peer command to establish a neighbor relationship.
7.6.2.48 Why Cannot an OSPF Sham Link Be Established?

1. Check that the router ID configured on the local router matches that on the peer.
2. Run the display ospf shamlink command to check the sham link status.
7.6.2.49 Why Cannot an OSPF Virtual Link Be Established?

1. Check that the router ID configured on the local router matches that on the peer.
2. Run the display ospf vlink command to check the virtual link status.
7.6.2.50 After MIB Parameters Are Configured on the MIB Browser and Router,
the MIB Browser Connection Fails and the OSPF MIB Cannot Be Displayed
Normally. Why?
1. Check that the Ethernet connection is normal.

2. Check whether any address conflict occurs on the network.
3. If the network is busy, decrease the retransmit interval and retransmit time of the MIB
browser.
4. Check whether ospf mib-binding is enabled on the OSPF instance.
5. The trap address specified in the snmp-agent target-host trap command and the
interface address of the MIB browser must be the same.
For example, check whether the following commands are configured correctly. If these
commands are correctly configured and the MIB browser is connected to the Ethernet, the
MIB can be displayed normally.
[HUAWEI] ospf mib-binding process-id
[HUAWEI] snmp-agent sys-info version all
[HUAWEI] snmp-agent community read public
[HUAWEI] snmp-agent community write private

7.6.2.51 Why Cannot the Standby Board Restart Through GR after a Switchover
to the Standby Board?
1. Check that graceful restart (GR) is configured properly on the master board.
2. Check that GR is configured properly on the GR Helper.
3. Check whether the topology changes on the GR Helper.
4. Check the access control list (ACL) configuration on the GR Helper.
7.6.2.52 Why Are the VPN Routes Learnt from the Peer Incorrect?
1. Ensure that the vpn-instance-capability simple command is not run on the Provider
Edge (PE) router at either end.
2. Check that domain identifiers are configured on both PEs and that at least one domain
identifier (level-2 identifier or level-1 identifier) matches the identifier of the other
router.
3. Check whether the Border Gateway Protocol (BGP) neighbor relationship is established.
4. Check whether the BGP route is correct.
7.6.2.53 Why Are IGP-Shortcut and Forwarding-Adjacency Forward Tunnel

Interfaces Not Advertised?
1. Check that the enable traffic-adjustment [ advertise ] command is run.
2. Check that OSPF supports tunnel traffic policing.
3. Check that the metric type and metric value are configured on the tunnel as needed.
4. Check that Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) is
configured correctly on the tunnel interface.
7.6.2.54 When the display ospf peer Command Is Run, Only FULL/DR and
FULL/BDR Is Displayed, with all Other Neighbors Showing 2-WAY/DROTHER.
Why?
To reduce the amount of flooding on broadcast media, such as Ethernet, Fiber Distributed
Data Interface (FDDI), and Token Ring, the router becomes full with only designated router
(DR) and backup designated router (BDR), and it shows 2-WAY for all other routers.
7.6.2.55 Why Is There No OSPF Neighbor as FULL/DR or FULL/BDR on the

Serial Port Link?
This is normal. On point-to-point (P2P) and point-to-multipoint (P2MP) networks, there are
no designated routers (DRs) or backup designated routers (BDRs). To reduce the amount of
flooding on broadcast media, such as Ethernet, Fiber Distributed Data Interfaces (FDDIs), and
Token Ring, designated routers (DRs) and backup designated routers (BDRs) are elected on
broadcast and non-broadcast multi-access networks. A router becomes full with only DRs and
BDRs, and it shows 2-WAY for all other routers.

7.6.2.56 Can an OSPF Neighbor Relationship Be Established Between Routers

that Are on Different Subnets?
A neighbor relationship can be established between two routers that are not on the same
subnet only when the routers are connected through point-to-point (P2P) links.
On a Point-to-Multipoint (P2MP) network, you can determine whether adjacencies can be
formed between neighbors that are not on the same subnet.
In all other cases, the routers must be on the same subnet.
7.6.2.57 How Can an OSPF Neighbor Relationship with a Router on a Certain

Interface Be Prevented?
To stop routers from becoming OSPF neighbors on a particular interface, run the silent-
interface command on the interface.
If the routers have a large number of interfaces, configuring the silent-interface command on
each of the interfaces is difficult. In this case, configure all the interfaces as silent by using a
single silent-interface all command. Then, cancel the prohibition of neighbor relationship
establishment on interfaces where a neighbor relationship needs to be established by running
the undo silent-interface command.
7.6.2.58 What Is the Relationship Between OSPF Interface Authentication and

Area Authentication?
The basic principles of OSPF authentication are as follows:
If authentication is configured on the interface, use the authentication on the interface. If null
is configured on the interface, no authentication is performed on the interface. If no
authentication is performed on the interface (Null does not mean that no authentication is
configured), the authentication configured on the area is used. If no authentication is
configured on the area, either, no authentication will be performed.
l vlink-peer commands:
vlink-peer X.X.X.X authentication-null
vlink-peer X.X.X.X simple { [ cipher | plain ] STRING }
vlink-peer X.X.X.X { md5 | hmac-md5 } key-id { [ cipher | plain ] STRING }
The above three commands are mutually exclusive.

l sham-link commands:
sham-link X.X.X.X X.X.X.X authentication-null
sham-link X.X.X.X X.X.X.X simple { [ cipher | plain ] STRING }
sham-link X.X.X.X X.X.X.X { md5 | hmac-md5 } key-id { [ cipher | plain ]
STRING }

l Authentication commands in the area view:
authentication-mode simple { [ cipher | plain ] STRING }
authentication-mode { md5 | hmac-md5 } key-id { [ cipher | plain ] STRING }
l Authentication commands on a common OSPF interface:

ospf authentication-mode null
ospf authentication-mode simple { [ cipher | plain ] STRING }
ospf authentication-mode { md5 | hmac-md5 } key-id { [ cipher | plain ]
STRING }

7.6.2.59 Do Problems Occur in Route Calculation When the Backbone Area Is

Discontinuous?
If the backbone area is discontinuous, the networks in some areas may be unreachable and
routing loops may occur in inter-area routes and external routes.
7.6.2.60 What Commands Can Be Used to Obtain Common OSPF Information?

Command Description
display ospf abr-asbr Display information about the routes to OSPF area boarder
router (ABR)/Autonomous System Boundary Routers (ASBRs).
Running this command on the router in a stub area or not-so-
stubby area (NSSA) does not display the information about the
routes to the ASBR.
display ospf asbr- Displays information about the redistributed routes that are
summary summarized.
If no IP address or mask is specified, information about all
summarized redistributed routes will be displayed.
display ospf brief Displays OSPF brief information.
display ospf Displays OSPF statistics.

cumulative
display ospf error Displays OSPF error information.
display ospf interface Displays OSPF interface information.
display ospf lsdb Displays the link state database (LSDB) information. You can
display the LSDB information by specifying different
parameters, such as brief LSDB information, information about
the specified LSA type, information about LSAs originated by
the specified router, and information about self-originated LSAs.
display ospf nexthop Displays OSPF next hop information.
display ospf peer Displays information about OSPF neighbors.

You can use the output of this command to troubleshoot OSPF
faults and check the OSPF neighbor configuration.
The output information also shows whether Graceful Restart
(GR) is executed on the neighbor.
display ospf request- Displays information about the OSPF request queue.
queue The output information of this command helps you with OSPF
troubleshooting.
display ospf retrans- Displays retransmission queue information.

queue

Command Description
display ospf routing Displays OSPF routing information.

You can display the OSPF routing information advertised via an
interface or the OSPF routing information with the specified next
hop.
display ospf vlink Displays OSPF virtual link information.
display ospf sham- Displays all the sham link information about the specified OSPF
link process or area. You can display all the attributes related to the
sham link.
debugging ospf event Displays OSPF event information.
debugging ospf lsa- Displays the information about originated LSAs.

originate
debugging ospf packet Displays the information about OSPF packets. The packet types
are ACK, DD, HELLO, REQUEST, and UPDATE. If no packet
type is specified, the information about all types of OSPF
packets is displayed.
debugging ospf spf Displays OSPF Shortest Path First (SPF) debugging information,
including Tunnel interface information about the Interior
Gateway Protocol (IGP) shortcut and adjacency forwarding.
7.6.2.61 What Commands Can Be Used to Obtain the Information About the
OSPF Network Connection?
Command Description
display ospf peer Displays the information about OSPF neighbors.
display ospf error Displays the information about OSPF errors.
display ospf interface Displays the information about OSPF interfaces.
display ospf brief Displays OSPF brief information.
display ospf cumulative Displays OSPF statistics.
display ospf lsdb Displays the information about the link state
database (LSDB).
display ospf routing Displays the information about OSPF routing.
debugging ospf packet Enables OSPF packet debugging.
debugging ospf event Enables OSPF event debugging.

7.6.2.62 What Commands Are Used to Obtain the Information about the OSPF
Routing Table?
Command Description
display ospf peer Displays information about OSPF neighbors.
display ospf routing Displays OSPF routing information.
display ospf lsdb Displays the OSPF link state database (LSDB)
information.
7.6.2.63 What Commands Are Used to Obtain the Information about the OSPF
Network Type?
Command Description
display ospf interface Displays OSPF interface information.
ospf network-type Sets the network type for an interface.
7.6.2.64 Why Is the OSPF Default Cost Incorrect?

For example, after the OSPF process is enabled on the router, the information about the
interface is displayed. The output information shows that the default OSPF cost of an Ethernet
interface is 7. Generally, the default OSPF cost is 1.
The default cost of an OSPF interface is calculated based on the bandwidth and bandwidth-
reference. Bandwidth-reference is configured under the OSPF process. Normally, the default
bandwidth-reference value is used. If the default bandwidth is 100 Mbit/s, the OSPF cost is
calculated as 1.
Locate the problem of the default OSPF cost. Note the factors affecting the OSPF cost:
bandwidth-reference and bandwidth. Based on these factors, locate the fault step by step.
7.6.2.65 Under What Conditions Is the Status of OSPF Set to Invalid Adv?
Summary Count : 2
Protocol: OSPF Process ID: 588
NextHop: 20.1.200.2 Interface: Pos1/0/3
RelayNextHop: 0.0.0.0 Neighbour: 0.0.0.0
Label: NULL Tunnel ID: 0x0
SecTunnel ID: 0x0
BkNextHop: 0.0.0.0 BkInterface:
BkLabel: 0 Tunnel ID: 0x0
SecTunnel ID: 0x0
State: Invalid Adv Age: 00h57m42s
Tag: 0
Protocol: ISIS Process ID: 46435

NextHop: 172.16.234.18 Interface: GigabitEthernet7/0/1
RelayNextHop: 0.0.0.0 Neighbour: 0.0.0.0
Label: NULL Tunnel ID: 0x83810BD5
SecTunnel ID: 0x0
BkNextHop: 0.0.0.0 BkInterface:
BkLabel: 0 Tunnel ID: 0x0
SecTunnel ID: 0x0
Tag: 0
In the preceding command output information, the state field is set to Invalid Adv because:
l A route, such as a direct route, with a smaller preference, exists.

l The route is filtered out by the filter policy.
l The output interface is on a sham link.
7.6.2.66 Why Does the ASBR Generate No Equal-Cost Route?

Two areas are configured on two routers separately, for example:
l Router A:
– area 0: 5.5.5.5
– area 1: 4.4.4.4
l Router B:
– area 0: 5.5.5.6
– area 1: 4.4.4.6
Adjacencies are formed on the routers separately.
Therefore, the next-hop of a route that Router B learns from Router A should be 5.5.5.5 or
4.4.4.4. However, the route on Router B goes through only 4.4.4.4 in area 1 as the gateway
and no load sharing can be performed.
This is because when multiple equal-cost routes exist, an ASBR selects the route with the
greatest area ID.
7.6.2.67 Why Cannot OSPF Import BGP Routes?

As defined in RFC 1364, OSPF cannot import IBGP routes.
Routes learned via IBGP must not be imported into OSPF
OSPF, however, can import IBGP routes on a PE.
BGP routes exist in a VPNv4 routing table on a device functioning as a PE but cannot be
imported to OSPF. This is because the role of the router changes from a PE to an MCE after
the vpn-instance-capability simple command in run in the OSPF process.
Solution: If the router needs to function as a PE, you need to run the undo vpn-instance-
capability simple command on the router.
7.6.2.68 What Does Each Error Value in the Output of the display ospf error
Command Mean?
l General packet errors: indicates the statistics about general packet errors.

– IP: received my own packet: indicates that a device receives a packet with the
source address being the IP address of the device.
Cause: A Layer 2 loop occurs.
– Bad packet: indicates that an error packet is received.
The causes are listed as follows:
n The router ID contained in the received packet is 0.
n The sum of the IP header length and packet length is different from the length
of the packet received by socket.
n The packet length is incorrect in the following situations:
○ The IP header length is smaller than the length of the OSPF packet.
○ The length of the OSPF packet is smaller than the length of a Hello
packet header.
○ The length of the OSPF packet is smaller than the length of a DD packet
header.
○ The length of the OSPF packet is smaller than the length of a Request
packet header.
○ The length of the OSPF packet is smaller than the length of an Update
packet header.
○ The number of LSAs in an Update packet is inconsistent with the number
of calculated LSAs.
○ The length of the OSPF packet is smaller than the length of an ACK
packet.
n The type value of the OSPF packet is greater than 5.
n An error is returned during packet processing.
n An error occurs during packet parse.
– Bad version: indicates that the version number is incorrect.
Cause: The OSPF version number contained in the received packet is not 2.
– Bad checksum: indicates that the checksum is incorrect. The value is not counted.
– Bad area id: indicates that a packet is received from an area that the interface does
not belong to.
Cause: The area whose ID is changed is restarted and a retransmitted packet is
received.
– Drop on unnumbered interface: indicates the number of packets discarded by an
unnumbered P2P interface.
Cause: The OSPF network type configured on the unnumbered P2P interface is not
P2P.
– Bad virtual link: indicates the number of error packets received on the Vlink.
n The Vlink is a null link and the packet is received from an area that the
interface does not belong to.
n The current status of the interface that receives the packet is not P2P.
n The router ID contained in the packet is not the router ID of the neighbor on
the Vlink.
– Bad authentication type: indicates that the authentication type is incorrect.


n The calculated checksum is inconsistent with the one filled in the packet
header by the sender.
n Null authentication fails.
n Simple authentication fails.
n MD5 authentication fails.
– Bad authentication key: indicates that the authentication key is incorrect.
n The null authentication is incorrect and the returned type value of the
authentication error is 0.
n The simple authentication is incorrect and the returned type value of the
authentication error is 2.
n The MD5 authentication is incorrect and the authentication error type is
returned.
n Other errors occur and the returned type value of the authentication error is 1.
– Packet too small: indicates that a packet of an improper length is received.
Cause: The sum of the IP header length and packet length is different from the
length of the packet received by socket.
– Packet size > ip length: indicates that the packet length is greater than the specified
value. This value is not counted.
– Transmit error: indicates that the packet is incorrectly transmitted.
Cause: The packet fails to be transmitted.
– Interface down: indicates the number of OSPF interfaces in the Down state.
Cause: The count is increased by 1 each time an OSPF interface becomes Down.
– Unknown neighbor: indicates that there is no corresponding neighbor.
n A non-Hello packet is received but there is no corresponding neighbor.
n The packet is received on the Vlink but there is no corresponding neighbor.
n The packet is received in an NBMA network but there is no corresponding
neighbor.
– Netmask mismatch: indicates that the network mask is unmatched.
Cause: The mask contained in the header of the Hello packet received in a non-P2P
network is inconsistent with the mask of the interface that receives the packet.
l HELLO packet errors: indicates the statistics about Hello packet errors.
– Hello timer mismatch: The values of the Hello timers on the two ends of a link are
inconsistent.
Cause: The set values of the Hello timers on the two ends of a link are different.
– Dead timer mismatch: indicates the values of the dead timers on the two ends of a
link are inconsistent.
Cause: The values of the dead timers on the two ends of a link are different.
– Extern option mismatch: indicates that the Option bits in Hello packets mismatch.
n The received Hello packet carries the E bit and NP bit.

n The Hello packet with the E bit is received in the stub area.
n The Hello packet with the E bit is not received in a common area.
n The Hello packet without the NP bit is received in the NSSA.
n The Hello packet with the NP bit is received in a common area.
– Router id confusion: indicates that router IDs conflict.
Cause: The router IDs of two neighboring devices conflict (note: this count is
applicable to only the case that the router IDs of two neighboring devices conflict,
and is inapplicable to router ID conflict on the entire network).
– Virtual neighbor unknown: indicates an unknown neighbor on a Vlink.
Cause: The router ID in the received Hello packet is different from that of the
neighbor on the Vlink.
– NBMA neighbor unknown: indicates an unknown NBMA neighbor.
Cause: The network type of the neighbor contained in the received Hello packet is
NBMA, but the NBMA neighbor does not exist.
– Invalid Source Address: indicates that the source address of the packet is invalid.
Cause: The Hello packet is received but there is no corresponding neighbor.
l DD packet errors: indicates the statistics about DD packet errors.
– Neighbor state low: indicates that status of the neighbor that receives the DD packet
is low.
n The neighbor in the Down or Attempt state receives the DD packet.
n The neighbor in the state lower than Exchange receives an LSRequest packet.
n The neighbor in the state lower than Exchange receives an Update packet.
n The neighbor in the state lower than Exchange receives an ACK packet.
– Router id confusion: is not used.
– Extern option mismatch: is the same as that in a Hello packet.
– Unknown LSA type: is not used.
– MTU option mismatch: indicates that the MTU in the received DD packet is greater
than that configured on the interface.
Cause: The MTU in the received DD packet is greater than the OSPF MTU
configured on the interface.
l LS ACK packet errors: indicates the statistics about LSAck packet errors.
– Neighbor state low: is the same as that in a DD packet.
– Bad ack: indicates that an ACK packet in which the LSA is unmatched with that in
the retransmission list in terms of the contents and age is received.
Cause: The LSA contained in the ACK packet sent by the neighbor is unmatched
with that in the retransmission list in terms of the contents and age.
– Duplicate ack: indicates duplicate ACK packets.
Cause: An Ack packet is replied several times for an LSA. This count is not
considered as an error on a broadcast network.
l LS REQ packet errors: indicates the statistics about LSRequest packet errors.
– Neighbor state low: is not used.

– Empty request: is not used.

– Bad request: indicates that an incorrect request packet is received.
n Duplicate LSAs are received from the neighbor but the LSA still exists in the
request list.
n An old LSA is received from the neighbor but the LSA still exists in the
request list.
n A request packet is received from the neighbor but the requested LSA is null
on the local node.
l LS UPD packet errors: indicates the statistics about Update packet errors.
– Neighbor state low: is not used.
– Newer self-generate LSA: is not used.
– LSA checksum bad: is not used.
– Received less recent LSA: indicates that an LSA that is older than that in the LSDB
is received.
Cause: An older LSA is received, that is, the device has a new LSA.
l Opaque errors: indicates statistics about Opaque LSA errors.
– 9-out of flooding scope: indicates that the flooding of Type 9 LSAs is out of the
flooding range.
Cause: Type 9 Opaque LSAs are received but the Opaque capability is not enabled.
flooding range.
Cause: Type 10 Opaque LSAs are received but the Opaque capability is not
enabled.
flooding range.
Cause: Opaque LSAs are received when the Opaque capability is not enabled, or
Type 11 LSAs are received when the current area does not support the As-external-
lsa capability.
l Retransmission for packet over Limitation errors: indicates that the number of packet
retransmission times exceeds the set limit.
– Number for DD Packet: indicates that the number of DD packet retransmission
times exceeds the set limit.
Cause: After the limit on the number of packet retransmission times is set, the
neighbor becomes Down and the count is increased by 1, each time the number of
DD packet retransmission times exceeds the set limit.
– Number for Update Packet: indicates that the number of Update packet
Update packet retransmission times exceeds the set limit.
– Number for Request Packet: indicates that the number of request packet

LS Request packet retransmission times exceeds the set limit.
l Receive Grace LSA errors: indicates the statistics about received Grace LSA errors.
– Number of invalid LSAs: indicates the number of invalid Grace LSAs.
Cause: The received Grace LSA is incorrectly parsed.
– Number of policy failed LSAs: indicates the number of policy failures.
Cause: The GR helper policy fails and the device fails to enter the helper state.
– Number of wrong period LSAs: indicates that the value of the GR timer contained
in the received Grace LSA is incorrect.
n The aging time of the Opaque-LSAs is not 3600s and greater than the GR
period.
n The value of the age field in the received Opaque-LSA is greater than 1800.
l Configuration errors: indicates the statistics about configuration errors.
– Tunnel cost mistake: indicates that the cost of the tunnel is incorrect.
Cause: The cost of the tunnel is not greater than 0.
– The network type of the neighboring interface is not consistent: indicates that the
network type of the local interface is inconsistent with that of the neighboring
interface.
Cause: The network types configured on the neighboring interfaces may be
inconsistent.
7.6.2.69 What Is the Difference Between Unplanned GR and Planned GR?

The difference between unplanned GR and planned GR is as follows:
During the unplanned GR, the restarter does not send any Grace LSA before the active/
standby switchover, that is, the restarter does not instruct its neighbor to enter the Helper state.
The restarter sends a Grace LSA after the active main control board becomes the standby
main control board. Therefore, the GR period cannot be greater than the value of the dead
timer.
IETF GR has a graceful period timer. The value of the timer needs to be negotiated by the
restarter and the helper, and finally is negotiated as the value of the timer on the restarter. The
default value of the timer is 120s.
7.6.2.70 Are the MTUs in the DD Packets Exchanged to Establish an OSPF

Neighbor Relationship Checked?
When the interfaces are configured with different MTUs, OSPF can normally set up the
neighbor relationship. By default, OSPF does not check the MTUs in DD packets.
When the ospf mtu-enable command is run on an interface, the OSPF neighbor relationship
cannot be set up when the MTUs in the DD packets are inconsistent with the one set on the
interface. In this case, the MTUs in the DD packets need to be checked. If the MTU in a DD
packet is greater than the MTU set on the interface, the interface discards the DD packet.

7.6.2.71 What Are the Destination Addresses of Various Packets Sent by

Interfaces with Different Network Types?
l Hello packets:
On a broadcast, P2MP, or P2P network, Hello packets are destined for multicast address
224.0.0.5. On a virtual link, Hello packets are unicast from one end to the other end. On
an NBMA network, Hello packets are unicast from a node to its neighbors.
l DD packets, LSRs, and LSUs:
On a broadcast, P2MP, or NBMA network, DD packets, LSRs, or LSUs are unicast from
a node to its peers. On a P2P network, DD packets, LSRs, or LSUs are destined for
address 224.0.0.5.
l LSAck packets:
– On a P2P network, LSAck packets are destined for address 224.0.0.5.
– On a P2MP or an NBMA network, LSAck packets are unicast from a node to its
neighbors.
– On a broadcast network, the situation is a little complicated.
i. If an LSAck packet is directly sent by a device, the LSAck is unicast by the
device to its neighbor.
ii. If an LSAck packet is sent by a device after a certain delay, the LSAck packet
is sent in multicast mode. If the current interface is a DR or a BDR, the
interface sends the LSAck packet to multicast address 224.0.0.5. Otherwise,
the LSAck packet is sent to multicast address 224.0.0.6.
7.6.2.72 How to Determine that Configured OSPF Router IDs Conflict?

1. Problem phenomenon
On an OSPF network, configured OSPF router IDs conflict sometimes. Once a router ID
conflict occurs, OSPF LSAs are frequently aged and generated, causing network
unstable. This is because a router ID uniquely identifies an OSPF device. When a router
ID conflict occurs, the following situations occur:
– The CPU usage is high, which is mainly caused by the Rout task.
– Routing flapping occurs.
2. Methods of determining an intra-area router ID conflict
The network topology is assumed as follows:
Router ID: Router ID: Router ID: Router ID:

1.1.1.1 Area0 2.2.2.2 1.1.1.1 Area0 4.4.4.4
Area0
RouterA RouterB RouterC RouterD
Router A, Router B, Router C, and Router D in area 0 establish OSPF neighbor

relationships. The router IDs of Router A and Router C are 1.1.1.1. Therefore, a router
ID conflict occurs.
Identification method:

a. Run the display ospf lsdb command on any of the routers every one second to
check whether the Age field in the Router LSA frequently changes and whether the
value of the Sequence field increases quickly.
<RouterA> display ospf lsdb
Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence
Metric
Router 4.4.4.4 4.4.4.4 1410 48 80000003 1562
Router 2.2.2.2 2.2.2.2 2 48 8000001C 1562
Router 1.1.1.1 1.1.1.1 6 36 800015D0 1562
Network 10.22.22.1 2.2.2.2 7 32 80000001 0
Network 10.11.11.2 2.2.2.2 23 32 80000002 0
<RouterA> display ospf lsdb

Link State Database
Area: 0.0.0.0
Metric
Router 4.4.4.4 4.4.4.4 1411 48 80000003 1562
Router 2.2.2.2 2.2.2.2 3 48 8000001C 1562
Router 1.1.1.1 1.1.1.1 0 36 800015D3 1562
Network 10.22.22.1 2.2.2.2 8 32 80000001 0
Network 10.11.11.2 2.2.2.2 24 32 80000002 0
In this example, on the device with the router ID being 1.1.1.1, the Age field in the
Router LSA frequently changes and the value of the Sequence field increases
quickly.
b. Run the display ospf routing command on Router B every one second, and you can
find that route flapping occurs. If intra-area route flapping occurs but neighbor
flapping does not occur, it can be determined that a router ID conflict occurs.
<RouterB> display ospf routing

Routing Tables
Routing for Network
Destination Cost Type NextHop AdvRouter Area
10.33.33.0/24 3124 Transit 10.22.22.2 4.4.4.4
0.0.0.0
10.22.22.0/24 1562 Transit 10.22.22.1 2.2.2.2
0.0.0.0
10.11.11.0/24 1562 Transit 10.11.11.2 2.2.2.2
0.0.0.0
Total Nets: 3
Intra Area: 3 Inter Area: 0 ASE: 0 NSSA: 0
<RouterB> display ospf routing
Routing Tables
Routing for Network

10.22.22.0/24 1562 Transit 10.22.22.1 2.2.2.2
0.0.0.0
10.11.11.0/24 1562 Transit 10.11.11.2 2.2.2.2
0.0.0.0
Total Nets: 2
3. Methods of determining an inter-area router ID conflict


Router ID: Router ID: Router ID:

1.1.1.1 2.2.2.2 1.1.1.1
Area0 Area1
RouterA RouterB RouterC
The router ID of Router A conflicts with that of Router C, but Router A and Router C are
not in the same area.
Run the display ospf lsdb command on any of the routers every one second. If a large
number of AS external LSAs from the same router are frequently refreshed, it can be
determined that an inter-area router ID conflict occurs.
<HUAWEI> 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 172 48 80000002 1562
Router 1.1.1.1 1.1.1.1 174 48 80000003 1562
Sum-Net 10.22.22.0 2.2.2.2 166 28 80000001 1562
Sum-Asbr 1.1.1.1 2.2.2.2 38 28 80000001 1562

Link State Database
Area: 0.0.0.0
Router 2.2.2.2 2.2.2.2 173 48 80000002 1562
Router 1.1.1.1 1.1.1.1 175 48 80000003 1562
Sum-Net 10.22.22.0 2.2.2.2 167 28 80000001 1562
Sum-Asbr 1.1.1.1 2.2.2.2 39 28 80000001 1562
AS External Database
External 10.1.2.0 1.1.1.1 3600 36 80000004 1
External 10.1.3.0 1.1.1.1 3600 36 80000004 1
External 10.1.1.0 1.1.1.1 3600 36 80000004 1
Generally, a router ID conflict occurs on a network sometimes. Therefore, you need to master
the methods of determining a router ID conflict to quickly locate the fault. After eliminating
the router ID conflict, run the reset ospfprocess-id command to make the configuration take
effect.
7.6.2.73 How to Determine that the IP Addresses of Interfaces in an OSPF Area

Conflict?
1. Problem phenomenon
On a network, correct routes fail to be generated sometimes, because interfaces on
different devices are configured with the same IP address. On an OSPF network, when
the IP addresses of interfaces conflict, OSPF LSAs are frequently aged and generated,
causing the network unstable. When the IP addresses of interfaces conflict, the following
situations may occur:

– The CPU usage is high, which is mainly caused by the ROUT task.
– Routing flapping occurs.
2. Methods of determining an intra-area IP address conflict
Router ID:1.1.1.1 Router ID:2.2.2.2 Router ID:3.3.3.3 Router ID:4.4.4.4

10.11.1.1 10.11.1.2
10.22.1.2 10.12.1.2
10.22.1.3 10.12.1.4
10.12.1.2 10.12.1.1
RouterA RouterB RouterC RouterD
a. Conflict between the IP addresses of a DR and a non-DR

The interface with the IP address being 10.12.1.2 on Router A functions as a DR,
and the interface with the IP address being 10.12.1.2 on Router C is not a DR. The
IP addresses of the two interfaces conflict.
Run the display ospf lsdb command on Router C every one second. You can find
that the Age field of the Network LSA is always 3600 or the Network LSA does not
exist once in a while and the value of the Sequence field increases quickly on the
network where the IP addresses of interfaces conflict.
Link State Database
Area: 0.0.0.0
Metric
Router 4.4.4.4 4.4.4.4 2 48 8000000D 1
Router 3.3.3.3 3.3.3.3 6 72 80000016 1
Router 2.2.2.2 2.2.2.2 228 60 8000000D 1
Router 1.1.1.1 1.1.1.1 258 60 80000009 1
Network 10.12.1.4 4.4.4.4 121 32 80000001 0
Network 10.12.1.2 1.1.1.1 3600 32 80000015 0
Network 10.22.1.3 3.3.3.3 227 32 80000003 0
Network 10.11.1.1 1.1.1.1 259 32 80000002 0
Metric
External 192.168.1.2 4.4.4.4 206 36 80000032 1
Run the display ospf lsdb command on the other routers. You can find that the Age
field of the Network LSA switches between 3600 and a smaller value and the value
of the Sequence field increases quickly on the network where the IP addresses of
interfaces conflict. Run the display ospf routing command on Router B every one
second, and you can find that route flapping occurs. If intra-area route flapping
occurs but neighbor flapping does not occur, it can be determined that an IP address
conflict or a router ID conflict occurs. For details about how to eliminate a router
ID conflict, see "How to Determine that the Configured OSPF Router IDs
Conflict?"
<HUAWEI> display ospf routing
Routing Tables
Routing for Network
10.23.1.0/24 2 Stub 10.22.1.3 3.3.3.3
0.0.0.0

10.12.1.0/24 2 Transit 10.22.1.3 4.4.4.4

0.0.0.0
10.21.1.0/24 2 Transit 10.22.1.3 4.4.4.4
0.0.0.0
10.11.1.0/24 1 Transit 10.11.1.2 2.2.2.2
0.0.0.0
10.34.1.1/32 2 Stub 10.11.1.1 1.1.1.1
0.0.0.0
10.22.1.0/24 1 Transit 10.22.1.2 3.3.3.3
0.0.0.0
Routing for ASEs
Destination Cost Type Tag NextHop
AdvRouter
192.168.1.2/32 1 Type2 1 10.22.1.3
4.4.4.4
Total Nets: 7
b. Conflict between the IP addresses of two DRs

The interface with the IP address being 10.12.1.2 on Router A functions as a DR,
and the interface with the IP address being 10.12.1.2 on Router C also functions as
a DR. The IP addresses of the two interfaces conflict.
Run the display ospf lsdb command on any router every one second. You can find
that there are two Network LSAs with the LinkState ID being 10.12.1.2, and the
values of the Age fields of the two LSAs are always small and the values of the
Sequence fields increase quickly.
Link State Database
Area: 0.0.0.0
Metric
Router 4.4.4.4 4.4.4.4 17 48 8000011D 1
Router 3.3.3.3 3.3.3.3 21 72 8000015A 1
Router 2.2.2.2 2.2.2.2 151 60 80000089 1
Router 1.1.1.1 1.1.1.1 1180 60 8000002A 1
Network 10.12.1.2 3.3.3.3 3 32 8000016A 0
Network 10.12.1.2 1.1.1.1 5 32 80000179 0
Network 10.22.1.3 3.3.3.3 145 32 8000002D 0
Network 10.21.1.4 4.4.4.4 10 32 80000005 0
Network 10.11.1.2 2.2.2.2 459 32 80000003 0
Metric
External 192.168.1.2 4.4.4.4 30 36 80000037 1
3. Methods of determining an intra-area IP address conflict

a. For the conflict between the IP address of a DR and the IP address of a non-DR,
you can find the conflicting IP addresses based on the LinkState ID in the flapping
Network LSA, and then find one of the devices based on AdvRouter and locate the
interface. The other device can be found only based on network IP address
planning. It is difficult to find the other conflicting device based on information
carried by OSPF LSAs.
In this example, you can determine that the conflicting IP address is 10.12.1.2, and
the router ID of one of the devices is 1.1.1.1. The other device with the router ID
being 3.3.3.3 cannot be found based on the information carried by OSPF LSAs.
b. When the addresses of two DRs conflict, you can determine the IP addresses of
which interfaces on which devices conflict based on LinkState Id and AdvRouter
fields of the two Network LSAs with the same LinkState IDs.

In this example, it is easy to find the devices (with router IDs being 3.3.3.3 and
1.1.1.1 respectively) whose interface addresses conflict and the corresponding
interfaces based on LinkState IDs.
Generally, a router ID conflict occurs on a network sometimes. Therefore, you need to master
the methods of determining a router ID conflict to quickly locate the problem and solve the
problem.
7.6.2.74 The Local Device Advertises a Host Route with a 24-bit Mask of a
Loopback Interface to Its Neighbor. Why Is the Mask Length of the Route in the
Routing Table of the Neighbor Changed to 32 Bits?
As defined in RFC 2328, OSPF advertises a host route with a 24-bit mask of a loopback
interface as a host route with a 32-bit mask.
It is meaningless to advertise the network segment route of a loopback interface. This is

because a loopback interface cannot be connected to an actual network and it is improper to
import network segment traffic to a loopback interface.
7.6.2.75 Why Is an OSPF Neighbor Relationship Established Slowly (One

Minute) on a Broadcast Network with a Few Routes?
On a broadcast network, when the OSPF neighbor status is 2-way, the DR and BDR need to
be selected through negotiation. Generally, the DR and BDR are selected after the waiting
timer times out. The default value of the waiting timer is 40s.
Therefore, it takes about 1 minute to establish an OSPF neighbor relationship.
7.6.2.76 Why Are the OSPF Routes in the Routing Table in the Inactive State?
A policy for filtering all OSPF routes is configured in an OSPF process. As a result, all OSPF
routes in the routing table are in the Inactive state.
7.6.2.77 Why Does the Interface of an OSPF Process Have Different Statuses
Simultaneously?
If a tunnel interface and a loopback interface run OSPF and the tunnel interface borrows the
address of the loopback interface, when the tunnel interface becomes Down but the loopback
interface works normally, the problem occurs. You can run the display ospf interface all
command to view the details.
Interfaces
Interface: 1.1.1.1 (LoopBack0)
Cost: 1 State: DR Type: Broadcast MTU: 1500
Priority: 1
Interface: 1.1.1.1 (Tunnel2/0/0)
Cost: 1562 State: Down Type: P2P MTU: 1500
Unnumbered

7.6.2.78 Why Cannot OSPF P2P Interfaces on a Square-Shared Network Establish

an OSPF Neighbor Relationship?
As shown in Figure 7-8, four devices form a square-shared network. Why cannot P2P
interfaces in the same VLAN establish an OSPF neighbor relationship?
Figure 7-8 Square-shared network
RouterA RouterB
VLAN10
RouterD RouterC
A: A Hello packet sent by a device is broadcast in the entire VLAN because the four
interfaces are in the same VLAN and the Hello packet is sent in multicast mode. After
receiving the Hello packet from an P2P interface, another device immediately attempts to
establish an OSPF neighbor relationship because the P2P interface does not check the mask in
the Hello packet. Because an P2P interface can establish only one neighbor relationship, the
device ignores the Hello packets sent by other devices. As a result, the neighbor relationship
is always in the Init state.
l If Router A sends a Hello packet and Router B receives the Hello packet, Router A
considers Router B as its neighbor.
l If Router B sends a Hello packet and Router C receives the Hello packet, Router B
considers Router C as its neighbor.
l If Router C sends a Hello packet and Router D receives the Hello packet, Router C
considers Router D as its neighbor.
l If Router D sends a Hello packet and Router A receives the Hello packet, Router D
considers Router A as its neighbor.
As a result, a dead loop occurs, causing a failure to establish an OSPF neighbor relationship.
7.6.2.79 Why Is the Calculated Metric of an OSPF Link 65535?

This is because the stub-router command is run in the OSPF process. After the stub-router
command is run on a router, the router instructs other OSPF routers not to use this stub router
for data forwarding by increasing the metrics of the links in the LSA generated by the router
to 65535.

7.6.2.80 What Are the Rules of Filling In the FA Field of an OSPF LSA?
When the outbound interface of an imported route is enabled in the same NSSA and is a
broadcast interface, the Forwarding Address (FA) field of the LSA is filled in with the next
hop address of the imported route.
If there is a loopback interface in the NSSA, the FA field of the LSA is filled in with the
address of the loopback interface. If there is no loopback interface in the NSSA, the FA field
of the LSA is filled in with the address of the interface that goes Up first in the NSSA.
7.6.2.81 Does a Device Support OSPF NSF Described in RFC 3623?

The device supports OSPF Non-Stop Forwarding (NSF).
7.6.2.82 What Are the Recommended Values of OSPF Timers?

The recommended values of OSPF timers are as follows:
l ospf timer hello: 10s (default value)
l spf-schedule-interval: 50 ms
l lsa-originate-interval: 0
l lsa-arrival-interval: 0
l ospf trans-delay: 1s (default value)
7.6.2.83 Why Do OSPF Neighbors Have Problems Forming an Adjacency?

l An interface is not Up.
l OSPF is not enabled on an interface where it is needed.
l An interface is configured to work in silent mode.
l The OSPF Hello packet is filtered out by an inbound ACL.
l The interface masks are mismatched.
l The Hello timer values are mismatched.
l The authentication types or authentication keys are mismatched.
l Area IDs are inconsistent.
l Area flags are inconsistent.
l Router IDs are duplicated.
7.6.2.84 Why Is the OSPF Neighbor Stuck in a Certain State?
Stuck in the Init State

The Init state indicates that a router can receive Hello packets from its neighbor but it does not
see itself in the Neighbor field of the neighbor's Hello packets.
l The neighbor is configured with an improper ACL, which filters out the Hello packets
sent by the router.

l The link is faulty. For example, the link is a unidirectional link and can only receive
packets rather than send packets. As a result, the Hello packets cannot reach the
neighbor. Such a cause is common on an NBMA network.
l On an NBMA network, mapping is required between Layer 2 and the IP address. In case
of static mapping, the key parameter Broadcast is missing.
Stuck in the Attempt State

The attempt state exists only on an NBMA network. This state indicates that a router is
sending Hello packets to a statically configured neighbor but has not received any response.
l The neighbor is configured with an improper ACL, which filters out the Hello packets
sent by the router.
l The Layer 2 link is faulty, which cause the Hello packets unable to reach the neighbor.
Stuck in the 2-way State

The 2-way state indicates that a router has established a two-way adjacency with a remote
end.
In broadcast or NBMA mode, the 2-way state of DRothers is a normal state.
In other modes, if neighbors are stuck in the 2-way state, it is an abnormal situation and the
possible cause is that the Layer 2 link is faulty.
Stuck in the Exstart/Exchange State

Router A Router B
In the networking shown in the preceding diagram, the MTU of Router A is larger than that of
Router B and the router ID of Router B is larger than that of Router A.
After Router A and Router B establish two-way communication, they negotiate a master/slave
relationship and determine initial DD sequence numbers for exchanging DD packets. The
negotiation result is that Router B acts as the master. After Router A receives an initial DD
packet from Router B, it sets the status of Router B to exchange and also sends a DD packet
carrying the DD sequence number negotiated for Router B. After Router B receives the DD
packet from Router A, it finds that the MTU (carried in the DD packet) of Router A
mismatches its own MTU and therefore ignores the received DD packet. Router B then re-
sends a DD packet. On Router B, you can view that Router A is stuck in the Exstart state.
Stuck in the Loading State

In the loading state, neighbors exchange LSRs and LSUs to obtain detailed LSAs. If a
neighbor is stuck in this state, it indicates that the LSR or LSU exchange fails.

l The neighbor responds with an incorrect packet after receiving an LSR: You can run the
display ospf error command to find whether such an error occurs.
l No sufficient memory is available to process the packet received from the neighbor: You
can run the display process memory command to check the process memory.
7.6.3 IS-IS
7.6.3.1 What Is the Difference Between IS-IS and OSPF in the OSI Reference
Model Posed by the ISO?
IS-IS packets are encapsulated at the link layer into RawLink packets; OSPF packets are
encapsulated at the IP layer into RawIP packets.
Figure 7-9 shows the format of an IS-IS packet.
Figure 7-9 IS-IS packet format

MTU (1500 bytes by default)
Destination Source Len LLC IS-ISpacket

MAC MAC
6 bytes 6 bytes 2 bytes 3 bytes
7.6.3.2 What Are the Characteristics of IS-IS and OSPF In Terms of Protocols?
Item IS-IS OSPF
Whether it is originally No Yes

designed for IP
Whether it is a link-state Yes Yes

IGP
Whether it is directly Yes No

running at the link layer
Whether it introduces the Yes Yes

concept of area
Whether it is applicable to Yes Yes

hierarchical large-scale
networks
Whether it defines a Yes Yes

designated router (DR)

Item IS-IS OSPF
Whether the DR election is Yes No

implemented in preemption
mode
Whether an LSP is Yes Yes

generated to describe the
network structure
Whether it supports IP Yes Yes
Whether it supports non-IP Yes No

protocols
Applicable scope It is generally used on large- It is commonly used on

scale ISP networks. enterprise networks and ISP
networks.
Complexity It generates less LSPs and It generates more LSAs and

uses only one area. uses multiple areas.
Expansibility It supports a large single Relatively large networks are

area. generally divided into
multiple OSPF areas.
Support on TE It can be extended to It can be extended to support

support TE. TE.
Adjustability Excellent Good
7.6.3.3 Does IS-IS Support P2MP Interfaces?

IS-IS does not support point-to-multipoint (P2MP) interfaces.
For NE40E&NE80E, P2MP networks can be configured as a group of point-to-point (P2P)

links to implement the function of P2MP.
7.6.3.4 In the display isis interface Command Output, Why the MTU on a
Broadcast Network Is 1497 Bytes Whereas the MTU on a P2P Network Is 1500
Bytes?
By default, the physical MTUs of the POS interfaces enabled with PPP and Ethernet
interfaces are 1500 bytes.
On the P2P network that is enabled with PPP, the MTU of a P2P interface is 1500 bytes in the
display isis interface command output.
On a broadcast network, there is a 3-byte Local Link Control (LLC) field in the data
according to the 802.3 link protocol encapsulation format, and the value of this field is
FEFE03. Therefore, in IS-IS, the actual length of the data to be transmitted is 1497 bytes,
which is 3 bytes shorter than the physical MTU.

7.6.3.5 How Are IS-IS Neighbor Relationships Established?

Figure 7-10 shows the process of establishing an IS-IS neighbor relationship on an Ethernet
link.
Figure 7-10 Process of establishing an IS-IS neighbor relationship on an Ethernet link
RTA RTB
Hello ( DR = 0.0.0.0 )
Down Down
Hello ( DR = 0.0.0.0 )
Init Init
Up Hello ( DR is elected ) Up
Up LSP Up
Up CSNP Up
Up PSNP Up
On a P2P link, HUAWEI NetEngine40E/80E supports both two-way handshake and three-
way handshake. The establishment of an IS-IS neighbor relationship on a P2P link through
three-way handshake is similar to the establishment of an IS-IS neighbor relationship on an
Ethernet link, and thus is not mentioned here. Figure 7-11 shows the process of establishing
an IS-IS neighbor relationship on a P2P link through two-way handshake.
Figure 7-11 Process of establishing an IS-IS neighbor relationship on a P2P link
RTA RTB
Adjacency state Adjacency state
Down Down
IIH
Down Up
IIH
Up Up
7.6.3.6 What Are the Principles of DIS Election on a Broadcast Network?

On a network segment, the Intermediate System (IS) where the interface with the highest
Designated Intermediate System (DIS) priority resides is elected as the DIS. In the case of the
same DIS priorities, the IS where the interface with the highest MAC address resides is
selected as the DIS. The DIS priority is configured through the isis dis-priority priority-value
command. The greater the priority value, the higher the priority.

7.6.3.7 What Types of cost-style Can Be Configured in an IS-IS Process and What
Are their Features?
The following types of cost-style can be configured in an IS-IS process:
l narrow: indicates that the packets with the cost of the narrow type can be received or
sent.
l wide: indicates that the packets with the cost of the wide type can be received or sent.
l wide-compatible: indicates that the packets with the cost of the narrow or wide type can
be received but only the packets with the cost of the wide type can be sent.
l compatible: indicates that the packets with the cost of the narrow or wide type can be
received or sent.
l narrow-compatible: indicates that the packets with the cost of the narrow or wide type
can be received but only the packets with the cost of the narrow type can be sent.
NOTE
The cost-style in narrow mode ranges from 1 to 63; the cost-style in wide mode ranges from 1 to
16777215.
As shown in Table 7-8, if IS-IS processes are configured with different cost-styles, the
received and sent TLV types are different.
Table 7-8 TLV advertisement
Cost-style Received cost- Sent cost- Received TLV Sent TLV

style style
Narrow Narrow Narrow Neighbour 2 Neighbour 2
IPv4 internal IPv4 internal

128 128
IPv4 external IPv4 external

130 130
Wide Wide Wide Extended Nbr Extended Nbr

22 22
IPv4 extended IPv4 extended

135 135
Compatible Narrow or Wide Narrow or Wide Neighbour 2 Neighbour 2

128 128

130 130
Extended Nbr Extended Nbr

22 22
IPv4 extended IPv4 extended

135 135

Cost-style Received cost- Sent cost- Received TLV Sent TLV

style style
Narrow- Narrow or Wide Narrow Neighbour 2 Neighbour 2

compatible
128 128

130 130
Extended Nbr
22
IPv4 extended
135
Wide- Narrow or Wide Wide Neighbour 2 Extended Nbr

compatible 22
IPv4 internal IPv4 extended

128 135
IPv4 external
130
Extended Nbr
22
IPv4 extended
135
7.6.3.8 What Are the Functions of IS-IS Timers and What Are Their Default
Values?
The functions and default values of IS-IS timers are listed in Table 7-9.
Table 7-9 Functions and default values of IS-IS timers
IS-IS Timer Default Value Function
CSNP Timer 10s Specifies the interval for sending CSNPs on a

broadcast network by using the parameter
csnp-interval.
HELLO Timer 10s (3s for the Specifies the interval for sending Hello
DIS) messages.
lsp-retransmit Timer 5s Specifies the interval for resending LSPs, that

is, the interval between marking LSPs with
the SRM and sending LSPs on a P2P link.
lsp-throttle Timer 50 ms Specifies the minimum interval for sending

LSPs.

IS-IS Timer Default Value Function
lsp-generation Timer 2s Specifies the maximum interval for

generating an LSP.
lsp-max-age Timer 1200s Specifies the maximum Keepalive time of an

LSP generated by the current IS-IS process,
which is configured by using the timer lsp-
max-age command.
lsp-refresh Timer 900s Specifies the LSP refresh interval, which is

configured by using the timer lsp-refresh
command.
spf 10s Specifies the maximum delay of route

calculation.
PSNP Timer 5s Specifies the interval between marking

PSNPs with the SSN and sending PSNPs.
Minimum interval for 50 ms Specifies the interval between marking LSPs

sending packets on a with the SRM and sending LSPs.
broadcast network
7.6.3.9 What Is the Working Principle of BFD for IS-IS?

BFD is a simple hello protocol. It is similar to the hello protocol of IS-IS in many aspects.
Two devices periodically send BFD detection packets on the channel between them. If one
device does not receive the detection packet from the peer within a certain period of time, the
device believes that the bidirectional channel to the peer becomes faulty.
IS-IS, in conjunction with BFD, can fast detect the neighboring status. In this manner, IS-IS
devices can fast converge.
7.6.3.10 What Is the Difference Between Dynamic BFD for IS-IS and Static BFD
for IS-IS?
Differences between dynamic BFD for IS-IS and static BFD for IS-IS are as follows:
l Dynamic BFD for IS-IS is triggered by upper layer protocols; BFD sessions are
dynamically established; link failures are detected according to the BFD session status.
l Static BFD for IS-IS is manually configured to detect link failures.
7.6.3.11 What Are the Functions of T1 Timer, T2 Timer, and T3 Timer in GR?
l T1: Each interface maintains a T1 timer. If the GR restarter receives an IIH packet that
contains the RA flag and a CSNP of the same level from a helper, the GR restarter
cancels the T1 timer. Otherwise, the T1 timer expires. After the T1 timer expires for
three times, the T1 timer is deleted. The default value of the T1 timer is 3 seconds.
l T2: Each LSDB maintains a T2 timer. A Level-1-2 LSDB maintains two T2 timers;
Level-1 and Level-2 LSDBs maintain a T2 timer each. T2 is the maximum time that the
system waits for LSDB synchronization. The default value of the T2 timer is 60 seconds.

If the LSDB synchronization is completed within the default 60 seconds, the T2 timer is
canceled.
l T3: The T3 timer applies to only the restarter. Each restarter maintains a T3 timer. If the
T3 timer expires, it indicates that the LSDB synchronization fails. In this case, IS-IS sets
the overload bit in the LSP. The initial value of the T3 timer is 65535 seconds. Each
restarter maintains an adjacency with a remaining time with a neighbor device. When
GR is performed, the neighbor adds the remaining time of the adjacency and the RA set
to the restart TLV of the IIH packet, and then sends the IIH packets to the restarter. After
the IIH packets are received from the neighbor, the restarter sets the T3 timer to the
smallest value of the remaining time among those of various IIH packets. In the case that
the device is restarted and the T3 timer is running, LSPs of all devices are not
transmitted and forwarding entries are not updated. When the T3 timer is canceled or
expires, SPF calculation starts and the FIB table is updated.
7.6.3.12 What Are the IS-IS TE Features?

IS-IS TE features are as follows:
l Advertisement of link bandwidth from IS-IS to RSVP-TE, defined in RFC 3784

l IGP shortcut, defined in RFC 3906
l Forwarding adjacency, with no RFC recommendations
7.6.3.13 How to Configure IS-IS Fast Convergence?

To configure IS-IS fast convergence, run the following commands in the IS-IS process view:
l timer spf
l flash-flood
l timer lsp-generation
7.6.3.14 How to Enable IS-IS to Support IGP-LDP Synchronization?

Run the isis ldp-sync command in the interface view to enable synchronization between LDP
and IS-IS on the interface, and then run the isis timer ldp-sync command in the interface
view to change the values of the associated timers.
7.6.3.15 Where Are IS-IS and OSPF Deployed on the Network?

IS-IS is deployed on backbone networks; OSPF is deployed on MANs. OSPF is more suitable
for MAN services in terms of the protocol itself. OSPF VPN extension can prevent loops on
VPNs by default. You can also configure OSPF VPN extension not to prevent loops on VPNs.
In this manner, you can configure MCE to isolate routes.
7.6.3.16 Is IS-IS Applicable to the Network Where One CE Is Dual-Homed to

Two PEs?
IS-IS can be used in the network where one CE is dual-homed to two PEs. In IS-IS and OSPF,
the configurations of the networking where one CE is dual-homed to two PEs are different.
Figure 7-12 and Figure 7-13 show two applications of CE-PE dual-homing.

Figure 7-12 Networking diagram of CE-PE dual-homing 1
CE PE P PE CE
CE PE P PE CE
Figure 7-13 Networking diagram of CE-PE dual-homing 2
CE PE P PE CE
CE PE P PE CE
As shown in the networking, a PE imports BGP routes to IS-IS and thus IS-IS on the PE can
advertise the routes to the peer PE through a CE. IS-IS on the peer PE learns the routes as IS-
IS routes. By default, IS-IS routes are prior to BGP routes. Therefore, the RM module prefers
the IS-IS routes and then BGP routes become inactive. In this case, the PE cannot import the
BGP routes, causing route flapping.
IS-IS is not as good as OSPF in preventing route loops. OSPF marks imported BGP routes
with DN bits to prevent route loops. IS-IS does not provide mechanisms to prevent route
loops. Therefore, IS-IS needs to tag the BGP routes it imports. After learning the routes, the
peer PE filters out the routes through policies.
7.6.3.17 How to Obtain the Maximum Number of IS-IS Routes Carrying Out
Load Balancing?
The maximum number of IPv4 routes that carry out load balancing is obtained based on the
number of IPv4 routes that carry out load balancing in RM defined in the license, and the
maximum number of IPv6 routes that carry out load balancing is obtained based on the
number of IPv6 routes that carry out load balancing in RM defined in the license.

7.6.3.18 Three-way Handshake Is Implemented on P2P Interfaces of an IS-IS

Device, Why Does the Problem that the Local Device Is Up and the Remote
Device Is Down Occur?
To be compatible with the peer supporting only two-way handshake rather than three-way
handshake, the HUAWEI NetEngine40E/80E works in two-way handshake mode. As a result,
the problem that the local device is Up and the remote device is Down may occur.
7.6.3.19 In an IPv6 Topology, Why Does Not the Level-1-2 Device on an IS-IS
Network Set an ATT Flag in the Header of a Packet?
In an IPv6 topology, the Level-1-2 IS-IS device sets an ATT flag in the Multi-Topology TLV
rather than the header of an LSP. You can run the display isis lsdb verbose local command to
view the details.
7.6.3.20 What Do the Parameters in the set-overload Command Mean?

set-overload [ on-startup [ timeout1 | start-from-nbr system-id [ timeout1 [ timeout2 ] ] |
wait-for-bgp [ timeout1 ] ] [ send-sa-bit [ timeout3 ] ] ] [ allow { interlevel | external } * ]
on-startup: indicates that the overload bit remains set within a specified period (in seconds)
when a device is restarted or faulty.
timeout1: specifies the period during which the overload bit remains set after the system is
started. The default value is 600s.
start-from-nbr system-id: specifies the period during which the overload bit remains set
according to the status of a specified neighbor.
timeout1 [ timeout2 ]: sets the period during which the overload bit remains set, which is
relevant to the neighbor status. The value of the timeout2 ranges from 5 to 86400, in seconds.
The default value of the timeout2 is 1200 seconds (20 minutes).
l If the specified neighbor is Up before the timeout of timeout2, the duration of the
overload bit of the system is the value of the timeout1.
l If the specified neighbor is not Up before the timeout of timeout2, the duration of the
overload bit of the system is the value of the timeout2.
wait-for-bgp: sets the period for keeping the overload bit according to the status of the BGP
convergence.
send-sa-bit: specifies the period during which the overload bit remains in Hello packets after
the device is started.
allow: allows advertising IP prefixes. By default, advertising IP prefixes is not allowed when
the system enters the Overload state.
interlevel: allows advertising the IP prefixes learned from IS-IS devices of different levels.
external: allows advertising the IP prefixes learned from other protocols.
7.6.3.21 Q:How to View the Source of an IS-IS Route?

A: Run the display isis lsdb verbose command to view all the routes, and search for the
target IP address to view the source for a route.

For example, the source for the target IP address 10.192.197.0 is to be located. Run this
command to search for this address in the command output. the source is 10.200.31.212.
In addition, you can run the display isis table-name command to check the device names if
mappings between the device name and system ID are configured.
7.6.4 BGP
7.6.4.1 What Is the Function of the undo synchronization Command?

NE40E&NE80E does not support IGP and BGP synchronization. Therefore, the undo
synchronization command is configured by default and the configuration cannot be
modified.
7.6.4.2 Why Cannot the Router ID of the System Changed by Using the router id
Command Take Effect?
The changed router ID of the system can take effect in BGP only when the reset bgp all
command is executed. Then, BGP takes the changed router ID as the new router ID.
7.6.4.3 Why Does BGP Attempt to Establish Connections over 30 Seconds After
the Peer Is Configured?
Compared with IGP configuration, BGP configuration is more complex. In addition to the
peer and AS, the egress, multi-hop, timer, and various capabilities need to be specified.
Currently, BGP does not support dynamic capability negotiation. Therefore, these parameters,
after being modified, need to be renegotiated.
To avoid frequent interruptions during the renegotiation, a proper time parameter is required
to ensure that the relevant configurations are complete before the link establishment attempt.
RFC4271 recommends 120s, whereas 32s is adopted by Huawei devices.
7.6.4.4 What Are the Advantages of Using the Loopback Address to Establish
BGP Peer Relationship?
The loopback interface is a logical interface. Generally, it is in the Up state and is less affected
by links than physical interfaces.
7.6.4.5 Why Does One BGP End Send the Open Packet Twice Sometimes?
The BGP session relationship is not the master-slave relationship. Both BGP ends may
actively establish connections. The open packet is sent regardless of the connection
established actively or passively. In addition, one connection is terminated during the
negotiation. Therefore, the open packet may be sent twice.
7.6.4.6 How to Set the Durations of the Hold Timer and Keepalive Timer of the
BGP Peer?
You can run the peer timer command to set the durations of the Hold timer and Keepalive
timer. This command specifies the timeout period of the BGP connection and the interval to
send the Keepalive message. A longer timeout period can relieve the impact of link flapping,
whereas a shorter timeout period makes the timer rapidly perceive link changes. After

connections are established between two peers, the durations of the two timers are negotiated
by the two peers and the shorter durations are adopted.
7.6.4.7 What Do Such BGP Peer States As active, no neg, and idle (admin) Stand
For?
In addition to Idle and Established, the BGP peer has the following states:
l active: indicates that the TCP connection of the BGP session is not established.
l no neg: indicates that the capability of establishing the BGP connection is not negotiated.
The IPv4 unicast is configured on one end, whereas the IPv4 unicast and IPv4 multicast
are configured on the other end. After the neighbor is set up, you find that the IPv4
unicast is adopted through the negotiation and it is in the Established state, whereas the
IPv4 multicast is in the no neg state because the IPv4 multicast is not configured on one
end.
l Idle (Admin): indicates that the neighbor relationship is shut down initiatively and no
attempt is made to establish the neighbor relationship. If the peer ignore command is
configured or the peer is set to the Down state through the MIB, the neighbor is in the
Idle (Admin) state.
7.6.4.8 Why Are BGP Connections Re-established After the peer connect-
interface Command Is Configured?
Currently, the NE40E&NE80E does not support BGP dynamic capability negotiation.
Therefore, if certain capabilities of the BGP peer are changed, the BGP connection is
automatically disconnected and then the capabilities of the neighbor are renegotiated.
If the peer connect-interface command is configured, the BGP session needs to be set up by
designating the egress. Therefore, the source address of the TCP connection may be changed
and the TCP connection needs to be re-established by using the new source address.
In addition, after any change in BGP capabilities, such as enabling or disabling label-routing
capabilities, enabling or disabling address family capabilities (IPv4, IPv6, VPNv4, and
VPNv6), and enabling graceful restart (GR) capabilities, the BGP speaker tears down the
session with its peer and then re-negotiates the capabilities with its peer.
7.6.4.9 What Is the Function of the BGP MD5 Authentication? What Are
Functions of the simple Parameter and the cipher Parameter?
BGP MD5 authentication is designed to prevent TCP attacks. Currently, the MD5 algorithm is
cracked but can still prevent common TCP attacks.
When the MD5 algorithm is adopted, the MD5 password and TCP+BGP packets are input for
calculation and then result A is saved in the TCP packet. The TCP peer resolves the result to
check whether the TCP packet is a fake one. If so, it discards this TCP packet to guarantee
stable TCP connection.
The simple parameter and cipher parameter only determine in which mode a password is
displayed.
l For the simple parameter, the password is displayed in plaintext.
l For the cipher parameter, the password is displayed in ciphertext.
If the same password is configured on both ends, the two ends adopt the same password
during interworking.

7.6.4.10 Why Is Not the BGP Connection Disconnected Immediately After the
shutdown Command Is Run on Either Interface Between Two Devices?
The BGP connection is disconnected immediately after the shutdown command is run on the
interface only when the EBGP neighbors have direct links and the ebgp-interface-sensitive
command is configured in the BGP view (by default, this command is configured in the BGP
view). The BGP connections between other types of BGP peers are reset only after the Hold
timer times out.
7.6.4.11 Why Is the BGP Connection with the Same Peer in the VPNv4 Address
Family Disconnected After the BGP Connection with a Peer in the Unicast
Address Family Is Reset by Using the reset bgp ipv4-address Command?
If the peers in two address families adopt the same IP address, the two address families share
the same BGP session, that is, share one TCP connection. In this case, if the BGP connection
of one peer is reset, the other BGP connection is also disconnected.
7.6.4.12 How Does BGP Handle an Incorrect Packet?

After receiving a packet, BGP first checks whether it is an incorrect packet and then processes
routing information included in the packet. If the packet is found to be incorrect, BGP handles
the packet by following the rules specified by RFC 4271. If the packet cannot be handled by
the rules, the "lenient receiving but strict processing" principle is adopted. Specifically, BGP
receives all packets, including incorrect packets, but sends only correct packets.
7.6.4.13 What Is the Role of the Atomic Aggregation Attribute in Manual

Aggregation?
The atomic aggregation attribute (atomic-aggregate) indicates that the AS-Path attribute is
lost. This attribute is carried by the aggregated route that is created by the aggregate ipv4-
address { mask | mask-length } detail-suppressed command.
7.6.4.14 Why Does Automatic Aggregation Not Function on Routes of the Entire
Network Received from the Peer?
Automatic aggregation only functions on the routes imported through the import-route
command.
7.6.4.15 Does the Neighbor Relationship Need to Be Established Between RRs in

the Dual RR Backup Environment?
If the same routes are received by two RRs, there is no need to establish connections because
various computing resources may be consumed after connections are established.
However, if two RRs receive different routes or need to advertise local routes they learned, a
peer relationship must be established between the RRs. If no peer relationship is established
between the RRs, the routers in an AS have different FIB tables.
7.6.4.16 Why Does a Route Loop Occur Between IBGP Peers When EBGP Routes
Are Withdrawn?
As shown in Figure 7-14, RouterC sends a route to its EBGP neighbors, RouterA and
RouterB. According to the BGP routing policy, RouterA and RouterB send the route received

from the EBGP end to its IBGP neighbor. Then, RouterA sends the route to its IBGP neighbor
RouterB, and RouterB sends the route to RouterA. According to the routing policy, both
RouterA and RouterB prefer the route from RouterC. In this case, there are two routes with
the same prefix on RouterA and RouterB; one is the route received from RouterC; the other is
the route learned from its IBGP neighbor.
When the route is deleted by RouterC, both RouterA and RouterB receive a withdraw packet
from RouterC. According to the routing policy, RouterA and RouterB regard this route as the
preferred one. As a result, a route looping occurs for the moment.
The route loop occupies certain network bandwidth and may cause brief network congestion.
However, in most cases, route convergence completes within 1s, and user services are not
greatly affected.
Figure 7-14 Repetition of AS numbers

RouterA
AS100
AS200
RouterC
RouterB
7.6.4.17 Is It Normal That undo peer 61.255.9.20 route-policy policy_1 export

Appears in the VPNv4 View of the Configuration File?
Q: Is it normal that the following command in bold exists in the configuration file?
ipv4-family vpnv4
reflector cluster-id 10.10.10.10
undo policy vpn-target
peer mp-rr enable
peer mp-rr route-policy policy_1 export
peer mp-rr reflect-client
peer mp-rr next-hop-local
peer mp-rr advertise-community
peer 61.255.9.20 group mp-rr
undo peer 61.255.9.20 route-policy policy_1 export
peer mp-ext enable
A: It is normal. This is because the peer group mp-rr to which the peer 61.255.9.20 belongs
includes more than one peer, and all these peers may reference the policy policy_1 of mp-rr.
In addition, different peers in mp-rr may be configured with different policies or have other
configurations. The undo peer 61.255.9.20 route-policy policy_1 export command is used
to cancel the applications of the policy policy_1 on the peer 61.255.9.20.

7.6.4.18 Why Do Export Policies Configured on the RR Not Take Effect?

By default, the route reflection attribute of the reflector is the route attribute determined by
the import policy and is not affected by either the export policy or the peer { group-name |
ipv4-address | ipv6-address } next-hop-local command.
To enable the RR to modify the route attributes of BGP routes using the export policy, run the
reflect change-path-attribute command.
7.6.4.19 What Is the Difference Between valid best and valid in the Detailed BGP
Route Attributes?
When obtaining one route during the resolution of the update packet, the BGP first iterates the
route.
l If route iteration is successful, the route is reachable and valid.
l Otherwise, the route is invalid.
Then, the route is available for routing. If this route is preferred, the route becomes the best
route.
7.6.4.20 What Is Route Iteration?

Iteration refers to the following process: BGP receives a route from the IBGP neighbor.
Generally, the next hop of the route is the loopback address of the peer end. Actually, the
information about such a next hop cannot guide traffic forwarding, and the information about
the real next hop of the egress is needed.
Route iteration is classified into two types: route iteration based on the outbound interface and
next hop, and tunnel iteration.
l The iteration of the next hop for an egress indicates that the next hop learnt by BGP is
searched for in the IP routing table. When a route (generally, an IGP route) with the
actual next hop and egress information is found, the next hop and egress information is
filled in the IP routing entry of this BGP route and generate the corresponding FIB entry.
l The iteration of tunnels indicates that private routes are crossed in the VPN instance. In
this case, the next hop is the loopback address of the remote PE and the egress
information and OutGoingToken information are unavailable. In this case, this loopback
address is unavailable. The system searches for related information and fills such
information in the forwarding entry. The routing management module regards the next
hop of the route as the destination address and checks the global tunnel list to determine
whether the information about the tunnel to the destination address exists. If so, the
module fills in the tunnel information in the routing entry and generates the
corresponding FIB entry.
7.6.4.21 How Does BGP Select Routes?

When there are multiple routes to the same destination, BGP selects routes according to the
following policies:
1. BGP prefers the route with the largest PreVal.

2. BGP prefers the route with the highest Local_Pref.
3. BGP prefers the aggregated route. The preference of an aggregated route is higher than
that of a non-aggregated route.

4. BGP prefers the local route that is manually aggregated. The preference of the local
route that is manually aggregated is higher than that of the local route that is
automatically aggregated.
5. BGP prefers the local route that is imported by using the network command. The
preference of the route that is imported by using the network command is higher than
that of the local route that is imported by using the import-route command.
6. BGP prefers the route with the shortest AS_Path.
7. BGP compares Origin attributes, and selects routes whose origin types are IGP, EGP, and
Incomplete in sequence.
8. BGP prefers the route with the smallest MED.
9. BGP prefers the routes learned from EBGP. The preference of an EBGP route is higher
than that of an IBGP route.
10. BGP prefers the path with the smallest IGP metric to the next hop in an AS. If load
balancing is configured and there are multiple external routes with the same AS_Path,
load balancing is performed according to the number of configured routes.
11. BGP prefers the route with the shortest Cluster_List.
12. BGP prefers the route with the smallest Originator_ID.
13. BGP prefers the route advertised by the router with the smallest router ID.
14. BGP compares IP addresses of its peers, and prefers the route that is learnt from the peer
with a smaller IP address.
7.6.4.22 What Is the Relationship Between the Peer and the Group?
A peer may belong to different groups in different views. The connection relationship
between the peer and the group in the BGP view prevails. Other types of relationships
between the peer and the group in the VPN instance view prevail.
NOTE
The following commands take effect preferentially on a single peer.

l peer bfd
l peer bfd block
l peer bfd enable
l peer listen-only
l peer valid-ttl-hops
The new configurations of the other BGP configuration commands take effect preferentially.
7.6.4.23 What Is Route Cross?

Route cross indicates that a private network route is copied to other VPN instances.
Route cross can be divided into remote cross and local cross depending on route sources.
l Remote cross indicates that the ExtCommunity attribute of each route learnt from
VPNv4 matches the corresponding import community of the local VPN. The routes
whose ExtCommunity attribute matches the import community of the local VPN are
copied to the VPN instance.
l Local cross indicates that the routes of a specific VPN instance are copied to other VPN
instances according to the matching rules (similar to the rules of remote cross) of ERT
and IRT.

7.6.4.24 What Does the Public Parameter Indicate Which Appears After the Next
Hop Is Specified for the Static Route in the Private Network?
The Public parameter is used to configure the mutual access between the public network and
the private network. If the Public parameter is configured, the next hop of the route is a public
network address. The device searches for the destination address during packet forwarding.
Then, the device can access the public network through the next hop.
7.6.4.25 Why Does the Number of Ext-Community Attributes Increase in the BGP
Private Routing Table?
Q: The RT attribute is set to 1:1 in a VPN. Why does the Ext-Community attribute have
three additional values besides 1:1 in the routing table of the BGP private network?
Ext-Community:OSPF DOMAIN ID <0.0.0.0 : 0>, OSPF RT <0.0.0.0 : 1 : 0>,
OSPF ROUTER ID <10.1.1.1 : 0>, RT <1 : 1>
Convergence Priority: 0
AS-path Nil, origin incomplete, MED 3, pref-val 0, valid, local, best, pre 255
A: The three values are generated during the importing of OSPF multi-instance routes. The
three values are carried by BGP and sent to the remote PE. When importing the BGP route
next time, OSPF running on the remote PE can perform route calculation based on the three
values. Then, the packet processing in the intermediate MPLS network is transparent to
OSPF. For the detailed description of the three values, refer to RFC4577.
7.6.4.26 Why Must the RD Be Globally Unique When the PE Serves as a Reflector
or an ASBR?
As shown in Figure 7-15, the same RD is configured for the VPN when the RR and PE1
connect to CE1. When the neighbor between CE1 and a PE is disconnected or the neighbor
between the RR and PE1 is disconnected, the route to CE1 is not available on both PE2 and
CE2. Why?
Figure 7-15 VPN Dual-Homed Networking
CE1 RR ( PE )
VPN site
PE
10.1.1.1/8 PE2
VPN
backbone
PE1
CE2
Use the route 10.1.1.1/8 as an example. The RR learns the route and also receives the route
from PE1. If the VPN has the same RD on PE1 and the RR, the RR performs BGP route

selection. Then the RR advertises the preferred route to PE2 based on the BGP VPNv4 peer
relationship. Therefore, PE2 receives only one VPN-IPv4 route to 10.1.1.1/8.
When the direct link between the RR and CE1 is faulty, the RR sends the Update message to
PE2 to notify PE2 to delete the VPN-IPv4 route to 10.1.1.1/8. PE2 deletes the VPN-IPv4
route to 10.1.1.1/8 after receiving the message. Therefore, PE2 loses the VPN-IPv4 route to
10.1.1.1/8 and cannot forward VPN data to the destination address. In fact, PE2 should have a
route to 10.1.1.1/8 whose path is PE2 -> PE1 -> CE1.
If the RD of the VPN on the RR is different from that on PE1, PE2 receives the two VPN-
IPv4 routes to 10.1.1.1/8 from the RR and reserves them. When the link between the RR and
CE1 or that between PE1 and CE1 is faulty, PE2 deletes the corresponding route and reserves
the other route, thus enabling the normal forwarding of the data to 10.1.1.1/8.
7.6.4.27 Why Cannot BGP Peer Be Established?

To establish BGP peer relationship, a TCP session needs to be created through port 179 and
the OPEN messages need to be exchanged properly. To solve the problem, you need to
perform the following operations.
1. Run the display bgp peer command to check whether the AS number and IP address of
peers are properly configured.
2. Use the display bgp peer command to check whether the router IDs configured on both
BGP peers are conflicting.
3. If a loopback interface is used, check whether the loopback interface is set as the source
interface for sending BGP packets through the peer connect-interface command.
4. If the EBGP neighbors are not directly connected physically, check whether the peer
ebgp-max-hop command is configured.
5. Check whether a route to the neighbor is available in the routing table.
6. Use the ping -a source-ip-address host-address command to check whether the specified
connect-interface has a reachable route to the peer.
7. Check whether the ACL that disables TCP port 179 is configured.
7.6.4.28 Why Cannot the Route of 192.168.1.0/26 Be Imported After network

192.168.1.0 Is Configured?
If the mask is not configured, only the routes on the natural network segment are imported.
That is, running the network 192.168.1.0 command imports only the route of 192.168.1.0/24.
7.6.4.29 Why Do Certain IGP Routes Fail to Be Imported When the import-route
Command Is Used to Import IGP Routes to BGP?
The import-route command cannot be used to import inactive routes and the default route.
To import the default route, the default-route imported command and import-route
command need to be configured in the BGP view.
7.6.4.30 Why Do Certain BGP Routes Fail to Be Imported When the import-route
Command Is Used to Import BGP Routes?
The import-route command is valid for only EBGP active routes when it is used to import
BGP routes to IGP. IBGP routes can be imported to IGP only when OSPF multi-instance is
configured.

7.6.4.31 Why Cannot the Community Attribute of a Route Be Displayed on the

Neighbor After the Route with the Community Attribute Is Advertised to the
Neighbor?
The peer advertise-community command needs to be configured to advertise the community
attribute.
7.6.4.32 How to Change the Next Hop of a Route?

On the route receiving side of the IBGP neighbor or EBGP multi-hop neighbor, you can
change the next hop through configuring the ingress policy; on the route sending side of the
IBGP neighbor, you can change the next hop to the IBGP neighbor itself by configuring the
peer next-hop-local command or change the next hop through configuring the egress policy.
7.6.4.33 Why Do Routes Listed in the BGP Routing Table Carry Out Load
Balancing Though Load Balancing Is Not Configured?
After load-balanced IGP routes are imported to BGP, these routes still carry out load
balancing.
7.6.4.34 Why Cannot Some Routes Be Dampened After dampening Is

Configured? How to Use BGP to Dampen Route Flapping?
The dampening command of BGP is valid for only EBGP routes. BGP can be used to
dampen route flapping in three ways: route aggregation, route dampening, and setting of the
minimum interval between route updates.
7.6.4.35 Why Is the MED Value of the OSPF Route Imported to the PE Not the
Cost Value of OSPF?
According to RFC 4577, the value of Multi_EXIT_DISC attribute (MED) is set to the cost
value of OSPF plus 1.
7.6.4.36 Why Is the Private Network Route Still in the Invalid State After the
Public Network Tunnel Is Established?
Q: After a bidirectional TE tunnel is established between two PEs, the learned VPN routes are
not included in the IP routing table of the VPN, and the detailed routing table information
shows that these routes are in invalid state. Why?
A: By default, during the iteration of private network routes, LSPs instead of CR-LSPs are
searched for. The TE tunnel is a CR-LSP. The tunnel policy needs to be configured to enable
the routes to be iterated to CR-LSPs. In the tunnel policy, you can configure the tunnels that
can be iterated and the configuration sequence of tunnel types, which determines the priority
of tunnel types during iteration.
7.6.4.37 Why Cannot the VPN Route Perform Tunnel Load Balancing?
By default, only one LSP is iterated during VPN route iteration. Although multiple equal-cost
LSPs exist, only one LSP is selected. To perform load balancing, you must configure the
tunnel policy in the system view, set the number of routes for load balancing in the policy, and
then apply the tunnel policy in the corresponding VPN instance view.

7.6.4.38 How to Check Whether EBGP Neighbor Flapping Is Caused by the

Excessive Long AS-Path Attribute?
There are three possible causes for neighbor flapping:
1. Improper processing during the forwarding of the route whose AS-Path attribute has
more than 255 AS numbers to the EBGP neighbor
2. Sending of a error packet to Huawei device by a device of another vendor due to the
failure to process the route with more than 255 AS numbers
3. Failure to parse the packet with more than 255 AS numbers by a device of another
vendor although Huawei device can properly process the route
The corresponding checking methods are as follows:
l Run the display bgp peer peer-ip-address log-info command to check whether neighbor
flapping is caused by 3/11 (3 indicates an Update packet error; 11 indicates an AS-Path
attribute error in the Update packet).
l Run the display bgp routing-table command to check whether the preferential routes
with no less than 255 AS numbers are available for the neighbor. These routes will be
forwarded to the neighbor.
The following examples describe the parsing of packets sent by Huawei device in scenarios
(1) and (3).
l Scenario 1: In an office, the logs on a device of another vendor that connects to Huawei
device show that an error packet sent by Huawei device is received.
%BGP-5-ADJCHANGE: neighbor 219.150.48.128 Down BGP Notification sent Feb 17
00:25:22 CCT: %BGP-3-NOTIFICATION: sent to neighbor 219.150.48.128 3/11
(invalid or corrupt AS path) 518 bytes 50020202 020044E6 10260CB9 71B9BAFC
BA3y39w: BGP: 219.150.48.128 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF
FFFF FFFF 022C 0200 0002 1140 0101 00
50 02 //AS-Path attribute (length: two bytes)
02 02 //Total length
02 00 //Two segments (the first segment is a sequence containing 0 AS
numbers, which is abnormal)
44 E610 260C B971 B9BA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
FC40 0304 DB96 3080
15 //21-bit mask
5E 7DD8 // 94.125.216.0
The AS-Path attribute with more than 255 AS numbers is not processed. Therefore, the
AS number count field (one byte) is 0, and an error packet is generated. In this case,
Huawei device is faulty.
l Scenario 3: In an office, the EBGP neighbor between Huawei device and a device of
another vendor flaps and then automatically recovers to the normal state. The logs on the

device of another vendor show that the device receives the Update packet from Huawei
device. The Update packet parsing result is as follows:
Feb 17 01:12:34.954 MNL: BGP: 120.28.27.1 Bad attributes FFFF FFFF FFFF FFFF
FFFF FFFF FFFF FFFF 0245 0200 0002 2A40 0101 00
50 02 //AS-Path attribute (length: two bytes)
02 06 //Total length: 518
02 02 //Two segments (the first segment is a sequence containing two AS
numbers)
24 58 //AS 9304
3C 34 //AS 15412
02 FF //The second segment is a sequence containing 255 AS numbers.
0B 6205 1371 B9BA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA
FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FCBA FC
40 0304 DABC 6895
4005 0400 0000 64
80 0904 781C 1B15
800A 0400 0000 02
In this example, only the AS-Path attribute of the packet is analyzed.

The packet carries more than 255 AS numbers. The cause of neighbor disconnection is
also that the AS-Path attribute of the route advertised by Huawei device to the device of
another vendor carries more than 255 AS numbers. According to the protocol, each AS-
Seq can store a maximum of 255 AS numbers. When the number of AS numbers exceeds
255, another AS-Seq should be used to store the additional AS numbers. However, the
peer device of another vendor deems it as a fault (which is allowed by the protocol) and
shuts down the neighbor. Therefore, 5/0 BGP error occurs on Huawei device, which
results in neighbor interruption. In this case, Huawei device is normal.
7.6.4.39 Why Is the Next Hop Address of a Route Imported by BGP from Another
Protocol to the BGP Routing Table 0.0.0.0?
Why is the next hop address of a route imported by BGP from another protocol to the BGP
routing table 0.0.0.0?
After BGP imports a route of another protocol, the next hop of the route becomes 0.0.0.0. The
route must exist on the local node because the route can be imported by BGP. That is, the
route is not a newly added one, and only the reference count of the route increases.
The route is not preferred by RM. Therefore, the next hop of the route does not matter. When
sending the route to its IBGP or EBGP peers, BGP changes the next hop of the route to a
proper one based on the rules defined in RFC 4271. Generally, it is recommended that the
next hop of the route should be changed to the local address used to set up a connection.
The processing of IPv6 routes is similar to that of IPv4 routes, and is not mentioned here.

7.6.4.40 What Are the Views Where the preference Command Can Be Run?
A router learns a VPNv4 route 1.1.1.1 from an MP-IBGP peer and then injects the VPNv4
route to the routing table of the VPN instance, and learns an OSPF route 1.1.1.1 from OSPF
multi-instance (CE). By default, the router selects the OSPF route. A customer, however,
requires that the router should select the route to be crossed to the VPN instance. How to
configure the router to select the VPNv4 route?
To configure the router to select the VPNv4 route, you need to set the value of local in the
preference { external internal local | route-policy route-policy-name } command to make the
preference value of the BGP route smaller than the preference value of the OSPF route so that
the BGP route is preferred.
The views where the preference command can be run include the BGP view, BGP-IPv4
unicast address family view, BGP-IPv6 unicast address view, BGP-VPN instance view, and
BGP-VPNv6 instance view.
The preference command cannot be used in the BGP-VPNv4 address family view, because
VPNv4 routes do not guide packet forwarding or take part in route selection. To change the
results of VPN route selection, run the preference command in the BGP-VPN instance view.
7.6.4.41 Why Is the Mask Length of a Route in the BGP Routing Table Not
Displayed?
Why is the mask length of a route in the BGP routing table not displayed?
<HUAWEI> display bgp routing-table
Total Number of Routes: 4
BGP Local router ID is 1.1.1.2

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
* 1.1.1.0/24 1.1.1.1 0 0 100?
* 1.1.1.2/32 1.1.1.1 0 0 100?
*> 5.1.1.0/24 1.1.1.1 0 0 100?
*> 100.1.1.0/24 1.1.1.1 0 0 100?
*> 100.36.0.0 132.33.42.56 0 0 100?
If the mask length of the route prefix is the same as the natural mask length, the mask length
of the route is not displayed in the routing table.
7.6.4.42 Why Cannot the Import Policy Be Used to Change the Preference of a
Route on a Peer?
Why cannot the import policy be used to change the preference of a route on a peer?
Currently, in the NE40E&NE80E, only the preference command can be used to change the
preference of a route, and the peer route-policy command cannot be used to change the
preference of a route on a peer.
7.6.4.43 After the default med 1 Command Is Run, Why Is the Cost of an IGP
Route Imported with the network Command Still Used as an MED Value?
After the default med command is run, why is the cost of an IGP route imported with the
network command still used as an MED value of a BGP route to be advertised?

The network command is used to import routes without changing the routes. Therefore, the
value set with the default med command is ignored. As a result, the cost of an imported IGP
route is used as the MED value of a BGP route to be advertised. The default med command
is still valid to other routes such as routes imported with the import-route command. To
change the MED value of a route, you can apply the route-policy when advertising routes
(although the configuration of this method is complex, the method is recommended because
the configuration file is clear).
7.6.4.44 What Is the Address Range of a BGP Peer?

What is the address range of a BGP peer?
The IPv4 address (x.x.x.x) range of a BGP peer is as follow:
l This first field cannot be 0 or 127. The address cannot be a multicast address that begins
with 224 or 225.
l The address cannot be a local address. For example, the address cannot be the address of
an interface on the device.
The IPv6 address (x:x::x) range of a BGP peer is as follow:
l The address cannot be ::, ::1, or a multicast address that begins with 0xff.
l The address cannot be a local address including a link-local address. For example, the
address cannot be the address of an interface on the device.
7.6.4.45 What Is the Full Name of MED?

What Is the Full Name of MED?
The full name of MED is MULTI_EXIT_DISC. An MED is an optional non-transitive
attribute. The format of an MED is an integer of four bytes. The MED attribute is exchanged
only between two neighboring ASs. The AS that receives the MED does not advertise it to
any other AS. The MED serves as the metric used by an IGP. It is used to determine the
optional route when traffic enters an AS. When a BGP router obtains multiple routes with the
same destination address but different next hops from EBGP peers, the route with the smallest
MED value is selected as the optional route when other conditions of the routes are the same.
For details about the MED, see RFC 4271.
7.6.4.46 Why Do Two Different VPN Instances on a PE Fail to Successfully Ping

Each Other?
There are two VPN instances, vpn1 and vpn2, on a PE. vpn1 is bound to an interface of CE1
and vpn2 is bound to an interface of CE2. vpn1 and vpn2 interact with each other. Why
cannot the two VPN Instances fail to ping each other with the ping -vpn-instance vpn1 -a
10.1.1.2 20.1.1.1 command?
Figure 7-16 Networking where the VPN instances on the PE fail to ping each other
10.1.1.1/24 20.1.1.1/24 vpn2

vpn1 10.1.1.2/24 20.1.1.2/24
CE1 PE CE2

The host route of the address of the interface to which the VPN instance is bound in the BGP-
VPN instance address family on the PE (the import-route direct command or the network
command can be used to import the host address of the interface address) so that the routing
table of the VPN instance has the host routes of interface address of other VPN instances after
VPN routes are locally crossed. If only the network segment route of the interface address is
imported, the reply packet is forwarded by the PE to CE1 after the ping -vpn-instance vpn1 -
a 10.1.1.2 20.1.1.1 command is run, because the PE can find the network segment route rather
than the host route of the interface address in the routing table of vpn1. As a result, the ping
operation fails. The CEs can still interwork normally, although the host route of the interface
address is not imported.
7.6.4.47 Why Are Routes Discarded After I Configure a Policy to Modify

Attributes of the Routes?
To set the local-preference of a VPNv4 route with the community attribute being 1000:1 on
plane 1 to 100 and set the local-preference of a VPNv4 route with the community attribute
being 1000:2 on plane 2 to 200, you need to configure the following policy:
ip community-filter 1 permit 1000:1
ip community-filter 2 permit 1000:2
route-policy planechoice permit node 10

if-match community-filter 1
apply local-preference 100
bgp 65000
ipv4-family vpnv4
policy vpn-target
peer 10.10.4.13 enable
peer 10.10.4.13 route-policy planechoice import
After the policy is configured, the VPNv4 routes that do not match the two if-match clauses
are discarded.
When configuring the policy, you must check whether a null node needs to be configured.
Otherwise, you intend to modify the attributes of routes if the routes meet certain conditions
and do not modify the attributes of the routes if the routes do not meet the conditions, but the
attributes of routes are modified if the routes meet the conditions and are denied if the routes
do not meet the conditions after the configuration. When the route-policy plane choice
permit node 30 command is run after the policy is modified, the routes that do not match the
two if-match clauses continue to be matched with the next node, and pass the policy on node
30.

7.6.4.48 When the peer next-hop-local Command Is Not Run on a Device, Why
Does the Device Change the Next Hop of the Route Received from an EBGP Peer
to the Address of Its Loopback Interface When Sending the Route to Its IBGP
Peer?
The two routers, Router A, and Router B, function as the egresses of the network. Router A
sends a received EBGP route to Router B. Why is the next hop of the route in the routing
table of Router B changed to the address of the loopback interface on Router A?
This problem is relevant to BGP load balancing.
l When load balancing is not configured, a device does not change the next hop of the
route received from an EBGP peer when sending the route to its IBGP peer.
l When load balancing is configured, traffic is load balanced after reaching the peer.
Therefore, the peer changes the next hop of the route to its address to import the traffic.
Check whether the maximum load-balancing command is run on Router A.
7.6.4.49 How to View the BGP Routes Before Filtering?

The BGP routes before filtering cannot be viewed, and only the routes after filtering can be
viewed.
7.6.4.50 What Are the Functions of the peer keep-all-routes Command?

The peer keep-all-routes command is used to save all BGP routing updates from a specified
peer after the BGP connection is set up. After this command is run, when modifying the
import policy, you can directly obtain the routes that do not match the import policy on the
local device, and do not need to configure the local device to request routes from its peer.
If a router does not support the Route-refresh capability, you need to run this command on the
local and remote routers.
7.6.4.51 Can the Next Hop of a BGP Route Be Redirected Through a Routing
Policy?
The next hop of a route learned from an IBGP peer or a multi-hop EBGP peer can be
redirected through a routing policy, whereas the next hop of a VPNv4 or a route learned from
a one-hop EBGP peer cannot be redirected through a routing policy.
Redirecting the next hop of a route through a routing policy can adjust traffic or improve
network security.
7.6.4.52 Why Is the BGP Down Cause Displayed as 6/6 When an Interface Goes
Down?
In normal situations, when the cause of the BGP Down event is displayed as 6/6, BGP
configurations are changed and a BGP connection needs to be set up again. When the EBGP
peers are directly connected, the fields 6/6 and Send Notification are displayed if an interface
goes Down.
<HUAWEI> display bgp vpnv4 vpn-instance NGN-SS peer 10.2.64.254 log-info
Peer : 10.2.64.254
Date Time State Error Notification
15-Jan-2010 01:53:14 Up

15-Jan-2010 01:46:18 Down 6/6 Send Notification

10-Dec-2009 00:07:37 Up
7.6.4.53 How to Process a 4-Byte AS Number?

NOTE
Before a route is advertised from a device that supports an AS number to a device that does not support
an AS number, the 4-byte AS path number in the form of X.Y must be converted into 23456 at the
advertising end.
l Q: After receiving a route carrying 4-byte AS_Path attribute, does a supporting device
discard the route or convert the AS_Path attribute into 23456 before sending the route to
other BGP peers?
A: The device converts the AS_Path attribute into 23456 and advertises the route to other
BGP peers.
l routerQ: Can such a route be sent to other BGP peers in other form or only in 23456?
A: This route cannot be sent in other form but only in 23456.
l routerQ: If two or more routes carrying 4-byte AS path attribute are received, convert the
AS number into 23456 at the receiving end on both routes or on only one route?
A: Convert the AS number on both routes.
l routerQ: If two or more routes carrying 4-byte AS path attribute are to be reflected to
other devices, convert the AS number into 23456 on both routes or on only one route?
A: Convert the AS number on both routes.
7.6.5 RM and TNLM
7.6.5.1 What Is the Meaning of Each Field in the display ip routing-table verbose
Command Output?
For example:
<HUAWEI> display ip routing-table 1.1.1.1 32 verbose
---------------------------------------------------------------
Summary Count : 1
State: Active Adv GotQ Age: 02h17m46s
Tag: 0 Priority: 0
RelayNextHop: 192.168.12.1 Interface: Ethernet0/2/0
TunnelID: 0x0 Flags: RD
BkNextHop: 24.24.24.241 BkInterface: GigabitEthernet6/0/2
l Routing Table: indicates the name of the instance, to which the route belongs. "Public"
indicates the public network instance.
l Summary Count: indicates the number of routes with the prefix specified in the
command.
l Destination: indicates the destination address of the route and the length of the mask.
l Protocol: indicates the name of the routing protocol.

l Process ID: indicates the process ID of the route.

l Preference: indicates the preference of the route protocol.
l Cost: indicates the route cost.
l NextHop: indicates the next hop of the route. It indicates the original next hop for routes
that require iteration.
l Neighbour: indicates the neighbour.
l State: indicates the state of the route. It has the following values:
– Active: indicates that the route is active.
– Invalid: indicates that the route is invalid.
– Inactive: indicates that the route is inactive.
– NoAdv: indicates that the route cannot be advertised.
– Adv: indicates that the route can be advertised.
– Del: indicates that the route is to be deleted.
– GotQ: indicates that the route is successfully iterated.
– WaitQ: indicates that the route has not been successfully iterated.
– Stale: indicates that the route has the Stale flag and is used in GR.
l Age: indicates the duration of the route after it is generated.
l Tag: indicates the route tag.
l Label: indicates the label allocated by MPLS.
l QosInfo: indicates QoS information.
l RelayNextHop: indicates the next hop address generated by the iteration of routes.
l Interface: indicates the outbound interface.
l TunnelID: indicates the tunnel ID.
l Flags: indicates the route flags, including:
– R: indicates that the route is iterated.
– D: indicates that the route is successfully delivered to the FIB.
l BkNextHop: indicates the backup next hop.
l BkInterface: indicates the backup outbound interface.
7.6.5.2 What Is the Meaning of "Flag" in the display fib Command Output?
At present, the "Flag" in the output of the display fib command includes the following flags:
l B: indicates the blackhole route, that is, the route whose outbound interface is NULL0.
l D: indicates the route generated by dynamic protocols such as IS-IS, OSPF, BGP, and
RIP.
l G: indicates the route to the gateway. The destination address of the route is a gateway.
l H: indicates the route to the host.
l L: indicates the route generated by ARP or ES-IS. It is commonly used in the VLAN-
ARP scenario.
l S: indicates the static route, which is configured with the ip route-static command or
generated through corresponding network management operations.
l C: indicates the non-32-bit direct route generated on the VLAN interface.

l F: indicates the route generated by static ARP.

l U: indicates that the route is reachable.
l V: indicates the route generated on the interface configured with target VRF.
7.6.5.3 What Is the Meaning of the order Parameter in the Configuration of the
Multicast Static Route?
l The result of the RPF search based on multicast static routes is related to the
configuration sequence of multicast static routes. For example:
ip rpf-route-static 1.1.1.1 255.255.255.255 bgp 2.2.2.2 preference 1
ip rpf-route-static 1.1.1.1 255.255.255.255 isis 3.3.3.3 preference 1
If the order is reverse to the preceding configuration:

The result may be totally different. The configured sequence directly affects the RPF
search result.
l Generally, the route configured earlier is placed in front of the route configured later in
the routing table. Such an ordinal relationship may inconvenience the configuration. For
example, you have configured
If you want to add the following configuration to the middle of the existing two
configurations:
ip rpf-route-static 1.1.1.1 255.255.255.255 ospf 4.4.4.4 preference 1
you must delete

and then run

because of the ordinal relation. It is very inconvenient. Therefore, the order parameter is
introduced.
The order parameter is used to set the order of the command to be configured in the
command set (based on the same address). Therefore, you can directly conduct the
following configuration instead of performing the operation of deletion and addition:
ip rpf-route-static 1.1.1.1 255.255.255.255 ospf 4.4.4.4 preference 1 order 2
In this manner, the preceding command is set to the second command after the
configuration.
l The order parameter features relativity and provisionality. It defines the relative location
relationship of all static configurations for the same RPF address. After the command is
executed and the order of the current configuration set is determined, order becomes
meaningless. The order parameter is not permanent. For example, the
command is the second, which does not mean that the command is always the second.
The order parameter defines the order of the command based on the entire configuration
set only when the command is executed. Therefore, the order parameter featuring
relativity and time-sensitive is only used to facilitate users' adjustment of configurations.
It does not indicate a permanent feature of the configuration.
l The order parameter is not displayed through the display this command because order
is specified by the sequence in which the commands are displayed.

7.6.5.4 Why Is the Number of Routes Listed in the Routing Table Inconsistent
with That Listed in the FIB After the Mechanism of Route Iteration as Required
Is Adopted?
After the mechanism of route iteration as required is adopted, no route is derived from the
route that is iterated to multiple outbound interfaces, which belong to only one route. When
the route is downloaded to the FIB, it is decomposed into multiple routes by outbound
interfaces. In this case, the situation of inconsistency between the number of routes listed in
the routing table and that listed in the FIB may occur.
In the Flags entry of a route, R indicates that the route is iterated, and D indicates that the
route is successfully downloaded to the FIB.
7.6.5.5 How Are Static Routes Prevented from Supernet Iteration?

Supernet iteration is implemented for a static route if the following conditions are met:
l The mask length of the next-hop IP address configured for the static route is less than or
equal to that of the route's destination IP address.
l The next-hop IP address and destination IP address belong to the same network segment.
For example, supernet iteration is implemented for the following static routes:
l ip route-static 5.5.5.5 (destination IP address) 24 (mask length) 5.5.6.6 (next hop IP
address) 16 (mask length)
l ip route-static 5.5.5.5 (destination IP address) 24 (mask length) 5.5.5.6 (next hop IP
address) (mask length less than or equal to 24)
After supernet iteration, static routes become invalid. To prevent supernet iteration, use either
of the following methods:
l Ensure that the next-hop IP address and destination IP address belong to different
network segments when configuring a static route. For example, you can configure as
follows: ip route-static 5.5.5.5 (destination IP address) 24 (mask length) 5.3.6.6 (next
hop IP address) 16 (mask length)
l Ensure that the next-hop IP address's network segment is less than the destination IP
address's network segment when configuring a static route. For example, you can
configure as follows: ip route-static 5.5.5.5 (destination IP address) 24 (mask length)
5.5.5.6 (next hop IP address) 32 (mask length)
7.6.5.6 Why Cannot the Backup Information of a Static Route or a BGP Route Be
Generated After IP FRR Is Configured?
IP FRR does not automatically take effect for iterated routes. Instead, an iterated route inherits
the backup outbound interface and backup next hop of the route to the next hop that are
generated through IP FRR. If the static route or BGP route is an iterated route and the IP FRR
backup information of the next hop route is not generated, the backup information cannot be
generated although the static route or BGP route matches the IP FRR policy.
7.6.5.7 Why Is the Prompt That the Route Is Modified Displayed When the Static
Multicast Routes Share the Same Source IP Address and Address Mask but
Differ in the Outbound Interface?
Example

[HUAWEI] ip rpf-route-static 1.1.1.1 32 Serial 0/0/1 preference 10

[HUAWEI] ip rpf-route-static 1.1.1.1 32 Serial 0/0/0 preference 20
Info: Route has been modified
If the configured static multicast routes share the same parameter values, a prompt that this
route already exists is displayed.
If the static routes to be configured differ in the source IP address, address mask, source VPN,
or unicast protocol, the routes are considered to be new ones.
If the routes share the same source IP address, address mask, source VPN, and unicast
protocol but differ in the matching policy, process, priority, or order, the following processing
rules are adopted.
l If the routes share the same source IP address and outbound interface, the route
modification prompt is displayed.
l If the routes share the same source IP address and next hop, the route modification
prompt is displayed.
l If the routes share the same source IP address, protocol, and matching policy but differ in
the outbound interface or next hop, the route modification prompt is displayed.
7.6.5.8 Can a Public Route Be Iterated to the Tunnel?

By default, a non-label route can be iterated to only the outbound interface and next hop and
cannot be iterated to the tunnel. After the following command is configured, a non-label route
of the public network can inherit the tunnel ID of IGP (or the static route). Therefore, MPLS
forwarding is implemented.
The route recursive-lookup tunnel command is used to enable the non-label route of the
public network to be iterated to the tunnel and is valid for only non-label routes of the public
network that require iteration. To implement precise control, you can specify an optional list
of IP address prefixes to filter the non-label routes that need to be iterated to the tunnel. You
can run the undo route recursive-lookup tunnel command to restore the default
configuration.
7.6.5.9 What Is the Logical Relationship Between the Nodes in a Route-Policy?

The route-policy is used to filter route information and set attributes for the routes that are not
filtered out. The filtering relationship among the nodes enabled with route-policy is "or".
That is, a route is permitted by the route policy if it passes the filtering at one node. Route
information that fails to pass the filtering at any node is not permitted by the route policy. The
relationship among if-match conditions is "and". That is, the apply statement can be executed
only when the filtering result is pass. Pay attention to the following special conditions:
l By default, the filtering result is pass when a policy is not configured with the policy
name.
l By default, the filtering result is pass if a policy is configured with the policy name but
not configured with if-match conditions.
Take the following typical cases for examples to explain filtering rules:
l Case 1:
route-policy aa permit node 1
if-match xx1
if-match yy1
apply zz1

if-match xx2
if-match yy2
apply zz2
If xx1 and yy1 are satisfied, zz1 is applied and pass is returned. Otherwise, check
whether xx2 and yy2 are satisfied. If xx2 and yy2 are satisfied, zz2 is applied and pass is
returned. Otherwise, deny is returned.
l Case 2:
route-policy aa deny node 1
if-match xx1
if-match yy1
apply zz1
if-match xx2
if-match yy2
apply zz2
If xx1 and yy1 are satisfied, zz1 is not applied and deny is returned. Otherwise, check
whether xx2 and yy2 are satisfied. If xx2 and yy2 are satisfied, zz2 is applied and pass is
returned. Otherwise, deny is returned.
l Case 3:
route-policy aa deny node 1
if-match xx1
if-match yy1
apply zz1
apply zz2
If xx1 and yy1 are satisfied, zz1 is not applied and deny is returned. Otherwise, zz2 is
applied and pass is returned.
7.6.5.10 Why Can Static Multicast Routes That Are Configured with Invalid
Route Policies Take Effect?
The route-policy parameter is specified when static multicast routes are configured. The
following two routes are found to coexist:
ip rpf-route-static 1.1.1.1 32 route-policy policy1 pos1/0/0
ip rpf-route-static 1.1.1.1 32 route-policy policy2 pos1/0/1
However, policy1 and policy2 are not configured in the system view in advance. Why can the
two routes take effect?
In fact, this matching policy does not make much sense and is usually used to identify
different routes. If the matching policy is not configured, one address can be configured with
only one route.
The system only determines whether the configuration of the route contains a matching policy
and does not care whether the policy actually exists.
7.6.5.11 What Is Wildcard "ip-prefix"?

In the ip ip-prefix command:
l If the IP address prefix is set to 0.0.0.0 mask, all routes whose mask length is mask are
matched.
l If the IP address prefix is set to 0.0.0.0 0 less-equal 32, all routes are matched.
l If ipv4-address mask-length is set to 0.0.0.0 0, only the default route is matched.
l You can use the ACL to match the routes with IP addresses ranging from 0.0.0.0/1 to
0.0.0.0/32.

7.6.5.12 Can IP FRR That Is Not Configured with the Backup Outbound Interface
Take Effect?
The backup outbound interface must be configured for the IP FRR policy. IP FRR that is
configured with only the backup next hop cannot take effect.
7.6.5.13 What Are Rules for the Election and Update of Router IDs?
The rules for the election and update of router IDs are as follows:
1. If the router ID is configured through the router id command, set the router ID
according to the configuration result.
2. If the router ID is not configured through the router id command and loopback
interfaces that are configured with IP addresses exist, set the router ID to the maximum
IP address among IP addresses of these loopback interfaces.
3. If the router ID is not configured through the router id command and no loopback
interface configured with the IP address exists, set the router ID to the maximum IP
address among IP addresses of other interfaces (irrespective of whether the interface is
UP or DOWN).
4. The process of reelecting the router ID can be triggered only when the IP address of the
interface that is set as the router ID is deleted or modified.
5. The change of the interface status does not result in the reelection of the router ID.
6. If the IP address of a loopback interface is configured after the router ID is set to the IP
address of a non-loopback interface, the router ID reelection does not occur.
7. If an interface IP address whose value is larger than the value of the router ID, the router
ID reelection does not occur.
8. If the boards work in active/standby mode, the router ID that is configured through the
router id command and the router ID that is elected from interface IP addresses should
be backed up.
9. The router ID may be set to a small interface IP address when the protocol wishes to
obtain the router ID during system startup, because the route management (RM) module
may have not obtained all information about interface IP addresses. This should not be
regarded as a problem.
10. After the router ID is changed, the reset command needs to be executed to specify a new
router ID for the protocol.
11. The router ID cannot be set to 0.0.0.0 or 255.255.255.255.
7.6.5.14 How to Select a Tunnel Among Multiple Tunnels Working in Load

Balancing Mode?
If the number of tunnels is set to 6 for load balancing, how to select six LSP tunnels from
eight ones during tunnel iteration?
If the selected tunnels enter the Down state, how to re-select tunnels?
If the selected tunnels go Up from the Down state, how to re-select tunnels?
The TNLM randomly selects six tunnels and then returns them to the RM.
If the status of the selected tunnels changes (for example, the first tunnel enters the Down
state), the TNLM randomly selects another tunnel from two candidate ones.

If the tunnels go Up from the Down state and there are less than six tunnels for load
balancing, the TNLM is triggered to re-select six tunnels and then returns them to the RM.
Otherwise, the status of tunnels does not affect load balancing.
7.6.5.15 What Are the Functions of the Tunnel Policy?

The functions of the tunnel policy are as follows:
l You can specify the number of tunnels carrying out load balancing when configuring a
tunnel policy.
l You can select the tunnels to be bound during the tunnel policy configuration.
l You can assign priorities for different types of tunnels during the tunnel policy
configuration. Then, tunnels can be selected based on the priority.
7.6.5.16 What Are Tunnel Selection Rules Configured Through the tunnel select-
seq Command and tunnel binding Command?
You can only run either the tunnel select-seq command or the tunnel binding command for a
tunnel policy. That is, the two commands cannot be used together.
l The tunnel select-seq command is used to set the priorities of tunnels that work in load
balancing mode. The closer the tunnel type is to the keyword select-seq, the higher the
priority is. In addition, only the tunnel types configured through the tunnel select-seq
command can be selected. If n tunnels are configured to work in load balancing mode
through the tunnel select-seq command, n available tunnels are selected in descending
order of the priority.
l The tunnel binding command can only be used to bind MPLS TE tunnels. If the given
destination IP address is directed to a TE tunnel through the tunnel binding command,
HUAWEI NetEngine40E/80E supports the down switch function of the TE tunnel
through configuration. That is, if the bound TE tunnel is down, other types of tunnels can
be selected in the sequence of LSP, CR-LSP, and GRE. In the same tunnel policy, you
can specify different destination IP addresses directed to the TE tunnels by using the
tunnel binding command.
Appendix: Tunnel Selection Principles Adopted by Tunnel Policies
l Configure a select-sequence tunnel policy.
Example:
#
tunnel-policy p1
tunnel select-seq cr-lsp lsp gre load-balance-number 6
#
The following bound CR-LSPs cannot be selected.

#
ip address unnumbered interface LoopBack0
destination 2.2.2.9
mpls te tunnel-id 2
mpls te reserved-for-binding
mpls te commit
#
l Configure tunnels by using the tunnel binding command.

Example

#
tunnel-policy p1
tunnel binding destination 2.2.2.9 te Tunnel5/0/0
#
The CR-LSPs of the non-binding type cannot be selected. If the down switch function is
enabled for the tunnels of the binding type and the CR-LSP tunnel of the binding type
goes Down, other types of tunnels can be selected in the sequence of LSP, CR-LSP, and
GRE.
7.6.5.17 Why Does the TE Tunnel to Be Bound Fail to Be Found After the tunnel
binding Command Is Configured?
You should check:
l Whether the value of the destination parameter in the tunnel binding command is
consistent with the destination address of the tunnel. If they are inconsistent, the tunnel
binding operation fails.
l Whether the MPLS TE tunnel to be bound is configured in advance and the mpls te
reserved-for-binding command is configured in the tunnel interface view.
7.6.5.18 How to Correctly Understand Load Balancing Carried Between 32

Routes?
A device establishes indirect neighbors with 32 other devices through loopback interfaces.
The iteration of 32 IGP routes is implemented on each loopback interface. Each neighbor
imports a route with the same prefix. If the load balancing mode is configured on this device,
can 1024 (32x32) next hops be iterated on this device and how many next hops are delivered
to the FIB?
The number of routes working in load balancing mode is specified in the load balancing PAF
entry of the RM. The number of routes working in load balancing mode delivered to the FIB
is determined by the load balancing PAF entries of both the RM and FIB. The number of PAF
entries of both the RM and FIB must be 32.
In view of the routing layer, 1024 next hops can be iterated. However, only a maximum of 32
next hops can be delivered to the FIB. Redundant next hops cannot be processed although
these active routes are successfully iterated.
7.6.5.19 Can the Outbound Interface Only Be the Point-to-Point Interface During
the Configuration of a Static Route for Multicast?
When a static route is configured for multicast, the following prompt is displayed. What is the
meaning of the prompt?
[HUAWEI] ip rpf-route-static 30.33.0.2 32 Eth-Trunk 0
Error: The next-hop IP address is required for multi-access media.
This prompt indicates that the next hop is not configured. That is, the interface is not a point-
to-point interface.
Other types of interfaces except the point-to-point interface cannot be specified as the RPF
interface of the static route for multicast. The reason is that the IP address of the next hop
cannot be specified if an RPF interface is used as a broadcast interface; when the multicast
performs the RPF check, the neighbor cannot match the IP address of the next hop.

However, other interfaces can be used for the static multicast route. For example, if the next
hop of the unicast rather than the outbound interface is configured, the outbound interface of
the unicast route is inherited.
In addition, when a static route is configured for multicast, the unicast can be unreachable but
links must be properly connected.
7.6.5.20 Does the Configuration of an Active Static Route Still Exist When the
Outbound Interface Status of the Static Route Goes Down?
If the outbound interface state of a static route goes Down, the static route will be deleted
from the IP routing table, but its configuration still exists.
7.6.5.21 What Do PAF Items in RM Represent?

What do the PAF items in RM represent?
The commonly used PAF items in RM are listed as follows:
l PAF_LCS_ROUT_RM_URT_SPECS_MAX_ROUTES_NUM: indicates the number of

unicast routes on the entire device.
l PAF_LCS_ROUT_RM_URT_SPECS_MAX_ROUTES_NUM_ALL_VRF: indicates the
total number of unicast routes in all VPN instances.
l PAF_LCS_ROUT_RM_URT_SPECS_MAX_ROUTES_NUM_PER_VRF: indicates the
number of unicast routes in a VPN instance.
l PAF_LCS_ROUT_RM_URT_SPECS_MAX_PREFIX_NUM: indicates the number of
unicast route prefixes on the entire device.
l PAF_LCS_ROUT_RM_USR_SPECS_MAX_ROUTES_NUM: indicates the number of
static routes.
l PAF_LCS_ROUT_RM_MSR_SPECS_MAX_ROUTES_NUM: indicates the number of
multicast static routes.
l PAF_LCS_ROUT_RM_SPECS_NUM_EQUICOSTRTS: indicates the number of IPv4
routes for load balancing.
l PAF_LCS_ROUT_RM_SPECS_MILLION_FIB_ENABLED: indicates whether the
million FIB feature is enabled.
l PAF_LCS_ROUT_RM_IM_SPECS_BROADCAST_FLAG: indicates whether subnet
route broadcasting is enabled.
7.6.6 Routing Policy
7.6.6.1 After the load-balance packet Command Is Run, the tracert Command
Output Shows that Packet-by-Packet Load Balancing Is Configured. Why Cannot
Packet-by-Packet Load Balancing Be Implemented for Traffic?
Currently, IP routing does not support packet-by-packet load balancing, and the load-balance
packet command is valid only for soft forwarding.

7.6.6.2 What Is UCMP?

Unequal-Cost Multiple Path (UCMP) allows traffic to be distributed among equal-cost paths
to a specified destination based on the bandwidths of paths. In this manner, all paths bear
different amounts of traffic based on their bandwidth to achieve proper load balancing.
You can run the load-balance unequal-cost enable command to enable UCMP on an
interface. This command can be used on physical interfaces only, and cannot be used on
logical interfaces. By default, UCMP is not enabled on an interface.
UCMP can be implemented among paths only after all outbound interfaces of equal-cost
routes on a device are enabled with UCMP and FIB entries re-delivery is triggered again. If
one of the outbound interfaces is not enabled with UCMP, UCMP is performed among paths,
even though FIB entry re-delivery is triggered.
UCMP applies to only equal-cost routes. It is independent of routing protocols. That is, it does
not concern whether the Interior Gateway Protocol (IGP) or the Border Gateway Protocol
(BGP) is used.
7.6.6.3 On an Ethernet, After an Interface Is Configured with an IP Address, the

Host Route and Network Segment Route Associated With the Interface IP
Address Are Generated. On a PPP Network, Why Is the Host Route Destined for
the Remote Interface Generated?
On a PPP network, the addresses of two directly interfaces can belong to different network
segments. If the host route destined for the remote interface is not generated, the two
interfaces cannot ping each other.
7.7 Multicast
7.7.1 How to Perform Load Balancing When the Outbound

Interface of Multicast Traffic Is an Eth-Trunk Interface or an IP-
Trunk Interface?
Multicast does not support load balancing among Eth-Trunk member interfaces. In one
multicast group, only one fixed member interface of the Trunk interface is chosen to send
multicast traffic. Different multicast groups may choose different member interfaces of a
Trunk interface to send multicast traffic.
7.7.2 Why Is the Multicast Source Register Message Still

Forwarded After the register-policy Command Is Configured on
the RP to Discard the Register Message?
This command should be configured in proper time. If the RPT has been switched to be the
SPT when the register-policy command is being configured, packet forwarding is only based
on the SPT. After the register-policy command is configured, the multicast source register
message is filtered out and the RPT entry is aged. The SPT entry, however, still exists.
Therefore, packets can still be forwarded.

7.7.3 Which Inter-AS Modes Are Supported by Multicast VPNs?

Option A and Option C are supported.
7.7.4 How to Enable an RP Router to Filter the Received Multicast

Data Packets Based on the Source Address or Source/Group
Address?
The configurations are as follows:
[HUAWEI] acl number 2001
[HUAWEI-acl-basic-2001] rule permit source 10.10.1.2 0
[HUAWEI-acl-basic-2001] rule deny source 10.10.1.1 0
[HUAWEI-acl-basic-2001] quit
[HUAWEI] pim
[HUAWEI] source-policy 2001
You can run the source-policy command to enable a router to filter the received multicast data
packets based on the source address or source/group address.
l If source-policy is configured and a basic ACL is defined, the router matches the source
addresses of all the received multicast data packets with the ACL. The packets denied by
the ACL are discarded.
l If source-policy is configured and an advanced ACL is defined, the router matches both
the source addresses and group addresses of all the received multicast data packets with
the ACL. The packets denied by the ACL are discarded.
This command is used to filter the multicast data, including the multicast data encapsulated in
Register messages.
7.7.5 What Are the Functions of PIM Silent on a PIM Interface?

On the access layer, if the interface directly connected to a host is enabled with the PIM
protocol, PIM neighbors can be established on this interface to process various PIM protocol
packets. Such configuration, however, may bring security problems. For example, when
malicious hosts send a large number of pseudo PIM Hello packets, it may lead to the collapse
of the device.
To avoid the preceding problem, you can run the pim silent command on the interface to set
the interface to work in PIM silent state. After the interface enters the PIM silent state, it is
forbidden to receive or forward any PIM protocol packet. All PIM neighbors and the PIM
state machine on this interface are deleted and the interface automatically becomes a DR.
Meanwhile, the PIM silent function does not affect the IGMP function on the interface.
The PIM silent function is applicable only to the interface that is directly connected to the
network segment of user hosts, and only one PIM device can be connected to this network
segment.
7.7.6 When a Host Leaves a Group, How Does an IGMP Querier

Judge Whether Any Other Members of the Group Exist on the
Network Segment?
In IGMPv1, when a host leaves a multicast group, the host does not send any message. A
device considers that all multicast members have left a group when the timer of the group
expires.

In IGMPv2 and IGMPv3, a host sends a Leave message when leaving a group. After
receiving the Leave message, the querier sends a group-specific or source/group-specific
Query message to the network segment of the host. The destination address of the Query
message is the address of the multicast group and the group address in the message is also
filled in with the address of the multicast group.
l If other members of the group exist on the network segment, they respond with Report
messages.
l If no response is received when the timeout period ends, the querier considers that no
member of the group exists on the network segment and cancels forwarding multicast
data to the group.
7.7.7 Can the Hosts and Devices on the Same User Network
Segment Run Different Versions of IGMP?
IGMP has three versions, namely IGMPv1, IGMPv2, and IGMPv3. Different IGMP versions
run on devices and hosts are compatible, but all the devices on the same network segment
must run IGMP of the same version. If the versions of IGMP run on the devices on the same
network segment are different, IGMP member relationships are chaotic.
Run the display igmp interface interface-type interface-number command on all the devices
on the same network segment to check the versions of IGMP run on the devices. If the
versions are not the same, modify the configuration.
7.7.8 What Are Functions of an RPF Check in MSDP and What Is

the Process of an RPF Check?
After MSDP receives an SA message, it forwards the message to all its peers. To prevent SA
messages from being circularly forwarded between MSDP peers, MSDP performs RPF check
on the received SA message. MSDP strictly controls the inbound of the SA message. It
directly discards the SA message that does not comply with the RPF rules.
MSDP has the following RPF rules:
l If the peer that sends the SA message is the source's RP (the RP that constructs the SA
message), the SA message is accepted and forwarded to other peers.
l The SA message sent by a static RPF peer is accepted. A device can set up MSDP peer
relationship with multiple devices at the same time. Users can select one or multiple
peers from these remote peers and set it (or them) as a static RPF peer (or RPF peers).
l If a device has only one remote MSDP peer, the remote peer automatically becomes the
RPF peer. The device accepts the SA message sent by this remote peer. The PIM-SM
domain that has only one remote MSDP peer outside the PIM-SM domain is called a
Stub domain.
l If the peer that sends the SA message and the local device belong to the same mesh
group, the local device accepts the SA message. The SA message from the mesh group is
not forwarded to the members of the mesh group but to all peers that do not belong to the
mesh group.
l If the peer that sends the SA message is the next-hop "route" to the source's RP, the SA
message is accepted and forwarded to other peers. The "route" includes the MBGP route,
multicast static route, and unicast route (BGP or IGP).
l If the route that reaches the source's RP spans multiple ASs, the SA message sent by the
peer of the next-hop AS is accepted. If the next-hop AS has multiple remote MSDP
peers, the SA message sent by the remote peer with the highest IP address is accepted.

7.7.9 How Do Unicast Packets (Such as Register Packets and Graft

Packets) of a Multicast Routing Protocol Pass an Mtunnel
Interface Since an Mtunnel Interface Does Not Advertise Its
Routes?
All unicast packets are not transmitted over the Mtunnel. Instead, they are transmitted over an
MPLS public network tunnel set up between VPNs. Only the multicast data and the protocol
packets with the destination address being multicast address are transmitted by the Mtunnel
interfaces. Therefore, unicast packet transmission is not affected though the Mtunnel
interfaces do not advertise their routes.
7.7.10 Why Does the Downstream Interface Used by the Source'S

DR to Send Register Messages Remain in the Register State?
After a multicast network is well deployed, the multicast source sends multicast data. The
multicast entries on the source's DR always have a registered downstream interface.
The direct cause is that the source's DR receives no Register-Stop message. This may be
resulted from abnormal unicast routing.
Do as follows to find the causes:
1. Check that the unicast route between the source's DR and the RP is correct and the
source's DR and the RP can ping each other successfully.
– If no unicast route exists between the source's DR and the RP or the source's DR
and the RP cannot ping through each other, the RP cannot receive Register
messages and hence will not send Register-Stop messages.
– If no unicast route exists between the source's DR and the RP or the source's DR
and the RP cannot ping through each other, the Register-Stop messages sent from
the RP to the source's DR may be lost.
2. If the source's DR and the RP can ping each other successfully, further check whether an
SPT is set up from the RP to the source's DR and ensure the RP can complete SPT
switchover. This requires that all related interfaces are configured with the same PIM
protocol. If the RP has not completed SPT switchover, no Register-Stop message is sent.
3. Check whether the RP creates an (S, G) entry and sends a Register-Stop message. If
necessary, run the debugging pim register and debugging mfib register commands to
enable the debugging of the PIM and MFIB modules and view whether a Register or
Register-Stop message is received and processed. Run the display pim routing-table
source-address command to check whether the corresponding (S, G) entry is created.
7.7.11 On Which Interfaces Need PIM Be Enabled In a PIM

Domain?
In multicast network deployment, if PIM is not enabled on some necessary interfaces, the
multicast function becomes abnormal. Then, on some interfaces need PIM be enabled.
A device must perform the RPF check before creating multicast forwarding entries: The
device searches the unicast routing table for an optimal route to the object of the RPF check.
The outbound interface of the optimal route acts as an RPF interface and the next-hop
interface of the optimal route acts as an RPF neighbor. The PIM protocol requires that
multicast forwarding entries be created only after PIM is enabled on both the RPF interfaces

and the RPF neighbor. Therefore, a complete multicast distribution tree can be set up along
the forwarding path of the packet.
Generally, the object of the RPF check is the multicast source. In PIM-SM, the objects of the
RPF check can be the multicast source, RP, and BSR. The RPF interface and the RPF
neighbor completely depend on unicast routes and are independent of the PIM protocol. To
ensure that PIM can be enabled on all the RPF interfaces and RPF neighbors, you are
recommended to enable PIM on all non-boundary interfaces in the PIM domain.
The following interfaces may be ignored:
l Interface directly connected to the multicast source: The RPF interface is the interface
directly connected to the multicast source when the device directly connected to the
multicast source performs the RPF check with the object being the multicast source.
l Interface directly connected to the user host:
– If IGMPv1 is run on an interface, you must enable PIM. This is because IGMPv1
does not the querier election. In IGMPv1, the querier is specified by PIM.
– If IGMPv2/v3 is run on an interface, PIM is recommended. Although IGMPv2/v3
supports the querier election, enabling PIM improves the system stability.
l Interface that functions as a C-BSR or C-RP in PIM-SM
7.7.12 Can PIM-DM and PIM-SM Run Simultaneously in a PIM

Domain?
No. If the PIM protocols configured on the RPF interface and the RPF neighbor are
inconsistent, multicast forwarding entries cannot be created correctly.
Since PIM Hello packets do not carry PIM protocol information, the PIM device cannot know
which PIM protocol is run on its PIM neighbor. If the PIM protocols configured on the RPF
interface and the RPF neighbor are inconsistent, two neighboring devices cannot learn PIM
routing information from each other. As a result, related multicast forwarding entries cannot
be created correctly.
Therefore, in multicast network deployment, you are recommended to configure the same
PIM protocol (either PIM-SM or PIM-DM) on all non-boundary interfaces in the PIM
domain.
7.7.13 Why Must We Ensure that Unicast Routes Are Reachable

Before Configuring Multicast Services?
Multicast devices do not maintain unicast routing information independently on the network.
Before creating PIM routing entries, the multicast devices must perform the RPF check
according to the existing unicast routing information on the network. If there is no unicast
route to a specific destination, the RPF check fails.
The existence of the unicast route to the multicast source is a prerequisite for SPT
establishment regardless of which PIM protocol is configured.
In a PIM-SM network, the existence of the unicast route to the RP is a prerequisite for source
registration and RPT establishment.
If the BSR is used in a PIM-SM network, the existence of the unicast route to the BSR is a
prerequisite for RP information obtaining.

7.7.14 How to Perform the RPF Check for Establishing an RPT in

a PIM-SM Domain?
A receiver's DR first performs the RPF check: It searches for a unicast route to the RP. The
outbound interface of the searched route acts as an upstream interface and the next hop of the
searched route acts as an RPF neighbor. Then, the receiver's DR sends a Join message to the
RPF neighbor. After receiving the Join message, the previous-hop device performs the RPF
check and forwards the Join message upstream at the same time. The Join message is sent
upstream hop by hop until it reaches the RP.
In the preceding process, if there is one device that has no route to the RP, the RPT cannot be
established.
7.7.15 Why Is the Forwarding of the Multicast Data Packet

Interrupted After the Multicast Data Reaches the Intermediate
Device Through the MDT?
The following describes the possible causes resulting from the protocol layer:
The TTL value of the multicast data packet from the multicast source is too small or the
multicast minimum-ttl configured on some device along the forwarding path is improper.
After receiving the multicast data packet, the device subtracts the TTL value in the packet
header by 1 and recalculates the checksum. If the TTL value is 0 after subtraction, the device
discards the packet; if the TTL value is not 0, the device forwards the packet to all the
corresponding downstream interfaces based on forwarding entries. If the multicast
minimum-ttl command is configured on the downstream interface, the packet is forwarded
only when the TTL value in the packet header is greater than or equal to the configured
minimum-ttl value. Otherwise, the packet is discarded.
To rectify the fault, follow the steps described below:
1. Run the debugging ip packet command to view the TTL value of the multicast data
packet forwarded by the local device. If the command output shows that the TTL value
of the multicast data packet from the multicast source is too small, you need to adjust it
to a larger value.
2. Run the display multicast minimum-ttl command to view the minimum-ttl configured
on the downstream interface. If the command output shows that the configured
minimum-ttl is improper, adjust the minimum-ttl to a smaller value or remove the
configuration about the minimum-ttl.
7.7.16 Why Is Multicast Forwarding Prone to Be Interrupted on a

Device Where Preferential Use of the Static RP Is Enabled?
The possible cause is that a static RP cannot respond to the change of the dynamic RP. When
the dynamic RP changes, the RP information on the device where preferential use of the static
RP is enabled is different from that on other devices.
For example, on a PIM-SM network, C-RP-A and C-RP-B are configured to serve all
multicast groups. C-RP-A has a higher priority and hence is elected as the RP. Then, add C
device to the network, configure preferential use of the static RP on C device, and set the
address of C-RP-A as the static RP address; however, in some cases, for example, the RP
interface turns Down, C-RP-A can no longer function as the dynamic RP and C-RP-B takes

over as a dynamic RP. As a result, RP information on C device is inconsistent with that on

other network devices, which leads to multicast forwarding failures.
Solution:
l Synchronize the configurations about the static RP on C device in time to ensure that the
configurations are consistent with those of the currently functioning dynamic RP.
l Remove the configuration about preferential use of the static RP on C device to ensure
that RP configurations on all devices of the network are consistent.
7.7.17 Why Is Multicast Forwarding on a Normal Interface

Interrupted After Hello Messages Are Sent to This Interface?
After PIM is enabled and a static multicast group is configured, the device creates a
forwarding entry with the downstream interface specified; however, after a PIM Hello
message is sent to this interface, the downstream interface of the forwarding entry is deleted.
The source address filled in the PIM Hello message is higher than the address of the interface
functioning as the DR, or the value of the DR priority field of the PIM Hello message is larger
than the value of the interface functioning as the DR. As a result, the interface can no longer
function as the DR after receiving the PIM Hello message. In case that Assert election is not
performed, the DR on the shared network segment is responsible for forwarding multicast
packets. Therefore, the device considers that the new DR is to be used for multicast
forwarding and then prunes the downstream interface.
7.7.18 Why Cannot an MDT Be Set Up Correctly If PIM Is Not

Enabled on an RPF Interface?
The PIM protocol does not maintain its own unicast routing table. Instead, it uses the existing
unicast routing table as a basis for the RPF check. Generally, the object of the RPF check is
the multicast source. On a PIM-SM network, the objects of the RPF check can be the
multicast source, RP, and BSR. For an object, the PIM device searches the existing unicast
routing table for an optimal route to the object. The outbound interface of the route acts as an
RPF interface. You can see that the RPF interface completely depends on the existing unicast
route and is independent of the PIM protocol. The PIM protocol, however, requires that the
RPF interface be enabled with PIM. This requirement must be guaranteed through network
design. If the RPF interface is not enabled with PIM, the MDT cannot be correctly set up and
hence multicast forwarding fails.
Solution: Enable the PIM protocol on the RPF interface.
7.7.19 Why Cannot an MDT Be Set Up Correctly If the RPF

Neighbor Is Not a PIM Neighbor?
The PIM protocol does not maintain its own unicast routing table. Instead, it uses the existing
unicast routing table as a basis for the RPF check. Generally, the object of the RPF check is
the multicast source. On a PIM-SM network, the objects of the RPF check can be the
multicast source, RP, and BSR. For the object of an RPF check, the PIM device searches the
existing unicast routing table for an optimal route to the object. The outbound interface of the
route acts as an RPF interface and the next-hop device acts as an RPF neighbor. If there are
multiple next-hop addresses, the hop with the highest IP address acts as the RPF neighbor.
You can view that the RPF neighbor completely depends on the existing unicast route and is
independent of the PIM protocol.

The PIM protocol, however, requires that the RPF neighbor be a PIM neighbor. This
requirement can be guaranteed through network design. PIM protocol does not select an RPF
neighbor from non-PIM neighbors because PIM protocol does not maintain the unicast
routing information independently. If the corresponding interface of the device where the RPF
neighbor resides is not enabled with PIM, the MDT cannot be correctly set up and hence
multicast forwarding fails.
Solution: Enable the PIM protocol on the corresponding interface where the RPF neighbor
resides.
7.7.20 Why Cannot an MDT Be Set Up Correctly If There Is No

Unicast Route to the Multicast Source?
When PIM-DM is run on the entire network, multicast data is flooded from the first-hop
device directly connected to the multicast source to the last-hop device directly connected to
the user host along the MDT. Regardless of which device the multicast data is flooded to, the
(S, G) entry is created only on the device that has a route to the multicast source. Conversely,
if a device does not have a route to the multicast source or its RPF interface is not enabled
with PIM-DM, it cannot create an (S, G) entry.
When PIM-SM is run on the entire network and devices prepare to join the SPT to the
multicast source, the (S, G) entry is created only on the device that has a route to the multicast
source. Conversely, if no route to the multicast source exists or the RPF interface to the
multicast source is not enabled with PIM-SM, the (S, G) entry cannot be created.
The existence of the unicast route to the multicast source is a prerequisite for the creation of
PIM routing entries regardless of which PIM protocol is configured. Multicast forwarding
succeeds only when unicast routes are reachable.
Solution: Check configurations about unicast routes or configure a static multicast route to
ensure that the unicast route to the multicast source exists.
7.7.21 Why Cannot an RPT Be Set Up Correctly If Static RP

Configurations on the Devices over the Entire Network Are
Inconsistent?
If static RP configurations on the devices over the entire network are inconsistent, the RPT
cannot be correctly set up or the RP cannot join the SPT to the multicast source.
An RP is the core of the PIM-SM network. It serves specified multicast groups. Multiple RPs
can exist on the network simultaneously. You can specify an RP to serve only certain groups.
You need to ensure that the RP information of all the devices for a specified group is
consistent on the network. Otherwise, the multicast function cannot work normally.
If you use the static RP mechanism, you need to ensure that static RP configurations on all the
devices (including the static RP itself) are consistent over the network.
Solution: Configure the static RPs in the same way on all the devices over the network,
including the static RP address and ACL rule.
7.7.22 How Does IGMP Elect a Querier from Multiple Devices on

a Shared Network Segment?
When a host network segment is connected to the interfaces on multiple devices, to avoid data
conflict, only one device interface is allowed to send Query messages. This interface acts as

the querier. The other device interfaces that run IGMP can listen to the IGMP messages on the
network segment.
In IGMPv1, querier selection depends on the multicast routing protocol, such as PIM. In
IGMPv2 and IGMPv3, the device interface with the lowest IP address acts as the querier on
the network segment.
7.7.23 What Are Differences Between the Querier and the PIM DR
and Who Is Responsible for Forwarding Multicast Data?
A PIM DR is responsible for processing host joins on the local network segment and
receiving multicast data from other devices, such as the RP and source's DR. It is also
responsible for forwarding the multicast data received from the multicast source on the local
network segment. A querier is responsible for exchanging messages with user hosts so that all
the devices on the local network segment can learn consistent information about relationships
between hosts and multicast groups.
The functions of the PIM DR and querier do not conflict or overlap. Therefore, one device
can function as both the PIM DR and the querier or two devices function as the PIM DR and
the querier separately. In terms of load sharing, by default, the device with the higher IP
address functions as the PIM DR and the device with the lower IP address functions as the
querier. If only IGMP is configured on the network segment where the receiver resides, the
IGMP querier is responsible for forwarding multicast data; if PIM is also configured,
commonly, the DR is responsible for forwarding multicast data; if Assert election is
performed, the Assert Winner is responsible for forwarding multicast data.
7.7.24 What Are Requirements for Configuring IGMP Parameters

on Each Interface of the Devices on a Shared Network Segment?
When you configure IGMP parameters on interfaces in the scenario where a user network
segment is connected to multiple devices, note that:
You must ensure that IGMP parameters configured on the interfaces of the devices on a
shared network segment are consistent.
IGMP parameters on interfaces are mutually affected and restricted. If IGMP parameters
configured on the interfaces of the devices on a shared network segment are inconsistent, the
IGMP member relationships are chaotic.
Checking method: Run the display igmp interface interface-type interface-number verbose
command on all the devices on the shared network segment to check IGMP parameters. If the
IGMP parameter configurations are inconsistent, modify the configurations. The following
list IGMP parameters:
l IGMP version
l Robustness
l Query interval
l Other querier timeout
l Maximum query response time
l Last member query count
l Last member query interval
l Startup query interval

l Startup query count
7.7.25 Why Are not (S, G) Entries Generated After SSM Mapping
Is Enabled?
The interface is enabled with SSM mapping and IGMP, and is configured with a static SSM
mapping policy. After the interface receives IGMPv1 or IGMPv2 Report messages, (S, G)
entry does not exist in the MFIB table.
When a querier enabled with SSM mapping receives an IGMPv1 or IGMPv2 (*, G) Report
message, the querier checks the group address G. When G is in the SSM group address range
and the host is configured with G-related SSM mapping rules, the device transforms the (*,
G) to (G, Include, (S1, S2, S3...)) entry. SSM mapping is thus implemented.
G in the (*, G) Report message is not in the SSM group address range. Run the display this
command in the PIM view to check the current configuration. If the command output displays
the ssm-policy basic-acl-number or the ssm-policy acl-name acl-name command, it indicates
that the SSM group address range is redefined on the device.
Run the display acl command to check the ACL configuration. Ensure that G is in the SSM
group address range. By default, the SSM group address range is 232.0.0.0/8.
The ssm-policy rule related to G in the (*, G) Report message are not configured. Run the
display igmp ssm-mapping interface-type interface-number command to check the SSM
mapping rules configured on the current device and to check whether the source address of G
is specified. Note that the address of the group enabled with SSM mapping must be within the
SSM group address range.
7.7.26 Can a Device Process the Report Messages Delivered After

the Maximum Response Time Expires?
The maximum response time of IGMP Query messages is used to control a host to send a
Report message within the certain period. As long as the host sends a Report message within
the maximum response time, the multicast routing entries required by the host are not aged
and data forwarding is not interrupted.
The maximum response time configured on a device requires a host to send a Report message
within a certain period. This is because entries on the device will time out and be aged. The
initial timeout period is calculated as: Interval for sending general Query messages x IGMP
robustness variable + Maximum response time. Zero-Packet-Loss cannot be guaranteed on the
network and thus the network allows (IGMP robustness variable -1) times of packet loss as
long as the host receives the last Query message and sends a Report message within the
maximum response time. Then, the multicast routing entries required by the host are not aged
and data forwarding is not interrupted.
If the host receives the Query message but sends a Report message after the maximum
response time expires, and if the host is the only receiver of the group, data forwarding is
interrupted though the device receives the Report message. This is because the IGMP entries
on the device are already aged and deleted before the device receives the Report message.
Data forwarding interruption can be avoided if the host sends a Report message within the
maximum response time. The device, however, can process the Report message to create a
new entry for data forwarding.

IGMP Report messages can be processed as long as the responser interfaces are configured
with IGMP. IGMP Report message processing is irrespective of the maximum response time.
7.7.27 Why Does the SA Filtering Policy Configured on the MSDP

Peer Originating SA Messages Fail to Take Effect?
The reason why the configuration about the peer peer-address sa-policy export [ acl
{ advanced-acl-number | acl-name } ] command cannot take effect to filter the sent SA
messages is:
In the MSDP view, the import-source [ acl { acl-number | acl-name } ] command is used to
create a filtering policy applied in sending local source information to other peers whereas the
peer peer-address sa-policy { export | import } [ acl { advanced-acl-number | acl-name } ]
is used to set a filtering policy applied in receiving and sending SA messages.
Therefore, on the RP creating SA messages, if you run the peer peer-address sa-policy
export [ acl { advanced-acl-number | acl-name } ] command to filter the sent SA messages,
the command does not take effect. Instead, you need to run the import-source [ acl { acl-
number | acl-name } ] command.
7.7.28 Why Cannot (S, G) Information Be Exchanged Though

Anycast RP Is Configured?
Though anycast RP is deployed on the network, RPs cannot exchange (S, G) information after
the multicast source sends multicast data.
Solution: In the application of anycast RP, the originating-rp command must be configured.
Commonly, the interface address specified in the originating-rp command is the same as the
address used to establish the MSDP peer relationship.
1. The networking where MSDP peer relationships are set up between PIM-SM RPs to
implement RP load sharing is a common MSDP networking. The configuration of
Anycast RP requires that the RPs with the same addresses be configured in the multicast
domain and an MSDP peer relationship be set up between the interfaces configured as
RPs.
NOTE
The MSDP peer address cannot be identical with the RP address; otherwise, a TCP connection
fails to be set up between MSDP peers.
2. Run the originating-rp command on the interfaces setting up MSDP peer relationships.
MSDP then replaces the RP address carried in the SA message to be sent with the
interface address specified in the originating-rp command. Otherwise, when the MSDP
peer performs the RPF check on the received SA message but finds that the RP address
is identical with the locally configured RP address, the MSDP peer rejects the SA
message.
7.7.29 Why Does the State of the MSDP Peer Keep Down Though
the MSDP Peer Relationship Is Set Up?
You can run the peer peer-address connect-interface interface-type interface-number
command on two ends to set up an MSDP peer relationship. The address of the interface
specified by interface-type interface-number in the locally configured peer connect-interface
command must be consistent with peer-address specified in the peer connect-interface
command run on the remote end.

Solution: Change the peer-address specified in the peer connect-interface command run on
the remote end to be consistent with the address of the interface specified by interface-type
interface-number in the locally configured peer connect-interface command.
7.7.30 Why Cannot the router Learn Entries of Group Members

After Layer 2 Multicast Is Correctly Configured and All Interfaces
Are Up?
Run the display l2-multicast limit command to check whether multicast CAC is successfully
configured on the router and whether the number of entries on the router reaches the upper
limit. For example:
<HUAWEI> display l2-multicast limit
L2-multicast limit information, The unit of bandwidth is kbits/sec
------------------------------------------------------------------------------
ConfigEntries ConfigBandwidth
CurrentEntries CurrentBandwidth
------------------------------------------------------------------------------
Global limit information:
------------------------------------------------------------------------------
100 ----------
14 ----------
Global channel limit information:
------------------------------------------------------------------------------
ch1 100 ----------
0 ----------
interface GigabitEthernet3/0/0 limit information:
------------------------------------------------------------------------------
100 ----------
0 ----------
interface GigabitEthernet3/0/0 channel limit information:
------------------------------------------------------------------------------
The preceding example shows that multicast CAC has been configured on the router and the
number of current entries has not exceeded the upper limit.
Then, run the display current-configuration command or run the display this command in
the channel view to check whether unspecified-channel deny is configured for the channel
on the router. The unspecified-channel deny command is used to define the mode in which
multicast groups in a channel are processed. If this command is configured, check whether the
multicast group addresses are within the range allowed by the channel that the multicast
groups want to join. For example:
[HUAWEI] l2-multicast-channel
[HUAWEI-l2-channel] display this
#
l2-multicast-channel
channel cctv type asm
unspecified-channel deny
#
return
The preceding display in bold indicates that the mode in which multicast groups in a channel
are processed is successfully configured. When the router receives a Join message for a
multicast group that is beyond the range allowed by the channel, the router discards the Join
message and does not create any forwarding entry for this group.

7.7.31 What Are Characteristics of PIM-DM, PIM-SM, and PIM-

SSM and Which Type of Network Is Each Mode Applicable to?
l PIM-DM is short for Protocol Independent Multicast Dense Mode. In this mode, the
flood-prune mode is used to forward multicast data. PIM-DM is applicable to the small
LAN in which group members densely reside. Rendezvous Points (RPs) and Designated
Routers (DRs) are not involved in PIM-DM. Through the periodical flooding-pruning,
PIM-DM creates and maintains a unidirectional and loop-free SPT connecting the
multicast source and group members.
l PIM-SM is short for Protocol Independent Multicast Sparse Mode. In this mode, an
MDT is set up when receivers actively join a multicast group. PIM-SM is applicable to
the network on which group members sparsely reside. RP maintenance, RPT
construction, and multicast source registration are involved in PIM-SM.
l PIM-SSM is similar to PIM-SM but maintaining RPs, constructing RPTs, and registering
multicast sources are not required. In PIM-SSM, an SPT can be directly set up between a
multicast source and group members as long as the source is routable. Therefore, PIM-
SSM has a distinct advantage in inter-AS multicast data forwarding.
7.7.32 Does a Device Preferentially Select the Route with the

Highest Precedence Rather Than the Route with the Longest
Matched Mask?
l If the longest match policy is not configured for route selection, a device selects an
optimal route based on route precedences in RPF selection.
l If the longest match policy is configured for route selection, a device selects a route with
the longest matched mask in RPF selection. If the masks of routes are in the same length,
the device selects an optimal route based on route precedences.
A device selects an optimal route respectively from the multicast static routing table, MBGP
routing table, MIGP routing table, and unicast routing table, and then selects one route from
the four routes as the RPF route. Route selection rules are as follows:
l If the longest match policy is configured for route selection:
– A route with the longest matched mask is selected from the four routes.
– If the masks of four routes are in the same length, the route with the highest
preference is selected.
– If the preferences of the four routes are the same, a route is selected in the order of
multicast static route, MBGP route, MIGP route, and unicast route.
l If the longest match policy is not configured for route selection:
– The route with the highest preference is selected.
– If the preferences of the four routes are the same, a route is selected in the order of
multicast static route, MBGP route, MIGP route, and unicast route.
7.7.33 Does an Outbound Interface Functioning as a DR Stop

Forwarding Multicast Data Immediately If It Changes to Be a
Non-DR Because of Changed DR Priority After a PIM DR
Switching Delay Is Set?
Using the pim timer dr-switch-delay command, you can enable the PIM DR switching delay
function and set a switching delay on an interface. After a new PIM neighbor joins, the

outbound interface may not function as a DR any more; however, within the switching delay
or before the new DR takes effect to forward multicast traffic, the original outbound interface
still has the DR function and continues to forward multicast data. In this manner, non-stop
multicast traffic forwarding is ensured during DR switchover.
The preceding configuration is applicable only in the case where a new PIM neighbor joins
and thus the outbound interface changes from a DR to a non-DR; however, if DR switchover
is triggered by manually changing the DR priority but no new PIM neighbor joins, the
outbound interface stops forwarding multicast data immediately.
7.8 QoS
7.8.1 CAR
7.8.1.1 Will the FTP Service Be Affected If the Default CBS and PBS
Configurations Are Adopted for the CAR?
A 90 percent CAR deviation may occur on FTP services. It is recommended to set the CIR,
CBS, and PBS rather than the PIR based on the lab research.
CBS = 100 × CIR; PBS = 2 × CBS (Note that the unit of CIR is kbit/s and the unit of CBS
and PBS is Byte.)
7.8.1.2 After the Rate in a CAR Policy Is Limited to 20 Mbit/s, the Interface Rate
Sometimes Exceeds 20 Mbit/s. Why Does the CAR Policy Not Take Effect?
The interface rate displayed through the display interface command is the rate of the inbound
interface, that is, the interface rate when the CAR is not configured. Therefore, the actual
traffic rate may exceed the CAR.
7.8.1.3 What Are the Reference Values of the CIR and CBS of the CAR on a Sub-
Interface?
Generally, the CBS is 10 times as large as the CIR.
7.8.1.4 After the qos car cir 10000 cbs 1000000 pbs 0 green pass yellow pass red
discard inbound Command Is Configured on an Interface, Traffic on the
Interface Is at a Steady Rate of About 10M. Why Does Great Jitter Occur?
Because the configured CBS value is rather great, if the total traffic rate is above 10M, the
CBS token bucket cannot be full. Therefore, the traffic rate is limited to be less than 10M. If
the total traffic is slight, the CBS token bucket will be full with tokens because the tokens are
placed into the bucket at a rate of 1000 but removed from the bucket at a rather slow rate. If
traffic bursts occur when the CBS token bucket is full of tokens, tokens can be obtained for
1000000 bit/s traffic, which is far beyond 10M. It is recommended to decrease the CBS value
and adjust it to 10 times the value of the CIR. If the great jitter still persists, the CBS value

can be adjusted to an even smaller value. Note that after the adjustment the 10M bandwidth
may not be guaranteed.
7.8.2 Traffic Policy
7.8.2.1 If Multiple Behaviors Are Configured in One Policy, What Is the

Execution Sequence of Multiple Behaviors in One Traffic Policy?
If multiple behaviors are configured through the classifier classifier-name behavior

behavior-name command, the behaviors are executed in the configuration sequence.
classifier classifier1 behavior behavior1
classifier classifier2 behavior behavior2
For example, after a packet arrives, the device checks whether the packet matches classifier 1.
If so, the device processes the packet based on behavior 1 regardless of classifier 2 or
behavior 2; If not, the device checks whether the packet matches classifier 2, and so on.
7.8.2.2 Can the Master and Backup Next Hops That Are Not Defined in the
Routing Table Be Configured for Redirection on the Device?
Yes.
7.8.2.3 Why Are No Statistics About the Number of Packets Matching an ACL
Rule Collected After a Traffic Policy Is Configured on the Device?
You can check that the statistic enable command is configured in the traffic policy view and
the display traffic policy statistics interface gigabitEthernet 2/0/0 inbound command is
configured.
7.8.2.4 How Does share-mode Function When a Traffic Policy Is Applied to

Different Interfaces?
To configure rate limit for multiple IP address segments, users apply a traffic policy to
different interfaces. For example, when the rate is limited to 10 Mbit/s in the traffic behavior,
whether these interfaces share 10 Mbit/s bandwidth or 10 Mbit/s bandwidth is exclusive to
each interface is determined by the share-mode configurations in the traffic policy.
l If share-mode is configured in the traffic policy, these interfaces share 10 Mbit/s

bandwidth.
l If share-mode is not configured in the traffic policy, 10 Mbit/s bandwidth is exclusive to
each interface.
If a traffic policy configured with share-mode is applied to different interfaces, statistics about
the traffic on all the interfaces are collected. That is, the traffic policy configured with share-
mode does not collect statistics about the traffic on each interface individually.
If a traffic policy not configured with share-mode is applied to different interfaces, statistics
about the traffic on each interface individually are collected.

7.8.2.5 If URPF and the Traffic Policy Are Both Configured on an Interface,
Which Is Executed First? Does URPF Affect MPLS Forwarding?
The traffic policy takes effect first. If URPF functions normally, MPLS forwarding is not
affected.
7.8.2.6 When the ATM Service Type Is Set to VBR on the Device, What Does the
Last CDVT Parameter Mean?
CDTV is short for Cell Delay Variation Tolerance. The device determines whether the
received cell is illegal and whether to discard the received cell by checking whether the
difference between the time when the cell reaches the device and the theoretical time when
the cell should reach the device is below the threshold. CDTV is a parameter defined in the
ATM protocol standard. In general, the greater the CDTV value, the lower the probability of
packet loss.
7.8.2.7 Can Traffic Switch Back to the Original Path If the Interface Configured
with Redirection Is Down?
Traffic can switch back to the original patch only after the redirection policy is configured as
a weak policy.
7.8.2.8 How to Configure an Anti-virus Access List?

Configuring an anti-virus access list correctly involves defining traffic classification and
traffic behaviors, determining a traffic policy, and applying the traffic policy to the interface.
The following shows an example:
acl number 3000
description ANTI-VIRUS
rule 1 deny tcp destination-port eq 135
rule 16 deny udp destination-port eq 135
rule 17 deny udp destination-port eq netbios-ns
rule 18 deny udp destination-port eq netbios-dgm
rule 19 deny udp destination-port eq netbios-ssn
rule 40 permit ip
traffic classifier anti_virus operator or
if-match acl 3000
traffic behavior anti_virus

traffic policy anti

classifier anti_virus behavior anti_virus
traffic-policy anti inbound
7.8.2.9 How to Define the Traffic Policy and Use the Traffic Policy on Interfaces?
Define the traffic policy and use the traffic policy on interfaces. The following shows an
example:
acl number 3001
rul per icmp source 1.1.1.1 0 destination 1.1.1.2 0
#
traffic classifier 1
if-match acl 3001
#
traffic behavior 1
#
traffic policy tp1
classifier 1 behavior 1
statistics enable
#
interface Ethernet2/0/0
ip address 10.1.1.1 255.255.255.252
traffic-policy tp1 inbound
NOTE
l You need to run the statistics enable command in the view of the traffic policy and enable the
statistics function of the traffic policy.
l Run the traffic classifier classifier-name [ operator { and | or } ] command. When defining the
traffic classification, you cannot specify the parameter operator as AND. If the logical relation of
the rules is AND, displaying the statistics based on rules is not supported and only the statistics
about the overall matching packets are displayed.
7.8.2.10 Whether Can the Same Traffic Policy Limit the Traffic on Users on
Different Sub Interfaces?
By default, the traffic policy is with shared attributes. That is, the speed limit of bandwidth
depends on the number of nodes on which the traffic policy is applied. If a traffic policy is
applied to multiple interfaces, these interfaces share the bandwidth.
If users on interfaces do not want to share the same bandwidth, run the undo share-mode
command in the view of the traffic policy.
7.8.2.11 How to Impose the Limit on the Access of the Host with the Specific
Source or Destination Address to the Network?
The configuration requirements are as follows: The host whose source IP address is 10.1.1.1
needs to access the hosts on the network segment 10.1.1.18/26 and the host whose IP address
is 10.10.10.10; the host whose source IP address is 10.1.1.2 needs to access all addresses on
the network. In this case, the following configuration is needed:
acl number 3000

rule 0 permit ip source 10.1.1.1 0 destination 10.1.1.18 0.0.0.63
rule 1 permit ip source 10.1.1.1 0 destination 10.10.10.10 0
rule 2 permit ip source 10.1.1.2 0
rule 3 deny ip
traffic classifier 1 operator or

if-match acl 3000

traffic behavior 1
#
traffic policy tp1
share-mode
#
undo shutdown
ip address 10.10.1.1 255.255.255.252
traffic-policy tp1 inbound
7.8.2.12 How to Enable a Server to Set Up Website Services but Disable Other
Servers to Set Up Website Services?
If you want to enable the server whose IP address is 192.168.129.135 to set up website
services only, see the following configuration file:
acl number 3003

rule 0 permit tcp destination 192.168.129.135 0 destination-port eq www
rule 1 permit tcp destination 192.168.129.135 0 destination-port eq 8080
rule 1000 deny tcp destination-port eq www
rule 1002 permit ip
traffic classifier 1
if-match acl 3003
quit
traffic behavior 1
quit
traffic policy 1
quit
7.8.2.13 How to Prevent Any Source IP Address from Pinging a Destination

Address?
Here provides an example. If you want to prevent any source IP address from pinging the IP
address 9.9.9.9, see the following configuration file:
acl 3000
rule 2 deny icmp source any destination 9.9.9.9 0
rule 3 permit ip

if-match acl 3000
traffic behavior b1
traffic policy t1
ip address 10.1.1.1 255.255.255.252
traffic-policy t1 inbound
7.8.2.14 How to Limit the Online Service of Users to a Certain Period?

1. Define an ACL rule.
acl number 3000
rule 5 deny ip destination 2.2.2.0 0.0.0.7 time-range wb
rule 10 permit ip

2. Define the control time.

time-range wb 00:00 to 07:50 daily
3. Define the traffic classification.

traffic classifier wb operator or
if-match acl 3000
4. Define traffic behaviors.

traffic behavior wb
5. Define a traffic policy.

traffic policy
traffic policy wb
classifier wb behavior wb
6. Apply the traffic policy on interfaces.

traffic policy
traffic-policy wb inbound
7.8.2.15 How Do I Check Packet Drop Between Devices?
Figure 7-17 Networking diagram showing packet drop between devices

10.1.1.1 10.1.1.2
RouterA RouterB
As shown in Figure 7-17, packets are dropped between the directly connected Router A and
Router B. If you want to identify where packets are dropped, you can configure the ACL on
two devices. Specific configurations are as follows:
<HUAWEI>system-view
[HUAWEI]acl 3001
[HUAWEI-acl-adv-3001]rule permit icmp source 10.1.1.1 0 destination 10.1.1.2 0
[HUAWEI-acl-adv-3001]quit
[HUAWEI]traffic classifier icmp_in operator or
[HUAWEI-classifier-icmp_in]if-match acl 3001
[HUAWEI-classifier-icmp_in]quit
[HUAWEI]traffic behavior icmp_in
[HUAWEI-behavior-icmp_in]quit
[HUAWEI]traffic policy icmp_in
[HUAWEI-trafficpolicy-icmp_in]classifier icmp_in behavior icmp_in
[HUAWEI enable
[HUAWEI-trafficpolicy-icmp_in]undo share-mode
[HUAWEI-trafficpolicy-icmp_in]quit
[HUAWEI]interface GigabitEthernet 2/0/1
[HUAWEI-GigabitEthernet2/0/1]traffic-policy icmp_in inbound
[HUAWEI-GigabitEthernet2/0/1]quit
<HUAWEI>reset acl counter 3001
After the preceding configurations, run the following command to check the number of
packets that match the ACL.
<HUAWEI>display traffic policy statistics interface GigabitEthernet 2/0/1 inboun
d verbose rule-based
Info: The statistics is shared because the policy is shared.
Interface: GigabitEthernet2/0/1
Traffic policy inbound: icmp_in
slot 2 :

Traffic policy applied at 2010-01-02 05:20:49

Statistics disabled at 2010-01-02 05:20:49
Statistics last cleared: Never
Rule number: 1 IPv4, 0 IPv6
Current status: OK!
Classifier: icmp_in operator or

if-match ACL 3001
rule 5 permit icmp source 10.1.1.1 0 destination 10.1.1.2 0
0 bytes, 0 packets
Last 30 seconds rate 0 pps, 0 bps
7.8.2.16 How to deal with the relationship between the deny/permit mode
defined in ACL and the deny/permit mode defined in traffic behavior?
The ways are as follows.
l permit in ACL indicates the following behaviors are executed when the rule is matched.
The behavior deny forbids the traffic matching the rule, while the behavior permit allows
the traffic matching the rule.
l deny in ACL indicates the deny behavior is executed when the rule is matched, omitting
the following behaviors.
7.8.2.17 Why Does a User Fail to Go Online After a Traffic Policy Is Configured?
After the display current-configuration command is run, the following configurations are
displayed:
acl number 3000
traffic classifier denywww operator or

if-match acl 3000
traffic behavior denywww

deny
traffic policy denywww

share-mode
classifier denywww behavior denywww
As shown in the preceding configurations, the deny action is defined in the traffic behavior,
causing HTTP packets to be filtered out. As a result, the user cannot go online.
You can run the permit command in the traffic behavior view to allow HTTP packets to pass
through. The user then can go online.
7.8.3 ATM QoS
7.8.3.1 Why Is the CLP Field in ATM Cells Not Kept After Successful
Configuration of Transparent Transmission of ATM Cells?
Check whether simple traffic classification has been enabled on the PVC of the upstream PE
where transparent transmission of ATM cells is configured.

7.8.3.2 Why Do ATM Cells Fail to Go Into Internal Queues of the PE After
Configuration of Transparent Transmission of ATM Cells?
On the upstream PE, check that simple ATM traffic classification is enabled on the PVC and
the correct mapping rule is configured in the default DS domain. Only the default DS domain
supports ATM QoS. Therefore, mapping rules configured in other DS domains do not take
effect.
7.8.3.3 Why Does the Command Configured in the DS Domain Fail to Be

Displayed?
The DS domain has the default configuration of many parameters. The default configuration
is not displayed when you run the display current-configuration command.
To check all the configurations including the default on an interface, you can run the display
this interface command in the interface view.
7.8.3.4 Is the trust upstream default Command Effective on Both Upstream or

Downstream Packets?
After you run the trust upstream default command to add an interface to the DS domain, it
is effective on both upstream and downstream packets on the interface. This command applies
to all incoming packets on the interface regardless of service types, ATM cell transparent
transmission, IPoA, or IPoEoA. The incoming packets enter queues according the mappings
in the DS domain that the interface joins. This command also applies to the outgoing packets
of only IPoA and IPoEoA services on the interface. The interface then must change the DSCP
values of the packets according to the mappings in the DS domain that the interface joins.
7.8.4 HQos
7.8.4.1 HQoS Is Configured on the User Side of the PE. Why Does HQoS Not
take Effect?
l HQoS is not configured on the interface where HQoS is required.

l Simple traffic classification is not configured on the interface.
You can run the display to check the configuration of HQoS.
7.8.4.2 Q: Why Cannot a Large Number of Users Access the Internet or Why Is the
Internet Access Speed Low If a RADIUS Server Is Used to Allocate User
Bandwidth?
When a RADIUS server is used to allocate user bandwidth, by default, downstream CAR will
schedule HQoS policies to deploy user bandwidth. Each user exclusively uses the reserved
bandwidth. If a larger number of users are accessing the Internet concurrently, the total
bandwidth to be reserved for users exceeds the interface bandwidth and hence no bandwidth
can be allocated to new access users. The new access users then enter the default queue for
scheduling. The bandwidth of the default queue is 128 kbit/s and therefore the Internet access
speed of these users is very low.

To configure users to share bandwidth, run the qos rate-limit-mode car { inbound |
outbound } command in the domain to which the users belong to configure the rate limit
mode. The users are then scheduled based on the CAR parameters set in the QoS profile.
7.8.5 UCL
7.8.5.1 Presume that a Policy Is Configured with Both ACL 3000 and ACL 6000. If
the Policy Is Globally Applied, How Many Rules Are Delivered? If the Policy Is
Applied to an Interface, How Many Rules Are Delivered?
l For policies that are globally configured, only ACLs in the range of 6000 to 9999 are
delivered. None of the other rules (including non-ACL rules) are delivered.
l For policies that are configured on interfaces, all the other rules (including non-ACL
rules) except ACLs in the range of 6000 to 9999 are delivered.
NOTE
Upstream and downstream NNI traffic on the LPUA

\LPUF-21\LPUF-50\LPUF-51\LPUF-120\LPUF-240\LPUF-101 can be matched against ACLs.
7.8.6 BAS HQoS
7.8.6.1 Why Does Not BAS HQoS Take Effect at the User Side?
l The configured simple traffic classification is incorrectly.
l In the case of family users, QoS profile is incorrectly configured on the interface or in
the domain to which the family users belong.
l In the case of leased line users, QoS profile is incorrectly configured in the domain to
which the leased line users belong.
7.8.7 Last Mile QoS
7.8.7.1 Why Does Not Last Mile QoS Take Effect?

l Last mile QoS in not configured in the system view.
l The mode of last mile QoS is incorrect.
7.8.7.2 How Does Last Mile QoS Configurations Take Effect with L2TP Services?
For L2TP services, last mile QoS configurations in the AAA domain view first take effect. If
last mile QoS is not configured in the AAA domain view, last mile QoS configurations in the
interface view take effect.
7.8.8 Others

7.8.8.1 What Are Configuration Differences Between QoS-related Commands on

a Logical Interface and QoS-related Commands on a Physical Interface?
l traffic-policy
The traffic-policy command cannot be configured on a VLANIF interface. It must be
configured on member interfaces joining the VLAN.
When configuring the traffic-policy command to create a traffic policy for Layer 2
communication, you must set the link-layer parameter. This is because this command is
applicable to Layer 3 communication by default.
When configuring the traffic-policy command on a port-switch interface (either an
Ethernet interface or a trunk interface) joining a VLAN, you must set the vlan parameter.
For other types of interfaces, the vlan parameter does not need to be set.
After the traffic-policy command is configured on a main interface, the traffic policy
configuration takes effect only on the main interface but not on its sub-interfaces. To
create traffic policies on sub-interfaces, run this command on each sub-interface.
l port-queue
The port-queue command can be configured only on physical interfaces but not on
logical interfaces.
You do not need to set the vlan parameter in the port-queue command run on any
interface.
l port-mirroring
To enable port mirroring on a trunk interface, run the port-mirroring command on each
trunk member interface.
To enable port mirroring on a VLANIF interface, run the port-mirroring command on
each VLANIF member interface.
You do not need to set the vlan parameter in the port-mirroring command run on any
interface.
l trust upstream
When configuring the trust upstream command on a port-switch interface (either an
Ethernet interface or a trunk interface) joining a VLAN, you must set the vlan parameter.
For other types of interfaces, the vlan parameter does not need to be set.
After the trust upstream command is configured on a main interface, the configuration
takes effect only on the main interface but not on its sub-interfaces. To enable the trust
upstream function on sub-interfaces, run this command on each sub-interface.
l Sequence in which the traffic-policy and port-mirroring commands take effect and
sequence in which the traffic-policy and qos car commands take effect
After both the traffic-policy and port-mirroring commands are configured on an
interface, if packets match ACL rules, the packets are processed based on the traffic
policy; if the packets do not match ACL rules, the packets are mirrored.
After both the traffic-policy and qos car commands are configured on an interface, if
packets match ACL rules, the packets are processed based on the traffic policy; if the
packets do not match ACL rules, the packets are processed based on QoS CAR actions.
7.8.8.2 Under Which Conditions Can Policy-based Routing on the NE40E&NE80E

Take Effect? Must Reachable Routes Exist?
Whether the strong or weak policy can take effect is irrelevant to routes.

During packet forwarding, if a strong policy is configured on an interface, the policy can take
effect when the interface is physically Up. For an Ethernet interface, ARP entries (either static
or dynamic) must also exist. If the preceding conditions are met, packets can be forwarded;
otherwise, packets are discarded. If a weak policy is configured, the next-hop addresses
configured for packets are matched with the FIB table. If the next-hop addresses found in the
FIB table are consistent with the configured next-hop addresses, packets can be forwarded. If
the next-hop addresses found in the FIB table are inconsistent with the configured next-hop
addresses, the destination addresses of packets are matched with the FIB table. If the entries
corresponding to the destination addresses are found, packets can be forwarded; otherwise,
7.8.8.3 Is There Any Restriction on Weights Assigned to WFQ Queues? Is It

Required that the Sum of Weights of all WFQ Queues Be 100?
Each WFQ queue can be assigned a weight of 1 to 100. Usually, the total sum of weights
assigned to all WFQ queues is 100. This is to facilitate calculation and is not a requirement.
The formula used to calculate the bandwidth for each queue is as follows: (Priority value of
the queue + 1) / Total quota of bandwidth.
The formula used to calculate the total quota of bandwidth is as follows: Number of queues x
(Priority value of the queue + 1).
For example, assume that four WFQ queues exist on an interface. The priority value of one
queue is 5, and the priority value of each of the other three is 4. The total quota of bandwidth
is calculated below:
(4 + 1) x 3 + (5 + 1) = 21
Based on the quota, the weight for each of the three queues with 4 as the priority value is
5/21, and the weight for the queue with 5 as the priority value is 6/21.
7.8.8.4 Can the Policies Configured on a Main Interface Take Effect on All Its
Sub-interfaces?
The policies configured on a main interface cannot take effect on all its sub-interfaces.
Matching packets with ACL rules and performing re-mark actions are both performed on
interfaces. Sub-interfaces cannot inherit policies from their main interface. To make a policy
take effect on all sub-interfaces of a main interface, you must configure the policy on every
interface.
To simplify configurations and ensure that configurations take effect on all the sub-interfaces,
create a QoS profile and configure an unshared traffic policy so that sub-interfaces use the
same traffic classifier and same behavior. This also simplifies the configuration modification
process.
7.9 MPLS
7.9.1 LDP

7.9.1.1 What Are the Functions of LDP Hello Messages?

An LSR sets up a Hello adjacency with another LSR by exchanging Hello messages with the
other LSR. The LSR starts a Hello Hold timer to maintain the Hello adjacency. When
receiving a Hello message of the Hello adjacency, the LSR resets the Hello Hold timer. If the
Hello Hold timer expires, the LSR deletes the Hello adjacency. In addition, if an LDP session
is set up only through this Hello adjacency, the LDP session is deleted.
7.9.1.2 How to Identify an LDP Hello Message?

For a Hello message of a local LDP session, the destination address is 224.0.0.2 and the
source address is the IP address of the LDP-enabled interface; for a Hello message of a
remote LDP session, the destination address is the peer LSR ID and the source address is the
local LSR ID. In addition, the Hello messages are encapsulated through UDP and transmitted
through port 646. Actually, the Hello messages are forwarded by IP.
7.9.1.3 How to View the Number of Received and Sent Hello Messages?
Run the display mpls ldp interface command to view the number of received and sent Hello
messages on an interface.
7.9.1.4 Why the Number of Both Received and Sent Hello Messages Is Zero?
running the display mpls ldp interface command. Normally, Active will be showed in the
Status field. If Inactive is displayed, it indicates that the interface cannot receive or send Hello
messages. Usually, the Inactive state indicates that the interface is Down because the
shutdown command is run or no IP address is assigned to the interface, or another reason.
7.9.1.5 Why Cannot the Peer Receive a Hello Message from the Local LSR When
Both the Local Interface and Peer Interface Are Up?
The possible cause is that the interface board does not support the sending of large packets
such as a packet larger than 180 bytes. You can ping the peer interface with large packets to
verify the preceding judgment.
7.9.1.6 Why Does Not the Number of Both Received and Sent Hello Messages
Increase?
You can check the negotiated value of the Hello Hold timer by running the display mpls ldp
interface verbose command. The value of the negotiated Hello Hold timer is the smaller
value between the set Hello Hold timers on both ends of an LDP session. The value of a Hello
Send timer is one third of the value of a Hello Hold timer. By default, the Link Hello Hold
timer is set to 15s and the Remote Hello Hold timer is set to 45s.
7.9.1.7 How to Determine an LDP Transport Address Used to Set Up a TCP

Connection?
By default, LSR IDs are used to set up a TCP connection. If the mpls ldp transport-address
command is configured in the interface view, the IP addresses of the specified interfaces are
used to set up a TCP connection.

7.9.1.8 How to View the LDP Transport Address Used to Set Up a TCP
Connection?
You can view the LDP transport address used to set up a TCP connection by running the
display mpls ldp session verbose command.
7.9.1.9 How to Determine a Server and a Client in a TCP Connection for an LDP
Session?
You can compare the two LDP transport addresses used to set up a TCP connection. The LSR
with a larger IP address plays the active role that to initiates an LDP session and thus is the
client of the TCP connection. The LSR with a smaller IP address plays the passive role and
thus is the server of the TCP connection.
7.9.1.10 How to View a TCP Connection Set Up for an LDP Session?

Port 646 is used to set up a TCP connection for an LDP session. When running the display
tcp status command, you can view the TCP connections for LDP sessions with port number
being 646.
7.9.1.11 How to Judge Whether a TCP Connection on a Server Is Normal?

Normally, on the server, there is a listening port with the status being Listening and one or
more connections with the status being Established. In a TCP connection, the local port
number is 646 and the peer port number is a randomly assigned five-digit number.
TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID
State
0d3bda5c 32 /1 0.0.0.0:23 0.0.0.0:0 14849
Listening
0b6d91cc 23 /2 2.2.2.2:646 1.1.1.1:53585646 0
Established
7.9.1.12 Why Does a TCP Connection Fail to Be Set Up?

You can run the ping -a [ src-addr ] [ dst-addr ] command with and without src-addr being
specified. If the address cannot be pinged, you can exclude the problems of the routes and the
forwarding entries.
7.9.1.13 Why Does a TCP Connection Fail Go Up When the Ping Is Successful?
The prerequisite for setting up a TCP connection is that the client initiates the TCP connection
and the server has a listening port in the Listening state. You can run the display tcp status
command to check whether the client initiates the TCP connection and whether a listening
port is created on the server.
7.9.1.14 Why Is Not a Listening Port Created on a Server?

The prerequisite for creating a listening port on a server is that an LSR receives a Hello
message from a client, and confirms that the LSR itself is the server according to the transport
address carried in the Hello message. If no listening port is created on the server, you can
check the received Hello message and the transport address that is selected through
comparison.

7.9.1.15 Why Does Not a Client Initiate a TCP Connection?

The prerequisite for a client to initiate a TCP connection is that an LSR receives a Hello
message from a server, and confirms that the LSR itself is the client according to the transport
address carried in the Hello message. If the client does not initiate a TCP connection, you can
check the received Hello message and the transport address that is selected through
comparison.
7.9.1.16 Why Does a TCP Connection Fail to Be Set Up When Both a Server and a
Client Initiate a TCP Connection?
The establishment of a TCP connection for an LDP session uses MD5 authentication. If one
end of the connection is configured with MD5 authentication whereas the other end is not, or
two ends of the connection are configured with different MD5 passwords, the TCP connection
cannot be set up. In addition, if MD5 authentication in cipher text mode is implemented on a
non-Huawei device in a private manner, MD5 authentication fails and a Huawei device and
the non-Huawei device cannot communicate with each other.
7.9.1.17 What Are the Functions of LDP Keepalive Messages?

Two LSRs maintain an LDP session by exchanging Keepalive messages. The LSR starts a
Keepalive Hold timer to maintain the LDP session. When receiving a Keepalive message of
the LDP session, the LSR resets the Keepalive Hold timer. If the Keepalive Hold timer
expires, the LSR deletes the LDP session.
7.9.1.18 How to View the Number of Received and Sent Keepalive Messages?
You can run the display mpls ldp session command to view the number of received and sent
Keepalive messages of an LDP session.
7.9.1.19 Why Does Not the Number of Both Received and Sent Keepalive
Messages Increase?
You can check the negotiated Keepalive Hold timer by running the display mpls ldp session
verbose command. The negotiated value of the Keepalive Hold timer is the smaller value
between the set Hold timers on both the two ends of an LDP session. The value of a
Keepalive Send timer is one third of the value of a Keepalive Hold timer. By default, the
Keepalive Hold timer is set to 45s.
7.9.1.20 What Are the Common Causes of the Problem that an LDP Session
Suddenly Goes Down?
An LDP session is sensitive to the link status and the system busy state. The LDP session may
flap when the packet forwarding becomes abnormal or the CPU usage is high.
Usually, the interruption event of an LDP session is logged and the common cause is that a
Hello Hold timer expires or a Keepalive Hold timer expires.
7.9.1.21 How to Locate the Cause of the Problem that an LDP Session Flaps After
a Hello Hold Timer Expires?
When the Hello Hold timer expires, you can run the display mpls ldp interface command to
check whether both ends of the LDP session can send Hello messages. If Hello messages are

not sent normally, the possible cause is that the system is busy or a fault occurs in the system.
If Hello messages are normally sent but fail to be received, the possible cause is that the
transmission on links is abnormal. In this case, you can ping the IP address of the peer
interface to check the forwarding status.
7.9.1.22 How to Locate the Cause of the Problem that an LDP Session Flaps After
a Keepalive Hold Timer Expires?
When the Keepalive Hold timer expires, you need to check whether both ends of the LDP
session can normally send Keepalive messages by running the display mpls ldp session
command. If Keepalive messages are not sent normally, the possible cause is that the system
is busy or a fault occurs in the system. If Keepalive messages are normally sent but fail to be
received, the possible cause is that the transmission on links is abnormal. In this case, you can
ping the transport address used to set up a TCP connection on the peer to check the
forwarding status.
7.9.1.23 Why Cannot an LDP Session Go Up After a TCP Session Is Normally Set
Up?
After the TCP connection is set up, both ends of the LDP session need to negotiate parameters
such as the label advertisement mode of either DU or DoD. If the parameter negotiation fails,
the LDP session cannot go Up.
7.9.1.24 In Which Scenario Do LSPs Flap?

The possible causes are route flapping and LDP session flapping. In addition, in the scenario
where loop detection, address redirection, or multi-link is configured or in the ring topology,
the LSPs may flap.
7.9.1.25 How to Troubleshoot the Problem of LSP Flapping?

You can perform one of the following operations to solve the problem according to specific
causes:
l Change the policy for of triggering the establishment of LSPs.
– Run the lsp-trigger ip-prefix ip-prefix-name command to use a specified segment
route based on an IP prefix list to trigger the establishment of LSPs.
– Run the lsp-trigger host command to use 32-bit IP routes to trigger LDP to set up
LSPs.
l If multiple links are set up, enable LDP and establish LDP sessions on these links.
l If addresses overlap, you can delete one of them.
l If a ring network exists, set the cost of the direct link to a value equal to or smaller than
the sum of the costs of another link; alternatively, connect another device to the device
on which LSP flapping occurs and then establish an LDP session on the new device.
7.9.1.26 Which Measures Can Be Taken When LSP Flapping Occurs?

You can perform the following operations:
l Check whether the peer can be always pinged through.
Run the display mpls ldp peer command in the system view, and you can view the
transport address (in the Transport-Address field) used by the peer to set up an LDP

session with the local node. Then you can run the ping command to check whether
l Check whether route flapping occurs.
Run the display ip routing-table command in the system view, and you can view
information about all routes. In addition, you can specify a destination address in the
command to view all routes to the destination address. By monitoring route information
within a certain period, you can check whether route flapping occurs.
l Check whether LDP session flapping occurs.
Run the display mpls ldp session command in the system view, and you can view
information about all LDP sessions. In addition, you can specify a peer address in the
command to view information about an LDP session between the local node and the
peer. By monitoring LDP session information within a certain period, you can check
whether LDP session flapping occurs.
l View configurations to check whether the lsp-trigger all command is configured.
l You can enable the debugging function to check whether an abnormality occurs.
7.9.1.27 How to Verify That an LDP LSP Is Successfully Set Up?

You can perform the following operations to verify that the LDP LSP is successfully set up:
l Check and ensure that an LDP session is correctly set up by running the display mpls
ldp session command.
l Check and ensure that a route exists by running the display ip routing-table ip-address
mask command.
l Check and ensure that the outgoing interface of the route and the address of the recovery
source of the LDP peer are the same by running the display mpls ldp peer command.
l Check and ensure that the configurations are met the requirements for triggering the
establishment of an LSP.
NOTE
You can view the policy for triggering the establishment of an LSP in the MPLS view. By default,
the lsp-trigger host command is configured to trigger the establishment of an LSP.
7.9.1.28 What Is the Process of Configuring LDP over TE?

As shown in Figure 7-18, P1, P2, and P3 belong to an RSVP-TE area. PE1 and PE2 are
located in a VPN. LDP is run between PE1 and P1 and between P3 and PE2. Take the LDP
LSP between PE1 and PE2 as an example to demonstrate the process of establishing an LDP
LSP over the RSVP-TE domain.
Figure 7-18 Process of setting up an LDP LSP over an RSVP-TE domain
LDP-Label-3 LDP-Label-2 LDP-Label-1
PE1 P1 P2 P3 PE2
RSVP-Label-2 RSVP-Label-1
LDP LSP RSVP LSP LDP LSP

1. An RSVP-TE tunnel is set up between P1 and P3. P3 distributes RSVP-Label-1 to P2

and P2 assigns RSVP-Label-2 to P1.
2. A remote LDP session is set up between P1 and P3.
3. The forwarding adjacency function is enabled on P1 and P3 to ensure that the outgoing
interface of the route to PE2 is a tunnel interface as displayed on P1.
4. PE2 triggers LDP to set up an LSP and sends a Label Mapping message carrying LDP-
Label-1 to P3.
5. After receiving the Label Mapping message, P3 sends a Label Mapping message
carrying LDP-Label-2 to P1 through the remote LDP session.
6. After receiving the Label Mapping message, P1 sends a Label Mapping message
carrying LDP-Label-3 to PE1.
The LDP LSP from PE1 to PE2 is thus set up over the RSVP-TE domain.
7.9.1.29 How to Troubleshoot the Problem that an LSP Fails to Be Set Up in the
LDP over TE Scenario?
Figure 7-19 Process of setting up an LDP LSP over an RSVP-TE domain
LDP-Label-3 LDP-Label-2 LDP-Label-1
PE1 P1 P2 P3 PE2
RSVP-Label-2 RSVP-Label-1
LDP LSP RSVP LSP LDP LSP
As shown in Figure 7-19, the troubleshooting procedures are as follows:
1. Check whether the remote device can be pinged through.

2. Check whether the two ends of the tunnel can learn the routes from each other.
3. Check whether basic MPLS functions are correctly configured.
Ensure that LDP is enabled globally and on interfaces of PE1, P1, P3, and PE2; RSVP is
enabled globally and on interfaces of P1, P2, and P3.
4. Check whether an LDP session is successfully set up and ensure that the destination
address of the tunnel is the same with the LSR ID of the remote LDP peer.
– You can run the display mpls ldp session command to check whether an LDP
session is set up. As shown in the preceding figure, local LDP sessions must be set
up between PE1 and P1, and between P3 and PE2.
– You can run the display mpls ldp remote-peer command to check information
about the remote LDP session. As shown in the preceding figure, a remote LDP
session must be set up between P1 and P3.
5. Check whether a TE tunnel is correctly set up and whether the tunnel status is Up.

The forwarding adjacency function is enabled on the tunnel interface and the metric is
adjusted, which ensures that traffic from P1 to P3, from P1 to PE2, from P3 to PE1, and
from P3 to P1 passes through the tunnel interface.
6. Check whether the ip address of the TE Tunnel is configured.
7. To locate the cause of the problem that the LSP is not set up, see the preceding FAQs.
7.9.1.30 What Are the Functions of MPLS Ping?

In an MPLS network, if an LSP fails to forward data, the MPLS control plane on which the
LSP is set up cannot detect the forwarding failure, which complicates the network
maintenance.
MPLS ping is a mechanism to detect an LSP failure and locate the faulty node. Similar to
ordinary IP ping, MPLS ping detects availability of an LSP through MPLS Echo Request
messages and MPLS Echo Reply messages. These two types of messages are encapsulated
through UDP and sent through port 3503.
An MPLS Echo Request message carries information about a FEC to be detected. Similarly to
a packet belongs to this FEC, the MPLS Echo Request message travels along an LSP to
implement detection.
After the MPLS Echo Request message reaches the egress of the LSP and the control plane on
the egress confirms that the outgoing interface of the FEC resides on the local LSR, the
MPLS ping finishes.
To prevent the egress from forwarding the Echo Request message to another node, in the IP
header of the Echo Request message, the destination address is set to an IP address (as the
local loopback address) within the segment 127/8 and the TTL is set to 1.
7.9.1.31 Does MPLS Ping Support Fragmented Packets?

MPLS ping does not support fragmented packets.
7.9.1.32 What Are the Functions of GR Timers Configured in the MPLS LDP
View?
After the switchover of the GR Restarter, the MPLS Forwarding State Holding timer, namely,
the Neighbor-liveness timer configured in the MPLS LDP view, is started. Within the timeout
period of the Neighbor-liveness timer, all forwarding entries before the switchover is
performed are retained; after the Neighbor-liveness timer expires, all forwarding entries that
are not restored are deleted.
After the GR Helper senses that the switchover is performed or a protocol is restarted on the
GR Restarter, the GR Helper starts a GR Reconnect timer. Within the timeout period of the
GR Reconnect timer, all forwarding entries of the GR Restarter are retained; after the GR
Reconnect timer expires, all forwarding entries that are not restored are deleted. Before the
GR Reconnect timer expires, if all sessions between the GR Restarter and GR Helper are
reestablished, the GR Helper deletes the GR Reconnect timer and starts a GR Recovery timer.
Before the GR Recovery timer expires, the GR Helper assists the GR Restarter in restoring
forwarding entries. After the GR Recovery timer expires, the GR Helper deletes all GR
Restarter-related forwarding entries that are not resorted.

7.9.1.33 What Is the Default Value of Each GR Timer Set in the MPLS LDP View?
By default, the MPLS Forwarding State Holding timer, namely, the Neighbor-liveness Timer,
is set to 10 minutes and both the GR Reconnect timer and the GR Recovery timer are 5
minutes.
7.9.1.34 Why Is the Logged LDP GR Time Larger Than the Timeout Period (10
Minutes) of the MPLS Forwarding State Holding Timer?
After the switchover is performed on the GR Restarter, the routes must converge before the
LDP GR process is performed. Although being started immediately after the switchover, the
MPLS Forwarding State Holding timer is reset after the route convergence. The logged start
time of the GR process is the time the MPLS Forwarding State Holding timer is started for the
first time; the logged end time of the GR process is the timeout time of the MPLS Forwarding
State Holding timer. The logged LDP GR time is the sum of the route convergence time and
the timeout period (10 minutes) of the MPLS Forwarding State Holding timer.
7.9.1.35 How to Judge Whether a Device Is in the LDP GR Process?

You can run the display mpls graceful-restart command to view the current GR status.
7.9.1.36 Why Does Not an LSR Retain Forwarding Entries After the Master/Slave
Switchover Is Performed on the Neighbor?
The LSR can retain forwarding entries after the master/slave switchover is performed on a
neighbor only when GR is enabled on both ends of an LDP session. In addition, the LDP GR
capabilities on the local LSR and the neighbor are negotiated when the LDP session is set up.
7.9.1.37 How to Judge Whether an LSR Has the GR Capability?

You can run the display mpls ldp session verbose command to view the GR capability of
both ends of an LDP session and the values of the GR Reconnect timer and GR Recovery
timer. In the command output, when On is displayed in the Session FT Flag field, it indicates
that the LSR has the GR capability.
7.9.1.38 Why Does LDP Loop Detection Not Need to Be Enabled?

An LSP is set up strictly based on IP routes. The routing protocol such as IS-IS and OSPF
already ensures that the generated routes contain no loop. In this case, LDP loop detection
does not need to be enabled.
7.9.1.39 Why Is No Optimal Route Generated?

The optimal route and the less optimal route must be bound through LDP FRR. If no optimal
route is generated, you can convert one of routes working in load balancing mode to the
optimal route by changing the cost of OSPF or IS-IS. You can then run the display ip
routing-table command in the system view to view all routes and check whether the optimal
route is generated.
Typical problem: No optimal route is generated if two routes work in load balancing mode.
As shown in Figure 7-20, two routes between LSR A and LSR B work in load balancing
mode. In this case, no optimal route is generated.

Figure 7-20 LDP FRR

LSRC
Smallest
Cost
LSRA Optimal LSRB
route
Cancel load balancing
LSRD
Solution: Change the cost of OSPF or IS-IS so that the optimal route can be generated.
7.9.1.40 Why Cannot the Primary LSP Be Bound to a Backup LSP When LDP FRR
Is Enabled?
LDP FRR is implemented on the basis of LDP labels distributed along the backup LSP. You
can check whether an LDP session is successfully set up in the system view of each node. The
status of the backup LSP must be Operational.
7.9.1.41 How to Judge Whether a Liberal LSP Is Generated When LDP FRR Is
Enabled?
You can change routes by changing the cost to convert the links working in load balancing
mode to the normal LSP and liberal LSP. You can then run the display mpls ldp lsp
command in the system view to view all LSPs and check whether the liberal LSP is set up.
Typical problem: When two LSPs work in load balancing mode, no backup LSP (namely, the
liberal LSP) is generated and thus the LDP FRR backup LSP cannot be set up.
Figure 7-21 Networking diagram of LDP FRR load balancing

LSRC
Smaller cost
LSRA LSRB
Normal LSP
Liberal LSP
LSRD

Solution: Change the cost of OSPF or IS-IS so that the liberal LSP can be set up.
7.9.1.42 How to Judge Whether Manual LDP FRR Is Correctly Configured?

Manual LDP FRR can be correctly configured by running the mpls ldp frr nexthop
command on the outgoing interface of the primary LSP to specify the next hop of the backup
LSP.
Figure 7-22 Networking diagram of manual LDP FRR

LSRC
Enable LDP FRR

Smaller cost
Normal LSP
LSRA LSRB
Liberal LSP
LDP FRR next hop LSRD
7.9.1.43 Does Packet Loss Occur During the LDP FRR Switchback?
Packets may be discarded during the LDP FRR switchback and packet loss is unavoidable in
the FRR feature.
FRR applies for a forwarding entry to be used by a liberal LSP. The forwarding entry is the
backup forwarding entry used by the primary LSP and is delivered together with the primary
forwarding entry to the forwarding plane. In this manner, the primary LSP and the liberal LSP
are associated with each other. In the scenario of the switchback, no liberal LSP exists and no
forwarding entry is generated for the liberal LSP. As a result, LDP FRR does not take effect.
7.9.1.44 What Types of Labels Are Distributed Through LDP?

LDP distributes labels of the following types:
l explicit-null: indicates the explicit null label.
l implicit-null: indicates the implicit null label.
l non-null: indicates the non-null label.
7.9.1.45 What Is an Explicit Null Label?

An explicit null label is the IPv4 explicit null label with the value being 0. The explicit null
label is valid only at the bottom of a label stack, which indicates that an LSR must pop out the
label and forward the packet based on the IPv4 header.
When detecting that a label with the value being 0 is assigned to the downstream forwarded
entry, the penultimate hop pushes the label with the value being 0 into the label stack of the

packet and then forwards the packet to the egress. When detecting that the label in the
received packet is 0, the egress does not search the ILM but directly pops out the label and
forwards the packet according to the IP header (assume that there is only one label in the label
stack).
7.9.1.46 What Is an Implicit Null Label?

An implicit null label is the label with the value being 3. An LSR can use and distribute the
implicit null label, whereas the label does not appear in an encapsulated packet. When an LSR
is to swap labels and detects that the incoming label is an implicit null label, the LSR pops out
the label from the label stack instead of swapping the label with a new label.
When detecting that the label with the value being 3 is to be assigned to the downstream
entry, the penultimate hop directly forwards the packet to the egress without pushing any label
into the packet. When receiving the packet and finding that the packet carries no label, the
egress handles the packet as an ordinary IP packet.
7.9.1.47 In Which Scenario Does LDP Use Non-Null Labels?

LDP uses non-null labels in any of the following scenarios:
l If the non-null mode is specified in the MPLS view, the egress needs to assign a non-null
label to the penultimate hop.
l When receiving a Label Mapping message from a neighbor and replying with no Label
Release message, the LSR uses a non-null label to set up an LSP including the liberal
LSP.
l The non-null label is used when a Transit LSP is set up.
l In a remote LDP session, if no downstream local session is set up and the policy for
triggering the establishment of an LSP is all, an LSR, functioning as an agent egress,
assigns a non-null label to each FEC except for the local route.
NOTE
Each FEC uses a label.
7.9.1.48 How to Identify the Type of the Label Pushed into a Packet at the
Penultimate Hop?
By default, the egress assigns an implicit null label to the penultimate hop. When an LSR is
assigned an implicit null label, the LSR does not swap the label at the top of the label stack
with the implicit null label but only pops out the label. If a label is pushed into the packet on
the penultimate hop, it indicates that the type-based label distribution mode is modified.
Typical problem: When a label to be assigned to the penultimate hop is configured as the
explicit null label or non-null label in the MPLS view, the penultimate hop can be assigned
the label whose value is not 3. You can view the configurations in the MPLS view to check
the type of the label assigned to the penultimate hop.
Solution: You can configure the penultimate hop popping (PHP) feature in the MPLS view.
That is, you can modify the type of the label to be assigned to implicit null. Alternatively, you
can delete the label distribution configurations.

7.9.1.49 How to Configure an Explicit Null Label Be Assigned to the Penultimate

Hop?
If an implicit null label is assigned to the penultimate hop, it indicates that the egress allocates
a label with the value being 3 for the penultimate hop. If a non-null label is assigned to the
penultimate hop, it indicates that the PHP feature is not used. In this case, the egress allocates
a normal label with the value equal to or larger than 16 for the penultimate hop.
Typical problem: The type of the label to be allocated is unchanged or is changed to non-null.
In this case, no explicit null label is assigned to the penultimate hop.
Solution: Change the label distribution mode to explicit-null in the MPLS view.
7.9.1.50 What Is the Meaning of the MTU in the display mpls interface Command
Output?
The MTU indicates the minimum value of the MTU set on an interface. For example, the
MPLS MTU is set to 1000 bytes on the interface and the MTU is set to 800 bytes. The valid
MTU value is 800 bytes on the interface.
7.9.1.51 What Are the Meanings of MTUs in the display mpls interface verbose
Command Output?
Their meanings are as follows:
l MPLS MTU: indicates the MTU value set through the mpls mtu command.
l Interface MTU: indicates the interface MTU that is negotiated.
l Effective MTU: indicates the smaller value between the MPLS MTU and interface
MTU.
<HUAWEI> display mpls interface pos 2/0/0 verbose
No : 1
Interface : Pos2/0/0
Status : Up
TE Attribute : Enable
Static LSPCount : 0
Static CR-LSPCount : 0
LDP LSPCount : 0
RSVP LSPCount : 0
MPLS MTU : -
Interface MTU : 1500
Effective MTU : 1500
TE FRR : Disable
Interface Index : 0x18000206
7.9.1.52 What Is the Meaning of the MTU in the display mpls ldp interface
verbose Command Output?
The value in the Effective MTU field is obtained from the interface configuration.
Theoretically, the effective MTU value is the smaller value between the MPLS MTU and the
interface MTU.
When the MPLS MTU and the interface MTU are changed, configurations can be updated
only after the interface is restarted.

7.9.1.53 What Is the Meaning of the MTU in the display mpls lsp include
Command Output?
The MTU indicates the LSP MTU. Each LSP has one outgoing interface and the LSP MTU is
the smaller value between the effective MTU value of the outgoing interface and the MTU
value received from the downstream neighbor.
7.9.1.54 What Are the Causes of the Problem that a Static LSP Cannot Go Up?
Static LSPs can be classified into the ordinary static LSP, static LSP bound to a tunnel, and
static CR-LSP.
l For an ordinary static LSP, you can check the configured commands. The ordinary static
LSP cannot go Up in one of the following situations:
– MPLS is not globally enabled.
– A static LSP with the same name is already set up.
– A static LSP with the same destination address and the same outgoing interface (or
next hop) already exists.
– A static LSP with the same incoming label is already set up.
– The configured next-hop address is not the actual next-hop address in the routing
table.
l For a static LSP bound to a tunnel, you can check the configured commands. The static
LSP bound to a tunnel cannot go Up in one of the following situations:
– MPLS TE is not globally enabled.
– The tunnel to which the static LSP is bound does not exist or is not configured on
the ingress.
– A static LSP with the same name already exists.
– A static LSP with the same destination address and the outgoing interface (or next
hop) already exists.
– A static LSP with the same incoming label already exists.
table.
l For a static CR-LSP, you can check the configured commands. The static CR-LSP
cannot go Up in one of the following situations:
– MPLS TE is not globally enabled.
– The tunnel to which the static CR-LSP is bound does not exist or is not configured
on the ingress.
– A static LSP with the same name already exists.
– A static LSP with the same destination address and the outgoing interface (or next
hop) already exists.
– A static LSP with the same incoming label already exists.
table.

7.9.1.55 What Is the Difference Between a Static LSP Bound to a Tunnel and a
Static CR-LSP?
Static LSPs are classified into the ordinary static LSP and the static LSP bound to a tunnel,
whereas the static CR-LSP is of only one type and must be bound to a tunnel. The difference
between a static LSP bound to a TE tunnel and a CR-LSP is that a static CR-LSP requires the
reserved bandwidth, whereas a static LSP does not need the reserved bandwidth.
7.9.1.56 Which Must Be Specified, the Next-hop Address or the Outgoing

Interface, When a Static Ingress LSP Is to Be Set Up?
When a static ingress LSP (including the static ingress LSP bound to a tunnel) is to be set up,
the configuration entries must be strictly checked according to route information, including
the destination address, mask, next-hop address, and outgoing interface. If one of the
configurations of the static LSP is inconsistent with the route information, the static LSP
cannot go Up.
When a static LSP is to be set up, if an outgoing interface is specified, the system calculates
the next-hop address according to the outgoing interface. In this case, the next-hop address is
the IP address of the local outgoing interface. If the next-hop address (which is the IP address
of the incoming interface of the peer but not the IP address of the local outgoing interface) is
specified, the system calculates the outgoing interface according to the next-hop address. In
this case, the calculated outgoing interface is still the local outgoing interface.
When configuring a static ingress LSP, note the following:
l For a static LSP over TE, if the IP address of the TE tunnel is unnumbered, you must
assign an outgoing interface.
l If a static route is used and an outgoing interface is specified, the outgoing interface must
be specified for the static ingress LSP.
l Except for the preceding situations, the next-hop address, rather than the outgoing
interface, must be specified for the static ingress LSP.
NOTE
The principle is that the route of the static ingress LSP must match the route information.
7.9.1.57 Why Does an LDP Session Fail to Be Set Up After the Link Protocol Is
Changed to Frame Relay on an LDP-Enabled POS Interface?
When frame relay (FR) is used as a link protocol on a POS interface, you must configure FR
features so that FR can go Up and another protocol over FR can also go Up.
Solution:
1. Configure an FR-enabled interface as the DCE on one end of the LDP session so that the
link protocol can go Up. (The other end dos not need to be configured because the
default type is DTE)
2. Set the DLCI.
3. Enable the sending of multicast packets.
For example:
#
interface Pos1/0/0
clock master

link-protocol fr
fr interface-type dce
fr map ip default 50 broadcast
fr dlci 50
ip address 100.1.2.2 255.255.255.0
isis enable 1
mpls
mpls ldp
#
The configurations of the peer are as follows:

#
interface Pos1/0/0
clock master
link-protocol fr
fr map ip default 50 broadcast
fr dlci 50
ip address 100.1.2.1 255.255.255.0
isis enable 1
mpls
mpls ldp
#
7.9.1.58 What Are the Causes of the Board Problem, Which Results In LDP
Session Flapping?
Figure 7-23 shows the networking of the MPLS L3VPN inter-AS Option C.
Figure 7-23 Networking diagram of the MPLS L3VPN inter-AS Option C
PE1 ASBR1 ASBR2 PE2
Problem description: An LDP session between PE1 and ASBR1 is flapping.
l After the display mpls ldp session command is run on PE1, the output shows that an
LDP session flaps, and the number of sent Keepalive messages is more than the number
of received Keepalive messages.
After the ping command on PE1 is run, the output shows that the ping packets longer
than 180 bytes are discarded. The ping thus fails.
On the board of PE1, the maximum size of packets allowed to be transmitted is 180
bytes.
l After the display mpls ldp session command is run on ASBR1, the output shows that
the LDP session between ASBR1 and PE1 flaps, whereas the LDP session between
ASBR1 and ASBR2 is normal.
The ping packets longer than 180 bytes sent from ASBR1 to PE1 are discarded; whereas,
the ping packets longer than 180 bytes sent from ASBR1 to ASBR2 can be transmitted,
which indicates that the ping is successful. In addition, the ping packets longer than 1500
bytes sent from ASBR1 to ASBR2 can also be transmitted, which indicates that the ping
is successful.

Cause analysis: An LDP session is maintained through Keepalive messages. If the peer of the
LDP session does not receive a Keepalive message within 45 seconds, the LDP session goes
Down.
The Keepalive messages are transmitted through TCP. If TCP packets are longer than 180
bytes, the Keepalive messages cannot be sent. The size of a Keepalive message is small,
whereas the Keepalive message has to be packed with other messages into a TCP packet. If
the TCP packet is longer than 180 bytes, the Keepalive message cannot be sent. In this case,
the LDP session goes Down.
Solution: Replace the board on PE1 and ensure that the sizes of packets allowed to be
transmitted are the same on the boards of all nodes.
7.9.1.59 Why Cannot an LDP Session Be Set Up Between ATM Interfaces?

An LDP session can be set up between ATM interfaces only after the special configurations
are performed on these ATM interfaces.
Problem description: After the check, the configurations of both ends of the LDP session are
as follows:
l Configurations of LSR A are as follows:
#
interface Atm1/0/0
ip address 100.21.24.21 255.255.255.0
pvc 30/1
map ip default
mpls
mpls ldp
#
l Configurations of LSR B are as follows:

#
interface Atm1/0/0
ip address 100.21.24.24 255.255.255.0
pvc 30/1
map ip default
mpls
mpls ldp
#
After the display mpls ldp session command is run, the output does not show an LDP session
or the LDP peers; whereas, the interfaces of both ends of the LDP session can ping through
each other.
To send Layer 3 packets, the ATM interfaces must be configured with the mapping between
the local VPI and the peer VPI on the PVC; to send multicast packets, the ATM interfaces
must be configured with the mapping with the broadcast attribute on the PVC.
You can run the map ip default broadcast command or the map ip inarp broadcast
command in the PVC view to enable the sending of multicast packets. The LDP session then
can be normally set up.
Solution:
Run the map ip inarp broadcast command or the map ip default broadcast command on
both ends of the LDP session.
l Configurations of LSR A are as follows:
#
interface Atm1/0/0

ip address 100.21.24.21 255.255.255.0

pvc 30/1
map ip inarp broadcast
mpls
mpls ldp
#
l Configurations of LSR B are as follows:

#
interface Atm1/0/0
ip address 100.21.24.24 255.255.255.0
pvc 30/1
map ip inarp broadcast
mpls
mpls ldp
#
7.9.1.60 What Are the Messages of LDP and the Intervals for Sending These
Messages?
TCP
Hello Hello Keepalive Port
Prot Message Hello Message Message Message Numbe
ocol (Raw-IP) (Raw-Link) (UDP) (TCP) r
LDP None None The interval The interval for 646

for sending sending messages
messages is is 15s and the
5s; the Hello Keepalive Hold
Hold timer is timer is set to
15s; the 45s.
multicast IP
address is
224.0.0.2; the
port number
is 646.
7.9.1.61 What Problems Does the Coexistence of a Local LDP Session and a
Remote LDP Session Solve?
A: The answer is as follows:
Figure 7-24 Networking diagram of the coexistence of a local LDP session and a remote LDP
session
LSRC
LSRA LSRB

On a network shown in Figure 7-24, LSR A and LSR B function as PEs. If L2VPN services
are to be deployed, the following conditions must be satisfied:
l An LDP session is established between LSR A and LSR B to swap L2VPN labels. If the
session is interrupted, L2VPN labels will be re-distributed.
l An E2E public network tunnel is established from LSR A to LSR B, transmitting
L2VPN traffic. If the LSP goes Down, L2VPN traffic will be interrupted.
Therefore, if a link between LSR A and LSR B fails, a remote LDP session needs to be
established, ensuring proper L2VPN label swapping; after the link between LSR A and LSR
B recovers, a local session needs to be established to set up an LDP LSP.
On a network that does not allow the coexistence of a local LDP session and a remote LDP
session, if a link between LSR A and LSR B fails, a local session goes Down and then a
remote session needs to be established. This requires that L2VPN labels be re-distributed.
Likewise, after the link between LSR A and LSR B recovers, the remote session goes Down
and a local session needs to be established. This also requires that L2VPN labels be re-
distributed.
If the coexistence of a local LDP session and a remote LDP session is allowed, neither a local
nor a remote LDP session will be disconnected and L2VPN labels will not be re-distributed
regardless of whether the link between LSR A and LSR B fails or recovers.
7.9.1.62 Are There Any LDP Sub-features?

A: The answer is as follows:
LDP Sub-Feature Description
LDP-IGP LDP-IGP synchronization means that a route switchback is

synchronization delayed by suppressing the setup of an IGP neighbor relationship
so that the route switchback and LDP convergence can be
performed synchronously. The backup link continues forwarding
traffic before an LSP is established on a primary link. The backup
link is deleted after the LSP is established along the primary link.
LDP GR LDP graceful restart (GR) enables a Restarter to perform a master/

slave switchover or protocol-based restart without interrupting the
forwarding process with the help of a Helper, thus minimizing
protocol flapping on the control plane.

LDP FRR LDP fast reroute (FRR) backs up local interfaces on MPLS
networks. LDP FRR, in liberal label retention mode, obtains a
liberal label, applies for a forwarding entry associated with the
label, and then forwards the forwarding entry to the forwarding
plane as a backup forwarding entry used by the primary LSP.
When the interface fails (which is detected by the interface itself or
by being associated with a Bidirectional forwarding detection
(BFD) session) or the primary LSP fails (which is detected by an
associated BFD session), LDP FRR fast switches traffic to a
backup LSP to protect the primary LSP. The backup forwarding
entries generated by LDP FRR are subject to the primary LSP
rather than the backup LSP; therefore, LDP FRR implementation
does not involve traffic switchover.
LDP MTU MTU is short for maximum transmission unit. When two devices
on one network communicate with each other, the MTU of the
network plays an important role. An MTU value determines the
maximum number of bytes that can be transmitted by the sender at
a time. If the MTU exceeds the maximum number of bytes
supported by the receiver or a transit device, packets are then
fragmented or even discarded, thus aggravating the network
transmission load. In view of this, devices have to calculate a
correct MTU before communication so that packets can reach the
receiver successfully.
LDP MD5 MD5, short for Message-Digest Algorithm 5, is an international

standard digest password algorithm defined in RFC 1321. A
typical application of MD5 is to calculate the digest of a message
to avoid modification of the message. The MD5 message digest is
uniquely generated by an irreversible character string algorithm. A
different message digest is generated whenever the message
changes in any form during transmission, based on which the
receiver considers the arriving packet incorrect.
Static LSP A static LSP is an LSP that is totally manually established. All key
information about the static LSP such as incoming labels, outgoing
labels, the ingress, and the egress are manually configured. The
status change of a static LSP such as going Up or Down is locally
significant, which do not affect the Up or Down state of LSPs
established on the upstream or downstream nodes.
Distributing labels Distributing labels for BGP by LDP means that LDP uses public
for BGP by LDP 32-bit-mask BGP routes to establish an egress LSP and LDP uses
public BGP routes to establish a transit LSP.
LDP over TE RSVP-TE is an MPLS tunneling technique and generates LSPs as

tunnels to transparently transmit packets of other protocols. LDP is
another MPLS tunneling technique and generates LDP LSPs. LDP
over TE enables LDP LSPs to cross an RSVP-TE area, thus
transmitting VPN services.

LDP GTSM GTSM, short for generalized TTL security mechanism (GTSM), is
a mechanism for protecting IP services by checking whether the
TTL value in the IP header is within a pre-defined range.
7.9.1.63 What Are Functions of the remote-peer pwe3 and remote-ip ip-address
pwe3 Commands?
The remote-peer pwe3 command and the remote-ip ip-address pwe3 command prohibit a
device from distributing labels to remote peers.
l The remote-peer pwe3 command takes effect on all remote peers.
l The remote-ip ip-address pwe3 command takes effect on a specified remote peer.
By default, a device is permitted to distribute labels to all remote peers.
When a remote LDP session needs to be configured, it is commended that the remote-peer
pwe3 command or the remote-ip ip-address pwe3 command be used to prohibit a device
from distributing labels to remote peers, ensuring the system performance.
# Prohibit a device from distributing labels to all remote peers.
[HUAWEI-mpls] mpls ldp
[HUAWEI-mpls-ldp] remote-peer pwe3
Warning: The modification has impact on all remote peers including the existing
ones. Continue? [Y/N] y
# Prohibit a device from distributing labels to a remote peer with the IP address being
1.1.1.1/32.
[HUAWEI] mpls ldp remote-peer rtc
[HUAWEI-mpls-ldp-remote-rtc] remote-ip 1.1.1.1 pwe3
[HUAWEI-mpls-ldp-remote-rtc]
NOTE
The remote-peer pwe3 command and the remote-ip ip-address pwe3 command are inapplicable to the
LDP over TE networking.
The remote-peer pwe3 command prohibits a device from distributing labels to remote peers,
which is applicable to networks where a large number of remote peers exist but LDP over TE
is not deployed. If LDP over TE is deployed, do not use this command.
The remote-peer pwe3 command is applicable to any of the following situations:
On networks where a large number of remote peers exist but LDP over TE is not deployed, it
is useless to distribute labels to remote peers. In addition, distributing labels to remote peers
will use a large number of labels and memory resources, and will cause LDP LSPs to fail to
be established on devices with small label spaces due to shortage of labels, thus affecting LDP
services.
The performance of the HUAWEI NetEngine40E/80E is high, on which the preceding
problems seldom occur. On networks where more than 500 remote peers exist and LDP over
TE is not deployed, it is recommended that the remote-peer pwe3 command or the remote-ip
ip-address pwe3 command, however, be used to prohibit an HUAWEI NetEngine40E/80E
from distributing labels to remote peers.

NOTE
The remote-peer pwe3 command is irrelevant to L2VPN services and does not affect L2VPN labels or
local peers.
7.9.1.64 What Are Functions of the lsp-trigger { all | host | ip-prefix ip-prefix-
name | none } Command?
A: The parameter description is as follows:
l all: indicates that all static routes and IGP routes trigger the establishment of an LSP.
l host: indicates that 32-bit IP routes trigger the establishment of an LSP.
l ip-prefix ip-prefix-name: specifies the name of the IP prefix list that triggers the
establishment of an LSP. The value is a string of 1 to 169 characters without spaces,
when quotation marks are used around the string, spaces are allowed in the string.
l none: indicates that the establishment of an ingress LSP or an egress LSP is not
triggered.
The lsp-trigger command sets the policies for triggering the establishment of ingress LSPs
and egress LSPs. IP routes to 32-bit addresses or IGP routes filtered by an IP address prefix
list can trigger the establishment of LSPs. IGP routes denied by the IP address prefix list
cannot trigger the establishment of LSPs.
The undo lsp-trigger command restores the default settings.
By default, the 32-bit IP routes trigger the establishment of LSPs.
The lsp-trigger command takes effect only on ingress and egress LSPs. To configure policies
for triggering the establishment of transit LSPs, you can run the propagate mapping
command in the MPLS LDP view.
Both the lsp-trigger command and the lsp-trigger bgp-label-route command can be used to
configure policies for triggering the establishment of LDP LSPs. The first command is
associated with static routes and IGP routes, and the second command is associated with
labeled BGP routes of public networks.
Modifying an LSP-triggering policy during the LDP GR process is invalid.
7.9.1.65 What Are Functions of the propagate mapping Command?

The answer is as follows:
l The functions of the propagate mapping for ip-prefix command are as follows:
The propagate mapping for ip-prefix command filters received routes using an IP
prefix list. The routes that match addresses in the prefix list are used by LDP to establish
a transit LSP.
The undo propagate mapping for ip-prefix command restores the default
configuration.
By default, LDP uses the received routes without filtering them to set up transit LSPs.
l The functions of the propagate mapping for ip-prefix for bgp-route command are as
follows:
The propagate mapping for ip-prefix for bgp-route command enables a device to
distribute labels bound to BGP routes to establish transit LSPs.
The undo propagate mapping for ip-prefix for bgp-route command restores the
default configuration.

By default, the LDP module does not set up transit LSPs for BGP routes.
After the propagate mapping for ip-prefix for bgp-route command is run, a device
creates transit LSPs for all received BGP routes. Therefore, the token resources may be
insufficient.
7.9.1.66 How to Configure RDs of Two Devices, to Which a CE is Dual-Homed, to

Enable an Automatic Service Failover If a Failure Occurs?
When a CE is dual-homed to two devices, the two devices must be configured with different
RDs, therefore enabling an automatic service failover if a failure occurs.
7.9.1.67 Is MPLS Forwarding Supported After a CPOS Interface is Encapsulated

with FR?
After being encapsulated with FR, a CPOS interface supports MPLS forwarding. The main
interface does not support FR encapsulation.
7.9.1.68 How to Allocate Labels to a Penultimate Hop After the label advertise
non-null Command Has Been Configured in the MPLS View on the Egress?
Run the reset mpls ldp command in the user view on the egress of a specified LDP LSP
without configuring peer peer-id, therefore enabling the egress to allocate a label to the
penultimate hop.
7.9.1.69 Which Routes Can Iterate to LSPs After the route recursive-lookup
tunnel Command Has Been Configured?
Static routes and BGP routes can iterate to LSPs. IGP routes, however, do not iterate to LSPs
because IGP routes do not need to.
Using the route recursive-lookup tunnel command, you can configure the unlabeled routes
of a public network to iterate to LSPs. By default, the unlabeled routes can iterate to only an
outbound interface and the next hop instead of LSPs.
7.9.1.70 Q: Why the Size of MPLS L2VPN Packets Sent by a PE Is Different from
That in Port Queue Statistics?
A: The display port-queue statistics command displays statistics about packets sent by the
TM chip on an LPU. In addition to the TM chip, packets also pass through a PIC and the NP
chip for additional processing and encapsulation. As a result, the packet size changes.
In statistics collected by the TM chip, packets contain 12-byte frame headers that were added
on the SFU. After the packets arrive at the NP chip, these frame headers are removed. In
addition, if L2VC packets are transmitted, private labels are added, which also changes the
packet size.
7.9.2 TE

7.9.2.1 What Are the Advantages of MPLS TE Against the Ordinary MPLS?
The advantages of MPLS TE are as follows:
l Providing a wide range of attributes, including bandwidth assurance, explicit path,
affinity attribute, priority and preemption, and Make-before-break.
l Providing numerous applications, including backup tunnel, fast re-route, tunnel re-
optimization, automatic bandwidth adjustment, IGP Short-cut, and forwarding adjacency.
l Enabling operators to deliver more diverse services and to better meet users'
requirements.
l Supporting multiple information advertising protocols, including OSPF TE extension
and IS-IS TE extension; supporting multiple MPLS TE signaling protocols, including
RSVP-TE and CR-LDP; supporting MPLS TE tunnel establishment through static
configuration. The HUAWEI NetEngine40E/80E provides comprehensive MPLS TE
solutions.
7.9.2.2 What Is the Role of CSPF in the TE Architecture?

Constraint Shortest Path First (CSPF) is a path selecting component in MPLS TE.
The pre-requisites for CSPF are as follows:
l The constraint conditions of an LSP to be established, such as bandwidth, affinity,
preemption/hold priority, and explicit path
l Traffic Engineering Database (TEDB)
Based on the requirements of the LSP, CSPF prunes the links that do not meet the
requirements of TE attributes from the TEDB, and then finds a shortest path to the egress of
the LSP by using the Shortest Path First (SPF) algorithm.
7.9.2.3 Why is RSVP Called a Soft State?

For an RSVP-enabled network, a soft state refers to a state in routers and end nodes that can
be updated by certain RSVP messages.
RSVP takes a "soft state" approach to managing the reservation state in routers and hosts.
RSVP soft state is created and periodically refreshed by Path and Resv messages. The local
state of an LSP is deleted if no matching refresh messages arrive before the expiration of a
"cleanup timeout" interval. The local state of an LSP may also be deleted by an explicit
"teardown" message. At the expiration of each "refresh timeout" period and after a state
change, RSVP scans its state to build and forward Path and Resv refresh messages to
succeeding hops.
7.9.2.4 How Many Types of RSVP-TE Messages Are There?

RSVP-TE messages include the Path message, Resv message, PathErr message, ResvErr
message, PathTear message, ResvTear message, ResvConf message, Hello message, ACK
message, Srefresh message, GRPath message and RecoveryPath message.
l Path message: An RSVP path message is sent downstream by each sender along the
routes data packets are forwarded. A path message stores the path state in each node.
l Resv message: Resv message is used to reserve resources on each node. A Resv message
carries the resource reservation information for which the sender applies. It is sent in the
direction opposite to the direction of data traffic. On each node of the CR-LSP, a

Reserved State Block (RSB) is created, and the Resv message records information about
the allocated labels.
l PathTear message: PathTear messages remove (tear down) path states as well as
dependent reservation states in any nodes along a path. PathTear messages follow the
same path as Path messages.
l ResvTear message: ResvTear messages remove reservation states along a path. ResvTear
messages are transmitted upstream toward senders.
l PathErr message: When path errors occur, the node processing Path messages sends a
PathErr message to the sender that issued the Path message. PathErr messages only
report path errors to the sender, and do not alter any path state along the way.
l ResvErr message: When a reservation request fails to be processed or is damaged
because of preemption, a ResvErr message is delivered to all the downstream receivers
involved.
l ResvConf message: This message is sent to downstream devices hop by hop by the
sender to confirm the resource reservation requests.
The RSVP TE extension adds new objects to the Path and Resv messages. These objects can
carry Label binding messages and the constraint messages during the routing for the LSR
along the path. Therefore, RSVP TE supports both the Constraint-Based Routing (CR)
function and fast reroute (FRR) function.
7.9.2.5 What Does Make-before-break Mean?

One of the TE requirements is that the established tunnel be rerouted to meet certain
constraints. For example, when a better route exists or the tunnel resource is insufficient, a
new path must be set up to switch the traffic. Make-before-break is a mechanism which sets
up a new path before deleting the original path. This ensures that data is not lost when the
traffic is switched, without additional bandwidth consumption.
When a new CR-LSP is being established, it may compete with the original path on the
shared link for the bandwidth. If the new path fails in the bandwidth contention, it cannot be
established. Through the make-before-break mechanism, the system does not need to
calculate the bandwidth reserved for the new path. That is, the new path uses the bandwidth of
the original path.
A similar measure is increasing the tunnel bandwidth. If the reservable bandwidth of the
shared link meets the increased bandwidth requirements, a path can be established.
Figure 7-25 Schematic diagram of Make-before-break

60Mbit/s 60Mbit/s 60Mbit/s
R1 R2 R3 R4
60Mbit/s 60Mbit/s
R5
As shown in Figure 7-25, it is presumed that a path from R1 to R4 needs to be established.

The reservable bandwidth is 30 Mbit/s, and the path previously established is R1-R2-R3-R4.

You may expect to increase the bandwidth to 40 Mbit/s and forward data through R5, on
which the traffic load is relatively light. The available reservable bandwidth on R3-R4 is 30
Mbit/s, which cannot meet the requirement for the total bandwidth. But the incremental
requirement of 10 Mbit/s can be met by using the make-before-break mechanism.
Through the make-before-break mechanism, the newly established path R1-R5-R3-R4 uses
the bandwidth of the original path R3-R4 and adds the incremental bandwidth. After the new
path is established, the original path is deleted after traffic is switched to the new path.
7.9.2.6 Types of FRR Protection

Two types of FRR with different protected objects are available.
l Link protection: Direct link exists between the PLR and the MP, and the primary LSP
tunnel passes through this link. When this link fails, the traffic can be switched to the
bypass LSP. As shown in Figure 7-26, the primary LSP is R1→R2→R3→R4, and the
bypass LSP is R2→R6→R3.
Figure 7-26 Schematic diagram of FRR link protection
PLR MP
R1 R2 R3 R4
Primary LSP
Bypass LSP
R6
l Node protection: As shown in the following figure, the PLR and the MP are connected
through R3. The primary LSP passes through R3. When R3 fails, the traffic can be
switched to the bypass LSP. In Figure 7-27, the primary LSP is R1→R2→R3→R4→R5;
the bypass LSP is R2→R6→R4; R3 is the protected node.
Figure 7-27 Schematic diagram of FRR node protection

PLR MP
R1 R2 R3 R4 R5
Primary LSP
Bypass LSP
R6

7.9.2.7 CR-LSP Backup Modes

An LSP providing path backup for the primary LSP in the same tunnel is called a backup
path. When the Ingress detects that the primary LSP is unavailable, it switches traffic to the
backup path. After the primary LSP recovers, traffic is switched back to the primary LSP. In
this manner, traffic on the primary LSP is protected.
Two types of backup are available.
l Hot-standby: A primary CR-LSP and a backup CR-LSP is established in sequence. Both

the primary CR-LSP and backup CR-LSP can be established. If the primary CR-LSP
fails, MPLS TE switches traffic immediately to the backup CR-LSP.
l Ordinary and Best-effort: The backup CR-LSP is set up when the primary CR-LSP fails.
7.9.2.8 Differences Between CR-LSP Backup and TE FRR

CR-LSP backup is a type of end-to-end path protection, providing protection for the entire
LSP.
FRR provides local protection. It protects only a certain link or a certain node in the LSP.
Besides, FRR is a temporary protection policy that can respond quickly. It has a strict
requirement on switching time, whereas CR-LSP backup does not.
The CR-LSP backup is often used together with FRR. FRR can rapidly respond to the fault on
a link or node and can switch traffic to the bypass tunnel within the shortest period.
Information about the link fault is sent to the Ingress through signaling, and then the traffic is
switched to the backup CR-LSP.
7.9.2.9 How to Verify Results of the CSPF Route Calculation?

You can run the display mpls te cspf destination command to check the results of the CSPF
route calculation.
If the CSPF route calculation is correct, the command output is as follows:

<HUAWEI> display mpls te cspf destination 3.3.3.3 explicit-path path_a
Path for the given constraints is:
2.2.3.2 Include
2.2.3.3 Include
The total metrics of the calculated path is : 1
If the CSPF route calculation is incorrect, check whether every router is correctly configured.
Ensure that the status of the links that the explicit path passes is correct, and that the reserved
bandwidth is sufficient.
7.9.2.10 In MPLS TE, How to Judge Whether Loops Are Formed?

When the mpls te record-route command or the mpls te record-route label command is
configured on a tunnel, loops are often detected, and the following log is displayed.
Apr 17 2007 15:41:32 TEFRR_08 %%01RSVP/3/LOOP_PATH(l): There is a loop in PATH
message(Tunnel ID=1,Egress Address=8.8.8.8).
The preceding log indicates that there are identical IP addresses on the LSRs that the tunnel
passes. In this case, check the configurations and change the identical IP addresses on the
LSRs. Then, the tunnel can be properly established.

7.9.2.11 Why Does RSVP Authentication Fail?

The RSVP authentication between two LSRs may fail for two reasons. One is that the
authentication keys on the two LSRs are not the same; the other is that only one LSR is
configured with RSVP authentication.
7.9.2.12 Why Does an RSVP Message Time Out?

Path and Resv message time out for many reasons. The following example explains one of the
reasons.
Figure 7-28 Schematic diagram of MPLS TE-enabled network
LSRA LSRB LSRC LSRD
As shown in the preceding figure, a TE tunnel from LSR A to LSR C is configured. After the
tunnel becomes Up, RSVP authentication is enabled on LSR A, but not on LSR B. As a
result, RSVP messages between LSR A and LSR B are all discarded because the RSVP
authentication fails. Consequently, Path messages time out on one end of the tunnel, whereas
Resv messages times out on the other end of the tunnel.
7.9.2.13 How to Determine Whether the Destination Address of a Tunnel Is

Reachable or Not?
You can run the ping command to determine whether the destination address of a tunnel is
reachable or not.
<HUAWEI> ping 5.5.5.5
0.00% packet loss
You can also run the tracert command to determine whether the destination address of a
tunnel is reachable or not.
<HUAWEI> tracert 5.5.5.5
traceroute to 5.5.5.5(5.5.5.5) 30 hops max,40 bytes packet
1 10.5.7.5 4 ms 4 ms 4 ms

7.9.2.14 What Is the Relationship Between the Destination Address of a Tunnel

and the IP Address of a Loopback Interface?
If the destination address of a tunnel is the IP address of the loopback interface on the egress
node, the IP address of the loopback interface must be the MPLS LSR-ID. Otherwise, the
tunnel cannot become Up. This is because MPLS TE is not enabled on the loopback interface.
Therefore, if the destination address of a tunnel is the IP address of the loopback interface on
the egress node, the IP address of the loopback interface must be the MPLS LSR-ID.
7.9.2.15 How to Check the Path of a Tunnel?

In the tunnel view, run the mpls te record-route command. Then, run the display mpls te
tunnel path command, and the link address of the path of the tunnel is displayed.
7.9.2.16 How Can a TE Tunnel Participate in Route Calculation?

After a CR-LSP is established by using a tunnel, three methods are available for allowing a
TE tunnel to participate in route calculation.
l Using static routes
By running the following command, all traffic bound for 10.0.0.0/8 is diverted to Tunnel
1/0/0.
ip route-static 10.0.0.0 8 tunnel1/0/0
l Policy-based routing: using the re-direction function to forward the specified traffic
through the TE tunnel
l Automatic route calculation: IGP Shortcut and Forwarding adjacency
– The IGP Shortcut mode is enabled on only the ingress of a TE tunnel for route
calculation, and does not affect the IGP route calculation by the other LSRs.
– The Forwarding adjacency mode advertises a TE tunnel as a virtual link to the other
LSRs, and affects the IGP route calculation by all the other LSRs in the same AS as
the advertiser.
7.9.2.17 Why Does the TE Tunnel Fail to Be Set Up Although the LSP is
Successfully Calculated by the CSPF?
The TEDB, which results from the IGP TE flooding, does not contain all information about
TE. For example, the TEDB does not contain information on whether the TE signaling
protocol should be enabled on some links or which interface is enabled with signaling
protocols such as the RSVP TE. After the IGP TE extension and CSPF calculation, if the
signaling for setting up a CR-LSP reaches an LSR with no signaling protocol enabled, the
CR-LSP cannot be set up.
In addition, the bandwidths reserved for a link during the CSPF route calculation may be
adequate, but after the CSPF route calculation, bandwidth resources on the link change when
the signaling protocol reserves resources for the link, (for example, the available bandwidth
previously calculated has been preempted by a newly established CR-LSP). In this situation,
the tunnel also fails to be set up.

7.9.2.18 Of the Equal-cost TE Links, the Link with the Maximum Reservable
Bandwidth is Selected in CSPF Calculation Although tie-breaking Is Set to most-
fill. Why?
In CSPF calculation, if several equal-cost TE tunnel paths are available, CSPF will select the
path based on the tie-breaking rule. This rule determines the path election according to the
percentage of the used reservalble bandwidth to the maximum reservable bandwidth, not the
reservable bandwidth remaining on the path.
7.9.2.19 For TE Tunnel Re-optimization, What Are the Criteria Determining

Whether the Re-optimization Path Is a Better One?
On HUAWEI NetEngine40E/80E, for TE Tunnel re-optimization, the metric is first
compared, followed by the number of hops, and finally the bandwidth.
7.9.2.20 RSVP-TE Is Enabled on Both Ends of a Link. But Running the display
mpls rsvp-te peer Command Displays no Information About the RSVP Peer.
Why?
On HUAWEI NetEngine40E/80E,running the display mpls rsvp-te peer command displays
information about the RSVP peer only if the TE LSP has been successfully established.
7.9.2.21 What Is the Typical Application of the LDP over TE Tunnel Feature?
The LDP over TE Tunnel feature mainly applies to a network where TE is supported only by
devices at the core of the network rather than being supported by all devices on the network.
That is, the TE tunnel serves as the "next hop" of the entire LDP LSP.
The following is an example for the application of the LDP over TE Tunnel feature.
Figure 7-29 LDP over TE Tunnel
MPLS TE
domain
LSRA LSRB LSRC LSRD
7.9.2.22 How Are TE Tunnels Used in Inter-AS BGP/MPLS IP VPN Forwarding

and Inter-AS VPWS Forwarding?
TE tunnels are not used for the propagation of routes and VPN labels. Instead, TE tunnels are
used for only traffic forwarding.
In the case of EBGP mode of inter-AS ASBRs, TE tunnels can be set up only between PEs
and ASBRs in an AS to function as part of the BGP LSP that is used to forward traffic
between PEs in different ASs.
In the case of Multi-hop EBGP mode of inter-AS PEs, inter-AS TEs can be directly
established between PEs in different ASs to forward traffic.

In the current HUAWEI NetEngine40E/80E implementation, ASBRs cannot connect a TE

tunnel to LSPs of the other types to form a BGP LSP that is used to forward traffic between
PEs in different ASs.
l TE tunnels in inter-AS BGP/MPLS IP VPN

– Inter-AS Option B
TE tunnels are set up between PEs and ASBRs in an AS to forward traffic.
– Inter-AS Option C
n Inter-AS TE tunnels are set up between PEs in different ASs to forward traffic.
n TE tunnels are set up between PEs and ASBRs in an AS to function as part of
the BGP LSP that is used to forward traffic between PEs in different ASs
(currently not supported by the HUAWEI NetEngine40E/80E).
– C&C
n Inter-AS TE tunnels are set up between PEs in different ASs to forward traffic.
n TE tunnels are set up in ASs of different operators to function as part of the
BGP LSP that is used to forward traffic between PEs in different ASs.
n C&C LDP multi-instance mode
○ PE-to-PE TE tunnels are set up in an AS of a provider carrier's network to
forward traffic.
○ PE-to-ASBR TE tunnels are set up in an AS of a customer carrier's
network to forward traffic (not supported by the current version).
n C&C EBGP
○ PE-to-PE TE tunnels are set up in an AS of a provider carrier's network to
forward traffic.
○ PE-to-ASBR TE tunnels are set up in an AS of a customer carrier's
network to forward traffic (not supported by the current HUAWEI
NetEngine40E/80E version).
l TE tunnels in inter-AS VPWS forwarding
– Inter-AS TE tunnels are set up between PEs in different ASs to forward traffic.
n Applications of TE tunnels in inter-AS Martini VPWS where PEs propagate
L2VPN labels through Multi-hop EBGP
n Applications of TE tunnels in inter-AS Kompella VPWS where PEs propagate
L2VPN labels through Multi-hop EBGP
n Applications of TE tunnels in inter-AS Kompella VPWS where ASBRs
propagate L2VPN labels through EBGP
– TE tunnels are set up between PEs and ASBRs in an AS to function as part of the
BGP LSP that is used to forward traffic between PEs in different ASs (HUAWEI
NetEngine40E/80E does not supports currently).
Applications of TE tunnels in inter-AS Kompella VPWS where ASBRs propagate
L2VPN labels through EBGP.
7.9.2.23 How to View the Basic Attributes of a Tunnel?

You can view the basic attributes of a tunnel by running the display mpls te tunnel-interface
[ tunnel interface-number | auto-bypass-tunnel tunnel-name ] [ | count ] [ | { begin | include
| exclude } regular-expression ] command.

The preceding command displays all the configurations of a tunnel. The auto-bypass-tunnel
parameter displays detailed information about auto-bypass. By running the command, you can
view information about the status machine.
When updating the tunnel attributes, you can run the preceding command to view information
about the tunnel.
l The break-before-make mechanism is adopted to modify the key attributes (for example,
the destination address, priority, signaling, and class of service) of a tunnel. The tunnel is
first deleted, and then re-established; no Modify nodes are created. In this case, running
the preceding command displays the information only about the modification of the
primary tunnel.
l The make-before-break mechanism is adopted to modify the non-key attributes (for
example, the explicit path and route pinning) of a tunnel. A Modify node is created, and
then a tunnel is set up on the Modify node. After the new LSP is set up, traffic is
switched to the new LSP and then the original LSP is deleted. In this case, running the
preceding command shows the Manual information about both Primary and Modify.
7.9.2.24 How to View the Actual Path of a Tunnel and the Binding of FRR?
You can run the display mpls te tunnel path command to view the actual path (ARHOP) of a
tunnel and the binding of FRR.
7.9.2.25 How to View Information About the Allocation of Link Bandwidth?

You can run the display mpls te link-administration bandwidth-allocation command to
view information about the allocation of link bandwidth.
7.9.2.26 How to View Information About an LSP?

You can run the display mpls lsp verbose command to view information about an LSP.
7.9.2.27 How to View Information About PSB and RSB?

You can run the display mpls rsvp-te psb-content and display mpls rsvp-te rsb-content
commands to view information about PSB and RSB respectively.
PSB information is sent from the upstream device during the path establishment and is
forwarded through Path messages. RSB information keeps the information that is forwarded
through Resv messages.
7.9.2.28 What Are the Functions of RSVP Route Pinning?

Route pinning is applicable only to the ingress. By copying the RRO to the ERO, the ingress
keeps a route unchanged. Route pinning takes effect only on existing LSPs. After a tunnel is
reset, the RRO is deleted. Then, routes of subsequent LSPs become changeable.
Route pinning takes effect only when CSPF is not configured. When CSPF is not configured,
if IGP routes or static routes change, LSPs will change accordingly.
When CSPF is not configured and route pinning is configured, LSPs will not change after a
route change.

7.9.2.29 Why Is Not TE-IGP Synchronization Designed?

The reasons are as follows:
l Establishing a TE tunnel is seldom affected by IGP convergence.
During the establishment of a tunnel, a device send RSVP signaling messages based on
the IGP routes. After these messages are received and handled, the tunnel is then
established.
If IGP is not enabled, a tunnel can also be established along a strictly explicit path (as
routes of directly-connected links are obtained without IGP).
l In addition, the maintenance of a TE tunnel is separate from IGP.
When CSPF and IGP are enabled, the CSPF module adds IGP-calculated route
information to the Chop object and then sends it to the TE module. After obtaining the
object, the TE object generates EROs (which describe IP addresses of nodes along an
entire tunnel).
EROs maintain the proper receiving and sending of RSVP signaling messages.
Therefore, the tunnel is still Up even if the destination route becomes unreachable after
IGP is deleted.
A tunnel goes Up and then Down in either of the following situations:
– A link goes Down. As a result, RSVP signaling messages cannot be sent or received
and the tunnel is torn down immediately.
– RSVP signaling messages cannot be properly sent or received, and a certain
message is dropped for more than three consecutive times. The tunnel will be
deleted because of timeout.
l In view of applications, TE-IGP synchronization is inconsequential.
The purpose for establishing a TE tunnel is to transmit traffic and traffic is forwarded
along an LSP based on labels. The tunnel continues to transmit traffic after being
established even if IGP is deleted, which means that its links are reachable and the
forwarding is not affected.
If TE-IGP synchronization is deployed, a tunnel may be deleted because of IGP. If IGP
fails but links are normal on a network, a tunnel is deleted because of TE-IGP
synchronization, causing traffic interruption. Such a design is opposite to the purpose of
design.
7.9.2.30 What Is the Meaning of an RSVP Neighbor Address?

An RSVP neighbor address is displayed in one of the following formats:
l It is displayed as a physical interface address, for example, 10.1.2.2.
l If "Neighbor Addr:-----" is displayed, it indicates that the associated RSVP neighbor
address is invalid and the PSB and RSVP are configured on a virtual interface with an
invalid address.
For example, the following information is displayed when the inbound interface to which
the PSB is attached on the ingress has an invalid address and thus PSB's neighbor
address is also invalid.
<HUAWEI> display mpls rsvp-te peer
Remote Node id Neighbor
Neighbor Addr: -----
SrcInstance: 0x8277E43C NbrSrcInstance: 0x0
PSB Count: 82 RSB Count: 0
Hello Type Sent: REQ Neighbor Hello Extension: DISABLE

SRefresh Enable: NO
Last valid seq # rcvd: NULL
Likewise, "Neighbor Addr:-----" is displayed when the neighbor address of an RSB

attached to the egress is invalid.
l If the device is in FRR Inuse state and the PSB and RSB are configured on a virtual
interface, the neighbor address is a peer LSP ID, for example, 2.2.2.2.
Figure 7-30 Networking diagram of RSVP neighbor

1.1.1.1/32 2.2.2.2/32 3.3.3.3/32
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.2.1/24 10.1.2.2/24 10.2.4.2/24 10.2.4.3/24
LSRA LSRC
GE2/0/0 LSRB GE2/0/0
10.1.4.1/24 10.1.4.3/24
Figure 7-30 shows the networking diagram.

– A primary tunnel named Tunnel 6/0/1 is set up along the path LSR A --> LSR B -->
LSR C.
– A bypass tunnel named Tunnel 6/0/100 is set up along the path LSR A --> LSR C.
When the primary tunnel named Tunnel 6/0/1 is not in FRR Inuse state, the neighbor
address is a physical interface address.
Display the peer status on LSR A. You can see that the neighbor address is displayed as a
physical interface address, for example, 10.1.2.2.
SRefresh Enable: NO
Interface GE1/0/0
Neighbor Addr: 10.1.2.2
Hello Type Sent: NONE Neighbor Hello Extension: DISABLE
SRefresh Enable: NO
Interface GE2/0/0
SRefresh Enable: NO
Display the peer status on LSR C. You can see that the neighbor address is displayed as a
physical interface address, for example, 10.2.4.2.


SRefresh Enable: NO
Interface GE1/0/0
SRefresh Enable: NO
Interface GE2/0/0
SRefresh Enable: NO
After the tunnel enters the FRR Inuse state, the neighbor address of the PSB and RSB
attached to the IfEntry on the virtual interface is a peer LSR ID.
The peer status is displayed on LSR A. You can see that the neighbor address is
displayed as a peer LSR ID, for example, 2.2.2.2.
SRefresh Enable: NO
Interface GE1/0/0
SRefresh Enable: NO
Interface GE2/0/0
SRefresh Enable: NO
7.9.2.31 Are There Any TE Sub-Features?

MPLS TE (Traffic Engineering) is short for Multiprotocol Label Switching Traffic
Engineering. MPLS TE establishes a TE tunnel with guaranteed bandwidth to forward labels
and ensure bandwidth. The MPLS TE technique provides the following features.

TE Sub-Feature Description
TE FRR (Fast TE fast reroute (FRR) is a local protection mechanism, protecting

Reroute) traffic on a primary TE tunnel against link or node failures.
In TE FRR, bypass tunnels are pre-established without using failed
links or nodes, thus protecting traffic of the primary tunnel. If the
link or node is defective on a primary tunnel, traffic is transmitted
along the bypass tunnel, and the ingress simultaneously initiates the
establishment of the primary tunnel without interrupting data
transmission.
The concepts associated with FRR are as follows:
l Primary tunnel: It is the tunnel whose traffic is protected.
l Bypass tunnel: It is the tunnel that protects traffic on the primary
tunnel. On a bypass tunnel, the point of local repair (PLR) is the
ingress and the merge point (MP) is the egress. The bypass
tunnel is usually in the idle state and does not transmit services.
If the bypass tunnel is required to take over service from the
primary tunnel while it is protecting traffic of the primary tunnel,
sufficient bandwidth needs to be allocated to the bypass tunnel.
l PLR: is short for point of local repair. A PLR is the ingress of a
bypass tunnel, which must be on the primary tunnel. The PLR
can be the ingress rather than the egress of the primary tunnel.
l MP: is short for merge point. An MP is the egress of a bypass
tunnel, which must be on the primary tunnel and cannot be the
ingress of the primary tunnel.
l Link protection: A PLR (LSR B) and an MP (LSR C) are
directly connected by a link, and a primary tunnel passes through
the link on a network shown in Figure 7-31. If this link fails,
traffic switches to the bypass tunnel.
Figure 7-31 Schematic diagram of FRR link protection

PLR MP
LSRA LSRB LSRC LSRD
Primary LSP
LSRE
Bypass LSP
l Node protection: A PLR (LSR A) and an MP (LSR C) are

connected by LSR B along a link LSR A -> LSR B -> LSR C,
and a primary tunnel passes through the link on a network shown
in Figure 7-32. If LSR B fails, traffic switches to the bypass
tunnel.

Figure 7-32 Networking diagram of FRR node protection

PLR MP
LSRA LSRB LSRC LSRD
LSRE

TE make-before- Make-before-break is a technique for ensuring high reliability of a

break switchover. Its principle is simple. When a new tunnel is to be
established, the previous tunnel will be deleted only after the new
tunnel has been established and traffic has switched to the new
tunnel, thus ensuring proper traffic transmission. This is a required
technique for ensuring high reliability of transmitting
telecommunication-level services.
Figure 7-33 Principles of the make-before-break mechanism

60Mbit/s 60Mbit/s 60Mbit/s
LSRA LSRB LSRC LSRD

60Mbit/s 60Mbit/s
LSRE
On a network shown in Figure 7-33, assume that the maximum

reservable bandwidth of all links is 60 Mbit/s. A CR-LSP along the
path LSRA-> LSRB -> LSRC -> LSRD is set up with the
bandwidth being 40 Mbit/s. The path is expected to change to
LSRA -> LSRE -> LSRC -> LSRD to forward data because LSRE
has a light load. The reservable bandwidth of the path from LSRC to
LSRD is only 20 Mbit/s. The total bandwidth cannot meet the
requirement for 40 Mbit/s. In this case, you can use the make-
before-break mechanism to solve the problem. Through the make-
before-break mechanism, the newly established path LSRA ->
LSRE -> LSRC -> LSRD uses the original bandwidth of the path
from LSRC to LSRD during resource reservation. After the new
CR-LSP is set up, traffic switches to the new CR-LSP, and then the
original CR-LSP is deleted.
The process of increasing the tunnel bandwidth is similar. If the
reservable bandwidth of the shared link increases to a certain extent,
a new CR-LSP can be established. On a network shown in Figure
7-33, assume that the maximum reservable bandwidth of all links is
60 Mbit/s. A CR-LSP along the path LSRA-> LSRB -> LSRC ->
LSRD is set up with the bandwidth being 30 Mbit/s. The bandwidth
is expected to be 40 Mbit/s. The reservable bandwidth of the path
from LSRC to LSRD is only 30 Mbit/s. The total bandwidth cannot
meet the requirement for 40 Mbit/s. In this case, you can use the
make-before-break mechanism to solve the problem. Through the
make-before-break mechanism, the newly established CR-LSP uses
the original bandwidth. After the new CR-LSP is set up, traffic
switches to the new CR-LSP, and then the original CR-LSP is
deleted.

Automatic By using automatic bandwidth adjustment, a system can

bandwidth dynamically detect traffic and then re-create a tunnel with required
adjustment bandwidth according to detection results.
The bandwidth of a tunnel can be manually set, for example, 50
kbit/s. Traffic on a tunnel is usually changeable. To ensure
continuity of traffic, you can reserve the bandwidth required by the
maximum amount of traffic. This meets the requirement of traffic
but wastes bandwidth resources. On communications networks,
bandwidth resources are valuable. Automatic bandwidth adjustment
is therefore developed, saving bandwidth.
The average bandwidth of a tunnel within a sampling period can be
obtained through regular sampling. After sampling for multiple
times in a period, you can calculate a new bandwidth according to
the average value of the sampled values and then establish a new
CR-LSP. After the CR-LSP is established, traffic switches to the
new CR-LSP, and the original CR-LSP is deleted. If the CR-LSP
fails to be established, traffic is still transmitted along the original
CR-LSP. The bandwidth will be adjusted after the next sampling
period.
You can also set the maximum bandwidth and minimum bandwidth,
ensuring that the bandwidth is adjusted within the range.

Re-optimization Automatic re-optimization means that the path of a CR-LSP is

recalculated at certain intervals. In this manner, the path of the CR-
LSP is optimized.
TE aims at optimizing the distribution of traffic over a network.
After a CR-LSP is established, the path of the CR-LSP can be re-
optimized according to the changed bandwidth, traffic, or
management policy on a network. A CR-LSP is optimized after a
better path is found. The CR-LSP is re-established when a better
path with a smaller metric, fewer hops, and other required
conditions exists. CR-LSP re-optimization is performed in either of
the following modes:
l Automatic re-optimization: You can specify an interval at which
a CR-LSP is optimized. After the interval expires, the CR-LSP
automatically finds for a better path to perform re-optimization.
l Manual re-optimization: You can run a command line to trigger
CR-LSP re-optimization and request the system to recalculate a
better path to set up a CR-LSP.
When CR-LSP re-optimization is in process, traffic must be
uninterrupted. Traffic must switch to the new CR-LSP before the
original CR-LSP is torn down. On a link shared by the new and the
original CR-LSPs, the bandwidth used by the original CR-LSP
cannot be released before the new CR-LSP is established.
Therefore, if the bandwidth on the shared link is calculated twice,
the new LSP may not be established because of scarce resource.
The RSVP-TE shared explicit (SE) reservation style can prevent this
problem. The SE style allows the original and new CR-LSPs to
share bandwidth resources; therefore, the new CR-LSP can be set up
before the original CR-LSP is torn down.

TE LSP backup On one tunnel, a CR-LSP that is used to protect traffic of a primary
CR-LSP is called a backup CR-LSP.
The backup CR-LSP protects traffic of key CR-LSPs. CR-LSP
backup plays an important role in traffic protection. If a primary
CR-LSP fails, traffic can switch to a backup CR-LSP.
When the ingress detects that the primary CR-LSP is unavailable, it
switches traffic to the backup CR-LSP. After the primary CR-LSP
recovers from the fault, traffic switches back. In this manner, traffic
on the primary CR-LSP is protected.
CR-LSP backup is performed in either the following modes: hot-
standby or ordinary backup. A Hot-standby CR-LSP supports a
best-effort path.
l Hot-standby: A backup CR-LSP is set up immediately after a
primary CR-LSP is set up. If the primary CR-LSP fails, traffic
switches to the backup CR-LSP. After the primary CR-LSP
recovers, traffic switches back to the primary CR-LSP.
l Ordinary and Best-effort: A backup CR-LSP is set up after a
primary CR-LSP fails. If the primary CR-LSP fails, traffic
switches to the backup CR-LSP. After the primary CR-LSP
recovers, traffic switches back to the primary CR-LSP.

TE tunnel A TE protection group is applicable to networks requiring high

protection group performance. After a protection tunnel is reserved, transmission of
data traffic can be quickly restored on a backup tunnel after a
primary tunnel fails.
A primary tunnel and a backup tunnel are pre-established and then
the backup tunnel is specified as a protection tunnel for the primary
tunnel. The primary tunnel and the backup tunnel work together,
forming a protection group.
You can separately configure the attributes of a bypass tunnel,
which will facilitate the planning of a network. The concepts
associated with the tunnel protection group are as follows:
l Primary tunnel: It is the tunnel whose traffic is protected.
l Protection tunnel: It is the tunnel that protects traffic of a
primary tunnel.
l Protection switchover: In a tunnel protection group, if a primary
tunnel fails, data traffic swiftly switches to a backup tunnel,
which enhances reliability of a network.
– 1:1 mode: One primary tunnel and one backup tunnel are set
up between an ingress and an egress. Normally, data is
transmitted along the primary tunnel. If the ingress detects a
failure on the primary tunnel using a detection mechanism,
protection switching is performed and the ingress switches
data to the backup tunnel.
– N:1 mode: A tunnel functions as a backup tunnel for multiple
primary tunnels. If any primary tunnel fails, data switches to
the shared backup tunnel. This saves bandwidth on a full-
meshed network, as shown in Figure 7-34.
Figure 7-34 Networking diagram of 1:1 protection mode
Working tunnel-1
LSRA Working tunnel-2
Protection tunnel-3
Data flo
tun
Data flo
tun

BFD for TE BFD for TE is an end-to-end fast detection mechanism applicable to

MPLS TE. BFD for TE is used to fast detect failures along the links
of an MPLS TE tunnel.
The traditional detection mechanisms detect faults at low speeds.
BFD uses the fast packet transmission mode and quickly detects
failures on MPLS TE tunnels, which triggers a fast switchover for
service protection.
Figure 7-35 Schematic diagram of BFD
LSRB LSRD
LSRA L
LSRC LSRE
On a network shown in Figure 7-35, a Layer 2 switch exists

between LSR C and LSR E. Without BFD, if LSR E fails, LSR A
and LSR F cannot detect the failure in time due to the Layer 2
switch. The Hello mechanism then performs detection, whereas
detection will last for a long time.
After BFD is enabled on LSR A, LSR B, LSR C, LSR D, LSR E,
and LSR F, if LSR E fails, LSR A and LSR F can detect the failure
within a short period, and then traffic switches to the path LSR A ->
LSR B -> LSR D -> LSR F.BFD for TE can rapidly detect a failure
on a CR-LSP and notifies the forwarding plane, implementing a fast
traffic switchover. Usually, BFD for TE is deployed together with
Hot-standby or a tunnel protection group.
The concepts associated with BFD are as follows:
l Static BFD session: Both the local discriminator and remote
discriminator are specified manually. In addition, the local and
remote discriminators at an end must match those at the other
end of a BFD session. Otherwise, no BFD session is set up.
After a BFD session is set up, the interval at which BFD packets
are sent and received is changeable.
l Dynamic BFD session: The local discriminator and remote
discriminator do not need to be manually specified. After a
neighbor relationship is set up by using a routing protocol, the
routing management (RM) module distributes parameters to
instruct the BFD module to set up a BFD session. The local

discriminator, remote discriminator, and intervals at which BFD

packets are sent and received are obtained through negotiations.
l Detection period: indicates the interval at which the system
detects whether a BFD session is Up. If no BFD packet is
received from the remote end within a detection period, the BFD
session is considered Down.
BFD for tunnel BFD detects the communication failures between forwarding
engines. To be specific, BFD detects connectivity of a data protocol
that is running on a path between two systems. The path can be
either a physical link or a logical link, including a TE tunnel.
When the BFD session is detecting an entire TE tunnel, Virtual
Private Network (VPN) FRR is triggered to quickly switch traffic if
a primary TE tunnel is defective, minimizing impacts on services.
In the VPN FRR scenario, a TE tunnel is set up between provider
edge (PE) devices and the BFD mechanism is used to detect traffic
along this tunnel. If the BFD mechanism detects a failure on the TE
tunnel, VPN FRR switches traffic in milliseconds.
RSVP In RSVP authentication, authentication objects are added to RSVP

authentication messages and verified to prevent RSVP messages from being
modified or forged. In this manner, malicious attacks by using
RSVP messages are prevented. In addition, reliability and security
of a network are enhanced.
To prevent an unauthorized remote LSR from setting up a neighbor
relationship with a device or attacking a device (such as maliciously
reserving a large amount of bandwidth) by constructing forged
RSVP messages and then setting up an RSVP neighbor relationship,
you can configure RSVP authentication. RSVP authentication is
performed on the basis of authentication keys.
RSVP Message Digest 5 (MD5) authentication, however, cannot
prevent anti-replay attacks or prevent the problem of neighbor
relationship termination resulted from RSVP message missequence.
To prevent these problems, RSVP authentication extensions are
introduced. In the RSVP authentication extension, the functions of
authentication lifetime, handshake, and message window are added
on the basis of the original authentication. The authentication
extension improves security and enhances user authentication in a
harsh network environment, such as network congestion.
To avoid unceasing RSVP authentication, you can configure RSVP
authentication lifetime. RSVP neighbors then can retain a neighbor
relationship though no CR-LSP exists between them till RSVP
authentication lifetime expires.

RSVP GR RSVP graceful restart (GR) is a status recovery mechanism

applicable to RSVP-TE. RSVP-TE GR is designed to ensure non-
stop forwarding (NSF). If a failure occurs on the control plane of a
device, the upstream and downstream neighbors send messages to
restore the RSVP soft state, whereas the forwarding plane does not
sense the failure and is not affected by the failure. In this manner,
traffic is transmitted stably and reliably.
RSVP GR detects the GR status of neighbors by using the enhanced
Hello feature. On a network show in Figure 7-36, after a faulty
Restarter is being restarted, the Restarter stops sending Hello
messages to its neighbors. After failing to receiving Hello messages
for three consecutive times, the GR-enabled neighbors consider that
the Restarter enters the GR process. Then, all forwarding
information is retained, and LPUs on Helpers keep transmitting
services, and the neighbors are waiting for the Restarter to restore
forwarding information.
After the Restarter is restarted, if it receives Hello messages from its
neighbor, it will send Hello messages to the neighbor. The modes
for processing Hello messages are different on the upstream and
downstream nodes.
l If an upstream Helper receives a Hello message, it will send a
GR Path message downstream to the Restarter.
l If a downstream node receives a Hello message, it will send a
Recovery Path message upstream to the Restarter.
Figure 7-36 Networking diagram of restoring the GR status by

using GR Path and Recovery Path messages
Upstream Downstream
Hello Hello
Support GR Path Recovery Path Support

Restart
After the Restarter receives the Path message and the Recovery Path
message, the PSB restores the CR-LSP according to these two
messages. In this manner, information about the CR-LSP on the
local control plane is restored.
If a downstream Helper cannot send the Recovery Path message, the
local status is restored only by using the GR Path message.

RSVP Srefresh In the case that an entire RSVP Refresh message does not need to be
sent, the system only sends an RSVP summary, a small part of a
Refresh message, to maintain the RSVP soft state and respond to an
RSVP soft state change or a route change.
Each RSVP session generates, sends, receives, and handles RSVP
Path and Resv messages within a refresh period. With the increasing
number of RSVP sessions, a large number of Refresh messages
need to be exchanged to maintain the soft state; if a non-Refresh
message is discarded during transmission, reliability may be
affected and a delay may occur. Srefresh can prevent the preceding
problem. It reduces the number of Refresh messages and improves
reliability of RSVP message transmission and resource usage.
l Trigger messages and refresh messages
RSVP messages are classified into trigger messages and refresh
messages. Trigger messages are the RSVP messages that are sent
for the first time to advertise the status and other information.
Trigger messages can be messages indicating the new status, a
route change associated with a reserved path, a change of an
existing RSVP session, a reservation change, or a change of a
non-RSVP object.
Refresh messages describe the status that has been advertised.
Refresh messages contain the same objects and information as
the previous sent trigger messages, and are transmitted along the
same path. Refresh messages can be either Path messages or
Resv messages.
l Message_ID extension
Message_ID objects are extended, supporting verification and
reliable transmission of RSVP messages. A Message_ID object
can identify a refresh message. After a node receives a refresh
message, using information in the refresh message simplifies the
processing of refresh messages.
l Srefresh extension
A Srefresh message is extended. Srefresh messages contain
multiple Message_IDs. Each Message_ID represents an RSVP
refresh message. A sender can refresh the RSVP status by
transmitting only Srefresh messages rather than standard RSVP
Path or Resv messages. After receiving the Srefresh messages, a
receiver refreshes a state according to each Message_ID,
maintaining the RSVP soft state. If the RSVP status or a route
changes, it triggers the sender to send standard RSVP messages
to refresh upstream and downstream RSVP status, thus
rectifying the RSVP session failures. Using Srefresh messages
instead of standard RSVP Path or Resv messages reduces the
number of RSVP messages. In addition, Srefresh messages are
sent at a shorter interval than standard RSVP Path and Resv
messages, improving reliability and the recovery capability of an
RSVP session.

BFD for RSVP BFD for RSVP detects RSVP neighbor relationships. When a Layer
2 device such as a hub exists between neighboring RSVP nodes, the
two nodes can detect a link failure only by using the Hello
mechanism. It takes several seconds to rectify the failure. This
results in the loss of a great amount of data. BFD for RSVP
implements fault detection in milliseconds. BFD for RSVP fast
detects failures on the link between neighboring RSVP nodes. BFD
for RSVP is deployed on a TE FRR network where Layer 2 devices
exist on a primary CR-LSP between the PLR and its RSVP
neighbor. BFD for RSVP uses the RSVP module as an application
module and uses the BFD module as a protocol module.
BFD Session
BFD Session
A BFD session for RSVP is set up to detect a link between RSVP

neighbors. In this manner, the RSVP module can fast detect a link
failure.
The objects to be detected are different for BFD for RSVP, BFD for
CR-LSPs, and BFD for TE. BFD for RSVP mainly detects the IP
layer, and only single-hop BFD sessions can be set up between
RSVP neighbors.
BFD for RSVP can share BFD sessions with BFD for OSPF, BFD
for IS-IS, and BFD for BGP. When local BFD for RSVP shares a
BFD session with another protocol, the local device selects the
smallest values of all the parameters of the shared BFD session as
the local BFD parameters. The parameters include the transmission
interval, the receiving interval, and the local detection multiplier.
7.9.2.32 What Is the Hop Limit of a TE Tunnel?

Usually, a TE tunnel comprises no more than 32 hops.
An MPLS label comprises an 8-bit TTL field that is similar to the TTL field in an IP header.
Processing TTLs can prevent route loops and be used in the tracert function. In RFC 3443,
two modes for processing TTLs are defined for MPLS: uniform and pipe. By default, MPLS
processes TTLs in pipe mode.
l Uniform mode
When an IP packet enters an MPLS network, the IP TTL is reduced by 1 and then
mapped to the MPLS TTL field on the ingress. Then, the TTL in the packet is processed
in a standard manner over the MPLS network. The egress reduces the MPLS TTL by 1
and then maps the MPLS TTL to the IP TTL. Figure 7-37 shows that MPLS processes a
TTL in uniform mode.

Figure 7-37 Schematic diagram of processing TTLs in uniform mode
MPLS
CE1 PE1 P PE2 CE2
MPLS
TTL 254
MPLS MPLS
TTL 254 TTL 253
IP TTL IP TTL
IP TTL IP TTL
255 252
254 254
l Pipe mode
On the ingress, an IP TTL is reduced by 1 and the MPLS TTL is a fixed value. Then, the
TTLs in the packet are processed in a standard manner over the MPLS network. The
egress reduces the IP TTL by 1. When an IP packet is passing through an MPLS
network, the IP TTL is reduced by 1 only on the ingress and egress no matter how many
hops exist between the ingress and egress. Figure 7-38 shows that MPLS processes
TTLs in pipe mode.
Figure 7-38 Schematic diagram of processing TTLs in pipe mode
MPLS
CE1 PE1 P PE2 CE2
MPLS MPLS
TTL 254 TTL 253
MPLS MPLS
TTL 254 TTL 254
IP TTL IP TTL IP TTL IP TTL
255 254 254 253

7.9.3 VPLS
7.9.3.1 Does the Device Support MAC Address Learning in Qualified Mode on a
VPLS Network?
No. The device supports MAC address learning only in unqualify mode.
7.9.3.2 How Many Tags Are Carried in a Packet Sent by a Sub-interface for QinQ
VLAN Tag Termination Accessing a VPLS Network in Symmetry Mode?
A sub-interface for QinQ VLAN tag termination accesses an L2VPN in either symmetry
mode or asymmetry mode.
Outbound VPLS VPLS

Interface (Ethernet Encapsulation) (VLAN Encapsulation)
Type
Symmetry An outer tag is added. An outer tag is replaced.

mode
Asymmetry Double tags are added. One tag is stripped and then double tags
mode are added.
7.10 VPN
7.10.1 MPLS L2VPN
7.10.1.1 Under What Conditions Can a VSI Be Up in a VPLS Network?

In the case that the configurations are correct, VPLS can be Up when one of the following
conditions is met:
l mVSI: requires an Up PW or an Up AC in the VSI.
l Service VSI: requires two or more Up AC interfaces, or an Up AC interface and an Up
PW.
NOTE
An AC interface is an interface bound to a VSI. On a Martini VPLS network, if the peer is a UPE, the
PW connecting the UPE is handled as an AC in internal processing. The detailed VSI information shows
that the PW type of the UPE is MEHVPLS.
7.10.1.2 Under What Conditions Can a PW Be Up When the VPLS Network Is

Configured?
A PW can go Up when all the following conditions are met:
l The parameters on both ends of the PW such as encapsulation types and MTUs must be
the same.

l The AC interfaces are Up.

l The public network tunnel is Up.
l An LDP session or a remote BGP peer session is set up between PEs.
7.10.1.3 May the VSI Status Be Affected When ACs on Both Ends of a PW Are
Bound to Interfaces of Different Types?
No. The communication cannot be affected. At present, only Ethernet-encapsulated interfaces
including Ethernet interfaces and VLANIF interfaces are supported.
7.10.1.4 Can Communication Be Normal When ACs Are Bound to Interfaces of

Different Types on Both Ends of a PW?
No, the communication cannot be affected.
7.10.1.5 May the VSI Status Be Affected When Both VSIs Learn MAC Addresses
in Different Modes?
No, the VSI status is affected only when the MTUs or the encapsulation types are different.
The different MAC address learning modes, however, affect packet forwarding.
7.10.1.6 Why the LSP Token in a VPLS MID Entry Is Different from the Token of
the Current Tunnel?
The LSP token is the token value of the PW corresponding to the MID entry, and the LSP
token is irrelevant to the tunnel token.
7.10.1.7 How Can a PW Be Set Up Between Devices Through Martini VPLS?

The PW can go Up when the following conditions are met:
l For VSIs, the PW signaling protocols on both devices must be LDP.

l VSI IDs of both devices must be the same.
l If VSI IDs on both devices are different, the negotiated VC ID must be the same as the
VC ID of the peer when the peer is configured.
7.10.1.8 Can a Device Configured with a Martini VPLS Link Communicate with a
Device Configured with a VLL?
Martini VPLS supports Notification messages, so Martini VPLS can communicate with
PWE3 VLL.
When configure Martini VPLS to communicate with a Martini VLL (include PWE3 VLL),
note that the VSI ID and the VC ID of the VLLs are the same (or the negotiated VC ID in the
peer configuration must be the same as the VC ID of the peer), and the encapsulation types of
the VSIs and VLLs are the same.

7.10.1.9 How to Locate the Cause of the Problem that the Martini VPLS
Connection Fails to Go Up?
Take the VSI named a2 as an example. Run the display vsi name a2 verbose command to
view detailed information about VSI a2. Perform the following operations:
1. Check whether the encapsulation types, MTUs, and VSI IDs of VSIs on both ends of a
PW are the same, and whether the Martini VPLS or Martini VLL is adopted on both
ends of the PW.
Solution: If not, run the mtu command in the VSI view to set the same MTU on the VSIs
of both ends of a PW. In addition, run the encapsulationcommand to set the same
encapsulation type on VSIs of both ends of a PW.
2. Check whether an LDP session is Up.
Solution: If not, run the display mpls ldp session command to check whether the LDP
session is in the Operational state. If the LDP session is not in the Operational state,
check the public network links and LDP configurations.
3. Check whether the tunnel ID exists.
Solution: If not, check the public network links and LDP or TE configurations. The
VPLS links can be configured as LDP LSPs or CR-LSPs (VPLS over TE). When the
peer information shows the Tunnel policy field and the binding mode is specified in the
tunnel policy, these indicate that the tunnel is a VPLS over TE tunnel.
4. Check whether the AC interfaces bound to VSIs are Up (State), or on the SPE check
whether the PWs of two or more peers of the VSIs are Up and one peer is the UPE (with
the PW type being MEHVPLS).
5. Check whether PWs are Up (PW State).
If the preceding conditions are met on the local node except for the PW status being Down,
you can run the display vsi remote ldp [ route-id ip-address ] [ pw-id pw-id ] command to
view the VSI information on the peer. If no command output is displayed, it indicates that the
VSI configurations on the peer are incorrect and you need to check the peer configurations.
<HUAWEI> display vsi name a2 verbose
***VSI Name : a2
Administrator VSI : no
Isolate Spoken : disable
VSI Index : 0
PW Signaling : ldp
MTU : 1500
Mode : uniform
Service Class : --
Color : --
DomainId : 0
Domain Name :
VSI State : up
VSI ID : 2
VC Label : 23552
Peer Type : dynamic
Session : up
Tunnel Policy Name : policy1
VC Label : 23453
Peer Type : dynamic

Session : up
Interface Name : GigabitEthernet1/0/0.1

State : up
**PW Information:
PW State : up
PW Type : label
PW State : up
PW Type : MEHVPLS
7.10.1.10 Can VSIs Go Up Only When PEs Being Bound to VSIs?

No. The VSI status can go up when interfaces on two PEs are not bound to VSIs. In the
HVPLS networking, you need to configure upe when specifying a peer. In this case, the PW
between a UPE and an SPE is regarded as an AC. In the case that upe is configured for two
peers, the VSIs can go Up in the case that the VSI of the peer goes Up whereas the local
interface is not bound to a VSI.
7.10.1.11 Can Only One VSI on One End of a PW Be Up?

The VSI may be Up only on one end of a PW. When two ends of a PW are specified as UPEs,
the local end is Down whereas the peer can be Up. In addition, in this case the forwarding
status of both the local end and other ends is Down.
7.10.1.12 Is the Full Mesh Required by PEs in the Networking of VPLS Using
LDP Signaling?
The full mesh is required on PEs functioning as SPEs but not on PEs functioning as UPEs.
7.10.1.13 Can a VSI Be Up Only When VSI IDs on Both Ends of a PW Are the
Same?
No. These two VSI IDs can be different. When negotiation-vc-id is configured for a peer, the
two ends negotiate PW based on the negotiated VC ID. In this case, although the VSI IDs are
different, the two ends of the PW can communicate with each other.
7.10.1.14 Is negotiation-vc-id Relevant to a UPE?

No. They are irrelevant to each other. negotiation-vc-id is only used for negotiating VC IDs.

7.10.1.15 When Does the mpls ldp remote-peer Command Need to Be Run
During the Process of Configuring a VPLS Peer?
No remote LDP peer is required when PEs are directly connected. The mpls ldp remote-peer
command is required when PEs are not directly connected.
When a Huawei device and a non-Huawei device are used together, remote LDP peers need to
be configured when the LDP implementation mechanisms are different on these two devices.
7.10.1.16 How Can a PW Be Set Up Between Devices Connected Through

Kompella VPLS?
When import-extcommunity of the VSI on the local end and export-extcommunity of the
VSI on the peer are the same, a VC can be set up. In addition, detailed information about the
VSI on the local end contains PW information. That is, a unidirectional VC can be set up only
after the local end compares local import-extcommunity with export-extcommunity carried
in the label sent by the peer and verifies that these two parameters are the same. Therefore, the
planning of a Kompella VPLS network must be properly prepared to ensure the interworking
between devices. Otherwise, the devices may incorrectly communicate.
Normally, import-extcommunity of the VSI on the local end and export-extcommunity of
the VSI on the peer are the same.
7.10.1.17 How to Locate the Cause of the Problem that the Kompella VPLS
Take the VSI named bgp1 as an example. Perform the following operations:
1. Check whether import-extcommunity of the VSI on the local end and export-
extcommunity of the VSI on the peer are the same.
2. Check whether the encapsulation types and the MTUs of VSIs on both ends of a PW are
the same.
Solution: If not, run the mtu command in the VSI view to set the same MTU for VSIs on
both ends of the PW. In addition, run the encapsulationcommand to set the same
encapsulation type for VSIs on both ends of the PW.
3. Check whether the label value range meets the requirement that the site IDs of VSIs on
different PEs must be different, and the local site ID should be smaller than the sum of
the site-range and default-offset of the peer.
4. Check whether AC interfaces bound to the VSI are Up.
5. Check whether the status of the BGP peer relationship is Established.
Solution: Run the display bgp peer command and the display bgp vpls peer command
to check the BGP status. If the BGP peer relationship is not established, check public
network links and BGP configurations.
6. Check whether a tunnel ID exists.
Solution: If not, check public network links.
<HUAWEI> display vsi name bgp1 verbose
***VSI Name : bgp1
Administrator VSI : no
Isolate Spoken : disable
VSI Index : 0
PW Signaling : bgp


MTU : 1500
Mode : uniform
Service Class : --
Color : --
DomainId : 0
Domain Name :
VSI State : up
BGP RD : 168.1.1.1
Import vpn target : 100:1
Export vpn target : 100:1
Remote Label Block : 25600/5/0
Local Label Block : 25600/5/0
Interface Name : GigabitEthernet1/0/0.1
State : Up
**PW Information:
PW State : Up
PW Type : label
7.10.1.18 What Are the Precautions for Configuring a Huawei Device to

Interwork with a Non-Huawei Device Through Kompella VPLS?
When setting MTUs, ensure that the MTUs of VSIs created on different PEs within the same
VPLS network must be the same.
By default, the value of MTU in the VSI view is 1500. If the MTUs of two VSIs on the two
PEs in the same VPLS domain are different, the two PEs cannot exchange information or
establish a connection.
Check the following before you configure a Kompella VPLS link between a Huawei device
and a non-Huawei device:
l Whether the non-Huawei device supports the MTU consistency check in the VSI view.
l Whether the MTU of the non-Huawei device is the same as the default MTU of the
Huawei device.
When a Huawei device running the interworks with a non-Huawei device through Kompella
VPLS, you need to perform either of the following configurations to ensure that VCs are Up:
l Set the same MTU for the VSIs on the Huawei device (PE) and the non-Huawei device.
l Run the mtu-negotiate disable command to ignore the MTU consistency check.
7.10.1.19 What Is the Relationship Between the Site, Range, and Offset of BGP
VPLS?
Site refers to a position of the remote label in the label block received by the local end from a
peer. For example, a label block sent by a peer is 1000/10/0. If the value of a local site is 5,
the remote label on the local end is 1005.
Range refers to the sum of VPN sites connected by a VPLS link. Offset refers to a value as
the base that is counted in the calculation of a label block. For example, a label block is
1000/10/1, and the base value of a remote label is 1000. In this case, the remote label on the
local end is 1004.

The local site ID should be smaller than the sum of the site-range and default-offset of the
peer.
7.10.1.20 How Can a PW Be Set Up Between Two Devices When One Is

Configured With the Martini VLL and the Other Is Configured with the PEW3
VLL?
If two devices configured with the Martini VLL and PWE3 VLL respectively can interwork
with each other, you need to ensure that the VC IDs and VC types of the VLLs on these
devices are the same.
7.10.1.21 Under What Conditions Can an LDP VC Connection Be Up?

l For a static VC, a VC can go Up only when the following conditions are met:
– The local AC interface is Up.
– The public network tunnel is Up.
You can run the display mpls static-l2vc interface command to check the LDP VC
status.
l For a dynamic VC, a PW can go Up only the following conditions are met:
– The local AC interface is Up.
– The public network tunnel is Up.
– The LDP session is Up.
– The MTUs, VC types, and control words on both ends of the PW are the same.
– The VC IDs are the same.
You can run the display mpls l2vc interface command to check the PW status.
7.10.1.22 How to Locate the Cause of the Problem that the Martini or PWE3 VLL
Take the VLL on GE 1/0/0.1 as an example. Perform the following operations:
1. Check whether the VC IDs, encapsulation types, MTUs, and control words on both ends
of a VSI are the same, and whether the VLL or VPLS on both ends are configured in
Martini mode.
Solution: If not, set the same parameters on both ends. If the peer is configured with the
Martini VPLS, the control word must be Disable.
2. Check whether the AC interface (GE 1/0/0.1 in this example) bound to a VLL is Up.
3. Check whether an LDP session is Up.
Solution: If not, run the display mpls ldp session command to check whether the LDP
session is in the Operational state. If the LDP session is not in the Operational state,
check the public network links and LDP configurations according to FAQs of MPLS
LDP.
4. Check whether the PW has selected a tunnel.
Run the display mpls l2vc vc-id command.
– Check the VC tunnel/token info field in the command output. If VC tunnel/token
info is displayed as 0 tunnels/tokens, it indicates that no tunnel is selected by a
PW.

– Check the tunnel policy name field in the command output.

n If tunnel policy name is displayed as "-", it indicates that an LDP LSP is used
as the tunnel for a PW or no tunnel policy is configured. An MPLS TE tunnel
can be used for a PW only after a tunnel policy is configured.
n If tunnel policy name is not displayed as "-", it indicates that a tunnel policy
is adopted. In this case, you can run the display this command in the tunnel
policy view to view the tunnel policy configuration.
[HUAWEI-tunnel-policy-p1] display this
#
tunnel-policy p1
tunnel select-seq cr-lsp load-balance-number 1
#
NOTE
If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is

configured in the tunnel policy view, you also need to run the mpls te reserved-for-binding
command on the tunnel interface.
5. Check whether the remote label exists.
Solution: If the remote label is 0, check the peer device according to the preceding
procedure.
6. In PWE3 mode, verify that the forwarding status on the local and remote ends is
"forwarding."
<HUAWEI> display mpls l2vc interface gigabitethernet 1/0/0.1
*client interface : GigabitEthernet1/0/0.1 is up
session state : up
AC state : up
VC state : up
VC ID : 100
VC type : VLAN
destination : 192.3.3.3
local group ID : 0 remote group ID : 0
local VC label : 21504 remote VC label : 21504
local AC OAM State : up
local PSN State : up
local forwarding state : forwarding
remote AC OAM state : up
remote PSN state : up
remote forwarding state: forwarding
BFD for PW : unavailable
manual fault : not set
active state : active
forwarding entry : exist
link state : up
local VC MTU : 1500 remote VC MTU : 1500
local VCCV : Disable
remote VCCV : Disable
local control word : disable remote control word : disable
tunnel policy : --
traffic behavior : --
PW template name : --
primary or secondary : primary
VC tunnel/token info : 1 tunnels/tokens
NO.0 TNL type : lsp , TNL ID : 0x2002003
create time : 0 days, 0 hours, 7 minutes, 16 seconds
up time : 0 days, 0 hours, 5 minutes, 6 seconds
last change time : 0 days, 0 hours, 5 minutes, 6 seconds

7.10.1.23 How to Change a VLL to the Martini Mode?

A system supports PWE3 mode by default and at the same time can communicate with a
device configured with the VLL in Martini mode. To change the VLL to Martini, you need to
run the mpls l2vpn default martini command in the MPLS L2VPN view.
In addition, you can run the undo mpls l2vpn default martini command to restore the PWE3
mode.
If a VC is configured, the PWE3 mode and the Martini mode cannot be switched to each
other.
7.10.1.24 When Do local-ce ip and local-ce mac Need to Be Set On a

Heterogeneous Network?
local-ce ip and local-ce mac need to be configured when Ethernet interfaces or sub-interfaces
are encapsulated on PEs of an L2VPN in IP heterogeneous interworking mode. An ordinary
ARP entry is different from the ARP entry of an L2VPN Ethernet interface encapsulated in IP
heterogeneous interworking mode. In this case, the MAC address learning modes are
different.
If an incoming L2VPN interface is encapsulated in IP heterogeneous interworking mode on a
PE receiving an ARP Request packet from a CE, the PE replies with its own MAC address
irrespective of the destination address.
7.10.1.25 What Special Configurations Are Required by an FR Interface and What

Are the Principles for Configuring a DCE Interface and a DTE Interface on a CE
and a PE?
Note the following when you configure an FR interface:
l When an interface is of the DCE or NNI type, the interface (can be either a main
interface or a sub-interface) must be configured with a DLCI.
l When an interface is of the DTE type, for a main interface, the system automatically
determines the local DLCI; for a sub-interface, you must manually set a DLCI.
l When an FR interface is configured on a CE to access a PE, no special configurations are
required on the interface of the PE connected to the CE. On two CEs that communicate
with each other, the interface on one CE connected to a PE must be of the DCE type, and
the interface on the other CE connected to a PE must be of the DTE type, as shown in
Figure 7-39.
l Figure 7-39 Networking diagram of VPWS
PE1 PE2
VPN backbone
DCE DTE
CE1 CE2

l If an NBMA network is built between PEs through FR, ATM, ensure that the link
mappings are configured to allow broadcast packets to pass through the interface on
which an LSP is to be set up.
7.10.1.26 What Are the Functions of Control Words in PWE3?

On the control plane of PWE3, one bit is used to indicate whether the control word is enabled.
A VC can go Up only when the control words on both ends of the VC are the same.
On the forwarding plane, if the control word is supported, a 32-bit control word is added to a
data packet header to indicate the sequence of packets. Usually, packets are out of order only
when the load balancing mode is enabled.
When Ethernet runs between PEs and PPP runs between PEs and CEs, the size of the PPP
control packets is smaller than the smallest MTU supported by the Ethernet. Then, the PPP
negotiation fails. In this case, you can avoid this problem by enabling the control word to add
padding bits.
7.10.1.27 Can a Multi-Hop VC with the Same Peer and Different Encapsulation
Types Be Set Up on an SPE Configured with the mpls switch-l2vc Command?
Yes, this is because a VC is identified by a VC ID and a VC type.
7.10.1.28 Can a PW ID Be Set to Zero or No PW ID Be Set When a Static PW Is to

Be Set Up?
Yes. A static PW can be configured with or without a PW ID. When the PW ID of a static PW
is set to zero, the static PW cannot exchange data with other PWs.
7.10.1.29 How to Implement VLL Load Balancing?

Load balancing refers to that traffic of one PW is transmitted over multiple tunnels in turns.
The number of tunnels working in load balancing mode is controlled by a license.
To configure the load balancing mode, you need to configure the tunnel selection policy, that
is, specify a policy name when configuring a VC.
7.10.1.30 What is Multi-Hop in PWE3? When Does Multi-Hop PWE3 Need to Be

Configured? How to Configure Multi-Hop PWE3?
Multi-hop PWE3 is used to connect multiple VCs to interwork CEs.
When a VC spans different ASs or only a fragmented tunnel rather than a direct tunnel exists
between UPEs, multi-hop PWE3 is required. Multi-hop PWE3 lowers the performance
requirements of access devices.
When a UPE cannot sense whether its peer is a UPE or an SPE, the UPE just regards its peer
as an SPE. Therefore, you can configure the UPE the same as a UPE on a single-hop PW. The
PW configurations on the SPE are classified into the following types:
l Dynamic-dynamic PW: indicates that both PWs to be switched on the SPE are dynamic
PWs.

l Static-static PW: indicates that both PWs to be switched on the SPE are static PWs.
l Mixed PW: indicates that two PWs to be switched on the SPE are a dynamic PW and a
static PW.
7.10.1.31 What Are Differences Between the Tagged and Untagged Encapsulation
Modes on an Ethernet Interface and the Tagged and Raw Encapsulation Modes
on a PWE3 Tunnel?
The functions of the tagged and untagged attributes of Ethernet interfaces and the tagged and
raw attributes of PWE3 tunnels bound to the Ethernet interfaces are as follows:
l When an Ethernet interface at the AC side receives packets, the tagged and untagged
attributes are used to identify the VLANs to which the packets belong and the sub-
interfaces that can receive the packets. By default, the Ethernet packets are of the
untagged type and the VLAN packets are of the tagged type.
l The tagged and raw attributes of a PWE3 tunnel are used to set whether a VLAN tag
(indicating a CE VLAN) is carried in the PWE3 payload. When a PWE3 packet is sent
along the PW, the outgoing interface is determined according to a VC label rather than a
VLAN tag.
Whether a PWE3 packet carries a VLAN tag is irrelevant to whether an Ethernet interface
bound to the PWE3 tunnel adds VLAN tags to packets.
You can set a PWE3 tunnel encapsulation type to raw to process VLAN tags in packets. For
example, the local AC interface is a main Ethernet interface and the peer is an Ethernet sub-
interface.
l The Ethernet main interface receives an untagged packet. On the PWE3 tunnel
configured with the raw mode, the packet is not added with a VLAN tag before being
sent to the peer. The outgoing interface on the peer is an Ethernet sub-interface, which
adds a VLAN tag to the packet and then sends the packet.
l In the reverse direction, when receiving a packet with a VLAN tag and detecting that the
PWE3 tunnel is configured with the raw mode, the Ethernet sub-interface strips the
VLAN tag from the packet before sending it through the Ethernet main interface along
the PW. In this case, the packet does not carry a VLAN tag.
In QinQ mode, a packet carries multiple tags when being transmitted along a PW. If the
PWE3 tunnel is configured with the raw mode, the local end strips the outer tag from the
packet so that the packet travels to the peer with only an inner tag.
On a VLANIF interface, a packet from a default VLAN does not carry a VLAN tag. If the
PWE3 tunnel is configured with the tagged mode, a forwarding engine adds a default VLAN
tag to a packet. In addition, an Ethernet main interface adds a virtual default VLAN tag to a
packet.
When configuring a PWE3 tunnel on an Ethernet interface, you can only manually configure
the packet encapsulation type as either tagged or untagged.
7.10.1.32 Why CEs on Both Ends of a PW Cannot Communicate with Each Other
When Interfaces on the CEs and PEs Are Up After the CEs Access the PEs
Through the ATM Homogeneous Medium?
The possible cause is that the PVCs are different on the interfaces of the PEs connected to the
CEs and the interfaces on the CEs connected to the PEs. In this case, verify that all interfaces

on the PEs connected to the CEs and all interfaces on the CEs connected to the PEs are
configured with the same PVC.
7.10.1.33 When AC Interfaces on PEs on Both Ends of a PWE3 Tunnel Are

Ethernet Interfaces, the Two CEs Cannot Ping Each Other When the mpls l2vc
Command Without ip-interworking Is Used on PEs. Why?
When ip-interworking is configured, a CE learns the MAC address of the connected PE
through ARP entries; when ip-interworking is not configured, a CE learns the MAC address
of the peer CE through ARP entries. A MAC entry ages in about 20 minutes. Within a short
period, the MAC entry that is the MAC address of the local PE does not age on a CE.
Therefore, the CEs cannot ping each other. In this case, you just need to run the reset arp all
command in the user view to update ARP entries. The CEs then can ping through each other.
7.10.1.34 Which Configuration Takes Effect, L2VPN or L3VPN When an Interface

Is Concurrently Bound to an L2VPN and L3VPN?
An interface cannot serve as both an L2VPN AC interface and an L3VPN AC interface at the
same time. If you configure L2VPN services on an interface, all Layer 3 features such as the
IP address and routing protocol configured on the interface become invalid. If you configure
L2VPN and L3VPN services on an interface, only L2VPN services are available. The L3VPN
services become available after the L2VPN services are deleted.
7.10.1.35 What Are Differences Between Ethernet OAM and Other Link
Detection Mechanisms?
Ethernet OAM is a mechanism to detect Ethernet links. Different from other link detection
mechanisms, Ethernet OAM requires CEs to support link detection.
When the links dual homing a CE to PEs need to be switched, Ethernet OAM provides two
switchover methods of transient interrupting a physical interface and clearing the MAC
address of the interface connecting the CE to the PE.
7.10.1.36 Why Cannot Ethernet OAM in Transient Interruption Mode Be

Configured in the VLL FRR Networking?
During traffic switchback after the primary PW recovers from a fault, to implement link
switchover between a dual-homed CE and PEs, the secondary PW changes itself to Down for
a certain period and notifies an AC interface of the simulated fault. The period for the
secondary PW to keep the Down state is the Resume time set by using the mpls l2vpn
reroute command.
After the AC interface is notified of the simulated fault, the L2VPN module on the PE will
receive a message indicating that the link is Down if link switchover is triggered by clearing
the MAC address. On the PE, the message is generated after the AC side senses the simulated
fault of the secondary PW; therefore, the PE will not send this Notification message to the
peer PE.
If transient interruption is configured, the L2VPN module of the PE will receive a message
indicating that the physical interface is Down. This message must be sent to the peer PE. Then
the L2VPN module of the PE considers that a fault occurs on the secondary PW and it
removes the Resume timer. The period of transient interruption is 7 seconds. Therefore, the
link will recover from the fault after 7 seconds. That is, the Resume period is always 7

seconds. As a result, the PW switchback policy is inconsistent with the policies you have
configured.
7.10.1.37 What Are the Precautions for Configuring VLL FRR Switchback
Policies?
If an asymmetric VLL FRR network is deployed and ACs are Ethernet links and Ethernet
OAM is configured on an interface of a PE connected to a CE, the Resume time cannot be set
to 0 seconds in a switchback policy but must be equal to or longer than 1 second.
If the Resume time is set to 0 seconds, during PW switchback, the local PE will repeatedly
send messages indicating that the secondary PW is Down or Up. In this case, if EFM is
enabled to detect links between the peer PE and the CEs, as specified in IEEE802.3ah, the PE
must send a probe packet to CEs every second. Since the interval for sending the Down or Up
message is shorter than 1 second, the PE cannot normally forward these messages to the peer
CE.
If the remote shutdown function is configured on the interface of a PE connected to a CE, you
are not recommended to use the policy of immediate revertive switchback, because this policy
may lead to network flapping and traffic loss. In addition, you can use the policy of delayed
revertive switchback to set delay-time equal to or more than 30 seconds.
7.10.1.38 In PWE3 Heterogeneous Internetworking, CEs Run OSPF. Why Cannot

the Local CE Learn Routes to the Peer CE Through OSPF?
Check the AC link types at the local and peer CEs. If the AC link type at the local CE is
Ethernet, its OSPF type is broadcast. If the AC link type at the peer CE is PPP, its OSPF type
is P2P. Because different network types are configured for OSPF interfaces, the local and peer
CEs cannot complete route calculation after establishing an adjacency. Therefore, you must
run the ospf network-type p2p command on the local CE's Ethernet interface to change the
network type of the OSPF interface to P2P.
7.10.1.39 Tunnels Are Correctly Configured Between PEs. Why Cannot a VC Be

Bound to the Tunnel After PWE3 Is Configured?
The possible cause is that the tunnels to which the VC can be bound does not match the
configured tunnel policy. A VC is bound to a tunnel based on the configured tunnel policy. If
a CR-LSP is configured in the tunnel policy but a device is configured only with LDP LSPs,
the VC cannot be bound to a correct tunnel.
7.10.1.40 How Can a PW Be Set Up Between Devices Through the Kompella

VLL?
When import-extcommunity of the VLL on the local end and export-extcommunity of the VLL
on the peer are the same, a VC can be set up. In addition, detailed information about the VLL
on the local end can show PW information. That is, a unidirectional VC can be set up only
after the local end detects that local import-extcommunity with export-extcommunity carried in
the label sent by the peer are the same.
Normally, import-extcommunity of the VLL on the local end and export-extcommunity of the
VLL on the peer are the same.

7.10.1.41 What Are the Precautions for Configuring a Huawei Device to

Interwork with a Non-Huawei Device Through Kompella VLL?
The MTUs of devices in a VPN must be the same. If the MTUs of the same VPN on two PEs
are different, the two PEs cannot exchange information or establish a connection. By default,
the MTU is set to 1500 in the L2VPN view.
Confirm the following before you configure a Kompella VLL between a Huawei device and a
non-Huawei device:
l Ensure that the non-Huawei device supports MTU consistency check in the L2VPN
instance.
l Ensure that the default MTU of the non-Huawei device is the same as the default MTU
of the Huawei device.
When a Huawei device running the interworks with a non-Huawei device through Kompella
VLL, you need to perform either of the following configurations to ensure that VCs are Up:
l Set the MTU of the L2VPN instance on the PE to be the same as the MTU on the non-
Huawei device.
l Run the ignore-mtu-match command to ignore the MTU consistency check.
7.10.1.42 Are the Full Connections Between PEs in a VPLS Network Physical or
Logical? How to Prevent Routing Loops?
PEs are logically fully connected, as shown in Figure 7-40.
Figure 7-40 Networking diagram of full connections between PEs
PE1 PE2 PE3
PE1 is directly connected to PE2 and is not directly connected to PE3. Every two PEs are
configured as peers of the third PE. For example, PE2 and PE3 are configured as two peers of
PE1. In this manner, the PEs are fully connected.
In a VPLS network, split horizon is adopted to prevent routing loops. That is, the packets
received from a PW are not forwarded to other PWs but to ACs; the packets received from an
AC are forwarded to other ACs and all PWs. To break split horizon rules, you need to specify
a UPE as a peer. (This configuration is applicable to only Martini VPLS.)
7.10.1.43 How Does the System Calculate the Blocking Time in MAC Flapping?
A: The time period during which an interface is blocked and the number of times an interface
is permanently blocked can be calculated when block-time block-time and retry-times retry-
times are specified in the loop-detect eth-loop loop-times (VSI view) command.
For example, block-time is set to 100 seconds and retry-times is set to 2. When detecting a
loop in a specific VLAN, the system blocks the interface where the loop occurs in any of the
following modes:

l After the loop is detected for the first time, the interface is blocked for 100 seconds and
then restored.
l If the loop is detected again within the first detection cycle specified by detect-cycle-
time after the interface is restored, the interface is blocked for 2 x 100 seconds and then
restored. If no loop is detected within the first detection cycle, the system considers that
the loop is eliminated and when the loop occurs again, the system re-starts the
calculation.
l If the loop is immediately detected again after the second block cycle specified by
detect-cycle-time is complete, the interface is blocked for 3 x 100 seconds and then
restored. If no loop is detected after the second block cycle is complete, the system
considers that the loop is eliminated and when the loop occurs again, the system re-starts
the calculation.
l If the loop is immediately detected once again after the third block cycle specified by
detect-cycle-time is complete, that is, the loop occurs for three times after the first
blocking is complete, the system blocks the interface permanently. This is because the
number of loop occurrences exceeds retry-times defined by the system.
7.10.1.44 Why Forwarding Entries Are Correct but Traffic Forwarding Fails on a
PE After Some VPLS Services Are Deployed?
For example, after the control word function is enabled, VSI PWs go Up, but traffic
forwarding fails.
If forwarding entries can be correctly generated, but traffic cannot be forwarded, the boards
may not support the corresponding services.
Perform the following steps to rectify the fault:
1. Run the display vsi verbose command on the problem device to check details about VSI
PWs. Check whether the control-word enable command has been configured and
whether the forwarding entries are correct.
2. Check the types of the boards on which the public network-side inbound and outbound
interfaces reside.
– If the board type is LPUF-50, LPUF-51, LPUI-51, LPUS-51, LPUF-120,
LPUI-120, LPUF-240, LPUI-240, LPUF-101, LPUI-101, LPUS-101, or LPUI-102,
the boards support the control word function. Contact Huawei technical support
engineers.
– If the boards do not support the control word function, go to Step 3.
3. Change configurations and use interfaces on control word-capable boards as inbound and
outbound interfaces for service forwarding.
The procedure for handling traffic forwarding failures for flow label-based load balancing,
VPLS E-Tree, TPIDs for PWs, multicast VPLS, and MP2MP PBB over VPLS services is the
same as that for handling traffic forwarding failures after the control word function is enabled.
7.10.2 L3VPN
7.10.2.1 Does a Super VLAN Transmit L3VPN Services on a Device?
A super VLAN configured on a user-side interface can transmit L3VPN services.

7.10.2.2 Can Load Balancing Be Performed for L3VPN Traffic Transmitted over
an MPLS Network?
By default, no load balancing is performed for L3VPN traffic transmitted over an MPLS
network. To enable load balancing, run the following command to specify the number of
tunnels to balance traffic and the sequence for carrying out load balancing.
tunnel select-seq { gre | lsp | cr-lsp } * load-balance-number load-balance-number

command to specify the number of tunnels to balance traffic and the sequence for carrying out
load balancing.
7.10.2.3 May L3VPN Services Be Interrupted During a Master/Slave Failover on

the Device?
l If GR is not enabled, during a master/slave switchover, route re-convergence causes

L3VPN services to be interrupted.
l On a network with GR enabled such as BGP GR, LDP GR, and IGP GR, services will
not be interrupted on the NE40E&NE80E providing 16 slots for LPUs, but services will
be interrupted temporarily on the NE40E&NE80E providing non-16 slots for LPUs. The
MPU is integrated with an SFU on the NE40E&NE80E providing non-16 slots for
LPUs. In this case, after an MPU on the NE40E&NE80E providing non-16 slots for
LPUs is reset, the SFU is also reset, causing data loss.
7.10.2.4 What Are VPN Label Allocation Modes and What Are Differences
Between These Modes?
VPN labels are allocated in either of the following modes:
l Apply-label per-route (default)

l Apply-label per-instance
The difference between these two modes is as follows:
l Allocating labels in per-route mode consumes a large number of label resources on a

device. If a large number of routes exist, the number of required labels may exceed the
maximum number of labels available on the device, therefore leading to a failure in
allocating excess labels and therefore causing a forwarding failure.
l Allocating labels in per-instance mode consumes a less number of label resources on the
device than that in per-route mode. In per-instance mode, a VPN is assigned one label.
It is recommended that the apply-label per-instance mode be adopted though these two modes
have the same effects. The apply-label per-route mode, however, must be adopted in the
scenarios where a carrier network accesses another carrier network.
7.10.2.5 Can a Notification of a Link Failure on a Link Between the Remote PE

and CE Is Sent over a VLL to Instruct the Local PE or CE to Change the
Connection Status?

Run the mpls l2vpn trigger if-down command on PEs of both ends of a VLL connection,
therefore instructing the local PE or CE to change the connection status if the remote PE or
CE fails.
7.10.2.6 What Is the Function of the remote-ip ip-address pwe3 Command?

The remote-ip ip-address pwe3 command disables a node from distributing labels to a
specified remote peer. This command does not take effect on label distribution over a private
network. In addition, this command is inapplicable to an LDP over TE network.
7.10.2.7 Can the NE40E&NE80E Back Up Configurations to the N2000 Server by

Using VPNs?
It is not supported by V600R009C10. The cause is as follows:
There is no VPN instance node in the operation table of HWCM. Therefore, the NMS fails to
notify the V600R009C10 of the VPN instance to which the FTP server belongs. When
V600R009C10 functions as an FTP client to set up a connection with the FTP server, the
attempt fails because no VPN parameter is carried.
In V300R006, you can run the additionally developed set net-manager vpn-instance <vpn>
command to set the VPN instance to which the FTP server belongs. Then, the VPN instance is
used for the FTP service, Flash MIB, and HWCM MIB by default.
7.10.2.8 Why Traffic Is Unevenly Shared After the Load-Balancing Mode

Changes from Route Load Balancing to Trunk Load Balancing on a P in an
L3VPN Scenario?
In an L3VPN scenario, after route load balancing is configured on a P, two MPLS LSPs will
take shape on the public network and L3VPN service traffic will be shared between the two
LSPs. The ingress distributes traffic between the two LSPs based on the five-tuple
information of packets. After route load balancing is changed to trunk load balancing on the P,
the P distributes traffic among trunk member links based on labels. As a result, traffic with
different five-tuple information but the same label is distributed to one link, causing uneven
traffic sharing.
7.10.3 ATM IWF
7.10.3.1 What Is the Possible Cause for Communication Failure in the MPLS
L2VPN?
l On the PE, the interface on the CE side is in Down state.

l The tunnel between PEs fails to be set up.
l The LDP session between the PEs fails to be set up.
l The PEs at both ends have different values of VC ID and VC type.
l The PEs at both ends have different MTU values.
l Label switching and binding between both ends are not complete.

7.10.3.2 Why IWF Is Addressed?

The ATM-Ethernet IWF feature takes advantage of the similar structure of the double layer of
VLAN in Ethernet Q-in-Q and the ATM VPI/VCI. It maps the VPI/VCI to the outer VLAN
ID and the inner VLAN ID to keep the management mode in ATM network that VPI and VCI
values are used to identify users and services. It has little impact on the management mode of
the existing network and can be applied in the transition from ATM to Ethernet.
7.11 Security
7.11.1 URPF
7.11.1.1 What Is the Difference Between the URPF Strict Mode and the URPF
Lose Mode?
URPF can be classified into strict URPF and loose URPF.
The difference between the strict mode and lose mode is as follows:
l After being configured with URPF in lose mode, the packet can pass the URPF check
when the forwarding table contains the corresponding entries. Interface match is not
required.
l After being configured with URPF in strict mode, the packet can pass the URPF check
only when the forwarding table contains the corresponding entries and the outbound
interface matches the entry in the forwarding table.
7.11.1.2 Q: Can the router Forward a Packet through an Interface that receives the
packet?
A: Yes. After receiving a packet on an interface, the router searches the routing table for an
entry mapped to the destination address, not the source address. If there is a matched entry,
the packet is forwarded even though the inbound and outbound interfaces are the same. Even
if URPF is strictly configured, the source address of a packet can still pass the URPF check if
it is legal. A packet, therefore, can be forwarded through an interface that receives the packet.
7.11.2 Port Mirroring
7.11.2.1 Can the Device Mirror Traffic of Multiple Ports to One Observing Port?
If So, Is There a Restriction on the Number of Mirrored Ports?
Yes. The device can mirror traffic of multiple ports to one observing port. In addition, there is
no restriction on the number of mirrored ports whose traffic is mirrored to one observing port.
Nevertheless, the volume of traffic of these mirrored ports must be supported by the
forwarding capability.
7.11.2.2 Is Traffic on Sub-interfaces Mirrored After Mirroring Is Configured on

the Main Interface?
Yes, it is. After mirroring is configured on the main interface, traffic on sub-interfaces is
mirrored.

7.11.2.3 Can an Interface Be Configured As a Mirroring Port and an Observing

Port At the Same Time?
No. An interface can be configured as either a mirroring port or an observing port.
7.11.2.4 Do Ethernet Interfaces Support the Port Mirroring Function?

No.
7.11.3 Local Defense

7.11.3.1 How to Configure Users to Manage the Router Through a Specified
Interface?
Apply the interface-level policy for management plane protection on the specified interface
and allow packets of management protocols to be sent to the CPU in the policy. At the same
time, enable the global policy for management plane protection and prevent management
protocol packets from being sent to the CPU in the global policy.
7.11.3.2 Why Some Normal Packets Are Discarded When Local Attack Defense
Policy Is Applied?
When a router receives a large number of packets, the application layer association function
and TCP/IP attack defense function limit the bandwidth for packet sending according to the
protocols of packets, therefore ensuring the reasonable range of the network traffic. In this
case, attack packets are discarded on the one hand; on the other hand, some normal packets
are also discarded due to the limited bandwidth.
7.11.3.3 Is NetStream Information in the Cache a Basis for Checking Whether

Attacks Exist?
NetStream information in the cache on a device is used to check the status of the NetStream
module. The specific traffic volume, however, is not contained. Therefore, NetStream
information cannot be a basis for checking whether attacks exist.
A NetStream Data Analyzer (NDA) can be used to check whether attacks exist by analyzing
the attack flows collected through NetStream and viewing packet characteristics.
7.11.3.4 Services Are Interrupted After a Layer 2 Interface Is Shut Down or When
the CPU Usage of the Board Where the Interface Resides Increases. How to
Handle This Problem?
Run the display l2-loop-detect status-info slot slot-number command to display summary
information about Layer 2 loop detection. Check whether Lay 2 loops occur on the interface.
If Lay 2 loops occur on the interface, run the display l2-loop-detect packets-info slot slot-
number command to display the packet information on the interface. Then, analyze the loop
causes, confirm the link that causes on the loops, and rectify the problem based on the
interface information and packet information. Three possible causes for the Layer 2 loops are
as follows:
l In an Ethernet ring network, the loop-prevention protocol does not take effect because
the ring network is attacked or overloaded.

l In a non-ring network, loops occur due to incorrect link connections.

l Loops occur because a single channel of an optical module fails to work.
NOTE
If an interface is shut down due to Layer 2 loops. After the loops are cleared, run the display this
interface in the interface view to check whether L2-loop-detect DOWN is displayed. If this
information is displayed, run the shutdown command and then run the undo shutdown command so
that the interface status will become Up.
If Layer 2 loops do not occur, collect the executed results of the preceding troubleshooting
procedures, configuration files, log files, and alarm files of the device. Then, contact Huawei
technical personnel.
7.11.4 other
7.11.4.1 Can a Routing Protocol and Routing Protocol Services Be Run on GE

0/0/0 on an SRU/MPU?
GE 0/0/0 on an SRU/MPU is an MEth interface and is used to manage a device. Therefore, it
is not recommended that a routing protocol or routing protocol services be run on GE 0/0/0.
7.12 Reliability
7.12.1 BFD
7.12.1.1 When Does Batch Backup Occur?

Batch backup occurs when an RBS connection is just created, or a command for configuring
time or regular batch backup is run.
7.12.1.2 Why Does VRRP Switchback Need to Be Controlled?

VRRP switchback control ensures that VRRP switchback is performed only after a great
number of users have gone online. If batch backup occurs before certain users go online,
traffic is lost.
7.12.1.3 When Does an Address Pool Need to Be Bound to the RBP?

For the exclusive address pool mode, the address pool must be bound to the RBP. The primary
device advertises the address pool network segment route and the secondary device cancels
the route.
7.12.1.4 When Does an Address Pool Need to Be Bound to the RBS?

For the shared address pool mode, the address pool must be bound to the RBS. The primary
and secondary devices both advertise the address pool route. In this case, you need to
configure a route policy to ensure that the return traffic is forwarded to the primary device.

7.12.1.5 Why More Than the Maximum Number of BFD Sessions Can Be
Configured and the System Only Prompts an Error When the Configurations Are
Committed?
The number of BFD configurations is independent of the number of BFD sessions.
Commonly, the maximum number of global BFD configurations is at least the maximum
number of global BFD sessions. If the number of BFD sessions reaches the upper limit but the
number of BFD configurations has not reached the upper limit, you can perform more BFD
configurations. When you run the commit command, however, you can find that BFD
sessions cannot be set up and the system prompts an error.
In this manner, the system can read the BFD configuration that has not set up a BFD session
after a BFD session is deleted and set up a session for this configuration. As a result, the
system performance is fully used.
7.12.1.6 Why the Contents of the Time Entry in Session Statistics Vary with the
Session Status?
When the BFD session is Down, the duration from the last status change to the present time is
recorded in the Down Status Lasting Time entry. For example:
<HUAWEI> display bfd statistic session all slot 10
--------------------------------------------------------------------------------
Session MIndex : 16388 (One Hop) State : Down Name : 1
--------------------------------------------------------------------------------
Local/Remote Discriminator : 514/1
.......
Create Time : 2006/02/22 18:45:05
Last Down Time : 2006/02/23 10:34:49
Down Status Lasting Time : 000D:00H:00M:00S
Total Time From Create : 000D:15H:56M:35S
When the BFD session is Up, the duration from the last change to the Down state to the
present time is recorded in the Total Time From Last DOWN entry. For example:
<HUAWEI> display bfd statistic session all slot 10
--------------------------------------------------------------------------------
Session MIndex : 16945 (One Hop) State : Up Name : 46
--------------------------------------------------------------------------------
Local/Remote Discriminator : 559/46
......
Create Time : 2006/02/22 18:45:05
Last Down Time : 2006/02/23 10:34:49
Total Time From Last DOWN : 000D:00H:00M:32S
Total Time From Create : 000D:00H:09M:09S
7.12.1.7 Why the commit Command Needs to Be Used?

Using the commit command, you can submit configurations. The major purposes of this
command are to determine whether configurations are correct and whether to submit the
configurations. Before the commit command is used, no configuration or modification takes
effect.
The reasons for using the commit command include:
l There are a great number of BFD configurations and some of them are mandatory. The
commit command needs to be used only after all mandatory BFD configurations are
performed. Then, BFD sessions can be successfully set up. If BFD configurations are
incorrect or incomplete, the configurations fail and an error message is prompted when

you run the commit command. For example, the system prompts "Error: The remote
discriminator or the local discriminator is not configured."
l If BFD configurations are correct but the condition for setting up BFD sessions is not
met (for example, the route is unreachable), BFD sessions cannot be set up after the
commit command is used. Then, the system displays a prompt. After the condition is
met, the system creates BFD sessions automatically.
7.12.1.8 Why the BFD Session Detection Mode Is Still Asynchronous After the
Demand command Is Configured in the BFD Session View?
The demand mode of BFD session detection needs to be negotiated by both ends of the BFD
session. If only one end of the session is configured with the demand mode, the BFD session
detection mode is still Asynchronous. Only when both ends of the session are configured with
the demand mode, the BFD session detection mode becomes Demand.
--------------------------------------------------------------------------------
Session MIndex : 258 (Multi Hop) State : Up Name : atoc
--------------------------------------------------------------------------------
BFD Bind Type : Peer Ip Address
Bind Peer Ip Address : 10.2.1.2
Actual Tx Interval (ms) : 1000 Actual Rx Interval (ms) : 1000
WTR Interval (ms) : -- Process PST : Disable
Local Demand Mode : Enable Demand Tx Interval (ms) : --
Last Local Diagnostic : Administratively Down
Session TX TmrID : -- Session Detect TmrID : --
Session Init TmrID : -- Session WTR TmrID : --
PDT Index : FSM-0|RCV-0|IF-0|TOKEN-0
--------------------------------------------------------------------------------
7.12.1.9 Why the Type of a Single-hop Route Is Displayed as Multi-hop in BFD

Session Details?
When you run the display bfd session all verbose command, the status of the BFD session
rather than the route status is displayed. The status of the BFD session (single-hop or multi-
hop) adapts to different protocol implementation mechanisms in different networking, that is,
different BFD session status. The status of the BFD session is not about the actual networking
mode.
For BFD sessions, the criterion for distinguishing a single-hop session from a multi-hop
session is whether the session is bound to an interface. According to the RFC for BFD, a
single-hop session needs to be bound to an interface. Therefore, you need to specify the
interface parameter to create a single-hop BFD session. When creating a multi-hop session,
you do not need to specify the interface parameter. Note that the multi-hop mechanism can be
applied to the single-hop networking.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------


Local Demand Mode : Disable
--------------------------------------------------------------------------------
7.12.1.10 Can You List All the Session Detect Modes and Specify When a Session
Detect Mode Is Adopted?
The session detect modes include:
l Asynchronous mode with echo function: At present, only the passive echo function is
supported.
l Asynchronous mode without echo function: When the demand mode is not configured or
the demand mode is configured but the negotiation fails, session detection is in
asynchronous mode.
l Demand mode with echo function: At present, this mode is not supported.
l Demand mode without echo function: When both ends of a BFD session are configured
with the demand mode and the negotiation succeeds, this mode is adopted.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Local Demand Mode : Disable
--------------------------------------------------------------------------------
7.12.1.11 Why Is Information on the LPU Inconsistent with that on the MPU?
BFD sessions are processed on the LPU. Information of different types is synchronized to the
MPU at different intervals. For example:
l Session status: is synchronized at 100-ms intervals.

l Session information: is synchronized at 5-minute intervals.

l Session statistics: are synchronized at intervals of 5 to 10 minutes. The intervals vary

with device types.
The session status displayed on the MPU is almost synchronous with that on the LPU,
whereas the other information displayed on the MPU is earlier than that on the LPU. For
example, Actual Tx Interval (ms) indicates transmission intervals of sessions and Actual Rx
Interval (ms) indicates receiving intervals of sessions. If you view information on the MPU
and LPU soon after a session goes Up, you can find that information on the two boards is not
synchronous. The intervals on the MPU are still the packet transmission intervals for
negotiation, whereas the intervals on the LPU are the packet transmission intervals for
detection.
To view packet transmission intervals on the LPU, you can run the display bfd session
discriminator discriminator verbose slot slot-id command. The value of the Actual Tx
Interval (ms) field in the command output is the packet transmission intervals on the LPU.
7.12.1.12 What Is the Difference Between Min Tx Interval (ms) and Actual Tx
Interval (ms)?
Min Tx Interval is a configured value, whereas Actual Tx Interval is the actual transmission
interval after session negotiation. The formulas for negotiating packet transmission and
receiving intervals are as follows:
l Negotiation of packet transmission and receiving capability:

– Actual packet transmission intervals = max (min-tx-interval of the local end, min-
rx-interval of the peer end)
– Actual packet receiving intervals = max (min-tx-interval of the local end, min-rx-
interval of the local end)
l Negotiation of detection intervals:
– For asynchronous mode: Detection intervals = Detection time multiplier of the peer
end * max (min-tx-interval of the peer end, min-rx-interval of the local end)
– For demand mode: Detection intervals = Detection time multiplier of the local end
* max (min-tx-interval of the local end, min-rx-interval of the peer end)
7.12.1.13 Why the Packet Count Stops Increasing When the Session Goes Up?
The process before the session goes up is the negotiation process. The packets sent before the
session goes up are negotiation packets. If the device is based on hardware forwarding,
negotiation packets are processed by the software. In this case, packets are visible to the
software, and therefore, the packets can be counted. You can obtain the packet count from
debugging information.
After the session goes Up, session-sent packets are called detection packets. Detection packets
are forwarded through the hardware. Therefore, the packets are invisible to the upper-layer
software. As a result, the packet count does not increase. After BFD packet debugging is
enabled, you still cannot view packet transmission or receiving. The function of periodically
querying the statistics of BFD packets synchronizes the number of packets on the device to
the software periodically. The number of packets thus increases in batches after a certain
period.
If the device is based on software forwarding, you can view the packet count and debugging
information at any time.

7.12.1.14 Why Does the BFD Session in the Down State Remain Down After
Receiving a Packet Indicating the Up State?
After a BFD session goes up through status negotiation, the BFD session at one end of the
link detects a link fault when the link fails intermittently. In this case, the BFD session at this
end of the link goes down and a BFD packet indicating the Down state of this end is sent to
the peer end of the link. Before the BFD session at the peer end of the link receives the BFD
packet, however, a BFD packet indicating the Up state of the peer end is sent to this end. In
this case, the BFD session at this end does not process the packet and its status remains
unchanged. Otherwise, the BFD session at this end flaps.
7.12.1.15 Does Any Change in the Tx or Rx Parameter Result in BFD Session

Flapping?
A change in the Tx or Rx parameter does not result in BFD session flapping.
BFD parameter changes are negotiated through the P bit and F bit in a BFD packet. In this
manner, a change in the Tx or Rx parameter does not result in BFD session flapping. To
increase the value of the Tx parameter or decrease the value of the Rx parameter, one end
needs to negotiate with the peer end through the P bit and F bit in a BFD packet. One end can
increase the value of the Rx parameter or decrease the value of the Tx parameter without
negotiating with the peer end.
For example, if the local end intends to increase the value of the Tx parameter, it constructs a
BFD packet with the P bit as 1 and the F bit as 0 and sends it to the peer end. This packet
carries the new Tx parameter. After receiving the packet, the peer end updates its detection
time according to the new Tx parameter and replies to the local end with a BFD packet with
the P bit as 0 and the F bit as 1. The local ends changes its transmission intervals after
receiving the reply. If the local end receives no reply from the peer end, the local end keeps
sending the BFD packet and its transmission interval remains unchanged. This ensures that a
change in the Tx or Rx parameter does not affect the status of BFD sessions.
7.12.1.16 How Long Does It Take for a BFD Session to Go Up After It Is

Established?
It is determined by the transmission interval of the BFD session in the negotiation stage, that
is, the transmission interval of the BFD session in the Down state. You can adjust the interval
as required. The actual transmission interval is the product of the value defined in the
specification and a random value ranging from 1 to 1.5.
7.12.1.17 What Are the Four Parameters of a Dynamic BFD Session?

The four parameters are the source IP address, destination IP address, interface index, and
VRF index of the bound VPN.
7.12.1.18 BFD for IFNET, Also Called BFD for Interface or Interface Status
Association, Is a Widely Used Feature of BFD. What Are the Purpose and Typical
Scenarios of This Feature?
Using the process-interface-status command on a multicast BFD session enables interface
status association. When the status of the multicast BFD session changes, BFD notifies the
change in IFNET BFD status. If you run the display this interface command in the interface
view in this case, you can view that the protocol status is UP(BFD Status Down). At the same

time, IFNET reports the Vlink to the route management (RM) module to withdraw the host
routes and network segment routes on the interface.
The applicable environment of BFD for IFNET is as follows: When a transmission device
exists between two devices and a fault occurs on the transmission device, the two devices
need a long time to detect the fault. As a result, the direct route becomes ineffective after a
long time, and network interruption lasts for a long time. Additionally, BFD for IFNET is
often used in TE FRR.
7.12.1.19 What Is BFD for PST?

PST is short for port status table. An interface is in the Up or Down state. A PST can be used
to guide packet forwarding. BFD for PST is widely used in FRR. After the process-pst
command is used in a BFD session that is bound to an interface, the device can associate the
BFD session with the PST of the interface. When the BFD session detects a fault and goes
down, the corresponding bit in the PST for the interface is set to Down. As a result, an FRR
switchover occurs.
In BFD for PST, the notification of modifying the PST is sent to the interface board rather
than the main control board. This saves the time for cross-board communications and reduces
fault notification time.
7.12.1.20 When the process-interface-status Command Is Run, the System

Displays "Error: A BFD session has been configured with process-interface-
status." What Does This Error Prompt Mean?
If multiple BFD sessions are bound to the same interface, you can configure the process-
interface-status command in only one BFD session. That is, the status of only one BFD
session affects the BFD status of the bound interface.
7.12.1.21 When Different Applications Share the Same BFD Session and Set
Different Values of TX and RX Parameters, Which Value Does the BFD Session
Adopt?
The BFD session adopts the minimum values of Tx and Rx parameters configured for all
applications because the maximum values may be unable to satisfy the requirements of
multiple applications for the transmission interval. The transmission interval indicates the
packet transmission capability of BFD. For example, if an application is configured with a
small packet transmission interval, it indicates that BFD supports this packet transmission
interval on the device.
7.12.1.22 During the Configuration of Dynamic BFD for IS-IS, If Tx and Rx

Parameters Are Both Set on an Interface Through the isis bfd enable Command
and Configured Globally in the IS-IS View, Which Configuration of the
Parameters Takes Effect?
The configuration on the interface takes effect.
7.12.1.23 What Is the Range of the Source Port Number of BFD Protocol Packets?
The source port number of BFD protocol packets ranges from 49152 to 65535. The value is
uniquely determined by the configured local descriptor of a BFD session.

7.12.1.24 Why No Corresponding BFD Session Is Available After Static BFD Is

Configured?
After configuring a static BFD session, you need to run the commit command to commit the
configuration. Otherwise, the BFD session cannot be created.
7.12.1.25 Why Does a Dynamic BFD Session Fail to Be Created?

In the case of BFD for routing protocols (including OSPF, IS-IS, and BGP), do as follows:
1. Check whether the neighbor relationship is established.
2. Run the display rm bfd-session command to check whether the RM triggers the
establishment of a BFD session.
3. If the neighbor relationship is established, and the RM triggers the establishment of a
BFD session, enable the BFD debugging and locate the fault.
7.12.1.26 How to Handle the Situation that a BFD Session Is Successfully Created
But Remains Down?
1. Run the ping -m time command to check whether the link works properly.
2. If the link works properly, check whether packets are normally transmitted on the BFD
session.
3. If packets are received, contact Huawei technical personnel. If no packets are received,
check whether faults occur during packet forwarding.
If the session is of the BFD for IP type, you need to check whether the TTL command is used
in the BFD view. Using the TTL command in the BFD view may cause inconsistency of TTL
values at the two ends of a BFD session.
7.12.1.27 What Are the TTL Values of BFD-related Features?

l For a session of the BFD for IP type, you can set the TTL of the BFD packet. If you do
not run the TTL command to set the TTL value, the following default values are
adopted:
– Static and single-hop: 255
– Static and multi-hop: 254
– Dynamic and single-hop: 255
– Dynamic and multi-hop: 253
l For a session of the BFD for LSP/TE/PW type, the default TTL is 1.
l For a session of the BFD for VSI PW type, the default TTL is 255.
7.12.1.28 When the BFD for Static LSP Session and BFD for Dynamic LSP Session
Coexist (the Two BFD Sessions Are of the Same FEC), Which BFD Session Will
Take Effect?
When BFD sessions for detecting a static LSP and a dynamic LSP that has the same FEC with
the static LSP coexist, only the BFD session for detecting the dynamic LSP takes effect.

7.12.1.29 What Defines the Default Minimum Tx and Rx Values?

The default minimum sending interval (Tx) and the default minimum receiving interval (Rx)
of a BFD session are specified by PAF_LCS_BFD_TX_RX_INTERVAL in a PAF file.
7.12.1.30 What Are the Meanings of Two Items in the display bfd session all
verbose Command Output?
The display bfd session all verbose command displays detailed information about a BFD
session.
[HUAWEI] display bfd session all verbose
--------------------------------------------------------------------------------
Session MIndex : 16384 (Multi Hop) State : Up Name : auto
--------------------------------------------------------------------------------
Bind Session Type : Static_Auto
Bind Interface : -
Bind Source IP Address : 89.1.1.1
Proc Interface Status : Disable Process PST : Disable
WTR Interval (ms) : -
Active Multi : 6
Last Local Diagnostic : Control Detection Time Expired
Bind Application : AUTO
PDT Index : FSM-F000000 | RCV-0 | IF-F090000 | TOKEN-0
--------------------------------------------------------------------------------
In the command output, the meanings of the following items are as follows:
l Local Detect Multi: indicates the detection multiplier set on the local end.
l Active Multi: indicates the actual detection multiplier, which is the detection multiplier
set on the peer end.
NOTE
When a system receives a BFD control packet from a peer, the system compares the Required Min Rx
Interval (RMRI) carried in this packet with the local Desired Min Tx Interval (DMTI). The system
selects the longer interval from the RMRI and the DMTI for sending BFD control packets. The system
selects a slower rate for sending BFD control packets. The detection multipliers (Detect Multi values)
are set on the two systems of a BFD session separately without being negotiated.
The detection period of a BFD session in demand mode and that in asynchronous mode are
calculated using different Detect Multi values.
l In asynchronous mode: Detection period = Received Detect Multi x Max (Local RMRI,
Received DMTI)
l In demand mode: Detection period = Local Detect Multi x Max (Local RMRI, Received
DMTI)
The parameters in the preceding formulas are as follows:

l DMTI: indicates the desired minimum interval for sending BFD packets on the local end.
l RMRI: indicates the supported minimum interval for receiving BFD packets on the local
end.
l Detect Multi: indicates the detection multiplier.
7.12.1.31 Why Must a BFD Session Take Less Time to Detect a Trunk Member
Interface Than It Takes to Detect a Trunk Interface?
A BFD session must take less time to detect a trunk member interface than it takes to detect
the trunk interface. This ensures that the BFD session can still detect a failure on the trunk
interface if its trunk member interface fails.
7.12.1.32 What Is the Meaning of the C Bit in a BFD Control Packet?

A BFD control packet is encapsulated by UDP for transmission. Figure 7-41 shows the
format of a BFD control packet.
Figure 7-41 BFD control packet format

0 2 7 9 10 11 1213 14 15 23 31
Vers Diag Sta P F C A D R Detect Mult Length
My Discriminator
Your Discriminator
Desired Min TX Interval
Required Min RX Interval
Required Min Echo RX Interval
Auth Type (optional) Auth Len (optional) Authentication Data... (optional)
The C bit indicates whether the control plane is separated from the forwarding plane. The
value can be:
l 1: indicates that the control plane is separated from the forwarding plane.
l 0: indicates that the control plane is associated with the forwarding plane.
7.12.2 VRRP
7.12.2.1 Why Cannot the VRRP Status Be Switched Properly After STP Is
Enabled?
The problem is as follows:
On a network shown in Figure 7-42, a VRRP backup group is configured on Router B and
Router C. Router B functions as a master device and Router C functions as a backup device.
A VRRP Advertisement packet is broadcast from Router B to Router C and passes through
Router D using a Layer 2 forwarding method. Assume that Router D is enabled with STP.
When a link is recovering from a failure, the VRRP backup group status cannot be switched
properly.

Figure 7-42 Networking diagram of a VRRP backup group in a scenario where STP is
enabled on a forwarding device
RouterB
GE2/0/1 GE2/0/2
GE4/0/1
RouterA GE4/0/2
GE3/0/1 GE3/0/2 RouterD
RouterC
Possible phenomena are as follows:

l The backup device in the VRRP backup group becomes the master device after the timer
for receiving a VRRP Advertisement packet expires.
l Two master devices may coexist for a short time, thus causing service interruption.
l After the network becomes stable, Router B becomes the backup device, and Router C
becomes the master device.
After Router D is enabled with STP, STP re-calculates the route of the link between Router B
and Router D if the link fails, thus blocking GE 4/0/1 on Router D. After the link between
Router B and Router D recovers, Router D sends a BPDU to Router B. Router D, however,
cannot receive the BPDU from Router B because Router B is not enabled with STP. GE 4/0/1
is unblocked only after the timeout period (with the default interval being 30s) for waiting a
BPDU expires. Then, the network becomes stable. During the timeout period, Router B
becomes the master device because it does not receive a VRRP Advertisement packet from
Router C. Then, two master devices coexist.
In this case, you can perform one of the following operations:
l Disable STP globally on Router D. On an actual network, if STP is enabled only on one
device, it does not take effect.
l On Router D, disable STP on interfaces connected to VRRP devices.
l Enable STP on Router B, Router C, and Router D.
NOTE
l If STP is globally enabled on Router D, by default, all interfaces on Router D are enabled with
STP.
l If STP is also enabled on Router B and Router C, the more complex the networking, the more time
STP takes to unblock the interface. If the time STP takes to calculate a reachable route and then
unblock interfaces is longer than VRRP timeout period, it means that enabling STP on either
Router B or Router C cannot prevent temporary coexistence of two master devices.
7.12.2.2 How Does a VRRP Backup Group Track the BFD Session Status?

Tracking the Status of an Ordinary BFD Session

1. A VRRP backup group tracks the status of an ordinary BFD session in either Increase
mode or Reduce mode. As a BFD session fast detects a failure, a VRRP backup group
fast detects the changed link status by tracking the BFD session status and then fast
performs a master/backup switchover. Devices will increase their priorities in a VRRP
backup group that is tracking the BFD status in Increase mode if a BFD session goes
Down. The Increase mode takes effect only on backup devices. Devices will reduce their
priorities in a VRRP backup group that is tracking the BFD status in Reduce mode if a
BFD session goes Down. The Reduce mode takes effect on both master and backup
devices.
2. The configurations of tracking the BFD session status are as follows:
– After BFD is enabled, an ordinary BFD session will fast detect a failure on a link
between Router A and Router B in milliseconds if a failure occurs on the link or a
host.
– By tracking the status of an ordinary BFD session, the VRRP backup group can fast
detect the link status after the ordinary BFD session notifies the VRRP backup
group of a link failure.
– Devices in a VRRP backup group adjust their priorities according to the status
notified by BFD, or a device in a VRRP backup group performs a fast switchover to
start a preemption process.
– A VRRP backup group can track the status of a maximum of eight BFD sessions.
– A VRRP backup group can perform a master/backup switchover within 200 ms by
tracking the BFD session status.
3. Take an application scenario as an example.
Figure 7-43 Networking diagram of tracking the status of an ordinary BFD session
RouterA RouterB
Switch
On a network shown in Figure 7-43, VRRP is enabled on Router A and Router B. Router A
functions as a master device and Router B functions as a backup device. User traffic is
forwarded by Router A. A BFD session is established between Router A and Router B. The
VRRP backup group tracks the BFD session status. If the BFD session status changes,
priorities of the two devices in the VRRP backup group are changed and then a master/backup

switchover is performed. When the BFD session detects a failure on a link between Router A
and Router B, a Down event is notified to VRRP. Then, the priority of Router B in the VRRP
backup group increases, which becomes higher than the priority of the VRRP backup group
on Router A. As a result, a master/backup switchover is performed. Router B then becomes a
master device and subsequent user traffic will be forwarded by Router B.
Tracking the Status of Link and Peer BFD Sessions

1. Link and peer BFD sessions are similar to an ordinary BFD session except for their
distinct characteristics. All of these BFD sessions can detect failures on a link or the
devices at both ends of the link, and VRRP can track the status of these BFD sessions to
fast perform a master/backup switchover in milliseconds. By tracking the BFD session
status, a VRRP backup group performs a master/slave switchover by changing priorities
of devices in the VRRP backup group, which is similar to the means of tracking the
interface status. By tracking the status of the peer BFD session and link BFD session, a
VRRP backup group directly performs a master/slave switchover without changing
priorities in the VRRP backup group. A peer BFD session can detect failures on both
NPEs on two ends of a session and the local and remote links. The peer BFD session,
however, cannot identify whether the local or remote NPE fails or whether the local or
remote link fails. A link BFD session can only detect failures on a local link and a local
NPE.
2. The configurations of tracking the BFD session status are as follows:
– Two NPEs are enabled with VRRP.
– A peer BFD session is created between the two NPEs.
– Link BFD sessions are created between a UPE and the two NPEs.
– A VRRP backup group is configured to track both the link BFD sessions and the
peer BFD session.
3. Take an application scenario as an example.
Figure 7-44 Networking diagram of tracking the status of link and peer BFD sessions
NPE
Link BFD
Peer
BFD
UPE
Link BFD
NPE
On a network shown in Figure 7-44, VRRP is run on two NPEs. A peer BFD session is set up
to detect link and device failures between NPEs; two link BFD sessions are established to
detect link and device failures between the NPEs and a UPE.

7.12.2.3 How to Identify the Interface That Has Sent Incorrect Packets After a
Large Number of TTL Error Log Messages Are Generated on a Device in a VRRP
Backup Group?
Follow the procedures below to identify the faulty interface:
1. Check the cached log messages. It is found that a large number of VRRP
DETECTPACKETERROR log messages are generated, indicating that the system may
be attacked by VRRP packets.
[HUAWEI] display logbuffer
Logging buffer configuration and contents:enabled
Allowed max buffer size : 1024
Actual buffer size : 10
Channel number : 4 , Channel name : logbuffer
Dropped messages : 0
Overwritten messages : 47222
Current messages : 10
Nov 13 2009 09:30:11 LMT-NSP-34 %%01VRRP/3/DETECTPACKETERROR(l): System
detected a VRRP packet error: PACKET TTL ERROR!
2. Check statistics about VRRP packets. Identify the VRRP backup group that has received
incorrect VRRP packets. Then identify the interface where the VRRP backup group
resides.
[HUAWEI] display vrrp statistics
Checksum errors :
0
Version errors :
0
Vrid errors :
0
Vlanif2012 | virtual router 2

Transited to master :
1
Received advertisements :
1096283
Advertisement interval errors :

0
Failed to authentication check :

0
Received ip ttl errors :

9101624
Received packets with priority zero :

Sent packets with priority zero :

0
Received invalid type packets :

0
Received unmatched address list packets :

0
Unknown authentication type packets :

0
Mismatched authentication type :

0
Packet length errors :

0
Discarded packets since track admin-vrrp : 0
The command output shows that VRRP backup group 2 has received a large number of
incorrect VRRP packets and VRRP backup group 2 is configured on VLANIF 2012.
3. Identify the interface that has sent the incorrect packets. If the VRRP backup group is
configured on a VLANIF interface that has received the incorrect packets, go to the next
step.
a. Check which member interfaces join this VLANIF interface.
VLAN ID Type Status MAC Learning Broadcast/Multicast/Unicast
Property
-------------------------------------------------------------------------
-------
2012 common enable enable forward forward forward default
----------------
Untagged Port: GigabitEthernet2/0/17 GigabitEthernet5/0/5
----------------
Tagged Port: GigabitEthernet2/0/2 GigabitEthernet2/0/6
----------------
Interface Physical
GigabitEthernet2/0/2 UP
b. Check statistics about VRRP packets on each VLANIF member interface. If a

member interface is receiving packets at an increasing rate, it indicates that the
member interface is the one that has sent the incorrect packets.
[HUAWEI] display interface GigabitEthernet 2/0/6
Description:HUAWEI, Quidway Series, GigabitEthernet2/0/6 Interface
Switch Port,The Maximum Transmit Unit is 1500
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is
0018-823c-c449
Media type: twisted-pair ,Link type: auto negotiation
Loopback:none, Maximal BW:1G, Current BW:100M, full-duplex mode,
negotiation: enable, Pause Flowcontrol:Receive Enable and Send Enable
Input:


Overrun: 0 packets
RxPause: 0 packets
Output:
Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
TxPause: 0 packets
4. Display information about the incorrect packets on the member interface.

Check the source MAC addresses in the incorrect VRRP packets.
[HUAWEI] debugging ethernet packet verbose interface GigabitEthernet 2/0/6
*0.48757426 LMT-NSP-34 ETH/7/eth_rcv:Slot=2;Receive an Eth Packet,
interface : GigabitEthernet2/0/6, eth format: 0, length: 100, pro
totype: 8100 othertype, src_eth_addr: 0000-5e00-0102, dst_eth_addr:
0100-5e00-0012
*0.48757426 LMT-NSP-34 ETH/7/eth_verbose:Slot=2; 01 00 5E 00 00 12 00 00 5E
00 01 02 81 00 07 DC
*0.48757426 LMT-NSP-34 ETH/7/eth_verbose:Slot=2; 08 00 45 C0 00 28 CA 26 00
00 64 70 A0 08 0A 01
*0.48757427 LMT-NSP-34 ETH/7/eth_verbose:Slot=2; 01 64 E0 00 00 12 21 02 96
01 00 01 3D F9 0A 01
*0.48757427 LMT-NSP-34 ETH/7/eth_verbose:Slot=2; 01 01 00 00 00 00 00 00 00
00 00 00 00 00 00 00
5. Restrain the member interface from sending incorrect packets.

It is recommended that the member interface be restrained from sending these incorrect
packets, thus restoring normal CPU operation as soon as possible.
7.12.2.4 Why Is There Only Logs Indicating that a Backup Device Is Switched to a
Master Device, but Not Logs Indicating that a Master Device Is Switched to a
Backup Device?
l Normally, after a master device receives a VRRP Advertisement packet with the priority
being 0, a log indicating the event that a backup device has been switched to a master
device is displayed. Sending such a VRRP Advertisement packet simulates a status
change from Backup to Master to trigger the sending of a gratuitous ARP packet. In this
case, the device remains in the Master status.
l On a device that is in either the Master state or the Backup state, the device switches the
status from Backup to Master after receiving a VRRP Advertisement packet with the
priority being 0 and then displays an associated log.
l In addition, a VRRP Advertisement packet with the priority being 0 will be sent, only if
the master device receives a VRRP Advertisement packet carrying a priority higher than
the local priority, or if the interface (in Master state) on which the VRRP backup group is
created goes Down. A backup device in a VRRP backup group does not send a VRRP
Advertisement packet with the priority being 0.
7.12.2.5 What Are the Formats of Two Types of Packets Sent by VRRP Backup
Groups?
VRRP backup groups send either VRRP Advertisement packets or gratuitous ARP packets.

VRRP Advertisement Packets

A VRRP Advertisement packet is encapsulated by IP. Its contents are as follows:
l Source MAC address: is the virtual MAC address of a VRRP backup group. The virtual
MAC address is in the format of 000-5e00-01+VRID.
l Destination MAC address: is 0100-5e00-0012, a multicast MAC address.
l Source IP address: is the primary IP address for the interface of a VRRP backup group.
l Destination MAC address: is 224.0.0.18, a multicast IP address.
l VRRP protocol number: is 0x70.
NOTE
When a device in a VRRP backup group is in the non-Master state, or when the device in a VRRP
backup group sends a VRRP Advertisement packet with the priority being 0, the source MAC address
carried in the VRRP Advertisement packet is the MAC address of a physical interface.
A VRRP Advertisement packet provides either of the following functions:

l Negotiates the state machine.
l Refreshes the MAC address entries of downstream switches. This function is applicable
in the situation where switches exist between two VRRP devices.
If an mVRRP backup group and service VRRP backup groups are configured, only the
mVRRP backup group, rather than the service VRRP backup groups, sends VRRP
Advertisement packets.
Gratuitous ARP Packets Sent by a VRRP Backup Group

l Source MAC address: is the virtual MAC address of a VRRP backup group, in the
format of 000-5e00-01+VRID.
l Destination MAC address: is all 0s, a broadcast MAC address.
l Source IP address: is the same as the destination IP address. Both of them are the virtual
IP address of a VRRP backup group.
A gratuitous ARP packet is sent when a VRRP backup group enters the Master state. A
gratuitous ARP packet provides either of the following functions:
l Refreshes the MAC address entries of downstream switches.
l Enables users attached to switches to learn a MAC address by receiving the ARP entries
carried in packets.
If an mVRRP backup group and a service VRRP backup group are configured, both the
mVRRP and service VRRP backup groups send gratuitous ARP packets after both of them
enter the Master state.
7.12.2.6 How to Determine the Master and Slave Status in a VRRP Backup Group
in the Situation Where Two Virtual IP Addresses Assigned to It Are Two
Addresses of Interfaces Configured with the VRRP Backup Group?
The device on which the VRRP backup group is first configured functions as a master device,
and the other device functions as a backup device.

7.12.2.7 Up to Eight Interfaces on a HUAWEI NetEngine40E/80E Are Tracked by

an Unlimited Number of VRRP Backup Groups, Why?
Which Understandings of a Maximum of Eight Trackable Interfaces Is Correct, Only Up to
Eight Interfaces on a HUAWEI NetEngine40E/80E Are Tracked by an Unlimited Number of
VRRP Backup Groups, or Only Up to Eight Inbound Interfaces Are Tracked by Each VRRP
Backup Group on a HUAWEI NetEngine40E/80E?
A VRRP backup group tracks the status of a maximum of eight interfaces, and multiple
VRRP backup groups track the status of the same interface.
NOTE
The number of trackable interfaces on a HUAWEI NetEngine40E/80E is not limited but depends on the
number of configured VRRP backup groups.
7.12.2.8 How to Negotiate the Master and Backup Status of Devices with the
Same Priority but Different IP Addresses in a VRRP Backup Group?
When the link is normal, a master device in a VRRP backup group sends VRRP
Advertisement packets to backup devices to negotiate the master and backup status. The
VRRP Advertisement packets carry priorities. If a device receives a VRRP Advertisement
packet with a priority the same as the local priority, the device compares the carried IP
address with the local IP address. Then, the device with a larger IP address preempts to be a
master device.
7.12.2.9 How Does Proxy ARP Function When Multiple IP Addresses Are
Mapped to One Virtual MAC Address in ARP Entries?
The answers are as follows:
l When two users belonging to different VLANs need to communicate with each other,
proxy ARP needs to be configured on VLAN sub-interfaces. Interfaces enabled with
inter-VLAN proxy ARP do not directly discard ARP Request packets that are not sent to
themselves. Instead, they search the ARP mapping table for the destination MAC
address. If the destination MAC address is found, interfaces send the MAC address of
the proxy router to the senders of the ARP requests.
Inter-VLAN proxy ARP provides the following functions:
– Enables users on different VLANs to communicate with each other.
– Enables users on different sub-VLANs to communicate with each other.
l If a VRRP-enabled Ethernet interface is configured with proxy ARP, intra-VLAN proxy
ARP, or inter-VLAN proxy ARP, proxy ARP on such an interface functions differently
from proxy ARP on other interfaces. Proxy ARP on such an interface responds to a
request based on both the number of VRRP backup groups and the VRRP backup group
status on this interface. Either of the following situations may occur:
– If only one VRRP backup group is configured on the interface, proxy ARP
responds to an ARP Request packet as follows:
n If the device in the VRRP backup group is in the Master state, proxy ARP
replies to the ARP Request packet using the virtual MAC address of the VRRP
backup group.
n If the device in the VRRP backup group is in the Backup state, proxy ARP
does not reply to the ARP Request packet.

– If multiple VRRP backup groups are configured on the interface, proxy ARP
responds to an ARP Request packet as follows:
n If the device in all VRRP backup groups are in the Master state, proxy ARP
replies to the ARP Request packet using one of virtual MAC addresses of
these VRRP backup groups.
n If the device in all VRRP backup groups is in the Backup state, proxy ARP
does not reply to the ARP Request packet.
7.12.2.10 How to Distinguish BFD Sessions When a VRRP Backup Group Tracks
the Status of BFD Sessions with Automatically-Negotiated Discriminators?
You can specify either the name or the local discriminator of a BFD session to be tracked by a
VRRP backup group. Either a BFD session name or a local discriminator uniquely identifies a
BFD session.
7.12.2.11 Why Cannot a Preemption Delay on a Device Functioning as the IP

Address Owner Take Effect?
When the IP address of an interface on which a VRRP backup group is set up functions as a
virtual IP address, the involved device is the IP address owner of the VRRP backup group.
When the device operates properly, it responds to packets with the destination address being
the virtual IP address.
A preemption delay refers to a delay period of time a backup device takes to become a master
device. If the IP address owner recovers from a failure, it directly becomes a master device
without waiting for expiration of the preemption delay. This indicates that the IP address
owner is irrelevant to the preemption delay.
NOTE
For a VRRP backup group that needs to support the preemption delay, the master device cannot be
configured as the IP address owner.
7.12.2.12 Can a VRRP Backup Group Be Established by Using a Secondary IP

Address?
Yes. A VRRP backup group can be established by using a secondary IP address.
7.12.2.13 After an NQA Test Instance Is Deleted, Why Can the Configuration of
Associating VRRP with NQA Be Still Restored?
Problem Phenomenon
After you configure VRRP association with NQA, perform the following operations:
l Power off the board on which the VRRP backup group resides.
l Delete the NQA test instance associated with the VRRP backup group.
l Power on the board on which the VRRP backup group resides.
The board then enters the configuration restoration procedure.
After the configuration restoration is complete, run the display current-configuration
interface interface-type interface-name command to view the configuration file for VRRP
association with NQA. For example:

<HUAWEI> display current-configuration interface gigabitethernet3/0/0

#
undo shutdown
admin-vrrp vrid 5
vrrp vrid 5 track nqa 1 1
undo dcn
#
return
Cause Analysis
1. After you power off the board on which the VRRP backup group resides, the VRRP
module deletes the VRRP backup group and its configurations, including the
configuration of associating VRRP with NQA.
2. After you delete the NQA test instance, the NQA module notifies the VRRP module of
the deletion event. Because the VRRP backup group has been deleted, the VRRP module
does not process the deletion event.
3. After you power on the board on which the VRRP backup group resides, the VRRP
module enters the configuration restoration procedure. By default, the NQA
configuration is restored after the global and interface configurations are restored.
Therefore, the VRRP module directly restores the configuration of associating VRRP
with NQA without checking whether the NQA test instance exists during configuration
restoration.
After the configuration is restored, the VRRP module sets the status of VRRP association
with NQA to Ignore when detecting that the NQA test instance does not exist. The status of
the VRRP backup group does not change, and therefore services are not affected.
7.12.3 Eth-OAM
7.12.3.1 Can EFM OAMPDUs Be Transmitted Between Different VLANs?

l EFM OAMPDUs do not carry VLAN tags and are only used to detect direct links. After
an interface receives EFM OAMPDUs, the interface does not forward them.
l EFM OAM detection is irrelevant to VLANs. If two interfaces on a direct link are added
to different VLANs, EFM OAM can still be used to detect the direct link.
7.12.3.2 Can Ethernet CFM Be Used to Detect Links Between Trunk Member
Interfaces?
Ethernet CFM can be used to detect links between trunk member interfaces. To be specific,
the port CC function can be enabled to detect the links.
Figure 7-45 Networking diagram of the CC detecting function
GE1/0/0 GE1/0/0
RouterA RouterB

As shown in Figure 7-45, the Eth-Trunk member interface on Router A is GE 1/0/0 and the
Eth-Trunk member interface on Router B is GE 1/0/0. After the following configurations,
Ethernet CFM can be used to detect the link between the two Eth-Trunk member interfaces.
Do as follows on Router A:
[RouterA] cfm md md1
[RouterA-md-md1] ma ma1
[RouterA-md-md1-ma1] remote-mep mep-id 2
[RouterA-md-md1-ma1] mep mep-id 2 interface GigabitEthernet 1/0/0 outward
[RouterA-md-md1-ma1] mep ccm-send mep-id 2 enable
[RouterA-md-md1-ma1] remote-mep ccm-receive mep-id 2 enable
Do as follows on Router B:
[RouterB] cfm md md1
[RouterB-md-md1] ma ma1
[RouterB-md-md1-ma1] remote-mep mep-id 1
[RouterB-md-md1-ma1] mep mep-id 1 interface GigabitEthernet 1/0/0 outward
[RouterB-md-md1-ma1] mep ccm-send mep-id 1 enable
[RouterB-md-md1-ma1] remote-mep ccm-receive mep-id 1 enable
7.12.3.3 What Are the Differences Between 802.1ag MAC Ping and Generic
GMAC Ping?
802.1ag MAC Ping

Similar to the ping operation, the 802.1ag MAC ping checks whether the destination device is
reachable by sending test packets and receiving response packets. After being triggered by
commands, the 802.1ag MAC ping detects the fault on the link between the local device and
the destination device.
The local device must be an MEP; the destination device can be an MEP or an MIP with the
same level as that of the local MEP. The local device and the destination device can be in the
same MA or in different MAs.
Figure 7-46 Principle of the 802.1ag MAC ping
RouterB
MEP2
LBM LBR
MEP3
MEP1
RouterA
MEP LBM data flow

LBR data flow

As shown in Figure 7-46, MEP1 initiates the 802.1ag MAC ping to MEP2. The process is as
follows:
1. MEP1 sends a Loopback Message (LBM) to MEP2. The LBM must carry information
about MEP2, either the MAC address or the MEP ID.
2. After receiving the LBM, MEP2 responds with a Loopback Reply (LBR). MEP1
calculates the period of the ping operation to analyze network performance.
Within a specified timeout period, if MEP1 receives no LBR from MEP2, MEP1
considers that MEP2 is not reachable; if MEP1 receives the LBR from MEP2 within the
timeout period, MEP1 can figure out the delay from MEP1 to MEP2 based on the
timestamp carried in the LBR. In addition, MEP1 can send multiple LBMs continuously
and then observe how many LBRs are sent back. This helps to find out the packet loss
ratio on the network.
Generic MAC Ping
Figure 7-47 Principle of the generic MAC ping

RouterB
LBM LBR
RouterA
LBM data flow

LBR data flow
As shown in Figure 7-47, the generic MAC ping has the similar principle as that of the
802.1ag MAC ping. The difference is that the local device does not need to be an MEP and
the destination device does not need to be an MEP or an MIP. In other words, the generic
MAC ping can be implemented without the need to configure MD, MA, or MEP on the local
device, intermediate device, and destination device, and the only requirement is to enable the
generic MAC ping function on the intermediate device. Therefore, the generic MAC ping is
applicable to the network (or part of the network) where MD, MA, and MEP are not
configured for trouble shooting.
1. Router A sends an LBM to Router B. The LBM must carry information about the MAC
address of B and the ID of the VLAN or VSI to which the generic MAC ping operation
is bound.
2. After receiving the LBM, Router B responds with an LBR. Then, Router A calculates the
period of the ping operation to analyze network performance.

7.12.3.4 Can You List the Advantages and Disadvantages of BFD and EFM OAM?
Advantages of BFD:
1. BFD provides light-load and short-period failure detection for channels between adjacent
forwarding engines.
2. BFD uses a universal mechanism to detect all media and protocol layers in real time and
supports various detection time and costs.
3. BFD is a universal detection mechanism for the entire network. It is used to quickly
detect and monitor forwarding states of IP routes or link connections on the network.
BFD can be used both to detect forwarding engines or interfaces and to detect links from
end to end.
Advantages of EFM OAM:
1. EFM OAM detects the quality and effectiveness of links.
2. If the event that the number of error frames or error codes exceeds the upper limit or the
errored frame second event is detected on an interface, the local device generates a trap
and reports the trap to the NMS, and then advertises the fault to the peer device through
EFM OAMPDUs.
3. EFM OAM supports fault notification. If a fault, such as system reboot, interface board
reset, physical status of an interface going Down, or physical link failure, occurs on the
local device, the local device notifies the peer device of the fault by sending EFM
OAMPDUs, and then writes the fault event to the log and reports the log to the NMS.
4. EFM OAM supports the remote loopback function. When the local end sends non-EFM
OAMPDUs to the peer end, the peer end sends these PDUs to the local end, instead of
forwarding these PDUs based on their destination addresses. This is called remote
loopback. Remote loopback can be used to locate faults and test link performance.
Disadvantages of EFM OAM: The interval at which EFM OAM detects a direct link is one
second, which cannot be modified by users. Different from EFM OAM, BFD can implement
the link detection in milliseconds, and the interval can be modified by users through the
relevant command line.
7.12.4 NQA
7.13 User Access
7.13.1 What Is the Sequence of Authentication Modes in AAA?

After the authentication-mode local radius command is run, a user can log in successfully if
the user account is not created on the local device but exists on the RADIUS server.
After the authentication-mode radius local command is run, a user fails to log in if the user
account is not created on the RADIUS server but exists on the local device.
Summary:
l In authentication-mode local radius mode, if a user account cannot be found and no
backup authentication mode is specified, the user fails the authentication; if a user
account cannot be found but a backup authentication mode such as RADIUS
authentication is specified, the user is to be authenticated in backup authentication mode.

l In authentication-mode radius local or authentication-mode hwtacacs local mode, if

a user account cannot be found on the RADIUS or HWTACACS server or the password
is incorrect, the user fails to log in.
7.13.2 Why Is the User Logged Out Ten-Plus Seconds After the
RADIUS Server Becomes Faulty and the User Alternatively Logs
in Through Local Authentication?
The user may be logged out because the RADIUS server is faulty and cannot implement
accounting. No accounting scheme is required if the user is only to be authenticated.
The period after which the user is logged out is determined by radius-server timeout and
radius-server retransmit. The default values of radius-server timeout and radius-server
retransmit are respectively 5 seconds and 3 times. Therefore, the user is logged out after
about 15 seconds.
7.13.3 Why Is the Log Indicating that the RADIUS Server Is Down
Generated When the User Uses a Local Account to Log in to the
router?
Fault Description:
After the authentication-mode radius local mode is configured, different user accounts and
passwords are required by RADIUS authentication and local authentication. The RADIUS
server functions normally and the route between the router and the RADIUS server is
reachable. The user using the account and password required by RADIUS authentication
passes the authentication; the user using the account required by RADIUS authentication but
an incorrect password fails the authentication. The user using the account and password
required by local authentication also passes the authentication; a log indicating that the
RADIUS server is Down, however, is generated.
RDS/4/RDAUTHDOWN: RADIUS authentication server is down! (IpAddress=[IPADDR])
Cause Analysis:
The NAS sends a request to the RADIUS server, but the RADIUS server does not respond to
the request. Then, the NAS sends requests to the RADIUS server at specific intervals. If the
NAS receives no response after several request attempts, the NAS considers that the RADIUS
server is Down. If local authentication is configured, local authentication is alternatively
adopted at this time.
When a correct user account but an incorrect password are used by a user to log in, the
RADIUS server responds, which prevents local authentication, by directly denying the login
of the user.
The RADIUS server is not Down (the RADIUS server functions normally and is reachable),
but does not respond to the requests of the NAS (the debugging information displays this
event). The possible causes are as follows: The RADIUS server is too busy to respond; the
RADIUS server fails to match the account that is used by the user to log in and therefore does
not respond.
If the RADIUS server does not respond, the router considers that the RADIUS server is Down
and alternatively adopts local authentication. If the RADIUS server responds by denying the
login of the user, the router does not adopt local authentication.

It is probably because the RADIUS server ignores the requests to protect against attacks. As a
result, the router receives no response and considers that the RADIUS server is Down.
7.13.4 The NE40E&NE80E Controls the Online Time of a User

Through the Session Timeout Period Delivered by a RADIUS
Server. Why Does the User Remain Online When the Timeout
Period Expires?
If the RADIUS versions are inconsistent, the restriction to the user online time does not take
effect. If the RADIUS configured on the NE40E&NE80E is of the Portal type (RADIUS+1.1)
whereas the standard RADIUS is configured for the iTellin, the user is not cut off when the
session timeout period expires.
7.13.5 PPPoE User Configured on the NE40E&NE80E Fails to Dial

Up. RADIUS Debugging Information Shows that the
Authentication Success Message Is Received but No Accounting
Packet Is Received?
l The RADIUS server detects that certain attributes of the user are incorrect. For example,
the type of the attribute configured on the RADIUS server does not match that on the
router. As a result, the authentication fails.
l The NE40E&NE80E fails to identify the attributes delivered by the RADIUS server. As
a result, the authentication fails. For instance, the filter ID in the packet whose code is 2
does not exit on the NE40E&NE80E.
7.13.6 How Does the NE40E&NE80E Convert RADIUS Attributes?
The process is as follows:
1. Enter the configuration RADIUS group mode.

[HUAWEI] radius-server group tt
2. Perform either of the following as required:

– To prohibit an attribute, do as follows in the RADIUS group:
n Prohibit the sending function of the NAS-Identifier attribute.
[HUAWEI-radius-tt] radius-attribute disable NAS-Identifier send
[HUAWEI-radius-tt] radius-server attribute translate [HUAWEI-radius-tt]
radius-attribute disable NAS-Identifier receive
[HUAWEI-radius-tt] radius-server attribute translate
– Prohibit the sending and receiving functions of the NAS-Identifier attribute.

[HUAWEI-radius-tt] radius-attribute disable NAS-Identifier receive send
– To convert an attribute, do as follows in the RADIUS group.

n Convert NAS-Port into Nas-port-new in the outbound direction.
[HUAWEI-radius-tt] radius-attribute translate NAS-Port Nas-port-new send

– Convert NAS-Port into Nas-port-new in the inbound direction.

[HUAWEI-radius-tt] radius-attribute translate NAS-Port Nas-port-new receive
– Convert NAS-Port into Nas-port-new in both directions.

[HUAWEI-radius-tt] radius-attribute translate NAS-Port Nas-port-new send
receive
7.13.7 Why Cannot the DHCPv4 Client Obtain an IP Address

From the Remote IP Address Pool in the Case that the BAS and
DHCPv4 Server Are Correctly Configured?
l The gateway of the remote IP address pool on the BAS is not the same as the gateway of
the IP address pool on the DHCPv4 server.
l There is no route from the DHCPv4 server to the network segment of the remote IP
address pool. There must be a route from the DHCPv4 server to the network segment of
the remote IP address pool, with the destination of the route as the gateway of the remote
IP address pool and the outbound interface as the interface connected to the BAS.
7.13.8 What Address Does the router Use to Send L2TP and
RADIUS Packets?
The router sends L2TP packets in the following modes:

l If the RADIUS server delivers the address of the local end of the tunnel through the
Tunnel_Client_Endpoint attribute (No. 66), the router uses this address as the source
address to send L2TP packets to the LNS.
l If the RADIUS server does not deliver the address of the local end, the router uses the
loopback address bound to the L2TP group as the source address to send L2TP packets
to the LNS.
l If no loopback address is bound to the L2TP group, the router uses the IP address of the
interface in the local routing table through which packets can reach the LNS as the
source address of L2TP packets. This interface is usually the uplink interface of the
router.
l When sending RADIUS packets, the router uses the IP address of the interface bound to
the RADIUS server as the source address of the RADIUS packets.
l If no interface is bound to the RADIUS server, the router uses the IP address of the
interface in the local routing table through which packets can reach the RADIUS server
as the source address of the RADIUS packets. This interface is usually the uplink
interface of the router.
7.13.9 What Is the Process of L2TP Tunnel Authentication?
If the tunnel authentication is configured on both ends, the process of L2TP tunnel
authentication is as follows:
l The two ends perform tunnel authentication and establish a tunnel at the same time.

l The LAC first sends a Start-Control-Connection-Request (SCCRQ) to the LNS. At the

same time, a random character string is generated and sent to the LNS as a local CHAP
Challenge. When receiving the Challenge, the LNS combines it with the local password
and Start-Control-Connection-Reply (SCCRP) (defined in 2 RFC) to generate a character
string. The LNS uses MD5 to compute a 16-byte Response. The LNS then sends the
Response to the LAC through the SCCRP; meanwhile a random character string (LNS
Challenge) is generated and sent to the LAC through the SCCRP message.
l Authentication process on the LAC: The LAC combines its own CHAP Challenge with
the local password and SCCRP (defined in 2 RFC) to generate a character string. The
LAC then uses MD5 to compute the 16-byte character string and compares the string
with the CHAP Response that is contained in the SCCRP from the LNS. If they are the
same, the authentication succeeds; otherwise, the authentication fails, and the tunnel is
disconnected.
l Similarly, the LNS needs to authenticate the LAC. When finding the CHAP Challenge in
the SCCRP from the LNS, the LAC adds a local password and Stop-Control-
Connection-Notification (SCCCN) (defined in 3 RFC) to it, uses MD5 to compute a 16-
byte character string, and sends the string to the LNS through the SCCCN. When
receiving the SCCCN, the LNS adds the local CHAP Challenge, local password, and
SCCCN to generate a character string. The LNS then uses MD5 to compute a 16-byte
character string and compares the string with the LAC CHAP Response in the SCCCN.
If they are the same, the authentication succeeds; otherwise, the authentication fails and
the tunnel is disconnected.
7.13.10 If the LNS Is a Device of Huawei But the LAC Is Not,

What Should Be Noted During the Configuration of the LNS?
In this case, the LNS may not support certain parameters that are PPP pre-negotiated by the
LAC and the user, which may cause failure to set up PPP sessions on the LNS. Therefore, you
need to configure PPP renegotiation parameters on the LNS to force the LNS and the user to
perform PPP negotiation again.
7.13.11 If the LAC Is a Device of Huawei But the LNS Is Not,

What Should Be Noted During the Configuration of the LAC?
In this case, the LAC may not support certain parameters that are PPP pre-negotiated by the
LNS and the user, which may cause failure to set up PPP sessions on the LAC. Therefore,
check the negotiable parameters supported by the LAC, and perform proper configuration.
7.13.12 How Can I Jointly Use L2TP Parameters Set on the router
and the RADIUS Server?
There are the following situations:
l In the domain, neither the L2TP group nor the l2tp-user radius-force command is
configured.
In such a situation, users in this domain are not L2TP users and do not set up tunnels,
regardless of whether local authentication or RADIUS authentication is adopted, and
whether the attribute tunnel-type (64) or other L2TP parameters are delivered by the
RADIUS server.

Local users are also not L2TP users.

l In the domain, the l2tp-user radius-force command is configured, but the L2TP group
is not configured.
In such a situation, whether users in the domain are L2TP users is determined by the
attributes delivered by the RADIUS server. If the attribute tunnel-type (64) is delivered
by the RADIUS server and the attribute value is 3, it indicates that users in the domain
are L2TP users, and these users set up tunnels by using other L2TP parameters delivered
by the RADIUS server, such as the IP address of the LNS and the tunnel password (for
details, refer to the instructions for the RADIUS server). If only the attribute tunnel-type
(64) is delivered by the RADIUS server, these users cannot use other parameters to set
up tunnels. As a result, the users fail to log in. If the attribute tunnel-type (64) is not
delivered by the RADIUS server, users in the domain are common users and do not set
up tunnels.
Local users are also common users and do not set up tunnels.
l In the domain, both the L2TP group and the l2tp-user radius-force command are
configured.
In such a situation, whether users in the domain are L2TP users is determined by the
attributes delivered by the RADIUS server. If the attribute tunnel-type (64) is delivered
by the RADIUS server and the attribute value is 3, it indicates that users in the domain
are L2TP users. If other L2TP parameters, such as the IP address of the LNS and the
tunnel password, are delivered by the RADIUS server, the users set up tunnels by using
these parameters. If only the attribute tunnel-type (64) is delivered by the RADIUS
server, the users correctly set other L2TP parameters, such as the IP address of the LNS
and tunnel password, in the L2TP group view, and then set up tunnels; if the users set
other L2TP parameters incorrectly, they cannot set up tunnels and fail to log in. If the
attribute tunnel-type (64) is not delivered by the RADIUS server, users in the domain are
common users and do not set up tunnels.
If users of the local authentication are L2TP users, but they incorrectly set L2TP
parameters in the L2TP group view, these users cannot set up tunnels and fail to log in.
l In the domain, the L2TP group is configured, but the l2tp-user radius-force command
is not configured.
In such a situation, all users in the domain are L2TP users, regardless of whether local
authentication or RADIUS authentication is adopted, and whether the attribute tunnel-
type (64) is delivered by the RADIUS server (if the attribute tunnel-type (64) is delivered
by the RADIUS server, the attribute value must be 3). If other L2TP parameters are
delivered by the RADIUS server, the users use these parameters to set up tunnels; if no
other L2TP parameter is delivered by the RADIUS server, the users correctly set other
L2TP parameters, such as the IP address of the LNS and tunnel password, in the L2TP
group view, and then set up tunnels; if the users set other L2TP parameters incorrectly,
they cannot set up tunnels and fail to log in.
7.13.13 What Configurations Are Adopted on the NE40E&NE80E

to Arrange Different Users of the RADIUS Authentication to Be
Authenticated by Different LNSs?
The configurations are the same as those for common L2TP services except that an IP address
is specified by the start l2tp command in the L2TP group view.
The RADIUS server needs to be set with the attribute Tunnel_Server_Endpoint (67) to
determine the address of the LNS that is used to authenticate users. The attribute

Tunnel_Server_Endpoint (67) specifies the IP addresses of tunnel servers. A maximum of

eight such IP addresses can be specified, which are separated by blank spaces.
If the l2tp-user radius-force command is configured in the domain view, the RADIUS server
can specify PPP authentication or LNS authentication for users.
7.13.14 When the NE40E&NE80E Functions as an LAC, How Does

the NE40E&NE80E Match Primary and Backup LNSs in the L2TP
Group?
The NE40E&NE80E functions as an LAC, and multiple LNSs are configured in the L2TP
group view. In such a situation, if the tunnel load-sharing command is not configured in the
L2TP group view, one of the LNSs is configured as the primary LNS and the other ones as
backup LNSs. You can run the display l2tp-group command to view the primary/backup
statuses of these LNSs, and find that the first-listed LNS is the primary LNS, and the other
LNSs are backup LNSs.
If the NE40E&NE80E cannot detect the primary LNS, the NE40E&NE80E sends connection
requests to back up LNSs sequentially until a connection is set up successfully. The
NE40E&NE80E is configured with a timer. Before the timer expires, the NE40E&NE80E
keeps the connection with the backup LNS, regardless of whether the primary LNS goes Up
or not; after the timer expires, the NE40E&NE80E establishes the connection with the
primary LNS if the primary LNS is Up at the moment.
7.13.15 Can the NE40E&NE80E Not Authenticate the Tunnel

Name of the LAC When Performing Tunnel Authentication?
The NE40E&NE80E has a default L2TP group named default-lns. If the name of the remote
LAC is not found in the self-defined L2TP group, the default L2TP group default-lns is used.
In this group, the name of the remote LAC does not need to be specified, and any LAC can
access the L2TP group. To use a self-defined L2TP group, you need to specify the name of
the remote LAC in the allow l2tp virtual-template virtual-template-number remote lac-name
command in the group view.
7.13.16 If the PPP Authentication Is configured Differently on the

LNS and the LAC, Can a User Pass the Authentication and Join in
the VPN?
A: If the PPP authentication is configured differently on the LNS and the LAC, the user (a
PPP dial-up terminal) is required to be compatible with both the PAP authentication and the
CHAP authentication; otherwise, the user cannot pass the authentication.
When the PPP authentication mode configured on the LAC is PAP, and the PPP authentication
mode configured on the LNS is CHAP, the user is firstly authenticated by the LAC in plain
text mode. After passing the authentication, the user is authenticated by the LNS. That is, the
user sends the LCP parameters ever negotiated with the LAC to the LNS, and the LNS rejects
some unacceptable parameters, including the authentication mode. In such a case, the user
initiates the secondary negotiation. During the secondary negotiation, the user specifies the
authentication mode as CHAP, and the LNS sends the challenge word to the user. In this
manner, the secondary authentication is complete.

7.13.17 Which Interface Does the Device Select to Send RADIUS

and L2TP Packets?
A: For RADIUS packets:
l The system preferentially selects the IP address of the interface bound to the RADIUS
server group as the source address to send RADIUS packets, that is, the interface
configured by running the radius-server source interface interface-type interface-
number command in the RADIUS server group view.
l If the source interface of the RADIUS server is not bound to the RADIUS server group,
the system selects the source interface of the RADIUS server bound in global mode, that
is, the interface configured by running the radius-server source interface interface-type
interface-number command in the system view.
l If the source interface is not configured in the RADIUS server group view or the system
view, the system selects the IP address of the interface in the local routing table that can
reach the RADIUS server as the source address to send packets, generally the IP address
of an upstream interface on the router.
For L2TP packets:
l If the RADIUS server delivers the local address through the attribute
tunnel_client_endpoint (66), the router preferentially selects this address as the source
address to send L2TP packets to the LNS.
l If the RADIUS server does not deliver the attribute tunnel_client_endpoint (66), the
router selects the IP address of the interface bound by using the tunnel source interface-
type interface-number command in the group view as the source address to send L2TP
packets to the LNS.
l If no IP address is bound to the L2TP group, the system uses the IP address of the
interface in the routing table that can reach the RADIUS server as the source address to
send L2TP packets, generally the IP address of an upstream interface on the router.
7.13.18 Why Do L2TP Users Fail to Pass the Authentication

Through Dialup?
This section lists the frequently asked questions and the answers.
The authentication of L2TP users on the LAC and the LNS may fail. The possible causes are
as follows:
l The password delivered by the RADIUS server of the LAC is incorrect.
l The start l2tp command is not configured for the L2TP group, or the attributes delivered
by the RADIUS server are incorrect.
l L2TP is disabled on the LNS.
l The incorrect tunnel board or source interface of the tunnel is bound to the INS group.
l The route between the LAC and the LNS is unreachable.
l The incorrect default domain, mandatory authentication domain, or mandatory
replacement authentication domain is configured for the L2TP group on the LNS.
l The tunnel radius-force command is configured, but relevant L2TP attributes fail to be
acquired from the RADIUS server.

7.13.19 Why Cannot 802.1X Authentication Work Together with

Web Authentication in Wired Access Whereas This Can Be
Achieved in Wireless Access?
In wired access, users must pass the 802.1X authentication before obtaining IP addresses. If
both 802.1X authentication and Web authentication are configured on the BAS interface, the
network interface card on an 802.1X user's PC automatically sends DHCP request packets to
apply for an IP address after the PC is powered on. The BRAS, however, considers the user as
a Web user and assigns an IP address to the user.
In WLAN access, the WLAN-supporting AP provided by Huawei is deployed to provide

controlled ports based on users. In this case, if a user fails 802.1X authentication, the AP
discards all non-EAP packets of the user. This ensures that EAP packets are preferentially
transmitted to the BRAS.
7.13.20 Why Cannot the NE40E&NE80E Assign IP Address to

PPPoX User Through RADIUS?
The IP address should be assigned by the RADIUS server, but the PPPoX user obtains an IP
address from the local address pool.
l The Framed-IP-Address attribute is not carried in the authentication success message

sent by the RADIUS server.
l The IP address contained in the RADIUS authentication message is 255.255.255.255
(FFFFFFFF) or 255.255.255.254 (FFFFFFFE).
7.13.21 Which Attributes of the RADIUS Packets Will Change

After PPPoE+ Is Deployed?
To enable PPPoE+ on the NE40E&NE80E, run the client-option82 command in the BAS
interface view. The NAS-PORT-ID attribute does not carry the information of the
NE40E&NE80E port. This attribute reports the location of the DSLAM.
l Ethernet (in case of QinQ disabled)

l DslamHostName eth frame/slot/subslot/port:vlanid
l Ethernet (in case of QinQ enabled)
l DslamHostName eth frame/slot/subslot/port:qinqvlan.vlanid
7.13.22 Why Cannot the PPPoE User Go Online by Dialing Up?
The PPPoE user cannot be authenticated successfully. The PC displays a message showing
that the user name and the password are incorrect.
In some cases, the RADIUS server does not support the CHAP authentication because of the
configurations on the server. Therefore, when the client is authenticated through CHAP, the
RADIUS server returns the authentication failure packet.

7.13.23 What Do the Full Match and Fuzzy Match Mean for the
service-name Parameter in PPPoE?
The meanings are as follows:
l Full match
Full match is successful in the following case: No service-name is specified in the user
authentication, and the number of the service-name values on the NE40E&NE80E does
not exceed 8.
If service-name is specified in the user authentication, the NE40E&NE80E searches all
the service-name values. In this case, the full match indicates the NE40E&NE80E has
the same service-name.
l Fuzzy match
If no service-name is specified in the user authentication, the fuzzy match is successful.
If service-name is specified in the user authentication, the NE40E&NE80E searches all
the service-name PPPoE values.
The fuzzy match is successful if:
−The NE40E&NE80E finds the same service-name.
−Or the number of the service-name values does not exceed 8.
7.13.24 Why Cannot the PPPoX User Obtain an IP Address

Through DHCP Server?
When the NE40E&NE80E serves as the proxy, the user accessing the NE40E&NE80E cannot
get an IP address from the DHCP server.
The reason is that the mask of the IP address assigned by DHCP server is not the same as that
of the address pool, so the user cannot obtain the IP address and fails to go online.
7.13.25 Why Cannot the VPN User Pass the Authentication After
Dialing In?
After checking the configuration, you can find that the VPN instance corresponding to the
VPN user is not configured in the address pool or the authentication domain. This leads to the
failure.
7.13.26 For the L2TP Access, What Aspects Need We Pay

Attention to During the Configuration of the LAC and LNS?
For the L2TP access, pay attention to the following aspects when configuring the LAC and
LNS:
l The L2TP function must be enabled on the LAC and the LNS.
l IPv6 forwarding must be enabled on the LAC and the LNS.
l The same L2TP group must be configured on the LAC and the LNS.
l The IP address of the LNS must be bound to the L2TP group on the LAC.

l A tunnel must be configured in the L2TP group on the LAC.

l The tunnel configured in the L2TP group on the LAC must be bound to the L2TP group
on the LNS.
l Tunnel authentication modes and passwords configured on the LAC and the LNS must
be consistent.
7.13.27 On a DHCPv6 Layer 3 Network, a Client Accesses the

DHCPv6 Server Through a DHCPv6 Relay Agent. Why Cannot
the Client Get Online Though Configurations of the Relay Agent
and DHCPv6 Server Are Correct?
l The IPv6 address of the inbound interface of the first relay agent is on a different
network segment from the addresses in the address pool configured on the DHCPv6
server.
l The address pool configured on the DHCPv6 server is not of the relay type.
7.13.28 What Is the Relationship Between Ordinary L3 Users and

Ordinary L2 Users?
Ordinary L2 users access the router through L2 devices, for example, switches. Ordinary L3
users access the router through the L3 devices.
Each ordinary L3 user has an IP address. Their online process is triggered by IP packets or
DHCP. After an ordinary L3 user is authenticated, a user entry is generated on the router.
Therefore the router manages the users conveniently.
7.13.29 Why Cannot Mandatory Web Authentication Be

Performed for NE40E&NE80E Users?
The user's PC is configured with a proxy, which leads to the failure of the mandatory Web
authentication.
7.13.30 How Can the Static Users and PPP Users, Belonging to the
Same VLAN, Access the NE40E&NE80E Through the Same Port?
On the NE40E&NE80E, the binding authentication and PPP authentication cannot be

configured on a BAS interface at the same time. Therefore, belonging to the same VLAN, the
static users and PPP users cannot access the NE40E&NE80E through the same BAS interface.
To solve this problem, you should do as follows:
l Configure authentication-method to ppp+web in the BAS interface view.

l In the BAS interface view, configure the default domain to the authentication domain of
PPP users, and configure the default pre-authentication domain to the authentication
domain of static users.

l Configure other parameters as usual for static users and PPPoE users.
7.13.31 Why Cannot the Static User Go Online Immediately After

Being Disconnected Manually?
l The detect parameter is not configured. The NE40E&NE80E detects if the user gets
online only when the detect parameter is configured for the static user.
l The ip trigger command is not configured on the BAS interface. Therefore, the IP
packet from the user cannot trigger the access flow.
IP trigger may lead to a high CPU usage because each IP packet triggers the access flow once
and there are too many IP packets.
7.13.32 Why Cannot I Open the Web Authentication Page When

Entering the URL of Other Websites Except for the Web
Authentication Server URL?
l The configuration of the NE40E&NE80E is improper.

l The DNS server is faulty.
l The web server is faulty.
7.13.33 Why It Prompts That the IP Addresses Conflict?
In the scenario where the NE40E&NE80E servers as the DHCP server, when detecting that an
address in the address pool is being used but not assigned by itself, the NE40E&NE80E sets
the address to the conflict state so that the address is not to be assigned later. This prevents IP
address conflict. The NE40E&NE80E sets some addresses to the conflict state and does not
automatically delete them. In this manner, several IP addresses may be in the conflict state
after a period of time. This decreases available IP addresses. Therefore, users cannot obtain IP
addresses to get online. To solve this problem, you can use the reset conflict-ip-address
command to delete those IP addresses in the conflict state.
7.13.34 Why Cannot Super Long Ping Packets Reach the Network
Side Through the CAPWAP Channel After a Wireless User
Accesses the Internet?
l The AP-accessed subcard on the AC does not support packet fragmentation.

l The AC does not have boards capable of packet reassembly.
l The AP-accessed interface on the AC is not configured with a Maximum Transmission
Unit (MTU).
l The packet reassembly function is not enabled in the WLAN AC view.

7.13.35 Why Cannot Super Long Ping Packets Reach the Network
Side Through the CAPWAP Channel After a Wireless User
Accesses the Internet?
l The AP-accessed subcard on the AC does not support packet fragmentation.
l The AC does not have boards capable of packet reassembly.
l The AP-accessed interface on the AC is not configured with a Maximum Transmission
Unit (MTU).
l The packet reassembly function is not enabled in the WLAN AC view.
7.13.36 Why Do Lots of Users Fail to Pass RADIUS Authentication

During Login After Device Upgrade?
There is a possibility that services of some users are suspended on the RADIUS server during
the restart of the device. If this problem occurs, close the problematic user connections to the
RADIUS server.
To prevent this problem, do as follows before performing device restart for upgrade: use the
block command in the domain view to set the domain status to Block and run the cut access-
user command to break down user connections. After restarting the device, run the undo
block command to restore the default configurations of the domain.
7.13.37 What May Cause Slow Network Access After Lots of Users
Get Online?
First, run the display access-user user-iduser-id command to check detailed user
information, especially the record of the user's upstream and downstream traffic. If user traffic
exists, the user can access the network although the access speed is slow. If user traffic does
not exist, the user cannot access the network.
If the user cannot access the network, ping the user address from the router to check if the link
between the user and router is faulty, and ping the interface connecting the router to the
upstream device from the user device to check if the link from the user to the network is
faulty. The faulty link can be located based on the ping result.
If the user can access the network but the access speed is slow, do as follows to isolate the
fault:
1. First check the bandwidth allocated to the user to see if the bandwidth is too small.
2. Check whether the queue resources allocated to the user have already been used up. If
the resources have been used up, the traffic of the user enters the default queue where the
available bandwidth is too small.
3. Check routing information on the device to see if route flapping has occurred or a link
participating in load balancing is faulty. Both of these situations will cause packet loss
and lead to slow network access.

7.13.38 Q: Why Cannot Static Users Attached to the

NE40E&NE80E Go Online?
A: The MAC addresses of static users may be conflict with those of the users that are already
online. In this case, you can change the MAC addresses of static users so that they can go
online successfully.
7.13.39 Why Does a DHCP Client Fail to Access the router and
Why Is No Failure Cause Available?
Run the display dhcp-access statistics packet command to check the DHCP packet statistics.
If the router does not receive a DHCP Discover packet from a DHCP client, the VLAN
configuration on the device between the router and DHCP client may be incorrect. As a result,
the link becomes faulty.
7.13.40 Why Does a Static User Without Being Assigned an IP

Address Automatically Obtain an IP Address from the Address
Pool After Connecting to the Network?
An Address Pool Is Configured for PPPoE Users and the excluded-ip-address Command Is
Used to Disallow the Assignment of Certain Addresses That Are Available to Static Users. An
address pool is configured for PPPoE users, and the excluded-ip-address command is used to
disallow the assignment of certain addresses in the pool that are available only to static users.
A static user with an assigned IP address can successfully log in. If a static user without an IP
address attempts to log in, DHCP allocates to the static user an IP address that is available to
PPPoE users. This wastes IP addresses in the IP address pool and makes the management of
static users inconvenient.
There are two solutions to the problem. Choose one of them to address the problem.
l Different IP address pools are configured for static users and PPPoE users respectively.
All IP addresses in the IP address pool configured for static users are prevented from
being used in the IP address pool configured for PPPoE users.
l No default domain is configured on the BAS interface to which static users are attached.
If a static user without an IP address attempts to log in, DHCP is not used for address
allocation.
7.13.41 How to Configure an ACL on the NE40E&NE80E to Make

a Group of DHCP Users Communicate with a Certain Destination
Address?
You can configure a user control list (UCL) with the source being a user group and the
destination address being a specific IP address.
7.13.42 Can Users Accessing the NE40E&NE80E Through

Different Interfaces Obtain Addresses from the Global Address
Pool?
Yes. You can enable users that access the NE40E&NE80E through different interfaces to
obtain addresses from the global address pool by configuring domains on the interfaces

separately and then binding the global address pool to the domains. In this manner, multiple
interfaces can use the same address pool and gateway.
7.14 Video Service
7.14.1 Why Are the Packet Loss Statistics Collected by the MDI
and No-Reference QoE Algorithms Different?
The MDI algorithm collects statistics about the Transport Stream (TS) packet loss, whereas
the no-reference QoE algorithm collects statistics about the RTP packet loss.
7.14.2 Why Cannot Channels Be Configured on the router?

When the router works in auto mode, channels are delivered by the Content Manage System
(CMS) and cannot be configured on the router.
7.14.3 Why Cannot MDI or VMOS Be Enabled for a VAS Group?

Check whether the involved MDI or VMOS channel has been configured for another VAS
group. An MDI or a VMOS channel can be configured for only one VAS group.


NE Series Router Maintenance Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NE Series Router Maintenance Guide PDF

Uploaded by

Copyright:

Available Formats

NE Series Router Maintenance

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2016-06-30) Huawei Proprietary and Confidential i

3 Emergency Maintenance Guidelines.......................................................................................12

Issue 01 (2016-06-30) Huawei Proprietary and Confidential ii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential iii

5 Special Topic.............................................................................................................................. 111

Issue 01 (2016-06-30) Huawei Proprietary and Confidential iv

5.6.6.5 Maintenance for L2TP LAC Service Hot Backup................................................................................................148

Issue 01 (2016-06-30) Huawei Proprietary and Confidential v

5.9.2.4 Flexible Card Value-Added Service Processing Unit (VSUF-160)......................................................................234

Issue 01 (2016-06-30) Huawei Proprietary and Confidential vi

5. User Quantity Evaluation............................................................................................................................................. 293

Issue 01 (2016-06-30) Huawei Proprietary and Confidential vii

5.9.5.2.5 Live Network Deployment Examples............................................................................................................... 357

Issue 01 (2016-06-30) Huawei Proprietary and Confidential viii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential ix

Issue 01 (2016-06-30) Huawei Proprietary and Confidential x

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xi

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xiii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xiv

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xv

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xvi

7.3.2.2 What Is the MAC Address of a VLANIF Interface?............................................................................................694

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xvii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xviii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xix

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xx

7.6.2.66 Why Does the ASBR Generate No Equal-Cost Route?..................................................................................... 741

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxi

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxii

7.6.4.32 How to Change the Next Hop of a Route?......................................................................................................... 773

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxiii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxiv

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxv

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxvi

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxvii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxviii

7.9.2.11 Why Does RSVP Authentication Fail?...............................................................................................................840

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxix

7.10.1.11 Can Only One VSI on One End of a PW Be Up?.............................................................................................864

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxx

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxi

7.12.1.7 Why the commit Command Needs to Be Used?................................................................................................ 881

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxiii

Issue 01 (2016-06-30) Huawei Proprietary and Confidential xxxiv

Date Change Remark

2016–06–30 This is the first official released.

Issue 01 (2016-06-30) Huawei Proprietary and Confidential 1

2 Routine Maintenance Items

About This Chapter

Issue 01 (2016-06-30) Huawei Proprietary and Confidential 2

2.1 Backing Up the Configuration File

l Backing Up the File Through TFTP

l Backing Up the File Through FTP

Issue 01 (2016-06-30) Huawei Proprietary and Confidential 3

c. On the maintenance terminal, initiate an FTP connection to the router.

d. Configure transfer parameters.

e. Transfer the configuration file.