MSR 3016

H3C MSR 20/30/50 Series Routers
Configuration Manual (v1.00)
MSR 20 Series Routers

www.3Com.com
Part Number: 10016324 Rev. AA
August 2007
Downloaded from www.Manualslib.com manuals search engine

3Com Corporation Copyright © 2007, 3Com Corporation. All rights reserved. No part of this documentation may be reproduced in any form or
350 Campus Drive by any means or used to make any derivative work (such as translation, transformation, or adaptation) without written
permission from 3Com Corporation.
Marlborough, MA
USA 01752-3064 3Com Corporation reserves the right to revise this documentation and to make changes in content from time to time
without obligation on the part of 3Com Corporation to provide notification of such revision or change.
3Com Corporation provides this documentation without warranty, term, or condition of any kind, either implied or
expressed, including, but not limited to, the implied warranties, terms or conditions of merchantability, satisfactory quality,
and fitness for a particular purpose. 3Com may make improvements or changes in the product(s) and/or the program(s)
described in this documentation at any time.
If there is any software on removable media described in this documentation, it is furnished under a license agreement
included with the product as a separate document, in the hard copy documentation, or on the removable media in a
directory file named LICENSE.TXT or !LICENSE.TXT. If you are unable to locate a copy, please contact 3Com and a copy will
be provided to you.
UNITED STATES GOVERNMENT LEGEND
If you are a United States government agency, then this documentation and the software described herein are provided to
you subject to the following:
All technical data and computer software are commercial in nature and developed solely at private expense. Software is
delivered as “Commercial Computer Software” as defined in DFARS 252.227-7014 (June 1995) or as a “commercial item”
as defined in FAR 2.101(a) and as such is provided with only such rights as are provided in 3Com’s standard commercial
license for the Software. Technical data is provided with limited rights only as provided in DFAR 252.227-7015 (Nov 1995) or
FAR 52.227-14 (June 1987), whichever is applicable. You agree not to remove or deface any portion of any legend provided
on any licensed program or documentation contained in, or delivered to you in conjunction with, this User Guide.
Unless otherwise indicated, 3Com registered trademarks are registered in the United States and may or may not be
registered in other countries.
3Com and the 3Com logo are registered trademarks of 3Com Corporation.
H3C, , Aolynk, , H3Care, , TOP G, , IRF, NetPilot, Neocean, NeoVTL, SecPro,

SecPoint, SecEngine, SecPath, Comware, Secware, Storware, NQA, VVG, V2G, VnG, PSPT, XGbus, N-Bus, TiGem, InnoVision
and HUASAN are trademarks of Hangzhou H3C Technologies Co., Ltd., a 3Com company.
All other trademarks that may be mentioned in this manual are the property of their respective owners.
ENVIRONMENTAL STATEMENT
It is the policy of 3Com Corporation to be environmentally-friendly in all operations. To uphold our policy, we are committed
to:
Establishing environmental performance standards that comply with national legislation and regulations.
Conserving energy, materials and natural resources in all operations.
Reducing the waste generated by all operations. Ensuring that all waste conforms to recognized environmental standards.
Maximizing the recyclable and reusable content of all products.
Ensuring that all products can be recycled, reused and disposed of safely.
Ensuring that all products are labelled according to recognized environmental standards.
Improving our environmental record on a continual basis.
End of Life Statement
3Com processes allow for the recovery, reclamation and safe disposal of all end-of-life electronic components.
Regulated Materials Statement
3Com products do not contain any hazardous or ozone-depleting material.
Environmental Statement about the Documentation
The documentation for this product is printed on paper that comes from sustainable, managed forests; it is fully
biodegradable and recyclable, and is completely chlorine-free. The varnish is environmentally-friendly, and the inks are
vegetable-based with a low heavy-metal content.

CONTENTS
ABOUT THIS GUIDE

Conventions 69
Related Documentation 70
1 ATM AND DSL INTERFACE CONFIGURATION

ATM and DSL Interface 71
IMA-E1/T1 Interface Configuration 72
Overview 72
Configuring an ATM E1/T1 Interface 73
Configuring an IMA Group 73
ATM IMA-E1/T1 Interface Configuration Example 74
Troubleshooting ATM IMA-E1/T1 Interfaces 75
ATM E3/T3 Interface Configuration 76
Overview 76
Configuring an ATM E3/T3 Interface 76
ATM OC-3c/STM-1 Interface Configuration 76
Overview 77
Configuring an ATM OC-3c/STM-1 Interface 77
ADSL Interface Configuration 77
Overview 77
Configuring an ADSL Interface 79
Upgrading ADSL2+ Card Software 79
G.SHDSL Interface Configuration 80
Overview 80
Configuring a G.SHDSL Interface 80
Displaying and Maintaining ATM and DSL Interfaces 81
Troubleshooting 81
Troubleshooting ATM Interfaces 81
Troubleshooting DSL Interfaces 82
2 POS INTERFACE CONFIGURATION

Overview 83
SONET/SDH 83
POS 83
Configuring a POS Interface 83
Displaying and Maintaining POS Interfaces 84
POS Interface Configuration Example 85
Directly Connecting Routers Through POS Interfaces 85
Connecting Routers Through POS Interfaces Across Frame Relay 86
Troubleshooting POS Interfaces 87

3 ETHERNET INTERFACE CONFIGURATION
General Ethernet Interface Configuration 89
Combo Port Configuration 89
Basic Ethernet Interface Configuration 89
Configuring Flow Control on an Ethernet Interface 90
Configuring Loopback Test on a Layer 2 Ethernet Interface 91
Configuring Loopback on a Layer 3 Ethernet Interface 91
Configuring the Working Mode of an Ethernet Interface 92
Configuring Layer 2 Ethernet Interfaces 92
Configuration Task List 92
Configuring a Port Group 92
Configuring the Storm Suppression Ratio for an Ethernet Interface 93
Configuring the Interval for Collecting Ethernet Interface Statistics 94
Enabling Loopback Detection on an Ethernet Interface 94
Configuring the Cable Type for an Ethernet Interface 95
Testing the Cable on an Ethernet Interface 96
Setting the MTU for an Ethernet Interface 96
Configuring the Suppression Time of Link-Layer-State Changes on an Ethernet
Interface 97
Maintaining and Displaying an Ethernet Interface 97
4 WAN INTERFACE CONFIGURATION

Asynchronous Serial Interface 99
Overview 99
Configuring an Asynchronous Serial Interface 100
AUX Interface 101
Overview 101
Configuring an AUX Interface 101
USB Interface 101
Overview 101
Configuring a USB Interface 101
Synchronous Serial Interface 102
Overview 102
Configuring a Synchronous Serial Interface 102
AM Interface 103
Overview 103
Configuring an AM Interface 104
ISDN BRI Interface 104
Overview 104
Configuring ISDN BRI Interface 106
CE1/PRI Interface 106
Overview 106
Configuring CE1/PRI Interface (in E1 Mode) 107
Configuring CE1/PRI Interface (in CE1 Mode) 107
Configuring CE1/PRI Interface (in PRI Mode) 108
Configuring Other CE1/PRI Interface Parameters 109
Configuring Error Packets Diffusion Restraint 110

Displaying and Maintaining CE1/PRI Interfaces 110
CT1/PRI Interface 110
Overview 110
Configuring CT1/PRI Interface in CT1 Mode 111
Configuring an CT1/PRI Interface operating as a PRI interface 111
Configuring Other CT1/PRI Interface Parameters 112
Starting/Stopping a BERT Test on CT1/PRI Interface 113
Configuring Error Packets Diffusion Restraint 114
Displaying and Maintaining CT1/PRI Interfaces 114
E1-F Interface 115
Overview 115
Configuring an E1-F Interface (in Framed Mode) 115
Configuring an E1-F Interface (in Unframed Mode) 115
Configuring Other E1-F Interface Parameters 116
Displaying and Maintaining E1-F Interfaces 116
T1-F Interface 117
Overview 117
Configuring a T1-F Interface 117
Starting/Stopping a BERT Test on T1-F Interface 118
Displaying and Maintaining T1-F Interfaces 119
CE3 Interface 119
Overview 119
Configuring a CE3 Interface (in E3 Mode) 119
Configuring a CE3 Interface operating in CE3 Mode 120
Configuring Other CE3 Interface Parameters 120
Displaying and Maintaining CE3 Interfaces 121
CT3 Interface 122
Overview 122
Configuring a CT3 Interface (in T3 Mode) 123
Configuring CT3 Interface in CT3 Mode 123
Configuring Other CT3 Interface Parameters 124
Displaying and Maintaining CT3 Interfaces 125
5 ATM CONFIGURATION
Introduction to ATM Technology 127
ATM Overview 127
Hierarchical Structure of ATM 127
Overview of IPoA, IPoEoA, PPPoA and PPPoEoA Applications 128
IPoA 129
IPoEoA 129
PPPoA 129
PPPoEoA 129
Configuring ATM 130
Configuring ATM Interface 130
Configuring an ATM Sub-Interface 130
Configuring an ATM Sub-Interface 130
Checking Existence of PVCs When Determining the Protocol State of an ATM P2P
Sub-interface 131
Configuring PVC 131
Configuring PVC parameters 131

Assigning a Transmission Priority to an ATM PVC 132
Configuring PVC Service Map 133
Configuring an ATM Class 133
Configuring VP Policing 136
Configuring Applications over ATM 136
Configuring IPoA 136
Configuring IPoEoA 137
Configuring PPPoA 137
Configuring PPPoEoA 138
Displaying and Maintaining ATM 139
ATM Configuration Examples 140
IPoA Configuration Example 140
IPoEoA Configuration Example 142
PPPoA Configuration Example 143
PPPoEoA Server Configuration Example 144
PPPoEoA Client Configuration Example 146
ATM PVC Transmit Priority Configuration Example 148
Troubleshooting ATM 149
Link State Error in IPoA Application 149
Link Report Error in PPPoA Application 149
Ping Failure 149
ATM Interface State Error 150
PVC State is Down while ATM Interface State is Up 150
Ping Failure after PPPoA Configuration 150
Packet Loss and CRC Errors and Changes of Interface State 151
6 DCC CONFIGURATION
Introduction to DCC 153
Overview 153
Approaches to DCC 153
DCC Features 156
Preparing for DCC Configuration 156
DCC Configuration 157
DCC Configuration Task List 157
Configuring Basic Parameters for DCC 157
Configuring C-DCC 159
Configuring RS-DCC 166
Configuring MP for DCC 168
Configuring PPP Callback 170
Configuring ISDN Caller Identification Callback 174
Configuring Advanced DCC Functions 176
Configuring DCC Timers and Buffer Queue Length 178
Configuring Traffic Statistics Interval 179
Displaying and Maintaining DCC 179
DCC Configuration Example 179
C-DCC Application 180
RS-DCC Application 182
DCC Application on ISDN 186
RS-DCC Application with MP 190

DCC for Dialup ISDN BRI Line and Leased Line Connection 192
Router-to-Router Callback with DCC (PPP Approach) 194
Router-to-Router Callback with DCC (ISDN Approach) 197
Router-to-PC Callback with DCC 198
NT Server-to-Router Callback with DCC 200
Circular Dial String Backup and Internet Access with DCC 202
Troubleshooting 208
Troubleshooting Cases 208
7 DLSW CONFIGURATION
DLSw Overview 211
Introduction 211
Differences between DLSw v1.0 and DLSw v2.0 212
Related Specifications 213
Configuring DLSw in an Ethernet Environment 213
Creating DLSw Peers 214
Mapping a Bridge Set to DLSw 215
Adding an Ethernet Interface to a Bridge Set 215
Setting DLSw Timers 215
Configuring LLC2 Parameters 216
Enabling the Multicast Function of DLSw v2.0 217
Configuring the Maximum Number of DLSw v2.0 Explorer Retries 217
Applying an ACL in DLSw 217
Configuring DLSw in an SDLC Environment 218
Configuring DLSw 218
Configuring an SDLC Interface 219
Enabling DLSw Forwarding on an SDLC Interface 219
Configuring SDLC Roles 219
Configuring an SDLC Address for a Secondary Station 220
Configuring an SDLC Peer 221
Configuring an SDLC XID 221
Configuring an SDLC Virtual MAC Address 222
Configuring the Properties of an Synchronous Serial Interface 222
Configuring Optional SDLC Parameters 223
Configuring Local Reachable MAC or SAP Addresses 224
Configuring Remote Reachability Information 224
Displaying and Debugging DLSw 225
DLSw Configuration Examples 225
Configuring LAN-to-LAN DLSw 225
Configuring SDLC-to-SDLC DLSw 226
Configuring DLSw for SDLC-LAN Remote Media Translation 228
Configuring DLSw with VLAN Support 229
DLSw v2.0 Configuration Example 231
Troubleshooting DLSw 232
Unable to Establish a TCP Connection 232
Unable to Establish a DLSw Circuit 233
8 FRAME RELAY CONFIGURATION

Frame Relay Terminologies 235

Overview 235
DTE, DCE, UNI, and NNI 235
Virtual Circuit 235
Frame Relay Protocol Parameters 236
Frame Relay Address Mapping 237
Frame Relay Configuration Task List 238
Configuring DTE Side Frame Relay 238
Configuring Basic DTE Side Frame Relay 238
Configuring Frame Relay Address Mapping 239
Configuring Frame Relay Local Virtual Circuit 239
Configuring Frame Relay Switching 240
Configuring Frame Relay Subinterface 241
Configuring Frame Relay over IP Network 242
Configuring Annex G 244
Configuring DCE Side Frame Relay 245
Configuring Basic DCE Side Frame Relay 245
Configuring Frame Relay Address Mapping 246
Configuring Frame Relay Local Virtual Circuit 246
Configuring Frame Relay Switching 246
Configuring Frame Relay Subinterface 246
Configuring Frame Relay over IP Network 246
Configuring Annex G 246
Displaying and Maintaining Frame Relay 246
Frame Relay Configuration Example 247
Interconnecting LANs through Frame Relay Network 247
Interconnecting LANs through Dedicated Line 249
Interconnecting LANs through an Annex G DLCI 250
Troubleshooting Frame Relay 252
Frame Relay Compression 253
Overview 253
Configuring FRF.9 Compression 254
Configuring FRF.20 IP Header Compression 254
Displaying and Maintaining Frame Relay Compression 255
Frame Relay Compression Configuration Example 255
9 MULTILINK FRAME RELAY

Overview 257
Configuring Multilink Frame Relay 258
Displaying and Maintaining Multilink Frame Relay 259
Multilink Frame Relay Configuration Examples 259
MFR Direct Connection Configuration Example 259
MFR Switched Connection Configuration Example 260
10 PPPOFR
Overview 263
Configuring PPPoFR 263
Displaying and Maintaining PPPoFR 263
PPPoFR Configuration Example 264

11 MPOFR
Overview 265
Configuring MPoFR 265
MPoFR Configuration Example 266
12 GVRP CONFIGURATION
Introduction to GVRP 271
GARP 271
GVRP 274
Protocols and Standards 274
Configuring GVRP 275
Configuring GVRP Functions 275
Configuring GARP Timers 275
Displaying and Maintaining GVRP 276
GVRP Configuration Example 276
GVRP Configuration Example I 276
GVRP Configuration Example II 277
GVRP Configuration Example III 279
13 HDLC CONFIGURATION
Introduction to HDLC 281
HDLC Overview 281
HDLC Frame Format and Frame Type 281
Configuring HDLC 282
14 X.25 AND LAPB CONFIGURATION

Introduction to X.25 and LAPB Protocols 283
Configuring LAPB 285
Configuring X.25 286
Configuring X.25 Interface Parameters 286
Configuring X.25 Interface Supplementary Parameters 290
Configuring X.25 Datagram Transmission 292
Configuring Additional Parameters for X.25 Datagram Transmission 294
Configuring X.25 Subinterface 299
Configuring X.25 Switching 299
Configuring X.25 Load Sharing 300
Configuring X.25 Closed User Group 303
X.25 PAD Remote Access Service 305
Introduction to X.25 PAD 305
Configuring X.25 PAD 306
Troubleshooting X.25 PAD 307
Configuring X.25 over TCP (XOT) 307
Introduction to XOT Protocol 307
Configuration Procedure 308
Configuring X.25 over FR 310
Introduction to X.25 over FR 310
Configuring SVC Application of X.25 over FR 311
Configuring PVC Application of X.25 over FR 311
Configuring X2T 312

Introduction 312
Displaying and Maintaining LAPB and X.25 314
LAPB Configuration Example 314
X.25 Configuration Examples 316
Direct Connection of Two Routers via Serial Interfaces (One Mapping) 316
Direct Connection of Two routers through Serial Interfaces (Two Mappings) 317
Connecting the Router to X.25 Public Packet Network 319
Configuring VC Range 320
Transmitting IP Datagrams through X.25 PVCs 320
X.25 Subinterface Configuration Example 323
SVC Application of XOT 324
PVC Application of XOT 326
SVC Application of X.25 over FR 327
PVC Application of X.25 over FR 329
X.25 Load Sharing Application 331
Implementing X.25 Load Sharing Function for IP Datagram Transmission 334
TCP/IP Header Compression Protocol Application 336
X.25 PAD Configuration Example 338
X2T Configuration Example 339
X2T SVC Configuration Example 339
X2T PVC Configuration Example 340
Troubleshooting LAPB Configuration 340
LAPB (or X.25) of Two Sides Always Being Down 340
Failed to Ping the Other Side with X.25 on Both Sides Being Up 341
Troubleshooting X.25 Configuration 341
X.25 of Two Sides Always Being Down with LAPB of two sides Being Up 341
Failed to Ping the Other Side with X.25 on Both Sides Being Up 341
Continuous Resets and Clears of the VC Established 342
PVC Setup Request Rejected 342
Failed to Ping through the XOT SVC Configured 342
Failed to Ping through the XOT PVC Configured 342
15 LINK AGGREGATION OVERVIEW

Link Aggregation 345
LACP 345
Consistency Considerations for Ports in an Aggregation 346
Approaches to Link Aggregation 346
Manual Link Aggregation 347
Static LACP Link aggregation 348
Load Sharing in a Link Aggregation Group 349
Aggregation Port Group 349
16 LINK AGGREGATION CONFIGURATION

Configuring Link Aggregation 351
Configuring a Manual Link Aggregation Group 351
Configuring a Static LACP Link Aggregation Group 352
Assigning a Name for an Aggregation Group 352
Entering Aggregation Port Group View 353

Displaying and Maintaining Link Aggregation 353
Link Aggregation Configuration Example 353
17 MODEM CONFIGURATION
Overview 355
Modem Configuration 355
Configuring the Modem Answer Mode 356
Configuring Modem Using the AT Commands 356
Modem Configuration Example 356
Troubleshooting 357
18 PORT MIRRORING CONFIGURATION

Port Mirroring Overview 359
Introduction to Port Mirroring 359
Implementation of Port Mirroring 359
Configuring Local Port Mirroring 360
Displaying and Maintaining Port Mirroring 361
Examples of Typical Port Mirroring Configuration 361
Local Port Mirroring Configuration Example 361
19 PPP AND MP CONFIGURATION

Introduction to PPP and MP 363
PPP 363
MP 366
Configuring PPP 367
Configuring PPP 367
Configuring the Local Device to Authenticate the Peer Using PAP 368
Configuring the Local Device to Authenticate the Peer Using CHAP 368
Configuring the Local Device to Be Authenticated by the Peer Using PAP 369
Configuring the Local Device to Be Authenticated by the Peer Using CHAP 369
Configuring PPP Negotiation 370
Configuring PPP Link Quality Control 373
Enabling the PPP Accounting Statistics Function 373
Configuring MP 374
Configuring MP Using a VT Interface 374
Configuring an MP-group 376
Configuring PPP Link Efficiency Mechanism 376
Configuring IPHC 378
Displaying and Maintaining PPP/MP/PPP Link Efficiency Mechanism 379
PPP and MP Configuration Example 380
PAP Authentication Example 380
CHAP Authentication Example 380
MP Configuration Example 381
Three Types of MP Binding Mode 384
Troubleshooting PPP Configuration 392
20 PPPOE CONFIGURATION
Introduction to PPPoE 393
Configuring PPPoE Server 394

Configuring PPPoE Client 395
Introduction to PPPoE Client 395
Resetting/Deleting a PPPoE Session 396
Displaying and Maintaining PPPoE 397
PPPoE Configuration Example 397
PPPoE Server Configuration Example 397
PPPoE Client Configuration Example 398
Connecting a LAN to the Internet via ADSL Modem 400
Using ADSL as Backup Line 403
Accessing the Internet through an ADSL Interface 403
21 BRIDGING CONFIGURATION
Bridging Overview 405
Introduction to Bridging 405
Major Functionalities of Bridges 405
Bridging Configuration Task List 409
Configuring Basic Bridging Functionalities 409
Configuring Bridge Table Entries 411
Configuring Bridge Routing 411
Displaying and Maintaining Bridging Configurations 412
Transparent Bridging Configuration Examples 412
Transparent Bridging over ATM 412
Transparent Bridging over PPP 413
Transparent Bridging over MP 414
Transparent Bridging over FR 415
Transparent Bridging X.25 416
Transparent Bridging over HDLC 416
Inter-VLAN Transparent Bridging 417
Bridging with FR Sub-Interface Support 418
Bridge Routing 420
22 ISDN CONFIGURATION
Introduction to ISDN 421
Configuring ISDN 422
Configuring ISDN BRI 422
Configuring ISDN PRI 423
Configuring the Negotiation Parameters of ISDN Layer 3 Protocol 424
Configuring the SPID of the ISDN NI Protocol 428
Setting the Called Number or Sub-Address to Be Checked During a Digital
Incoming Call 429
Configuring to Send Calling Number During an Outgoing Call 429
Setting the Local Management ISDN B Channel 430
Configuring ISDN B Channel Selection Mode 430
Configuring the Sliding Window Size on the PRI Interface 431
Configuring Statistics About ISDN Message Receiving/Sending 431
Configuring to Check the Calling Number When an Incoming Call Comes 431
Configuring TEI Treatment on the BRI Interface 432
Configuring ISDN BRI Leased Line 432

Configuring Permanent Link Function on ISDN BRI Link Layer 432
Specifying an ISDN BRI Interface to be in Permanent Active State on Physical
Layer 433
Enabling Remote Powering on an ISDN BRI Interface 433
Displaying and Maintaining ISDN 434
ISDN Configuration Example 434
Connecting Routers through ISDN PRI Lines 434
Connecting Routers through ISDN BRI Lines Running NI 435
Using ISDN BRI Leased Line to Implement MP Bundling 436
Configuring ISDN 128K Leased Lines 438
Interoperating with DMS100 Switches 440
Troubleshooting 441
23 MSTP CONFIGURATION
MSTP Overview 443
Introduction to STP 443
Introduction to MSTP 452
Configuring the Root Bridge 459
Configuring an MST Region 459
Specifying the Root Bridge or a Secondary Root Bridge 460
Configuring the Work Mode of MSTP Device 462
Configuring the Priority of the Current Device 462
Configuring the Maximum Hops of an MST Region 463
Configuring the Network Diameter of a Switched Network 464
Configuring Timers of MSTP 464
Configuring the Timeout Factor 465
Configuring the Maximum Transmission Rate of Ports 466
Configuring Ports as Edge Ports 467
Configuring Whether Ports Connect to Point-to-Point Links 467
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets 468
Enabling the Output of Port State Transition Information 469
Enabling the MSTP Feature 469
Configuring Leaf Nodes 470
Configuring an MST Region 470
Configuring the Work Mode of MSTP 470
Configuring the Timeout Factor 470
Configuring the Maximum Transmission Rate of Ports 470
Configuring Ports as Edge Ports 470
Configuring Path Costs of Ports 470
Configuring Port Priority 473
Configuring Whether Ports Connect to Point-to-Point Links 473
Configuring the Mode a Port Uses to Recognize/Send MSTP Packets 473
Enabling Output of Port State Transition Information 474
Enabling the MSTP Feature 474
Performing mCheck 474
Configuration Prerequisites 474

Configuration Example 474
Configuring Digest Snooping 475
Configuring No Agreement Check 477
Prerequisites 478
Configuring Protection Functions 479
Configuration prerequisites 479
Enabling BPDU Guard 479
Enabling Root Guard 479
Enabling Loop Guard 480
Enabling TC-BPDU Attack Guard 481
Displaying and Maintaining MSTP 481
MSTP Configuration Example 482
24 VLAN CONFIGURATION
Introduction to VLAN 487
VLAN Overview 487
VLAN Fundamental 488
VLAN Classification 489
Configuring Basic VLAN Attributes 489
Configuring VLAN Interface Basic Attributes 490
Configuring a Port-Based VLAN 491
Introduction to Port-Based VLAN 491
Configuring the Access-Port-Based VLAN 492
Configuring the Trunk-Port-Based VLAN 493
Configuring the Hybrid-Port-Based VLAN 494
Displaying and Maintaining VLAN 494
VLAN Configuration Examples 495
25 VOICE VLAN CONFIGURATION

Introduction to Voice VLAN 497
Working Modes of Voice VLAN 498
Security Mode and Normal Mode of Voice VLAN 499
Configuring the Voice VLAN 500
Configuring Voice VLAN under Automatic Mode 500
Configuring Voice VLAN under Manual Mode 500
Displaying and Maintaining Voice VLAN 501
Voice VLAN Configuration Examples 502
A Configuration Examples of the Voice VLAN under Automatic Mode 502
A Configuration Examples of Voice VLAN under Manual Mode 503
26 PORT ISOLATION CONFIGURATION

Introduction to Port Isolation 507
Configuring Isolation Groups 507

Adding a Port to the Isolation Group 507
Displaying and Maintaining Isolation Groups 508
Port Isolation Configuration Example 508
27 DYNAMIC ROUTE BACKUP CONFIGURATION

Overview 511
Concept 511
Features 511
Implementation 512
Dynamic Route Backup Configuration 512
Creating Dynamic Route Backup Groups 512
Enabling the Dynamic Route Backup Function on a Backup Interface 513
Configuring Backup Link Disconnection Delay 513
Dynamic Route Backup Configuration Example 513
Example I 513
Example II 516
Example III 518
Using One Dynamic Route Group to Monitor Multiple Network Segments 520
28 LOGICAL INTERFACE CONFIGURATION

Logical Interface Overview 525
Dialer Interface 525
Loopback Interface 525
Introduction to Loopback Interface 525
Configuring a Loopback Interface 526
Null Interface 526
Introduction to Null Interface 526
Configuring a Null Interface 526
Sub-interface 527
Introduction to Sub-interface 527
Configuring an Ethernet Sub-interface 527
Configuring a WAN Sub-interfaces 528
Ethernet Sub-interface Configuration Example 530
WAN Sub-interface Configuration Example 532
Configuring MP-group Interfaces 533
Configuring MFR Interface 533
VT and VA Interface 534
Introduction to VT and VA interface 534
Configuring VT 534
Displaying and Maintaining VTs and VA Interfaces 535
Troubleshooting 536
Configuring VE 536
Introduction to VE 536
Configuring VE 536
29 CPOS INTERFACE CONFIGURATION

Overview 539
SONET/SDH 539
CPOS 539

SDH Frame Structure 540
Terms 540
Multiplexing E1/T1 Channels to Form STM-1 541
Calculating E1/T1 Channel Sequence Numbers 541
Overhead Byte 542
CPOS Interface Application Scenario 543
Configuring a CPOS Interface 544
Configuring an E1 Channel 545
Configuring a T1 Channel 545
Displaying and Maintaining CPOS Interfaces 546
Troubleshooting CPOS Interfaces 546
30 ARP CONFIGURATION
ARP Overview 549
ARP Function 549
ARP Message Format 549
ARP Process 550
ARP Mapping Table 551
Configuring ARP 552
Configuring a Static ARP Entry 552
Configuring the Maximum Number of ARP Entries Dynamically Learned on an
Interface 552
Setting Aging Time for Dynamic ARP Entries 552
Enabling the ARP Entry Check 553
Enabling the Support for ARP Requests from a Natural Network 553
ARP Configuration Example 553
Configuring Gratuitous ARP 554
Introduction to Gratuitous ARP 554
Configuring Gratuitous ARP 554
Configuring ARP Source Suppression 555
Introduction to ARP Source Suppression 555
Configuring Authorized ARP 555
Introduction to Authorized ARP 555
Example for Configuring Authorized ARP on a DHCP Server 556
Example for Configuring Authorized ARP on a DHCP Relay Agent 557
Displaying and Maintaining ARP 559
31 PROXY ARP CONFIGURATION

Proxy ARP Overview 561
Enabling Proxy ARP 561
Displaying and Maintaining Proxy ARP 562
Proxy ARP Configuration Examples 562
Proxy ARP Configuration Example 562
Local Proxy ARP Configuration Example in Case of Port Isolation 563
32 DHCP OVERVIEW
Introduction to DHCP 565

DHCP Address Allocation 566
Allocation Mechanisms 566
Dynamic IP Address Allocation Procedure 566
IP Address Lease Extension 567
DHCP Message Format 567
DHCP Options 568
DHCP Options Overview 568
Introduction to DHCP Options 568
Self-Defined Options 569
33 DHCP SERVER CONFIGURATION

Introduction to DHCP Server 573
Application Environment 573
DHCP Address Pool 573
IP Address Allocation Sequence 574
DHCP Server Configuration Task List 575
Enabling DHCP 575
Enabling the DHCP Server on an Interface 575
Configuring an Address Pool for the DHCP Server 576
Creating a DHCP Address Pool 576
Configuring an Address Allocation Mechanism 576
Configuring a Domain Name Suffix for the Client 578
Configuring DNS Servers for the Client 578
Configuring WINS Servers and NetBIOS Node Type for the Client 579
Configuring the BIMS server Information for the Client 579
Configuring Gateways for the Client 580
Configuring Option 184 Parameters for the Client with Voice Service 580
Configuring the TFTP Server and Bootfile Name for the Client 581
Configuring Self-Defined DHCP Options 581
Configuring the DHCP Server Security Functions 582
Enabling Unauthorized DHCP Server Detection 583
Configuring IP Address Conflict Detection 583
Configuring the DHCP Server to Support Authorized ARP 584
Configuring the Handling Mode for Option 82 584
Displaying and Maintaining the DHCP Server 585
DHCP Server Configuration Examples 585
DHCP Server Configuration Example 585
Self-Defined Option Configuration Example 587
Troubleshooting DHCP Server Configuration 588
34 DHCP RELAY AGENT CONFIGURATION

Introduction to DHCP Relay Agent 589
Application Environment 589
Fundamentals 589
DHCP Relay Agent Support for Option 82 590
DHCP Relay Agent Configuration Task List 591

Configuring the DHCP Relay Agent 591
Enabling DHCP 591
Enabling the DHCP Relay Agent on Interfaces 591
Correlating a DHCP Server Group with Relay Agent Interfaces 592
Configuring the DHCP Relay Agent to Send a DHCP-Release Request 593
Configuring the DHCP Relay Agent Security Functions 593
Configuring the DHCP Relay Agent to Support Option 82 595
Displaying and Maintaining the DHCP Relay Agent Configuration 596
DHCP Relay Agent Configuration Example 596
Troubleshooting DHCP Relay Agent Configuration 597
35 DHCP CLIENT CONFIGURATION

Introduction to DHCP Client 599
Enabling the DHCP Client on an Interface 599
Displaying and Maintaining the DHCP Client 600
DHCP Client Configuration Example 600
36 DHCP SNOOPING CONFIGURATION

DHCP Snooping Overview 601
Function of DHCP Snooping 601
Configuring DHCP Snooping Basic Functions 602
Displaying and Maintaining DHCP Snooping 602
DHCP Snooping Configuration Example 602
37 BOOTP CLIENT CONFIGURATION

Introduction to BOOTP Client 605
BOOTP Application 605
Obtaining an IP Address Dynamically 606
Configuring an Interface to Dynamically Obtain an IP Address through BOOTP 606
Displaying and Maintaining BOOTP Client Configuration 606
BOOTP Client Configuration Example 606
38 DNS CONFIGURATION
DNS Overview 609
Static Domain Name Resolution 609
Dynamic Domain Name Resolution 609
DNS Proxy 611
Configuring the DNS Client 611
Configuring Static Domain Name Resolution 611
Configuring Dynamic Domain Name Resolution 612
Configuring the DNS Proxy 612
Displaying and Maintaining DNS 612
DNS Configuration Examples 613
Static Domain Name Resolution Configuration Example 613
Dynamic Domain Name Resolution Configuration Example 613
DNS Proxy Configuration Example 617
Troubleshooting DNS Configuration 618

39 IP ACCOUNTING CONFIGURATION
Introduction to IP Accounting 619
Configuring IP Accounting 619
IP Accounting Configuration Example 620
Network Requirements 620
Network Diagram 621
Displaying and Maintaining IP Accounting Configuration 622
40 IP ADDRESSING CONFIGURATION
IP Addressing Overview 623
IP Address Classes 623
Special Case IP Addresses 624
Subnetting and Masking 624
IP Unnumbered 625
Configuring IP Addresses 625
Assigning an IP Address to an Interface 625
IP Addressing Configuration Example 626
Configuring IP Unnumbered 628
IP Unnumbered Configuration Example 628
Displaying and Maintaining IP Addressing 630
41 IP PERFORMANCE CONFIGURATION
IP Performance Overview 631
Enabling the Device to Forward Directed Broadcasts 631
Enabling the Device to Forward Directed Broadcasts 631
Configuring TCP Attributes 633
Configuring TCP MSS for the Interface 633
Enabling the SYN Cookie Feature 633
Enabling Protection Against Naptha Attack 634
Configuring TCP Optional Parameters 635
Configuring ICMP to Send Error Packets 636
Displaying and Maintaining IP Performance 638
42 IP UNICAST POLICY ROUTING CONFIGURATION

Introduction to IP Unicast Policy Routing 639
Configuring IP Unicast Policy Routing 639
Defining a Policy 639
Enabling System Policy Routing 641
Enabling Interface Policy Routing 642
Displaying and Maintaining IP Unicast Policy Routing Configuration 642
IP Unicast Policy Routing Configuration Examples 643
Configuring Policy Routing Based on Source Address 643
Configuring Policy Routing Based on Packet Size 644

43 UDP HELPER CONFIGURATION
Introduction to UDP Helper 647
Configuring UDP Helper 648
Displaying and Maintaining UDP Helper 648
UDP Helper Configuration Example 649
44 URPF CONFIGURATION
URPF Overview 651
Basic Concepts 651
Processing Flow 651
Configuring URPF 652
45 FAST FORWARDING CONFIGURATION

Introduction to Fast Forwarding 653
Configuring Fast Forwarding 654
Displaying and Maintaining Fast Forwarding 654
46 IPV6 BASICS CONFIGURATION

IPv6 Overview 655
IPv6 Features 655
Introduction to IPv6 Address 657
Introduction to IPv6 Neighbor Discovery Protocol 659
IPv6 PMTU Discovery 663
Introduction to IPv6 DNS 664
IPv6 Basics Configuration Task List 664
Configuring Basic IPv6 Functions 665
Enabling the IPv6 Packet Forwarding Function 665
Configuring an IPv6 Unicast Address 665
Configuring IPv6 NDP 666
Configuring a Static Neighbor Entry 666
Configuring the Maximum Number of Neighbors Dynamically Learned 667
Configuring Parameters Related to an RA Message 667
Configuring the Number of Attempts to Send an NS Message for DAD 669
Configuring PMTU Discovery 670
Configuring the Interface MTU 670
Configuring a Static PMTU for a Specified IPv6 Address 670
Configuring the Aging Time for PMTU 671
Configuring IPv6 TCP Properties 671
Configuring IPv6 FIB-Based Forwarding 671
Configuring ICMPv6 Packet Sending 672
Configuring the Maximum ICMPv6 Error Packets Sent in an Interval 672
Enable Sending of Multicast Echo Replies 673
Configuring IPv6 DNS 673
Configuring Static IPv6 Domain Name Resolution 673
Configuring Dynamic IPv6 Domain Name Resolution 673
Displaying and Maintaining IPv6 Basics Configuration 674
IPv6 Configuration Example 675
Troubleshooting IPv6 Basics Configuration 678

47 NAT-PT CONFIGURATION
NAT-PT Overview 679
NAT-PT Mechanism 680
Implementing NAT-PT 680
NAT-PT Configuration Task List 681
Configuring NAT-PT 681
Enabling NAT-PT 682
Configuring a NAT-PT Prefix 682
Configuring Mappings for IPv4 Hosts Accessing IPv6 Hosts 682
Configuring Mappings for IPv6 Hosts Accessing IPv4 Hosts 683
Configuring the NAT-PT Session Timeout Time for Different Protocol Packets 685
Configuring the Maximum Number of Sessions 686
Configuring the ToS/Traffic Class Field in a Packet After NAT-PT 686
Displaying and Maintaining NAT-PT 686
NAT-PT Configuration Example 687
Configuring Dynamic IPv6-to-IPv4 Mappings 687
Configuring Static IPv4-to-IPv6 and IPv6-to-IPv4 Mappings 688
Troubleshooting NAT-PT 690
48 DUAL STACK CONFIGURATION

Dual Stack Overview 691
Configuring Dual Stack 691
49 TUNNELING CONFIGURATION
Introduction to Tunneling 693
IPv6 over IPv4 Tunnel 694
IPv4 over IPv4 Tunnel 697
IPv4/IPv6 over IPv6 Tunnel 698
6PE Overview 699
Tunneling Configuration Task List 700
Configuring an IPv6 Manually Configured Tunnel 700
Configuring Automatic IPv4-Compatible IPv6 Tunnel 704
Configuring 6to4 Tunnel 708
Configuration Example 1 709
Configuration Example 2 711
Configuring ISATAP Tunnel 714

Configuring IPv4 over IPv4 Tunnel 717
Displaying and Maintaining Tunneling Configuration 730
Troubleshooting Tunneling Configuration 730
50 IPV6 UNICAST POLICY ROUTING CONFIGURATION

Introduction to IPv6 Unicast Policy Routing 731
Configuring IPv6 Unicast Policy Routing 731
Defining an IPv6 Policy 731
Enabling IPv6 System Policy Routing 733
Enabling IPv6 Interface Policy Routing 734
Displaying and Maintaining IPv6 Unicast Policy Routing Configuration 734
IPv6 Unicast Policy Routing Configuration Examples 734
Configuring Policy Routing Based on Source Address 734
Configuring Policy Routing Based on Packet Size 736
51 TERMINAL ACCESS CONFIGURATION

Introduction to Terminal Access 739
Typical Applications of Terminal Access 740
Terminal Access Feature List 741
Terminal Access Features 742
Terminal Access Specifications 748
TTY Terminal Access Configuration 749
Configuration Example for TTY Terminal Access 753
Telnet Terminal Access Configuration 755
Configuration Example for Telnet Terminal Access 758
RTC Terminal Access Configuration 759
Asynchronous RTC Terminal Access Configuration Example 765
Asynchronous RTC Multi-instance Configuration Example 767
Displaying and Maintaining Terminal Access Configuration 769
52 FEP INSTALLATION AND CONFIGURATION

Installing and Configuring SCO OpenServer Server 771
Installing Device Drivers 771
Modifying System Configuration File inittab 775
Editing the ttyd Configuration File 775
Modifying Route Configuration File 778

Running and Terminating ttyd on Unix Server 778
Installing and Using ttyd Administration Program ttyadm 780
Installing and Configuring SCO UnixWare Server 787
Modifying System Configuration File ttydefs 788
Editing ttyd Configuration File 788
Installing and Configuring SUN OS Server 789
Running and Terminating ttyd on the Unix Server 790
Installing and Configuring IBM AIX Server 791
Running and Terminating ttyd on the Unix Server 792
Installing and Configuring HP-UX Server 793
Editing ttyd Configuration File 794
Installing and Configuring Red Hat Linux Server 795
53 TERMINAL ACCESS TROUBLESHOOTING

Prompts on Terminals 799
Terminal Access Troubleshooting 800

54 TERMINAL ACCESS FAQ
55 IP ROUTING OVERVIEW
IP Routing and Routing Table 815
Routing 815
Routing Table 815
Routing Protocol Overview 817
Static Routing and Dynamic Routing 817
Classification of Dynamic Routing Protocols 817
Routing Protocols and Routing Priority 818
Load Balancing and Route Backup 819
Route Recursion 819
Sharing of Routing Information 819
Configuring Load Sharing 820
Configuring Bandwidth-based Non-Balanced Load Sharing 820
Configuring the Load Sharing Bandwidth for an Interface 820
Displaying and Maintaining a Routing Table 821
Bandwidth-based Load Sharing Configuration Example 822
56 BGP CONFIGURATION
BGP Overview 825
Formats of BGP Messages 826
BGP Path Attributes 829
BGP Route Selection 832
IBGP and IGP Information Synchronization 834
Settlements for Problems Caused by Large Scale BGP Networks 835
BGP GR 838
MP-BGP 839
BGP Configuration Task List 840
Configuring BGP Basic Functions 841
Prerequisites 841
Controlling Route Distribution and Reception 843
Prerequisites 843
Configuring BGP Route Redistribution 843
Configuring BGP Route Summarization 843
Advertising a Default Route to a Peer or Peer Group 844
Configuring BGP Route Distribution Policy 844
Configuring BGP Route Reception Policy 845
Enabling BGP and IGP Route Synchronization 846
Configuring BGP Route Dampening 846
Configuring BGP Routing Attributes 846
Prerequisites 846
Tuning and Optimizing BGP Networks 849
Prerequisites 849

Configuring a Large Scale BGP Network 851
Configuring BGP Peer Groups 851
Configuring BGP Community 852
Configuring a BGP Route Reflector 853
Configuring a BGP Confederation 853
Configuring BGP Graceful Restart 853
Displaying and Maintaining BGP Configuration 855
Displaying BGP Configuration 855
Resetting BGP Connections 856
Clearing BGP Information 856
BGP Typical Configuration Examples 856
BGP Basic Configuration 856
BGP and IGP Interaction Configuration 859
BGP Load Balancing and MED Attribute Configuration 862
BGP Community Configuration 864
BGP Route Reflector Configuration 866
BGP Confederation Configuration 868
BGP Path Selection Configuration 871
Troubleshooting BGP Configuration 874
No BGP Peer Relationship Established 874
57 IS-IS CONFIGURATION
IS-IS Overview 877
Basic Concepts 877
IS-IS Area 879
IS-IS Network Type 882
IS-IS PDU Format 883
IS-IS Features Supported 889
IS-IS Configuration Task List 892
Configuring IS-IS Basic Functions 893
Configuring IS-IS Routing Information Control 894
Specifying a Priority for IS-IS 894
Configuring IS-IS Link Cost 895
Configuring the Maximum Number of Load Balanced Routes 896
Configuring IS-IS Route Summarization 896
Advertising a Default Route 897
Configuring Inbound Route Filtering 897
Configuring Route Redistribution 897
Configuring IS-IS Route Leaking 898
Tuning and Optimizing IS-IS Network 898
Configuring a DIS Priority for an Interface 898
Configuring IS-IS Timers 899
Disabling an Interface from Sending/Receiving IS-IS Hello Packets 900

Configuring LSP Parameters 900
Configuring SPF Parameters 901
Configuring Dynamic Host Name Mapping 902
Configuring IS-IS Authentication 902
Configuring LSDB Overload Tag 903
Logging the Adjacency Changes 904
Enabling an Interface to Send Small Hello Packets 904
Enabling IS-IS Trap 904
Configuring IS-IS GR 904
Displaying and Maintaining IS-IS Configuration 905
IS-IS Configuration Example 906
IS-IS Basic Configuration 906
DIS Selection Configuration 910
IS-IS GR Configuration Example 913
58 OSPF CONFIGURATION
Introduction to OSPF 917
Basic Concepts 918
OSPF Area Partition and Route Summarization 919
Classification of OSPF Networks 924
DR and BDR 925
OSPF Packet Formats 926
OSPF Features Supported 935
Related RFCs 937
OSPF Configuration Task List 937
Configuring OSPF Basic Functions 939
Prerequisites 939
Configuring OSPF Area Parameters 940
Prerequisites 940
Configuring OSPF Network Types 941
Prerequisites 941
Configuring the OSPF Network Type for an Interface 941
Configuring an NBMA Neighbor 942
Configuring a Router Priority for an OSPF Interface 942
Configuring OSPF Routing Information Control 942
Prerequisites 942
Configuring OSPF Route Summarization 943
Configuring OSPF Inbound Route Filtering 943
Configuring ABR Type3 LSA Filtering 943
Configuring OSPF Link Cost 944
Configuring the Maximum Number of OSPF Routes 944
Configuring the Maximum Number of Load-balanced Routes 944
Configuring OSPF Priority 945
Configuring OSPF Route Redistribution 945
Configuring OSPF Network Optimization 946
Prerequisites 946
Configuring OSPF Packet Timers 946

Configuring LSA Transmission Delay Time 947
Configuring SPF Calculation Interval 948
Configuring LSA Minimum Repeat Arrival Interval 948
Configuring LSA Generation Interval 948
Disabling Interfaces from Sending OSPF Packets 949
Configuring Stub Routers 949
Configuring OSPF Authentication 950
Adding Interface MTU into DD Packets 950
Configuring the Maximum Number of External LSAs in LSDB 951
Making External Route Selection Rules Defined in RFC1583 Compatible 951
Logging Neighbor State Changes 951
Configuring OSPF Network Management 951
Enabling the Advertisement and Reception of Opaque LSAs 952
Configuring OSPF Graceful Restart 952
Configuring the OSPF GR Restarter 952
Configuring the OSPF GR Helper 953
Triggering OSPF Graceful Restart 953
Displaying and Maintaining OSPF Configuration 954
OSPF Configuration Examples 955
Configuring an OSPF Stub Area 958
Configuring an OSPF NSSA Area 960
Configuring OSPF DR Election 962
Configuring OSPF Virtual links 965
Troubleshooting OSPF Configuration 968
No OSPF Neighbor Relationship Established 968
Incorrect Routing Information 969
59 RIP CONFIGURATION
RIP Overview 971
RIP Working Mechanism 971
Operation of RIP 972
RIP Version 973
RIP Message Format 973
TRIP 975
RIP Features Supported 976
Configuring RIP Basic Functions 976
Configuring RIP Advanced Functions 978
Configuring an Additional Routing Metric 978
Configuring RIP-2 Route Summarization 979
Disabling Host Route Reception 980
Configuring Inbound/Outbound Route Filtering Policies 980
Configuring a Priority for RIP 981
Configuring RIP Route Redistribution 981

Optimizing the RIP Network 981
Configuring RIP Timers 982
Configuring the Split Horizon and Poison Reverse 982
Enabling CheckZero Field Check on RIPv1 Messages 983
Enabling Source IP Address Check on Incoming RIP Updates 984
Configuring RIP-2 Message Authentication 984
Configuring a RIP Neighbor 984
Configuring TRIP 985
Configuring RIP-to-MIB Binding 986
Displaying and Maintaining RIP Configuration 986
RIP Configuration Example 986
RIP Version Configuration 986
Configuring RIP Route Redistribution 988
Troubleshooting RIP Configuration 990
No RIP Updates Received 990
Route Oscillation Occurred 990
60 ROUTING POLICY CONFIGURATION

Introduction to Routing Policy 991
Routing Policy and Policy Routing 991
Filters 992
Routing Policy Application 993
Routing Policy Configuration Task List 993
Defining Filtering Lists 993
Prerequisites 993
Defining an IP-prefix List 993
Defining an AS Path ACL 995
Defining a Community List 995
Defining an Extended Community List 995
Configuring a Routing Policy 996
Prerequisites 996
Creating a Routing Policy 996
Defining if-match Clauses for the Routing Policy 996
Defining apply Clauses for the Routing Policy 998
Displaying and Maintaining the Routing Policy 1000
Routing Policy Configuration Example 1000
Applying Routing Policy When Redistributing IPv4 Routes 1000
Applying a Routing Policy When Redistributing IPv6 Routes 1003
Troubleshooting Routing Policy Configuration 1005
IPv4 Routing Information Filtering Failure 1005
IPv6 Routing Information Filtering Failure 1005
61 STATIC ROUTING CONFIGURATION

Introduction 1007
Static Route 1007
Default Route 1007
Application Environment of Static Routing 1008
Configuring a Static Route 1008

Detecting Reachability of the Static Route’s Nexthop 1009
Detecting Nexthop Reachability Through Track 1009
Displaying and Maintaining Static Routes 1010
62 IPV6 BGP CONFIGURATION

IPv6 BGP Overview 1015
IPv6 BGP Configuration Task List 1016
Configuring IPv6 BGP Basic Functions 1017
Prerequisites 1017
Configuring an IPv6 Peer 1017
Advertising a Local IPv6 Route 1017
Configuring a Preferred Value for Routes from a Peer/Peer Group 1018
Specifying a Local Update Source Interface to a Peer/Peer Group 1018
Configuring a Non Direct EBGP Connection to a Peer/Peer Group 1019
Configuring Description for a Peer/Peer Group 1019
Establishing No Session to a Peer/Peer Group 1019
Logging Session State and Event Information of a Peer/Peer Group 1019
Prerequisites 1020
Configuring IPv6 BGP Route Redistribution 1020
Advertising a Default Route to a Peer/Peer Group 1020
Configuring Route Distribution Policy 1021
Configuring Route Reception Policy 1021
Configuring IPv6 BGP and IGP Route Synchronization 1022
Configuring Route Dampening 1022
Configuring IPv6 BGP Route Attributes 1023
Prerequisites 1023
Configuring IPv6 BGP Preference and Default LOCAL_PREF and NEXT_HOP
Attributes 1023
Configuring the MED Attribute 1024
Configuring the AS_PATH Attribute 1024
Adjusting and Optimizing IPv6 BGP Networks 1024
Prerequisites 1025
Configuring IPv6 BGP Timers 1025
Configuring IPv6 BGP Soft Reset 1026
Configuring the Maximum Number of Load-Balanced Routes 1026
Configuring a Large Scale IPv6 BGP Network 1027
Prerequisites 1027
Configuring IPv6 BGP Peer Group 1027
Configuring IPv6 BGP Community 1028
Configuring an IPv6 BGP Route Reflector 1029
Configuring 6PE 1029
Configuring Basic 6PE Capabilities 1030
Configuring Optional 6PE Capabilities 1031
Displaying and Maintaining IPv6 BGP Configuration 1033
Displaying BGP 1033

Resetting IPv6 BGP Connections 1034
Clearing IPv6 BGP Information 1034
IPv6 BGP Configuration Examples 1034
IPv6 BGP Basic Configuration 1034
IPv6 BGP Route Reflector Configuration 1036
6PE Configuration 1037
Troubleshooting IPv6 BGP Configuration 1041
No IPv6 BGP Peer Relationship Established 1041
63 IPV6 IS-IS CONFIGURATION

Introduction to IPv6 IS-IS 1043
Configuring IPv6 IS-IS Basic Functions 1043
Configuring IPv6 IS-IS Routing Information Control 1044
Displaying and Maintaining IPv6 IS-IS 1045
IPv6 IS-IS Configuration Example 1046
64 IPV6 OSPFV3 CONFIGURATION

Introduction to OSPFv3 1049
OSPFv3 Overview 1049
OSPFv3 Packets 1049
OSPFv3 LSA Types 1050
Timers of OSPFv3 1050
OSPFv3 Features Supported 1051
Related RFCs 1051
IPv6 OSPFv3 Configuration Task List 1051
Configuring OSPFv3 Basic Functions 1052
Prerequisites 1052
Configuring OSPFv3 Basic Functions 1052
Configuring OSPFv3 Area Parameters 1053
Prerequisites 1053
Configuring an OSPFv3 Stub Area 1053
Configuring OSPFv3 Virtual Links 1054
Configuring OSPFv3 Routing Information Management 1054
Prerequisites 1054
Configuring OSPFv3 Route Summarization 1054
Configuring OSPFv3 Inbound Route Filtering 1054
Configuring Link Costs for OSPFv3 Interfaces 1055
Configuring the Maximum Number of OSPFv3 Load-balanced Routes 1055
Configuring a Priority for OSPFv3 1055
Configuring OSPFv3 Route Redistribution 1056
Tuning and Optimizing an OSPFv3 Network 1056
Prerequisites 1056
Configuring OSPFv3 Timers 1056
Configuring the DR Priority for an Interface 1057
Ignoring MTU Check for DD Packets 1057

Disabling Interfaces from Sending OSPFv3 Packets 1058
Enabling the Logging on Neighbor State Changes 1058
Displaying and Maintaining OSPFv3 1059
OSPFv3 Configuration Examples 1059
Configuring OSPFv3 Areas 1059
Configuring OSPFv3 DR Election 1063
Troubleshooting OSPFv3 Configuration 1066
No OSPFv3 Neighbor Relationship Established 1066
Incorrect Routing Information 1066
65 IPV6 RIPNG CONFIGURATION

Introduction to RIPng 1069
RIPng Working Mechanism 1069
RIPng Packet Format 1070
RIPng Packet Processing Procedure 1071
Configuring RIPng Basic Functions 1071
Configuring RIPng Advanced Functions 1072
Configuring an Additional Routing Metric 1072
Configuring RIPng Route Summarization 1073
Configuring a RIPng Route Filtering Policy 1073
Configuring the RIPng Priority 1074
Configuring RIPng Route Redistribution 1074
Optimizing the RIPng Network 1074
Configuring RIPng Timers 1075
Configuring the Split Horizon and Poison Reverse 1075
Configuring Zero Field Check 1076
Displaying and Maintaining RIPng 1076
RIPng Configuration Example 1077
66 IPV6 STATIC ROUTING CONFIGURATION

Introduction to IPv6 Static Routing 1081
Features of IPv6 Static Routes 1081
Default IPv6 Route 1081
Configuring an IPv6 Static Route 1081
Configuring an IPv6 Static Route 1082
Displaying and Maintaining IPv6 Static Routes 1082
IPv6 Static Routing Configuration Example 1082
67 MULTICAST OVERVIEW
Introduction to Multicast 1085
Comparison of Information Transmission Techniques 1085
Roles in Multicast 1087
Advantages and Applications of Multicast 1088

Multicast Models 1088
Multicast Architecture 1089
Multicast Addresses 1089
Multicast Protocols 1092
Multicast Packet Forwarding Mechanism 1095
Multi-Instance Multicast 1095
Introduction to the Multi-Instance Concept 1095
Multi-Instance Application in Multicast 1096
68 MULTICAST ROUTING AND FORWARDING CONFIGURATION

Multicast Routing and Forwarding Overview 1097
Introduction to Multicast Routing and Forwarding 1097
RPF Mechanism 1097
Multicast static route 1100
Multicast Traceroute 1101
Application of GRE Tunnel in Multicast Forwarding 1101
Configuring Multicast Routing and Forwarding 1102
Enabling IP Multicast Routing 1103
Configuring Multicast Static Routes 1103
Configuring a Multicast Routing Policy 1104
Configuring Multicast Forwarding Range 1104
Configuring Multicast Forwarding Table Size 1105
Tracing a Multicast Path 1106
Displaying and Maintaining Multicast Routing and Forwarding 1106
Configuration Examples 1108
Changing an RPF Route 1108
Creating an RPF Route 1110
Troubleshooting Multicast Routing and Forwarding 1112
Multicast Static Route Failure 1112
Multicast Data Fails to Reach Receivers 1113
69 IGMP CONFIGURATION
IGMP Overview 1115
IGMP Versions 1115
Work Mechanism of IGMPv1 1115
Enhancements in IGMPv2 1117
Enhancements in IGMPv3 1118
Multi-Instance IGMP 1119
IGMP Configuration Task List 1119
Configuring Basic Functions of IGMP 1120
Enabling IGMP 1120
Configuring IGMP Versions 1121
Configuring a Static Member of a Multicast Group 1122
Configuring a Multicast Group Filter 1122
Adjusting IGMP Performance 1123

Configuring IGMP Message Options 1123
Configuring IGMP Query and Response Parameters 1124
Configuring IGMP Fast Leave Processing 1126
Displaying and Maintaining IGMP 1127
IGMP Configuration Example 1127
Troubleshooting IGMP 1129
No Membership Information on the Receiver-Side Router 1129
Inconsistent Memberships on Routers on the Same Subnet 1130
70 MSDP CONFIGURATION
MSDP Overview 1131
Introduction to MSDP 1131
How MSDP Works 1132
Multi-Instance MSDP 1137
MSDP Configuration Task List 1137
Configuring Basic Functions of MSDP 1138
Enabling MSDP 1138
Creating an MSDP Peer Connection 1139
Configuring a Static RPF Peer 1139
Configuring an MSDP Peer Connection 1140
Configuring MSDP Peer Description 1140
Configuring an MSDP Mesh Group 1140
Configuring MSDP Peer Connection Control 1141
Configuring SA Messages 1141
Configuring SA Message Content 1142
Configuring SA Request Messages 1142
Configuring an SA Message Filtering Rule 1143
Configuring SA Message Cache 1144
Displaying and Maintaining MSDP 1144
MSDP Configuration Examples 1145
Example of Leveraging BGP Routes 1145
Anycast RP Configuration Example 1150
Static RPF Peer Configuration Example 1154
Troubleshooting MSDP 1158
MSDP Peers Stay in Down State 1158
No SA Entries in the Router’s SA Cache 1158
Inter-RP Communication Faults in Anycast RP Application 1159
71 PIM CONFIGURATION
PIM Overview 1161
Introduction to PIM-DM 1161
How PIM-DM Works 1162
Introduction to PIM-SM 1164
How PIM-SM Works 1165

Introduction to BSR Admin-scope Regions in PIM-SM 1169
SSM Model Implementation in PIM 1171
Multi-Instance PIM 1172
Configuring PIM-DM 1173
PIM-DM Configuration Task List 1173
Enabling PIM-DM 1173
Enabling State Refresh 1174
Configuring State Refresh Parameters 1175
Configuring PIM-DM Graft Retry Period 1175
Configuring PIM-SM 1176
PIM-SM Configuration Task List 1176
Enabling PIM-SM 1177
Configuring a BSR 1178
Configuring an RP 1182
Configuring PIM-SM Register Messages 1184
Configuring RPT-to-SPT Switchover 1185
Configuring PIM-SSM 1185
PIM-SSM Configuration Task List 1185
Enabling PIM-SM 1186
Configuring the SSM Group Range 1186
Configuring PIM Common Information 1187
PIM Common Information Configuration Task List 1187
Configuring a PIM Filter 1188
Configuring PIM Hello Options 1188
Configuring PIM Common Timers 1190
Configuring Join/Prune Message Limits 1192
Displaying and Maintaining PIM 1192
PIM Configuration Examples 1193
PIM-DM Configuration Example 1193
PIM-SM Configuration Example 1197
PIM-SSM Configuration Example 1202
Troubleshooting PIM Configuration 1205
Failure of Building a Multicast Distribution Tree Correctly 1205
Multicast Data Abnormally Terminated on an Intermediate Router 1206
RPs Unable to Join SPT in PIM-SM 1207
No Unicast Route Between BSR and C-RPs in PIM-SM 1208
72 IPV6 MULTICAST ROUTING AND FORWARDING CONFIGURATION

IPv6 Multicast Routing and Forwarding Overview 1209
Introduction to IPv6 Multicast Routing and Forwarding 1209
RPF Mechanism 1209
Configuring IPv6 Multicast Routing and Forwarding 1212

Enabling IPv6 Multicast Routing 1212
Configuring an IPv6 Multicast Routing Policy 1212
Configuring an IPv6 Multicast Forwarding Range 1213
Configuring the IPv6 Multicast Forwarding Table Size 1213
Displaying and Maintaining IPv6 Multicast Routing and Forwarding 1214
Troubleshooting IPv6 Multicast Routing and Forwarding 1215
Abnormal Termination of IPv6 Multicast Data 1215
73 MLD CONFIGURATION
MLD Overview 1217
Introduction to MLD 1217
MLD Version 1217
How MLDv1 Works 1217
How MLDv2 Works 1219
MLD Message Types 1220
Configuring Basic Functions of MLD 1224
Enabling MLD 1224
Configuring the MLD Version 1224
Configuring a Static Member of an IPv6 Multicast Group 1225
Configuring an IPv6 Multicast Group Filter 1225
Adjusting MLD Performance 1226
Configuring MLD Message Options 1226
Configuring MLD Query and Response Parameters 1227
Configuring MLD Fast Leave Processing 1229
Displaying and Maintaining MLD Configuration 1230
MLD Configuration Example 1230
Troubleshooting MLD 1232
No Member Information on the Receiver-Side Router 1232
Inconsistent Memberships on Routers on the Same Subnet 1233
74 IPV6 PIM CONFIGURATION

IPv6 PIM Overview 1235
Introduction to IPv6 PIM-DM 1235
How IPv6 PIM-DM Works 1236
Introduction to IPv6 PIM-SM 1238
How IPv6 PIM-SM Works 1239
SSM Model Implementation in IPv6 PIM 1244
Configuring IPv6 PIM-DM 1246
IPv6 PIM-DM Configuration Task List 1246
Enabling IPv6 PIM-DM 1246
Enabling State Refresh 1247
Configuring State Refresh Parameters 1247
Configuring IPv6 PIM-DM Graft Retry Period 1248

Configuring IPv6 PIM-SM 1248
IPv6 PIM-SM Configuration Task List 1248
Enabling IPv6 PIM-SM 1249
Configuring a BSR 1250
Configuring an RP 1252
Configuring IPv6 PIM-SM Register Messages 1254
Configuring RPT-to-SPT Switchover 1255
Configuring IPv6 PIM-SSM 1256
IPv6 PIM-SSM Configuration Task List 1256
Enabling IPv6 PIM-SM 1257
Configuring the IPv6 SSM Group Range 1257
Configuring IPv6 PIM Common Information 1258
IPv6 PIM Common Information Configuration Task List 1258
Configuring an IPv6 PIM filter 1259
Configuring IPv6 PIM Hello Options 1259
Configuring IPv6 PIM Common Timers 1261
Configuring Join/Prune Message Limits 1262
Displaying and Maintaining IPv6 PIM 1263
IPv6 PIM Configuration Examples 1263
IPv6 PIM-DM Configuration Example 1263
IPv6 PIM-SM Configuration Example 1267
IPv6 PIM-SSM Configuration Example 1272
Troubleshooting IPv6 PIM Configuration 1275
Failure of Building a Multicast Distribution Tree Correctly 1275
RPs Unable to Join SPT in IPv6 PIM-SM 1276
No Unicast Route Between BSR and C-RPs in IPv6 PIM-SM Domain 1277
75
MULTICAST VPN CONFIGURATION

Multicast VPN Overview 1279
Introduction to MPLS L3VPN 1279
Introduction to Multicast VPN 1281
Introduction to MD-VPN 1282
How MD-VPN Works 1285
Share-MDT Established 1285
Share-MDT-Based Deliver of Multicast Protocol Packets 1287
Share-MDT-Based Delivery of Multicast Data Packets 1289
MDT Switching 1290
MD-VPN Configuration Task List 1292
Configuring MD-VPN 1292
Enabling IP Multicast Routing in a VPN Instance 1292
Configuring a Share-Group and an MTI Binding 1293
Configuring MDT Switching Parameters 1293

Enabling Switch-Group Reuse Log 1294
Displaying and Maintaining MD-VPN 1294
MD-VPN Configuration Example 1295
Troubleshooting MD-VPN Configuration 1308
Unable to Establish a Share-MDT 1308
Unable to Build an MVRF 1309
76 MPLS BASICS CONFIGURATION

MPLS Overview 1311
Basic Concepts of MPLS 1312
Architecture of MPLS 1314
MPLS and Routing Protocols 1316
Applications of MPLS 1316
MPLS Configuration Basics 1318
Label Advertisement and Management 1318
PHP 1319
TTL Processing in MPLS 1319
Inspecting an MPLS LSP 1320
LDP Overview 1321
LDP Basic Concepts 1321
LDP Label Distribution 1322
Fundamental Operation of LDP 1323
LDP Loop Detection 1324
LDP GR 1325
Configuring MPLS Basic Capability 1325
Configuring PHP 1326
Configuring a Static LSP 1327
Configuring MPLS LDP 1328
MPLS LDP Configuration Task List 1328
Configuring MPLS LDP Capability 1328
Configuring Local LDP Session Parameters 1329
Configuring Remote LDP Session Parameters 1329
Configuring the Policy for Triggering LSP Establishment 1330
Configuring Label Advertisement, Distribution and Retention Modes 1331
Configuring LDP Loop Detection 1331
Configuring LDP MD5 Authentication 1331
Enabling MTU Signaling 1332
Configuring LDP Instances 1332
Configuring LDP GR 1333

Restarting MPLS LDP 1334
Gracefully Restarting MPLS LDP 1334
Configuring MPLS IP TTL Processing 1334
Configuring MPLS IP TTL Propagation 1334
Specifying the Type of Path for ICMP Responses 1334
Configuring MPLS Fast Forwarding 1335
Setting the Interval for Reporting Statistics 1336
Inspecting an MPLS LSP 1336
Enabling MPLS Trap 1336
Displaying and Maintaining MPLS 1336
Resetting LDP Sessions 1336
Displaying MPLS Operation 1337
Displaying MPLS LDP Operation 1337
Clearing MPLS Statistics 1338
MPLS Configuration Example 1338
LDP Session Configuration Example 1338
Configuring LDP to Establish LSPs 1342
Troubleshooting MPLS 1343
77 MPLS TE CONFIGURATION
MPLS TE Overview 1345
Traffic Engineering and MPLS TE 1345
Basic Concepts of MPLS TE 1347
MPLS TE Implementation 1347
CR-LSP 1348
CR-LDP 1349
RSVP-TE 1349
Traffic Forwarding 1354
Automatic Bandwidth Adjustment 1355
CR-LSP Backup 1356
Fast Reroute 1356
DiffServ-Aware TE 1357
MPLS TE Configuration Task List 1358
Configuring MPLS TE Basic Capabilities 1359
Configuration procedure 1359
Creating MPLS TE Tunnel over Static CR-LSP 1360
Configuring MPLS TE Tunnel with Dynamic Signaling Protocol 1361
Configuring RSVP-TE Advanced Features 1366
Tuning CR-LSP Setup 1370

Tuning MPLS TE Tunnel Setup 1372
Configuration Procedures 1372
Configuring Traffic Forwarding 1374
Configuration Procedures 1374
Configuring Traffic Forwarding Tuning Parameters 1377
Configuring Automatic Bandwidth Adjustment 1379
Configuring CR-LSP Backup 1380
Configuring FRR 1381
Displaying and Maintaining MPLS TE 1384
Displaying and Maintaining MPLS TE 1384
Resetting Automatic Bandwidth Adjustment 1385
MPLS TE Configuration Example 1386
MPLS TE Using Static CR-LSP Configuration Example 1386
MPLS TE Tunnel Using RSVP-TE Configuration Example 1390
RSVP-TE GR Configuration Example 1396
MPLS TE Using CR-LDP Configuration Example 1398
CR-LSP Backup Configuration Example 1405
FRR Configuration Example 1409
MPLS TE in MPLS L3VPN Configuration Example 1417
Troubleshooting MPLS TE 1424
78 MPLS L2VPN CONFIGURATION

MPLS L2VPN Overview 1425
CCC MPLS L2VPN 1428
SVC MPLS L2VPN 1428
Martini MPLS L2VPN 1428
Kompella MPLS L2VPN 1429
Configuring MPLS L2VPN 1429
Configuring a PE Interface Connecting a CE 1430
Configuring a PE Interface Connecting a CE to Use PPP/HDLC/FR 1430
Configuring a PE Interface Connecting a CE to Use Ethernet 1431
Configuring a PE Interface Connecting a CE to Use VLAN 1431
Configuring a PE Interface Connecting a CE to Use ATM AAL5 1431
Configuring CCC MPLS L2VPN 1432
Configuring SVC MPLS L2VPN 1433

Configuring Martini MPLS L2VPN 1434
Configuring Kompella MPLS L2VPN 1435
Displaying and Maintaining MPLS L2VPN 1438
Displaying the Operation of MPLS L2VPN 1438
Resetting BGP L2VPN Connections 1438
MPLS L2VPN Configuration Example 1438
Example for Configuring a Local CCC Connection 1438
Example for Configuring a Remote CCC Connection 1440
Example for Configuring SVC MPLS L2VPN 1444
Example for Configuring Martini MPLS L2VPN 1448
Example for Configuring Kompella MPLS L2VPN 1452
Example for Configuring a Kompella Local Connection 1455
Troubleshooting MPLS L2VPN 1456
79 MPLS L3VPN CONFIGURATION

MPLS L3VPN Overview 1459
MPLS L3VPN Concepts 1460
MPLS L3VPN Packet Forwarding 1463
MPLS L3VPN Networking Schemes 1464
MPLS L3VPN Routing Information Advertisement 1467
Carrier’s Carrier 1468
Multi-AS VPN 1470
Multi-Role Host 1473
HoVPN 1473
OSPF VPN Extension 1476
BGP AS Number Substitution 1480
MPLS L3VPN Configuration Task List 1480
Configuring VPN Instances 1481
Creating a VPN Instance 1481
Associating a VPN Instance with an Interface 1481
Configuring Route Related Attributes of a VPN Instance 1482
Configuring a Tunneling Policy of a VPN Instance 1483
Configuring Basic MPLS L3VPN 1484
Configuring a VPN Instance 1484
Configuring Route Advertisement between PE and CE 1484
Configuring Route Advertisement between PEs 1488
Configuring Routing Features for BGP VPNv4 Subaddress Family 1488
Configuring Inter-Provider VPN 1491
Configuring Inter-Provider VPN Option A 1491
Configuring Inter-Provider VPN Option B 1491
Configuring Inter-Provider VPN Option C 1492
Configuring Multi-Role Host 1495

Configuring Policy Routing 1495
Applying Policy Routing 1495
Configuring a Static Route 1495
Configuring HoVPN 1495
Configuring HoVPNs 1495
Configuring OSPF Sham Link 1496
Configuring a Loopback Interface 1496
Advertising Routes of a Loopback Interface 1497
Creating a Sham Link 1497
Configuring Multi-VPN-instance CE 1497
Configuring BGP AS Number Substitution 1498
Resetting BGP Connections 1499
MPLS L3VPN Configuration Example 1501
Example for Configuring MPLS L3VPNs 1501
Example for Configuring MPLS L3VPNs Using a GRE Tunnel 1508
Example for Configuring Inter-Provider VPN Option A 1513
Example for Configuring Inter-Provider VPN Option B 1519
Example for Configuring Inter-Provider VPN Option C 1524
Example for Configuring Carrier’s Carrier 1531
Example for Configuring Multi-Role Host 1538
Example for Configuring HoVPN 1540
Example for Configuring OSPF Sham Links 1547
Example for Configuring BGP AS Number Substitution 1552
80 DVPN CONFIGURATION
DVPN Overview 1557
Basic Concepts of DVPN 1557
Operation of DVPN 1558
Implementation of DVPN 1559
Supported DVPN Features 1561
DVPN Configuration Task List 1562
Configuring AAA 1562
Configuring the VAM Server 1562
VAM Server Configuration Task List 1562
Creating a VPN Domain 1562
Enabling the VAM Server 1563
Configuring the Listening IP Address and UDP Port Number 1563
Configuring Security Parameters for VAM PDUs 1563
Configuring a Client Authentication Mode 1564

Configuring the IP Address of Hub 1564
Configuring the Pre-Shared Key of VAM Server for a VPN Domain 1565
Configuring Keepalive Parameters 1565
Configuring the VAM Client 1565
VAM Client Configuration Task List 1566
Creating a VAM Client 1566
Specifying an Interval for Resending a VAM Packet 1566
Specifying the Primary VAM Server 1566
Specifying the Secondary VAM Server 1567
Creating a Local User and Password 1567
Specifying the VPN Domain of the VAM Client 1567
Specifying the Pre-Shared Key of the VAM Client 1567
Enabling the VAM Client 1568
Configuring an IPSec Profile 1568
Configuring an IPSec Profile 1568
Configuring the DVPN Tunnel Parameters 1569
Prerequisites 1569
Configuring a DVPN Tunnel 1569
Configuring a DVPN Route 1571
Displaying and Maintaining DVPN 1571
DVPN Configuration Example 1571
DVPN Configuration Example for Full-Mesh Networks 1571
DVPN Configuration Example for Spoke-Hub Networks 1581
81 GRE CONFIGURATION
GRE Overview 1589
Introduction to GRE 1589
GRE Applications 1591
Configuring a GRE over IPv4 Tunnel 1593
Configuring a GRE over IPv6 Tunnel 1594
Displaying and Maintaining GRE 1596
GRE over IPv4 Tunnel Configuration Example 1596
GRE over IPv6 Tunnel Configuration Example 1598
Troubleshooting GRE 1600
82 L2TP CONFIGURATION
L2TP Overview 1601
Introduction to VPDN 1601
Introduction to L2TP 1602
L2TP Configuration Task List 1607
LAC Configuration 1607
Configuring the LAC 1607
Configuring the Local AAA Scheme and the Users and Passwords 1609
LNS Configuration 1609
Configuring the LNS 1609

Configuring Mandatory CHAP Authentication 1611
Specifying to perform LCP Negotiation with Users 1612
Configuring the Local Address and the Address Pool for Allocation 1613
Configuring Local Authentication, Usernames and Passwords 1614
Specifying to Include ACCM in Control Messages 1614
Displaying and Maintaining L2TP 1614
L2TP Configuration Example 1614
NAS-Initiated VPN 1615
Client-Initiated VPN 1617
L2TP Multi-Domain Application 1618
Complicated Network Application 1621
Troubleshooting L2TP 1621
83 QOS OVERVIEW
Introduction 1623
Traditional Packets Forwarding Application 1623
New Requirements Caused by New Applications 1623
Congestion: Causes, Impact, and Countermeasures 1624
Causes 1624
Impact 1625
Countermeasure 1625
Traffic Management Technologies 1625
84 TRAFFIC CLASSIFICATION, POLICING, AND SHAPING

Traffic Classification Overview 1627
Traffic classification 1627
Priority 1627
Traffic Policing and Traffic Shaping 1628
Traffic Evaluation and Token Bucket 1628
Traffic Policing and Traffic Shaping Configuration 1632
Configuring Traffic Policing 1632
Configuring Traffic Shaping 1635
Configuring Line Rate on Physical Interface 1637
Displaying and Maintaining TP/TS/Rate Limiting 1638
Traffic Policing and Shaping Configuration Example 1639
85 QOS POLICY CONFIGURATION

Introduction 1641
Configuring QoS Policy 1641
Introduction to QoS Policies 1642
QoS Policy Configuration 1642
Defining a Class 1642
Defining Traffic Behavior 1643
Defining Policy 1645
Applying Policy 1645
Displaying and Maintaining QoS Policy 1647

86 CONGESTION MANAGEMENT
Congestion Management Overview 1649
Congestion Management Policies 1649
Comparison of Congestion Management Technologies 1654
Configuring FIFO Queuing 1656
Configuring FIFO Queuing 1656
Configuration Example for FIFO Queuing 1656
Configuring Priority Queuing 1657
Configuring Priority Queuing 1657
Priority Queuing Configuration Example 1658
Configuring Custom Queuing 1659
Configuring Custom Queuing 1659
CQ Configuration Example 1659
Configuring WFQ 1660
Configuring WFQ 1660
WFQ Configuration Example 1660
Configuring Class-based Queuing 1661
Configuring the Maximum Available Bandwidth on the Interface 1662
Defining a Class 1663
Defining Traffic Behavior 1663
Defining Policy 1668
Applying Policy 1669
CBQ Configuration Example 1670
Displaying and Maintaining CBQ 1672
Configuring RTP Priority Queuing 1672
Configuring RTP Priority Queuing 1672
RTP PQ Configuration Example 1673
Token Function of QoS 1673
Configuring QoS Token 1673
QoS Token Configuration Example 1674
87 PRIORITY MAPPING
Priority Mapping Overview 1675
Configuring Priority Mapping Table 1676
Configuring Port Priority 1678
Configuring Port Priority Trust Mode 1678
Displaying and Maintaining Priority Mapping 1679
Priority Mapping Configuration Example 1680
Network Example 1 1680
Network Example 2 1681

88 CONGESTION AVOIDANCE
Congestion Avoidance Overview 1683
Configuring WRED 1685
Configuring WRED through Two Methods 1685
WRED Parameters 1685
Configuring WRED on Interface 1686
Configuring WRED Through WRED Table 1687
Displaying and Maintaining WRED 1688
WRED Configuration Example 1688
89 MPLS QOS CONFIGURATION

MPLS QoS Overview 1689
Configuring MPLS QoS 1689
Configuring MPLS PQ 1690
Configuring MPLS CQ 1690
Configuring MPLS QoS Policy 1691
MPLS QoS Configuration Example 1692
Configuring QoS for Traffics in the Same VPN 1692
90 DAR CONFIGURATION
DAR Overview 1697
IP Packet 1697
TCP Packet 1699
UDP Packet 1700
HTTP Packet 1700
RTP Packet 1701
RTCP Packet 1701
Static Protocols 1702
Configuring DAR 1704
Configuring Matching Rules of Protocol 1704
Configuring Port Number of DAR Application Protocol 1705
Renaming User-defined Protocols 1705
Configuring DAR Packet Statistics Function 1706
Configuring the Maximum Connection Number Recognizable by DAR 1706
Displaying and Maintaining DAR 1706
DAR Configuration Examples 1707
91 FRAME RELAY QOS CONFIGURATION

Frame Relay QoS Overview 1709
Frame Relay QoS 1709
Key Parameters 1709
Frame Relay QoS Implemented 1710
Configuring Frame Relay QoS 1716
Frame Relay QoS Configuration Tasks 1716

Creating and Configuring a Frame Relay Class 1716
Configuring Frame Relay Traffic Shaping 1717
Configuring Frame Relay Traffic Policing 1718
Configuring Frame Relay Congestion Management 1719
Configuring Frame Relay DE Rule List 1719
Configuring Frame Relay Queuing Management 1720
Configuring Frame Relay Fragmentation 1721
Displaying and Maintaining Frame Relay QoS 1722
Frame Relay QoS Configuration Example 1723
FRTS Configuration Example 1723
Frame Relay Fragmentation Configuration Example 1724
Frame Relay WRED Configuration Example 1725
92 802.1X CONFIGURATION
802.1x Overview 1729
Architecture of 802.1x 1729
Operation of 802.1x 1731
EAP Encapsulation over LANs 1731
EAP Encapsulation over RADIUS 1733
Authentication Process of 802.1x 1734
802.1x Timers 1737
Implementation of 802.1x in the Devices 1738
Features Working Together with 802.1x 1738
Guest VLAN 1739
Configuring 802.1x 1740
Configuring 802.1x Globally 1740
Configuring 802.1x for a Port 1741
Configuring a Guest VLAN 1743
Displaying and Maintaining 802.1x 1743
802.1x Configuration Example 1744
Guest VLAN Configuration Example 1746
93 AAA/RADIUS/HWTACACS CONFIGURATION
AAA/RADIUS/HWTACACS Configuration Overview 1751
Introduction to AAA 1751
Introduction to ISP Domain 1752
Introduction to RADIUS 1753
Introduction to HWTACACS 1757
AAA/RADIUS/HWTACACS Configuration Task List 1760
Configuring AAA 1761
Creating an ISP Domain 1761
Configuring ISP Domain Attributes 1762
Configuring an AAA Authentication Scheme for an ISP Domain 1762
Configuring an AAA Authorization Scheme for an ISP Domain 1764
Configuring an AAA Accounting Scheme for an ISP Domain 1766

Configuring Local User Attributes 1767
Tearing down User Connections Forcibly 1769
Configuring RADIUS 1769
Creating a RADIUS Scheme 1769
Specifying the RADIUS Authentication/Authorization Servers 1770
Configuring the RADIUS Accounting Servers and Relevant Parameters 1770
Setting the Shared Key for RADIUS Packets 1771
Setting the Upper Limit of RADIUS Request Retransmission Attempts 1772
Setting the Supported RADIUS Server Type 1772
Setting the Status of RADIUS Servers 1772
Configuring Attributes Related to the Data Sent to the RADIUS Server 1773
Setting Timers Regarding RADIUS Servers 1774
Configuring RADIUS Accounting-on 1775
Configuring an IP Address for the Security Policy Server 1776
Enabling the Listening Port of the RADIUS Client 1776
Configuring HWTACACS 1777
Creating a HWTACACS scheme 1777
Specifying the HWTACACS Authentication Servers 1777
Specifying the HWTACACS Authorization Servers 1777
Specifying the HWTACACS Accounting Servers 1778
Setting the Shared Key for HWTACACS Packets 1779
Configuring Attributes Related to the Data Sent to the TACACS Server 1779
Setting Timers Regarding HWTACACS Servers 1780
Displaying and Maintaining AAA/RADIUS/HWTACACS 1780
Displaying and Maintaining AAA 1780
Displaying and Maintaining RADIUS 1781
Displaying and Maintaining HWTACACS 1781
AAA/RADIUS/HWTACACS Configuration Example 1781
AAA for Telnet/SSH Users by a RADIUS Server 1781
AAA for FTP/Telnet Users by the Device Itself 1783
AAA for PPP Users by a HWTACACS Server 1784
Troubleshooting AAA/RADIUS/HWTACACS 1786
Troubleshooting RADIUS 1786
Troubleshooting HWTACACS 1787
94 FIREWALL CONFIGURATION
Firewall Overview 1789
Packet Filter Firewall 1789
ASPF 1790
Configuring a Packet Filter Firewall 1794
Packet Filter Firewall Configuration Task list 1794
Enabling the Firewall Function 1794
Configuring the Default Filtering Action of the Firewall 1794
Enabling Fragment Inspection 1794
Configuring the High and Low Watermarks for Fragment Inspection 1795
Configuring Packet Filtering on an Interface 1795
Configuring Ethernet Frame Filtering 1796
Displaying and Maintaining a Packet Filter Firewall 1796
Packet Filter Firewall Configuration Example 1797

Configuring an ASPF 1798
ASPF Configuration Task List 1798
Enabling the Firewall Function 1798
Configuring an ASPF Policy 1799
Applying an ASPF Policy to an Interface 1799
Enabling the Session Logging Function for ASPF 1800
Configuring Port Mapping 1800
Displaying and Maintaining an ASPF 1800
ASPF Configuration Example 1801
95 MAC AUTHENTICATION CONFIGURATION

MAC Authentication Overview 1803
RADIUS-Based MAC Authentication 1803
Local MAC Authentication 1804
Related Concepts 1804
MAC Authentication Timers 1804
Quiet MAC Address 1804
Configuring MAC Authentication 1804
Displaying and Maintaining MAC Authentication 1806
MAC Authentication Configuration Examples 1806
Local MAC Authentication Example 1806
RADIUS-Based MAC Authentication Example 1807
96 NAT CONFIGURATION
NAT Overview 1811
Introduction to NAT 1811
NAT Functionalities 1813
NAT Configuration Task List 1815
Configuring Address Translation 1816
Introduction to Address Translation 1816
Configuring Address Translation 1817
Configuring Internal Server 1818
Introduction to Internal Server 1818
Configuring an Internal Server 1818
Configuring NAT Log 1818
Introduction to NAT Log 1818
Enabling NAT Log Function 1819
Exporting NAT Logs 1819
Configuring Connection-limit 1820
Introduction to Connection-limit 1820
Displaying and Maintaining NAT 1822
NAT Configuration Example 1823
NAT Configuration Example 1823
Exporting NAT Logs to the Information Center 1825
Exporting NAT logs to Log Server 1826
Troubleshooting NAT 1827
Symptom 1: Abnormal Translation of IP Addresses 1827

Symptom 2: Internal Server Functions Abnormally 1827
97 PKI CONFIGURATION
Introduction to PKI 1829
PKI Overview 1829
PKI Terms 1829
Architecture of PKI 1830
Applications of PKI 1831
Operation of PKI 1831
PKI Configuration Task List 1832
Configuring an Entity DN 1832
Configuring a PKI Domain 1833
Submitting a PKI Certificate Request 1835
Submitting a Certificate Request in Auto Mode 1835
Submitting a Certificate Request in Manual Mode 1836
Retrieving a Certificate Manually 1837
Configuring PKI Certificate Validation 1837
Destroying a Local RSA Key Pair 1838
Deleting a Certificate 1839
Configuring an Access Control Policy 1839
Displaying and Maintaining PKI 1840
PKI Configuration Examples 1840
Configuring a PKI Entity to Request a Certificate from a CA 1840
Applying RSA Digital Signature in IKE Negotiation 1844
Configuring a Certificate Attribute-Based Access Control Policy 1846
Troubleshooting PKI 1848
Failed to Retrieve a CA Certificate 1848
Failed to Request a Local Certificate 1849
Failed to Retrieve CRLs 1849
98 PORTAL CONFIGURATION
Portal Overview 1851
Introduction to Portal 1851
Introduction to Extended Portal 1851
Portal System Components 1852
Portal Authentication Mode 1854
Portal Authentication Process 1855
Portal Configuration Task List 1857
Basic Portal Configuration 1857
Configuring an Authentication-Free Rule 1858
Configuring an Authentication Subnet 1859
Forcing a User to Log Out 1859
Configuring the Name of the Resource to be Protected 1860
Displaying and Maintaining Portal 1860
Portal Configuration Examples (on Routers) 1861
Portal Direct Authentication Configuration Examples 1861
Re-DHCP Authentication Configuration Examples 1863
Portal Layer 3 Portal Authentication Configuration Examples 1864

Portal+ Direct Authentication Configuration Examples 1865
Portal + Re-DHCP Authentication Configuration Examples 1867
Layer 3 Portal + Layer 3 Authentication Configuration Examples 1869
Troubleshooting Portal 1870
Inconsistent Keys on the Access Device and the Portal Server 1870
Incorrect Server Port Number on the Access Device 1871
99 RSH CONFIGURATION
Introduction to RSH 1873
Configuring RSH 1873
RSH Configuration Example 1874
100 IPSEC CONFIGURATION

IPSec Overview 1877
Operation of IPSec 1877
Basic Concepts of IPSec 1878
Encryption Card 1880
IPSec Configuration Task List 1880
Configuring ACLs 1881
Configuring an IPSec Proposal 1882
Configuring an IPSec Policy 1882
Configuring a Manual IPSec Policy 1883
Configuring an IKE-Dependent IPSec Policy 1884
Applying an IPSec Policy Group to an Interface 1887
Binding an IPSec Policy (Group) to an Encryption Card 1887
Enabling the Encryption Engine 1888
Enabling the IPSec Module Backup Function 1888
Configuring the IPSec Session Idle Timeout 1889
Enabling Encryption Card Fast Forwarding 1889
Displaying and Maintaining IPSec 1890
IPSec Configuration Example 1890
Example for Establishing SAs in Manual Mode 1890
Example for Establishing SAs in IKE Negotiation Mode 1893
Example for Employing Encryption Cards for IPSec Services 1896
101 IKE CONFIGURATION

IKE Overview 1901
Security Mechanisms of IKE 1901
Operation of IKE 1902
Function of IKE 1903
Relationship between IKE and IPSec 1903
IKE Configuration Task List 1903
Configuring a Name for the Local Security Gateway 1904
Configuring an IKE Proposal 1904
Configuring an IKE Peer 1905
Configuring Keepalive Timers 1907

Setting the NAT Keepalive Timer 1907
Configuring a DPD 1907
Disabling Next Payload Field Checking 1908
Displaying and Maintaining IKE 1908
IKE Configuration Example 1909
Example for Configuring IKE 1909
Example for IKE Aggressive Mode and NAT Traversal 1910
Example for Configuring IPSec/IKE to Work with ADSL 1913
Troubleshooting IKE 1916
Invalid User ID Information 1916
Proposal Mismatch 1917
Failure to Establish an IPSec Tunnel 1917
ACL Configuration Error 1917
102 SSH2.0 CONFIGURATION

SSH2.0 Overview 1919
Algorithm and Key 1919
Asymmetric Key Algorithm 1920
SSH Operating Process 1920
Configuring the Device as an SSH Server 1922
SSH Server Configuration Task List 1922
Enabling SSH Server 1923
Configuring the User Interfaces for SSH Clients 1923
Configuring RSA and DSA Keys 1924
Configuring a Client Public Key 1925
Configuring an SSH User 1926
Setting the SSH Management Parameters 1927
Configuring the Device as an SSH Client 1928
SSH Client Configuration Tasks 1928
Specifying a Source IP address/Interface for the SSH client 1928
Configuring Whether First-time Authentication is Supported 1928
Establishing a Connection Between the SSH Client and the Server 1929
Displaying and Maintaining the SSH Protocol 1930
SSH Server Configuration Example 1931
When Using Password Authentication 1931
When Using Publickey Authentication 1934
SSH Client Configuration Example 1940
When Using Password Authentication 1940
When Using Publickey Authentication 1942
103 SFTP SERVICE

SFTP Overview 1945
Configuring an SFTP Server 1945
Enabling the SFTP Server 1945
Configuring the SFTP Connection Idle Timeout Period 1946
Configuring an SFTP Client 1946
Specifying a Source IP Address or Interface for the SFTP Client 1946
Establishing a Connection to the SFTP Server 1946

Working with the SFTP Directories 1947
Working with SFTP Files 1948
Displaying Help Information 1949
Terminating the Connection to the Remote SFTP Server 1949
SFTP Configuration Example 1949
104 SSL CONFIGURATION

SSL Overview 1953
SSL Configuration Task List 1954
Configuring an SSL Server Policy 1954
Configuring an SSL Client Policy 1955
Displaying and Maintaining SSL 1955
Troubleshooting SSL 1956
SSL Handshake Failure 1956
105 GR OVERVIEW
Introduction to Graceful Restart 1957
Basic Concepts in Graceful Restart 1957
Graceful Restart communication procedure 1958
Graceful Restart Mechanism for Several Commonly Used Protocols 1960
106 BACKUP CENTER CONFIGURATION

Introduction to the Backup Center 1961
Basic Concepts of the Backup Center 1961
How the Backup Center Works 1962
Introduction to Backup Center Settings 1963
Configuring Interface Backup 1963
Configuring Main/backup Mode 1963
Associating an Interface with a Track Object 1964
Configuring Load Sharing 1965
Displaying and Maintaining the Backup Center 1965
Backup Center Configuration Example 1966
Multi-Interface Backup Configuration Example 1966
Multi-interface Load Sharing Configuration Example 1967
107 VRRP CONFIGURATION

Introduction to VRRP 1971
VRRP Overview 1971
VRRP Standby Group Overview 1972
VRRP Timers 1974
Format of VRRP Packets 1975
Principles of VRRP 1976
VRRP Tracking 1977
VRRP Application (Taking IPv4-Based VRRP for Example) 1977
Configuring VRRP for IPv4 1979

VRRP for IPv4 Configuration Task List 1979
Enabling Users to Ping Virtual IP Addresses 1980
Configuring the Association Between Virtual IP Address and MAC Address 1980
Creating Standby Group and Configuring Virtual IP Address 1981
Configuring Router Priority, Preemption Mode and Tracking Function 1982
Configuring VRRP Packet Attributes 1983
Displaying and Maintaining VRRP for IPv4 1983
Configuring VRRP for IPv6 1984
VRRP for IPv6 Configuration Task List 1984
Enabling Users to Ping Virtual IPv6 Addresses 1984
Configuring the Association Between Virtual IPv6 Address and MAC
Address 1984
Creating Standby Group and Configuring Virtual IPv6 Address 1985
Configuring Router Priority, Preemption Mode and Interface Tracking 1986
Configuring VRRP Packet Attributes 1986
Displaying and Maintaining VRRP for IPv6 1987
IPv4-Based VRRP Configuration Example 1987
Single VRRP Standby Group Configuration Example 1987
VRRP Interface Tracking Configuration Example 1990
Multiple VRRP Standby Groups Configuration Example 1993
IPv6-Based VRRP Configuration Example 1995
Single VRRP Standby Group Configuration Example 1995
VRRP Interface Tracking Configuration Example 1998
Multiple VRRP Standby Group Configuration Example 2001
Troubleshooting VRRP 2003
108 DEVICE MANAGEMENT

Device Management Overview 2005
Configuring Device Management 2006
Registering the Software 2006
Rebooting a Device 2006
Specifying a Boot ROM File for the Next Device Boot 2007
Upgrading Boot ROM 2007
Hot Swapping of a Card 2008
Configuring Temperature Alarm for a Card 2008
Configuring Alarm Buzzer 2009
Configuring Temperature Alarm Thresholds for a Card 2009
Clearing the 16-bit Interface Indexes Not Used in the Current System 2009
Displaying and Maintaining Device Management Configuration 2010
Device Management Configuration Example 2010
Remote Upgrade Configuration Example 2010
109 NQA OVERVIEW

Introduction to NQA 2013
Features of NQA 2013
Basic Concepts of NQA 2015
NQA Test Operation 2016
NQA Configuration Task List 2016
Configuring the NQA Server 2016

Enabling the NQA Client 2017
Creating an NQA Test Group 2017
Configuring an NQA Test Group 2017
Configuring the ICMP-echo Test 2017
Configuring the DHCP Test 2019
Configuring the FTP Test 2019
Configuring the HTTP Test 2020
Configuring the UDP-jitter Test 2021
Configuring the SNMP Test 2023
Configuring the TCP Test 2024
Configuring the UDP-echo Test 2025
Configuring the DLSw Test 2026
Configuring the Collaboration Function 2027
Configuring Trap Delivery 2027
Configuring Optional Parameters Common to an NQA Test Group 2028
Scheduling an NQA Test Group 2029
Displaying and Maintaining NQA 2030
NQA Configuration Examples 2030
ICMP-echo Test Configuration Example 2030
DHCP Test Configuration Example 2031
FTP Test Configuration Example 2031
HTTP Test Configuration Example 2032
UDP-jitter Test Configuration Example 2033
SNMP Test Configuration Example 2035
TCP Test Configuration Example 2036
UDP-echo Test Configuration Example 2037
DLSw Test Configuration Example 2038
110 NETSTREAM CONFIGURATION

NetStream Overview 2039
Introduction to NetStream 2039
Introduction to NetStream Aggregation 2040
Implementation of NetStream 2040
NetStream Configuration Task List 2041
Configuring NetStream Statistics 2041
Configuring NetStream Statistics 2041
Configuring NetStream Aggregation Statistics 2041
Configuring NetStream Aggregation Statistics 2041
Configuring Attributes of NetStream UDP Packets 2042
Configuring Attributes of NetStream UDP Packets 2042
Configuring NetStream Statistics Aging 2043
Introduction to NetStream Statistics Aging 2043
Configuring NetStream Statistics Aging 2043
Displaying and Maintaining NetStream 2043
NetStream Configuration Example 2044
Configuring NetStream 2044
Setting to Export Version 5 and Version 8 Packets 2045

111 NTP CONFIGURATION
NTP Overview 2049
Applications of NTP 2049
How NTP Works 2050
NTP Message Format 2051
Operation Modes of NTP 2053
Multiple Instances of NTP 2055
Configuring the Operation Modes of NTP 2055
Configuring NTP Server/Client Mode 2056
Configuring the NTP Symmetric Mode 2056
Configuring NTP Broadcast Mode 2057
Configuring NTP Multicast Mode 2058
Configuring the Local Clock as a Reference Source 2058
Configuring Optional Parameters of NTP 2059
Configuring the Interface to Send NTP Messages 2059
Disabling an Interface from Receiving NTP Messages 2059
Configuring the Allowable Maximum Number of Dynamic Sessions 2059
Configuring Access-Control Rights 2059
Configuring NTP Authentication 2060
Displaying and Maintaining NTP 2062
NTP Configuration Examples 2062
Configuring NTP Server/Client Mode 2062
Configuring the NTP Symmetric Mode 2064
Configuring NTP Broadcast Mode 2065
Configuring NTP Multicast Mode 2067
Configuring NTP Server/Client Mode with Authentication 2070
Configuring NTP Broadcast Mode with Authentication 2071
Configuring MPLS VPN Time Synchronization in Server/Client Mode 2073
Configuring MPLS VPN Time Synchronization in Symmetric Peers Mode 2075
112 RMON CONFIGURATION

RMON Overview 2077
Introduction 2077
How RMON Works 2077
RMON Groups 2078
Configuring RMON 2079
Displaying and Maintaining RMON 2081
RMON Configuration Example 2081
113 SNMP CONFIGURATION

SNMP Overview 2085
SNMP Mechanism 2085
SNMP Protocol Version 2086

MIB Overview 2086
SNMP Configuration 2086
Trap Configuration 2088
Displaying and Maintaining SNMP 2090
SNMP Configuration Example 2090
Configuration Example for SNMP Logging 2091
114 FILE SYSTEM MANAGEMENT CONFIGURATION

File System Management 2095
File System Overview 2095
Directory Operations 2095
File Operations 2096
Storage Device Operations 2097
File System Prompt Mode Setting 2098
File System Operations Example 2098
Configuration File Management 2099
Configuration File Overview 2099
Saving the Current Configuration 2100
Erasing the Startup Configuration File 2102
Specifying a Configuration File for Next Startup 2102
Backing up/Restoring the Configuration File for Next Startup 2103
Displaying and Maintaining Device Configuration 2104
115 FTP CONFIGURATION

FTP Overview 2105
Introduction to FTP 2105
Implementation of FTP 2105
Configuring the FTP Client 2106
Establishing an FTP Connection 2106
Configuring the FTP Client 2107
FTP Client Configuration Example 2108
Configuring the FTP Server 2110
Configuring FTP Server Operating Parameters 2110
Configuring Authentication and Authorization for Accessing FTP Server 2110
FTP Server Configuration Example 2111
Displaying and maintaining FTP 2112
116 TFTP CONFIGURATION

TFTP Overview 2115
Introduction to TFTP 2115
Implementation of TFTP 2115
Configuring the TFTP Client 2116
Displaying and Maintaining the TFTP Client 2117
TFTP Client Configuration Example 2117

117 SYSTEM MAINTAINING AND DEBUGGING
System Maintaining and Debugging Overview 2119
Introduction to System Maintaining and Debugging 2119
Introduction to System Debugging 2120
System Maintaining and Debugging 2121
System Maintaining 2121
System Debugging 2122
System Maintaining Example 2122
118 BASIC CONFIGURATIONS

Basic Configurations 2125
Entering/Exiting System View 2125
Configuring the Device Name 2125
Configuring the System Clock 2125
Configuring a Banner 2129
Configuring CLI Hotkeys 2130
Configuring User Levels and Command Levels 2131
Configuring Number of Concurrent Users 2132
Displaying and Maintaining Basic Configurations 2132
CLI Features 2133
Introduction to CLI 2133
Online Help with Command Lines 2133
Display Features 2135
History Command 2135
Command Line Error Information 2135
Edit Features 2136
119 INFORMATION CENTER CONFIGURATION

Information Center Overview 2137
Introduction to Information Center 2137
System Information Format 2141
Configuring Information Center 2142
Information Center Configuration Task List 2142
Setting to Output System Information to the Console 2142
Setting to Output System Information to a Monitor Terminal 2144
Setting to Output System Information to a Log Host 2145
Setting to Output System Information to the Trap Buffer 2145
Setting to Output System Information to the Log Buffer 2146
Configuring to Output System Information to the SNMP NMS 2146
Setting to Save System Information to a Log File 2147
Configuring Synchronous Information Output 2148
Displaying and Maintaining Information Center 2148
Information Center Configuration Example 2149
Outputting Log Information to a Unix Log Host 2149
Outputting Log Information to a Linux Log Host 2150
Outputting Log Information to the Console 2152

120 USER INTERFACE CONFIGURATION
User Interface Overview 2155
Brief Introduction 2155
Numbering User Interfaces 2156
User Interface Configuration Task List 2156
Configuring Asynchronous Serial Interface Attributes 2157
Configuring Terminal Attributes 2157
Configuring Modem Attributes 2158
Configuring the auto-execute Command 2159
Configuring User Privilege Level 2159
Configuring Access Restriction on VTY User Interface(s) 2160
Configuring Supported Protocols on VTY User Interface(s) 2160
Configuring Redirection Function on Asynchronous Serial Interface(s) 2161
Configuring Authentication Mode at Login 2162
Defining Shortcut Keys for Starting Terminal Sessions/Aborting Tasks 2164
Sending Messages to the Specified User Interface(s) 2164
Releasing the Connection Established on the User Interface(s) 2164
Displaying and Maintaining User Interface(s) 2164
121 MAC ADDRESS TABLE MANAGEMENT CONFIGURATION

Introduction to MAC Address Table 2165
Configuring MAC Address Table Management 2166
Configuring MAC Address Entries 2166
Disabling Global MAC Address Learning 2166
Disabling MAC Address Learning on an Ethernet Port or Aggregation Port
Group 2167
Configuring MAC Address Aging Timer 2167
Configuring Maximum Number of MAC Addresses an Ethernet Port or
Aggregation Port Group Can Learn 2168
Displaying and Maintaining MAC Address Table Management 2168
MAC Address Table Management Configuration Example 2169
122 AUTOMATIC CONFIGURATION

Introduction to Automatic Configuration 2171
How Automatic Configuration Works 2171
123 POE CONFIGURATION

PoE Overview 2175
Introduction to PoE 2175
Protocol Specification 2176
PoE Configuration Task List 2176
Configuring the PSE 2176
Configuring the PoE Interface 2177
Configuring a PoE Interface through the Command Line 2177
Configuring PoE Interfaces Through a PoE Configuration File 2178
Configuring PoE Power Management 2179
Configuring PSE Power Management 2179
Configuring PD Power Management 2180
Configuring the PoE Monitoring Function 2181
Configuring a Power Alarm Threshold for the PSE 2181

Upgrading PSE Processing Software Online 2181
Configuring a PD Disconnection Detection Mode 2182
Enabling the PSE to Detect Nonstandard PDs 2182
Displaying and Maintaining PoE 2183
PoE Configuration Example 2183
Troubleshooting PoE 2185
124 OAP MODULE CONFIGURATION

OAP Module Overview 2187
Switch of the Interface on an OAP Module 2187
Resetting an OAP Module 2188
125 ACFP CONFIGURATION

Introduction to ACFP 2189
ACFP Architecture 2189
ACFP Cooperation 2190
ACFP Management 2190
ACFP Information Overview 2191
Using ACFP 2194
Configuring ACFP 2194
Displaying and Maintaining ACFP 2195
ACFP Configuration Example 2195
Network Requirements 2195
Network Diagram 2196
126 ACSEI CONFIGURATION

Introduction to ACSEI 2199
Basic Concepts in ACSEI 2199
ACSEI Timers 2200
ACSEI Startup and Running 2200
ACSEI Server Configuration 2200
Enabling ACSEI Server 2200
Configuring the Clock Synchronization Timer 2201
Configuring the Monitoring Timer 2201
Close ACSEI Client 2201
Restart ACSEI client 2201
Displaying and Maintaining ACSEI Server 2201
ACSEI client Configuration 2201
Installing ACSEI Client 2202
Configuring the Default Startup Settings for ACSEI Client 2202
Controlling ACSEI Client 2204
Displaying and Maintaining ACSEI Client 2205
127 TRACK CONFIGURATION

Track Overview 2207
Collaboration between the Track Module and the Detection Modules 2207
Collaboration between the Track Module and the Application Modules 2207
Configuring Track-NQA Collaboration 2208

Configuring Collaboration Between the Track Module and Application
Modules 2208
Configuring Track-VRRP Collaboration 2208
Configuring Track-Static Routing Collaboration 2209
Configuring Track-Policy Routing Collaboration 2210
Configure Track-Backup Center Collaboration 2211
Displaying and Maintaining Track Object(s) 2211
Track Configuration Example 2212
VRRP-Track-NQA Collaboration Configuration Example 2212
128 IPX CONFIGURATION

IPX Protocol Overview 2217
IPX Address Structure 2217
IPX RIP 2217
IPX SAP 2218
IPX NetBIOS 2218
Protocol and Standards 2219
Configuring IPX Basic Functions 2219
Configuring IPX Routing 2219
Configuration Prerequisite 2219
Configuring an IPX Static Route 2220
Configuring IPX Route Number Limitation 2220
Enabling IPX RIP to Redistribute Static Routes 2220
Configuring IPX RIP Parameters 2221
Configuring IPX SAP 2221
Enabling IPX SAP 2221
Configuring IPX SAP Timers 2222
Configuring a Response Mode for IPX SAP GNS Request 2222
Configuring IPX Service Information 2223
Configuring the IPX Forwarding Feature 2224
Configuring IPX Forwarding Feature 2224
Pinging an IPX Network 2225
Displaying and Maintaining IPX Configuration 2225
IPX Configuration Example 2225
Troubleshooting IPX Configuration 2227
129 VOICE OVERVIEW

Introduction to VoIP 2233
VoIP System 2233
Basic VoIP Call Flow 2233
VoIP Features 2234
Voice Function Configuration 2235
Voice Subscriber Line 2237
Voice Entity 2237

Voice Protocols 2238
Dial Plan 2239
Command View 2240
130 VOIP OVERVIEW

Introduction to VoIP 2243
131 VOICE SUBSCRIBER LINE CONFIGURATION

Signal Tone 2245
FXS Voice Subscriber Line 2246
FXS Interface 2246
CID 2246
FXO Voice Subscriber Line 2246
FXO Interface 2246
CID 2246
Busy Tone Detection 2247
E&M Voice Subscriber Line 2248
E&M Interface 2248
Start Mode 2248
Configuring Call Progress Tones 2250
Specifying the Call Progress Tones of a Country 2250
Customizing Call Progress Tones for a Country 2250
Configuring Basic Functions 2251
Configuring FXS Voice Subscriber Line 2251
Configuring CID 2251
Configuring Packet Loss Compensation Mode 2252
Configuring FXO Voice Subscriber Line 2252
Enabling Calling Number Receiving and Sending 2252
Configuring Busy Tone Detection 2253
Configuring the Off-Hook Mode 2255
Configuring Other Functions 2256
Binding One FXS Interface to One FXO Interface 2256
Configuring E&M Voice Subscriber Line 2257
Configuring Cable Type 2257
Configuring Signal Type 2257
Configuring Start Mode 2258
Configuring Output Gain of SLIC Chip 2259
Configuring DTMF 2259
Introduction to DTMF 2259
Configuring DTMF Properties 2260

Configuring DTMF Detection 2260
Configuring Options Related to Dial Plan 2261
Configuring Adjustment Functions 2261
Configuring Echo Adjustment Function 2262
Configuring Gain Adjustment Function 2263
Configuring Time Adjustment Function 2263
Configuring Comfort Noise Function 2264
132 VOICE ENTITY CONFIGURATION

Introduction to Voice Entities 2265
Configuring POTS Entity 2266
Creating POTS Entity 2266
Configuring Local POTS Entity to Play Ringback Tones 2268
Configuring DTMF Transmission 2269
Enabling VAD 2269
Configuring VoIP Entity 2271
Creating VoIP Entity 2271
Configuring Fast Connection and Tunneling 2272
Configuring DTMF Transmission in Fast Connection Mode 2274
Configuring Out-of-Band DTMF Transmission with Tunneling Enabled 2274
Configuring VAD 2274
Configuring Voice Performance 2275
Resetting a Voice Card 2276
Configuring Global Default Voice Parameters 2276
Displaying and Maintaining VoIP Configuration 2278
VoIP Configuration Example 2279
FXS Interface 2279
FXO Interface 2280
One-to-One Binding between FXS and FXO 2282
Fast Connection 2284
Troubleshooting VoIP Configuration 2285
Busy Tone Given Immediately after Number Dialed 2285
Failed to Hang Up 2286
133 DIAL PLAN CONFIGURATION

Dial Plan Overview 2289

Dial Plan Process 2289
Regular Expression 2291
Introduction to Number Substitution 2292
Configuring a Calling Number Permitted to Call In 2293
Enabling Private Line Auto Ring-Down 2294
Configuring a Number Match Mode 2294
Configuring a Global Number Match Mode 2294
Configuring a Dial Terminator 2295
Configuring Voice Entity Selection Priority Rules 2295
Configuring a Number Priority Peer 2296
Configuring a Maximum-Call-Connection Set 2297
Configuring Number Substitution 2298
Configuring Global Number Substitution 2298
Configuring Number Substitution for A Voice Entity 2299
Configuring Number Substitution for A Voice Subscriber Line 2300
Configuring Number Sending Mode 2300
Configuring a Dial Prefix 2301
Displaying and Maintaining Dial Plan Configuration 2301
Dial Plan Configuration Examples 2301
Configuring Number Substitution 2301
Configuring the Match Order for Voice Entity Selection 2304
Configuring the Maximum-Call-Connection Set 2306
134 E1 AND T1 CONFIGURATION

Introduction to E1 and T1 2309
Overview 2309
E1/T1 Voice Functions 2309
E1/T1 Interface 2310
Features of E1/T1 2311
E1 and T1 Configuration Task List 2312
Configuring Basic Parameters for E1 Voice Interfaces 2313
Configuring a TDM Clock Source 2313
Configuring the Framing Format and Line Coding Format 2314
Creating a TS Set 2314
Configuring Basic Parameters for T1 Voice Interface 2315
Configuring a TDM Clock Source 2315
Configuring the Framing Format and Line Coding Format 2315

Creating a TS Set 2315
Configuring the Voice Subscriber Line for a TS Set 2316
Configuring Basic Functions for the Voice Subscriber Line 2316
Configuring the DTMF Detection Sensitivity 2316
Configuring the Volume Adjustment Function 2317
Configuring the Echo Adjustment Function 2317
Configuring the Comfortable Noise Function 2318
Binding Logical Voice Subscriber Line to POTS Entity 2319
Configuring R2 Signaling 2319
Introduction to R2 Signaling 2319
Configuring Basic R2 Signaling Parameters 2325
Configuring R2 Digital Line Signaling 2328
Configuring R2 Interregister Signaling 2329
Configuring DSS1 and Q.SIG Signaling 2330
Configuring Digital E&M Signaling 2331
Configuring a Start Mode 2331
Configuring Receive and Transit Signaling 2332
Configuring the Time Adjustment Function 2333
Querying the Trunk Circuits of a Timeslot or a Range of Timeslots 2334
Configuring Digital LGS Signaling 2334
Configuring the Time Adjustment Function 2334
Querying the Trunk Circuits of a Timeslot or a Range of Timeslots 2334
Displaying and Maintaining E1 and T1 Voice Configuration 2335
E1/T1 Voice Configuration Example 2335
E1 R2 Signaling and Digital E&M Signaling Configuration Example 2335
E1 Voice DSS1 Signaling Configuration Example 2338
Troubleshooting 2341
Failure of Call Connection from Router to PSTN 2341
135 FAX OVER IP CONFIGURATION

FoIP Overview 2343
Introduction to FoIP 2343
Protocol Criteria for FoIP 2344
Fax Flow 2344
FoIP Configuration 2344
Enabling ECM for Fax 2345
Configuring Fax Capability Transmission Mode 2346
Configuring Maximum Fax Rate 2346
Configuring Fax Training Mode 2347
Configuring a Fax Local Training Threshold 2348
Configuring Transmit Energy Level of Gateway Carrier 2348
Configuring Fax Interworking Protocol 2349
Configuring T.38 Capability Description Compatibility 2350
Configuring Default Values of Fax Parameters Globally 2351
Displaying and Maintaining FoIP Configuration 2352
FoIP Configuration Example 2352

136 H.323 CONFIGURATION
Introduction 2355
H.323 Architecture 2357
H.323 Fundamentals 2358
Gatekeeper Discovery 2358
Registration 2358
Address Translation 2358
Admission Control 2358
Call Setup 2359
Call Proceeding 2359
Alerting 2359
Connection 2359
Capability Negotiation 2359
Opening/Closing Logical Channel(s) 2360
Complete Release 2360
Disconnection 2360
H.323 Gateway Configuration 2360
Configuring Basic H.323 Gateway Functions 2360
Configuring Registration Password 2361
Configuring Security Calling 2362
Displaying and Maintaining the H.323 Gateway 2362
H.323 Gateway Configuration Example 2363
137 SIP OVERVIEW

Introduction to SIP 2367
Terms 2368
Functionality and Features of SIP 2369
SIP Messages 2370
SIP Fundamentals 2370
SIP Configuration Task List 2373
SIP UA Configuration 2373
Configuring SIP Authentication Information 2374
Configuring Registrar Information on SIP UA 2375
Configuring Proxy Server Information on SIP UA 2375
Configuring Fuzzy Telephone Number Registration 2376
Configuring SIP Routing for a Voice Entity 2376
Configuring Out-of-Band SIP DTMF Code Transmission Mode 2377
Configuring a Source IP Address 2377
Configuring a Domain Name for the SIP UA 2377
Configuring SIP Compatibility 2378
Configuring User-Agent Header and Server Header Fields 2378
Displaying and Maintaining SIP UAs 2379
SIP UA Configuration Examples 2379
Configuring Direct Calling for SIP UAs 2379
Configuring Proxy Server Involved Calling for SIP UAs 2380
Failed to Set Up Calls in the Proxy Server Approach to SIP Routing 2382
Failed to Register with the Registrar 2382

Failed to Set Up Point-to-Point Calls 2383
Failed to Send REGISTER Requests 2383
138 VOFR CONFIGURATION

Overview 2385
Fundamental VoFR Architecture 2385
Call Flow in Dynamic Mode 2386
Call Flow in FRF.11 Trunk Mode 2386
Configuration Task Lists 2387
Configuring VoFR Entity 2387
Creating VoFR Entity 2387
Enabling VAD 2389
Configuring VoFR Voice Bandwidth 2389
Configuring Dynamic Mode 2391
Configuring Huawei-Compatible Mode 2391
Configuring Nonstandard-Compatible Mode 2392
Configuring FRF.11 Trunk Mode 2393
Configuring Call Mode 2393
Configuring PSTN-Dialed Number 2394
Configuring Call Control Protocol 2394
Configuring Trunk Timer Length in FRF.11 Trunk Mode 2395
Configuring VoFR Packets to Carry Sequence Number 2395
Displaying and Maintaining VoFR 2395
VoFR Configuration Example 2395
Huawei-Compatible VoFR 2395
Nonstandard-Compatible VoFR 2397
FRF.11 Trunk 2399
Concurrent Transmission of Voice and Data 2401
Troubleshooting VoFR 2404
Call Failure in Huawei-Compatible Mode 2404
Poor VoFR Quality 2404
139 VOICE RADIUS CONFIGURATION

Overview 2405
Fundamentals 2405
RADIUS Provided by Voice Gateway 2407
Voice RADIUS Configuration Task List 2409
Configuring Voice RADIUS 2411
Configuring Accounting Method 2411
Enabling the Accounting Function for One-Stage Dialing Users 2411
Enabling Authentication Function for One-Stage Dialing Users 2412
Enabling Authorization Function for One-Stage Dialing Users 2412
Configuring Rule for Saving CDRs 2413
Configuring Access Number 2414
Configuring Two-Stage Dialing Process 2414

Enabling Accounting Function for Two-Stage Dialing Users 2415
Enabling Authentication Function for Two-Stage Dialing Users 2415
Enabling Authorization Function for Two-Stage Dialing Users 2416
Configuring Method of Collecting Digits of Called Number 2417
Configuring Number of Digits in Card Number/Password 2417
Configuring Number of Redial Attempts 2418
Enabling Language Selection Function 2419
Displaying and Maintaining Voice RADIUS 2420
Voice RADIUS Configuration Example 2420
Card Number/Password Process Configuration 2420
Troubleshooting Voice RADIUS 2423
140 CALL SERVICES CONFIGURATION

Introduction to Call Services 2425
Call Waiting 2425
Call Hold 2425
Call Forwarding 2425
Call Transfer 2426
Call Backup 2426
Hunt Group 2426
Call Barring 2426
Support for FEATURE Service of 3Com Voice System 2426
Call Services Configuration Task List 2427
Configuring Call Waiting 2427
Enabling/Disabling Call Waiting Using Keys 2427
Configuring Call Waiting Using Command Lines 2428
Configuring Call Hold 2429
Configuring Call Hold Using Command Lines 2429
Configuring Re_Invite Message Implementation Method 2429
Configuring Call Forwarding 2430
Enabling/Disabling Call Forwarding Using Keys 2430
Configuring Call Forwarding Using Command Lines 2430
Configuring Call Transfer 2433
Configuring Call Transfer Using Command Lines 2433
Configuring Hunt Group 2433
Enabling Hunt Group 2434
Configuring Hunt Group Priority Level 2434
Configuring Incoming Call Barring 2434

Enabling/Disabling Incoming Call Barring Using Keys 2435
Configuring Incoming Call Barring Using Command Lines 2435
Configuring Outgoing Call Barring 2435
Enabling/Disabling Outgoing Call Barring Using Keys 2436
Configuring Outgoing Call Barring Using Command Lines 2436
Configuring FEATURE Service 2436
Enabling/Disabling FEATURE Service Setting Using Keys 2437
Configuring FEATURE Service Using Command Lines 2438
Configuring a Number Priority Peer 2438
Call Services Configuration Example 2439
Call Forwarding Busy 2439
Call Transfer 2440
Hunt Group 2441

ABOUT THIS GUIDE
This manual describes how to operate your H3C MSR 20/30/50 Series router. It
includes the following sections about all of the major features of the routers.
This manual is intended for the following readers:
■ Network administrators
■ network engineers
■ Users who are familiar with the basics of networking
n Always download the Release Notes for your product from the 3Com World Wide
Web site and check for the latest updates to software and product
documentation: http://www.3Com.com
Conventions Table 1 lists icon conventions that are used throughout this guide.
Table 1 Notice Icons
Icon Notice Type Description
n Information note Information that describes important features or

instructions.
c Caution Information that alerts you to potential loss of data

or potential damage to an application, system, or
device.
w Warning Information that alerts you to potential personal

injury.
Table 2 lists text conventions that are used throughout this guide.
Table 2 Text Conventions
Convention Description
Screen displays This typeface represents information as it appears on the
screen.
Keyboard key names If you must press two or more keys simultaneously, the key
names are linked with a plus sign (+), for example:
Press Ctrl+Alt+Del
The words “enter” and “type” When you see the word “enter” in this guide, you must type
something, and then press Return or Enter. Do not press
Return or Enter when an instruction simply says “type.”

70 ABOUT THIS GUIDE
Table 2 Text Conventions
Convention Description
Words in italics Italics are used to:
Emphasize a point.
Denote a new term at the place where it is defined in the
text.
Identify menu names, menu commands, and software
button names.
Examples:
From the Help menu, select Contents.
Click OK.
Words in bold Boldface type is used to highlight command names. For
example, “Use the display user-interface command
to...”
Related The following manuals offer additional information necessary for managing your
Documentation MSR 20/30/50 Series router:
■ H3C MSR 20/30/50 Series Routers Installation Manuals — Covers setting up

and initializing your router.
■ H3C MSR 20/30/50 Series Routers Command Reference Guide — Provides a
detailed description of the operating commands. It includes sections about
getting started, system management, interface, link layer protocol, network
protocol, routing protocol, multicast protocol, security, VPN, reliability, QoS,
dial-up and VoIP, as well as a command index.
■ H3C MSR 20/30/50 Series Routers Interface Card and Interface Module Manual
— Covers the pinouts, function, interface attributes, panels, and LEDs of all
interface cards and modules available with the router.
■ LMR Series Routers Cable Manual — Describes the pinouts of the cables
available for LMR series routers.
■ Release Notes — Contains the latest information about your product. If
information in this guide differs from information in the release notes, use the
information in the Release Notes.
These documents are available in Adobe Acrobat Reader Portable Document

Format (PDF) on the CD-ROM that accompanies your router or on the 3Com
World Wide Web site: http://www.3Com.com

ATM AND DSL INTERFACE
1 CONFIGURATION
When configuring ATM/DSL interface, go to these sections for information you are
interested in:
■ “ATM and DSL Interface” on page 71
■ “IMA-E1/T1 Interface Configuration” on page 72
■ “ATM E3/T3 Interface Configuration” on page 76
■ “ATM OC-3c/STM-1 Interface Configuration” on page 76
■ “ADSL Interface Configuration” on page 77
■ “G.SHDSL Interface Configuration” on page 80
■ “Displaying and Maintaining ATM and DSL Interfaces” on page 81
■ “Troubleshooting” on page 81
ATM and DSL Interface This section covers these topics:

■ “ATM and DSL” on page 71
■ “ATM interfaces available for the low-end and mid-range routers” on page 72
■ “ATM interface features” on page 72
ATM and DSL

Asynchronous transfer mode (ATM) is a backbone network technology for
transmission of audio, video, and computer data. By virtue of its flexibility and
support to multimedia services, ATM is regarded as the core technology for
implementing broadband communications.
Digital subscriber line (DSL) is a technology providing high-speed data transmission

over the copper wire. It includes asymmetric digital subscriber line (ADSL),
high-bit-rate digital subscriber line (HDSL), very high rate digital subscriber line
(VDSL), single-pair high-speed DSL defined in ITU-T Standard G.991.2 (G.SHDSL),
and symmetric digital subscriber line (SDSL). These DSL technologies are different
in signal transmission speed and distance and uplink/downlink rate symmetric
mode (that is, whether uplink and downlink rates are the same).
The ATM physical layer lies at the bottom of the ATM reference model. Though it
is concerned with transmission media, its functionality does not rely on the
transmission mechanism and speed of specific medium. Rather, it primarily delivers
valid cells and the associated timing signals between the upper layer and
transmission medium. The speeds of physical access media are defined in
international standards such as ATM OC-3c/STM-1, ATM E3/T3, and IMA-E1/T1.
Most DSL applications are ATM-based, combining the advantages of ATM with the

72 CHAPTER 1: ATM AND DSL INTERFACE CONFIGURATION
low transmission cost feature of DSL. So far, DSL technologies have been widely
adopted for broadband accessing.
ATM interfaces available for the low-end and mid-range routers

So far, the low-end and mid-range routers can provide the following ATM
interfaces:
■ IMA-E1/T1
■ ATM E3/T3
■ ATM 25.6 Mbps
■ ATM OC-3c/STM-1 based on SONET/SDH
■ ATM ADSL based on the ADSL technology
■ ATM GSHDSL based on the GSHDSL technology
These interfaces support IPoA, IPoEoA, PPPoA, and PPPoEoA. For more
information about them, refer to “ATM Configuration” on page 127.
ATM interface features

The ATM interfaces support:
■ Nonreal-time variable bit rate (nrt_VBR)
■ Real-time variable bit rate (rt_VBR)
■ Constant bit rate (CBR)
■ Unspecified bit rate (UBR)
■ Permanent virtual circuit (PVC)
■ Per-VC traffic shaping
■ User-to-network Interface (UNI)
■ RFC1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5
■ RFC1577 Classical IP and ARP over ATM
■ F5 end to end loopback OAM
■ ATM adaptation layer 5 (AAL5)
IMA-E1/T1 Interface This section covers these topics:

Configuration ■ “Overview” on page 72
■ “Configuring an ATM E1/T1 Interface” on page 73
■ “Configuring an IMA Group” on page 73
■ “ATM IMA-E1/T1 Interface Configuration Example” on page 74
■ “Troubleshooting ATM IMA-E1/T1 Interfaces” on page 75
Overview Inverse multiplexing for ATM (IMA) technology distributes an ATM cell stream over
multiple low-speed links on a cell by cell basis and reassembles the cells into the
original stream at the far end. It is a cheap way for you to transmit high-speed
ATM cell streams over low-speed links while allowing for great flexibility.

The configuration of IMA-E1/T1 includes two parts: physical level parameters of

ATM E1/T1 interfaces and IMA features. If no IMA group is configured for
transmitting ATM cell streams, the cells are distributed directly over E1/T1 links.
You can, however, assign multiple IMA-E1/T1 interfaces to an IMA group to form a
higher-speed IMA interface link for ATM cell transmission.
For both IMA groups and the E1/T1 links outside the groups, you can create PVCs,
specify service types, and configure the related parameters. For more information
(including the configuration of PVCs), refer to “ATM Configuration” on page 127.
ATM E1/T1 interface configuration includes interface configuration and IMA group
configuration.
Configuring an ATM Follow these steps to configure parameters for an ATM E1/T1 interface:
E1/T1 Interface
To do... Use the command... Remarks
Enter system view system-view --
Enter ATM E1/T1 interface interface atm Required
view interface-number
Set the clock mode clock { master | slave } Optional
The default is slave.
Set the On an E1 frame-format { crc4-adm | Optional
framing interface no-crc4-adm }
The default is CRC4 ADM.
format
On a T1 frame-format { esf-adm | Optional
interface sf-adm }
The default is ESF ADM.
Set the line On an E1 code { ami | hdb3 } Optional
coding format interface
The default is HDB3.
On an T1 code { ami | b8zs } Optional
interface
The default is B8ZS.
Enable scrambling scramble Optional
Enabled by default.
Set the cable length cable { long | short } Optional
The default is long, allowing
automatic cable length
adaptation.
Set the loopback mode loopback { cell | local | Optional
payload | remote }
Disabled by default.
Configure an IMA group See Configuring IMA Groups Required
n E1 configurations are supported on the IMA (E1) interface module and T1

configurations on the IMA (T1) interface module.
The line coding formats for IMA-E1 interfaces and IMA-T1 interfaces are fixed to
high density bipolar of order 3 (HDB3) and bipolar with 8-zero substitution (B8ZS).
They are not configurable.
Configuring an IMA Follow these steps to configure an IMA group:

Group


Create an IMA group and ima ima-group Required
assign the interface to an group-number
This command adds the
existing IMA group
current interface to the IMA
group identified by the
group-number argument. If
the IMA group does not exist,
the command creates the
group first.
Return to system view quit -
Enter IMA group interface interface ima-group Required
view group-interfacenumber
Assign an IP address to the ip address ip-address Required
IMA group interface address-mask
Not assigned by default
Set the number of cells in an frame-length { 32 | 64 | 128 | Optional
IMA frame 256 }
The default is 128.
Set the clock mode for the ima-clock { ctc Optional
IMA group [ link-number number ] | itc }
The default is common
transmit clocking (CTC) mode.
Set the standard to be ima-standard Optional
adopted by the IMA group { alternate-v10 | normal |
The default is normal.
standard-v10 |
standard-v11 }
Set the minimum number of min-active-links number Optional
links required for the IMA
1 by default
group to work
Set the maximum link delay differential-delay Optional
between the member links in milliseconds
The default maximum link
the IMA group
delay between the member
links of an IMA group is 25
milliseconds.
Configure IMA group link test ima-test [ link-number Optional
number ] [ pattern-id id ]
If no E1/T1 link is specified,
the system sends the test
pattern over the first link in
the IMA group by default. If
no test pattern is specified,
0xAA applies by default.
By default, IMA group link
test is disabled.
ATM IMA-E1/T1 Network requirements

Interface Configuration As shown in Figure 1, on the IMA-8E1 interface module of the router, create two
Example IMA groups, each of which is assigned two links; create two PVCs, setting their
peer IP address to 10.10.10.10/24; and configure them to support pseudo
broadcast.

Network diagram
Figure 1 Network diagram for IMA-E1/T1 interface configuration
ATM IMA 1
10.110 .110 .1 /24
ĂĂ
ATM IMA 2
10.110 .120 .1 /24
Configuration procedure
# Assign two links to IMA group 1.
<Sysname> system-view
[Sysname] interface atm 5/0
[Sysname-Atm5/0] undo ip address
[Sysname-Atm5/0] ima ima-group 1
[Sysname-Atm5/0] interface atm 5/1
[Sysname-Atm5/1] quit
# Assign another two links to IMA group 2.
[Sysname] interface atm 5/2

[Sysname-Atm5/2] interface atm 5/3
[Sysname-Atm5/3] quit
# Create PVCs and assign IP addresses for the IMA groups.
[Sysname] interface ima-group 5/1

[Sysname-Ima-group5/1] ip address 10.110.110.1 255.255.255.0
[Sysname-Ima-group5/1] pvc aaa 1/42
[Sysname-atm-pvc-Ima-group5/1-1/42-aaa] map ip 10.10.10.10 broadcast
[Sysname-atm-pvc-Ima-group5/1-1/42-aaa] quit
[Sysname-atm-pvc-Ima-group5/1] quit
[Sysname] interface ima-group 5/2
[Sysname-Ima-group5/2] ip address 10.110.120.1 255.255.255.0
[Sysname-Ima-group5/2] pvc bbb 1/92
[Sysname-atm-pvc-Ima-group5/2-1/92-bbb] map ip 10.10.10.10 broadcast
Troubleshooting ATM You can start troubleshooting an ATM interface with testing network connectivity
IMA-E1/T1 Interfaces using the ping command or the extended ping command. In an extended ping
command, you can specify some options in IP header. For more information on the
use of the ping command, refer to “System Maintaining and Debugging” on page
2119.

If the interface cannot be pinged, check whether:
■ The interface is down.

■ The AAL5 encapsulation type of the PVC is incorrect.
ATM E3/T3 Interface This section covers these topics:

■ “Configuring an ATM E3/T3 Interface” on page 76
Overview This section covers only the physical configurations of the ATM E3/T3 interface. For
more information about how to configure ATM (including PVCs), refer to “ATM
Configuration” on page 127.
Configuring an ATM Follow these steps to configure an ATM E3/T3 interface:

E3/T3 Interface
Set the On an ATM E3 frame-format { g751-adm | Optional
framing interface g751-plcp | g832-adm }
The default is the G.751 PLCP
format
format.
On an ATM T3 frame-format { cbit-adm | Optional
interface cbit-plcp | m23-adm |
The default is the C-bit PLCP
m23-plcp }
format.
The default is short haul.
Configure scrambling scramble Optional
Enabled by default
The default is short haul.
payload | remote }
Disabled by default
n E3 configurations are supported on the ATM(E3) interface module and T3

configurations on the ATM(T3) interface module.
ATM OC-3c/STM-1 This section covers these topics:

Interface ■ “Overview” on page 72
Configuration
■ “Configuring an ATM OC-3c/STM-1 Interface” on page 77

Overview This section covers only the physical configurations of the interface. For more
information about how to configure ATM (including PVCs), refer to “ATM
Configuring an ATM Follow these steps to configure an ATM OC-3c/STM-1 interface:

OC-3c/STM-1 Interface
Enter ATM OC-3c/STM-1 interface atm Required
interface view interface-number
Set the framing format frame-format { sdh | sonet } Optional
The default is the SDH STM-1
format.
Enable scrambling scramble Optional
Enabled by default
remote }
Disabled by default
ADSL Interface This section covers these topics:

■ “Configuring an ADSL Interface” on page 79
■ “Upgrading ADSL2+ Card Software” on page 79
Overview ADSL Technologies

Asymmetric digital subscriber line (ADSL) is an asymmetric transmission
technology that implements high-speed data transmission over twisted-pair
copper wire by using unused high frequency ranges in the regular telephone line
with different modulation method. Normally, in the uplink band of 26 kHz to 138
kHz, ADSL can provide transmission rates up to 640 kbps (uplink) and in the
downlink band of 138 kHz to 1.104 MHz, it provides transmission rates up to 8
Mbps (downlink).
Some latest ADSL technologies, however, can provide faster transmission rates by
improving modulation rate, coding gain, initialization state machine, by reducing
frame head overhead, and by using enhanced signal processing methods. For
example, given the same bands, ADSL2 can provide uplink transmission rates up
to 1024 kbps and downlink transmission rates up to 12 Mbps. By expanding the
downlink band from 1.104 MHz to 2.208 MHz, ADSL2+ can even provide a
downlink rate as fast as 24 Mbps.
The transmission speed of ADSL is susceptible to transmission distance and line

quality. While increased transmission distance means decreased line quality and
transmission rate, decreased transmission distance means the contrary. When
setting up a link, ADSL can automatically make tuning for a reasonable speed
taking into consideration actual line conditions such as distance and noise.

Two types of ADSL modules/cards are available: ADSL over POTS and ADSL over
ISDN (ADSL-I).
Typical network topology for ADSL routers

The following figure shows a typical network topology for routers with ADSL
interfaces, where:
■ DSLAM at the central office (CO) end works as the central office equipment.
■ The router works as the customer premises equipment (CPE).
Figure 2 Typical network for an ADSL router
Splitter
Line ADSL ADSL Eth
DSLAM Phone
ADSL Router
Hub
Phone Server Host A Host B
Line activation and deactivation

Before transmitting services, the CPE must activate the line. This is done through
handshake training and information exchange between the CO equipment and
the CPE.
A typical activation process may last 30 seconds, beginning with line negotiation
until the line comes up. During this process, the two parties examine line distance
and conditions against the line configuration template (which defines the ADSL
criteria, channel mode, uplink and downlink speeds, and noise tolerance) and
attempts to reach an agreement. If the activation succeeds, a communication
connection is set up between the two parties. When negotiating connection
parameters during the line activation, the CO equipment plays a master role to
provide and decide values for most parameters, while the CPE a slave role to
accept them.
Contrary to activation, deactivation tears down the communication connection

between the two parties. The router tests the performance of the line regularly.
Once it finds out that the line performance is deteriorating, it automatically
deactivates, retrains, and reactivates the line.
n As ADSL transmission speed depends on distance and line quality heavily, make
sure regular twisted pairs are used and the cables are well connected when
connecting ADSL interfaces.
This section covers only the physical configurations of the ADSL interface. For

Configuring an ADSL
Interface To do... Use the command... Remarks
Enter ATM interface view interface atm Required
interface-number
Activate the ADSL interface clock { master | slave } Optional
The interface is active by
default.
Configure the ADSL interface adsl standard { auto | g9923 Optional
standard | g9925 | gdmt | glite |
The default is auto sensing.
t1413 }
Set the transmit power adsl tx-attenuation Optional
attenuation value attenuation
0 by default
n To have the adsl standard command take effect, you need to re-activate the
interface either by performing the shutdown and undo shutdown commands
or the activate and undo activate commands.
Upgrading ADSL2+ Card The upgradeable software includes Boot ROM and card software. You first need to
Software load the new software by FTP or some other means to the flash memory or the CF
card on your device. Before performing an upgrade, you need to shut down the
interface with the shutdown command if the interface is up. After completing
the upgrade, you need to bring the interface up with the undo shutdown
command.
Follow these steps to upgrade ADSL2+ card software:

Enter ATM interface interface atm Required
Shut down the interface shutdown Optional
Skip this step if the interface is already
down.
Quit to system view quit --
Quit to user view quit --
Upgrade software bootrom update file Required
file-url slot slot-no-list
Only distributed devices support the slot
[ subslot subslot-no-list ]
slot-no-list option.
[ all | part ]
The subslot subslot-no-list option is not
available if the device does not support
sub-card-level maintenance.
The highest slot number and the highest
sub-slot number varies with device
models.
Enter ATM interface interface atm --
Bring the interface up undo shutdown Required

n When executing the bootrom update file command, do not use the all option
unless absolutely necessary; use the part option instead. If you use the all option,
you will find it hard to roll back to the old version once the upgrade fails.
G.SHDSL Interface This section covers these topics:

■ “Configuring a G.SHDSL Interface” on page 80
Overview G. single-pair high-speed digital subscriber line (G.SHDSL) is a symmetric

transmission technology that implements high-speed data transmission over the
twisted-pair copper wire by making use of the unused high frequency ranges with
different modulation methods. So far, two types of G.SHDSL are supported:
two-wire and four-wire. Two-wire G.SHDSL can provide transmission rates up to
2.312 Mbps while four-wire G.SHDSL can provide transmission rates up to 4.624
Mbps.
The transmission speed of G.SHDSL is susceptible to transmission distance and line

quality. While increased transmission distance means decreased line quality and
transmission rate, decreased transmission distance means the contrary. When
setting up a link, G. SHDSL can automatically make tuning for a reasonable speed
taking into consideration the actual line conditions such as distance and noise.
For the networking topology for the routers with G.SHDSL interfaces, refer to that
for the routers with ADSL interfaces. But note that G.SHDSL interface requires no
splitter.
For a typical network topology for routers with G.SHDSL interfaces, see Figure 2.
You should note that unlike ADSL, G.SHDSL does not use the splitter.
This section covers only the physical configurations of the G.SHDSL interface. For
Configuring a G.SHDSL Follow these steps to configure a G.SHDSL interface:

Interface
Enter ATM interface view interface atm Required
interface-number
Activate the G.SHDSL activate Optional
interface
The interface is active by default.
Set the G.SHDSL interface shdsl annex { a | b } Optional
standard
Annex B is adopted by default.
Set the wiring mode shdsl wire { 2 | Optional
4-auto-enhanced |
4-enhanced mode by default
4-enhanced | 4-standard }
This command is available only if
the interface supports four-wire
G.SHDSL.

Displaying and Maintaining ATM and DSL Interfaces 81

Set the interface operating shdsl mode { co | cpe } Optional
mode
CPE by default
Set the single-pair rate shdsl rate { auto | rate } Optional
The default is auto-negotiation
mode for the two-wire G.SHDSL
interface and 2.312 Mbps for the
single-pair interface rate of the
four-wire G.SHDSL interface
(four-wire G.SHDSL interface rate is
4.624 Mbps).
Set a target margin to the shdsl snr-margin [ current Optional
SNR current-margin-value ]
By default, current-margin-value is
[ snext
set to 2, and snext-margin-value is
snext-margin-value ]
set to 0.
Set the PSD mode shdsl psd { asymmetry | Optional
symmetry }
The default is symmetry.
Displaying and
Maintaining ATM and To do... Use the command... Remarks
DSL Interfaces Display the configuration and display interface atm Available in any view
state of a specified or all ATM or [ interface-number ]
DSL interfaces
Display the actual configuration display dsl configuration Available in any view
of a DSL line interface atm interface-number
Display the state information of display dsl status interface Available in any view
a DSL line atm interface-number
Display DSL version information display dsl version interface Available in any view
and available capabilities atm interface-number
Display the configuration and display interface ima-group Available in any view
state about a specified or all IMA [ group-interfacenumber ]
group interfaces
Display the detailed information display status interface ima Available in any view
about a specified IMA group group-number
interface
Clear the statistics about all reset atm interface [ atm Available in user view
PVCs on the specified ATM interface-number ]
interface
n For those physical interfaces that are not connected to cables, shut down them
using the shutdown command to avoid anomalies resulted from interference.
Troubleshooting This section covers these topics:

■ “Troubleshooting ATM Interfaces” on page 81
■ “Troubleshooting DSL Interfaces” on page 82
Troubleshooting ATM When diagnosing ATM interface problems, first test the interface with the ping
Interfaces command or the extended ping command.

The ping command can test network connectivity. Extended ping command can
be used to specify some options in the IP header in addition to that function. For
more information about the ping command, see “System Maintaining and
Debugging” on page 2119.
If the interface cannot be pinged, check whether:
■ The interface is down, which causes missing of its route in the routing table.
■ The AAL5 encapsulation of PVC is incorrect (for 155 Mbps ATM interface only).
Troubleshooting DSL Improper line operation is one of the faults that you may encounter in DSL
Interfaces applications. Such a fault is likely to occur on whichever devices or nodes in the
hierarchical broadband network architecture. It is probably caused by the CPE
device, copper wire, splitter, DSL port on DSLAM, or even the broadband access
server. For this reason, you should segment the network to locate the problem.
Generally, DSLAM provides you with abundant fault isolating methods and a
complete guide, which are however, beyond the scope of this manual.
On the CPE, you may do the following when problem occurs:
1 Read the LEDs for the DSL interface card
When the DSL line is training, the LINK LED blinks. After the activation succeeds,
the LINK LED which should otherwise be OFF lights and stays ON. The Activity LED
blinks when data being transmitted on the line.
2 Display the DSL state information with the display dsl status command
The State of driver/chipsets field provides the information about interfaces and
transceiver states.
Common interface states include Activating, Active, Startupping, Deactive, and

Test Mode.
Common transceiver states include Idle, Data Mode, HandShaking, and Training.
3 Perform the debugging physical command to view details about activation, such
as sending of the activate command, activation timeout, training process, and
activation success.
4 If line activation attempts always fail, check that the line is securely connected and
functioning normally.
5 If bit error rate is high or interference happens too often, reset the interface with
the shutdown/undo shutdown command or reboot the device and reconnect
the line. If the problem is still there, make an overall line condition and
environment check.

POS INTERFACE CONFIGURATION
2
When configuring POS interfaces, go to these sections for information you are
interested in:
■ “Overview” on page 83
■ “Configuring a POS Interface” on page 83
■ “Displaying and Maintaining POS Interfaces” on page 84
■ “POS Interface Configuration Example” on page 85
■ “Troubleshooting POS Interfaces” on page 87
Overview This section covers these topics:

■ “SONET/SDH” on page 83
■ “POS” on page 83
SONET/SDH Synchronous optical network (SONET), a synchronous transmission system defined

by ANSI, is an international standard transmission protocol. It adopts optical
transmission.
In SDH defined by CCIT (today’s ITU-T), adoption of synchronous multiplexing and

flexible mapping allows you to add/drop low-speed tributary signals from SDH
signal without large amount of multiplexing/demultiplexing devices. This reduces
signal attenuation and device investment.
POS Packet over SONET/SDH (POS) is a technology popular in WAN and MAN. It can
support packet data such as IP packets.
POS maps length-variable packets directly to SONET synchronous payloads and

uses the SONET physical layer transmission standard. It offers high-speed, reliable,
and point-to-point data connectivity.
The POS interface on your device supports PPP, Frame Relay, and HDLC at the data
link layer and IP at the network layer. Its transmission rate can vary with devices.
For example, in the sequence of STM-1 (155 Mbps), STM-4c (622 Mbps) and
STM-16c/STM-16 (2.5 Gbps), the rate of each level is four times that of the
immediate lower level.
Configuring a POS Before you configure the link layer and network layer protocols on a POS interface,
Interface you must configure its physical parameters. In addition, to have the interface
participate in backup, configure the backup parameters; to set up firewall on the
interface, configure packet filtering rules.

84 CHAPTER 2: POS INTERFACE CONFIGURATION
Follow these steps to configure a POS interface:

Enter POS interface interface pos Required
Set the CRC length crc { 16 | 32 } Optional
The default is 32 bits.
Set the loopback loopback { local | remote } Optional
mode
Disabled by default
Configure the flag { c2 | { j0 | j1 } { sdh | Optional
overhead byte sonet } } flag-value
By default, SDH framing applies.
The default is hexadecimal 16 for C2.
In SDH framing, the defaults are 15
0x0 for both J0 and J1.
In SONET framing, the defaults are
0x01 for J0 and 62 0x0 for J1.
Set the framing frame-format { sdh | sonet } Optional
format
The default is SDH.
Configure scramble Optional
scrambling
Enabled by default.
Set the link type link-protocol { ppp | fr Optional
[ nonstandard | ietf | mfr
The default is PPP.
interface-number ] | hdlc }
Set the interface mtu mtu Optional
MTU
MTU range and the default value vary
with device.
Set the SD/SF threshold { sd | sf } value Optional
threshold for the
If you execute this command with the
interface
value argument set to X, the value of
the threshold specified is 10e-X. SD
threshold defaults to 10e-6 (that is, X
is 6). The SF threshold defaults to
10e-3 (that is, X is 3).
Displaying and
Maintaining POS To do... Use the command... Remarks
Interfaces Display status and configuration display interface pos Available in any
information about one or all POS [ interface-number ] view
interfaces
Display IP-related configurations and display ip interface pos Available in any
statistics for one or all POS interfaces [ interface-number ] view
Display IPv6-related configurations display ipv6 interface pos Available in any
and statistics for one or all POS interface-number view
interfaces

POS Interface Configuration Example 85
n If a physical interface is idle or has no cable connection, shut down it with the
shutdown command to avoid interface anomalies that may result from
interference. As the command can disable the interface, use it with caution.
POS Interface
Configuration
Example
Directly Connecting Network requirements

Routers Through POS Use a pair of single mode optic fiber (respectively for receiving and sending data)
Interfaces to connect the POS interfaces on Router A and Router B.
Encapsulate the interfaces with PPP.
Network diagram
Figure 3 Network diagram for connecting two POS interfaces through fiber
POS 1/0 POS 1/0

10 .110.1.10 /24 10.110.1 .11 /24
Router A Router B
1 Configure Router A
# Configure interface POS 1/0, setting its physical parameters to defaults.
<RouterA> system-view
[RouterA] interface pos 1/0
[RouterA-Pos1/0] ip address 10.110.1.10 255.255.255.0
[RouterA-Pos1/0] link-protocol ppp
[RouterA-Pos1/0] mtu 1500
[RouterA-Pos1/0] shutdown
[RouterA-Pos1/0] undo shutdown
2 Configure Router B
# Configure interface POS 1/0.
<RouterB> system-view
[RouterB] interface pos 1/0
# Set the clock mode to master and other physical parameters to defaults.
[RouterB-Pos1/0] clock master

[RouterB-Pos1/0] ip address 10.110.1.11 255.255.255.0
[RouterB-Pos1/0] link-protocol ppp
[RouterB-Pos1/0] mtu 1500
[RouterB-Pos1/0] shutdown
[RouterB-Pos1/0] undo shutdown
You can check the interface connectivity between the POS interfaces with the
display interface pos command and test network connectivity with the ping
command.

Connecting Routers Network requirements

Through POS Interfaces Connect routers to a public Frame Relay network through POS interfaces. The
Across Frame Relay routers are premise equipment that work as DTE side of Frame Relay.
Router A uses Frame Relay sub-interfaces to connect Router B and Router C in

different network segments.
Network diagram
Figure 4 Network diagram for POS interface connection across Frame Relay
Router A Router B
POS 1/0.1 POS1 /0

10.10.10.1/24 10 .10 .10 .2/24
DLCI=50 DLCI=70
Router C
FR
POS 1/0.2
20 .10 .10 .1/24
POS1/0
DLCI=60
20 .10.10.2/24
DLCI=80
# Configure POS interface 1/0.
[RouterA] interface pos 1/0
[RouterA-Pos1/0] clock slave
# Configure Frame Relay encapsulation on the interface.
[RouterA-Pos1/0] link-protocol fr
[RouterA-Pos1/0] fr interface-type dte
[RouterA-Pos1/0] quit
# Create sub-interface 1 on the interface.
[RouterA] interface pos 1/0.1

[RouterA-Pos1/0.1] ip address 10.10.10.1 255.255.255.0
[RouterA-Pos1/0.1] fr map ip 10.10.10.2 50
[RouterA-Pos1/0.1] mtu 1500
[RouterA-Pos1/0.1] quit
# Create sub-interface 2 on the interface.
[RouterA] interface pos 1/0.2

[RouterA-Pos1/0.2] ip address 20.10.10.1 255.255.255.0
[RouterA-Pos1/0.2] fr map ip 20.10.10.2 60
[RouterA-Pos1/0.2] mtu 1500
[RouterA-Pos1/0.2] quit

Troubleshooting POS Interfaces 87
# Configure interface POS 1/0.

[RouterB-Pos1/0] clock slave
# Configure Frame Relay encapsulation on the interface.
[RouterB-Pos1/0] link-protocol fr
[RouterB-Pos1/0] fr interface-type dte
[RouterB-Pos1/0] ip address 10.10.10.2 255.255.255.0
[RouterB-Pos1/0] fr map ip 10.10.10.1 70
[RouterB-Pos1/0] mtu 1500
Follow the same way to configure Router C.
You can check interface connectivity with the display interface pos command
and test network connectivity with the ping command.
Troubleshooting POS Symptom 1:

Interfaces
The physical state of POS interface is down.
Solution:
■ Check that the transmitting and receiving fibers-optic are correctly connected
to the POS interface. If you connect the two ends of a fiber-optic to the
transmitting end and the receiving end of the same POS interface, you can see
the message “loopback detected” on the screen when executing the display
interface command even if you have not enabled loopback.
■ If the two devices are directly connected back to back, one end of the POS
interfaces must be configured to use the master clock and the other end slave
clock.
Symptom 2: The physical layer is up but the link is down.
Solution:
Check that:
■ The configurations of clock, scrambling and other physical interfaces are

consistent on the connected two POS interfaces.
■ The same link layer protocol is configured on two sides.
■ Both ends are assigned IP addresses.
Symptom 3:
A great amount of IP packets are dropped.
Solution:
Check that:

■ The correct clock mode is configured on the POS interface. If not, enormous
amount of CRC errors can be generated.
■ Check that the MTU configuration is appropriate.

ETHERNET INTERFACE CONFIGURATION
3
When configuring Ethernet interfaces, go to these sections for information you
are interested in:
■ “General Ethernet Interface Configuration” on page 89
■ “Configuring Layer 2 Ethernet Interfaces” on page 92
■ “Configuring Layer 3 Ethernet Interfaces” on page 96
■ “Maintaining and Displaying an Ethernet Interface” on page 97
General Ethernet This section describes the attributes and configurations common to layer 2
Interface Ethernet interfaces and layer 3 Ethernet interfaces. For specific attributes, refer to
Configuration related sections hereinafter.
Combo Port Introduction to Combo port

Configuration A Combo port refers to two Ethernet interfaces in a device panel (normally one is
an optical port and the other is an electrical port). Inside the device there is only
one forwarding interface. Combo port and its corresponding electrical port work
in a TX/SFP mode. Users can choose one to use depending on the actual network
requirements, but not two simultaneously. When one port is working, the other is
disabled, and vice versa.
The two Ethernet interfaces of a Combo port in the device panel correspond to
only one interface view, in which the two Ethernet interfaces can be switched. A
Combo port can be a Layer 2 Ethernet interface or a Layer 3 Ethernet interface.
Configuring Combo port state

Follow these steps to configure a single Combo port state:

Enter system view system-view -
Enter Ethernet interface view interface interface-type -
interface-number
Enable a Combo port combo enable { copper | Optional
fiber }
By default, the electrical port
is enabled.
Basic Ethernet Interface Three types of duplex modes available to Ethernet interfaces:
Configuration ■ Full-duplex mode (full): in this mode, the sending and receiving of data packets
happen simultaneously;

90 CHAPTER 3: ETHERNET INTERFACE CONFIGURATION
■ Half-duplex mode (half): in this mode, at a particular time, either the sending
or receiving of data packets is allowed, but not both;
■ Auto-negotiation mode (auto): in this mode, the transmission mode is
negotiated between peer Ethernet interfaces.
If you configure the transmission rate for an Ethernet interface to be auto, then
the rate will be automatically negotiated between peer Ethernet interfaces.
Follow these steps to make basic Ethernet interface configurations:

interface-number
Configure the description for description text Optional
an Ethernet interface
By default, the descriptive
string is the current interface
name followed by
“interface”.
Configure the duplex mode duplex { auto | full | half } Optional
for an Ethernet interface
auto by default.
Configure the transmission speed { 10 | 100 | 1000 | Optional
rate for an Ethernet interface auto }
auto by default.
Shut down the Ethernet shutdown Optional
interface
By default, an Ethernet
interface is up. Use the undo
shutdown command to
bring up an Ethernet
interface.
n ■
■
The optical port does not support the speed command.
The speed 1000 command is only applicable in GigabitEthernet interface view.
Configuring Flow When flow control is turned on between peer Ethernet interfaces, if traffic
Control on an Ethernet congestion occurs at the ingress interface, it will send a Pause frame notifying the
Interface egress interface to temporarily suspend the sending of packets. The egress
interface is expected to stop sending any new packets when it receives the Pause
frame. In this way, flow controls helps to avoid the dropping of packets. Note that
only after both the ingress and the egress interfaces have turned on their flow
control will this be possible.
Follow these steps to configure flow control on an Ethernet interface:

interface-number
Turn on flow control on an flow-control Required
Ethernet interface
Turned off by default

General Ethernet Interface Configuration 91
Configuring Loopback You can enable loopback test to check whether the Ethernet interface functions
Test on a Layer 2 properly. Note that no data packets can be forwarded during the test. Loopback
Ethernet Interface test falls into the following two categories:
■ Internal loopback test, which is performed within switching chips to test the
functions related to the Ethernet interfaces.
■ External loopback test, which is used to test the hardware functions of an
Ethernet interface. To perform external loopback test on an Ethernet port, you
need to install a loopback plug on the Ethernet interface. In this case, packets
sent from the interface are received by the same interface.
Follow the following steps to configure Layer 2 Ethernet interface loopback test:

interface-number
Enable loopback test loopback { external | Optional
internal }
n ■ As for the internal loopback test and external loopback test, if a Layer 2
interface is down, only the former is available on it; if the interface is shut
down, both are unavailable.
■ The speed, duplex, mdi, and shutdown commands are not applicable during
a loopback test.
■ With the loopback test enabled, the Ethernet interface works in the full duplex
mode. With the loopback testing enabled, the original configurations will be
restored.
Configuring Loopback You can enable loopback on a Layer 3 Ethernet interface to check whether the
on a Layer 3 Ethernet Ethernet interface functions properly. Note that interfaces with loopback enabled
Interface cannot forward packets properly. Loopback on Layer 3 Ethernet interfaces falls
into the following two categories.
■ Internal loopback, used to check whether there is a fault on the chip’s
functions related to the Ethernet interfaces.
■ External loopback, used to check whether there is a fault on the hardware
functions of an Ethernet interface.
Follow the following steps to configure Layer 3 Ethernet interface loopback:

interface-number
Enable loopback on the loopback { external | Optional
interface internal }

Configuring the According to the layer at which the device processes received data packets,
Working Mode of an Ethernet interfaces can work in bridge or route mode.
Ethernet Interface
Follow these steps to change the working mode of an Ethernet interface:

interface-number
Change the working mode of an port link-mode { bridge | Required
Ethernet interface route }
c CAUTION:
■ Only 4SIC-FSW interface cards, 9DSIC-FSW interface cards, and the fixed
switching interfaces of 20-21 routers support work mode switching.
■ On an MSR series router, you can change the working mode to route mode for
up to two Ethernet interfaces.
■ After you change the working mode of an Ethernet interface, all the settings of
the Ethernet interface are restored to their defaults.
Configuring Layer 2
Ethernet Interfaces
Configuration Task List Ethernet interface configuration in bridge mode involves the following tasks:
■ “Configuring a Port Group” on page 92
■ “Configuring the Storm Suppression Ratio for an Ethernet Interface” on page
93
■ “Configuring the Interval for Collecting Ethernet Interface Statistics” on page
94
■ “Enabling Loopback Detection on an Ethernet Interface” on page 94
■ “Configuring the Cable Type for an Ethernet Interface” on page 95
■ “Testing the Cable on an Ethernet Interface” on page 96
Configuring a Port Port group enables configurations to be applied to multiple ports at the same
Group time. It relieves users of some duplicated operations that are needed on multiple
devices. Any commands executed in port group view apply to all the ports in the
port group.
A port group belongs to one of the following two categories:
■ Manual port group: manually created by users. You can add multiple Ethernet
interfaces to a manual port group.
■ Dynamic port group: dynamically created by the system, currently mainly used
to form link aggregation port groups. A link aggregation port group is
automatically created together with the creation of a link aggregation group
and cannot be created by users through command line input. The operations to

add ports to or removing ports from a link aggregation port group can only be
achieved through operations on the link aggregation group.
Manual port group is mainly used to synchronize the configurations among the
ports in it. When you use the display current-configuration or display this
command to view the current configuration, the configuration concerning manual
port group is not displayed. The configuration of manual port group gets invalid
after you reboot the device even if you have saved the current configuration
before reboot.
Aggregation port group is mainly used to achieve the port aggregation function.
You can use the display current-configuration or display this command to
view aggregation port group-related information. In addition, if you save the
configuration concerning aggregation port group, it remains valid even if you
reboot the device.
Follow these steps to enter aggregation port group view:
Use the
To do... command... Remarks
Enter port group Enter manual port group view port-group -
view manual
port-group-name
Enter aggregation port group port-group
view aggregation
agg-id
Follow these steps to configure a manual port group:

Create a manual port group and port-group aggregation agg-id Required
enter port group view
Add Ethernet interfaces to the group-member interface-list Required
manual port group
n Refer to “Aggregation Port Group” on page 349 for the information about
aggregation port group.
Configuring the Storm You can use the following commands to suppress the broadcast, multicast, and
Suppression Ratio for an unknown unicast traffic. When the broadcast, multicast, or unknown unicast
Ethernet Interface traffic over the interface exceeds the threshold, the system will discard the extra
packets so that the broadcast, multicast, or unknown unicast traffic ratio can drop
below the limit to ensure that the network functions properly.
Follow these steps to configure a storm suppression ratio for an Ethernet interface
To do... To use... Remarks


To do... To use... Remarks

Enter Enter interface interface-type Use either command
Ethernet Ethernet interface-number
Configured in interface view,
interface interface
the setting is effective only on
view or port view
the current interface; configured
group view
Enter port port-group { manual in port group view, the setting is
group view port-group-name | effective on all the ports in the
aggregation agg-id } current port group.
Configure the broadcast broadcast-suppression Optional
storm suppression ratio or { ratio | pps max-pps }
Currently, the ratio argument
the maximum PPS allowed
can only be 100; and the
on the Ethernet interface
max-pps argument can be 190,
380, 760, 1488, 2976, 5952, or
11904.
Configure multicast storm multicast-suppression Optional
suppression ratio or the { ratio | pps max-pps }
Currently, the ratio argument
maximum PPS allowed on
can only be 100; and the
the Ethernet interface
max-pps argument can be 190,
380, 760, 1488, 2976, 5952, or
11904.
Configure the unknown unicast-suppression { ratio | Optional
unicast storm suppression pps max-pps }
Currently, this command is not
ratio or the maximum PPS
supported.
allowed on the Ethernet
interface
n If you set the suppression ratio in interface view or port group view repeatedly, the
last configuration takes effect.
Configuring the Interval Complete the following configuration tasks to configure the time interval for
for Collecting Ethernet collecting interface statistics. Use the display interface command to display the
Interface Statistics interface statistics within this time interval.
Follow these steps to configure the interval for collecting interface statistics:

Configure the time flow-interval interval Optional
interval for collecting
The default interval for collecting
interface statistics
interface statistics is 300 seconds.
This configuration applies to all the Layer 2 ports.
Enabling Loopback The purpose of loopback detection is to detect loops on an interface.

Detection on an
Ethernet Interface When loopback detection is enabled on an Ethernet interface, the device will
routinely check whether the ports have any external loopback. If it detects a
loopback on a port, the device will turn that port under loopback detection mode.
■ If loops are detected on a port that is of access type, the port will be shutdown.
Meanwhile, trap messages will be sent to the terminal, and the corresponding
MAC address forwarding entries will be removed.

■ If loops are detected on a port that is of trunk or hybrid type, trap messages are
sent to the terminal. If the loopback detection control function is also enabled
on the port, the port will be blocked, trap messages will be sent to the
terminal, and the corresponding MAC address forwarding entries will be
removed.
Follow the following steps to configure loopback detection:

Enable global loopback loopback-detection enable Required
detection
Disabled by default
Configure the interval for port loopback-detection Optional
loopback detection interval-time time
30 seconds by default
interface-number
Enable loopback detection on loopback-detection enable Required
a port
Disabled by default
Enable loopback detection loopback-detection control Optional
control on a Trunk port or a enable
Disabled by default
Hybrid port
Enable loopback detection in loopback-detection Optional
all the VLANs containing the per-vlan enable
Enabled only in the default
port
VLAN(s) with Trunk port or
Hybrid ports
Display the information about display loopback-detection Optional
loopback detection
This command can be
executed in any view.
c CAUTION:
■ Loopback detection on a given port is enabled only after the
loopback-detection enable command has been issued in both system view
and the interface view of the port.
■ Loopback detection on all ports will be disabled after the issuing of the undo
loopback-detection enable command under system view.
■ For a Trunk or Hybrid port, make sure that the default VLAN of the port exists.
Configuring the Cable

Type for an Ethernet
Interface
n ■
■
The optical interface of a Combo port does not support this feature.
After you perform the configuration described in this section, the link goes
down and up automatically.
Two types of Ethernet cables can be used to connect Ethernet devices: crossover
cable and straight-through cable. To accommodate these two types of cables, an
Ethernet interface on a device can operate in one of the following three Medium
Dependent Interface (MDI) modes:

■ Across mode, where the Ethernet interface only accepts crossover cables.
■ Normal mode, where the Ethernet interface only accepts straight-through
cables.
■ Auto mode, where the Ethernet interface accepts both straight-through cables
and crossover cables.
Normally, the auto mode is recommended. The other two modes are useful only
when the device cannot determine the cable type.
Follow these steps to configure the cable type for an Ethernet Interface:

Enter Ethernet interface interface interface-type -
Configure the cable mdi { across | auto | normal } Optional
type for an Ethernet
Defaults to auto, that is, system
interface
automatically detects the type of
cable in use.
Testing the Cable on an

Ethernet Interface
n The optical interface of a Combo port does not support this feature.
Complete the following configurations to test the current working state of the
cable on an Ethernet interface. The system will return the testing result within five
seconds, indicating the receiving direction (RX), transmit direction (TX), any
short-circuit or open circuit, and the length of the faulty cable.

interface-number
Test the current working state of virtual-cable-test Required
Ethernet interface cables
Configuring Layer 3
Ethernet Interfaces
Configuration Task List Ethernet interface configuration in bridge mode involves the following tasks:
■ “Setting the MTU for an Ethernet Interface” on page 96
■ “Configuring the Suppression Time of Link-Layer-State Changes on an
Ethernet Interface” on page 97
Setting the MTU for an The value of Maximum Transmission Unit (MTU for short) affects the
Ethernet Interface fragmentation and grouping of IP packets.

Maintaining and Displaying an Ethernet Interface 97
Follow the following steps to set the MTU for an Ethernet interface:

interface-number
Set the MTU mtu size Optional
1,500 bytes by default
n Limited to the QoS queue length (for example, the default length of an FIFO queue
is 75), too small an MTU will result in too many fragments, which will be discarded
from the QoS queue. In this case, you can increase MTU or QoS queue length
properly. In Ethernet interface view, you can use qos fifo queue-length to
change the QoS queue length. For detailed configurations, see “QoS Overview” on
page 1623.
Configuring the An Ethernet interface working in Layer 3 mode has two link layer states: up and
Suppression Time of down. During the suppression time, link-layer-state changes will not be
Link-Layer-State propagated to the system. Only after the suppression time has elapsed will the
Changes on an Ethernet system be notified of the link-layer-state changes by the link layer. This
Interface functionality reduces the extra overhead occurred due to frequent link-layer-state
changes within a short period of time.
Follow the following steps to configure the suppression time of link-layer-state

changes on Ethernet Interface:

interface-number
Configure the suppression time of timer hold seconds Optional
link-layer-state changes on an Ethernet
10 seconds by
Interface
default
n You can increase the polling interval to reduce the negative effective caused to
network traffic due to time delay or heavy congestion.
Maintaining and
Displaying an To do... Use the command... Remarks
Ethernet Interface Display the current state of a display interface [ interface-type Available in any view
specified interface and related [ interface-number ] ]
information
Display a summary of a display brief interface Available in any view
specified interface [ interface-type [ interface-number ] ]
[ | { begin | include | exclude} text ]
Reset the statistics of a reset counters interface Available in user view
specified interface [ interface-type [ interface-number ] ]
Display the current ports of a display port { hybrid | trunk } Available in any view
specified type


Display the information about display port-group manual [ all | Available in any view
a manual port group or all the name port-group-name ]
manual port groups
Display the information about display loopback-detection Available in any view
the loopback detection
function

WAN INTERFACE CONFIGURATION
4
In terms of line type, wide area networks (WANs) fall into these types: X.25, Frame
Relay (FR), ATM, and ISDN. To interface to these networks, routers are designed
with asynchronous serial interface, synchronous serial interface, ATM interface,
ISDN BRI interface, CE1/PRI interface, and so on.
When configuring WAN interfaces, go to the following sections for information

that you are interested in:
■ “Asynchronous Serial Interface” on page 99

■ “AUX Interface” on page 101
■ “USB Interface” on page 101
■ “AM Interface” on page 103
■ “ISDN BRI Interface” on page 104
■ “CE1/PRI Interface” on page 106
■ “CT1/PRI Interface” on page 110
■ “E1-F Interface” on page 115
■ “T1-F Interface” on page 117
■ “CE3 Interface” on page 119
■ “CT3 Interface” on page 122
n Refer to “ATM and DSL Interface Configuration” on page 71 for information about
ATM interface.
Asynchronous Serial
Interface
Overview Following two types of asynchronous serial interfaces are available.

■ Synchronous/asynchronous serial interface operating in asynchronous mode,
whose interface index begins with Serial
■ Dedicated asynchronous serial interface, whose interface index begins with
Async
An asynchronous serial interface can operate in the flow mode or protocol mode.
It can operate as a dialup interface when having a modem or an ISDN terminal
adapter (TA) attached to it. You can encapsulate an asynchronous serial interface
with PPP on the data link layer to provide support for network layer protocols such
as IP and IPX.

100 CHAPTER 4: WAN INTERFACE CONFIGURATION
Configuring an Follow these steps to configure an asynchronous serial interface:

Asynchronous Serial
Enter asynchronous interface async Required
serial interface view interface-number
or
interface serial
interface-number
Set the interface physical-mode async Required
operating mode to
The default is synchronous mode.
asynchronous mode
This command is not available on AM
interfaces.
Skip this step if the interface is an
Async interface.
Set the link layer link-protocol ppp Optional
protocol
The default is PPP.
Set the operating mode async mode { flow | Optional
protocol }
The default is the protocol mode.
Enable level detection detect dsr-dtr Optional
Enabled by default.
This command is not available to AM
interfaces.
Enable local loopback loopback Optional
The default is 1500 bytes.
Set the polling interval timer hold seconds Optional
The default is 10 seconds.
Eliminate the pulses eliminate-pulse Optional
with a width less than
Enabled by default
3.472 us
Configure the MRU phy-mru mrusize Optional
when the interface
The default MRU is 1,700 bytes.
operates in the flow
mode This command is not available to AM
interfaces.
n ■ You can use the speed command to configure the baud rate for an
asynchronous serial interface. For details, refer to the “User Interface
■ Refer to “Configuring PPP” on page 367, “DCC Configuration” on page 153,
“IP Addressing Configuration” on page 623, “Firewall Configuration” on page
1789, and “Backup Center Configuration” on page 1961 for information about
the configuration concerning PPP, DCC, IP addressing, firewall, and backup
center.

AUX Interface 101
AUX Interface
Overview The AUX interface is fixed on your device. It can work as a regular asynchronous
serial interface at speeds up to 115200 bps. With this interface, you can perform
functions such as remote device configuration and line backup.
Configuring an AUX Follow these steps to configure an AUX interface:

Interface
Enter AUX interface view interface aux --
interface-number
Set the operating mode async mode { flow | Optional
protocol }
The default is the flow mode.
Enabled by default.
Set the link layer protocol link-protocol ppp Optional
The default is PPP.
n To perform other AUX interface configurations (such as baud rate, stop bit, parity,
and flow control), use the corresponding commands in user-interface view. Refer
to “User Interface Configuration” on page 2155 for related information.
USB Interface
Overview A USB interface can be used as a dial-up interface when having a 3G modem
attached to it. USB interface operates in the protocol mode. The link layer protocol
can be PPP and the network layer protocol can be IP or IPX.
Configuring a USB Follow these steps to configure a USB interface:

Interface
Enter USB interface view interface usb Required
interface-number
Set the link layer protocol link-protocol ppp Optional
The default is PPP.
The default is 1500 bytes.

n In certain cases, configurations concerning PPP, DCC, IP address, firewall, and

backup center are required for a USB interface. Refer to “Configuring PPP” on
page 367, “DCC Configuration” on page 153, “IP Addressing Configuration” on
page 623, “Firewall Configuration” on page 1789, and “Backup Center
Configuration” on page 1961 for related information.
Synchronous Serial
Interface
Overview A synchronous serial interface has the following features:

■ Work in either DTE or DCE mode. Usually, it serves as DTE to accept the clock
provided by DCE.
■ Be connected to various types of cables, such as V.24, V.35, X.21, RS449, and
RS530. Your device can automatically detect the type of connected cable and
select electrical properties. In most cases, you do not need to manually
configuration them.
■ Support link layer protocols such as PPP, FR, link access procedure, balanced
(LAPB), and X.25.
■ Support network layer protocols IP and IPX.
■ Provide information about the connected cable type, operating mode (DTE or
DCE) and so on with the display interface serial command.
Configuring a Follow these steps to configure a synchronous serial interface:

Synchronous Serial
Enter synchronous serial interface serial Required
Set the interface operating physical-mode sync Optional
mode to synchronous mode
The default is synchronous
mode.
Set the link layer protocol link-protocol { fr | hdlc | Optional
lapb | ppp | sdlc | x25 }
The default is PPP.
Set the digital signal coding code nrzi Optional
format
The default is
non-return-to-zero (NRZ).
Set the baud rate baudrate baudrate Optional
virtualbaudrate The default is 64,000 bps.
virtualbaudrate
These commands are available
to synchronous/asynchronous
serial interface operating in
asynchronous mode only.

AM Interface 103

Set the DTE-side operating clock { dteclk1 | dteclk2 | Optional
clock dteclk3 | dteclk4 |
The default is DCEclk for DCE
dteclkauto }
side and DTEclk1 for DTE side.
When the interface is
functioning as DCE, you do
not need to make the
configuration.
Set transmit-clock or receive invert { transmit-clock | Optional
clock inversion receive-clock }
Clock inversion is disabled by
default.
The default is 1,500 bytes.
Set the CRC mode crc { 16 | 32 | none } Optional
The default is 16-bit CRC.
Enabled by default.
Enable data carrier detection detect dcd Optional
(DCD)
Enabled by default.
Configure the polling interval timer hold seconds Optional
Set line idle-mark to 0xFF idle-mark Optional
The default is 0x7E.
Enable RTS signal reverse reverse-rts Optional
n ■ To set the baud rate for a synchronous/asynchronous serial interface operating

in asynchronous mode, use the speed command in user-interface view. Refer
to “User Interface Configuration” on page 2155 for related information.
■ Refer to corresponding volumes for information about other synchronous serial
interface configurations, such as PPP/X.25/FR, “DCC Configuration” on page
153, “IP Addressing Configuration” on page 623, “Firewall Configuration” on
page 1789, and “Backup Center Configuration” on page 1961.
You may need to configure parameters of PPP/X.25/FR, DCC, IP addressing,

firewall, and backup center in addition.
AM Interface
Overview Analog modem (AM) interfaces bring services provided by asynchronous serial
interfaces and analog modems together. Most of the configuration commands
used on asynchronous serial interfaces and modems can be directly used on AM
interfaces. When configuring an AM interface, you can treat it as a special
asynchronous serial interface.
AM interfaces provide dial-in and dial-out services for analog dial-up users.

Theoretically, if the peer (usually an ISP) uses a digital modem, the AM interface
can establish connection with V.90 Modem standard to provide downstream rates
up to 56 kbps and upstream rates up to 33.6 kbps. If the peer (usually a common
user) uses an analog modem (or an AM interface), the AM interface can establish
connection with V.34 Modem standard to provide rates (both downstream and
upstream) up to 33.6 kbps.
The real rate of an AM interface, however, may deviate somewhat depending on

line quality, PBX performance, connection protocol, and other elements.
Configuring an AM Follow these steps to configure an AM interface:

Interface
Enter AM interface view interface analogmodem Required
number
Set the area code country-code area-name Optional
united-states by default
Set asynchronous interface See “Configuring an Optional
properties Asynchronous Serial
Interface” on page 100.
n To set the baud rate for an AM interface, use the speed command in
user-interface view. Refer to “User Interface Configuration” on page 2155 for
related information.
The configuration of AM interface is similar to that of asynchronous interface and

modem, except that an AM interface does not support the modem auto-answer
and the baudrate commands. (Refer to “Modem Configuration” on page 355 for
information about modem configuration.)
You may need to configure parameters concerning PPP, DCC, IP addressing,

firewall and backup center. For their configuration, refer “Configuring PPP” on
page 367, “DCC Configuration” on page 153, “IP Addressing Configuration” on
page 623, “Firewall Configuration” on page 1789, and “Backup Center
ISDN BRI Interface
Overview Technical background

Integrated services digital network (ISDN) is a technology rising in 1970s. It
provides all-digital terminal-to-terminal services and fulfills the full digitized
delivery of the services integrated voice, data, graphics and video.
ISDN is different from the conventional PSTN network. In a conventional PSTN

network, user information is transferred as analog signals over analog user loop to
exchanges where these analog signals are converted into digital signals. These
digital signals traverse the digital switching and transmission network and are
converted into the analog signals again upon their reach at the destination. ISDN
makes it possible to implement digital transmission on a user loop and fulfills the
end-to-end digitalization. As a standardized digital interface, ISDN BRI interface

ISDN BRI Interface 105
can be used to forward digital and analog information. The standardization efforts
that ITU-T made in provisioning the ISDN services make the implementation of
ISDN become possible. The provisions of the recommendations I.430, Q.921, and
Q.931 allow all the devices meeting ITU-T ISDN provisions of unbarring ISDN
network access.
The following is the provision standardizing the ISDN user-network interface.
ITU-T I.411 provides the referential ISDN user-network interface configuration as

shown in the following figure on the basis of function group (a set of functions
required for accessing an ISDN network) and reference point (a concept used to
differentiate function groups).
Figure 5 Referential ISDN user-network interface configuration
5 4 3 2 1
TE1 NT2 NT1

S T U
TE2 TA
R S
Function groups include:
■ Network terminal 1 (NT1) implements the functionality of the first layer in the
OSI reference model, such as subscriber-line transmission, loop test, D-channel
competition.
■ Network terminal 2 (NT2), also known as intelligent network terminal,
implements the functionality of layers 1 through 3.
■ Category-1 terminal equipment (TE1), also known as ISDN standard terminal, is
user equipment compliant with the ISDN interface provisions. Digital phone-set
is such an example.
■ Category-2 terminal equipment (TE2), also known as non-ISDN standard
terminal equipment, refers to the user equipment incompliant with the ISDN
interface provisions.
■ Terminal adapter (TA) implements the adaptation function so that TE2 can
access a standard ISDN interface.
Reference points include:
■ R reference point between a non-ISDN equipment and TA.

■ S reference point between a user terminal and NT2.
■ T reference point between NT1 and NT2.
■ U reference point between NT1 and line terminal.
Preparing for making configuration

Before making configuration, you should:

■ Verify the type of the interface provided by your telecom service provider,
whether it is ISDN BRI U or ISDN BRI S/T. Despite that ITU-T I.411 has provided
an ISDN user-network interface reference model, there are some arguments in
the position of the user-network dividing point. For this reason, some nations
adopt the U interface while some others adopt the S/T interface depending on
their needs. Therefore, you must make sure the interface type provided by your
service provider before making a router purchase decision.
■ Request for digital service. As ISDN can provide integrated services including
both digital and voice, you must request for an ISDN line allowing digital call
service so that your router can make digital communications.
■ Select connection type, which can be a point-to-point connection or a
point-to-multipoint connection (optional). As ISDN supports semipermanent
connection, you can adopt the ISDN leased line in the event that you adopt
ISDN only for connecting two fixed points. Otherwise, you must select a
point-to-multipoint connection.
■ Request for the delivery of Calling Line Identification (CLI) function (optional).
With it, you can implement calling ID filtering on your ISDN line to reject some
users from accessing the local router and hence enhance the network security.
Configuring ISDN BRI Follow these steps to configure an ISDN BRI interface:
Interface
Enter ISDN BRI interface view interface bri number Required
Enable external loopback on the loopback { b1 | b2 | both } Disabled by default
ISDN BRI interface
ISDN BRI interfaces are used for dialup purpose. For details on ISBN BRI interface
configuration, refer to “DCC for Dialup ISDN BRI Line and Leased Line Connection”
on page 192.
CE1/PRI Interface
Overview In 1960s, the time division multiplexing (TDM) technology gained increasingly
wide application in the data communications system along with the introduction
of pulse code modulation (PCM) technology. So far, there exist two TDM systems
in the data communications system. One is the ITU-T recommended E1 system
that is widely adopted in Europe and P.R. China. The other is the ANSI
recommended T1 system that is widely used in North American and Japan. (The
system that Japan adopts is actually called J1. It is regarded as a T1 system due to
high similarity between them.)
A CE1/PRI interface can work in either E1 mode (also called non-channelized

mode) and CE1/PRI mode (that is, channelized mode).
A CE1/PRI interface in E1 mode equals an interface of 2 Mbps data bandwidth, on

which, no timeslots are divided. Its logic features are the same like those of a
synchronous serial interface. It supports the link layer protocols such as PPP, FR,
LAPB and X.25 and the network protocols such as IP and IPX.

A CE1/PRI interface in CE1/PRI mode is physically divided into 32 timeslots

numbered 0 to 31. Among them, timeslot 0 is used for transmitting synchronizing
information. This interface can be used as either a CE1 interface or a PRI interface.
■ When this interface is used as a CE1 interface, all the timeslots except timeslot
0 can be randomly divided into multiple channel sets and each set can be used
as an interface upon timeslot bundling. Its logic features are the same as those
of a synchronous serial interface. It supports link layer protocols such as PPP, FR,
LAPB and X.25, and network protocols such as IP and IPX.
■ When the interface is used as a PRI interface, timeslot 16 will be used as a D
channel to transmit signaling. Therefore, rather than selecting among all the
timeslots, you are only allowed to make a random B channel selection among
the timeslot sets except timeslots 0 and 16. The selected set of timeslots can be
bundled together with timeslot 16 to form a PRI set that can be used as an
interface. The logic features of this interface will be the same as those of an
ISDN PRI interface. It will support link layer protocol PPP and network protocols
such as IP and IPX and can be configured with parameters such as DCC.
Configuring CE1/PRI Follow these steps to configure a CE1/PRI interface in E1 mode:

Interface (in E1 Mode)
Enter CE1/PRI interface view controller e1 number Required
Set the interface to operate in using e1 Required
E1 mode
The default operating mode is
CE1/PRI mode.
Set other interface parameters See “Configuring Other Optional
CE1/PRI Interface Parameters”
on page 109.
After you set the CE1/PRI interface to operate in E1 mode, the system
automatically creates a serial interface numbered serial interface-number:0. This
interface is logically equivalent to a synchronous serial interface where you can
make other configurations such as:
■ Parameters of data link protocol such as “Configuring PPP” on page 367,

“VoFR Configuration” on page 2385, or “X.25 and LAPB Configuration” on
page 283
■ “IP Addressing Configuration” on page 623
■ “Backup Center Configuration” on page 1961 if the interface is used as a
primary or secondary interface for backup
■ “NAT-PT Configuration” on page 679 and “Configuring a Packet Filter Firewall”
on page 1794 if a firewall is to be set up
Configuring CE1/PRI Follow these steps to configure a CE1/PRI interface in CE1 mode:
Interface (in CE1 Mode)


Set the interface to operate in using ce1 Optional
CE1/PRI mode
CE1/PRI mode.
Bundle timeslots on the channel-set set-number Required
interface into channel sets timeslot-list list
Set other interface parameters See “WAN Interface Optional
A CE1/PRI interface in CE1/PRI mode can be used as a CE1 interface where a serial
interface is created upon creation of a channel set. You may bundle timeslots on a
CE1/PRI interface into up to 31 channel sets.
For each channel set, the system automatically creates a serial interface numbered
serial interface-number:set-number. This interface is logically equivalent to a
synchronous serial interface where you can make other configurations about:
■ Data link protocol such as “PPP and MP Configuration” on page 363, “VoFR
Configuration” on page 2385, “X.25 and LAPB Configuration” on page 283
n The timeslots on a CE1/PRI interface can be bundled into either channel sets or a
PRI set, but not the both, at a time.
Configuring CE1/PRI Follow these steps to configure a CE1/PRI interface in PRI mode:
Interface (in PRI Mode)
Set the interface to operate in using ce1 Optional
CE1/PRI mode
CE1/PRI mode.
Bundle timeslots on the pri-set [ timeslot-list list ] Required
interface into a PRI set
If no timeslot range is
specified, all timeslots except
timeslot 0 form a 30B + D
ISDN PRI interface.
Set other interface parameters See “WAN Interface Optional
A CE1/PRI interface in CE1/PRI mode can be used as a PRI interface where only one
PRI set can be created.
For the PRI set, the system automatically creates a serial interface numbered serial
interface-numbe:15. This interface is logically equivalent to an ISDN PRI interface
where you can make other configurations about:

■ “DCC Configuration” on page 153

■ “Configuring PPP” on page 367
■ “Backup Center Configuration” on page 1961 if the interface is to be used as a
■ “Firewall Configuration” on page 1789
n The timeslots on a CE1/PRI interface can be bundled into either channel sets or a
PRI set, but not both at a time.
Configuring Other Follow these steps to configure other CE1/PRI interface parameters:
CE1/PRI Interface
Parameters To do... Use the command... Remarks
Set the line code format code { ami | hdb3 } Optional
The default is high density
bipolar 3 (HDB3).
Configure to perform AIS detect-ais Optional
(alarm indication signal) test
By default, AIS test is
performed.
Set the cable type cable { long | short } Optional
The default cable setting is
long mode.
The default is slave, that is,
line clock.
Set the framing format frame-format { crc4 | Optional
no-crc4 }
The default is no-CRC4.
Set the line idle code type idlecode { 7e | ff } Optional
Set the type of interframe itf type { 7e | ff } Optional
filling tag
Set the number of interframe itf number number Optional
filling tags
The default is 4.
Set the loopback mode loopback { local | remote | Optional
payload }
Loopback is disabled by
default.
Quit to system view quit -
interface view of the interface interface-number:set-number
formed by a CE1/PRI interface
or
interface serial
interface-number:15
By default, 16-bit CRC is
adopted.

Configuring Error
Packets Diffusion
Restraint
n The support of this feature varies with device model. Refer to your specific device.
Error packet diffusion refers to the situation when one timeslot receives a certain
error packet, all the other timeslots are affected and also receive error packets.
You can restrain error packet diffusion by configuring three parameters:

detect-timer, renew-timer, threshold, which function in the following way:
If, during the time specified by detect-timer, the ratio of error packets on an
interface is greater than that specified by threshold, the interface is regarded as
faulty and is shut down. After waiting for some time specified by renew-timer, the
interface is re-enabled.
Follow these steps to configure error packets diffusion restraint:

Enable error packets diffusion error-diffusion restraint Required
enable
Configure the parameters of error-diffusion restraint Optional
error packets diffusion config detect-timer
By default, the value of
restraint renew-timer threshold
detect-timer is 30 seconds, of
renew-timer is 600 seconds;
the threshold is 20%
Restart the channel that is error-diffusion restraint Optional
shut down for the sake of restart-channel serial
error packets restraint interface-number:set-number
Displaying and
Maintaining CE1/PRI To do... Use the command... Remarks
Interfaces Display the operating state of display controller e1 Available in any view
a CE1/PRI interface [ interface-number ]
Display the operating state of display interface serial Available in any view
a channel set or PRI set interface-number:set-number
Clear the controller counter reset counters controller e1 Available in user view
for a CE1/PRI interface interface-number
CT1/PRI Interface
Overview A CT1/PRI interface can only operate in channelized mode. It can be used in the
following two ways:
■ When it is working as a CT1 interface, all the timeslots from 1 to 24 can be
randomly divided into groups. Each of these groups can form one channel set
for which the system automatically creates an interface logically equivalent to a
synchronous serial interface. This interface supports link layer protocols such as
PPP, FR, LAPB, and X.25, and network protocols such as IP and IPX.

■ When it is working as a PRI interface, timeslot 24 is used as a D channel for

signaling transmission. Therefore, only a group of timeslots except timeslot 24
can be chosen as the B channel. This timeslot group is bundled together with
timeslot 24 to form a PRI set. This PRI set will work as an interface logically
equivalent to an ISDN PRI interface where you can configure PPP at the data
link layer, IP or IPX at the network, DCC, and other configurations.
n The timeslots on a CT1/PRI interface can be bundled into either channel sets or a
PRI set at a time.
Configuring CT1/PRI Follow these steps to configure a CT1/PRI interface in CT1 mode:
Interface in CT1 Mode
Enter CT1/PRI interface view controller t1 number Required
Bundle timeslots on the channel-set set-number Required
interface into channel sets timeslot-list list [ speed
Up to 24 channel sets can be
{ 56k | 64k } ]
bundled.
The default timeslot speed is
64 kbps.
Configure other interface See “Configuring Other Optional
parameters CT1/PRI Interface Parameters”
on page 112.
For each channel set, the system automatically creates a serial interface numbered
serial number:set-number. This interface is logically equivalent to a synchronous
serial interface where you can make other configurations about:
■ Data link protocol such as “PPP and MP Configuration” on page 363, “VoFR
Configuration” on page 2385, “X.25 and LAPB Configuration” on page 283
Configuring an CT1/PRI Follow these steps to configure a CT1/PI interface operating as a PRI mode:
Interface operating as a
PRI interface To do... Use the command... Remarks
Bundle timeslots on the pri-set [ timeslot-list list ] Required
interface into a PRI set
Only one PRI set can be
created at a time.
Configure other interface See “Configuring Other Optional
parameters CT1/PRI Interface Parameters”
on page 112.

For the PRI set, the system automatically creates a serial interface numbered serial
number:23. This interface is logically equivalent to an ISDN PRI interface where
you can make other configurations about:

■ “Configuring a Packet Filter Firewall” on page 1794
Configuring Other Follow these steps to configure other CT1/PRI interface parameters:
CT1/PRI Interface
Parameters To do... Use the command... Remarks
Set the line code format code { ami | b8zs } Optional
The default is B8ZS1.
Set the cable length and cable long { 0db | -7.5db | Optional
attenuation -15db | -22.5db }
The long 0db keyword
cable short { 133ft | 266ft | applies by default.
399ft | 533ft | 655ft }
line clock.
Set the framing format frame-format { sf | esf } Optional
The default is ESF.
Enable user data inversion data-coding { normal | Optional
inverted }
Disable user data inversion.
Set the line idle code type idlecode { 7e | ff } Optional
Set the type of interframe itf type { 7e | ff } Optional
filling tag
Set the number of interframe itf number number Optional
filling tags
The default is 4.


Set alarm thresholds alarm-threshold los Optional
pulse-detection value
1 For LOS3 alarm
alarm-threshold los
The threshold of
pulse-recovery value
pulse-detection defaults to
alarm-threshold ais {level-1| 176 and the threshold of
level-2} pulse-recovery defaults to 22.
That is, if the number of the
alarm-threshold lfa { level-1
pulses detected during the
| level-2 | level-3 | level-4 }
total length of 176 pulse
detection intervals is smaller
than 22, the pulse-recovery
threshold, a LOS alarm occurs.
1 Both AIS4 alarm threshold
and LFA5 alarm threshold
default to level-1.
Set the behavior of the fdl { ansi | att | both | none } Optional
interface on the FDL in ESF
The default is none, meaning
framing
that FDL is forbidden.
Enable loopback loopback { local | remote | Optional
payload }
Send remote control loopback sendloopcode Optional
code { fdl-ansi-llb-down |
No remote control code is
fdl-ansi-llb-up |
sent by default.
fdl-ansi-plb-down |
fdl-ansi-plb-up |
fdl-att-plb-down |
fdl-att-plb-up |
inband-llb-down |
inband-llb-up }
interface view of an interface interface-number:set-number
formed by a CT1/PRI interface
or
interface serial
interface-number:23
adopted.
Note:
1. B8ZS = Bipolar 8-zero substitution; 2. ESF = Extended super frame; 3. LOS = Loss of signal;
4. AIS = Alarm indication signal; 5. LFA = Loss of frame align
Starting/Stopping a Bit error rate test (BERT) is operating as follows:

BERT Test on CT1/PRI
Interface The local end sends out a pattern, which is to be looped over somewhere on the
line and back to the local end. The local end then checks the received pattern for
the bit error rate, and by so doing helps you determine whether the condition of
the line is good. To this end, you must configure loopback to allow the transmitted
pattern to loop back from somewhere on the line, for example, from the far-end
interface by placing the interface in far-end loopback.
You may view the state and result of the BERT test with the display controller t1
command.

Follow these steps to start/stop a BERT test on a CT1/PRI interface:

Start a BERT test bert pattern { 2^20 | 2^15 } Required
time minutes [ unframed ]
Configuring Error
Packets Diffusion
Restraint
n The support of this feature varies with device model. Refer to your specific device.
Error packet diffusion refers to the situation when one timeslot receives a certain
error packet, all the other timeslots are affected and also receive error packets.
You can restrain error packet diffusion by configuring three parameters:

detect-timer, renew-timer, and threshold, which function in the following way:
If, during the time specified by detect-timer, the ratio of error packets on an
interface is greater than that specified by threshold, the interface is regarded as
faulty and is shut down. After waiting for some time specified by renew-timer, the
interface is re-enabled.
Follow these steps to configure error packets diffusion restraint:

Enable error packets diffusion error-diffusion restraint Required
enable
Configure the parameters of error-diffusion restraint Optional
error packets diffusion config detect-timer
By default, the values are 30
restraint renew-timer threshold
seconds for detect-timer, 600
seconds for renew-timer and
20% for the threshold.
Restart the channel that is error-diffusion restraint Optional
shut down for the sake of restart-channel serial
error packets restraint interface-number:set-number
Displaying and
Maintaining CT1/PRI To do... Use the command... Remarks
Interfaces Display the operating state of display controller t1 Available in any view
a CT1/PRI interface [ interface-number ]
a channel set or PRI set interface-number:set-number
Clear the controller counter for reset counters controller t1 Available in user view
a CE1/PRI interface interface-number

E1-F Interface 115
E1-F Interface
Overview E1-F interfaces, fractional E1 interfaces, are simplified CE1/PRI interfaces. They are
a cost-effective alternative to CE1/PRI interfaces where E1 access does not need
multiple channel sets or ISDN PRI.
Compared with a CE1/PRI interface, an E1-F interface delivers these features:
■ In framed mode, it can only bind timeslots into one channel set, while a
CE1/PRI interface can group and bundle timeslots randomly into multiple
channel sets.
■ It does not support PRI mode.
An E1-F interface can work in both framed (the default) and unframed modes.
When the E1-F interface is working in unframed mode, it is a non-timeslot

interface with 2048 kbps of data bandwidth. It is logically equivalent to a
synchronous serial interface where you may configure PPP, HDLC, FR, LAPB or X.25
at the link layer and IP or IPX at the network layer.
When the E1-F interface is working in framed mode, it is physically divided into 32
timeslots numbered 0 through 31. Except timeslot 0 used for transmitting
synchronization information, all other timeslots can randomly form one channel
set. The rate of the interface is thus n × 64 kbps and its logical features are the
same as those of a synchronous serial interface where you can configure PPP, FR,
LAPB and X.25 at the data link layer and IP or IPX at the network layer.
Configuring an E1-F Follow these steps to configure an E1-F interface in framed mode:
Interface (in Framed
Mode) To do... Use the command... Remarks
Enter E1-F interface view interface serial Required
interface-number
Set the interface to operate in undo fe1 unframed Optional
framed mode
The default is framed mode.
Bundle timeslots on the fe1 timeslot-list range Optional
interface
specified, all timeslots are
bundled by default.
Set other interface parameters See “Configuring Other E1-F Optional
Interface Parameters” on
page 116.
Configuring an E1-F Follow these steps to configure an E1-F interface in unframed mode:
Interface (in Unframed
Mode) To do... Use the command... Remarks
interface-number


Set the interface to operate in fe1 unframed Required
unframed mode
The default is framed mode.
Set other interface parameters See “Configuring Other E1-F Optional
page 116.
Configuring Other E1-F Follow these steps to configure other E1-F interface parameters:
Interface Parameters
serial-number
Set the line code format fe1 code { ami | hdb3 } Optional
The default is HDB3.
Set the clock mode fe1 clock { master | slave } Optional
line clock.
Set the cable type fe1 cable { long | short } Optional
The long keyword applies by
default.
Configure the CRC mode fe1 crc { 16 | 32 | none } Optional
16-bit CRC by default.
Configure to perform AIS test fe1 detect-ais Optional
By default, AIS test is
performed.
Set the framing format fe1 frame-format { crc4 | Optional
no-crc4 }
Set the line idle code type fe1 idlecode { 7e | ff } Optional
Set the interframe filling tag fe1 itf type { 7e | ff } Optional
type
Set the number of interframe fe1 itf number number Optional
filling tags
The default is 4.
Set the loopback mode fe1 loopback { local | Optional
payload | remote }
default.
Displaying and
Maintaining E1-F To do... Use the command... Remarks
Interfaces Display the configuration and display fe1 [ serial Available in any view
state of a specified or all E1-F interface-number ]
interfaces
an E1-F interface interface-number

T1-F Interface 117
T1-F Interface
Overview T1-F interfaces, fractional T1 interfaces, are simplified CT1/PRI interfaces. They are
a cost-effective alternative to CT1/PRI interfaces where T1 access does not need
multiple channel sets or ISDN PRI.
Compared with a CT1/PRI interface, a T1-F interface delivers these features:
■ In framed mode, it can bind timeslots into only one channel set, while a
CT1/PRI interface can group and bundle timeslots randomly into multiple
channel sets.
■ It does not support PRI mode.
A T1 line is multiplexed from 24 channels. That is, a T1 primary group frame DS1
(digital signal level-1) comprises 24 DS0 (64 kbps) timeslots and 1 framing bit for
synchronization, with each timeslot being 8 bits. Each primary group frame thus
has 193 bits (24 × 8+1). As DS1 can transmit 8000 frames per second, its
transmission speed is 1544 kbps (193 × 8 kbps).
A T1-F interface can only work in framed mode. Timeslots 1 through 24 on it can
randomly form a channel set. The rate of the interface is thus n × 64 kbps or n ×
56 kbps and its logical features are the same as those of a synchronous serial
interface where you can configure PPP, FR, LAPB and X.25 at the data link layer
and IP or IPX at the network layer.
Configuring a T1-F Follow these steps to configure a T1-F interface:

Interface
Enter T1-F interface view interface serial --
interface-number
Bundle timeslots on the ft1 timeslot-list range Required
interface into a channel set [ speed { 56k | 64k } ]
specified, all timeslots are
bundled into one channel set.
64 kbps, and the default T1-F
interface speed is 1536 kbps.
Set the cable length and ft1 cable { long decibel | Optional
attenuation short length }
The long 0db keyword
applies by default.
Set the line code format ft1 code { ami | b8zs } Optional
The default is B8ZS.
Set the clock mode ft1 clock { master | slave } Optional
line clock.
Enable user data inversion ft1 data-coding { inverted | Optional
normal }


Set the behavior of the ft1 fdl { ansi | att | both | Optional
interface on the FDL in ESF none }
FDL is disabled by default.
framing
16-bit CRC by default.
Set the frame format ft1 frame-format { esf | sf } Optional
The default is esf.
Set alarm thresholds ft1 alarm-threshold los Optional
pulse-detection value
For LOS alarm
ft1 alarm-threshold los
The threshold of
pulse-recovery value
pulse-detection defaults to
ft1 alarm-threshold ais 176 and the threshold of
{ level-1 | level-2 } pulse-recovery defaults to 22.
That is, if the number of the
ft1 alarm-threshold lfa
pulses detected during the
{ level-1 | level-2 | level-3 |
total length of 176 pulse
level-4 }
detection intervals is smaller
than 22, the pulse-recovery
threshold, a LOS alarm occurs.
Both AIS alarm threshold and
LFA alarm threshold default to
level-1.
Set the type of line idle code ft1 idlecode { 7e | ff } Optional
Set the type of interframe ft1 itf type { 7e | ff } Optional
filling tag
Set the number of interframe ft1 itf number number Optional
filling tags
The default is 4.
Set the loopback mode ft1 loopback { local | Optional
remote | payload }
default.
Send remote control loopback ft1 sendloopcode Optional
code { fdl-ansi-llb-down |
No remote control code is
fdl-ansi-llb-up |
sent by default.
fdl-ansi-plb-down |
fdl-ansi-plb-up |
fdl-att-plb-down |
fdl-att-plb-up |
inband-llb-down |
inband-llb-up }
Starting/Stopping a BERT is operating as follows:

BERT Test on T1-F
Interface The local end sends out a pattern, which is to be looped over somewhere on the
line and back to the local end. The local end then checks the received pattern for
the bit error rate, and by so doing helps you determine whether the condition of
the line is good. To this end, you must configure loopback to allow the transmitted
pattern to loop back from somewhere on the line, for example, from the far-end
interface by placing the interface in far-end loopback.
You may view the state and result of the BERT test with the display ft1 serial
command.

CE3 Interface 119
Follow these steps to start/stop a BERT test on a T1-F interface:

Enter CT1/PRI interface view interface serial interface-number --
Start a BERT test ft1 bert pattern { 2^20 | 2^15 } time Required
minutes [ unframed ]
Displaying and
Maintaining T1-F To do... Use the command... Remarks
Interfaces Display information about a display ft1 [ serial serial-number ] Available in any
specified or all T1-F interfaces view
Display the operating state of a display interface serial Available in any
specified T1-F interface serial-number view
CE3 Interface
Overview Like E1, E3 also belongs to the digital carrier system of ITU-T. It transmits data at
34.368 Mbps and adopts HDB3 as the line code format.
A CE3 interface can work in either E3 or CE3 (the default) mode.
■ A CE3 interface in E3 mode equals an interface with 34.368 Mbps data

bandwidth, on which, no timeslots are divided.
■ A CE3 interface in CE3 mode can demultiplex 16 channels of E1 signals in
compliance with ITU-T G.751 and G.742. Each E1 line can be divided into 32
timeslots numbered 0 to 31, of which timeslots 1 through 31 can be randomly
bundled into N × 64 kbps logical channels. (Timeslot 0 for framing signal
transmission must not participate in bundling operation.) Therefore, CE3 can
be channelized into E1 lines or CE1 lines.
When an E1 line is working in unframed (E1) mode, the system automatically

creates a serial interface numbered serial number/line-number:0 for it. This
interface operates at 2048 kbps and is logically equivalent to a synchronous serial
interface where you can make other configurations.
When the E1 line is working in framed (CE1) mode, you can bundle timeslots on it.
The system automatically creates a serial interface numbered serial
number/line-number:set-number for it. This interface operates at N × 64 kbps and
is logically equivalent to a synchronous serial interface where you can make other
configurations.
CE3 interfaces support link layer protocols PPP, HDLC, FR, LAPB, and X.25 and
network protocols IP and IPX.
Configuring a CE3 Follow these steps to configure a CE3 interface operating in E3 mode:
Interface (in E3 Mode)


Enter CE3 interface view controller e3 Required
interface-number
Set the interface to operate in using e3 Required
E3 mode
CE3 mode.
Configure the interface to fe3 { dsu-mode { 0 | 1 } | Optional
operate in FE3 mode and set subrate number }
By default, DSU mode 1 (the
the DSU mode or the subrate
Kentrox mode) is adopted,
and the subrate is 34010
kbps.
Set other interface parameters See “Configuring Other CE3 Optional
page 120.
Depending on the networking requirements, you probably need to configure the

CE3 interface with parameters about “Configuring PPP” on page 367, “VoFR
Configuration” on page 2385, “IP Addressing Configuration” on page 623, and so
on.
Configuring a CE3 Follow these steps to configure a CE3 interface in CE3 mode:
Interface operating in
CE3 Mode To do... Use the command... Remarks
interface-number
Set the interface to operate in CE3 using ce3 Optional
mode
CE3 mode.
Set the Set the operating e1 line-number Required
operating mode to unframed unframed
The default is CE1 mode.
mode of an E1 (E1) mode
line on the
Set the operating undo e1 line-number Optional
CE3 interface
mode to framed unframed
to unframed The default is framed mode.
(CE1) mode and
mode or
bundle timeslots e1 line-number Required
framed mode
on the CE1 channel-set set-number
No channel sets are created
interface timeslot-list list
by default.
CE3 Interface
Parameters” on page
120.

CE3 interface with parameters about “Configuring PPP” on page 367, “VoFR
on.
Configuring Other CE3 Follow these steps to configure other CE3 interface parameters:

CE3 Interface 121

interface-number
Configure to perform BERT bert pattern { 2^7 | 2^11 | Optional
test on the CE3 interface 2^15 | qrss } time number
[ unframed ]
Configure to perform BERT e1 line-number bert pattern Optional
test on an E1 channel created { 2^11 | 2^15 | 2^20 | 2^23 |
on the CE3 interface qrss } time number
[ unframed ]
Set the clock For the CE3 clock { master | slave } Optional
mode interface
line clock.
For an E1 line e1 line-number set clock Optional
{ master | slave }
line clock.
Set the national bit national-bit { 0 | 1 } Optional
The default is 1.
Set CRC check for serial crc { 16 | 32 | none} Optional
interfaces formed on the CE3
The default is 16-bit CRC.
interface
Enable For the CE3 loopback { local | payload | Optional
loopback interface remote }
For an E1 line e1 line-number set loopback default.
{ local | payload | remote }
Set E1 framing format on an e1 line-number set Optional
E1 line frame-format { crc4 |
The default is no-CRC.
no-crc4 }
interface view of an interface number/line-number:0
formed by a CE3 interface
or
interface serial
number/line-number:set-num
ber
adopted.
Displaying and
Maintaining CE3
Interfaces
c CAUTION: An interface is disabled when being shut down. So, perform

operations of this type with caution.
You can verify the configuration of a CE3 interface by using the display
commands listed in the following table in any view.


Display the state information display controller e3 Available in any view
of a CE3 interface [ interface-number ]
Display the configuration and display interface serial Available in any view
state of a serial interface interface-number
formed on a CE3 interface
Shut down a CE3 interface shutdown Perform the command in CE3
interface view.
Bring up a CE3 interface undo shutdown Perform the command in CE3
interface view.
Shut down an E1 line e1 line-number shutdown Perform the command in CE3
interface view.
Bring up an E1 line undo e1 line-number Perform the command in CE3
shutdown interface view.
n ■ Shutting down/bringing up a CE3 interface also shuts down/brings up the E1

lines demultiplexed from the CE3 interface, the serial interfaces formed by the
E1 lines, and the serial interfaces created on E1 lines by means of timeslot
bundling.
■ Shutting down/bringing up an E1 line also shuts down/brings up the serial
interface formed by it and the serial interface created on it by means of
timeslot bundling.
■ To shut down/bring up only a serial interface formed by E3 or E1 lines, or by
timeslot bundling on an E1 line, perform the shutdown/undo shutdown
command in the view of the corresponding serial interface.
CT3 Interface
Overview Both T3 and T1 belong to the T-carrier system promoted by ANSI. T3 uses the
digital signal level DS-3 and operates at 44.736 Mbps.
CT3 interfaces support two operating modes: T3 (unchannelized) and CT3

(channelized).
■ In T3 mode, a CT3 interface equals a synchronous serial interface with 44.736

kbps of data bandwidth, on which, no timeslots are divided.
■ In CT3 mode, a CT3 interface can be demultiplexed into 28 channels of T1
signals. Each T1 line can be divided into 24 timeslots numbered 1 through 24.
Different from E1, each line on a T1 interface can operate at either 64 kbps or
56 kbps. Therefore, the number of logical lines that can be created on a CT3
interface in CT3 mode is either M × 1.544 Mbps where M ranges from 1 to 28
or N × 56 kbps or N x 64 kbps where N ranges from 1 to 300.
When a T1 line is working in unframed (T1) mode, the system automatically

creates a serial interface numbered serial number/line-number:0 for it. This
interface operates at 1544 kbps and is logically equivalent to a synchronous serial
interface where you can make other configurations.
When the T1 line is working in framed (CT1) mode, you can bundle timeslots on it.
The system automatically creates a serial interface numbered serial

CT3 Interface 123
number/line-number:set-number for it. This interface operates at N × 64 kbps or N

× 56 kbps and is logically equivalent to a synchronous serial interface where you
can make other configurations.
Configuring a CT3 Follow these steps to configure a CT3 interface in CT3 mode:
Interface (in T3 Mode)
Enter CT3 interface view controller t3 Required
interface-number
Set the interface to operate in using t3 Required
T3 mode
CT3 mode.
Configure the interface to ft3 { dsu-mode { 0 | 1 | 2 | 3 | Optional
operate in the FT3 mode and 4 } | subrate number }
By default, DSU mode 0 (the
set the DSU mode or the
digital link mode) is adopted,
subrate
and the subrate is 44210
kbps.
Set other interface parameters See “Configuring Other CT3 Optional
page 124.

CT3 interface with parameters about “Configuring PPP” on page 367, “VoFR
Configuration” on page 2385, “IP Addressing Configuration” on page 623 and so
on.
Configuring CT3 Follow these steps to configure a CT3 interface in CT3 mode:
Interface in CT3 Mode
interface-number
Set the interface to operate in CT3 using ct3 Optional
mode
CT3 mode.
Set the Set the operating t1 line-number Required
operating mode to unframed unframed
The default is CT1 mode.
mode of a T1 (T1) mode
line on the
Set the operating undo t1 line-number Optional
CT3 interface
mode to framed unframed
to unframed The default is framed mode.
(CT1) mode and
mode or
bundle timeslots t1 line-number Required
framed mode
on the CT1 channel-set set-number
No channel sets are created
interface timeslot-list range
by default.
[ speed { 56k | 64k } ]
64 kbps.
CT3 Interface
Parameters” on page
124.


CT3 interface with parameters about “Configuring PPP” on page 367, “VoFR
on.
Configuring Other CT3 Follow these steps to configure other CT3 interface parameters:
interface-number
Set the clock For the CT3 clock { master | slave } Optional
mode interface
line clock.
For a T1 line t1 line-number set clock Optional
{ master | slave }
line clock.
Set the cable length cable feet Optional
The default is 14.9 meters (49
feet).
Set the On the CT3 loopback { local | payload | Optional
loopback interface remote }
mode
On a T1 line t1 line-number set loopback default.
Set the On the CT3 frame-format { c-bit | m23 } Optional
framing interface
The default is C-bit.
format
On a T1 line t1 line-number set Optional
frame-format { esf | sf }
The default is esf.
Configure On the CT3 alarm { detect | generate Optional
alarm signal interface { ais | febe | idle | rai } }
Alarm detection is enabled by
detection/sen
On a T1 line t1 line-number alarm default.
ding
{ detect | generate { ais |
rai } }
Start a BERT On the CT3 bert pattern { 2^7 | 2^11 | Optional
test interface 2^15 | qrss } time number
BERT test is disabled by
[ unframed ]
default.
On a T1 line t1 line-number bert pattern
{ 2^11 | 2^15 | 2^20 | 2^23 |
qrss } time number
[ unframed ]
Configure FEAC channel signal feac detect Optional
detection/sending on the CT3
feac generate loopback FEAC channel signal
interface
{ ds3-line | ds3-payload } detection is enabled by
default but no FEAC signals
feac generate { ds3-los |
are sent.
ds3-ais | ds3-oof | ds3-idle |
ds3-eqptfail }
Configure MDL message mdl { detect | data { eic Optional
detection/sending on the CT3 string | fic string | | gen-no
By default, MDL message
interface string | lic string | pfi string |
detection and sending are
port-no string | unit string } |
disabled and the default MDL
generate { idle-signal | path
message information applies.
| test-signal } }

CT3 Interface 125

Place a T1 line on the far-end t1 line-number Optional
CT3 interface in a loopback sendloopcode
{ fdl-ansi-line-up |
fdl-ansi-payload-up |
fdl-att-payload-up |
inband-line-up }
Set an FDL format for a T1 line t1 line-number set fdl { ansi | Optional
att | none }
ANSI T1.403 FDL is not
configured and PPR
transmission is disabled by
default.
interface view of an interface number/line-number:0
formed by a CT3 interfaces
or
interface serial
number/line-number:set-num
ber
adopted.
Note:
FEAC = Far end and control signal; MDL = Maintenance data link; PPR = Periodical
performance report
Displaying and
Maintaining CT3
Interfaces
c CAUTION: An interface is disabled when being shut down. So, perform

operations of this type with caution.
You can verify the configuration of a CT3 interface by using the display
commands listed in the following table in any view.

Display the state information display controller t3 Available in any view
of CT3 interface [ interface-number ]
Display the configuration and display interface serial Available in any view
state of a serial interface interface-number
formed on a CT3 interface
Display the state of a T1 line t1 line-number show Perform the command in CT3
interface view.
Shut down a CT3 interface shutdown Perform the command in CT3
interface view.
Bring up a CT3 interface undo shutdown Perform the command in CT3
interface view.
Shut down a T1 line t1 line-number shutdown Perform the command in CT3
interface view.
Bring up a T1 line undo t1 line-number Perform the command in CT3
shutdown interface view.

Note that:
■ Shutting down/bringing up a CT3 interface also shuts down/brings up the T1

lines demultiplexed from the CT3 interface, the serial interfaces formed by the
T1 lines, and the serial interfaces created on T1 lines by means of timeslot
bundling.
■ Shutting down/bringing up a T1 line also shuts down/brings up the serial
interface formed by it and the serial interface created on it by means of
timeslot bundling.
■ To shut down/bring up only a serial interface formed by T3 or T1 lines, or by
timeslot bundling on a T1 line, perform the shutdown/undo shutdown
command in the view of the corresponding serial interface.

ATM CONFIGURATION
5
Introduction to ATM
Technology
ATM Overview Asynchronous transfer mode (ATM) is a technology based on packet transmission
mode while incorporating the high speed of circuit transmission mode. It can
satisfy the need of various communication services. ATM was specified as a
broadband ISDN transmission and switching mode by ITU-T in June 1992.
Depending on its flexibility and support to multimedia services, it is regarded as
the core technology to implement broadband communications.
As defined by ITU-T, ATM transmits, multiplexes, and switches information in ATM

cells. An ATM cell has a fixed length of 53 bytes, among which 5 bytes is the cell
header and the remaining 48 bytes are payloads. The major function of the cell
header is to identify virtual connection, with limited functions on flow control,
congestion control and error control.
ATM is connection-oriented. The connection is a logical connection, or virtual

connection (VC). Each VC is identified by a pair of virtual path identifier (VPI) and
virtual channel identifier (VCI). One VPI/VCI pair has local significance only on a
segment of the link between ATM nodes. It is translated on ATM nodes. When a
connection is released, the relevant VPI/VCI pair is released and put back into the
resource table for other connections to use.
ATM interfaces support permanent virtual circuits (PVCs).
Hierarchical Structure of The basic ATM protocol framework consists of three planes: user plane, control
ATM plane, and management plane.
The user plane and the control plane is each subdivided into four layers, namely,
physical layer, ATM layer, ATM adaptation layer (AAL), and upper layer, each
allowing further division.
The control plane mainly uses signaling protocols to establish and release
connections.
The management plane is subdivided into layer management and plane

management. The former manages every layer in each plane and has a layered
structure corresponding to other planes. The latter is responsible for system
management and communications between different planes.
The following figure presents the relationships between layers and planes:

128 CHAPTER 5: ATM CONFIGURATION
Figure 6 ATM protocol model
Management plane
Control plane User plane
Plane management
Hierarchic al management
Upper layer Upper layer
protocol protocol
ATM adaptation layer
ATM layer
Physical layer
The specific functions of various layers are as follows:
■ The physical layer mainly provides transmission channels for ATM cells, forming
continuous bit streams by adding the transmission overheads onto the cells
from the ATM layer. AT the same time, upon receiving continuous bit streams
from the physical media, the physical layer takes out the effective cells and
transfers them to the ATM layer.
■ The ATM layer, residing over the physical layer, implements cell-based
communication with peer layers by leveraging the service provided by the
physical layer. The ATM layer relies on the types of the physical media and the
specific implementation of the physical layer, as well as the types of services
being transmitted. What is input into the ATM layer are 48-byte payloads,
which are called segmentation and reassembly protocol data units (SAR-PDUs),
and what the ATM layer outputs are 53-byte cells, which are also transferred to
the physical layer for transmission. What is input into the ATM layer are 48-byte
payloads, which are called segmentation and reassembly protocol data units
(SAR-PDUs), and what the ATM layer outputs are 53-byte cells, which are also
transferred to the physical layer for transmission. The ATM layer is responsible
for generating a 5-bytes cell header, which will be inserted in front of a
payload. Other functions of the ATM layer include VPI/VCI transmission, cell
multiplexing/demultiplexing, and generic flow control.
■ As the interface between upper layer protocol and ATM Layer, ATM Adaptation
Layer (AAL) is responsible for forwarding the information between ATM Layer
and upper layer protocols. At present, four types of AAL have been put
forward -- AAL1, AAL2, AAL3/4 and AAL5, each of which supports some
special services. Most ATM equipment manufacturers’ products use AAL5 to
support the data communication service.
■ ATM upper layer protocols provide functions such as WAN interconnection,
voice interconnection, interconnection with existing Layer 3 protocols,
encapsulation mode, LAN emulation, multi-protocol over ATM, and classical IP.
Overview of IPoA, ATM interfaces support the IPoA, IPoEoA, PPPoA and PPPoEoA applications.
IPoEoA, PPPoA and
PPPoEoA Applications

Overview of IPoA, IPoEoA, PPPoA and PPPoEoA Applications 129
IPoA IP over AAL5 (IPoA) carries IP packets over AAL5. AAL5 provides the IP hosts on
the same network with the data link layer for communications. In addition, to
allow these hosts to communicate on the same ATM network, IP packets must be
tuned somewhat.
As the bearer network of IP services, ATM provides high speed point-to-point

connections which considerably improve the bandwidth performance of IP
network. On the other hand, ATM also provides excellent network performance
and perfect QoS.
IPoEoA IPoE over AAL5 (IPoEoA) adopts a three-layer architecture, with IP encapsulation at
the uppermost layer, IP over Ethernet (IPoE) in the middle, and IPoEoA at the
bottom.
When a device is connected to a remote access server at high speed to access an

external network, PVC over ATM is used because of the long distance. In this case,
it is required for the ATM port of the server to carry Ethernet packets, which is
known as IPoEoA.
For IPoEoA, the device can implement the following basic functions:
In the application of IPoEoA, one virtual Ethernet (VE) interface can be associated
with multiple PVCs.
PVCs associated with the same VE interface are interconnected at layer 2.
PPPoA PPP over AAL5 (PPPoA) means that AAL5 bears the PPP protocol packets: Its
essence is that ATM cells are used to encapsulate PPP packets, while IP or other
packets are encapsulated in PPP packets. In this way, AAL5 may be simply viewed
as the bearer layer of PPP packets. PPPoA is important because the communication
process of PPPoA is managed by PPP, and thus it can make use of PPP’s flexibility
and extensive applications. Before transmitting PPP packets over AAL5, users must
create a virtual template (VT) interface. For more information about virtual
template interfaces, refer to “VT and VA Interface” on page 534.
PPPoEoA PPPoE over AAL5 (PPPoEoA) carries PPPoE packets over AAL5. This is to
encapsulate Ethernet frames in ATM cells. In this case, a PVC to simulate all
functions of Ethernet. To allow AAL5 carry Ethernet frames, the interface
management module provides the virtual Ethernet (VE) interface. This VE interface
has Ethernet characteristics and can be dynamically created through configuration
commands. The following is the protocol stack for the VE interface:
ATM PVC at the bottom layer
Ethernet at the link layer
Protocols the same as those for the Ethernet interface at the network layer and
upper layers
For more information about the VE interface, please refer to “Introduction to VE”
on page 536.

Configuring ATM Complete these tasks to configure ATM:
Task Remarks
“Configuring ATM Interface” on page 130 Required
“Configuring an ATM Sub-Interface” “Configuring an ATM Required
on page 130 Sub-Interface” on page
130
“Checking Existence of
PVCs When Determining
the Protocol State of an
ATM P2P Sub-interface”
on page 131
“Configuring PVC” on page 131 “Configuring PVC Optional
parameters” on page 131
“Assigning a Transmission Optional
Priority to an ATM PVC”
on page 132
“Configuring PVC Service Optional
Map” on page 133
“Configuring an ATM Class” on page 133 Optional
“Configuring VP Policing” on page 136 Optional
“Configuring Applications over “Configuring IPoA” on Optional
ATM” on page 136 page 136
“Configuring IPoEoA” on Optional
page 137
“Configuring PPPoA” on Optional
page 137
“Configuring PPPoEoA” Optional
on page 138
Configuring ATM Depending on the actual networking environment and system requirements,
Interface sometimes it may be necessary to modify certain parameters of an ATM interface.
Note that although these parameters apply to the ATM main interface and
sub-interfaces at the same time, they must be modified in ATM main interface
view, except for the mtu command, which can be executed on a sub-interface.
Refer to “ATM and DSL Interface Configuration” on page 71 for more information
about ATM interface configuration.
Configuring an ATM
Sub-Interface
Configuring an ATM Follow these steps to configure an ATM sub-interface:

Sub-Interface
Create an ATM sub-interface interface atm Required
and enter its view interface-number.subnumber
By default, the type of a
[ p2mp | p2p ]
sub-interface is
point-to-multipoint (p2mp).

Configuring PVC 131

Set the MTU for the ATM mtu mtu-number Optional
sub-interface
1500 bytes by default
c CAUTION:
■ When creating an ATM sub-interface, the two keywords p2mp and p2p are
available. The format of the command is interface atm
interface-number.subnumber [ p2mp | p2p ].
■ When entering the view of an existing ATM sub-interface, the two keywords
are not available. The format of the command becomes interface atm
interface-number.subnumber.
Checking Existence of Follow these steps to check existence of PVCs when determining the protocol
PVCs When Determining state of an ATM P2P sub-interface:
the Protocol State of an
ATM P2P Sub-interface To do... Use the command... Remarks
Create an ATM sub-interface interface atm Required
and enter its view interface-number.subnumb
By default, the sub-interface is
er p2p
configured as
point-to-multipoint (p2mp).
Check existence of PVCs atm-link check Required
when determining the
By default, the protocol state of
protocol state of the ATM P2P
the ATM P2P sub-interface is
sub-interface
consistent with the state of the
physical interface.
Configuring PVC
Configuring PVC Follow these steps to configure a PVC:

parameters
Enter ATM interface view or interface atm -
ATM sub-interface view { interface-number |
interface-number.subnu
mber }
Create a PVC, and enter PVC pvc { pvc-name [ vpi/vci ] Required
view | vpi/vci }
By default, no PVC is created.
Set the AAL5 encapsulation encapsulation Optional
protocol type for specified PVC aal5-encap
By default, aal5snap
encapsulation is adopted.


Start transmission and oam frequency Optional
retransmission detection of frequency [ up up-count
By default, OAM F5 Loopback
operations, administration, and down down-count
cell transmission is disabled, but
maintenance (OAM) F5 retry-frequency
if an OAM F5 Loopback cell is
Loopback cells retry-frequency ]
received, it should be
responded.
By default, up-count is 3,
down-count is 5 and
retry-frequency is 1 second.
Set the parameters for AIS/RDI oam ais-rdi up Optional
alarm cell detection up-count down
By default, AIS/RDI alarm cell
down-count
detection is enabled, which
means the PVC goes down
when the number of AIS/RDI
alarm cells received reaches
down-count and goes up if no
AIS/RDI alarm cell is received in a
period specified by the up-count
argument (in seconds).
Set the PVC Set the PVC’s service cbr output-pcr Optional
service type service type to [ cdvt cdvt-value ]
By default, the service type of a
and the constant bit rate
PVC is UBR.
rate-related (CBR)
parameters The CDVT is 500Œºs by default.
Set the PVC’s service ubr output-pcr
service type to You can use these four
unspecified bit commands to set the service
rate (UBR), and type and the parameters
set the relevant concerning transmission rate.
rate parameters Note that a newly configured
service type overwrites the
Set the PVC’s service vbr-nrt
existing one.
service type to output-pcr output-scr
variable bit output-mbs
rate-non real
time (VBR-NRT),
and set the
relevant rate
parameters
Set the PVC’s service vbr-rt
service type to output-pcr output-scr
variable bit output-mbs
rate-real time
(VBR-RT), and
set the relevant
rate parameters
n For details about the configuration of the RADIUS scheme, refer to

“AAA/RADIUS/HWTACACS Configuration” on page 1751.
Assigning a You can assign transmission priority to ATM PVCs associated with the UBR, VBR-T,
Transmission Priority to or VBR-NRT service. At the time of bandwidth allocation, the PVC with higher
an ATM PVC priority has priority over other PVCs.
Follow these steps to assign a transmission priority to the ATM PVC:


Enter ATM interface view interface atm -
{ interface-number |
interface-number.subnumber
}
Create PVC and enter its view pvc { pvc-name [ vpi/vci ] | -
vpi/vci }
Assign a transmission priority transmit-priority value Optional
to the ATM PVC
By default, the priority value is
0 for the UBR service, 5 for
the VBR-NRT service and 8 for
the VBR-RT.
Configuring PVC Service PVC service map allows different PVCs from the same PVC-Group to carry IP
Map packets of different priorities.
Follow these steps to configure PVC service map:

}
Create PVC, and enter its view pvc { pvc-name [ vpi/vci ] | -
vpi/vci }
Quit to ATM interface view quit -
Create a PVC-Group and pvc-group { pvc-name Required
enter Group view [ vpi/vci ] | vpi/vci }
The PVC specified by the
pvc-name or vpi/vci argument
must be created first.
Add a PVC to the PVC-Group pvc { pvc-name [ vpi/vci ] | Optional
vpi/vci }
Set the priority of the IP ip-precedence { pvc-name Optional
packets carried on PVC [ vpi/vci ] | vpi/vci } { min
[ max ] | default }
n ■ A primary PVC refers to the one based on which a PVC-group is created on an

ATM interface
■ A secondary PVC refers to a PVC created in a PVC-group.
Configuring an ATM An ATM class facilitates you in ATM configuration. Configurations of PVC MAP,
Class encapsulation type, OAM loopback, and service category and can be implemented
via an ATM-Class. First create an ATM class and set the parameters needed, and
then call the ATM class in PVC view or ATM interface view.
Follow these steps to configure an ATM class:


Create an ATM class and enter ATM class view atm class Required
atm-class-name
Specify ATM AAL5 encapsulation type for the encapsulation Optional
PVC aal5-encap
By default,
aal5snap
encapsulation is
adopted.
Start transmission of OAM F5 Loopback cells or oam frequency Optional
retransmission check of OAM F5 Loopback frequency [ up
By default, OAM F5
up-count down
Loopback cell
down-count
transmission is
retry-frequency
disabled, but if an
retry-frequency ]
OAM F5 Loopback
cell is received, it
should be
responded.
By default,
up-count is 3,
down-count is 5
and retry-frequency
is 1 second.
Set the Set the PVC’s service cbr output-pcr Optional
PVC’s service type
By default, the
service to constant
service type of a
type and bit rate (CBR)
PVC is UBR.
rate-rela
Set the PVC’s service ubr output-pcr
ted You can use these
service type
paramet four commands to
to
ers set the service type
unspecified
and the parameters
bit rate
concerning
(UBR), and
transmission rate.
set the
Note that a newly
relevant rate
configured service
parameters
type overwrites the
Set the PVC’s service vbr-nrt output-pcr output-scr existing one.
service type output-mbs
to variable
bit rate-non
real time
(VBR-NRT),
and set the
relevant rate
parameters
Set the PVC’s service vbr-rt output-pcr output-scr
service type output-mbs
to variable
bit rate-real
time
(VBR-RT),
and set the
relevant rate
parameters


Configur Configure map ip inarp [ minutes ] [ broadcast ] Required
e the IPoA and
By default,
service enable
mapping is not
type inverse
configured. When a
(use address
mapping is
different resolution
configured,
comman (InARP) for
pseudo-broadcast is
ds the PVC
not supported by
accordin
default.
g to
service Before configuring
types) InARP, make sure
the aal5snap
encapsulation is
used. Though
InARP is also be
supported when
using aal5mux or
aal5nlpid
encapsulation, the
system will prompt
a message
indicating a failure
when this ATM is
configured and
used on PVC.
Establish PPPoA mapping for the PVC map ppp Required
virtual-template
vt-number
Establish IPoEoA or PPPoEoA mapping map bridge Required
for the PVC virtual-ethernet
interface-number
Enter Enter ATM interface view interface atm Required
ATM { interface-number |
interface interface-number.subn
view or umber }
PVC
Enter PVC view interface atm Required
view
interface-number.subn
umber }
pvc { pvc-name
[ vpi/vci ] | vpi/vci }
Enable the ATM class on the interface or PVC atm-class Required
atm-class-name
As for the configurations performed to a PVC, note that:
■ The priorities of the same configurations performed to a PVC descend in this

order: the configuration directly performed to the PVC, the configuration
performed to the ATM class applied to the PVC, and the configuration
performed to the ATM class applied to the ATM interface.
■ For different configurations that conflict with each other, their priorities
descend in this order: the configuration directly performed to the PVC, the
configuration performed to the ATM class applied to the PVC, and the
configuration performed to the ATM class applied to the ATM interface.

■ All the configurations that are directly performed to the PVC, performed to the
ATM class applied to the PVC, and performed to the ATM class applied to the
ATM interface take effect if they do not conflict.
■ For different configurations performed to a PVC, the ATM class applied to the
PVC, and the ATM class applies to the ATM interface, if the configurations
conflict with each other, those apply first take effect, and conflict prompt
appears when the rest are performed.
■ When an ATM class is applied to a PVC, no message is prompted no matter
whether or not the ATM class is successfully applied.
■ Error messages are prompted when configurations performed to a PVC are
invalid.
Configuring VP VP policing is used to set the sustainable rate of a virtual path identifier (VPI).
Policing When applying VP policing, the parameters of PVC are still valid. Only when the
parameters of PVC and VP policing are satisfied, will the packets be transmitted or
received. In calculating the traffic, the LLC/SNAP, MUX and NLPID headers are
included, but the ATM cell head is not included.
Follow these steps to configure VP policing:

Enter ATM interface view interface atm interface-number -
Set the parameters of VP pvp limit vpi output-scr Required
policing
Configuring
Applications over ATM
Configuring IPoA Follow these steps to configure IPoA:

Enter ATM interface interface atm -
view { interface-number |
interface-number.subinterface-nu
mber }
Create PVC, and enter pvc { pvc-name [ vpi/vci ] | -
PVC view vpi/vci }
Configure IPoA map ip { ip-address [ ip-mask ] | Required
mapping for the PVC, default | inarp [ minutes ] }
By default, no mapping is
and enable PVC to carry [ broadcast ]
configured. If a mapping is
IP packets
configured, pseudo-broadcast is
not supported by default.
Before configuring InARP, make
sure that aal5snap encapsulation
is used. InARP is not supported
when aal5mux or aal5nlpid
encapsulations is adopted.

Configuring Applications over ATM 137
Note that a PVC cannot carry multiple protocols when the ATM AAL5 is
encapsulated with aal5mux. Once IPoA is configured on the PVC, other protocols
such as IPoEoA, PPPoA and PPPoEoA are not supported.
Configuring IPoEoA Follow these steps to enable IPoEoA on PVC:

Create a virtual Ethernet (VE) interface virtual-ethernet Required
interface interface-number
The IP address has to be
configured on VE interface (It
is invalid to configure it on
ATM interface)
}
Create PVC, and enter its view pvc { pvc-name [ vpi/vci ] | Required
vpi/vci }
Configure IPoEoA mapping map bridge Required
on PVC virtual-ethernet
interface-number
Configuring PPPoA When two routers are connected using DSL interfaces through a dial-up
connection, configure them as PPPoA server and client respectively. The two are
different in that, with the PPPoE server, you should configure an address pool to
allocate IP address for the remote node; with the PPPoE client, you should
configure address negotiation to accept the IP address allocated by the server end.
For relevant information, refer to “PPP and MP Configuration” on page 363
The following configurations enable the PVC to carry PPP and configure a PPP
mapping for the PVC.
encapsulated with aal5mux. Once PPPoA is configured on the PVC, other
protocols such as IPoA, IPoEoA, and PPPoEoA are not supported.
Follow these steps to configure PPPoA:

Create a VT interface interface Required
virtual-template
You must configure PPP
vt-number
authentication and IP address
on the VT interface (the IP
address is invalid if configured
on the ATM interface).


Set the PPP authentication mode Refer to “PPP and MP Required
and IP address; with the PPPoE Configuration” on page
server, an address pool should 363.
be configured to allocate IP
address for the peer end; with
the PPPoE client, address
negotiation should be
configured to accept the IP
address allocated by the server
end
interface-number.subnumb
er }
Create PVC, and enter PVC view pvc { pvc-name [ vpi/vci ] | Required
vpi/vci }
Configure PPPoA mapping for map ppp Required
the PVC virtual-template
vt-number
n As for the next hop and the outbound interface, only the former is required when
you configure a static route on a virtual-template interface. If you want to specify
the outbound interface as well, make sure the physical interface bound to the
virtual-template is valid.
Configuring PPPoEoA PPPoE adopts the Client/Server model. It encapsulates PPP packets into Ethernet
frames and provides point-to-point connection on Ethernet. The following
configurations enable the PVC to carry PPPoE and configure a PPPoE mapping for
the PVC.
encapsulated with aal5mux. Once PPPoEoA is configured on the PVC, other
protocols such as IPoA, IPoEoA and PPPoA are not supported.
Follow these steps to configure PPPoEoA:

Create a VT interface interface virtual-template Required
vt-number
You must configure PPP
authentication and IP address
on the VT interface (the IP
address is invalid if configured
on the ATM interface).

Displaying and Maintaining ATM 139

Set the PPP authentication Refer to “PPP and MP Required
mode and IP address; with the Configuration” on page 363.
PPPoE server, an address pool
should be configured to
allocate IP address for the
peer end; with the PPPoE
client, address negotiation
should be configured to
accept the IP address
allocated by the server end.
Create a VE interface interface virtual-ethernet Required
interface-number
Configure PPPoE parameters Refer to “PPP and MP Required
on VE interface (the Configuration” on page 363.
configuration differs when
with a PPPoE server and when
with a PPPoE client)
}
Create PVC, and enter PVC pvc { pvc-name [ vpi/vci ] | Required
view vpi/vci }
Create PPPoEoA mapping for map bridge Required
PVC virtual-ethernet
The interface-number
interface-number
argument refers to the VE
interface created in the above
steps.
virtual-template is valid.
Displaying and
Maintaining ATM To do... Use the command... Remarks
Show the relevant information display atm interface [ atm Available in any view
of ATM interface interface-number ]
Show the relevant information display atm pvc-info Available in any view
of the PVC [ interface interface-type
interface-number [ pvc
{ pvc-name [ vpi/vci ] | vpi/vci } ] ]
Show the information of the display atm map-info Available in any view
PVC mapping [ interface interface-type
Display PVC-Group information display atm pvc-group Available in any view
[ interface interface-type
Show the relevant information display atm class Available in any view
of the ATM-Class [ atm-class-name ]


Send OAM cells on the specified oamping interface atm Available in ATM
PVC on the interface to test interface-number pvc { pvc-name interface view
connectivity of the link | vpi/vci } [ number timeout ]
depending on whether response
is returned before the specified
timeout time.
Shut down the current physical shutdown Available in ATM
ATM interface interface view
ATM Configuration
Examples
n In the following examples, the network device, the digital subscriber line access
multiplexer (DSLAM) and its configuration command sequence are MA 5100
multi-business access device and the corresponding command sequence under its
configuration environment. ADSL router is configured according to the actual
selected devices in the actual networking environment. For complete details about
configuration commands, please refer to the corresponding command manuals.
With regard to practical networking, the network devices might be different from
the assumed devices in terms of networking capacity and configuration command
format. This situation is subject to exist without notice.
IPoA Configuration Network requirements

Example As shown in Figure 7, router A, B and C are connected to ATM network for
intercommunication. The requirements are:
The IP addresses of their ATM interfaces of the three routers are 202.38.160.1/24,
202.38.160.2/24 and 202.38.160.3/24 respectively;
In ATM network, the VPI/VCI of router A is 0/40 and 0/41, connecting to router B
and router C respectively. The VPI/VCI of router B is 0/50 and 0/51, connecting to
router A and C respectively. The VPI/VCI of router C is 0/60 and 0/61, connected
with router A and B respectively;
All the PVCs on ATM interfaces of the three routers work in IPoA application
mode.

Network diagram
Figure 7 Network diagram for IPoA configuration
Router B
ATM1/0
202 .38 .160 .2/24
VPI/VCI:
To Router A:0/50
To Router C:0/51
Router A ATM network
ATM network
ATM1/0
202 .38 .160 .1/24
VPI/VCI:
To Router B:0/40 Router C
To Router C:0/41
ATM1/0
202 .38.160.3/24
VPI/VCI:
To Router A:0/60
To Router B:0/61
# Enter the ATM interface, and configure an IP address for it.
[RouterA] interface atm 1/0
[RouterA-Atm1/0] ip address 202.38.160.1 255.255.255.0
# Establish a PVC, running IP.
[RouterA-Atm1/0] pvc to_b 0/40

[RouterA-atm-pvc-Atm1/0-0/40-to_b] map ip 202.38.160.2
[RouterA-atm-pvc-Atm1/0-0/40-to_b] quit
[RouterA-Atm1/0] pvc to_c 0/41
[RouterA-atm-pvc-Atm1/0-0/41-to_c] map ip 202.38.160.3
[RouterB] interface atm 1/0
[RouterB-Atm1/0] ip address 202.38.160.2 255.255.255.0
[RouterB-Atm1/0] pvc to_a 0/50

[RouterB-atm-pvc-Atm1/0-0/50-to_a] map ip 202.38.160.1
[RouterB-atm-pvc-Atm1/0-0/50-to_a] quit
[RouterB-Atm1/0] pvc to_c 0/51
[RouterB-atm-pvc-Atm1/0-0/51-to_c] map ip 202.38.160.3
3 Configure Router C

<RouterC> system-view
[RouterC] interface atm 1/0
[RouterC-Atm1/0] ip address 202.38.160.3 255.255.255.0
[RouterC-Atm1/0] pvc to_a 0/60

[RouterC-atm-pvc-Atm1/0-0/60-to_a] map ip 202.38.160.1
[RouterC-atm-pvc-Atm1/0-0/60-to_a] quit
[RouterC-Atm1/0] pvc to_b 0/61
[RouterC-atm-pvc-Atm1/0-0/61-to_b] map ip 202.38.160.2
IPoEoA Configuration Network requirements

Example As shown in Figure 8, each of the hosts in the two Ethernets is respectively
connected to the ATM network through an ADSL Router, and they communicate
with router C via DSLAM. The requirements are:
■ The IP address of the VE interface of router C is 202.38.160.1;
■ The VPI/VCI value of two PVCs connecting route C and DSLAM are 0/60 and
0/61, pointing to Router A and Router B respectively.
■ Both the WAN port of router C and the DSL interface of ADSL Router adopt
IPoEoA.
Network diagram
Figure 8 Network diagram for IPoEoA configuration
ADSL Router A
Ethernet
Host A
Router A VE 1
DSLAM 202 .38.160.1/24
Host B
Router C
ATM1/0.1
VPI/VCI:
To Router A:0/60
Router B To Router B:0/61
E the rnet
Host C
ADSL Router B
Host D
Configure Router C:
# Create a VE interface and configure an IP address for it.
[RouterC] interface virtual-ethernet 1
[RouterC-Virtual-Ethernet1] ip address 202.38.160.1 255.255.255.0
[RouterC-Virtual-Ethernet1] quit
# Create a PVC and specify it to support IPoE.

[RouterC] interface atm 1/0.1

[RouterC-Atm1/0.1] pvc to_adsl_a 0/60
[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] map bridge virtual-ethernet 1
[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] quit
[RouterC-Atm1/0.1] pvc to_adsl_b 0/61
[RouterC-atm-pvc-Atm1/0.1-0/61-to_adsl_b] map bridge virtual-ethernet 1
PPPoA Configuration Network requirements

Example As shown in Figure 9, two hosts dial into ATM network each through an ADSL
Router, and communicate with Router C through DSLAM. The requirements are:
■ To create VT for multi-user on Router C, and configure PPP map on VT.
The VPI/VCI value of two PVCs connecting Route C and DSLAM are 0/60 and 0/61,
pointing to ADSL Router A and ADSL Router B respectively.
■ Both the WAN port of Router C and the DSL interfaces of the two ADSL Router
adopt PPPoA. The authentication mode of ADSL Router is PAP. The IP addresses
of the two ADSL Routers are assigned by Router C.
Network diagram
Figure 9 Network diagram for PPPoA configuration
ADSL Router A
ATM1/0.1
Host A Router A VPI/VCI:
To Router A:0 /60
To Router B:0 /61
Router C
VT10
DSLAM 202 .38 .160 .1 /24
Router B VT11
202 .38 .161 .1 /24
Host B ADSL Router B
1 Configure Router C (PPPoA Server)
# Create user for PPP authentication, and establish local IP address pool.
[RouterC] local-user user1
[RouterC-luser-user1] service-type ppp
[RouterC-luser-user1] password simple pwd1
[RouterC-luser-user1] quit
[RouterC] domain system
[RouterC-isp-system] authentication ppp local
[RouterC-isp-system] ip pool 1 202.38.162.1 202.38.162.100
[RouterC-isp-system] quit

# Create VT interface, configure PAP authentication and IP address negotiation,

and allocate an IP address for the remote end from the IP address pool.
[RouterC] interface virtual-template 10

[RouterC-Virtual-Template10] ip address 202.38.160.1 255.255.255.0
[RouterC-Virtual-Template10] ppp authentication-mode pap
[RouterC-Virtual-Template10] remote address pool 1
[RouterC-Virtual-Template10] quit
[RouterC-Virtual-Template11] remote address pool 1
# Create a PVC, and specify it to carry PPP.

[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] map ppp virtual-template 10
[RouterC-atm-pvc-Atm1/0.1-0/61-to_adsl_b] map ppp virtual-template 11
2 Configure ADSL Router A (PPPoA Client)
# Create VT interface, and configure PAP authentication and IP address

negotiation.
[RouterA] interface Virtual-Template 0
[RouterA-Virtual-Template0] ppp pap local-user user1 password simple pwd1
[RouterA-Virtual-Template0] ip address ppp-negotiate
[RouterA-Virtual-Template0] quit
# Create PVC, and specify it to run PPP.

[RouterA-Atm1/0] pvc pppoa 0/37
[RouterA-atm-pvc-Atm1/0-0/37-pppoa] map ppp virtual-template 0
The configuration of ADSL Router B is similar to that of Router A.
c CAUTION: If the client cancels the IP address it has received through address
negotiation, or the client is configured with a fixed IP address, the communication
between the server and the client will fail. In this case, you need to shut down the
ATM interface first, and delete the IP address pool on the server.
PPPoEoA Server Network requirements

Configuration Example As shown in Figure 10, each host inside Ethernet dials into ATM network through
an ADSL router, and communicates with the router through DSLAM. The
requirements are:
The IP addresses of the VT interface of router C are 202.38.160.1 and

202.38.161.1.
The VPI/VCI addresses of two PVCs connecting router C with DSLAM are 0/60 and
0/61, pointing to ADSL Router A and ADSL Router B respectively.

Both the WAN port of router C and the DSL interface of ADSL Router adopt
PPPoEoA. Each host within the two Ethernets uses pre-installed PPPoE Client
program to make interactive PAP authentication with routers, and obtains IP
address from the router.
Network diagram
Figure 10 Network diagram for PPPoEoA server configuration
ADSL Router
Ethern et
Host A
ATM1/0.1
Router A VPI/VCI:
To Router A:0/60
Host B To Router B:0/61
Router C
VT10
DSLAM
Router B 202 .38 .160 .1/24
VT11
E the rnet
Host C 202 .38 .161 .1/24
ADSL Router
Host D
Configure Router C:
# Configure the users in the domain to use PPP authentication scheme, and create
local IP address pool.
[RouterC]domain system
[RouterC-isp-system] ip pool 1 202.38.162.1 202.38.162.100
[RouterC-isp-system] quit
# Create the VT interface to encapsulate PPP protocol and configure PAP

authentication parameters.


# Create the VE interface to encapsulate PPP protocol.

[RouterC-Virtual-Ethernet1] pppoe-server bind virtual-template 10
[RouterC-Virtual-Ethernet2] pppoe-server bind virtual-template 11
# Establish a PVC and specify it to carry PPPoE.

[RouterC-atm-pvc-Atm1/0.1-0/60-to_adsl_a] map bridge virtual-ethernet 1
[RouterC-atm-pvc-Atm1/0.1-0/61-to_adsl_b] map bridge virtual-ethernet 2
n For details about configuring a RADIUS scheme, refer to

“AAA/RADIUS/HWTACACS Configuration” on page 1751.
PPPoEoA Client Network requirements

Configuration Example As shown in Figure 11, the Ethernet interface IP address of Router A serves as the
gateway of all PCs in LAN. Router A is directly connected to the ADSL accessing
end of public network via the ADSL card to serve as the client of PPPoEoA (Atm1/0
is the port number of the ADSL card). The Server, PPPoEoA authentication server
of public network, is used to authenticate user information via CHAP.
Network diagram
Figure 11 Network diagram for ADSL PPPoEoA Client
ATM1/0
ATM network
Router A Server
Hub
Host A Host B
1 Configure Router A:
# Configure user name and password
[RouterA] local-user sysname
[RouterA-luser-sysname] password simple hello
[RouterA-luser-sysname] service-type ppp
[RouterA-luser-sysname] quit
# Configure dialing access control list:

[RouterA] dialer-rule 10 ip permit
# Create dialer port and configure the dial-up and PPP authentication:
[RouterA] interface dialer0

[RouterA-Dialer0] link-protocol ppp
[RouterA-Dialer0] ppp chap password hello
[RouterA-Dialer0] ppp chap user user1
[RouterA-Dialer0] ip address ppp-negotiate
[RouterA-Dialer0] dialer user ABC
[RouterA-Dialer0] dialer-group 10
[RouterA-Dialer0] dialer bundle 12
[RouterA-Dialer0] quit
# Create a VE interface:
[RouterA] interface virtual-ethernet 2

[RouterA-Virtual-Ethernet2] quit
# Configure the ATM interface of ADSL card:
[RouterA] interface atm1/0

[RouterA-Atm1/0] pvc 0/32
[RouterA-atm-pvc-Atm1/0-0/32] map bridge virtual-ethernet 2
[RouterA-atm-pvc-Atm1/0-0/32] quit
# Configure VE port:
[RouterA] interface virtual-ethernet 2

[RouterA-Virtual-Ethernet2] pppoe-client dial-bundle-number 12
# Configure the default route:
[RouterA] ip route-static 0.0.0.0 0.0.0.0 Dialer 0

2 If the PPPoEoA Server is of the same type of router, its PPPoEoA can be configured
as follow:
# Configure user features.
[Sysname] local-user user1
[Sysname-luser-user1] password simple hello
[Sysname-luser-user1] service-type ppp
# Create a virtual-template, set the authentication mode to CHAP, and configure

the IP address.
[Sysname] interface Virtual-Template 0

[Sysname-Virtual-Template0] ppp authentication-mode chap
[Sysname-Virtual-Template0] ppp chap user Sysname
[Sysname-Virtual-Template0] ip address 10.1.1.1 255.255.0.0
[Sysname-Virtual-Template0] remote address pool 80
[Sysname-Virtual-Template0] quit
# Configure the users in the domain to use the local authentication scheme, and
create a local IP address pool.

[Sysname] domain system

[Sysname-isp-system] scheme local
[Sysname-isp-system] ip pool 80 10.1.1.2 10.1.1.100
# Configure a VE interface.
[Sysname] interface virtual-ethernet 1
# Enable PPPoE Server on the VT specified on the virtual Ethernet interface.
[Sysname-Virtual-Ethernet1] pppoe-server bind virtual-template 0

[Sysname-Virtual-Ethernet1] mac-address 0022-0022-00C1
[Sysname-Virtual-Ethernet1] quit
# Configure ATM interface 1/0.
[Sysname] interface atm1/0

[Sysname-Atm1/0] pvc 0/32
[Sysname-atm-pvc-Atm1/0-0/32] map bridge virtual-ethernet 1
After the above-mentioned configuration, the link layer is able to work normally,
and the PCs can communicate with the server via the ATM upper layer protocols.
ATM PVC Transmit Network requirements

Priority Configuration As shown in Figure 12, you need to create PVC 1 and PVC 2 on the same ATM
Example 155 Mbps interface, each assigned 100 Mbps of bandwidth and associated with
the UBR service. Set the transmission priority of PVC 1 to 1 and that of PVC 2 to 3.
Let Router A distribute equal amount of traffic to Router B on two PVCs and
observe the statistics about received/sent/dropped packets.
Network diagram
Figure 12 Network diagram for ATM PVC priority configuration
Router A PVC1 Router B
ATM1/0 ATM1/0
202.38.160.1/24 PVC2 202 .38 .160 .2 /24
Configure Router A
# Configure the ATM interface.
[RouterA-Atm1/0] ip address 202.38.160.1 255.255.255.0
# Create two PVCs and assign them different transmission priority values.
[RouterA-Atm1/0] pvc 1 0/33

[RouterA-atm-pvc-Atm1/0-0/33-1] map ip 202.38.160.2
[RouterA-atm-pvc-Atm1/0-0/33-1] service ubr 100000
[RouterA-atm-pvc-Atm1/0-0/33-1] transmit-priority 1

[RouterA-atm-pvc-Atm1/0-0/33-1] quit
[RouterA-Atm1/0] pvc 2 0/32
[RouterA-atm-pvc-Atm1/0-0/32-2] map ip 202.38.160.3
[RouterA-atm-pvc-Atm1/0-0/32-2] service ubr 100000
[RouterA-atm-pvc-Atm1/0-0/33-1] transmit-priority 3
After two equal traffics that exceed the ATM bandwidth are sent to Router B, you
can use the display atm pvc-info interface atm 1/0/0 pvc command on Router
B to view statistical results for each PVC (you can make several tests and observe
the average statistical value). You can see that the PVC with higher priority
receives more packets than that with lower priority. In other words, the PVC with
the highest priority takes preference in getting bandwidth and other PVCs (if there
are many and with different priority values), regardless of their priority values, are
treated equally in terms of bandwidth allocation
Troubleshooting ATM
Link State Error in IPoA Symptom:

Application When IPoA is used, the link state is down.
Solution:
Make sure that the optical fiber is plugged in correctly.
Make sure that the local IP address has been configured.
Make sure that the PVC is successful created and communication between cards is
normal.
Link Report Error in Symptom:

PPPoA Application When PPPoA is used, the link does not report ‘UP’.
Solution:
Refer to “Link State Error in IPoA Application” on page 149.
Ping Failure Symptom:

The physical layer of the interfaces and the line protocol are both UP, but when
tested with the ping command, the two ends are mutually unreachable.
Solution:
If IPOA is used, make sure that the IP protocol address mapping is configured
correctly. If the interfaces of two routers are connected back-to-back, the local
PVC mapped to the remote IP must have the same VPI/VCI value as the remote
PVC mapped to the local IP. In addition, the IP addresses of the two ends must also
be in the same network segment.
If two routers are connected back-to-back, make sure that at least one of
interfaces uses internal transmission clock (master). Or, if the routers are
connected to ATM network, the transmission clock should be set to line clock.

Check the ATM interfaces of the two sides to make sure that they are of the same
type, for example, both are multimode fiber interfaces or both are single mode
fiber interfaces, or both are multimode fiber interfaces but connected using single
mode. If a multimode fiber interface and a single mode fiber interface are directly
connected, they can communicate in most cases, but sometimes with frequent
packet dropping and CRC errors.
If the two ends are PPPoA, make sure that their IP addresses (should be in the
same network segment) and authentication are correctly configured.
If, according to the ping command, small packets can pass but big packets
cannot, make sure that the mtu configurations of the two router interfaces are
the same.
ATM Interface State Symptom:

Error The interface state of ATM is DOWN
Solution:
Make sure that the optical fibers are correctly plugged to ATM interface. There
should be two optical fibers, one for receiving information and one for sending
information. The two are not exchangeable. If they are wrongly plugged, the
interface state of ATM cannot be UP.
If two routers are connected back-to-back, check if neither of the two ATM
interfaces enables internal transmission clock. By default, routers use line clock. If
two routers are connected back-to-back, one of them should be configured as
internal transmission lock with the clock master command.
PVC State is Down while Symptom:

ATM Interface State is The interface state of ATM is UP, but the PVC state is DOWN.
Up
Solution:
Please check if this fault results from enabling OAM F5 Loopback cell transmission
and retransmission detection. When two ATM devices are connected, the VPI/VCI
value of the PVCs on the two devices must be the same. Provided that OAM F5
cell transmission and retransmission detection is enabled, and the VPI/VCI value of
the remote node (connected directly with the local node) is not the same as the
local node, the local PVC state cannot change into UP.
Ping Failure after PPPoA Symptom:

Configuration The PVC state is UP, but after applications like IPoA are configured, the remote
node cannot be successfully pinged.
Solution:
Make sure that the remote node supports the same application as configured on
the local node. For example, if the local node uses PPPoA, the remote node should
also use PPPoA.
If the remote node supports the same application configured on local node, make
sure that the two sides use the same type of AAL5 encapsulation protocol. For

example, if one side uses SNAP whereas the other uses MUX, they cannot
communicate. You can enable the packet debugging function of ATM to get some
clues.
Packet Loss and CRC Symptom:

Errors and Changes of Two routers are connected back-to-back, and a ping between them is successful,
Interface State but sometimes there are large amount of packets lost and frequent CRC errors, or
the interface state alternates between UP and DOWN.
Solution:
Check the ATM interfaces of the two nodes to see if their types are the same,
namely, both are multimode fiber interface or both are single mode fiber interface.
If their types are different, you should change one of them. In most cases, when a
multimode fiber interface and a single mode fiber interface are directly connected,
they can communicate, but sometimes with the above-mentioned faults.
Generally speaking, you can successfully locate most problems mentioned and not
mentioned above if you enable all the ATM debugging functions during the
process.


DCC CONFIGURATION
6
When configuring DCC, go to these sections for information you are interested in:
■ “Introduction to DCC” on page 153
■ “Displaying and Maintaining DCC” on page 179
■ “DCC Configuration Example” on page 179
Introduction to DCC This section covers these topics:

■ “Approaches to DCC” on page 153
■ “DCC Features” on page 156
■ “Preparing for DCC Configuration” on page 156
Overview Dial control center (DCC) is a routing technology adopted when routers
interconnect through a public switched network like a public switched telephone
network (PSTN) or an integrated services digital network (ISDN). It can provide the
dial-on-demand service where any two routers dial to set up connection when
data needs transferring instead of setting up connection before that. When the
link becomes idle, DCC automatically disconnects it.
Under certain circumstances, connections between routers are instantly

established whenever there is data to be transferred, so data transfer is
time-independent, bursty, and small-sized. DCC is a flexible, economical and
efficient solution for such applications. In DCC, backup mechanisms are available
to guarantee communications. In case a primary line fails, DCC switch traffic over
to a secondary line to ensure ongoing services.
At present, Frame Relay (FR) is widely applied. Usually, users access Frame Relay
networks through leased lines. To reduce the cost and speed up accesses, Frame
Relay over ISDN (FRoI) technology can be used instead. Meanwhile, ISDN can act
as a backup to FR access.
Approaches to DCC Two approaches are available to DCC: circular DCC (“C-DCC” on page 154), and
resource-shared DCC (“RS-DCC” on page 155). They are suitable for different
applications. In practice, the two parties in a call do not necessarily adopt the same
approach.
n DCC terms:

154 CHAPTER 6: DCC CONFIGURATION
■ Physical interface: An interface that physically exists. Examples are serial, BRI,
and asynchronous interfaces.
■ Dialer interface: A logical interface created for configuring DCC parameters. A
physical interface inherits the DCC configuration of a dialer interface if it is
assigned to the dialer interface.
■ Dial interface: Any interface used for dialup connection. It can be a dialer
interface, a physical interface assigned to a dialer interface, or a physical
interface directly configured with DCC parameters.
C-DCC
1 Features of C-DCC
■ A logical dial (dialer) interface can contain multiple physical interfaces, but a
physical interface can be assigned to only one dialer interface. That is, a
physical interface can only provide one type of dial service.
■ You may assign a physical interface to a dialer interface to inherit DCC
parameters by assigning it to a dialer circular group, or directly configure DCC
parameters on the physical interface.
■ All the physical interfaces in a dialer circular group inherit the attributes of the
same dialer interface.
■ You may associate a dialer interface with multiple call destination addresses by
configuring the dialer route command or with a single call destination address
by configuring the dialer number command.
C-DCC is powerful and has broad applications. However, it lacks flexibility and
extensibility.
For example, on an ISDN BRI interface, all the B channels inherit its configuration
in the C-DCC approach. The static binding between call destination address
settings and physical interface configurations will restrict the use of C-DCC, as
dialer routes are becoming increasingly complicated as a result of network growth
and support to more protocols.
2 Association of physical interfaces and dialer interfaces in C-DCC
Figure 13 Association between physical interfaces and dialer interfaces
Physical Dialer interface

interface
S2 /0
dialer number
Dialer 1 Destination A
BRI1/0
S2 /1
dialer route
BRI1/1 Dialer 2
Destination B
S2 /2
dialer route
Async5/0 Destination C

Introduction to DCC 155
As shown in the above figure, a physical interface can be assigned to only one
dialer interface, but each dialer interface can contain multiple physical interfaces
and be mapped to multiple destination addresses. In addition, a physical interface
does not necessarily belong to any dialer interface. You may directly map it to one
or multiple destination addresses.
In the figure, physical interfaces Serial 2/1, BRI 1/1 and Serial 2/2 are assigned to
Dialer2, where mappings between dial strings and destination addresses are
configured.
RS-DCC
1 Different from C-DCC, RS-DCC separates logical configuration from physical
configuration. Thus, it is simpler and more flexible. RS-DCC delivers these features:
■ Physical interface configuration and logical configuration for calls are separate.
They are associated dynamically when triggered by calls. This allows a physical
interface to provide services for different dial applications.
■ Associations between dialer interfaces and call destination address are
one-to-one. You may configure them with the dialer number command.
■ Each dialer interface can contain multiple physical interfaces, and each physical
interface can be assigned to multiple dialer interfaces.
■ Dial attributes, such as dialer interface, dialer bundle, and physical interface,
are described by an RS-DCC set. All the calls destined to the same network use
the same RS-DCC set.
■ RS-DCC parameters cannot be directly configured on physical interfaces. A
physical interface can participate in RS-DCC only after it is assigned to a dialer
interface.
2 Association of physical interfaces, dialer bundles and dialer interfaces in RS-DCC
Figure 14 Association of physical interfaces, dialer bundles and dialer interfaces
Physical
interface Dialer interface
Dialer
bundle3 S 2/0
dialer number
Dialer1 Destination A
BRI1/0
Dialer
bundle2 S 2/1
dialer number Destination B

BRI1/1 Dialer2
S 2/2
Dialer
bundle1
Async5 /0
dialer number
Dialer3 Destination C
As shown in the above figure, a physical interface can be assigned to multiple

dialer bundles and serve for multiple dialer interfaces, but each dialer interface can

use only one dialer bundle and configured with one dial string. The physical
interfaces in a dialer bundle can be assigned different priorities.
In the figure, interface Dialer2 uses Dialer bundle 2 that contains physical
interfaces BRI 1/0, BRI 1/1 and Serial 2/1. Suppose BRI 1/0 is assigned the priority
of 100, BRI 1/1 the priority of 50, and Serial 2/1 the priority of 75. Since BRI 1/0
has a higher priority over BRI 1/1 and Serial 2/1, it will be preferred first when
Dialer2 wants to place a call.
DCC Features This section covers these topics:

■ “Basic DCC features” on page 156
■ “Callback through DCC” on page 156
Basic DCC features

The following are basic DCC features:
■ Support a wide range of dial interfaces, such as synchronous/asynchronous
serial interface, AUX port, ISDN BRI or PRI interface, and AM interface to
accommodate to different networking requirements.
■ Support link layer protocols such as PPP and FR on dial interfaces (physical or
dialer).
■ Support IP on dial interfaces.
■ Support dynamic routing protocols such as RIP and OSPF on dial interfaces.
■ Provide flexible dial interface backup
■ Allow you to manage different modems at the user interface.
Callback through DCC

In callback, the called party originates a return call to the calling party. The calling
party is the client, and the called party is the server. The callback client originates a
call first, and the callback server decides whether to originate a return call. If a
callback is needed, the server will immediately disconnect and originate a return
call.
DCC callback brings these benefits:
■ Enhance security: When placing a return call, the server dials the calling
number configured at the local end. This prevents the insecurity resulted from
user name and password compromise.
■ Change the charge bearer. This is useful for saving cost in the case that the call
rates in two directions are different.
■ Consolidate call charge bills to facilitate settlement.
At present, PPP callback and ISDN caller identification callback features are
available. The PPP callback conforms to RFC1570 specifications and can be used
where both client and server own fixed network addresses, or the client accepts
dynamic network address assignment.
Preparing for DCC When preparing for DCC configuration, you need to do the following:
Configuration ■ “Identifying the topology of DCC application” on page 157

■ “Making basic configuration” on page 157

■ “Configuring DCC parameters” on page 157
Identifying the topology of DCC application

You need to identify:
■ Which routers will provide DCC and how they are related to each other.
■ Which interfaces on the routers will provide DCC, and which roles they will be
playing.
■ Which transmission medium will be used, PSTN or ISDN.
Making basic configuration

Before configuring DCC on an interface, do the following:
■ Identify interface type (synchronous/asynchronous serial, ISDN BRI or PRI, AM,
or AUX) and configure physical interface parameters.
■ On the dial interface enable PPP, HDLC, FR, X.25, or some other link layer
protocol encapsulation.
■ Configure the network protocol, IP for example.
■ Configure the routing protocol, RIP or OSPF for example.
■ Select a DCC approach, C-DCC or RS-DCC.
Configuring DCC parameters

Configure DCC parameters depending on the DCC approach you selected for
basic DCC dial functions. Based on that, you may configure advanced functions
such as MP, PPP callback, ISDN caller identification callback, ISDN leased line, and
auto-dial. You can also tune the attribute values of DCC dial interfaces depending
on link conditions.
DCC Configuration
DCC Configuration Task Complete these tasks to configure DCC:

List
Task Remarks
“Configuring Basic Parameters for DCC” on page 157 Required
“Configuring C-DCC” on page 159 Required
“Configuring RS-DCC” on page 166 Optional
“Configuring MP for DCC” on page 168
“Configuring PPP Callback” on page 170 Optional
“Configuring ISDN Caller Identification Callback” on page 174 Optional
“Configuring Advanced DCC Functions” on page 176 Optional
“Configuring DCC Timers and Buffer Queue Length” on page Optional
178
“Configuring Traffic Statistics Interval” on page 179 Optional
Configuring Basic Regardless of which DCC approach is used, C-DCC or RS-DCC, you must perform
Parameters for DCC the tasks described in this section.

Complete these tasks to configure basic parameters for DCC:
Task Remarks
“Configuring physical interfaces” on page 158 Optional
Skip this task when configuring on ISDN BRI
or PRI interfaces.
“Associating a DCC dial ACL with the dial Required
interface” on page 158
“Configuring link layer/network/routing Required
protocol on the dial interface” on page 158
Configuring physical interfaces

For a synchronous/asynchronous serial interface, you must set its operating mode
depending on the connected modem. If the connected modem is asynchronous,
set the interface to operate in asynchronous mode and then enable modem dial
on the corresponding user interface. If the connected modem is synchronous, set
the interface to operate in synchronous mode.
For detailed configurations, refer to “WAN Interface Configuration” on page 99

and “Modem Configuration” on page 355.
Configuring link layer/network/routing protocol on the dial interface

In dial interface (physical or dialer) view, configure link layer protocol
encapsulation with the link-protocol command and assign the dial interface an IP
address with the ip address command.
In system view, perform other configurations.
When PPP encapsulation is configured, you may configure PAP or CHAP

authentication in addition. Moreover, consider the following when configuring
PPP related commands:
■ In C-DCC approach, make the configuration on dialer interfaces.

■ In RS-DCC approach, make the configuration on dialer interfaces and
preferably the same configuration on physical dial interfaces on the calling side
to guarantee the reliability of PPP link parameters negotiation; on the called
side, make the configuration on physical dial interfaces.
For detailed configurations, refer to Access Volume, IP Services Volume, and IP

Routing Volume.
Associating a DCC dial ACL with the dial interface

You may configure a dial ACL to filter traffic that traverses a dial interface. Packets
fall into two categories, depending on whether they are in compliance with the
permit or deny statements in the dial ACL.
■ Packets that match a permit statement or that do not match any deny
statements. When receiving such a packet, DCC either sends it out if a link is
present and resets the idle-timeout timer or originates a new call to set up a
link if no link is present.
■ Packets that do not match any permit statements or that match a deny
statement. When receiving such a packet, DCC either sends it out without

resetting the idle-timeout timer if a link is present, or drops it without

originating calls for link setup if no link is present.
For DCC to send packets normally, you must configure a dial access control list
(ACL) and associate it with the concerned dial interface (physical or dialer) by using
the dialer-group command. You may either configure a dial ACL directly using
the dialer-rule command or reference an existing ACL.
Follow these steps to associate a dial ACL with the dial interface:

Configure a dial ACL for a dialer dialer-rule group-number Required
access group, specifying the { protocol-name { deny | permit } |
conditions triggering DCC calls acl { acl-number | name acl-name } }
Enter dial interface (physical or interface interface-type --
dialer) view interface-number
Associate the dial interface with the dialer-group group-number Required
dial ACL by associating the interface
with the corresponding dialer access
group
n Make sure that the group-number arguments in the dialer-rule and

dialer-group commands take the same value.
Configuring C-DCC In C-DCC approach, you can configure DCC parameters for a physical interface in
either of the following two ways:
■ Directly configure DCC parameters on the physical interface. This is applicable
only to one-to-one calls or one-to-many calls.
■ Bind the interface to a dialer interface by assigning it to the dialer circular
group associated with the dialer interface. Thus, the interface can inherit the
DCC parameters configured on the dialer interface. This is applicable to
many-to-one and many-to-many calls in addition to one-to-many and
one-to-one calls.
A dialer circular group associates a dialer interface with a group of physical

interfaces. All physical interfaces in the group inherit the DCC configurations on
the dialer interface. If the dialer interface is associated with multiple destinations,
any physical interface in the group can call any of these destinations.
Depending on your network topology and dial needs, for example, to allow one or
multiple interfaces to both place and receive calls, you may use any combinations
of the following C-DCC configuration approaches:
■ “Configuring an interface to place calls to a remote end” on page 160

■ “Configuring an interface to receive calls from a remote end” on page 161
■ “Configuring an interface to place calls to multiple remote ends” on page 162
■ “Configuring an interface to receive calls from multiple remote ends” on page
163

■ “Configuring multiple interfaces to place calls to one or multiple remote ends”

on page 163
■ “Configuring multiple interfaces to receive calls from one or multiple remote
ends” on page 165
In the C-DCC implementation of DCC, the two dial parties can configure the
password authentication protocol (PAP) or the challenge-handshake
authentication protocol (CHAP) authentication. You are recommended to
configure authentication to ensure security of dialing IDs. When doing that, note
the following:
■ If one party has configured authentication, the other party must do that as
well.
■ At the sending side, if DCC is enabled on physical interfaces, directly configure
PAP or CHAP authentication on the physical interfaces. If DCC is enabled on a
dialer circular group, configure PAP or CHAP authentication on the dialer
interface corresponding to the dialer circular group.
■ At the receiving end, you are recommended to make the configuration on both
physical and dialer interfaces. This is because after a physical interface receives
a call, it negotiates PPP and authenticates the dialer prior to handing the call
over to the upper layer DCC module
Configuring an interface to place calls to a remote end

As shown in the following figure, an interface at the local end places calls to a
single remote end (the components in inverse color represent the routers irrelevant
to the networking):
Figure 15 Network diagram for an interface to place calls to a remote end
if1
Local end if0 Remote end
(Single (Single
interface) interface)
In this scenario, for Interface0 (if0) to place DCC calls to a single remote interface
if1, you may configure a dial string with the dialer number or dialer route
command. As calls are to be placed from a single interface, you can configure
DCC by configuring a dialer circular group. In addition, you may configure PAP or
CHAP authentication.
After completing the basic DCC configurations, follow these steps to configure an
interface to place calls to a remote end:


Enter dial interface (physical interface interface-type --
or dialer) view interface-number
Enable C-DCC dialer enable-circular Required
Disabled by default
Configure a dial string for dialer number dial-number Required
calling a remote end
dialer route protocol Use either command.
next-hop-address [ mask
network-mask-length ] [ user
hostname | broadcast ] *
dial-number [ autodial | interface
interface-type interface-number ] *
Configuring an interface to receive calls from a remote end

As shown in the following figure, an interface at the local end receives calls from a
single remote end (the components in inverse color represent the routers irrelevant
to the networking):
Figure 16 Network diagram for an interface to receive calls from a remote end
Local end if1 Remote end

if0
(Single (Single
interface) interface)
In this scenario, for interface0 (if0) at the local end to receive DCC calls from a
remote interface if1, you can configure DCC by configuring a dialer circular group.
In addition, you may configure authentication, PAP or CHAP.
interface to receive calls from a single remote end:

Disabled by default


Configure the interface to dialer route protocol Optional
receive calls from a remote next-hop-address [ mask
If the dialer route ip
end network-mask-length ] [ user
next-hop-address user
hostname command is
configured at the called end,
the called party will use the
specified next hop address
and hostname to authenticate
the calling party.
Configuring an interface to place calls to multiple remote ends

As shown in the following figure, an interface at the local end places calls to
multiple remote ends (the components in inverse color represent the routers
irrelevant to the networking):
Figure 17 Network diagram for an interface to place calls to multiple remote ends
if1
Remote end A
(Single/Multiple
interfaces)
if0
Local end if2 Remote end B
(Single (Single/Multiple
interface) interfaces)
if3
Remote end C
(Single/Multiple
interfaces)
In this scenario, a single local interface interface0 (if0) places DCC calls to multiple
remote interfaces including if1 and if2. As multiple remote ends are involved, you
must use the dialer route command to configure the dialer strings and
destination addresses. As only one originating interface is involved, you may
configure DCC parameters for the interface by configuring a dialer circular group.
In addition, you may configure PAP or CHAP authentication.
interface to place calls to multiple remote ends:

Disabled by default
Repeat this step to configure dialer route protocol Required
the dial strings and next-hop-address [ mask
destination addresses for the network-mask-length ] [ user
interface to place calls to hostname | broadcast ] * dial-number
multiple remote ends [ autodial | interface interface-type
interface-number ] *

Configuring an interface to receive calls from multiple remote ends

As shown in the following figure, an interface at the local end receives calls from
multiple remote ends (the components in inverse color represent the routers
irrelevant to the networking):
Figure 18 Network diagram for an interface to receive calls from multiple remote ends
Remote end A
(Single/Multiple
if1 interfaces)
if0 if2
Local end Remote end B
(Single (Single/Multiple
interface) interfaces)
if3
if4
Remote end C
(Single/Multiple
interfaces)
In this scenario, a single local interface interface0 (if0) receives DCC calls from
multiple remote interfaces including if1 and if4. As only one interface is involved
at the local end, you may configure DCC parameters for the interface by
configuring a dialer circular group. In addition, you may configure PAP or CHAP
authentication.
interface to receive calls from multiple remote ends:

Disabled by default
end (if multiple remote ends network-mask-length ] [ user
are involved, repeat this step) hostname | broadcast ] *
hostname command is
configured at a called end,
the calling party.
Configuring multiple interfaces to place calls to one or multiple remote

ends
As shown in the following figure, multiple interfaces at the local end place calls to
one or multiple remote ends (the components in inverse color represent the
routers irrelevant to the networking):

Figure 19 Network diagram for multiple interfaces place calls to one or multiple remote
ends
if1 Remote end A

(Single/Multiple
interfaces)
if0
Local end if2
if1 Remote end B
(Multiple (Single/Multiple
interfaces) interfaces)
if2
if3
Remote end C
(Single/Multiple
interfaces)
In this scenario, interfaces if0, if1, and if2 at the locate end place DCC calls to
interfaces if1, if2 and if3 at the remote end. If only one remote end is involved, use
the dialer number dial-number command to configure a dial string. If multiple
remote ends are involved, use the dialer route command to configure the dial
strings and destination addresses. As multiple interfaces are involved at the local
end, configure DCC parameters for them by configuring dialer circular groups. In
addition, you may configure PAP or CHAP authentication.
When placing calls, the physical interfaces in a dialer circular group use the IP
address of the associated dialer interface instead of its own. An ISDN BRI or PRI
interface itself can be regarded as a dialer circular group for its B channels. At the
same time, it can be assigned to other dialer circular groups.
After completing the basic DCC configurations, follow these steps to configure
multiple interfaces to place calls to one or multiple remote ends:

Create and enter dialer interface dialer number --
interface view
Configure the dial string and dialer route protocol Required
destination address for calling next-hop-address [ mask
If only one remote end is
a remote end (repeat this step network-mask-length ] [ user
involved, you may use the
if multiple remote ends are hostname | broadcast ] *
dialer number dial-number
involved) dial-number [ autodial |
command instead.
interface interface-type
Exit to system view quit --
Enter physical interface view interface interface-type --
interface-number
Assign the physical interface dialer circular-group Required
to the dialer circular group number
The number argument in this
corresponding to the dialer
command must take the same
interface
value assigned to the number
argument in the interface
dialer number command.


Assign a priority to the dialer priority priority Optional
physical interface in the dialer
The default priority is 1.
circular group
Configuring multiple interfaces to receive calls from one or multiple

remote ends
As shown in the following figure, multiple interfaces at the local end receive calls
from one or multiple remote ends (the components in inverse color represent the
routers irrelevant to the networking):
Figure 20 Network diagram for multiple interfaces receive calls from one or multiple
remote ends
Remote end A
(Single/Multiple
if1 interfaces)
if0 if2
Local end Remote end B
if1
(Multiple (Single/Multiple
interfaces) interfaces)
if2 if3
Remote end C
if4 (Single/Multiple
interfaces)
In this scenario, interfaces if0, if1, and if2 at the local end receive DCC calls from
multiple remote interfaces including if1, if2 and if4. As multiple interfaces are
involved at the local end, configure DCC parameters for them by configuring a
dialer circular group. In addition, you may configure PAP or CHAP authentication.
After completing the basic DCC configurations, follow these steps to configure
multiple interfaces to receive calls to one or multiple remote ends:

Create and enter dialer interface dialer number --
interface view
end (if multiple remote ends network-mask-length ] [ user
are involved, repeat this step) hostname | broadcast ] *
hostname command is
configured at a called end,
the calling party.
Enter physical interface view interface interface-type --
interface-number


Assign the physical interface dialer circular-group Required
to the dialer circular group number
The number argument in this
corresponding to the dialer
command must take the same
interface
value assigned to the number
argument in the interface
dialer number command.
Assign a priority to the dialer priority priority Optional
physical interface in the dialer
The default priority is 1.
circular group
Configuring RS-DCC In RS-DCC approach, physical interface configuration is separated from logical
configuration for calls and they can be combined dynamically for each call.
When configuring RS-DCC for on-demand dial, you need to configure RS-DCC
sets. Each RS-DCC set is an attribute collection containing a dialer interface, dialer
interface attributes, and a dialer bundle as follows:
■ For each dialer interface, you can define only one dial string. As this dial string
has its own dial attribute set, all calls placed using this dial string use the same
DCC attribute parameters (such as dial rate).
■ Each dialer interface can use only one dialer bundle. Each dialer bundle may
contain multiple physical interfaces with different priorities while each of these
interfaces can belong to multiple dialer bundles. For an ISDN BRI or PRI
interface, you can set the number of B channels to be used by configuring the
dialer bundle command.
■ All calls destined to the same network segment use the same RS-DCC set.
Due to the separation between physical configuration and logical configuration,

RS-DCC can accommodate more network topologies and DCC dial demands. For
example, it allows multiple interface groups to call multiple remote ends.
Figure 21 Multiple interfaces call multiple remote ends in RS-DCC approach
Physical interface
groups Remote end A
if1
(Single/Multiple
Call remote interfaces)
end A Local end
Dialer0
(Multiple
interfaces)
Call remote if2 Remote end B
Dialer1
end B (Single/Multiple
interfaces)
Call remote
end C Dialer2 if3
Remote end C
(Single/Multiple
interfaces)
In this scenario, a dialer interface is configured only for calling one remote end.
On-demand dial in this case is implemented by assigning a physical interface to
dialer bundles associated with different dialer interfaces.

If RS-DCC sets are used to configure RS-DCC parameters, you only need to
configure link layer encapsulation and dialer bundle numbers on physical
interfaces.
Before configuring RS-DCC, be aware of the following:
■ In RS-DCC, a RS-DCC set is unable to apply the attribute information in it, PPP
authentication for example, to the physical interfaces in a dialer bundle. In
other words, the physical interfaces do not inherit the authentication attribute
in the RS-DCC set. Therefore, authentication information must be configured
on call receiving physical interfaces.
■ Authentication is mandatory in RS-DCC. You must configure authentication
(dialer user and PPP authentication) on both dialer interfaces and their physical
interfaces. This is because RS-DCC needs to conduct PPP negotiation on the
physical interface and sends the agreed-upon remote username to DCC. Based
on this remote username, DCC decides which dialer interface address is used
and then informs PPP. PPP then uses the configuration of the dialer interface to
start IP control protocol (IPCP) negotiation.
Complete these tasks to configure RS-DCC for on-demand calling:
Task Remarks
“Enabling RS-DCC” on page 167 Required
“Configuring a dial string for the dialer interface” on page Required
167
“Assigning physical interfaces to the dialer bundle” on page Required
168
“Configuring dial authentication for RS-DCC” on page 168 Required
Enabling RS-DCC
Follow these steps to enable RS-DCC:

Create and enter dialer interface view interface dialer number --
Set the remote username dialer user username Required
Create a dialer bundle for the dialer dialer bundle number Required
interface
Configuring a dial string for the dialer interface

In the RS-DCC approach to on-demand dial, the attributes of physical interfaces
vary by dial string. Therefore, DCC parameters should be configured on dialer
interfaces and dial strings can be configured only with the dialer number
command. Furthermore, for each dialer interface, you can configure only one dial
string.
Follow these steps to configure a dial string for the dialer interface:



Enter dialer interface view interface dialer number --
Configure a dial string for calling a remote dialer number dial-number Required
end
Assigning physical interfaces to the dialer bundle

A dialer bundle is a collection of physical interfaces with different priorities. When
placing a call, DCC selects a physical interface from the bundle in priority order.
Follow these steps to assign physical interfaces to the dialer bundle:

Enter physical interface interface-type --
Assign the dialer bundle-member Required
interface to the number [ priority priority ]
Physical interfaces do not belong to any
dialer bundle
dialer bundle by default.
After a physical interface is assigned
without priority to a dialer bundle, it takes
the default priority of 1.
Configuring dial authentication for RS-DCC

In RS-DCC, associations between physical interfaces and dialer interfaces are
rather flexible. To allow a called party to discriminate calling parties, you must
configure authentication, either PAP or CHAP.
Follow these steps to configure dialup authentication for RS-DCC:

Configure the remote username dialer user username Required
Configure PPP encapsulation and PPP See “PPP and MP Configuration” Required
authentication (PAP or CHAP) on page 363.
n ■ You are recommended to configure either PAP or CHAP authentication on both

physical and dialer interfaces at both sending and receiving ends.
■ When PPP encapsulation is enabled on a dialer interface, you must configure a
remote username with the dialer user command for the dialer interface.
When DCC decides which dialer interface is used for receiving a call, it
compares the remote username gained through PPP negotiation against those
assigned to dialer interfaces for a match.
Configuring MP for DCC This section covers these topics:

■ “Implementing DCC with MP” on page 169
■ “Configuration procedure” on page 170

Implementing DCC with MP

In DCC applications, you may configure load thresholds for links.
If you set a link load threshold in the range 1 to 99, MP tunes allocated bandwidth
according to actual traffic percentage as follows:
■ When the percentage of traffic on a link to bandwidth exceeds the defined

traffic threshold, the system automatically brings up the second link, and
assigns them to one MP bundle. When the percentage of traffic on these two
links to bandwidth exceeds the defined traffic threshold, the system brings up
the third link, and assigns it to the MP bundle, so on and so forth. This ensures
appropriate traffic distribution on DCC links.
■ On the contrary, when the percentage of the traffic on N (which is an integer
greater than 2) links to the bandwidth of N - 1 links decreases under the
defined traffic threshold, the system automatically shuts down a link, so on and
so forth. This ensures the efficient use of DCC links.
If you set the link load threshold to zero, DCC brings up all available links when
triggered by auto-dial or packets instead of looking at traffic size before doing
that. In addition, it does not tear down links that has been established for timeout.
To implement MP with DCC, you must use dialer interfaces. The following is how
MP operates after you configure the ppp mp and dialer threshold commands on
a dialer interface:
1 When the ratio of traffic to bandwidth on a physical interface (or a B channel)

assigned to the dialer interface exceeds the load threshold, DCC brings up another
physical interface in the dialer interface, and assigns these links to an MP bundle. If
the physical interfaces are ISDN BRI or PRI interfaces, DCC uses idle B channels on
them to form an MP bundle.
2 When the number of bundled links reaches the upper threshold specified by the
max-bind-num argument, DCC stops to bring up new links.
Some dial applications may require multiple links to carry service. To this end, you
may configure the ppp mp min-bind command, allowing DCC to bring up
multiple links when triggered to ensure minimum bandwidth. The following is
how MP operates in this case:
3 DCC brings up the first link.

4 When the first link comes up, DCC checks whether the number of links in the MP
bundle reaches the lower limit specified by the min-bind-num argument. If not,
the router brings up the second link.
This process continues until the number of links in the MP bundle reaches the
lower limit.
Note that when MP is used with DCC, the commands dialer threshold, ppp mp
max-bind, and ppp mp min-bind must be configured in dialer interface view.
When configuring other PPP commands, observe the following:
■ In the C-DCC approach, configure in dialer interface view.

■ In the RS-DCC approach, configure in dialer interface view at the calling end
and in physical dial interface view at the called end. At the calling end,
however, you are recommended to configure the same PPP parameters on
physical dial interfaces as well to ensure reliable PPP link negotiation.
When the three commands, ppp mp min-bind, dialer threshold, and ppp mp
max-bind, are configured, DCC brings up links as follows:
5 Bring up a minimum number of links depending on the setting of the ppp mp

min-bind command.
6 If traffic size still exceeds the link load threshold set by the dialer threshold
command, bring up the next idle link. This process continues until the number of
links reaches the upper limit set by the ppp mp max-bind command or traffic size
decreases below the specified link load threshold.
Follow these steps to configure MP for DCC:

Enable MP ppp mp Required
Set link load thresholds dialer threshold Required
traffic-percentage [ in-out | in
If the traffic-percentage
| out ]
argument is set to 0, DCC will
bring up all available links
when triggered.
Set upper limit of links in an ppp mp max-bind Optional
MP bundle max-bind-num
The default is 16.
Set lower limit of links in an ppp mp min-bind Optional
MP bundle min-bind-num
The default is 0; DCC brings
up links depending on traffic
size.
n ■ Configure PPP commands on both dialer and physical interfaces to ensure

reliable PPP link negotiation.
■ The dialer threshold 0 command voids the dialer timer idle command. DCC
will bring up all available links when triggered.
■ Similar to the dialer threshold 0 command, the ppp mp min-bind command
voids the dialer timer idle command. When it is configured, DCC does not
look at traffic size to bring up links for MP bundling or tear down links that
have been brought up.
■ You need to configure the dialer threshold command only at the calling end.
Configuring PPP PPP callback adopts the client/server model where the calling party is the callback
Callback client and the called party is the callback server. The client first originates a call,
and the server decides whether to originate a return call. If a return call is needed,
the callback server disconnects and then originates a return call according to the
information such as username or callback number.

n ■ Configure PPP callback after completing the basic configuration of C-DCC or

RS-DCC.
■ PPP callback implementation requires authentication. You are recommended to
configure PAP or CHAP authentication on both physical and dialer interfaces on
both callback client and server.
■ With dynamic route backup configured on an interface, only the dynamic route
backup groups are used for dial. In this case, the interface does not accept
incoming calls or outgoing calls. So, do not configure dynamic route backup
groups for interfaces with callback configured.
Two approaches are available to configuring PPP callback with DCC:
■ “Configuring PPP callback in the C-DCC implementation” on page 171

■ “Configuring PPP callback in the RS-DCC implementation” on page 173
Configuring PPP callback in the C-DCC implementation

Configuring PPP callback in C-DCC involves configuring PPP callback client and
server.
1 Configure PPP callback client in the C-DCC implementation
As a callback client, your router can place calls to the remote end (which can be a
router or Windows NT server with the PPP callback server function), and receive
return calls from the remote end.
Follow these steps to configure PPP callback client in the C-DCC implementation:

Enter dialer interface view interface dialer --
interface-number
Enable PPP encapsulation link-protocol ppp Required
Configure authentication See “Configuring PPP” on Required
parameters page 367 for related
information.
Enable PPP callback client ppp callback client Required
Disabled by default
Configure the dial string for a ppp callback ntstring Optional
Windows NT Server to call dial-number
Not configured by default.
back
Configure this command if a
Windows NT Server requires
PPP callback clients to send
callback numbers.
Set the interval between two dialer timer enable seconds Optional
calls
15 seconds is recommended.
2 Configure PPP callback server in the C-DCC implementation
As a callback server, your router can place return calls according to network
addresses configured with the dialer route command (PPP authentication must
be configured in this case), or according to dial strings configured with the

service-type ppp command. You need to select either approach with the dialer
callback-center command.
You need to configure callback client usernames with the dialer route command,
so that the callback server can authenticate whether a callback client is valid when
receiving a call from it.
Follow these steps to configure PPP callback server in the C-DCC implementation:

Enable PPP callback server ppp callback server Required
Configure the PPP callback reference dialer callback-center Required
[ user | dial-number ] *
Add a callback client username dialer route protocol Required
next-hop-address [ mask
network-mask-length ]
user hostname
[ broadcast ]
[ dial-number [ autodial |
interface-number ] * ]
Configure either If the local-user user-name Required
command dial-number
service-type ppp
depending on keyword is
[ callback-nocheck |
the keyword configured, create
callback-number
configured with and enter local
callback-number |
the dialer user view to
call-number call-number
callback-center configure a
[ subcall-number ] ]
command callback user and
the dial string for
callback
If the user dialer route protocol
keyword is next-hop-address [ mask
configured, network-mask-length ]
configure a dial user hostname
string for callback [ broadcast ] dial-number
[ autodial | interface
interface-type
n ■ If the network address used by a callback client is dynamically assigned,

configuring the dialer route command to associate the callback dial string
with the network address for the client may result in callback failure. In this
case, you should use the service-type ppp command instead to associate the
dial string with the client username for callback.
■ To leave enough time for a server to call back, the interval between two calls
on the client need to be at least 10 seconds longer than that of the server. It is
recommended that the interval on the server be set to 5 seconds (the default)
and that on the client be set to 15 seconds.

Configuring PPP callback in the RS-DCC implementation

Configuring PPP callback in RS-DCC involves configuring PPP callback client and
configuring PPP callback server.
1 Configure PPP callback client in the RS-DCC implementation
As a callback client, your router can place calls to the remote end (which can be a
router or Windows NT server with the PPP callback server function), and receive
return calls from the remote end.
Configuring PPP callback client in RS-DCC is the same as that in C-DCC except
that the dial string is configured with the dialer number command in RS-DCC.
Follow these steps to configure PPP callback client in the RS-DCC implementation:

Enable PPP encapsulation link-protocol ppp Required
Configure authentication See “PPP and MP Configuration” on Required
parameters page 363 and “PPPoE Configuration”
on page 393 for related information.
Enable PPP callback client ppp callback client Required
Disabled by default
Configure the dial string for a ppp callback ntstring dial-number Required
Windows NT Server to place
return calls
calls
15 seconds is
recommended.
2 Configure PPP callback server in the RS-DCC implementation
Configuring PPP callback server in RS-DCC is the same as that in C-DCC except
that the callback reference can only be dial-number in RS-DCC and dial strings for
callback must be configured with the service-type ppp command.
Follow these steps to configure PPP callback server in the RS implementation:

Enable PPP callback server ppp callback server Required
Configure the PPP callback dialer callback-center Required
reference dial-number
Create and enter local user local-user user-name Required
view


Configure a dial string for service-type ppp Required
callback [ callback-nocheck |
When placing a return call,
callback-number
DCC identifies which dial
callback-number |
string to be used according to
the remote username
[:subcall-number ] ]
obtained through PPP
negotiation.
n To leave enough time for a server to call back, the interval between two calls on
the client need to be at least 10 seconds longer than that of the server. It is
recommended that the interval on the server be set to 5 seconds (the default) and
that on the client be set to 15 seconds.
Configuring ISDN Caller In an ISDN environment, implementing DCC callback through ISDN caller
Identification Callback identification function does not require authentication configuration.
This section covers these topics:
■ “Features of ISDN caller Identification callback” on page 174

■ “Configuring ISDN caller identification callback with C-DCC” on page 175
■ “Configuring ISDN caller identification callback with RS-DCC” on page 176
Features of ISDN caller Identification callback

1 In the applications of ISDN caller Identification callback, the callback server can
process an incoming call in three ways, depending on the result of matching the
dial-in number against numbers configured in dialer call-in commands at the
local end:
■ Deny the incoming call, if one or multiple dialer call-in commands exist, but
no match is found.
■ Accept the incoming call, if the call-in number matches a dialer call-in
command without the callback keyword or if no dialer call-in command
exists.
■ Call back, if the call-in number matches a dialer call-in command with the
callback keyword.
2 Dial-in numbers are matched against numbers configured in dialer call-in
commands starting with the right-most character. In addition, asterisks (*) are
used as wildcards to match any character. If a dial-in number matches multiple
dialer call-in commands, the best match is selected in the following order:
■ The one with the fewest asterisks (*).
■ The one that is found first.
3 At the server end, identify the dialer call-in commands matching incoming calls
■ In C-DCC, upon receipt of an incoming call, the server compares the incoming
number against the dialer call-in commands configured on the physical dial
interface or its corresponding dialer interface for a match.
■ In RS-DCC, upon receipt of an incoming call, the server compares the incoming
number against the dialer call-in commands configured on the involved dialer
interface for a match.

Configuring ISDN caller identification callback with C-DCC

Configuring ISDN caller identification callback with C-DCC involves configuring
the server end and the client end.
1 Configure the client of ISDN caller identification callback
Follow these steps to configure the client of ISDN caller identification callback:

Configure a destination dialer route protocol Required
address and dial string next-hop-address [ mask
Repeat this step to configure
network-mask-length ] [ user
destination addresses and dial
strings for calling multiple
dial-number [ autodial |
remote ends.
calls
2 Configure the server of ISDN caller identification callback
Follow these steps to configure the server of ISDN caller identification callback:

Configure the local end to dialer call-in remote-number callback Required
place ISDN return calls for the
specified ISDN calling number
Configure one or multiple dialer route protocol Required
destination addresses and dial next-hop-address [ mask
strings network-mask-length ] [ user
hostname | broadcast ] * dial-number
[ autodial | interface interface-type
Use this command instead of dialer number dial-number Optional
the dialer route command if
only one remote destination
address is involved
n ■ To make a successful callback for an incoming number, ensure that the dial
string configured in the dialer route or dialer number command on the dial
interface at the server end is exactly the same as the incoming number.

Configuring ISDN caller identification callback with RS-DCC

Configuring ISDN caller identification callback with RS-DCC involves configuring
the server end and the client end.
1 Configure the client of ISDN caller identification callback
Follow these steps to configure the client of ISDN caller identification callback:

Enter dialer interface view interface dialer --
interface-number
Configure a dial string for dialer number dial-number Required
calling a remote end
calls
2 Configure the server of ISDN caller identification callback
Follow these steps to configure the server of ISDN caller identification callback:

Enter dialer interface view interface dialer interface-number --
Configure the local end to place dialer call-in remote-number callback Required
ISDN return calls for the specified
ISDN calling number
Configure a dial string for calling a dialer number dial-number Required
remote end
n ■ The number configured in the dialer number command on the dialer

interface is not required to be same as the incoming number.
Configuring Advanced Configuring advanced DCC functions involves:

DCC Functions ■ “Configuring ISDN leased line” on page 176
■ “Configuring auto-dial” on page 177
■ “Configuring circular dial string backup” on page 177
Configuring ISDN leased line

ISDN leased line can be configured with C-DCC but not RS-DCC. This function is
fulfilled through establishing semi-permanent ISDN MP connections. Such
application requires that a leased line has been established on the PBX of your
telecom service provider and has been connected to the remote device.

After completing C-DCC configurations, follow these steps to configure ISDN

leased line:

Enter physical interface interface interface-type --
Specify a B channel for dialer isdn-leased number Required
ISDN leased line
No B channel is configured for ISDN
connection
leased line connection by default.
ISDN BRI interfaces support both 64 kbps and 128 kbps leased lines. For more
information, refer to “Configuring ISDN BRI” on page 422.
Configuring auto-dial
Auto-dial can be used with C-DCC but not RS-DCC. With auto-dial enabled, DCC
automatically dials the remote end of connection upon each device startup
without requiring a triggering packet. If the connection cannot be established, it
will retry at certain intervals. The connection thus established does not disconnect
due to timeout of the idle-timeout timer as it would in the traffic-triggered dial
approach. Its configuration thus voids the dialer timer idle command.
Follow these steps to configure auto-dial:

Configure one or multiple dialer route protocol Required
destination addresses and dial next-hop-address [ mask
Auto-dial is disabled by
strings that can be network-mask-length ] [ user
default.
auto-dialed hostname | broadcast ] *
dial-number autodial [ interface
interface-type interface-number ]
Set the auto-dial interval dialer timer autodial seconds Optional
The default is 300
seconds.
Configuring circular dial string backup

In C-DCC, you may configure multiple dialer route commands for the dial strings
used to call a destination address. These dial strings are backups to each other. If
DCC fails to call the remote end with a dial string, it will select the dialer route
command with the next dial string for another try.
Follow these steps to configure dial string circular backup:

Enter dial interface (physical interface interface-type interface-number --
or dialer) view


Repeat this step to associate dialer route protocol next-hop-address Required
multiple dial strings with the [ mask network-mask-length ] [ user
same next-hop-address hostname | broadcast ] * dial-number
[ autodial | interface interface-type
Configuring DCC Timers C-DCC and RS-DCC are available with some optional parameters. You may
and Buffer Queue configure them appropriately to improve on-demand dial efficiency.
Length
■ “DCC timers and buffer queue length” on page 178

DCC timers and buffer queue length

■ Link idle-timeout timer
A link idle-timeout timer starts upon setup of a link. When the timer expires, DCC
disconnects the link.
■ Holddown timer
A holddown timer starts upon disconnection of a link. The call attempt to bring up
this link can be made only after the timer expires. This is to prevent a remote PBX
from being overloaded.
■ Compete-idle timer
If all the channels are unavailable when DCC originates a new call, contention
occurs.
Normally, an idle-timeout timer starts upon setup of a link. If a call to another

destination address is placed at the same time, contention occurs. In this case,
DCC starts a compete-idle timer to replace the idle-timeout timer for the link.
When the idle time of the link reaches the setting of this compete-idle timer, the
link disconnects.
■ Wait-carrier timer
Sometimes, the time that DCC waits for a connection to be established may vary
call by call. To handle this situation, you may use a wait-carrier timer. A wait-carrier
timer starts when a call is placed. If the connection is not established upon
expiration of the timer, DCC terminates the call.
■ Buffer queue length
If no connection is available when a dial interface without a buffer queue receives

a packet, it will drop the packet. Configured with a buffer queue, the dial interface
will buffer the packet until a connection is available for packet sending.

Displaying and Maintaining DCC 179
Follow these steps to configure DCC timers and buffer queue length on a dial
interface:

Set the link idle-timeout timer dialer timer idle seconds Optional
Set the holddown timer dialer timer enable seconds Optional
Set the compete-idle timer dialer timer compete Optional
seconds
Set the wait-carrier timer dialer timer wait-carrier Optional
seconds
Set the buffer queue length dialer queue-length packets Optional
Packets are not buffered by
default.
Configuring Traffic Follow these steps to configure traffic statistics interval for DCC:
Statistics Interval
Set the traffic statistics interval dialer flow-interval interval Optional
for DCC
Displaying and
Maintaining DCC To do... Use the command... Remarks
Display information about display dialer [ interface interface-type Available in any
specified or all dial interfaces interface-number ] view
Display information about a display interface dialer [ number ] Available in any
dialer interface view
Tear down dialup links dialer disconnect [ interface Available in any
interface-type interface-number ] view
DCC Configuration This section provides these examples:

Example ■ “C-DCC Application” on page 180
■ “RS-DCC Application” on page 182
■ “DCC Application on ISDN” on page 186
■ “RS-DCC Application with MP” on page 190
■ “DCC for Dialup ISDN BRI Line and Leased Line Connection” on page 192
■ “Router-to-Router Callback with DCC (PPP Approach)” on page 194
■ “Router-to-Router Callback with DCC (ISDN Approach)” on page 197

■ “Router-to-PC Callback with DCC” on page 198

■ “NT Server-to-Router Callback with DCC” on page 200
■ “Circular Dial String Backup and Internet Access with DCC” on page 202
C-DCC Application Network requirements

On a network segment are located three routers: Router A with the IP address of
100.1.1.1/24, Router B with the IP address of 100.1.1.2/24, and Router C with the
IP address of 100.1.1.3/24.
Configure C-DCC to allow Router A to call Router B and Router C from multiple
interfaces while disabling Router B and Router C from calling each other.
Network diagram
Figure 22 Network diagram for a C-DCC application
S2/0 Router B
100 .1 .1.2/24
Modem 8810048 8810052 Modem
S 2/0
Router A PSTN
S 2/1
Dialer 0
100 .1 .1.1/24
Modem 8810049 8810063 Modem

S2/0
Router C
100 .1 .1.3/24
# Configure a dial access control rule for dialer access group 1.
# Assign an IP address to interface Dialer0, associate dialer access group 1 with the
interface, enable C-DCC, and configure dial strings for calling Router B and Router
C.
[RouterA] interface dialer 0

[RouterA-Dialer0] dialer enable-circular
[RouterA-Dialer0] ip address 100.1.1.1 255.255.255.0
[RouterA-Dialer0] dialer route ip 100.1.1.2 8810052
[RouterA-Dialer0] dialer route ip 100.1.1.3 8810063
# Set interface Serial 2/1 to work in asynchronous protocol mode and assign it to
dialer circular group 0.

[RouterA] interface serial 2/1

[RouterA-Serial2/1] physical-mode async
[RouterA-Serial2/1] async mode protocol
[RouterA-Serial2/1] dialer circular-group 0
[RouterA-Serial2/1] quit
# Set interface Serial 1/0 to work in asynchronous protocol mode and assign it to
dialer circular group 0.

[RouterA-Serial1/0] dialer circular-group 0
# Enable modem dialup on user interfaces to be used.
[RouterA] user-interface tty1

[RouterA-ui-tty1] modem both
[RouterA-ui-tty1] quit
2 Configure Router B.
[RouterB] dialer-rule 1 ip permit
# Set interface Serial 2/0 to work in asynchronous protocol mode.
[RouterB] interface serial 2/0

[RouterB-Serial2/0] physical-mode async
[RouterB-Serial2/0] async mode protocol
# Assign an IP address to interface Serial 2/0, associate dialer access group 1 with
the interface, enable C-DCC, and configure two dial strings for calling Router A.
[RouterB-Serial2/0] ip address 100.1.1.2 255.255.255.0

[RouterB-Serial2/0] dialer enable-circular
[RouterB-Serial2/0] dialer-group 1
[RouterB-Serial2/0] dialer route ip 100.1.1.1 8810048
[RouterB-Serial2/0] dialer route ip 100.1.1.1 8810049
[RouterB-Serial2/0] quit
# Enable modem dialup on the user interface to be used.
[RouterB] user-interface tty1

[RouterB-ui-tty1] modem both
[RouterC] dialer-rule 1 ip permit

# Set interface Serial 2/0 to work in asynchronous protocol mode.
[RouterC] interface serial 2/0

[RouterC-Serial2/0] physical-mode async
[RouterC-Serial2/0] async mode protocol
# Assign an IP address to interface Serial 2/0, associate dialer access group 1 with
the interface, enable C-DCC, and configure two dial strings for calling Router A.
[RouterC-Serial2/0] ip address 100.1.1.3 255.255.255.0

[RouterC-Serial2/0] dialer enable-circular
[RouterC-Serial2/0] dialer-group 1
[RouterC-Serial2/0] dialer route ip 100.1.1.1 8810048
[RouterC-Serial2/0] dialer route ip 100.1.1.1 8810049
[RouterC-Serial2/0] quit
# Enable modem dialup on the user interface to be used.
[RouterC] user-interface tty1

[RouterC-ui-tty1] modem both
RS-DCC Application Network requirements

As shown in the following diagram,
■ On Router A, interface Dialer0 is assigned an IP address 100.1.1.1/24 and
Dialer1 an IP address 122.1.1.1/24.
■ On Router B, interface Dialer0 is assigned an IP address 100.1.1.2/24.
■ On Router C, interface Dialer0 is assigned an IP address 122.1.1.2/24.
The Dialer0 interfaces on Router A and Router B are located on the same network
segment, so are the Dialer1 interface on Router A and the Dialer0 interface on
Router C.
Configure RS-DCC to allow Router A to call Router B and Router C from multiple
interfaces while disabling Router B and Router C from calling each other.
Network diagram
Figure 23 Network diagram for an RS-DCC application
NT 1 Router B
BRI1/0
8810052 100.1.1.2/24
Router A NT 1
8810048
ISDN
BRI1/0
100.1.1.1 /24
8810063 NT 1 Router C
BRI1 /0
100 .1.1 .3/24

# Configure a dial access control rule for dialer access group 1; create local user
accounts userb and userc for Router B and Router C and configure PPP
authentication for them.
[RouterA] local-user userb
[RouterA-luser-userb] password simple userb
[RouterA-luser-userb] service-type ppp
[RouterA-luser-userb] quit
[RouterA] local-user userc
[RouterA-luser-userc] password simple userc
[RouterA-luser-userc] service-type ppp
[RouterA-luser-userc] quit
# Assign an IP address to interface Dialer0, enable RS-DCC, and configure the

remote username allowed to call in.

[RouterA-Dialer0] dialer user userb
# Configure information for PPP authentication and the dial strings on interface
Dialer0. (Assume that PAP is adopted at the local end.)
[RouterA-Dialer0] ppp authentication-mode pap
[RouterA-Dialer0] ppp pap local-user usera password simple usera
[RouterA-Dialer0] dialer number 8810052
# Assign an IP address to interface Dial1, enable RS-DCC, and configure the


[RouterA-Dialer1] dialer user userc
Dialer1. (Assume that PAP is adopted at the local end.)
# Set interface Serial 2/0 to work in asynchronous protocol mode, configure

information for PPP authentication, and assign the interface to dialer bundle 1 and
dialer bundle 2.


[RouterA-Serial2/0] dialer bundle-member 1
[RouterA-Serial2/0] link-protocol ppp
[RouterA-Serial2/0] ppp authentication-mode pap
[RouterA-Serial2/0] ppp pap local-user usera password simple usera
# Set interface Serial 2/1 to operate in asynchronous protocol mode, configure

information for PPP authentication, and assign the interface to dialer bundle 1 and
dialer bundle 2.

# Configure user interfaces to be used and enable modem dialup on them.

[RouterAe-ui-tty1] quit
# Configure a dial access control rule for dialer access group 2; create a local user
account usera for Router A and configure PPP authentication for it.
[RouterB] local-user usera
[RouterB-luser-usera] password simple usera
[RouterB-luser-usera] service-type ppp
[RouterB-luser-usera] quit

remote username allowed to call in and the dial string for placing calls.
[RouterB] interface dialer 0

[RouterB-Dialer0] ip address 100.1.1.2 255.255.255.0
[RouterB-Dialer0] dialer user usera
[RouterB-Dialer0] dialer bundle 1
[RouterB-Dialer0] dialer number 8810048
# Configure information for PPP authentication. (Assume that PAP is adopted at

the local end.)
[RouterB-Dialer0] dialer-group 2
[RouterB-Dialer0] ppp authentication-mode pap

[RouterB-Dialer0] ppp pap local-user userb password simple userb

[RouterB-Dialer0] quit

information for PPP authentication, and assign the interface to dialer bundle 1.

[RouterB-Serial2/0] dialer bundle-member 1
[RouterB-Serial2/0] link-protocol ppp
[RouterB-Serial2/0] ppp authentication-mode pap
[RouterB-Serial2/0] ppp pap local-user userb password simple userb
# Configure the user-interface to be used and enable modem dialup on it.

account usera and configure PPP authentication for it.
[RouterC] local-user usera
[RouterC-luser-usera] password simple usera
[RouterC-luser-usera] service-type ppp
[RouterC-luser-usera] quit

remote username allowed to call in and the dial string for placing calls.
[RouterC] interface dialer 0

[RouterC-Dialer0] ip address 122.1.1.2 255.255.255.0
[RouterC-Dialer0] dialer user usera
[RouterC-Dialer0] dialer bundle 1
[RouterC-Dialer0] dialer number 8810049
# Configure information for PPP authentication. (Assume that PAP is adopted at

the local end.)
[RouterC-Dialer0] dialer-group 1
[RouterC-Dialer0] ppp authentication-mode pap
[RouterC-Dialer0] ppp pap local-user userc password simple userc
[RouterC-Dialer0] quit

information for PPP authentication, and assign the interface to dialer bundle 1.

[RouterC-Serial2/0] physical-mode async
[RouterC-Serial2/0] async mode protocol
[RouterC-Serial2/0] dialer bundle-member 1
[RouterC-Serial2/0] link-protocol ppp
[RouterC-Serial2/0] ppp authentication-mode pap

[RouterC-Serial2/0] ppp pap local-user userc password simple userc

# Configure the user-interface to be used and enable modem dialup on it.
[RouterC] user-interface tty1

[RouterC-ui-tty1] modem both
DCC Application on ISDN Network requirements

Figure 24 presents a scenario for C-DCC implementation, where:
■ On Router A, interface BRI 1/0 is assigned an IP address 100.1.1.1/24.
■ On Router B, interface BRI 1/0 is assigned an IP address 100.1.1.2/24.
■ On Router C, interface BRI 1/0 is assigned an IP address 100.1.1.3/24.
The BRI 1/0 interfaces on these three routers are located on the same network
segment.
Figure 25 presents a scenario for RS-DCC implementation, where:
■ On Router A, interface Dialer0 is assigned an IP address 100.1.1.1/24 and

Dialer1 an IP address 122.1.1.1/24.
■ On Router B, interface Dialer0 is assigned an IP address 100.1.1.2/24.
■ On Router C, interface Dialer0 is assigned an IP address 122.1.1.2/24.
The Dialer0 interfaces on Router A and Router B are located on the same network
segment, so are the Dialer1 interface on Router A and the Dialer0 interface on
Router C.
Make configuration to allow Router A to call Router B and Router C from multiple
interfaces while disabling Router B and Router C from calling each other in both
C-DCC and RS-DCC approaches.
Network diagram
Figure 24 Network diagram for C-DCC application on ISDN
NT 1 Router B
BRI1/0
8810052 100.1.1.2/24
Router A NT 1
8810048
ISDN
BRI1/0
100.1.1.1 /24
BRI1 /0
100 .1.1 .3/24

Figure 25 Network diagram for RS-DCC application on ISDN
NT 1 Router B
BRI1/0
8810052
Dialer 0
100 .1 .1.2/24
Dialer 0
Router A 100 .1 .1.1/24 NT 1
8810048
ISDN
BRI1/0
Dialer1
122 .1.1 .1/24
BRI1/0
Dialer 0
122 .1 .1.2/24
Solution 1: Use C-DCC to set up connection via ISDN BRI or PRI and configure
DCC parameters on physical interfaces.
# Assign an IP address to interface BRI 1/0, enable C-DCC, and configure the dial
strings for calling Router B and Router C.
[RouterA] interface bri 1/0

[RouterA-Bri1/0] ip address 100.1.1.1 255.255.255.0
[RouterA-Bri1/0] dialer enable-circular
[RouterA-Bri1/0] dialer-group 1
[RouterA-Bri1/0] dialer route ip 100.1.1.2 8810052
string for calling Router A.
[RouterB] interface bri 1/0

[RouterB-Bri1/0] ip address 100.1.1.2 255.255.255.0
[RouterB-Bri1/0] dialer enable-circular
[RouterB-Bri1/0] dialer-group 2
[RouterB-Bri1/0] dialer route ip 100.1.1.1 8810048

string for calling Router A.
[RouterC] interface bri 1/0

[RouterC-Bri1/0] ip address 100.1.1.3 255.255.255.0
[RouterC-Bri1/0] dialer enable-circular
[RouterC-Bri1/0] dialer-group 1
[RouterC-Bri1/0] dialer route ip 100.1.1.1 8810048
Solution 2: Use RS-DCC to set up connection via ISDN BRI or PRI and configure
DCC parameters on dialer interfaces.
accounts userb and userc for Router B and Router C and configure PPP
authentication for them.
[RouterA] local-user userc
[RouterA-luser-userc] password simple userc
[RouterA-luser-userc] service-type ppp
[RouterA-luser-userc] quit


Dialer0.
# Assign an IP address to interface Dial1, enable RS-DCC, and configure the


[RouterA-Dialer1] dialer user userc

Dialer1.
# Set information for PPP authentication on interface BRI 1/0 and assign the
interface to dialer bundle 1 and dialer bundle 2.

[RouterA-Bri1/0] dialer bundle-member 1
[RouterA-Bri1/0] link-protocol ppp
[RouterA-Bri1/0] ppp authentication-mode pap
[RouterA-Bri1/0] ppp pap local-user usera password simple usera


# Configure information for PPP authentication and the dial string on interface
Dialer0.
# Configure PPP authentication on interface BRI 1/0 and assign it to dialer bundle
1.

[RouterB-Bri1/0] dialer bundle-member 1
[RouterB-Bri1/0] link-protocol ppp
[RouterB-Bri1/0] ppp authentication-mode pap
[RouterB-Bri1/0] ppp pap local-user usera password simple usera

[RouterC] local-user usera
[RouterC-luser-usera] password simple usera
[RouterC-luser-usera] service-type ppp
[RouterC-luser-usera] quit

[RouterC] interface dialer 0

[RouterC-Dialer0] ip address 122.1.1.2 255.255.255.0
[RouterC-Dialer0] dialer user usera
[RouterC-Dialer0] dialer bundle 1
Dialer0.
[RouterC-Dialer0] dialer-group 1
[RouterC-Dialer0] dialer number 8810048
[RouterC-Dialer0] ppp authentication-mode pap
[RouterC-Dialer0] ppp pap local-user userc password simple userc
[RouterC-Dialer0] quit
# Configure information for PPP authentication on interface BRI 1/0 and assign the
interface to dialer bundle 1.

[RouterC-Bri1/0] dialer bundle-member 1
[RouterC-Bri1/0] link-protocol ppp
[RouterC-Bri1/0] ppp authentication-mode pap
[RouterC-Bri1/0] ppp pap local-user usera password simple usera
RS-DCC Application with Network requirements

MP Figure 26 presents a scenario where:
■ Two ISDN BRI interfaces on Router A and an ISDN PRI interface on Router B are
connected across ISDN.
■ Interface Dialer0 on Router A is assigned an IP address 100.1.1.1/24, and
interface Dialer0 on Router B is assigned an IP address 100.1.1.2/24.
Use RS-DCC on Router A to call Router B and C-DCC on Router B to call Router A.
In addition, implement traffic distribution for the two interfaces on Router A by
setting traffic thresholds and maximum bandwidth.

Network diagram
Figure 26 Network for a DCC application with MP
Dialer0
NT 1 8810048
100.1.1.1 /24
Dialer0
Router A BRI1/1 NT 1 100.1.1.2 /24 Router B
8810052 E 1 2/0
ISDN
BRI1 /0
8810049
NT 1
account userb for Router B and configure PPP authentication for it; and set traffic
statistics interval to three seconds for DCC.
[RouterA] dialer flow-interval 3
# Assign an IP address to interface Dialer0, enable RS-DCC, and configure MP.

[RouterA-Dialer0] ppp mp
[RouterA-Dialer0] dialer threshold 50
# Configure information for PPP authentication, the remote user allowed to call in
and the dial strings on interface Dialer0.

# Configure PPP authentication on BRI 1/1 and assign it to dialer bundle 1.

[RouterA-Bri1/1] ppp mp


# Configure PPP authentication on BRI 1/0 and assign it to dialer bundle 1.
[RouterA-Bri1/0] interface bri 1/0

[RouterA-Bri1/0] ppp mp
account usera for Router A and configure PPP authentication for it; and set traffic
statistics interval to three seconds for DCC.
[RouterB] dialer flow-interval 3
# Assign an IP address to interface Dialer0; enable C-DCC; and configure the dial
strings, MP, and information for PPP authentication.

[RouterB-Dialer0] dialer enable-circular
[RouterB-Dialer0] dialer route ip 100.1.1.1 8810048
[RouterB-Dialer0] dialer route ip 100.1.1.1 8810049
[RouterB-Dialer0] ppp mp
# Configure CE1/PRI interface E1 2/0 and set it to work in PRI mode.
[RouterB] controller e1 2/0

[RouterB-E1 2/0] pri-set
[RouterB-E1-2/0] quit
# Enable C-DCC on interface Serial 2/0:15 created on interface E1 2/0 and assign
the serial interface to interface Dialer 0.
[RouterB] interface serial 2/0:15

[RouterB-Serial2/0:15] dialer enable-circular
[RouterB-Serial2/0:15] dialer circular-group 0
DCC for Dialup ISDN BRI Network requirements

Line and Leased Line Figure 27 presents a scenario where:
Connection

■ On Router A, the B2 channel on interface BRI 1/0 is connected to the B1

channel on interface BRI 1/0 on Router C to provide a leased line, whereas the
B1 channel is connected to Router B through dialup.
■ Interface BRI 1/0 on Router A is assigned the IP address of 100.1.1.1/24,
interface BRI 1/0 on Router B the IP address of 100.1.1.2/24, and interface BRI
1/0 on Router C the IP address of 100.1.1.3/24.
■ In the ISDN network, virtual circuit mappings are set up on the switches
connected to Router A and Router to ensure that they can connect to the ISDN
network.
Configure C-DCC to allow Router A to call Router B and Router C and vice versa.
Network diagram
Figure 27 Network diagram for using DCC with dialup ISDN BRI and leased line
NT 1 Router B
BRI1/0
8810052 100 .1.1.2/24
Router A NT 1
8810048
ISDN
BRI1/0
100 .1.1.1/24
NT 1 Router C
BRI1/0
100 .1.1.3/24
[RouterA-Bri1/0] dialer isdn-leased 1
[RouterC-Bri1/0] ip address 100.1.1.3 255.255.255.0


[RouterC-Bri1/0] dialer isdn-leased 1
Router-to-Router Network requirements

Callback with DCC (PPP Figure 28 presents a scenario where:
Approach)
■ Router A and Router B are interconnected via serial interfaces across PSTN.
■ Interface Serial 2/0 on Router A is assigned the IP address of 100.1.1.1/24 and
interface Serial 2/0 on Router B is assigned the IP address of 100.1.1.2/24.
Implement PPP callback between Router A and Router B, specifying Router A as

the callback client and Router B as the callback server.
Network diagram
Figure 28 Network for DCC in router-to-router callback
Router A S2 /0 Modem Modem Router B

S2/0
100 .1 .1.1/24 8810048 8810052 100.1.1.2/24
PSTN
Callback Callback
Client Server
Solution 1: Use C-DCC to implement PPP callback, allowing the callback server to
make callback decision based on usernames configured in the dialer route
commands.
# Assign an IP address to interface Serial 2/0, configure its physical layer and
C-DCC parameters.

[RouterA-Serial2/0] ip address 100.1.1.1 255.255.255.0
[RouterA-Serial2/0] dialer enable-circular
[RouterA-Serial2/0] dialer-group 1
[RouterA-Serial2/0] dialer route ip 100.1.1.2 8810052
# Specify interface Serial 2/0 as the callback client.
[RouterA-Serial2/0] ppp callback client

[RouterA-Serial2/0] dialer timer enable 15
# Configure the user interface to be used and enable modem dialup on it.


# Configure a dial access control rule for dialer access group 2; and create a local
user account usera for Router A and configure PPP authentication for it.
C-DCC parameters.

# Specify the local end as the callback server, and set the callback reference to
user. In this case, DCC identifies the dial string for callback according to the
username configured in the dialer route command.
[RouterB-Serial2/0] dialer callback-center user

[RouterB-Serial2/0] dialer route ip 100.1.1.1 user usera 8810048
[RouterB-Serial2/0] ppp callback server

Solution 2: Use C-DCC to implement PPP callback, allowing the callback server to
identify the dial string for callback by comparing the remote username received in
PPP authentication against the local user database for a match.
C-DCC parameters.



# Specify interface Serial 2/0 as the callback client.
[RouterA-Serial2/0] ppp callback client

[RouterA-Serial2/0] dialer timer enable 15

account usera for Router A and configure PPP authentication for it; and configure
the dial string for callback.
[RouterB-luser-usera] service-type ppp callback-number 8810048
# Assign an IP address to interface Serial 2/0, and configure physical and C-DCC
parameters.

[RouterB-Serial2/0] dialer route ip 100.1.1.1 user usera 8810048
# Specify the local end as the callback server, and set the callback reference to dial
number. In this case, DCC identifies the dial string for callback by comparing the
remote username obtained through PPP authentication against the local user
database for a match.
[RouterB-Serial2/0] dialer callback-center dial-number

[RouterB-Serial2/0] ppp callback server


Router-to-Router Network requirements

Callback with DCC (ISDN Figure 29 presents a scenario where:
Approach)
■ Router A and Router B are interconnected via ISDN BRI interfaces across an
ISDN network.
■ Interface BRI 1/0 on Router A is assigned the IP address of 100.1.1.1/24 and
interface BRI 1/0 on Router B is assigned the IP address of 100.1.1.2/24.
Configure ISDN caller identification callback with C-DCC between Router A and
Router B, specifying Router A as the callback client and Router B as the callback
server.
Network diagram
Figure 29 Network diagram for ISDN caller identification callback with DCC
# Assign an IP address to interface BRI 1/0, and configure C-DCC parameters and
the dial string for placing calls to Router B.

[RouterA-Bri1/0] dialer timer enable 15
# Assign an IP address to interface BRI 1/0, and configure C-DCC parameters and
the dial string for placing calls to Router A.


# Enable the local end to place return calls for ISDN calling number 8810048.
[RouterB-Bri1/0] dialer call-in 8810048 callback
Router-to-PC Callback Network requirements

with DCC Figure 30 presents a scenario where:
■ PC and Router are interconnected through modems across a PSTN network.
■ Interface Serial 2/0 on Router is assigned the IP address of 100.1.1.1/24.
■ PC accepts the address assigned by Router.
Configure PPP callback with C-DCC between Router and PC, specifying PC as the
callback client and Router as the callback server to make return calls according to
dialer routes.
Network diagram
Figure 30 Network diagram for router-to-PC callback with DCC
PC
Modem Modem Router
S 2/0
100 .1. 1. 2/24 8810048 8810052 100.1 . 1.1 /24
PSTN
Callback Client Callback Server
1 Configure PC (installed with Windows 2000 for example)
Do the following to create a dialup connection with callback capability enabled:
# Place the modem connected to PC in auto answer mode.
# Select [Start/Programs/Accessories/Communications/Network and Dial-up

Connections]. In the [Network and Dial-up Connections] window, right-click on
the Make New Connection icon; and in the popup menu select the New
Connection...option. The [Network Connection Wizard] window appears. Click
<Next>.
# In the [Network Connection Type] dialog, select the Dial-up to the Internet
option, and click <Next>. The [Internet Connection Wizard] dialog appears. Select
to set up the Internet connection manually. Click <Next>.
# In the [Setting up your Internet connection] dialog box, select the I connect
through a phone line and a modem option. Click <Next> to set Internet
account connection information.
# Type in the phone number for dialing to the callback server. Click <Next>.
# Type in the username and password that you want to use for PPP authentication
when connecting to the server. Click <Next>.

# Assign a name to your new connection and follow the instruction to complete
the connection setup.
# In the [Network and Dial-up Connections] window, right-click on the connection

just created, and in the popup menu select the Properties option.
# In the properties setting dialog, select the [Networking] tab. In the Type of
dial-up server I am calling drop-down list, select PPP: Windows 95/98/NT4/2000,
Internet. Click <Settings> to do the following:
■ Select the Enable LCP extensions check box.

■ Unselect the Enable software compression check box.
■ Unselect the Negotiate multi-link for single link connections check box.
Click <OK>.
# Turn to the [ Network and Dial-up Connections] window. Click on the

connection icon you just created. Then, from the menu bar, select
[Advanced/Dial-up Preferences...]. In the [Dial-up Preferences] dialog, select the
[Callback] tab and do one of the following:
■ Select the No callback option. After the PPP authentication is passed in a call,
this option prevents the callback server from disconnecting the current
connection and calling back. Instead, the server will maintain the current
connection and allow the client to access the LAN or the Internet.
■ Select the Ask me during dialing when the server offers option. The
callback server will use the callback number you input to place return calls.
■ Select the Always call me back at the number(s) below option. The
callback server will place return calls always at the number or numbers already
set.
2 Configure Router
account userpc for PC and configure PPP authentication for the account.
<Router> system-view
[Router] dialer-rule 1 ip permit
[Router] local-user userpc
[Router-luser-userc] password simple userpc
[Router-luser-userc] service-type ppp
[Router-luser-userc] quit
# Assign an IP address to interface Serial 2/0, and configure physical layer

parameters.
[Router] interface serial 2/0

[Router-Serial2/0] ip address 100.1.1.1 255.255.255.0
[Router-Serial2/0] physical-mode async
[Router-Serial2/0] async mode protocol
# Configure PPP encapsulation and other PPP parameters on the interface.

[Router-Serial2/0] link-protocol ppp

[Router-Serial2/0] ppp authentication-mode pap
[Router-Serial2/0] ppp pap local-user Sysname password simple Sysname
# Configure the interface to assign an IP address to the remote end.
[Router-Serial2/0] remote address 100.1.1.2
# Specify interface Serial 2/0 as the PPP callback server, and set the callback
reference to user mode. In this case, DCC uses the dial string corresponding to the
username configured in the dialer route command to place return calls.
[Router-Serial2/0] ppp callback server

[Router-Serial2/0] dialer callback-center user
# Enable C-DCC on interface Serial 2/0 and configure C-DCC parameters.
[Router-Serial2/0] dialer enable-circular

[Router-Serial2/0] dialer-group 1
[Router-Serial2/0] dialer route ip 100.1.1.2 user userpc 8810048
[Router-Serial2/0] quit
[Router] user-interface tty1

[Router-ui-tty1] modem both
NT Server-to-Router Network requirements

Callback with DCC Figure 31 presents a scenario where:
■ Router and NT Server are interconnected via modems across a PSTN network.
■ NT Server is assigned the IP address of 100.1.1.254/24.
■ Router accepts the address assigned by NT Server.
Configure PPP callback with C-DCC between Router and PC, specifying Router as
the callback client and NT Server as the callback server to make return calls
according to dialer routes.
Network diagram
Figure 31 Network diagram for NT server-to-router callback with DCC
NT Server
Router S2 /0 Modem Modem
100 .1.1.1/24 8810048 8810052 100 .1 .1.254 /24
PSTN
Callback client Callback server
1 Configure Router
account usernt for NT Server and configure PPP authentication for the account.

[Router] local-user usernt
[Router-luser-userc] password simple usernt
[Router-luser-userc] service-type ppp
[Router-luser-userc] quit
# Configure physical layer parameters for interface Serial 2/0.

# Configure PPP encapsulation and other PPP parameters.

[Router-Serial2/0] ppp authentication-mode pap
[Router-Serial2/0] ppp pap local-user Router password simple Router
# Configure the interface to obtain IP address through PPP negotiation.
[Router-Serial2/0] ip address ppp-negotiate
# Configure the interface as the PPP callback client.
[Router-Serial2/0] ppp callback client

[Router-Serial2/0] dialer timer enable 15
# Enable C-DCC and configure C-DCC parameters on the interface.

[Router-Serial2/0] dialer route ip 100.1.1.254 8810052
[Router] user-interface tty1

2 Configure NT Server
Note that for Microsoft Windows users, the server must be Windows 2000 and a
higher version such as Windows XP. For the purpose of this example, Windows
2000 is adopted.
Do the following to create a dialup connection with callback capability enabled:
# Right-click on the My Network Places icon and from the popup menu select the
Properties option. The [Network and Dial-up Connections] window appears.
# Right-click on the Make New Connection icon; and from the popup menu select
the New Connection...option. The [Network Connection Wizard] window
appears. Click <Next>.

# In the [Network Connection Type] dialog, select the Accept incoming

connections option, and click <Next> to set the device for incoming connections.
Click <Next>. The [Incoming Virtual Private Connection] window appears.
# Select the Allow virtual private connections option if the server is connected to
the Internet to provide Internet access requests for the client. If otherwise, select
the Do not allow virtual private connections. Then click <Next>.
# In the [Allowed Users] dialog, click <Add>. In the popup [New User] dialog add
the username and password for the PPP callback client and click <OK>. An icon
for the new user account appears in the box in the [Allowed Users] dialog.
# Select the new user and click <Properties>. The properties setting dialog
appears.
# Under the [Callback] tab, do one of the following:
■ Select the Do not allow callback option. After the PPP authentication is
passed in a call, this option prevents the callback server from disconnecting the
current connection and calling back. Instead, the server will maintain the
current connection and allow the client to access the LAN or the Internet.
■ Select the Allow the caller to set the callback number option. After the PPP
authentication is passed in a call, the server will disconnect and then call back
the client at the number configured in the ppp callback ntstring dial-number
command. This option is almost the same as the last option except that the
charges are paid by the server end rather than the client end.
■ Select the Always use the following callback number option to set a
callback number.
Click <OK>. The [Networking Components] dialog box appears.
# Set the Networking components (use the default). Click <Next>.
# Assign a name to your connection and Click <Finish> to complete the creation.
Circular Dial String Network requirements

Backup and Internet Figure 32 presents a scenario where:
Access with DCC
■ Router A and Router B are connected across a PSTN network.
■ Router B works as an access server and is configured with an IP address of
100.1.1.254/24. It uses the address range of 100.1.1.1/24 to 100.1.1.16/24 for
address assignment. The PSTN dial strings available on it are 8810048 through
8810055, allowing the router to provide services to 16 online users.
■ Router A accepts the IP address assigned by Router B.
Configure Router A on the dialup side to implement cyclic dial string backup with
dialer routes. Configure Router B on the access side to use asynchronous serial
interfaces to provide DCC dialup access and adopt PAP to authentication the
dialup side.
Figure 33 presents another scenario where Router C and Router D are connected
across an ISDN network. The configurations of Router C and Router D are the

same as those of Router A and Router B, except that Router D uses an ISDN dial
string 8810048, rather than PSTN dial strings, to provide services.
Configure Router C and Router D to implement DCC with one dial string and use
CHAP for authentication.
Network diagram
Figure 32 Network diagram for dial string backup/access service with DCC (PSTN)
Modem
8810048
Router A Modem
S2/0
Modem
8810049 Async1/0̚
Async1/7
ĂĂ Modem Router B
PSTN ĂĂ Internet
Modem
Modem
Host 8810054
Modem
8810055
Figure 33 Network diagram for dial string backup/access service with DCC (ISDN)
Router C
BRI1/0
NT 1
S2 /0:15 Router D
ĂĂ 100 .1.1.254/24
ISDN Internet
8810048
NT 1
Solution 1: Configure circular dial string backup on Router A on dialup side. On
Router B, configure C-DCC, allowing the router to set up connections on eight
asynchronous serial interfaces; configure C-DCC parameters on a dialer interface.
account userb for Router B and configure PPP authentication for the account.

# Configure physical layer parameters for interface Serial 2/0 and enable PPP
address negotiation.

[RouterA-Serial2/0] ip address ppp-negotiate
# Configure PPP encapsulation and authentication on the interface.

[RouterA-Serial2/0] ppp pap local-user user1 password simple user1
# On the interface, enable C-DCC, and configure C-DCC parameters and the dial
strings for reaching Router B.

...

accounts user1 through user16 and configure PPP authentication for the accounts.
[RouterB] local-user user1
[RouterB-luser-user1] password simple user1
[RouterB-luser-user1] service-type ppp
[RouterB-luser-user1] quit
...

# Assign an IP address to interface Dialer0 and configure it to assign IP addresses

for PPP users.

[RouterB-Dialer0] link-protocol ppp
[RouterB-Dialer0] remote address pool 1
# Enable C-DCC and configure C-DCC parameters on the interface.
[RouterB-Dialer0] dialer enable-circular

# Configure physical and link layer parameters for interface Async 1/0.
[RouterB] interface async 1/0

[RouterB-Async1/0] async mode protocol
[RouterB-Async1/0] dialer circular-group 0
[RouterB-Async1/0] link-protocol ppp
[RouterB-Async1/0] ppp authentication-mode pap
[RouterB-Async1/0] ppp pap local-user userb password simple userb
[RouterB-Async1/0] quit
Repeat this step to configure physical and link layer parameters for interfaces
Async 1/1 through Async 1/7.
# Configure user interfaces TTY 1 through TTY 7 for interfaces Async 1/0 through
Async 1/7 and enable modem dialup on them.

[RouterB-ui-tty1] quit
...
[RouterB-ui-tty8] quit
# Configure the address for address assignment.
[RouterB] domain system

[RouterB-isp-system] ip pool 1 100.1.1.1 100.1.1.16
[RouterB-isp-system] quit
3 Configure user PC
# Set the answering mode of the modem connected to the user PC (installed with
Windows 2000 for example) to auto answer.

Connections]. In the [Network and Dial-up Connections] window, create a new
connection.

Connections]. In the [Network and Dial-up Connections] window, right-click on

the Make New Connection icon; and in the popup menu select the New
Connection...option. The [Network Connection Wizard] window appears. Click
<Next>.
# In the [Network Connection Type] dialog, select the Dial-up to the Internet
option, and click <Next>. The [Internet Connection Wizard] dialog appears. Select
to set up the Internet connection manually. Click <Next>.
# In the [Setting up your Internet connection] dialog box, select the I connect
through a phone line and a modem option. Click <Next> to set Internet
account connection information.
# Type in the phone number for dialing to the callback server. Click <Next>.
# Type in the username (user16 for example) and password (user16 for example)
that you want to use for PPP authentication when connecting to the server. Click
<Next>.
# Assign a name to your new connection and follow the instruction to complete
the connection setup.
# In the [Network and Dial-up Connections] window, right-click on the connection

just created, and in the popup menu select the Properties option.
# In the properties setting dialog, select the [Networking] tab. In the Type of
dial-up server I am calling drop-down list, select PPP: Windows 95/98/NT4/2000,
Internet. Click <Settings> to do the following:
■ Select the Enable LCP extensions check box.

■ Unselect the Enable software compression check box.
■ Unselect the Negotiate multi-link for single link connections check box.
Click <OK>.
# Turn to the [ Network and Dial-up Connections] window. Click on the

connection icon you just created. Then, from the menu bar, select
[Advanced/Dial-up Preferences...]. In the [Dial-up Preferences] dialog, select the
No callback option under the [Callback] tab.
Double-click the created connection to dial.
Solution 2: On Router C on the dialup side configure a single dial string. On Router
D on the access side, use C-DCC approach to set up connection with Router C
through an ISDN PRI interface; configure DCC parameters on a dialer interface.
account userd for Router D and configure PPP authentication for the account.
[RouterC] local-user userd
[RouterC-luser-userd] password simple user1

[RouterC-luser-userd] service-type ppp

[RouterC-luser-userd] quit
# Configure physical layer parameters for interface BRI 1/0 and enable PPP address
negotiation.

[RouterC-Bri1/0] ip address ppp-negotiate
# Configure PPP encapsulation and PPP CHAP authentication on the interface.
[RouterC-Bri1/0] link-protocol ppp

[RouterC-Bri1/0] ppp authentication-mode chap
[RouterC-Bri1/0] ppp chap user user1
# On the interface enable C-DCC, and configure C-DCC parameters and the dial
string for reaching Router D.

[RouterC-Bri1/0] dialer route ip 100.1.1.254 8810048
5 Configure Router D
accounts user1 through user16 and configure PPP CHAP authentication for the
accounts.
<RouterD> system-view
[RouterD] dialer-rule 2 ip permit
[RouterD] local-user user1
[RouterD-luser-user1] password simple user1
[RouterD-luser-user1] service-type ppp
[RouterD-luser-user1] quit
...
# Set CE1/PRI interface E1 2/0 to work in PRI mode.
[RouterD] controller e1 2/0

[RouterD-E1 2/0] pri-set
[RouterD-E1 2/0] quit
# Enable C-DCC on interface Serial 2/0:15. (This interface is automatically created

on CE1/PRI interface E1 2/0.)
[RouterD-E1 2/0] interface serial 2/0:15

[RouterD-Serial2/0:15] dialer enable-circular
[RouterD-Serial2/0:15] dialer-group 2
# Assign an IP address to the serial interface.

[RouterD-Serial2/0:15] ip address 100.1.1.254 255.255.255.0
# Configure PPP encapsulation and other PPP parameters on the serial interface.
[RouterD-Serial2/0:15] link-protocol ppp

[RouterD-Serial2/0:15] ppp authentication-mode chap
[RouterD-Serial2/0:15] ppp chap user userd
[RouterD-Serial2/0:15] remote address pool 1
[RouterD-Serial2/0:15] quit
# Configure an IP address pool for assigning addresses to PPP users.
[RouterD] domain system

[RouterD-isp-system] ip pool 1 100.1.1.1 100.1.1.16
[RouterD-isp-system] quit
Troubleshooting This section covers these topics:

■ “Troubleshooting Cases” on page 208
Troubleshooting Cases Symptom 1:
DCC dialup connection cannot be set up because the modem does not dial when
the router forwards data.
Solution:
Check that:
■ The modem and phone cable connections are correct, and the modem
initialization process is correct.
■ The dial interface, if it is synchronous/asynchronous, is set to work in
asynchronous protocol mode.
■ DCC is enabled on the dial interface.
■ A dialer route or dialer number command is available for the packets.
Symptom 2:
The remote end cannot be pinged after the modem is connected.
Solution:
Check that:
■ The same link layer encapsulation is adopted at the two ends, and correct PPP
parameters are configured for authentication. You may use the debugging
ppp all command to verify that.
■ Correct IP address is assigned to the dial interface (physical or dialer).
■ DCC is enabled on the dial interface.
■ The correct dialer-group and dialer-rule commands are configured and
associated to ensure that the packets can pass.

Troubleshooting 209
■ Use the debugging dialer event and debugging dialer packet commands
to locate the problem.


DLSW CONFIGURATION
7
DLSw Overview
Introduction Data link switching (DLSw) was jointly developed by Advanced Peer-to-Peer
Networking (APPN) and Implementers Workshop (AIW) for transmitting Systems
Network Architecture (SNA) traffic over a TCP/IP network. SNA was developed by
IBM in correspondence with the OSI reference model. The DLSw technique is a
solution for cross-WAN transmission of SNA traffic.
The DLSw mechanism is shown in the following figure:
Figure 34 DLSw mechanism
LAN TCP/IP LAN
LLC2 SSP LLC2

Terminal Router A Router B Terminal
1 The router that runs DLSw converts logical link control type 2 (LLC2) frames from
the local SNA device into Switch-to-Switch Protocol (SSP) frames that can be
encapsulated in TCP packets,
2 The SSP frames are forwards across the WAN over a TCP connection to the remote
router
3 The remote router converts the SSP frames back into LLC2 frames and sends them
to the peer SNA device.
As a result, the remote SNA device appears to be on the same network with the
local SNA device.
DLSw is different from transparent bridging in that it does not forward LLC2
frames transparently to the peer - instead it converts the LLC2 frames into SSP
frames for data encapsulation in TCP packets. The local termination mechanism of
DLSw eliminates the requirement for link layer acknowledgments and keepalive
messages to flow across a WAN. It also solves the data link control timeout
problem.
DLSw also enables transmission of synchronous data link control (SDLC) traffic
across a TCP/IP WAN by first converting SDLC frames to LLC2 frames, and then
transporting them to the remote end system through SSP. Thus, DLSw can be used
for interconnection between LAN and SDLC media.
Currently, two DLSw versions are available: version 1.0 and version 2.0. DLSw v1.0
is implemented based on RFC1795, while DLSw v2.0 is implemented based on
RFC2166 and is intended to improve product maintainability and to reduce

212 CHAPTER 7: DLSW CONFIGURATION
network cost. In addition, DLSw v2.0 provides enhancements by means of UDP

explorer frames sent in multicast and unicast modes. When the peer is also
running DLSw v2.0, the two ends can use UDP packets to explore reachability, and
a TCP connection is established only when data transmission is required.
n ■
■
SDLC is a data link layer protocol developed by IBM for IBM SNA networks.
For more information on LLC, refer to IEEE 802.2 standard.
Differences between Problems with DLSw v1.0

DLSw v1.0 and DLSw ■ TCP connection
v2.0
In DLSw v1.0, immediately after a pair of peers is configured, the local peer
attempts to establish a TCP connection with the remote peer (by first establishing
two TCP connections and bringing down one of them after capabilities exchange),
regardless whether a connection is needed. All packets, including explorer frames,
circuit setup requests and data packets, are transmitted over the TCP connection.
This wastes network resources.
■ Excessive broadcasts
Although a local acknowledgement mechanism is provided in DLSw v1.0, explorer

frames may flood the WAN over the established TCP connections if the
reachability table of DLSw contains a small number of entries or no entries.
■ Low maintainability
When a circuit is disconnected, DLSw v1.0 uses two types of messages to notify
the peer but cannot tell the disconnection cause. This adds to difficulty in locating
the reason for an abnormal circuit disconnection.
Enhancements in DLSw v2.0

DLSw v2.0 provides enhancements to address the above-mentioned problems
while it remains compatible with DLSw v1.0.
The components on a DLSw network are defined as follows:
Figure 35 DLSw v2.0 network
Origin LAN Origin DLSw UDP, TCP/IP Target DLSw LAN Target
station router router station
SSP message
In Figure 35, the origin station is the end station that originates communication,
the target station is the end station that accepts communication, the origin DLSw
router is a DLSw-enabled router connected to the origin station, and the target
DLSw router is a DLSw-enabled router connected to the target station. In this
document, an origin DLSw v2.0 router is a DLSw v2.0-capable router.
■ Using UDP packets to explore peer addresses
To prevent unnecessary TCP connection setups, DLSw v2.0 sends explorer frames
by using UDP packets instead of over TCP connection, unless a TCP connection is
present). These UDP packets can be sent in two ways: multicast and unicast

(depending on the specific situation). Using UDP packets reduces, to some degree,
the TCP connections required, and thereby saves network resources.
■ Setting up a single TCP connection when required
A TCP connection is set up after the origin and target DLSw v2.0 routers get
reachability information using UDP packets and when both the origin and target
stations want to set up a circuit between them. A DLSw circuit establishment
process is simplified into two stages: first, establishment of a single TCP
connection; then, capabilities exchange. If capabilities negotiation fails, the
source-end DLSw v2.0 router sends a reject packet to the peer and then the TCP
connection is taken down.
As a TCP connection is established only when a circuit is required between two

end systems, the overheads of establishing and maintaining TCP connections are
reduced, resulting in better system resource utilization.
n In case the origin and target DLSw routers use different versions of DLSw, for
backward compatibility, the one uses DLSw v2.0 works as a DLSw v1.0 router and
follows RFC1795 when setting up a TCP connection with its peer.
■ Enhanced maintainability
To enable a DLSw router to notify its peer about the reason for dropping a
connection, DLSw v2.0 defines five generic circuit halt reason codes: unknown
error, received DISC from end-station, detected DLC error with end-station,
circuit-level protocol error, and operator-initiated. The halt reason codes are sent
to the peer in SSP messages.
Related Specifications DLSw is documented in:

■ RFC 1795: Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG:
DLSw Closed Pages, DLSw Standard Version 1.0.
■ RFC 2166: APPN Implementer’s Workshop Closed Pages Document DLSw V2.0
Enhancements.
Configuring DLSw in Follow these steps to configure DLSw in an Ethernet environment:

an Ethernet
Environment To do... Use the command... Remarks
Enable bridging bridge enable Required
Enable a bridge set bridge bridge-set enable Required
Enable DLSw dlsw enable Optional
Enabled by default
Create a DLSw peer Refer to “Creating DLSw Peers” Required
on page 214
Configure a bridge set Refer to “Mapping a Bridge Set Required
connected to the DLSw to DLSw” on page 215
Add an Ethernet interface to Refer to “Adding an Ethernet Required
the bridge set Interface to a Bridge Set” on
page 215


Set DLSw timers Refer to “Setting DLSw Timers” Optional
on page 215
Configure LLC2 parameters Refer to “Configuring LLC2 Optional
Parameters” on page 216
Enable the multicast function Refer to “Enabling the Multicast Optional
of DLSw v2.0 Function of DLSw v2.0” on page
217
Configure the maximum Refer to “Configuring the Optional
attempts of sending an Maximum Number of DLSw v2.0
explorer frame in DLSw v2.0 Explorer Retries” on page 217
Apply an ACL in DLSw so that Refer to “Applying an ACL in Optional
DLSw handles only Ethernet DLSw” on page 217
frames that match the ACL
Configure local reachable Refer to “Configuring Local Optional
MAC or SAP addresses Reachable MAC or SAP
Addresses” on page 224
Configure the remote Refer to “Configuring Remote Optional
reachability information for Reachability Information” on
the router page 224
For more information on bridge and bridge set configuration, refer to “Bridging
Creating DLSw Peers Establishing a TCP connection is the first step in establishing a DLSw circuit. To
establish a TCP connection, you need to specify the IP addresses of both end
systems across the TCP connection.
Before the local router can initiate or accept a TCP connection request, you need
to configure a local DLSw peer specifying the IP address of the local end of the
TCP connection. A router can only have one local peer.
After a local peer is created, a remote DLSw peer should be created to establish a
TCP connection. The following command specifies the IP address of the remote
router with which a TCP connection is to be established. After the configuration,
the router will keep attempting to establish a TCP connection with the remote
router. A router can have multiple remote peers. A local DLSw peer must be
created before you can create a remote DLSw peer for it.
Follow these steps to create DLSw peers:

Create a local dlsw local ip-address [ init-window Required
DLSw peer init-window-size | keepalive
The IP address specifies with
keepalive-interval | max-frame
ip-address must be a
max-frame-size | max-window
reachable IP address of the
max-window-size | permit-dynamic |
local host
vendor-id vendor-id ] *


Create a remote dlsw remote ip-address [ backup Required
DLSw peer backup-address | keepalive
The IP address specified with
keepalive-interval | linger minutes |
the ip-address argument must
max-frame max-frame-size |
be a reachable IP address of
max-queue max-queue-length | priority
the remote DLSw router.
priority ] *
Removing a local DLSw peer will remove all its remote DLSw peers at the same
time.
Mapping a Bridge Set to DLSw was developed based on the bridging technology. Bridging between
DLSw different Ethernet interfaces is possible if these interfaces are configured in the
same bridge set. To enable forwarding frames of a bridge set to a remote end
system over a TCP connection, use the following command to map the bridge set
to DLSw. This command can be used repeatedly to map multiple bridge sets to
DLSw.
Follow these steps to map a bridge set connected to DLSw:

Map a bridge set to dlsw bridge-set bridge-set Required
DLSw
By default, no bridge set is mapped to be
connected to the DLSw.
This command should be used in
conjunction with the bridge bridge-set
enable command, with the same
bridge-set value in both commands.
Adding an Ethernet By adding an Ethernet interface to a bridge set and mapping the bridge set to
Interface to a Bridge Set DLSw, you can enable transmission of LLC2 frames on the Ethernet interface to a
remote end system over a TCP connection.
n For details about bridge set configuration, refer to “Bridging Configuration” on

page 405.
Setting DLSw Timers You can configure the timers used in creating DLSw circuits as per your actual
needs.
Follow these steps to set DLSw timers:



Configure DLSw dlsw timer { cache | Required
timer parameters connected | explorer |
Defaults:
explorer-wait |
local-pending | ■ cache: 120 seconds
remote-pending } seconds
■ connected: 300 seconds
■ explorer: 30 seconds
■ explorer-wait: 30 seconds
■ local-pending: 30 seconds
■ remote-pending: 30 seconds
Note that the timer values should be modified only when necessary.
Configuring LLC2 SNA was designed to transmit LLC2 frames over Ethernet. By means of LLC2
Parameters related commands, you can modify some LLC2 parameters.
Follow these steps to configure LLC2 parameters:

Enter interface view interface interface-type -
interface-number
Configure the maximum number of llc2 max-ack length Required
information frames the router can
3 by default
receive before it must send an
acknowledgement
Configure the maximum number of llc2 receive-window length Optional
consecutive information frames the
7 by default
router can send before receiving an
acknowledgement from the peer
Configure the length of LLC2 llc2 max-send-queue length Optional
output queue
50 by default
Configure the modulus value of llc2 modulo { 8 | 128 } Optional
LLC2
128 by default
Configure the number of LLC2 llc2 max-transmission retries Optional
transmission retries
3 by default
Configure the maximum LLC2 PDU llc2 max-pdu length Optional
Configure the LLC2 local llc2 timer ack-delay Optional
acknowledgment delay time mseconds
100 ms by default
Configure LLC2 acknowledgment llc2 timer ack mseconds Optional
waiting time
200 ms by default
Configure LLC2 busy-station polling llc2 timer busy mseconds Optional
interval
300 ms by default
Configure the LLC2 P/F waiting llc2 timer poll mseconds Optional
time
5,000 ms by default
Configure the LLC2 REJ status time llc2 timer reject mseconds Optional
500 ms by default


Configure the LLC2 POLL timer llc2 timer detect mseconds Optional
30,000 ms by default
Enabling the Multicast Before enabling the multicast function of DLSw v2.0, you first need to configure
Function of DLSw v2.0 the multicast function of the router and the local DLSw peer. DLSw v2.0 multicast
must be enabled before the origin DLSw v2.0 router can multicast SOCKET
messages (with explorer frames encapsulated) to a specific multicast address, so
that all target DLSw routers listening to the multicast address can receive the
SOCKET messages and get the explorer frames.
Follow these steps to enable the multicast function of DLSw v2.0:

Enable the multicast function dlsw multicast Required
of DLSw v2.0 [ multicast-ip-address ] interface
Disabled by default
interface-type interface-number
c CAUTION:
■ By default, the DLSw multicast function is disabled on devices running DLSw
v2.0. To enable this function, use the dlsw multicast command.
■ Before you can enable the DLSw multicast function, you need to configure the
outbound multicast interface specified with interface interface-type
interface-number in the above-mentioned command on the same interface as
the local DLSw peer.
■ Before the DLSw multicast can be enabled, you need to carry out the related
multicast command first.
Configuring the Each time the origin DLSw v2.0 router sends an explorer frame in a UDP multicast,
Maximum Number of it starts an explorer timer. If no response is received before the explorer timer times
DLSw v2.0 Explorer out, the router retransmits the explorer frame and resets the explorer timer. This
Retries process continues until a response is received or the maximum number of explorer
transmission retries is reached.
Follow these steps to configure the maximum of explorer transmission retries:

Set the maximum number of dlsw max-transmission retries Optional
explorer transmission retries
5 by default
Applying an ACL in Follow these steps to apply an ACL in DLSw:

DLSw


Create a MAC-based Layer acl number acl-number Required
2 ACL [ match-order { auto | config } ]
No Layer 2 ACL is configured
rule [ rule-id ] { deny | permit } by default.
[ fragment | logging | source
{ sour-addr sour-wildcard | any } |
time-range time-name |
vpn-instance
vpn-instance-name ] *
Apply a MAC-based ACL dlsw ethernet-frame-filter Required
on inbound and/or acl-number inbound
By default, no ACL is applied.
outbound traffic
dlsw ethernet-frame-filter
ACLs for inbound and
acl-number outbound
outbound traffic can be
configured at the same time
For details about creating a Layer 2 ACL, refer to ACL Configuration in the Security
Volume.
Configuring DLSw in
an SDLC Environment
Configuring DLSw Follow these steps to configure DLSw:

Enable DLSw dlsw enable Optional
Enabled by default
Create a DLSw peer Refer to “Creating DLSw Peers” on page Required
214
Configure an SDLC interface Refer to “Configuring an SDLC Interface” Required
on page 219
Enable DLSw forwarding on Refer to “Enabling DLSw Forwarding on Required
an SDLC interface an SDLC Interface” on page 219
Configure SDLC roles Refer to “Configuring SDLC Roles” on Required
page 219
Configure an SDLC address Refer to “Configuring an SDLC Address Required
for a secondary station for a Secondary Station” on page 220
Configure an SDLC peer Refer to “Configuring an SDLC Peer” on Required
page 221
Configure an SDLC XID Refer to “Configuring an SDLC XID” on Optional (required
page 221 for PU2.0 devices)
Configure an SDLC virtual Refer to “Configuring an SDLC Virtual Optional
MAC address MAC Address” on page 222
Configure the properties of a Refer to “Configuring the Properties of Optional
synchronous serial interface an Synchronous Serial Interface” on page
222
Configure optional SDLC Refer to “Configuring the Properties of Optional
parameters an Synchronous Serial Interface” on page
222


Configure optional SDLC Refer to “Configuring Optional SDLC Optional
Parameters Parameters” on page 223
Enable the multicast function Refer to “Enabling the Multicast Function Optional
of DLSw v2.0 of DLSw v2.0” on page 217
Configure the maximum Refer to “Configuring the Maximum Optional
number of DLSw v2.0 Number of DLSw v2.0 Explorer Retries”
explorer retries on page 217
Configure local reachable Refer to “Configuring Local Reachable Optional
MAC or SAP addresses MAC or SAP Addresses” on page 224
Configure the remote Refer to “Configuring Remote Optional
reachability information for Reachability Information” on page 224
the router
Configuring an SDLC The SDLC is a link layer protocol relative to the SNA. Its working principle is similar
Interface to that of HDLC. In order to make DLSw work normally, you need to configure an
SDLC interface by specifying SDLC as the link layer protocol on the synchronous
serial interface.
Follow these steps to configure an SDLC interface:

interface-number
Configure SDLC link-protocol sdlc Required
encapsulation on the
PPP encapsulation by default
interface
Note that the SDLC link layer protocol cannot underlie the IP protocol, so all the
IP-related configurations on the interface must be removed before you configure
SDLC encapsulation. For example, you need to delete the IP address of the
interface.
Enabling DLSw With DLSw forwarding enabled on the SDLC interface, all local SNA devices
Forwarding on an SDLC connected to the interface will be able to communicate with the remote device
Interface through DLSw.
Follow these steps to enable DLSw forwarding on an SDLC interface:

interface-number
Enable DLSw forwarding on sdlc enable dlsw Required
the interface
Disabled by default
Configuring SDLC Roles In contrast with HDLC, SDLC is an “unbalanced” link layer protocol. That is, the
end systems across a TCP connection are not equal in the positions: one is primary
and the other is secondary. The primary station, whose role is primary, plays a

dominant role and controls the whole connection process. The secondary station,
whose role is secondary, is controlled by the primary station. Therefore, we need
to configure a role for an SDLC interface.
In the SDLC role configuration, the role of an interface should be determined by

the role of the SDLC device to which this router is connected:
■ If the SDLC device connected with the local router has a role of primary, the
local interface should be configured to have a role of secondary;
■ If the SDLC device connected with the local router has a role of secondary, the
local interface should be configured to have a role of primary.
Generally, an IBM mainframe has a role of primary, while a terminal device such
as a UNIX host or an Auto Teller Machine (ATM) has a role of secondary.
Follow these steps to configure an SDLC role:

interface-number
Configure an SDLC role sdlc status { primary | Required
secondary }
By default, no SDLC role is
configured.
Configuring an SDLC The SDLC protocol allows multiple virtual circuits to run on an SDLC physical link,
Address for a Secondary with one end connected to the primary station and the other end to a secondary
Station station. In order to distinguish different virtual circuits, you need to specify an
SDLC address for each virtual circuit. SDLC is an “unbalanced” protocol, a primary
station can be connected with multiple secondary devices through a multi-user
system or an SDLC switch, while the secondary devices cannot be connected with
one another. Therefore, the communication between the primary station and each
secondary station can be guaranteed as long as each secondary device is identified
with an SDLC address.
The following command is used to specify an SDLC address for a virtual circuit,
which is unique on a physical interface. The configured SDLC address on a
synchronous serial interface is actually the address of the secondary SDLC station.
On the serial interface of the DLSw router connected with the primary SDLC
station, you need to configure the address of each secondary SDLC station that
communicates with the primary station. On the serial interface of the DLSw router
connected with a secondary SDLC station, you need to configure the address of
each secondary SDLC station connected with the serial interface.
An SDLC address ranges from 0x01 to 0xFE. The SDLC address of a router is valid
on only one physical interface. That is, the SDLC addresses configured on different
interfaces may be the identical.
Follow these steps to configure an SDLC address:


interface-number
Configure the address of an sdlc controller sdlc-address Required
secondary SDLC station
By default, no secondary
SDLC station address is
configured.
Configuring an SDLC The following command is used to specify the MAC address of the corresponding
Peer peer end for an SDLC virtual circuit so as to provide the destination MAC address
for SDLC-to-LLC2 frame conversion. In DLSw configuration, a peer should be
configured for each SDLC address. The MAC address of the peer should be the
MAC address of the remote SNA device (physical address in the Ethernet or Token
Ring format), or the compound MAC address derived from SDLC virtual MAC
address of the peer end and the SDLC address of the local end.
Follow these steps to configure the SDLC peer:

Configure MAC address dlsw reverse mac-address Optional
reversal
interface-number
Configure an SDLC peer sdlc mac-map remote Required
mac-addr sdlc-addr
By default, no SDLC peer is
configured.
n When specifying an SDLC peer MAC address for an SDLC virtual circuit, pay
attention to the difference between a token ring address and an Ethernet address:
■ If the remote SNA device uses a token ring address, use its token ring address
directly;
■ If the remote SNA device uses an Ethernet address, revert each octet of the
Ethernet address, for example, convert 00e0.fc03.a548 to 0007.3fc0.a512, by
using the dlsw reverse command.
Configuring an SDLC XID An XID is used to identify a device in an SNA system. When configuring an SDLC
connection, pay attention to the types of the connected SNA devices. Generally,
there are two types of devices in an SNA system: PU2.0 and PU2.1. An XID has
been configured on PU2.1 devices, so they can announce their identity by
exchanging the XID. A PU2.0 device does not come with an XID. Therefore, an XID
is not required on a PU2.1 device, but it is required on a PU2.0 device.
Follow these steps to configure an SDLC XID:



interface-number
Configure an SDLC XID sdlc xid sdlc-address Optional
xid-number
By default, no SDLC XID is configured
on a synchronous serial interface.
Configuring an SDLC Initially designed for LLC2 protocols, DLSw establishes mappings with virtual
Virtual MAC Address circuits through MAC addresses. Therefore, a MAC address must be specified for
an SDLC virtual circuit so that SDLC frames can be forwarded. Use the following
command to assign the current interface a virtual MAC address on an interface,
which will serve as the source MAC address during the conversion of SDLC frames
to LLC2 frames.
Follow these steps to configure an SDLC virtual MAC address:

interface-number
Configure an SDLC virtual sdlc mac-map local Optional
MAC address mac-address
No virtual MAC address by
default
n Note that the sixth byte of the MAC address should be set to 0x00. The system will
combine the first five bytes of this virtual MAC address with the SDLC address into
a new MAC address, which will serve as the source MAC address in SDLC-to-LLC2
frame format conversion.
Configuring the In practice, there are many types of SNA devices which differ from one another
Properties of an significantly. The following commands are used to tune some commonly used
Synchronous Serial parameters to ensure the compatibility among different devices.
Interface ■ Configure the encoding scheme of the synchronous serial interface
There are two encoding schemes, NRZI and NRZ, for synchronous serial interface.
The NRZ encoding scheme is generally used for synchronous serial interfaces of
routers. The serial interfaces of some SNA devices, however, use the NRZI
encoding scheme. Therefore, the encoding scheme of routers should be changed
according to the encoding schemes used on the connected devices.
■ Configure the idle-time encoding scheme of the synchronous serial interface
While most SDLC devices use “0x7E” (flags) to indicate “idle” space between
frames, some other SDLC devices use “0xFF” (marks) for this indication. For
compatibility with different types of devices, you can configure the router to send
either flags (default) or marks to indicate its idle state.
Follow these steps to configure the properties of the synchronous serial interface:


interface-number
Configure the baud rate of the baudrate baudrate Optional
synchronous serial interface
9,600 bps by default
Configure the synchronous serial code nrzi Optional
interface to use NRZI encoding
NRZ encoding by default
Configure the synchronous serial idle-mark Optional
interface to send 0xFF (marks)
0x7E by default
during idle state
Generally it is not required to change the idle-time encoding scheme of a

synchronous serial interface, except when the synchronous serial interface is
connected to an AS/400 device.
Configuring Optional Follow these steps to configure optional SDLC parameters:

SDLC Parameters
interface-number
Configure the length of SDLC sdlc max-send-queue length Optional
output queue
50 by default
Configure the maximum sdlc window length Optional
number of consecutive frames
7 by default
the device can send before
receiving an
acknowledgement from the
peer
Configure the modulus value sdlc modulo { 8 | 128 } Optional
of SDLC
8 by default
Configure the maximum sdlc max-pdu number Optional
SDLC PDU size
The maximum PDU size of
some PU2.0 devices is 265
bytes, while that of an IBM
AS/400 is 521 bytes. Typically,
this maximum PDU size
should be configured be the
same as on the peer SDLC
device.
Configure the maximum sdlc max-transmission Optional
number of SDLC transmission retries
20 by default
retries
Configure the local and sdlc sap-map local lsap Optional
remote SAP addresses for sdlc-addr
0x04 by default.
SDLC-to-LLC2 frame
sdlc sap-map remote dsap
conversion
sdlc-addr


Enable SDLC simultaneous sdlc simultaneous Optional
mode
Alternate mode by default
Generally, this configuration is
not required.
Configure the SDLC polling sdlc timer poll mseconds Optional
interval
1,000 ms by default.
Configure the amount of time sdlc timer ack mseconds Optional
the primary SDLC station
3,000 ms by default
waits for an acknowledgment
from the receiving secondary
station
Configure the amount of time sdlc timer lifetime mseconds Optional
a secondary SDLC station
500 ms by default
waits for an acknowledgment
from the receiving primary
station
n A SAP address refers to the address of one or more applications running on a

computer or network device.
Configuring Local To reduce the exploring time before the routers send information frames when
Reachable MAC or SAP network topology is stable, you can manually configure the local reachable MAC
Addresses addresses or SAP addresses.
Follow these steps to configure the local reachable MAC addresses or SAP
addresses:

Specify a local reachable MAC dlsw reachable Required
address or SAP address { mac-address mac-address
No local reachable MAC or
[ mask mask ] |
SAP addresses are configured
mac-exclusivity | saps
by default.
saps-list }
Configuring Remote To reduce the exploring time before the routers send information frames when
Reachability network topology is stable, you can manually configure the reachability
Information information of the remote end for the router.
Follow these steps to configure the remote reachability information:

Configure the reachability dlsw reachable-cache Required
information of the remote mac-address remote
No remote reachability
end ip-address
information is configured by
default.

Displaying and Debugging DLSw 225
Displaying and
Debugging DLSw To do... Use the command... Remarks
Display the capabilities display dlsw information Available in any view
exchange information [ ip-address | local ]
Display the information of a display dlsw circuits [circuit-Id ] Available in any view
virtual circuit or all virtual [ verbose ]
circuits
Display the information of a display dlsw remote Available in any view
remote peer or all remote peers [ ip-address ]
Display the reachability display dlsw reachable-cache Available in any view
information list of DLSw
Display LLC2 statistics display llc2 [ circuit circuit-id ] Available in any view
information
Reset the TCP connection(s) reset dlsw tcp [ ip-address ] Available in user view
between the DLSw router and a
remote peer or all remote peers
Clear the information of a reset dlsw circuits [ circuit-id ] Available in user view
virtual circuit or all virtual
circuits
Clear the reachability reset dlsw reachable-cache Available in user view
information list of DLSw
DLSw Configuration
Examples
Configuring LAN-to-LAN Network requirements

DLSw As illustrated in Figure 36, DLSw works in a LAN-LAN environment. Configure
DLSw on Router A and Router B to enable communication between an IBM host
with an SNA host over the Internet.
Network diagram
Figure 36 Network diagram for LAN-to-LAN DLSw configuration
Router A Router B
1.1.1 .1/24 2.2.2.2/24
Internet
Eth1/0 Eth1/0
LAN
LAN
LLC2 LLC2
IBM AS/400 Host

# Configure interface parameters on Router A to ensure that the local DLSw peer
1.1.1.1 and remote peer 2.2.2.2 are pingable to each other (specific configuration
steps omitted).
# Configure DLSw on Router A.
[RouterA] bridge enable
[RouterA] bridge 5 enable
[RouterA] dlsw local 1.1.1.1
[RouterA] dlsw remote 2.2.2.2
[RouterA] dlsw bridge-set 5
[RouterA] interface ethernet 1/0
[RouterA-Ethernet1/0] bridge-set 5
2 Configure Router B:
# Configure interface parameters on Router B to ensure that the local DLSw peer
steps omitted).
# Configure DLSw on Router B.
[RouterB] bridge enable
[RouterB] bridge 7 enable
[RouterB] dlsw local 2.2.2.2
[RouterB] dlsw remote 1.1.1.1
[RouterB] dlsw bridge-set 7
[RouterB] interface ethernet 1/0
[RouterB-Ethernet1/0] bridge-set 7
After this configuration, the two SNA LANs across the Internet are interconnected.
Configuring Network requirements

SDLC-to-SDLC DLSw As illustrated in Figure 37, DLSw works in an SDLC-to-SDLC environment.
Configure DLSw on Router A and Router B to enable communication between the
two SDLC LANs over the Internet.

Network diagram
Figure 37 Network diagram for SDLC-to-SDLC DLSw configuration
Router A Router B
1.1.1.1 /24 2 .2.2.2/24
Internet
S 2/0 S2/0
SDLC address: 0xC1
SDLC
SDLC
IBM AS/400 Host(SNA)

SDLC address: 0xC1
steps omitted).
[RouterA-Serial2/0] link-protocol sdlc
[RouterA-Serial2/0] sdlc enable dlsw
[RouterA-Serial2/0] sdlc status secondary
[RouterA-Serial2/0] sdlc controller c1
[RouterA-Serial2/0] sdlc mac-map remote 0000-2222-00c1 c1
[RouterA-Serial2/0] sdlc mac-map local 0000-1111-0000
[RouterA-Serial2/0] baudrate 9600
[RouterA-Serial2/0] code nrzi
steps omitted)
[RouterB-Serial2/0] link-protocol sdlc
[RouterB-Serial2/0] sdlc enable dlsw
[RouterB-Serial2/0] sdlc status primary
[RouterB-Serial2/0] sdlc controller c1
[RouterB-Serial2/0] sdlc mac-map remote 0000-1111-00c1 c1
[RouterB-Serial2/0] sdlc mac-map local 0000-2222-0000

[RouterB-Serial2/0] baudrate 9600

[RouterB-Serial2/0] code nrzi
After this step, the SDLC LANs across the WAN are interconnected.
Configuring DLSw for Network requirements

SDLC-LAN Remote As shown in Figure 38, Host A and Host B are PU2.0 nodes (ATM), and Host C is a
Media Translation PU2.1 node (OS2). Configure DLSw on Router A and Router B, using NRZ
encoding on the port connected with the multiplexer and NRZI encoding on the
port connected with Host C, so that the IBM host can communicate with all the
SNA PCs over the Internet.
Network diagram
Figure 38 Network diagram for SDLC-LAN configuration

Router A Router B
1 .1.1.1/24 2.2 .2.2/24 S2/1
S2/0
Eth1/0
SDLC
SDLC
LAN
LLC2
IBM AS/400
Host A(SNA ) Host B(SNA )
Internet
MAC address: 0028 -3300 -2af5 SDLC address: 0xC1 SDLC address: 0xC2
Host C(SNA )
SDLC address: 0 xC3
steps omitted).
steps omitted).

[RouterB-Serial2/0] sdlc xid c1 03e00001
[RouterB-Serial2/0] sdlc mac-map remote 0014-cc00-54af c1
[RouterB-Serial2/0] sdlc xid c2 03e00002
[RouterB-Serial2/1] code nrzi
# If the local and remote networks are stable, you can configure the following
commands to save the polling process.
[RouterB] dlsw reachable mac-exclusivity

[RouterB] dlsw reachable-cache 0014-cc00-54af remote 1.1.1.1
Note that in the configuration on router B, the MAC address in the sdlc mac-map
remote and dlsw reachable-cache commands is the MAC address of the
Ethernet card of the AS/400 device, which is connected to Router A. As an
Ethernet MAC address appears in the reverse bit order of a Token-Ring MAC
address, bit order reversal is required in MAC address configuration (for example, a
MAC address 0028-3300-2af5 appears to be 0014-cc00-54af after bit order
reversal). If the peer end is Token-Ring, bit order reversal is not required.
Configuring DLSw with Network requirements

VLAN Support As shown in Figure 39, Ethernet 1/1 of the Ethernet switch is connected with an
IBM host, Ethernet 1/0 of the switch is connected with Router A, and Ethernet 1/1
of Router B is connected with an SNA host. Perform the following configuration so
that the IBM host can communication with the SNA host over the Internet:
■ Add Ethernet 1/1 to VLAN 2, and configure Ethernet 1/0 as a trunk port,
allowing VLAN 2 of Ethernet 1/1 to pass.
■ Configure a sub-interface Ethernet 1/1.1 on Ethernet 1/1 of Router A and add
this sub-interface to VLAN 2.
Configure DLSw on Router A and Router B.

Network diagram
Figure 39 Network diagram for DLSw configuration with VLAN support
Eth1/0 Eth1/0
Eth1/1 Eth1/1.1 1.1.1.1/24 2.2.2.2/24 Eth1/1
Internet
Eth1/0
LSW Router A Router B
IBM AS/400 Host(SNA )
steps omitted).

[RouterA] interface ethernet 1/1.1
[RouterA-Ethernet1/1.1] bridge-set 1
# Configure DLSw on Router A

[RouterA-Ethernet1/1.1] vlan-type dot1q vid 1
[RouterB] dlsw bridge-set 1
steps omitted).

[RouterB-Ethernet1/1] ip address 2.2.2.2 255.255.255.0

[RouterB-Ethernet1/1] quit
[RouterB] rip
[RouterB-rip-1] network 2.0.0.0
[RouterB-rip-1] quit
3 Configure LSW
# Create VLAN 2, and assign Ethernet 1/1 to it.
<LSW> system-view
[LSW] vlan 2
[LSW-vlan2] port ethernet 1/1
[LSW-vlan2] quit
# Set Ethernet 1/0 to trunk mode and allow VLAN 2 to pass.
[LSW] interface ethernet1/0

[LSW-Ethernet1/0] port link-type trunk
[LSW-Ethernet1/0] port trunk permit vlan 2
DLSw v2.0 Network requirements

Configuration Example As shown in Figure 40, Router A is DLSw v2.0 capable, connected with an IBM
host, Router B and Router C are DLSw v1.0 or DLSw v2.0 capable, respectively
connected with PC1 and PC2, and CISCO is a DLSw-capable router of Cisco,
connected with PC3. All the DLSw routers listen to the multicast address
224.0.10.0. Enable the IBM host to communicate with all SNA hosts.
Network diagram
Figure 40 Network diagram for DLSw v2.0 configuration
Router B Host A(SNA )

Eth1/0
Eth1/1 1.1.1.1 /24
Internet
Router A Router C Host B(SNA )
Muticast address: 224 .0.10 .0
CISCO Host C(SNA )

IBM AS/400
1 Configure Router A.
# Configure bridge set 1.
# Add Ethernet 1/1 to bridge set 1.


[RouterA-Ethernet1/1] quit
# Enable multicast.
[RouterA] multicast routing-enable

[RouterA-Ethernet1/0] pim dm
[RouterA-Ethernet1/0] igmp enable
[RouterA-Ethernet1/0] igmp static-group 224.0.10.0
# Configure local DLSw peers, configure the permit-dynamic keyword to allow a

remote peer that is not preconfigured to initiate a TCP connection for dynamic
remote peer creation.
[RouterA] dlsw local 1.1.1.1 permit-dynamic
# Enable DLSw multicast, set the maximum number explorer retries and specify a
local bridge set.
[RouterA] dlsw multicast interface ethernet 1/0

[RouterA] dlsw max-transmission 3
2 Configure Router B and Router C
Before configuring Router B and Router C, first make sure of which DLSw version
they support. If they are DLSw v2.0 capable, the configuration is similar as on
Router A; if they are DLSw v1.0 capable, remove the multicast and explorer frame
retransmission part from the configuration.
For the configuration on the Cisco router, refer to Cisco documentation.
Troubleshooting DLSw Proper communication of the DLSw needs sound cooperation between the
involved SNA devices and DLSw-capable routers. A fault in the cooperation
between any two nodes may cause connection failure.
Unable to Establish a Symptom

TCP Connection A TCP connection cannot be established and the status information given by the
display dlsw remote command is DISCONNECT.
Analysis
TCP connection establishment is the first step in successful DLSw connection.
Failure in establishing a TCP connection is usually caused by problems between the
two routers, normally incorrect IP routing configuration.
Solution
Check whether the IP address of the remote peer is reachable by using the ping
command carrying the source address. Alternatively, use the display ip
routing-table command to check whether there is a route to the network

Troubleshooting DLSw 233
segment. After both sides have established a correct route, the TCP connection
can be created.
Unable to Establish a Symptom

DLSw Circuit A DLSw circuit cannot be correctly established. The display dlsw circuit
command shows that the virtual circuit cannot come into CONNECTED state.
Analysis
Many reasons can cause circuit establishment failure.
■ A TCP connection with the peer end must be successfully established first.
■ If a TCP connect can be successfully established but circuit establishment fails,
the problem usually lies in the cooperation between the router and the SNA
device, mainly with SDLC configuration.
Solution
1 First enable the SDLC debugging, and check whether the SDLC interface can
receive/forward frames normally by executing the display interface command. If
the interface cannot receive/forward frames correctly, possible causes are incorrect
encoding scheme, baud rate or clock configuration on the interface. Modify the
interface configuration parameters of the router or adjust the configuration
parameters of the SDLC device.
2 If frames can be received and forwarded correctly, examine whether the
configuration of the PU type is correct. Use the sdlc xid command to configure
the XID and change the configuration of the PU type.
3 If the PU type is correct, use the display dlsw circuit verbose command to check
whether the virtual circuit can enter the CIRCUIT_EST state. If not, the MAC
address of the SDLC peer is not correctly configured. Use the sdlc mac-map
remote command to modify the configuration parameters.
4 If the circuit can reach the CIRCUIT_EST state, but cannot reach the CONNECTED
state, this means that the configuration of the SDLC on the router does not match
that of the SNA devices. Check the configuration of the SDLC devices on both
sides and the configuration of the router. For example, check whether the XID of
the SNA device is properly configured (PU2.1), and whether the XID of the router
is properly configured (PU2.0). If all these configurations correct, check whether
the SDLC line on the primary SDLC device side (such as the AS/400 or S390) is
activated. Sometimes the SDLC line needs to be activated manually.


FRAME RELAY CONFIGURATION
8
When configuring frame relay, go to these sections for information you are
interested in:
■ “Frame Relay Terminologies” on page 235
■ “Frame Relay Configuration Task List” on page 238
■ “Configuring DTE Side Frame Relay” on page 238
■ “Configuring DCE Side Frame Relay” on page 245
■ “Displaying and Maintaining Frame Relay” on page 246
■ “Frame Relay Configuration Example” on page 247
■ “Troubleshooting Frame Relay” on page 252
■ “Frame Relay Compression” on page 253
Frame Relay
Terminologies
Overview Frame relay protocol is a simplified X.25 WAN protocol. It is a kind of statistical
multiplexing protocol that can establish multiple virtual circuits (VC) over a single
physical cable, each of which is identified by a data link connection identifier
(DLCI). A DLCI is not of global significance. It is valid to two directly connected
interfaces only. That is, you can use the same DLCI on different physical interfaces
to identify different VCs.
A frame relay network can be a public network, a private enterprise network, or a

network formed by direct connections between data devices.
DTE, DCE, UNI, and NNI Data Terminal Equipment (DTE) are end devices in frame relay networks. A frame
relay network provides the capability of data communications between end
devices.
Data Circuit-terminating Equipment (DCE) are network devices that provide

network access to DTEs.
User Network Interfaces (UNI) are interfaces used to connect DTEs and DCEs.
Network-to-Network interfaces (NNI) are interfaces used to connect frame relay

networks.
Virtual Circuit Virtual circuits fall into two types, permanent virtual circuit (PVC) and switched
virtual circuit (SVC), depending on how they are set up. Virtual circuits configured
manually are called PVCs, and those created by protocol negotiation are called

236 CHAPTER 8: FRAME RELAY CONFIGURATION
SVCs, which are automatically created and deleted by frame relay protocol. At
present, the most frequently used in frame relay is the PVC mode, that is.,
manually configured virtual circuit.
In the PVC mode, the availability of the virtual circuit should be checked. Local
management interface (LMI) protocol can implement this function. It is used to
maintain PVC table of frame relay protocol, including advertising added PVC entry,
detecting deleted PVC entry, monitoring PVC status change, and verifying PVC link
integrity. The system supports three LMI protocols: ITU-T Q.933 Appendix A, ANSI
T1.617 Appendix D and nonstandard compatible protocol. Their basic operating
mode is: DTE sends one Status Enquiry message to query the virtual circuit status
at a certain interval. After the DCE receives the message, it will immediately use
the Status message to inform DTE of the status of all the virtual circuits on current
interface.
The PVC status on DTE is completely determined by DCE, and the network
determines the PVC status on DCE. If two network devices are directly connected,
the equipment administrator sets the virtual circuit status of DCE.
Frame Relay Protocol Table 1 lists the parameters of frame relay.

Parameters
Table 1 Parameter description for frame relay protocol
Operating mode Parameter description Value range Default value

DTE Request PVC status 1 to 255 6
counter (N391)
Error threshold (N392) 1 to 10 3
Event counter (N393) 1 to 10 4
User side polling timer 0 to 32767 10
(T391), the value 0
(in seconds) (in seconds)
indicates that LMI protocol
is disabled
DCE Error threshold (N392) 1 to 10 3
Event counter (N393) 1 to 10 4
Network side polling timer 5 to 30 15
(T392)
(in seconds) (in seconds)
These parameters are stipulated by Q.933 Appendix A, and their meanings are
described as follows:
Meanings of parameters related to DTE operating mode:
■ N391: DTE sends a Status-Enquiry message at a certain interval (determined by

T391). There are two types of Status-Enquiry messages: link integrity
verification message and link status enquiry message. Parameter N391 defines
the ratio of sending the two types of messages, that is, number of link integrity
verification messages : number of link status enquiry messages = N391-1: 1
■ N392: it sets the threshold for errors among the observed events.
■ N393: it sets the total of observed events.
■ T391: it sets the interval for a DTE to send State-Enquiry messages.

Frame Relay Terminologies 237
A DTE sends a Status-Enquiry message at a certain interval to query the link status.
The DCE responds with a Status response message upon receiving the message. If
the DTE does not receive any response within a specified time, it will record this
error. If the number of errors exceeds the threshold, DTE will regard the physical
channel and all virtual circuits unavailable. N392 and N393 together define “error
threshold”. In other words, if the number of errors reaches N392 among the N393
Status Enquiry messages sent by DTE, DTE will consider that the number of errors
has reached the threshold and the physical channel and all virtual circuits are
unavailable.
Meanings of parameters related to DCE operating mode:
■ N392 and N393: These two parameters have similar meanings to those related
to DTE operating mode. However, DCE requires that the fixed time interval for
DTE sending a status-enquiry message should be determined by T392, while
DTE requires that this interval should be determined by T391. If DCE does not
receive the status-enquiry message from DTE within a period determined by
T392, an error recorder is created.
■ T392: Time variable, which defines the maximum time that DCE waits for a
status-enquiry message. The time value shall be greater than the value of T391.
Frame Relay Address Frame relay address mapping associates the protocol address of a remote device
Mapping with its frame relay address (local DLCI). By consulting the frame relay address map
by protocol address, the upper layer protocol can locate a remote device.
Frame relay is used to bear IP protocol. When sending an IP packet, the frame
relay-enabled router can obtain its next hop address after consulting the routing
table, which is inadequate for sending the packet to the correct destination across
a frame relay network. To identify the DLCI corresponding to the next hop address,
the router must consult a frame relay address map retaining the associations
between remote IP addresses and next hop DLCIs.
A frame relay address map can be manually configured or maintained by Inverse

Address Resolution Protocol (InARP).
The following figure presents how LANs are interconnected across a frame relay
network.
Figure 41 Interconnect LANs through a frame relay network
Router A Router B
DLCI=50 DLCI=70
Router C
DLCI=60 FR
DLCI=80

Frame Relay Complete the following tasks to configure frame relay:

Configuration Task
List Task Remarks
“Configuring DTE Side “Configuring Basic DTE Side Required
Frame Relay” on page Frame Relay” on page 238
238
“Configuring Frame Relay Required
Address Mapping” on page 239
“Configuring Frame Relay Local Required
Virtual Circuit” on page 239
“Configuring Frame Relay Optional
Switching” on page 240
Subinterface” on page 241
“Configuring Frame Relay over IP Optional
Network” on page 242
“Configuring Annex G” on page Optional
244
“Configuring DCE Side “Configuring Basic DCE Side Required
Frame Relay” on page Frame Relay” on page 245
245
“Configuring Frame Relay Required
Address Mapping” on page 246
“Configuring Frame Relay Local Required
Virtual Circuit” on page 246
Switching” on page 246
Subinterface” on page 246
“Configuring Frame Relay over IP Optional
“Configuring Annex G” on page Optional
246
Configuring DTE Side

Frame Relay
Configuring Basic DTE Follow these steps to configure DTE side frame relay:
Side Frame Relay
interface-number
Configure interface link-protocol fr [ ietf | Required
encapsulation protocol as nonstandard ]
ietf by default.
frame relay
The default link layer protocol
for interface encapsulation is
PPP.
Configure frame relay fr interface-type dte Required
interface type as DTE
The default frame relay
interface type is DTE.


Configure frame relay LMI fr lmi type { ansi | Optional
protocol type nonstandard | q933a |
The default frame relay LMI
bi-direction }
protocol type is q933a.
The support of the
bi-direction keyword varies
with device model.
Configure user side N391 fr lmi n391dte n391-value Optional
6 by default.
3 by default.
4 by default.
Configure user side T391 timer hold seconds Optional
10 seconds by default.
Configuring Frame Relay This section covers these topics:

Address Mapping ■ “Overview” on page 235
Overview
Frame relay address mapping can be configured statically or set up dynamically.
■ Static configuration means the manual setup of the mapping relation between
the peer IP address and local DLCI, and is usually applied when there are few
peer hosts or there is a default route.
■ Dynamic setup means the dynamic setup of mapping relation between peer IP
address and local DLCI by InARP. Dynamic setup is applied when the peer
device also supports InARP and network is complex.
Follow these steps to configure frame relay address mapping:

Enter interface view interface interface-type Required
interface-number
Add a static address map fr map ip { ip-address Optional
entry [ ip-mask ] | default }
The system has no static
dlci-number [ broadcast |
address map entries by
[ nonstandard | ietf ] |
default.
compression { frf9 | iphc } ]
*
Enable InARP to set up fr inarp [ ip [ dlci-number ] ] Optional
dynamically address mapping
By default, InARP is enabled.

Local Virtual Circuit ■ “Overview” on page 235

Overview
When the frame relay interface type is DCE or NNI, the interface (either main
interface or subinterface) must be manually configured with virtual circuits. When
the frame relay interface type is DTE, for the main interface, the system will
determine the virtual circuit automatically according to the peer device, and the
main interface can also be manually configured with virtual circuits; for
subinterface, it is required to manually configure virtual circuits.
A virtual circuit number is unique on a physical interface.
Follow these steps to configure frame relay local virtual circuit

interface-number
Configure virtual circuit on fr dlci dlci-number Required
interface
There is no virtual circuit on
interface by default.

Switching ■ “Overview” on page 235
Overview
A device with frame relay switching function enabled can act as a frame relay
switch. In this scenario, the frame relay interface should be NNI or DCE and it is
required to perform corresponding configuration on the two or more interfaces
used for frame relay switching before the frame relay switching function can work.
To configure frame relay switching, you can configure static routes for frame relay
switching in interface view or configure PVC for frame relay switching in system
view.
Follow these steps to configure frame relay switching:

Enable frame relay switching fr switching Required
interface-number


Set the type of interface for frame fr interface-type { dce | Required
relay switching to NNI or DCE nni }
interface type is DTE, which
means the system disables
frame relay switching by
default.
Frame relay switching is
unavailable to DTEs.
Configure Configure static fr dlci-switch in-dlci Required
frame relay routes for frame interface interface-type
There is no static route
switching relay switching in interface-number dlci
configured for frame relay
(either by interface view out-dlci
switching by default.
configuring
static route or The arguments in-dlci and
PVC) out-dlci used for
configuring frame relay
switching must have been
configured on
corresponding interface.
Configure PVC quit -
for frame relay
fr switch name interface Required
switching in
interface-type
system view
interface-number dlci dlci1
fr switch name Optional
Enter frame relay switching
PVC view
undo shutdown Optional
Enable current switching
PVC

Subinterface ■ “Overview” on page 235
Overview
The frame relay module has two types of interfaces: main interface and
subinterface. The subinterface is of logical structure, which can be configured with
protocol address and virtual circuit. One physical interface can include multiple
subinterfaces, which do not exist physically. However, for the network layer, the
subinterface and main interface make no difference and both can be configured
with virtual circuits to connect to remote devices.
The subinterface of frame relay falls into two types: point-to-point (P2P)
subinterface and point-to-multipoint (P2MP) subinterface. P2P subinterface is used
to connect a single remote device and P2MP subinterface is used to connect
multiple remote devices. A P2MP subinterface can be configured with multiple
virtual circuits, each of which sets up an address map with its connected remote
network address to distinguish different connections. Address maps can be set up
by manual configuration or dynamically set up by InARP.

The methods to configure virtual circuit and address map for P2P subinterfaces
and P2MP subinterfaces are different, as described below.
■ P2P subinterface
Since there is only one peer address for a P2P subinterface, the peer address is
determined when a virtual circuit is configured for the subinterface. You therefore
do not need to configure dynamic or static address map for P2P subinterface.
■ P2MP subinterface
For a P2MP subinterface, a peer address can be mapped to the local DLCI through
static address mapping or InARP which only needs to be configured on the main
interface. If static address mapping is required, it is necessary to set up static
address map for each virtual circuit.
Follow these steps to configure frame relay subinterface:

Create a subinterface and interface interface-type Required
enter subinterface view interface-number.subnumber
The type of a frame relay
[ p2mp | p2p ]
subinterface is p2mp by
default.
Configure virtual circuit on See “Configuring Frame Relay Required
frame relay subinterface Local Virtual Circuit” on page
239
Set up address map See “Configuring Frame Relay Optional
Address Mapping” on page
For P2MP subinterface, it is
239
required to set up address
map.

over IP Network ■ “Overview” on page 235
Overview
With the increasingly wide application of IP network, internetworking of frame
relay networks needs to be realized through Frame Relay over IP, which creates
generic routing encapsulation (GRE) tunnel between frame relay networks at two
ends and transmits frame relay packets through the GRE tunnel, as illustrated
below:

Figure 42 Typical implementation diagram of Frame Relay over IP
Frame Relay Frame Relay

IP network
network network
The frame relay packets transmitted through GRE tunnel fall into three categories:
FR packet and InARP packet, both of which have IP header encapsulated, and LMI
packet used to negotiate virtual circuit status in GRE tunnel.
Follow these steps to configure frame relay over IP network:

Create tunnel interface in system For detailed information Required
view and perform corresponding about tunnel interface
configuration on tunnel interface configuration, refer to “GRE
Configuration” on page
1589.
Enable frame relay switching fr switching Required
Configure frame Configure static interface interface-type -
relay switch routes for frame interface-number
either by static relay switching
fr dlci-switch in-dlci Required
routes or by in interface view
interface tunnel
PVC There is no static route for
interface-number dlci
frame relay switching by
out-dlci
default.
Configure PVC fr switch name interface Required
for frame relay interface-type
There is no PVC for frame
switching in interface-number dlci dlci1
relay switching by default.
system view interface tunnel
fr switch name Optional
undo shutdown Optional
After a PVC is created, its
status is up by default.
c CAUTION:
■ Before configuring frame relay over IP network, it is necessary to create and
configure tunnel interface. After the setup of a GRE tunnel interface, you can
specify the tunnel interface to be used by frame relay switching to implement
frame relay packets over IP network.
■ You need to configure static route for frame relay switching in frame relay
interface view or multilink frame relay (MFR) interface view at both ends of GRE
tunnel, or configure PVC for frame relay switching in system view. After frame
relay routes have been configured, two route entries will be added into the

frame relay routing table of the router. In one route entry, the ingress interface
is tunnel interface and the egress interface is frame relay interface. In the other
route entry, the ingress interface is frame relay interface and the egress
interface is tunnel interface. On the tunnel interface, a virtual circuit whose
DLCI number is out-dlci will be generated. The status of this virtual circuit
determines the status of the above mentioned routes.
■ The virtual circuit used for frame relay switching must be configured on the
tunnel interfaces at both ends of the GRE tunnel, and the DLCI number
(out-dlci) on the tunnel interfaces must be the same.
Configuring Annex G ANSI T1.617 Annex G (Annex G for short) defines the way to transmit X.25
packets through VCs. In an Annex G implementation, the
acknowledgement/retransmission and flow-control mechanism used in X.25 are
invoked to provide reliable transmission. Annex G can also be used to connect
X.25 networks through FR networks. It is a technology that can help you to
migrate from X.25 network to FR network and thus protects the investment on
X.25 effectively.
Follow these steps to configure Annex G:

interface-number
Encapsulate the interface with link-protocol fr Required
FR
By default, an interface is
encapsulated with PPP.
Create a VC fr dlci dlci-number Required
This command also leads you
to interface DLCI view.
By default, no VC is created
on an interface.
Configure the VC interface as annexg { dce | dte } Required
an Annex G interface
c CAUTION:
■ As Annex G is not compliant with Inverse-ARP, you need to configure a static
FR mapping for the destination IP address.
■ An Annex G interface is either a DCE or a DTE. For the two Annex G interfaces
of a VC, you need to configure one as the DTE and the other as the DCE.
Configure X.25 parameters for an Annex G interface

Follow these steps to configure X.25 parameters for an Annex G interface:


Configuring DCE Side Frame Relay 245

Create an X.25 template x25 template { name } Required
This command also leads you to
X.25 template view.
Configure X.25 Refer to “X.25 and LAPB Optional
parameters Configuration” on page
283.
Configure LAPB Refer to “X.25 and LAPB Optional
parameters Configuration” on page
283.
interface-number
Create a VC fr dlci dlci-number Required
This command also leads you to
interface DLCI view.
By default, no VC is created on
an interface.
Apply the X.25 template to x25-template { name } Optional
the DLCI
By default, a DLCI has no X.25
template applied to it.
c CAUTION:
■ With FR address mapping configured in FR interface view, packets destined for
the destination are transmitted through specific DLCI. With X.25 address
mapping configured in X.25 template view, a call to the specific X.25 address is
launched before a packet is sent to the destination IP address. IP packets can
be transmitted correctly only when the both types of address mappings are
configured.
■ The configuration performed in X.25 template view is similar to that performed
in X.25 interface view. To establish an X.25 link successfully, the configurations
on the routers of both sides need to be consistent with each other.
Configuring DCE Side

Frame Relay
Configuring Basic DCE Follow these steps to configure DCE side frame relay:
Side Frame Relay
interface-number
Configure interface link-protocol fr Required
encapsulation protocol as [ nonstandard | ietf ]
The link layer protocol for
frame relay
interface encapsulation is PPP
by default. When frame relay
protocol is used for interface
encapsulation, the default
operating mode is IETF.


Configure frame relay fr interface-type { dce | nni } Required
interface type to DCE or NNI
interface type is DTE.
Configure frame relay LMI fr lmi type { ansi | Optional
protocol type nonstandard | q933a }
The default frame relay LMI
protocol type is q933a.
Configure network side N392 fr lmi n392dce n392-value Optional
The default value is 3.
Configure network side N393 fr lmi n393dce n393-value Optional
The default value is 4.
Configure network side T392 fr lmi t392dce t392-value Optional
The default value is 15
seconds.
Configuring Frame Relay Refer to “Configuring Frame Relay Address Mapping” on page 239.
Address Mapping
Configuring Frame Relay Refer to “Configuring Frame Relay Local Virtual Circuit” on page 239.
Local Virtual Circuit
Configuring Frame Relay Refer to “Configuring Frame Relay Switching” on page 240.
Switching
Configuring Frame Relay Refer to “Configuring Frame Relay Subinterface” on page 241.
Subinterface
Configuring Frame Relay Refer to “Configuring Frame Relay over IP Network” on page 242.
over IP Network
Configuring Annex G Refer to “Configuring Annex G” on page 244.
Displaying and
Maintaining Frame To do... Use the command... Remarks
Relay Display frame relay display fr interface Available in any view
protocol status on [ interface-type
Either all the information or the
interface { interface-number |
information of specified interfaces
interface-number.subnumber }
can be shown. The specified
]
interface can be either main
interface or subinterface.
Display mapping table display fr map-info Available in any view
of protocol address and [ interface interface-type
frame relay address { interface-number |
]


Display display fr lmi-info Available in any view
receiving/sending [ interface interface-type
statistics information of interface-number ]
frame relay LMI type
can be shown. Only main interface
messages
can be specified.
Display frame relay data display fr statistics Available in any view
receiving/sending [ interface interface-type
statistics information interface-number ]
can be specified.
Display frame relay display fr pvc-info Available in any view
permanent virtual [ interface interface-type
circuit table { interface-number |
] [ dlci-number ]
Display statistics display fr inarp-info Available in any view
information of frame [ interface interface-type
relay InARP messages interface-number ]
can be specified.
Display the information display fr dlci-switch Available in any view
of configured frame [ interface interface-type
relay switching interface-number ]
Display the display x25 template Available in any view
configuration of an [ name ]
X.25 template
Clear all the reset fr inarp Available in user view
automatically
established frame relay
address maps
Clear the statistics on reset fr pvc interface serial Available in user view
an FR PVC interface-number [ dlci
dlci-number ]
Frame Relay This section provides these examples:

Configuration ■ “Interconnecting LANs through Frame Relay Network” on page 247
Example
■ “Interconnecting LANs through Dedicated Line” on page 249
Interconnecting LANs Network requirements

through Frame Relay Interconnect LANs through the public frame relay network. In this implementation,
Network the routers can only work as user equipment working in the frame relay DTE
mode.

Network diagram
Figure 43 Network diagram for connecting LANs through a frame relay network
Router A Router B
S2/0 S2/0
202 .38 .163 .251 /24 202 .38 .163 .252 /24
DLCI=50 DLCI=70
Router C
DLCI=60 FR
S2/0
202 .38 .163 .253 /24
DLCI=80
# Assign an IP address to Serial 2/0 interface.
# Configure interface encapsulation protocol as frame relay.
[RouterA-Serial2/0] link-protocol fr
[RouterA-Serial2/0] fr interface-type dte
# If the opposite router supports InARP, configure dynamic address mapping.
[RouterA-Serial2/0] fr inarp
# Otherwise, configure static address mapping.
[RouterA-Serial2/0] fr map ip 202.38.163.252 50

# Assign an IP address.
[RouterB-Serial2/0] link-protocol fr
[RouterB-Serial2/0] fr interface-type dte
[RouterB-Serial2/0] fr inarp

[RouterB-Serial2/0] fr map ip 202.38.163.251 70

3 Configure Router C:
[RouterC-Serial2/0] link-protocol fr
[RouterC-Serial2/0] fr interface-type dte
[RouterC-Serial2/0] fr inarp
[RouterC-Serial2/0] fr map ip 202.38.163.251 80

through Dedicated Line Two routers are directly connected through a serial interface. Router A works in
the frame relay DCE mode, and Router B works in the frame relay DTE mode.
Network diagram
Figure 44 Network diagram for interconnecting LANs through a dedicated line
S 2/0 S2/0
202 .38 .163 .251/24 202 .38 .163 .252 /24
DLCI=100
Router A Router B
Approach I: On main interfaces
# Configure the link layer protocol on the interface to frame relay in DCE mode.
[RouterA-Serial2/0] fr interface-type dce
# Configure a local virtual circuit.
[RouterA-Serial2/0] fr dlci 100

# Set the link layer protocol on the interface to frame relay.
Approach II: On subinterfaces
# Set the link layer protocol on the interface to frame relay and interface type to
DCE.
# Configure IP address of the subinterface and local virtual circuit.
[RouterA] interface serial 2/0.1 p2p

[RouterA-Serial2/0.1] ip address 202.38.163.251 255.255.255.0
[RouterA-Serial2/0.1] fr dlci 100
# Set the link layer protocol on the interface to frame relay and interface type to
DTE.
# Configure IP address of the subinterface and local virtual circuit.
[RouterB] interface serial 2/0.1 p2p

[RouterB-Serial2/0.1] ip address 202.38.163.252 255.255.255.0
[RouterB-Serial2/0.1] fr dlci 100

through an Annex G Two routers, Router A and Router B, are connected through their serial interfaces.
DLCI Router A operates as the DCE side; Router B operates as the DTE side.

Network diagram
Figure 45 Network diagram for interconnecting LANs through an Annex G DLCI
S 2/0 S2/0
202 .38 .163 .251/24 202 .38 .163 .252 /24
DLCI=100
Router A Router B
# Create an X.25 template.
[RouterA] x25 template vofr
# Configure the local X.25 address.
[RouterA-x25-vofr] x25 x121-address 10094
# Configure the X.25 address mapping to the destination IP address.
[RouterA-x25-vofr] x25 map ip 202.38.163.252 20094

[RouterA-x25-vofr] quit
# Assign an IP address to the local interface.

# Encapsulate the interface with FR.
# Create a DLCI interface.
# Configure the DLCI interface as an Annex G interface.
[RouterA-fr-dlci-Serial2/0-100] annexg dce
# Apply the X.25 template to the DLCI interface.
[RouterA-fr-dlci-Serial2/0-100] x25-template vofr

[RouterA-fr-dlci-Serial2/0-100] quit
# Configure the FR address mapping to the destination IP address.


[RouterB] x25 template vofr
# Configure the local X.25 address.
[RouterB-x25-vofr] x25 x121-address 20094
# Configure the X.25 address mapping to the destination IP address.
[RouterB-x25-vofr] x25 map ip 202.38.163.251 10094

[RouterB-x25-vofr] quit
# Assign an IP address to the local interface.

# Encapsulate the interface with FR.
# Create an FR DLCI interface.
[RouterB-Serial2/0] fr dlci 100
# Configure the DLCI interface as an Annex G DLCI interface.
[RouterB-fr-dlci-Serial2/0-100] annexg dte
# Apply the X.25 Template to the DLCI interface.
[RouterB-fr-dlci-Serial2/0-100] x25-template vofr

[RouterB-fr-dlci-Serial2/0-100] quit
# Configure the FR address mapping to the destination IP address.
Troubleshooting Symptom 1:
Frame Relay
The physical layer is in down status.
Solution:
■ Check whether the physical line is normal.

■ Check whether the remote device runs normally.
Symptom 2:
The physical layer is already up, but the link layer protocol is down.
Solution:

■ Ensure that both local device and remote device have been encapsulated with
frame relay protocol.
■ If two devices are directly connected, check the local device and remote device
to ensure that one end is configured as frame relay DTE interface and the other
end as frame relay DCE interface.
■ Ensure that the LMI protocol type configuration at the two ends is the same.
■ If the above conditions are satisfied, enable the monitoring function for the
frame relay LMI messages to see whether one Status Request message
correspond to one Status Response message. If not, it indicates the physical
layer data is not received/sent correctly. Check the physical layer. The
debugging fr lmi command is used to enable the monitoring function for
frame relay LMI messages.
Symptom 3:
The link layer protocol is up, but the remote party cannot be pinged.
Solution:
1 Ensure that the devices at both ends have configured (or created) correct address
mapping for the peer.
2 Ensure that there is a route to the peer if the devices are not in the same subnet
segment.
Frame Relay This section covers these topics:

Compression ■ “Overview” on page 235
■ “Configuring FRF.9 Compression” on page 254
■ “Configuring FRF.20 IP Header Compression” on page 254
■ “Configuring FRF.20 IP Header Compression” on page 254
■ “Frame Relay Compression Configuration Example” on page 255
Overview Frame relay compression technique can be used to compress frame relay packets
to save network bandwidth, reduce network load and improve the data transfer
efficiency on frame relay network.
The device supports FRF.9 stac compression (referred to as FRF.9) and FRF.20 IP
header compression (IPHC), which is referred to as FRF.20.
FRF.9
FRF.9 classifies packets into two types: control packets and data packets. Control
packets are used for status negotiation between the two ends of DLCI where
compression protocol has been configured. FRF.9 data packets cannot be switched
before the negotiation succeeds. If the negotiation fails after 10 attempts to send
FRF.9 control packet are made, the negotiating parties stop negotiation and the
compression configuration does not take effect.
FRF.9 compresses only data packets and InARP packets; it does not compress LMI
packets.

FRF.20
FRF.20 compresses the IP header of packets transmitted over frame relay. For
example, you may use it to compress voice packets to save bandwidth, decrease
load, and improve transmission efficiency on a frame relay network.
FRF.20 classifies packets into control packets and data packets. Control packets are
sent between FRF.20-enabled interfaces to negotiate status information. The
interfaces cannot exchange FRF.20 data packets before the negotiation succeeds.
If the negotiation fails after 10 attempts to send control packets are made, the
interfaces stop negotiation and their compression settings do not take effect.
FRF.20 compresses only RTP packets and TCP ACK packets.
Configuring FRF.9 Frame relay main interface is a P2MP interface, while frame relay subinterface
Compression includes two types: P2P and P2MP. Therefore, the configuration of frame relay
FRF.9 compression varies by different interface types. For a P2P subinterface, use
the fr compression frf9 command to enable FRF.9 compression in subinterface
view. For a P2MP frame relay interface or subinterface, the frame relay
compression is configured when creating static address mapping.
Follow these steps to configure FRF.9 compression:
Use the
Enter frame relay interface or subinterface view interface -
interface-type
interface-number
or
interface serial
interface-number.s
ubnumber
Configure FRF.9 For P2P subinterface, enable fr compression Optional
compression (select FRF.9 compression frf9
FRF.9 compression
either one
is disabled by
according to
default.
interface type)
For P2MP interface, enable fr map ip Optional
FRF.9 compression when { ip-address
creating static address [ ip-mask ] |
mapping default }
dlci-number
[ broadcast | [ ietf
| nonstandard ] ]*
compression frf9
Configuring FRF.20 IP Frame relay function provides IP header compression including RTP/TCP header
Header Compression compression. You can enable IP header compression on interfaces or when
configuring static address mapping.
Follow these steps to configure FRF.20 IP header compression:


Enter interface view interface -
interface-type
interface-number
Configure FRF.20 FRF.20 IP header fr compression iphc Optional
IP header compression on
FRF.20 IP header
compression interface and provide
compression is disabled
(select either FRF.20 IP header
on interface by default.
method) compression option
fr iphc { nonstandard Optional
| rtp-connections
FRF.20 IP header
number1 |
compression option is
tcp-connections
not provided by default.
number2 |
tcp-include }
Enable FRF.20 IP header fr map ip { ip-address Optional
compression when [ ip-mask ] | default }
The system does not
create a static address dlci-number
have static address
mapping [ broadcast ]
mapping by default.
[ nonstandard | ietf ]
compression iphc
Displaying and
Maintaining Frame To do... Use the command... Remarks
Relay Compression Display statistics information display fr compress Available in any view
about FRF.9 compression [ interface interface-type
interface-number ]
Display statistics information display fr iphc [ interface Available in any view
about FRF.20 IP header interface-type
compression interface-number ]
Frame Relay Network requirements

Compression Router A and Router B are connected through the frame relay network and frame
Configuration Example relay compression function (FRF.9) is enabled between them.
Network diagram
Figure 46 Network diagram for frame relay compression
S 2/0 S 2/0
10 .110 .40.1/24 10 .110 .40 .2 /24
Frame Relay
network
Router A Router B
[RouterA-Serial2/0] fr map ip 10.110.40.2 100 compression frf9

[RouterB-Serial2/0] fr map ip 10.110.40.1 100 compression frf9

MULTILINK FRAME RELAY
9
■ “Configuring Multilink Frame Relay” on page 258
■ “Displaying and Maintaining Multilink Frame Relay” on page 259
■ “Multilink Frame Relay Configuration Examples” on page 259
■ “MFR Switched Connection Configuration Example” on page 260
Overview Multilink frame relay (MFR) is a cost effective bandwidth solution for frame relay
users. Based on the FRF.16 protocol of the frame relay forum, it implements MFR
function on DTE/DCE interfaces.
MFR function provides a kind of logic interface, namely MFR interface. The MFR
interface is composed of multiple frame relay physical links bound together, so as
to provide high-speed and broadband links on frame relay networks.
To maximize the bandwidth of bundled interface, it is recommended to bundle

physical interfaces of the same rate for the same MFR interface when configuring
the MFR interface so as to reduce management cost.
Bundle and bundle link

Bundle and bundle link are two basic concepts related to MFR.
One MFR interface corresponds to one bundle, which may contain multiple bundle
links. One bundle link corresponds to one physical interface. A bundle manages its
bundle links. The interrelationship between bundle and bundle link is illustrated as
follows:
Figure 47 Illustration of bundle and bundle links
Bundle
Bundle Link
Bundle Link
Bundle Link
For the actual physical layer, bundle link is visible; while for the actual data link
layer, bundle is visible.

258 CHAPTER 9: MULTILINK FRAME RELAY
MFR interface and physical interface

An MFR interface is a kind of logic interface. Multiple physical interfaces can be
bundled into one MFR interface. One MFR interface corresponds to one bundle
and one physical interface corresponds to one bundle link. The configuration on a
bundle and bundle links is actually configuration on an MFR interface and physical
interfaces.
The function and configuration of the MFR interface is the same with that on the
FR interface in common sense. Like the FR interface, the MFR interface supports
DTE and DCE interface types as well as QoS queue mechanism. After physical
interfaces are bundled into an MFR interface, their original network layer and
frame relay link layer parameters become ineffective and they use the parameter
settings of the MFR interface instead.
Configuring Multilink Follow these steps to configure multilink frame relay:

Frame Relay
Create MFR interface and interface mfr Required
enter the MFR interface view { interface-number |
MFR interface or subinterface is not
interface-number.subnu
created by default.
mber }
Configure MFR bundle mfr bundle-name Optional
identifier [ name ]
The bundle identifier is “mfr +
frame relay bundle number” by
default. This identifier only has only
significance.
In spite of the default BID, you
cannot configure a BID as a string
in the form of mfr + number.
Enable MFR fragmentation mfr fragment Optional
Fragmentation is disabled on MFR
bundles by default.
Set the size of MFR sliding mfr window-size Optional
window number
The size of MFR sliding window is
equal to the number of physical
interfaces bundled by MFR by
default.
Configure the maximum mfr fragment-size Optional
fragment size for the bundle bytes
The maximum fragment is of 300
link
bytes by default.
Configure other parameters See “Frame Relay Optional
of the MFR interface Configuration Task List”
on page 238
Enter specified interface view interface interface-type -
interface-number
Bundle the current interface link-protocol fr mfr Required
to an MFR interface interface-number
An interface is not bundled with
any MFR interface by default.

Displaying and Maintaining Multilink Frame Relay 259

Configure MFR bundle link mfr link-name [ name ] Optional
identifier
The bundle link identifier is the
name of the current interface by
default.
Configure hello packet mfr timer hello seconds Optional
sending period of MFR
The hello packet sending period of
bundle link
bundle link is 10 seconds by
default.
Configure the waiting time mfr timer ack seconds Optional
before MFR bundle link
The waiting time before resending
resends hello packets
hello message is 4 seconds by
default.
Configure maximum mfr fragment-size Optional
fragment size for the bundle bytes
The maximum fragment size is of
link
300 bytes. The priority of fragment
size configured in frame relay
interface view is higher than that in
MFR interface view.
Configure the maximum mfr retry number Optional
times that MFR bundle link
The hello packet can be resent 2
can resend hello packet
times at the maximum by default.
Configure the MFR interface mfr Optional
to return ADD_LINK messages stateup-respond-addli
By default, an MFR interface does
and transit the corresponding nk
not respond to ADD_LINK requests
physical interface to the
received even if it is in protocol up
protocol ADD_SENT state
state. This causes the peer port
when it is in protocol up state
cannot be in protocol up state.
and receives an ADD_LINK
request from the peer
Displaying and
Maintaining Multilink To do... Use the command... Remarks
Frame Relay Display configuration and status display interface mfr Available in any
of MFR interface [ interface-number ] view
Display configuration and display mfr [ interface interface-type Available in any
statistics information of MFR interface-number | verbose ] view
bundle and bundle links
Multilink Frame Relay

Configuration
Examples
MFR Direct Connection Network requirements

Configuration Example Router A and Router B are directly connected through Serial 2/0 and Serial 2/1.
The frame relay protocol is used to bundle the two serial ports to provide broader
bandwidth.

Network diagram
Figure 48 Network diagram of MFR direct connection
Router A Router B
S 2/0 S 2/0
S 2/1 S 2/1
MFR 4 MFR 4
10.140.10.1/24 10 .140 .10 .2 /24
# Create and configure MFR interface 4 (MFR4)
[RouterA] interface mfr 4
[Router‘A-MFR4] ip address 10.140.10.1 255.255.255.0
[RouterA-MFR4] fr interface-type dte
[RouterA-MFR4] fr map ip 10.140.10.2 100
[RouterA-MFR4] quit
# Bundle Serial 2/0 and Serial 2/1 to MFR4

[RouterA-Serial2/0] link-protocol fr mfr 4
# Create and configure MFR interface 4 (MFR4)
[RouterB] interface mfr 4
[RouterB-MFR4] ip address 10.140.10.2 255.255.255.0
[RouterB-MFR4] fr interface-type dce
[RouterB-MFR4] fr dlci 100
[RouterB-fr-dlci-MFR4-100] quit
[RouterB-MFR4] fr map ip 10.140.10.1 100
[RouterB-MFR4] quit
# Bundle Serial 2/0 and Serial 2/1 to MFR4

[RouterB-Serial2/0] link-protocol fr mfr 4
MFR Switched Network requirements

Connection Router A and Router C are connected through MFR to Router B where MFR
Configuration Example switching is enabled.

Multilink Frame Relay Configuration Examples 261
Network diagram
Figure 49 Network diagram for MFR switching
Router A Router B Router C

S2/0 S2/0 S2/2 S 2/0
S 2/1 S 2/1 S2/3 S 2/1

MFR 1 MFR 1 MFR 2 MFR 2
1.1 .1.1/8 1.1.1.2 /8
# Configure interface MFR1
[RouterA] interface mfr 1
[RouterA-MFR1] ip address 1.1.1.1 255.0.0.0
[RouterA-MFR1] quit
# Add Serial 2/0 and Serial 2/1 to interface MFR1

# Enable frame relay switching
[RouterB] fr switching

[RouterB-MFR1] quit

[RouterB-MFR2] quit

[RouterB] quit



[RouterB-Serial 2/2] quit
# Configure static route for frame relay switching
[RouterB] fr switch pvc1 interface mfr 1 dlci 100 interface mfr 2 dl

ci 200
[RouterC] interface mfr 2
[RouterC-MFR2] ip address 1.1.1.2 255.0.0.0
[RouterC-MFR2] quit

[RouterC-Serial2/0] link-protocol fr mfr 2
[RouterC-Serial2/1] link-protocol fr mfr 2

PPPOFR
10
■ “Configuring PPPoFR” on page 263
■ “Displaying and Maintaining PPPoFR” on page 263
■ “PPPoFR Configuration Example” on page 264
Overview PPP over frame relay (PPPoFR) enables routers to establish end-to-end PPP sessions
on a frame relay network, allowing frame relay stations to use PPP features such as
LCP, NCP, authentication, and MP fragmentation.
Configuring PPPoFR Follow these steps to configure PPPoFR:

Create a virtual template interface virtual-template -
interface and the virtual interface-number
template interface view
Assign IP address ip address ip-address ip-mask Required
Return to system view quit Required
Enter corresponding frame interface interface-type -
relay interface interface-number
Configure interface link-protocol fr Required
encapsulation protocol to
frame relay
Configure a frame relay DLCI fr dlci dlci-number Required (optional for
DTE side)
Map frame relay DLCI to PPP fr map ppp dlci-number interface Required
virtual-template interface-number
virtual-template interface is valid.
Displaying and
Maintaining PPPoFR To do... Use the command... Remarks
Display PPPoFR MAP and display fr map-info pppofr [ interface Available in any
status interface-type interface-number ] view

264 CHAPTER 10: PPPOFR
PPPoFR Configuration Network requirements

Example Router A and Router B connect through frame relay network, and enable PPPoFR
between them.
Network diagram
Figure 50 Network diagram of PPPoFR
VT1 VT1
10.1.1.2/8 10.1.1.1/8
FR
S2/0 S2/0
Router A Router B
# Create and configure virtual template interface Virtual-Template 1
[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ip address 10.1.1.2 255.0.0.0
# Configure Serial 2/0

# Create PPP map on Serial 2/0
[RouterA-Serial2/0] fr map ppp 16 interface virtual-template 1

[RouterB] interface virtual-template 1
[RouterB-Virtual-Template1] ip address 10.1.1.1 255.0.0.0
[RouterB-Virtual-Template1] quit
# Configure Serial 2/0

[RouterB-Serial2/0] fr interface-type dce
# Create DLCI 16
# Create PPP map on Serial 2/0
[RouterB-Serial2/0] fr map ppp 16 interface virtual-template 1

MPOFR
11
■ “Configuring MPoFR” on page 265
■ “MPoFR Configuration Example” on page 266
Overview Multilink PPP over frame relay (MPoFR) is PPPoFR making use of MP fragments to
transmit MP fragments over frame relay stations.
In MPoFR configuration, first configure PPPoFR on two or more virtual templates (it
is not necessary to configure IP address on virtual templates), and then perform
the following configurations on these virtual templates to bind them to another
virtual template with PPP MP.
Configuring MPoFR Follow these steps to configure MPoFR:

Create a PPP MP virtual interface virtual-template -
template interface interface-number-mp
Configure the maximum qos max-bandwidth bandwidth Optional
bandwidth available for
For virtual template,
current interface
the default
maximum
bandwidth is 64
kbps.
Assign an IP address to ip address ip-address ip-mask Required
the current interface

266 CHAPTER 11: MPOFR

Configure PPPoFR on two Create virtual interface -
or more virtual templates, template interface virtual-template
and bind to virtual and enter the virtual interface-number
template interface template interface
configured with PPP MP view
Configure MP on ppp mp Required
virtual template virtual-template
interface interface-number-m
p
Enter the interface -
corresponding frame interface-type
relay interface interface-number
Configure frame relay link-protocol fr Required
as the link protocol
Configure a frame fr dlci dlci-number Required
relay DLCI
(optional for DTE
side)
Map frame relay DLCI fr map ppp Required
to PPP dlci-number
interface
virtual-template
interface-number
c CAUTION:
■ To ensure packet transmission quality over virtual-template (VT) interfaces, you
can configure queue-independent QoS features on VT interface and
queue-dependent QoS features on FR interface. For detailed information, refer
to “QoS Overview” on page 1623.
■ As for the next hop and the outbound interface, only the former is required
when you configure a static route on a virtual-template interface. If you want
to specify the outbound interface as well, make sure the physical interface
bound to the virtual-template interface is valid.
■ Refer to “PPP and MP Configuration” on page 363 for information about
MP-related configuration.
MPoFR Configuration Network requirements

Example ATM backbone network uses FR network as access network to support
transmission of multiple services. A single virtual circuit of FR link can transport
multiple kinds of service data.
As shown in the network diagram, the bandwidth of Router A Serial2/0 is 64

kbps. PC1 sends data service stream 1 to PC3, PC2 sends data service stream 2 to
PC4 and there is also a voice service stream.
The bandwidth of Router B Serial2/0 is 64 kbps. PC3 sends data service stream 3
to PC1, PC4 sends data service stream 4 to PC2, and there is also a voice service
stream.

To ensure voice quality, it is required to fragment the data packets to reduce voice
jitter caused by transmission delay. MPoFR is adopted here, and MP is used to
fragment data packets.
Network diagram
Figure 51 Net work diagram for MPoFR implementation
ATM
FR FR
Router A S2/0 S2 /0 Router B

1 .1. 6. 1/ 24 1.1.6.2/ 24
Eth1/ 0 Eth1/1 Eth1/0 Eth1/1

Telephone 1 .1.1.2/24 10 .1.1. 2/24 1. 1.4.2 /24 10.1 .4. 2/24 Telephone
Host A Host B Host C Host D

1.1 .1. 1/ 24 10.1. 1.1/ 24 1 .1. 4. 1/24 10.1.4. 1/24
n This example only covers PPPoFR related configuration. You need perform other
configurations on services, routes and so on.
# Configure ACL rule.
[RouterA] acl number 3001
[RouterA-acl-adv-3001] rule 0 permit ip source 1.1.1.0 0.0.0.255
[RouterA-acl-adv-3001] rule 1 permit ip source 10.1.1.0 0.0.0.255
[RouterA-acl-adv-3002] rule 0 permit tcp destination-port eq 1720
[RouterA-acl-adv-3002] rule 1 permit tcp source-port eq 1720
[RouterA-acl-adv-3002] quit
# Configure class liuliang.
[RouterA] traffic classifier liuliang

[RouterA-classifier-liuliang] if-match acl 3001
[RouterA-classifier-liuliang] quit
# Configure class liuliang corresponding behavior.

[RouterA] traffic behavior liuliang

[RouterA-behavior-liuliang] queue af bandwidth 20
[RouterA-behavior-liuliang] quit
# Configure class dial.
[RouterA] traffic classifier dial

[RouterA-classifier-dial] if-match acl 3002
[RouterA-classifier-dial] quit
# Configure class dial corresponding behavior
[RouterA] traffic behavior dial

[RouterA-behavior-dial] queue ef bandwidth 10 cbs 1500
[RouterA-behavior-dial] quit
# Configure policy.
[RouterA] qos policy liuliang

[RouterA-qospolicy-liuliang] classifier liuliang behavior liuliang
[RouterA-qospolicy-liuliang] classifier dial behavior dial
[RouterA-qospolicy-liuliang] quit
# Create and configure virtual template interface Virtual-Template 1.
[RouterA] interface irtual-template 1

[RouterA-Virtual-Template1] ppp mp virtual-template 3

[RouterA-Virtual-Template2] ppp mp virtual-template 3

[RouterA-Virtual-Template3] ppp mp lfi
[RouterA-Virtual-Template3] qos max-bandwidth 64
# Cancel fast forwarding defined in virtual template (CBQ is not supported when
fast forwarding is enabled).
[RouterA-Virtual-Template3] undo ip fast-forwarding

# Map specified DLCI to PPP virtual template on the interface.


# Enable real-time queue and policy on the interface to prevent interface

congestion
[RouterA-Serial2/0] qos apply policy liuliang outbound

[RouterA-Serial2/0] qos rtpq start-port 16384 end-port 32767 bandwid
th 20 cbs 1500
# Configure ACL rule
[RouterB] acl number 3001
[RouterB-acl-adv-3001] rule 0 permit ip source 1.1.4.0 0.0.0.255
[RouterB-acl-adv-3001] rule 1 permit ip source 10.1.4.0 0.0.0.255
[RouterB-acl-adv-3002] rule 0 permit tcp destination-port eq 1720
[RouterB-acl-adv-3002] rule 1 permit tcp source-port eq 1720
[RouterB-acl-adv-3002] quit
# Configure class 1
[RouterB] traffic classifier liuliang

[RouterB-classifier-liuliang] if-match acl 3001
[RouterB-classifier-liuliang] quit
# Configure class 1 corresponding behavior
[RouterB] traffic behavior liuliang

[RouterB-behavior-liuliang] queue af bandwidth 20
[RouterB-behavior-liuliang] quit
# Configure class 2
[RouterB] traffic classifier dial

[RouterB-classifier-dial] if-match acl 3002
[RouterB-classifier-dial] quit
# Configure class 2 corresponding behavior
[RouterB] traffic behavior dial

[RouterB-behavior-dial] queue ef bandwidth 10 cbs 1500
[RouterB-behavior-dial] quit
# Configure policy
[RouterB] qos policy liuliang

[RouterB-qospolicy-liuliang] classifier liuliang behavior liuliang
[RouterB-qospolicy-liuliang] classifier dial behavior dial
[RouterB-qospolicy-liuliang] quit
[RouterB] interface Virtual-Template 1

[RouterB-Virtual-Template1] ppp mp virtual-template 3


[RouterB-Virtual-Template2] ppp mp virtual-template 3

[RouterB-Virtual-Template3] ppp mp lfi
[RouterB-Virtual-Template3] qos max-bandwidth 64
# Cancel fast forwarding defined in virtual template (CBQ is not supported when
fast forwarding is enabled)
[RouterB-Virtual-Template3] undo ip fast-forwarding

# Map specified DLCI to PPP virtual template on the interface

# Enable real-time queue and policy on the interface to prevent interface

congestion
[RouterB-Serial2/0] qos apply policy liuliang outbound

[RouterB-Serial2/0] qos rtpq start-port 16384 end-port 32767 bandwid
th 20 cbs 1500

GVRP CONFIGURATION
12
GARP VLAN registration protocol (GVRP) is a “GARP” on page 271 application. It
functions based on the operating mechanism of GARP to maintain and propagate
dynamic VLAN registration information for the GVRP devices on the network.
When configuring GVRP, go to these sections for information you are interested
in:
■ “Introduction to GVRP” on page 271

■ “Configuring GVRP” on page 275
■ “Displaying and Maintaining GVRP” on page 276
■ “GVRP Configuration Example” on page 276
Introduction to GVRP This section covers these topics:

■ “GARP” on page 271
■ “GVRP Configuration” on page 271
■ “Protocols and Standards” on page 274
GARP Generic attribute registration protocol (GARP) provides a mechanism that allows
participants in a GARP application to distribute, propagate, and register with other
participants in a bridged LAN the attributes specific to the GARP application, such
as the VLAN or multicast address attribute.
GARP itself does not exist on a device as an entity. GARP-compliant application

entities are called GARP applications. One example is GVRP. When a GARP
application entity is present on a port on your device, this port is regarded a GARP
application entity.
■ “GARP messages and timers” on page 271

■ “Operating mechanism of GARP” on page 273
■ “GARP message format” on page 273
GARP messages and timers

1 GARP messages
GARP participants exchange information through the following three types of

messages: Join message, Leave message, and LeaveAll message.

272 CHAPTER 12: GVRP CONFIGURATION
■ A GARP participant uses Join messages to have its attributes registered on

other devices. A GARP participant also sends Join messages to register
attributes on other GARP participants when it receives Join messages from
other GARP participants or static attributes are configured on it.
■ A GARP participant uses Leave messages to have its attributes deregistered on
other devices. A GARP participant also sends Leave messages when it receives
Leave messages from other GARP participants or static attributes are
deregistered on it.
■ LeaveAll messages are used to deregister all the attributes, through which all
the other GARP participants begin to have all their attributes registered. A
GARP participant sends LeaveAll messages upon the expiration of the LeaveAll
timer, which is triggered when the GARP participant is created.
Join messages, Leave messages, and LeaveAll message make sure the
reregistration and deregistration of GARP attributes are performed in an orderly
way.
Through message exchange, all attribute information that needs registration

propagates to all GARP participants throughout a bridged LAN.
2 GARP timers
The interval of sending of GARP messages is controlled by the following four

timers.
■ Hold timer
A GARP participant usually does not forwards a received registration request

immediately after it receives a registration request, instead, it waits for the
expiration of the hold timer. That is, a GARP participant sends Join messages when
the hold timer expires. The Join message contains all the registration information
received during the latest Hold timer cycle. Such a mechanism saves the
bandwidth.
■ Join timer
Each GARP participant sends a Join message twice for reliability sake and uses a
join timer to set the sending interval. If the first Join message is not acknowledged
after the interval defined by the Join timer, the GARP participant sends the second
Join message.
■ Leave timer
A Leave timer starts upon receipt of a Leave message sent for deregistering some
attribute information. If no Join message is received before this timer expires, the
GARP application entity removes the attribute information as requested.
■ LeaveAll timer
A LeaveAll timer starts when a GARP application entity starts. When this timer
expires, the entity sends a LeaveAll message so that other entities can re-register
its attribute information. Then, a LeaveAll timer starts again.

Introduction to GVRP 273
n ■ The settings of GARP timers apply to all GARP applications, such as GVRP, on a
LAN.
■ Unlike other three timers, which are set on a port basis, the LeaveAll timer is
set in system view and takes effect globally.
■ A GARP application entity may send LeaveAll messages at the interval set by its
LeaveAll timer or the LeaveAll timer on another device on the network,
whichever is smaller. This is because each time a device on the network receives
a LeaveAll message it resets its LeaveAll timer.
Operating mechanism of GARP

The GARP mechanism allows the configuration of a GARP participant to
propagate throughout a LAN quickly. In GARP, a GARP participant registers or
deregisters its attributes with other participants by making or withdrawing
declarations of attributes and at the same time, based on received declarations or
withdrawals handles attributes of other participants. When a port receives an
attribute declaration, it registers the attribute; when a port receives an attribute
withdrawal, it deregisters the attribute.
GARP application entities send protocol data units (PDU) with a particular
multicast MAC address as destination. Based on this address, a device can identify
to which GVRP application, GVRP for example, should a GARP PDU be delivered.
GARP message format

The following figure illustrates the GARP message format.
Figure 52 GARP message format
DA DA length DSAP SSAP Ctrl PDU Ethernet Frame
1 3 N
Protocol ID Message 1 ... Message N End Mark GARP PDU structure
1 2 N
Attribute Type Attribute List Message structure
1 N
Attribute 1 ... Attribute N End Mark Attribute List structure
1 2 3 N
Attribute Length Attribute Event Attribute Vlaue Attribute structure
The following table describes the GARP message fields.
Table 2 Description on the GARP message fields
Field Description Value

Protocol ID Protocol identifier for GARP 1

Table 2 Description on the GARP message fields
Field Description Value

Message One or multiple messages, each --
containing an attribute type and an
attribute list
Attribute Type Defined by the concerned GARP 0x01 for GVRP, indicating the
application VLAN ID attribute
Attribute List Contains one or multiple attributes --
Attribute Consists of an Attribute Length, an --
Attribute Event, and an Attribute Value
Attribute Length Number of octets occupied by an 2 to 255 in bytes
attribute, inclusive of the attribute length
field
Attribute Event Event described by the attribute 0: LeaveAll Event
1: JoinEmpty Event
2: JoinIn Event
3: LeaveEmpty Event
4: LeaveIn Event
5: Empty Event
Attribute Value Attribute value VLAN ID for GVRP
If the Attribute Event is
LeaveAll, Attribute Value is
omitted.
End Mark Indicates the end of a GARP PDU 0x00
GVRP GVRP enables a device to propagate local VLAN registration information to other
participant devices and dynamically update the VLAN registration information
from other devices to its local database about active VLAN members and through
which port they can be reached. It thus ensures that all GVRP participants on a
bridged LAN maintain the same VLAN registration information. The VLAN
registration information propagated by GVRP includes both manually configured
local static entries and dynamic entries from other devices.
GVRP provides the following three registration types on a port:
■ Normal: Enables the port to dynamically register and deregister VLANs, and to
propagate both dynamic and static VLAN information.
■ Fixed: Disables the port to dynamically register and deregister VLANs or
propagate information about dynamic VLANs, but allows the port to propagate
information about static VLANs. A trunk port with fixed registration type thus
allows only manually configured VLANs to pass through even though it is
configured to carry all VLANs.
■ Forbidden: Disables the port to dynamically register and deregister VLANs, and
to propagate VLAN information except information about VLAN 1. A trunk
port with forbidden registration type thus allows only VLAN 1 to pass through
even though it is configured to carry all VLANs.
Protocols and Standards IEEE 802.1Q specifies GVRP.

Configuring GVRP 275
Configuring GVRP
n GVRP can only be configured at the Trunk port.
GVRP configuration is broken down into: configuring GVRP functions and

configuring GARP timers.
Configuring GVRP Follow these steps to configure GVRP functions on a trunk port:
Functions
Enable global GVRP gvrp Required
Disabled by default
Enter Ethernet Enter Ethernet interface interface-type Use either the command.
interface view interface view interface-number
Configured in Ethernet
or port group
Enter port port-group { aggregation interface view, the
view
group view agg-id | manual subsequent configuration is
port-group-name } effective on the current port
only; configured in port
group view, the subsequent
configuration is effective on
all ports in the port group.
Enable GVRP gvrp Required
Disabled by default
Set the GVRP registration gvrp registration { fixed | Optional
mode forbidden | normal }
The default is normal.
Configuring GARP Follow these steps to configure GARP timers:

Timers
Configure the GARP LeaveAll garp timer leaveall Optional
timer timer-value
The default is 1000
centiseconds.
Enter Ethernet Enter Ethernet interface interface-type Use either the command
or port group
Enter port port-group { aggregation interface view, the
view
group view agg-id | manual subsequent configuration is
port-group-name } effective on the current port
only; configured in port
group view, the subsequent
configuration is effective on
all ports in the port group.
Set the hold timer, join timer, garp timer { hold | join | Optional
and leave timer leave } timer-value
The default is 10 centiseconds
for the hold timer, 20
centiseconds for the join
timer, and 60 centiseconds
for the leave timer.
As for the GARP timers, note that:

■ The setting of each timer must be a multiple of five (in centiseconds).

■ The settings of the timers are correlated. If you fail to set a timer to a certain
value, you can try to adjust the settings of the rest timers. Table 3 shows the
relationship between the timers.
Table 3 Relationship between GARP timers
Timer Lower limit Upper limit

Hold 10 centiseconds Not greater than half of the join
timer setting
Join Not less than two times the hold timer Less than half of the leave timer
setting setting
Leave Greater than two times the join timer Less than the LeaveAll timer
setting setting
LeaveAll Greater than the leave timer setting 32765 centiseconds
Displaying and
Maintaining GVRP To do... Use the command... Remarks
Display statistics about GARP display garp statistics Available in any view
[ interface interface-list ]
Display GARP timers for display garp timer Available in any view
specified or all ports [ interface interface-list ]
Display statistics about GVRP display gvrp statistics Available in any view
Display the global GVRP state display gvrp status Available in any view
Clear the GARP statistics reset garp statistics Available in user view
GVRP Configuration
Example
GVRP Configuration Network requirements

Example I Configure GVRP for dynamic VLAN information registration and update among
devices, adopting the normal registration mode on ports.
Network diagram
Figure 53 Network diagram for GVRP configuration
Eth1/0 Eth1/1
Device A Device B
1 Configure Device A
# Enable GVRP globally.
<DeviceA> system-view
[DeviceA] gvrp

# Configure port Ethernet 1/0 as a trunk port, allowing all VLANs to pass.
[DeviceA] interface ethernet 1/0

[DeviceA-Ethernet1/0] port link-type trunk
[DeviceA-Ethernet1/0] port trunk permit vlan all
# Enable GVRP on Ethernet 1/0, the trunk port.
[DeviceA-Ethernet1/0] gvrp
[DeviceA-Ethernet1/0] quit
# Create VLAN 2 (a static VLAN).
[DeviceA] vlan 2
2 Configure Device B
<DeviceB> system-view
[DeviceB] gvrp
[DeviceB] interface ethernet 1/1

[DeviceB-Ethernet1/1] port link-type trunk
[DeviceB-Ethernet1/1] port trunk permit vlan all
# Enable GVRP on Ethernet 1/1, the trunk port.
[DeviceB-Ethernet1/1] gvrp
[DeviceB-Ethernet1/1] quit
[DeviceB] vlan 3
3 Verify the configuration
# Display dynamic VLAN information on Device A.
[DeviceA] display vlan dynamic

Now, the following dynamic VLAN exist(s):
3
# Display dynamic VLAN information on Device B.
[DeviceB] display vlan dynamic

2

Example II Configure GVRP for dynamic VLAN information registration and update among
devices. Specify fixed GVRP registration on Device A and normal GVRP registration
on Device B.

Network diagram
Eth1/0 Eth1/1
Device A Device B
[DeviceA] gvrp

# Enable GVRP on Ethernet 1/0.
# Set the GVRP registration type to fixed on the port.
[DeviceA-Ethernet1/0] gvrp registration fixed

[DeviceA] vlan 2
[DeviceB] gvrp

[Sysname] vlan 3


No dynamic vlans exist!

2

Example III To prevent dynamic VLAN information registration and update among devices, set
the GVRP registration mode to “forbidden” on Device A and “normal” on Device
B.
Network diagram
Eth1/0 Eth1/1
Device A Device B
[DeviceA] gvrp

# Set the GVRP registration type to forbidden on the port.
[DeviceA-Ethernet1/0] gvrp registration forbidden

[DeviceA] vlan 2

[DeviceB] gvrp

[DeviceB] vlan 3



HDLC CONFIGURATION
13
When configuring HDLC, go to these sections for information you are interested
in:
■ “Introduction to HDLC” on page 281
■ “Configuring HDLC” on page 282
Introduction to HDLC
HDLC Overview High-level data link control (HDLC) is a bit-oriented link layer protocol. Its most
prominent feature is that it can transmit any types of bit stream transparently.
■ HDLC supports point-to-point link only and does not support
point-to-multipoint link.
■ HDLC supports neither IP address negotiation nor authentication. It uses
keepalive messages to check link status.
■ HDLC can only be encapsulated on synchronous link. A synchronous
/asynchronous interface can also apply HDLC provided that it works in
synchronous mode. Currently, this protocol is applied on the Serial interface
and POS interface that work in synchronous mode.
HDLC Frame Format and There are three types of HDLC frames: information frame (I frame), supervision
Frame Type frame (S frame) and unnumbered frame (U frame).
■ Information frame is responsible for transmitting useful data or information.
■ Supervision frame is responsible for error control and flow control.
■ Unnumbered frame is responsible for the link establishment, teardown, and so
on.
An HDLC frame is composed of flag field, address field, control field, information
field and checksum field.
■ The flag field, 0111111, marks the beginning and end of an HDLC frame. Each
frame begins with F and ends with F.
■ The address field is eight bits; it identifies the source or destination where the
frame is sent or received.
■ The control field is eight bits; it identifies the control type and defines the frame
type (control or data).
■ The information field can be an arbitrary binary bit set. The minimum length
can be zero and the maximum length is decided by the FCS field or the buffer
size of the communicating node. Generally, the maximum length is between
1000 and 2000 bits.

282 CHAPTER 13: HDLC CONFIGURATION
■ The checksum field can use a 16-bit CRC to check the content of a frame.
Configuring HDLC Follow these steps to configure HDLC protocol:

interface-number
Enable HDLC on the link-protocol hdlc Required
interface
PPP is encapsulated by default.
The polling interval is 10 seconds by
default.

X.25 AND LAPB CONFIGURATION
14
When configuring LAPB and X.25, go to these sections for information you are
interested in:
■ “Introduction to X.25 and LAPB Protocols” on page 283
■ “Configuring LAPB” on page 285
■ “Configuring X.25” on page 286
■ “X.25 PAD Remote Access Service” on page 305
■ “Configuring X.25 over TCP (XOT)” on page 307
■ “Configuring X.25 over FR” on page 310
■ “Configuring X2T” on page 312
■ “Displaying and Maintaining LAPB and X.25” on page 314
■ “LAPB Configuration Example” on page 314
■ “X.25 Configuration Examples” on page 316
■ “X2T Configuration Example” on page 339
■ “Troubleshooting LAPB Configuration” on page 340
■ “Troubleshooting X.25 PAD” on page 307
Introduction to X.25 The X.25 protocol specifies the interface standards between data terminal
and LAPB Protocols equipment (DTE) and data circuit-terminating equipment (DCE). In 1974, CCITT
issued the first draft of X.25, whose initial files were based on the experiences and
recommendations of Telnet and Tymnet of USA and Datapac packet-switched
networks of Canada. It was revised in 1976, 1978, 1980 and 1984, added many
optional service functions and facilities.
X.25 allows two DTEs to communicate with each other over the existing telephone
network.
One DTE contacts the other to setup a connection. The other DTE can either
accept or refuse the connection as required. Once the connection is established,
the devices at both ends can transmit information in full duplex mode, and either
end can disconnect the connection at any time.
X.25 is the protocol for point-to-point interaction between DTE and DCE. DTE
usually refers to the host or terminal at the user side, and DCE usually refers to a
device like the synchronous modem. DTE is connected with DCE directly, DCE is
connected to a port of packet switching exchange (PSE), and some connections
are established between the packet switching exchanges, thus forming the paths
between different DTEs. In an X.25 network, the relation of entities is shown in
the following diagram:

284 CHAPTER 14: X.25 AND LAPB CONFIGURATION
Figure 56 X.25 network model
DTE
PSE DCE
DTE DCE PSE
PSE DCE
DTE
PSN
DTE Data terminal equipment
DCE Data circuit-terminating equipment
PSE Packet switching equipment
PSN Packet switching network
The X.25 protocol defines the lowest three layers of the OSI (Open System
Interconnection) reference model. As shown in the following figure, layer 3
(packet layer) provision of X.25 describes the packet format used by the packet
layer and the procedure of packet switching between two layer-3 entities. Layer 2
(link layer) provision of X.25, also known as Link Access Procedure Balanced
(LAPB), defines the frame format and procedure adopted in the DTE-DCE
interaction. Layer 1 (physical layer) of X.25 defines some physical and electrical
characteristics in the connection between DTE and DCE.
Figure 57 DTE/DCE interfaces
OSI reference model X.25
7
6
5
4
Packet layer
3 X.25 packet layer X.25 packet layer
interface
Data link
2 X.25 data link layer X.25 data link layer
interface
Physical layer
1 X.25 physical layer X.25 physical layer
interface
DTE DCE
The connection established via X.25 protocol between two DTEs is called virtual
circuit (VC), which exists logically and is distinct from the physical circuit in circuit
switching in nature. VCs involve Permanent Virtual Circuit (PVC) and Switched
Virtual Circuit (SVC). PVC is used for transmitting traffic that is generated in a
frequent but stable way and SVC for transmitting traffic that is generated in a
burst way.
Once a virtual circuit is established between a pair of DTEs, it is assigned a unique

virtual circuit number. When one DTE is to send a packet to the other, it numbers
this packet (with virtual circuit number) and sends it to DCE. According to the
number on the packet, DCE determines how to switch this packet within the
switching network, so that this packet can reach the correct destination. A link

Configuring LAPB 285
established between DTE and DCE by X.25 layer 2 (LAPB) is multiplexed by X.25
layer 3, and those finally presented to users are several usable virtual circuits.
The relation between packets and frames in the X.25 layers is shown in the
following diagram.
Figure 58 X.25 packet and LAPB frame
X.25 Layer 3 Packet

Packet User data
header
Frame
X.25 Layer 2 Frame Frame Frame
delimiter header Data check
delimiter
Frame sequence
X.25 Layer 1 Bit stream
X.25 link layer specifies the frame switching process between DTE and DCE. From
the perspective of layering, the link layer is just like a bridge interconnecting the
packet layer interface of DTE and that of DCE. Through this bridge, packets can be
transmitted continuously between the packet layer of DTE and that of DCE. The
link layer has the following main functions:
■ Transmit the data effectively between DTE and DCE

■ Ensure the synchronization of information between the receiver and sender
■ Detect and correct errors in the transmission
■ Identify and report the procedure error to the higher layer protocol
■ Inform the packet layer of the link layer state
As specified in international standards, the link layer protocol LAPB of X.25 adopts
the frame structure of High-level Data Link Control (HDLC) and is a subset of
HDLC. It requires for setting up a link by making use of the Set Asynchronous
Balanced Mode (SABM) command. A two-way link can be established after either
site sends an SABM command and the other replies with a UA response.
Although defined for X.25, as a separate link layer protocol, LAPB can directly
carry non-X.25 upper layer protocols for data transmission. You can set the link
layer protocol of serial interface as LAPB and transmit data locally. Meanwhile, the
X.25 implementation has switching function. Therefore, the device can be used as
a small-sized X.25 packet switch, thus protecting users’ investment in X.25. The
following figure describes the relation between LAPB, X.25 and X.25 switching.
Figure 59 Relation between LAPB, X.25 and X.25 switching
IP
X.25
switching
X.25
LAPB
Configuring LAPB Follow these steps to configure LAPB:


interface-number
Configure link layer link-protocol lapb [ dce | Required
protocol as LAPB dte ] [ ip | multi-protocol ]
By default, the link layer protocol is
PPP. When LAPB is configured, the
interface works as DTE with upper
layer as IP.
Configure the modulo lapb modulo { 8 | 128 } Optional
Defaults to 8
Configure LAPB lapb window-size k-value Optional
window parameter K
Defaults to 7
Configure LAPB lapb max-frame n1-value Optional
parameter N1
The default N1 is calculated
according to the MTU, upper layer
and modulus value.
Configure LAPB lapb retry n2-value Optional
parameter N2
Defaults to 10
Configure the system lapb timer { t1 t1-value | t2 Optional
timers T1, T2 and T3 in t2-value | t3 t3-value }
By default:
LAPB
■ T1 is 3000 milliseconds
■ T2 is 1500 milliseconds
■ T3 is 0 second
Configuring X.25
Configuring X.25 X.121 address

Interface Parameters If the device is used for X.25 switching, this task can be skipped. If it is connected
to X.25 public packet network, you must set an X.121 address for the connected
X.25 interface according to the requirements of the ISP. As defined in ITU-T
recommendation X.121, an X.121 address is a string of 1 to 15 numbers.
X.25 operating mode

Layer 3 of X.25 supported by your device can work in either DTE mode, or in DCE
mode. The format of the datagram is alternative, either IETF or nonstandard.
Note that an X.25 public packet switching network requires the device to access
the network as DTE and to be encapsulated with the IETF format generally.
Therefore, the operating mode of X.25 should be DTE and the encapsulation
format should be IETF. When two routers are connected back to back through
serial interfaces, ensure that they are using the same encapsulation format and are
respectively working as the DTE and DCE.
X.25 virtual circuit range

The X.25 protocol can create multiple logical virtual connections over a physical
link between DTE and DCE. These virtual connections are called Virtual Circuits
(VCs) or Logic-Channels (LCs). Up to 4095 virtual circuits can be established by

X.25, and their numbers range from 1 to 4095. The number used to differentiate
each virtual circuit (or logic channel) is called Logic Channel Identifier (LCI) or
Virtual Circuit Number (VCN).
n Strictly speaking, VC and LC are different. However, at the user end, they are
generally not distinguished strictly.
An important part of X.25 operation is how to manage the total 4,095 virtual
circuits. All the virtual circuit numbers are divided into four ranges (listed here in
ascending order):
■ A-Permanent virtual circuits (PVCs) range

■ B-Incoming-only channel range
■ C-Two-way channel range
■ D-Outgoing-only channel range
The numbers of the virtual circuits established by an X.25 call must be set in the
ranges of B, C and D. The permanent virtual circuits must be set in the A range.
According to ITU-T Recommendation X.25, the idle channel allocation rules in

initiating calls are as follows:
■ Only the DCE can initiate a call using a channel in the incoming-only channel
range.
■ Only the DTE can initiate a call using a channel in the outgoing-only channel
range.
■ Both the DCE and the DTE can initiate a call using a channel in the two-way
channel range.
■ DCE always uses the lowest available logic channel.
■ DTE always uses the highest available logic channel.
Thus, we can avoid the case that one side of the communication occupies all the
channels, and minimize the possibility of call collision.
In X.25 protocol, six parameters are employed to define the four ranges, as shown
in the following figure.
Figure 60 X.25 channel delimitation
1
PVC range
LIC Incoming-only
channel range
HIC
unused
LTC Two-way
channel range
HTC
Unused
LOC
Outgoing-only
channel range
HOC
Unused
4095

For the meanings of these six parameters, refer to Table 4.
Table 4 Description of X.25 channel range delimitation parameters
Parameter Description
LIC Lowest Incoming-only Channel
HIC Highest Incoming-only Channel
LTC Lowest Two-way Channel
HTC Highest Two-way Channel
LOC Lowest Outgoing-only Channel
HOC Highest Outgoing-only Channel
Each range (except PVC range) is defined by two parameters respectively working
as the upper limit and lower limit. The parameters are in the range of 1 to 4095
(including 1 and 4095), but they are regarded correct only if they satisfy the
following conditions:
■ In strict ascending order, i.e. 1 ≤ lic ≤ hic< ltc ≤ htc < loc ≤ hoc ≤ 4095.
■ If the upper limit (or lower limit) of a range is 0, then the lower limit (or upper
limit) shall also be 0, (which indicates this range is disabled from use).
Finally, following should be noted:
■ At the two sides (i.e. DTE and DCE) of a physical connection, these six
parameters of X.25 must be equal in a symmetric way, as different settings at
the two sides are very likely to result in an improper procedure and hence result
in transmission failures.
■ In configuration process, implement the correct settings of parameters with
consideration on the default of each parameter and the ascending order.
■ The new configuration cannot take effect immediately on a connection in use
unless you reset the interface using the commands shutdown and undo
shutdown.
X.25 packet numbering modulo

The implementation of X.25 supports both modulo 8 and modulo 128 in packet
numbering, with Modulo 8 being the default.
The X.25 protocol requires DTE and DCE have the same packet sequence
numbering mode. The new configuration is not effective unless you reset the
interface using the shutdown command and undo shutdown command.
Besides, the packet sequence numbering mode of X.25 layer 3 is different from
the frame sequence numbering mode of LAPB (X.25 layer 2). When modulo 128
numbering mode is employed in the DTE/DCE interface with high throughput rate,
for LAPB, only the efficiency of local DTE/DCE interface is affected, that is,
point-to-point efficiency increases. While for X.25 layer 3, the efficiency of
end-to-end is affected, that is, the efficiency between the two DTE increases.
Traffic control parameters

X.25 protocol is a reliable transport protocol with powerful traffic control
capability due to the “window size” and “maximum packet size”. However, it

cannot perform traffic control effectively and correctly unless correctly configured.
Any inappropriate configuration will cause CLEAR and RESET events of X.25. As
most public X.25 packet networks use the default window size and maximum
packet size specified in ITU-T X.25 Recommendation, the device also adopts the
same default values. Therefore, you need not set the two parameters unless
requested by the access service providers.
After the default window size and the default maximum packet size are set, the
SVC, which can be established only via calling, will use these default values if
related parameters are not negotiated in the call process. (Parameter negotiation
will be described in the later sections). The PVC, which can be established directly
without calling, will also use these default values if no window size or packet size
option is appended when it is specified. (Refer to “Configuring PVC Application of
X.25 over FR” on page 311).
An X.25 sender will fragment the oversize data packets at the upper layer based
on the maximum packet size, and mark the final fragment packet (M bit not set).
After the packets reach the receiver, X.25 will reassemble the fragment packets,
and determine whether a piece of complete upper layer packet is received based
on the M bit flag. Therefore, too small value of the maximum packet size will
consume too much router resources on message fragmenting and reassembling,
thus lowering efficiency.
Note that:
■ The maximum packet size < 8*MTU < N1 of LAPB

■ Reset interface using the shutdown and undo shutdown commands to
make new configuration take effect
To configure X.25 interface parameters, use the following commands:

interface-number
Configure the link layer link-protocol x25 [ dce |dte ] Required
protocol as X.25 [ ietf | nonstandard ]
The default link layer protocol is
PPP by default. With X.25 enabled,
the default operation mode is DTE
IETF.
Set an X.121 address x25 x121-address Optional
for the interface x.121-address
If the device is used for the purpose
of X.25 switching, this task can be
skipped. If it is connected to X.25
public packet network, you must
set an X.121 address for the
connected X.25 interface.
Set X.25 VC range x25 vc-range { bi-channel ltc Optional
htc [ out-channel loc hoc ] |
By default, lower and upper limits
in-channel lic hic
of two-way channel are 1 and
[ bi-channel ltc htc ]
1024, of incoming-only channel are
[ out-channel loc hoc ] |
both 0, of outgoing-only channel
out-channel loc hoc }
are both 0


Set the modulo x25 modulo { 8 | 128 } Optional
Defaults to 8
Set the sizes of VC input x25 window-size Optional
window and output input-window-size
By default, input-window-size is 2
window output-window-size
and output-window-size is 2
Set the maximum sizes x25 packet-size input-packet Optional
for input and output output-packet
By default, input-packet is 128
packets on the interface
bytes and output-packet is 128
bytes
Configuring X.25 It is necessary to configure certain supplementary X.25 parameters in some special
Interface Supplementary network environments. The section is related to these supplementary parameters.
Parameters
X.25 layer 3 delay timer
X.25 protocol defines a series of timers to facilitate its procedure. After X.25 sends
a control message, if it does not receive the response before the timeout of the
corresponding timer, X.25 protocol will take corresponding measure to handle this
abnormal event. The names and corresponding procedures of these timers are
shown in the following table.
Table 5 X.25 Layer 3 timer
Timer name
Procedure name DTE side DCE side
Restart T20 T10
Call T21 T11
Reset T22 T12
Clear T23 T13
Register T28 -
T28 is “Registration request sending” timer that is only defined on DTE for
dynamically requesting the network for optional services or stopping these
services. Its default value is 300 seconds, which cannot be changed.
Attributes related to X.25 address

To establish a SVC with a call, X.25 address is needed, which adopts the address
format specified in ITU-T Recommendation X.121. An X.121 address is a string of
0 to 15 digits. Some attributes related to X.121 address are as follows:
1 Alias of interface
When an X.25 call is forwarded across multiple networks, different networks will
likely make some modifications on the called address as needed, such as adding or
deleting the prefix. In such cases, the destination address of a call that reaches
X.25 interface may be inconsistent with X.121 address of the destination interface
(because the destination address of this call is modified within the network), still
the interface should accept this call. For this purpose, one or more alias names
must be specified for this interface.

To meet the requirements of different networks, X.25 defines nine match types
and their relevant alias string formats, as shown in the following table.
Table 6 Alias match modes and meanings
Matching mode Description Example

free Free matching, the alias string 1234" will match 561234, 1234567
is in the form of 1234 and 956123478, but will not match
12354.
free-ext Extended free matching, in ...1234 .." will match 678123459, but
which the alias string is in the will not match 68123459, 67812345
form of ...1234.. and 6781234591.
left Left-most matching mode, in $1234" will match 1234567 and
which the alias string is in the 12346790, but will not match
form of $1234 3123478 and 123784.
left-ext Extended left-most matching $1234 ..." will match 1234679 and
mode, in which the alias string 1234872, but will not match 123468
is in the form of $1234... and 12346890.
right Rightmost matching mode, in 1234$" will match 791234 and
which the alias string is in the 6901234, but will not match 7912345
form of 1234$ and 6212534.
right-ext Extended rightmost matching ....1234$" will match 79001234 and
mode, the alias string is in the 86901234, but will not match
form of ....1234$ 7912345 and 506212534.
strict Strict matching mode, in $1234$" can only match 1234
which the alias string is in the
form of $1234$
whole Whole matching mode, in ........" will match all the valid X.121
which the alias string is in the addresses of 8 digits in length
form of ........
whole-ext Extended whole matching *" will match all the valid X.121
mode, in which the alias string addresses
can only be *
2 Attributes related to the address code block in calling or called packets
As defined in the X.25 protocol, a call packet must carry the information set of
both the calling DTE address (source address) and the called DTE address
(destination address). This address information set is called the address code block.
While in call accept packet, some networks require that both (the calling DTE
address and the called DTE address) be carried, some networks require that only
one of the two be carried, while some others require that neither should be
carried. To adapt the difference between various networks, you can select as
required.
3 Default upper layer protocol that X.25 bears
An X.25 call request packet includes a CUD (Call User Data) field that indicates the
upper layer protocol type carried over X.25 protocol. When receiving an X.25 call,
the device will check the CUD field in the packet. If receiving a call carrying an
unidentifiable CUD field, the router will deny it. However, an upper layer protocol
can be specified as the default protocol on the X.25. When X.25 receives a call
with an unrecognizable CUD, it will treat it as the customized default upper layer
protocol.

To configure X.25 interface supplementary parameters, use the following
commands:

interface-number
Set the restart timer delay value x25 timer tx0 seconds Optional
By default, the value for DTE is
180 seconds, and the value for
DCE is 60 seconds.
Set the call request timer for DTE x25 timer tx1 seconds Optional
or the call indication timer for
DCE
DCE is 180 seconds.
Set the reset request timer for x25 timer tx2 seconds Optional
DTE or the reset indication timer
for DCE
DCE is 60 seconds.
Set the clearing request timer for x25 timer tx3 seconds Optional
DCE or the clearing request timer
for DTE
DCE is 60 seconds.
Configuring Specify an alias for x25 alias-policy Optional
the attributes the interface match-type alias-string
Not specified by default
related to
X.25 address Carry no X.121 x25 ignore Optional
address of the called-address
Carried by default
called DTE in each
call packet
Carry no X.121 x25 ignore Optional
address of the calling-address
Carried by default
calling DTE in each
call packet
Carry the address x25 response Optional
of the called DTE called-address
Not carried by default
in each
call-acceptance
packet
Carry the address x25 response Optional
of the calling DTE calling-address
Not carried by default
in each
call-acceptance
packet
Specify the default x25 default-protocol Optional
upper layer protocol-type
protocol
Configuring X.25 In the most frequently used X.25 service, data is transmitted between two hosts
Datagram Transmission using the X.25 protocol through X.25 packet switching network. As shown in the
following figure, LAN 1 and LAN 2 are far apart, and the large and distributed
X.25 packet switching network can be used to realize information exchange
between them.

Figure 61 Interconnecting LANs via X.25
LAN 1 LAN 2
X.25 packet
switching
network
Router A Router B
LAN 1 and LAN 2 communicate with each other by sending the datagrams
carrying Internet Protocol (IP) addresses. However, X.25 uses the X.121 address.
Therefore, to solve the problem, the mapping between IP address and X.121
address needs to be established. In other words, to enable X.25 to transmit data
remotely, correctly establishing the address mapping is very significant. This
section will deal with how to establish address mapping.
Create protocol to X.121 address mapping

An X.25 interface has its own X.121 address and internetworking protocol (such
as IP protocol) address. When X.25 initiates a call through this interface, the
source address (calling DTE address) in the call request packet is the X.121 address
of this interface.
Then, how can the router target the destination of the call? In other words, how
can the router determine the X.121 address for the IP address destination? For this
purpose, the router will look up the protocol-address-to-X.121 address mappings
that have been configured on the router. A direct call destination has its own
protocol address and X.121 address. In this case, a destination
protocol-address-to-X.121 address mapping must be created on the source.
Through the mapping, X.25 can find the destination X.121 address according to
the destination protocol address to initiate a call successfully. This is why the
address mapping shall be established for X.25.
n Such a mapping should be created for every destination.
Creating PVC
A PVC can be created for the data transmission featuring large but stable traffic
size and requiring the service quality of leased line. A PVC does not need any call
process and will always exist once set up. Before creating a PVC, it is unnecessary
to create an address mapping, because an address mapping is created implicitly
when a PVC is created.
To configure X.25 datagram transmission, use the following commands:

interface-number
Create a mapping of the x25 map protocol-type Required
destination protocol address to protocol-address x121-address
Not created by default
X.121 address x.121-address [ option ]


Specify the VC range x25 vc-range { bi-channel ltc htc Required for PVC
[ out-channel loc hoc ] | creation
in-channel lic hic [ bi-channel ltc
htc ] [ out-channel loc hoc ] |
Create a PVC x25 pvc pvc-number protocol-type Required
protocol-address x121-address
x.121-address [ option ]
n ■ Since the default two-way channel range: LTC=1, HTC=1024 does not support
PVC configuration, you need to specify a VC range using the x25 vc-range
command to create a PVC.
■ If a PVC has no related parameters configured, its traffic control parameters are
the same as that of its X.25 interface that is set by the commands x25
packet-size, x25 window-size.
Configuring Additional X.25 allows the addition of some characteristics, including a series of optional user
Parameters for X.25 facilities provisioned in ITU-T Recommendation X.25, for the sake of improving
Datagram Transmission performance and broadening application ranges.
This section describes how to configure such additional features, including the
options in the x25 map and x25 pvc command. Select and configure these
additional features according to X.25 network structure, and the services provided
by service provider.
To configure additional parameters for X.25 datagram transmission, use the

commands described in the following sub sections:
To do... Remarks
Enter system view -
“Specify the maximum idle time of SVC” on page 294 Optional
“Specify the maximum number of SVCs allowed to associate with the same Optional
address mapping” on page 295
“Configure packet pre-acknowledgement” on page 295 Optional
“Configure X.25 user facility” on page 296 Optional
“Configure the data queue length of VC” on page 297 Optional
“Broadcast via X.25” on page 298 Optional
“Restrict the use of address mapping” on page 298 Optional
Specify the maximum idle time of SVC

For the sake of cost saving, you can specify an SVC idle time upon the expiration
of which the SVC will be disconnected. Enabling this feature will not affect the
data transmission, as a new SVC can be set up again if there are new packets
waiting for transmission.
To configure an SVC idle time, use the following commands:



interface-number
Specify maximum idle time for x25 timer idle minutes Optional
all the SVCs on the interface
Defaults to 0 minute, no SVC
cleared automatically in this
case.
Specify maximum idle time for x25 map protocol-type Optional
SVC associated with an protocol-address
No mapping created by
address mapping x121-address x.121-address
default, if created, the value
idle-timer minutes
defaults to 0 minute, no SVC
cleared automatically in this
case.
Specify the maximum number of SVCs allowed to associate with the same
address mapping
You can specify the maximum number of SVCs allowed to set up for the same
address mapping. Be default, an X.25 address mapping can only be associated
with one VC. In case of busy traffic and slow line speed, you can increase this
number properly to reduce data loss. Up to 8 SVCs can be associated to an X.25
address mapping.
To configure the task, use the following commands:

interface-number
Specify the maximum number of x25 vc-per-map count Optional
SVCs associated with all address
The count
mappings on the X.25 interface
defaults to 1
Specify the maximum number of x25 map protocol-type
SVCs associated with an address protocol-address x121-address
mapping x.121-address vc-per-map count
Configure packet pre-acknowledgement

According to X.25 protocol, only after the input-window becomes full (i.e. the
number of received packets is equal to the value of window-size
input-window-size) will the receiving end send an acknowledgement. However, in
some X.25 networks, the delays may be long, resulting in low efficiency of sending
and receiving. X.25 allows you to specify an input-window size. Each time the
number of received packets reaches the value, the router will send an
acknowledgment to the peer, thus to improve the receiving and sending efficiency.
The value is called “receive-threshold”, which ranges from 0 to
input-window-size. If it is set to 1, every packet will be acknowledged. If it is set to
input-window-size, the acknowledgment will be sent only after the receiving
window is full. In applications requiring a high response speed, this function is
especially important.
To configure packet pre-acknowledgement, use the following commands:


interface-number
Set packet acknowledgment x25 receive-threshold count Optional
value
Defaults to 0, no pre-ack
available in this case
For information about input window size, refer to “Traffic control parameters” on
page 288.
Configure X.25 user facility

X.25 stipulates various user facilities, you can select and configure them. These
configurations can be modified in two ways:
■ X.25 interface-based configuration (by using the x25 call-facility command)
■ address-mapping-based configuration (by using the x25 map command)
The configuration based on X.25 interface will be effective in every call originating
from this X.25 interface, while the configuration based on address mapping will
be effective only in the calls originating from this address mapping.
1 X.25 interface based configuration
To do so, use the following commands:

Define ROA (Recognized x25 roa-list roa-name Optional
operating Agency) list roa-id&<1-10>
Not defined by default
interface-number
Specify CUG (Closed User x25 call-facility Optional
Group) number closed-user-group number
Perform max packet x25 call-facility packet-size Optional
negotiation while initiating a input-packet output-packet
call
Perform window size x25 call-facility Optional
negotiation while initiating a window-size
Not configured by default
call input-window-size
output-window-size
Request reverse charging x25 call-facility Optional
when initiating a call reverse-charge-request
Receive calls with reverse x25 reverse-charge-accept Optional
charging requests
Request throughput-level x25 call-facility threshold in Optional
negotiation while initiating a out
call
Carry transmission delay x25 call-facility send-delay Optional
request while initiating a call milliseconds


Specify ROA (recognized x25 call-facility roa-list Optional
operating agency) name
2 Address-mapping-based configuration

Define ROA (Recognized x25 roa-list roa-name Optional
operating Agency) list roa-id&<1-10>
interface-number
Specify CUG (Closed User x25 map protocol-type Optional
Group) number protocol-address x121-address
x.121-address closed-user-group
number
Perform max packet x25 map protocol-type Optional
negotiation while initiating a protocol-address x121-address
Not configured by
call x.121-address packet-size
default
input-packet output-packet
Perform window size x25 map protocol-type Optional
Not configured by
call x.121-address window-size
default
input-window-size
output-window-size
Request reverse charging x25 map protocol-type Optional
when initiating a call protocol-address x121-address
Not configured by
x.121-address
default
reverse-charge-request
Receive calls with reverse x25 map protocol-type Optional
charging requests protocol-address x121-address
Not configured by
x.121-address
default
reverse-charge-accept
Request throughput-level x25 map protocol-type Optional
Not configured by
call x.121-address threshold in out
default
Carry transmission delay x25 map protocol-type Optional
request while initiating a call protocol-address x121-address
Not configured by
x.121-address send-delay
default
milliseconds
Specify ROA (Recognized x25 map protocol-type Optional
operating Agency) protocol-address x121-address
Not configured by
x.121-address roa-list name
default
For CUG configuration, refer to “Configuring X.25 Closed User Group” on page
303.
Configure the data queue length of VC

You can specify the sending and receiving queue lengths of VC for X.25 to adapt
to different network environments. The default queue length can contain 200
packets, but you can increase the number for the sake of preventing accidental
packet loss in case of large traffic size or low X.25 network transmission rate.
To configure the queue length of VC, use the following commands:


interface-number
Set the queue length of X.25 x25 queue-length Optional
VC queue-size
Defaults to 200
Broadcast via X.25

Generally, internetworking protocols will need to send some broadcast datagrams
for specific purposes. On the broadcasting physical networks (such as Ethernet),
such requirements are naturally supported. However, for non-broadcasting
networks like X.25, how to realize the broadcasting?
You can determine whether to copy and send a broadcast to a destination. This is
very important. For instance, you must enable X.25 to send broadcast datagrams
so that broadcast-based application layer routing protocols can interact route
information on an X.25 network.
You can enable a VC to send broadcasting datagrams, regardless whether it is an

SVC or PVC.
To broadcast via X.25, use the following commands:

Enter interface view interface interface-type interface-number -
Enable to send broadcasting x25 map protocol-type protocol-address Required
packets to the peer of the x121-address x.121-address broadcast
SVC associated with this
address mapping
Enable to send broadcasting x25 pvc pvc-number protocol-type
packets to the peer of this protocol-address x121-address
PVC x.121-address broadcast
Restrict the use of address mapping

Before a destination is called, this destination must be found in the address
mapping table. Before a call is received, the source of this call must also be found
in the address mapping table. However, in some cases, some address mappings
are used for calling out only, while others are used for calling in only.
To restrict the use of address mapping, use the following commands:

Disable initiating calls using x25 map protocol-type protocol-address Required
an address mapping x121-address x.121-address no-callout
Disable accepting calls using x25 map protocol-type protocol-address Required
an address map x121-address x.121-address no-callin

Configuring X.25 X.25 subinterface is a virtual interface that has its protocol address and VC. On a
Subinterface physical interface, you can create multiple subinterfaces to implement the
interconnections of multiple networks through a physical interface. All
subinterfaces under master interface share an X.121 address with the master
interface. X.25 subinterfaces fit into point-to-point subinterfaces and
point-to-multipoint subinterfaces. Point-point subinterface is used to connect a
single remote end, while point-to-multipoint subinterface is used to connect
multiple ones, which must be on the same network segment.
To configure an X.25 subinterface, use the following commands:

Enter interface view interface serial interface-number -
Enable X.25 protocol on the link-protocol x25 Required
interface
Create an X.25 subinterface interface serial Required
interface-number.subnumber [ p2mp
P2MP by default
| p2p ]
n When the link layer protocol of the interface is LAPB, HDLC, or PPP, no
subinterface can be created.
Configuring X.25 X.25 switching function

Switching A packet network consists of many interconnecting nodes based on a specific
topology. A packet is sent from source to destination via a large number of nodes,
of which each node needs to have packet switching capability.
Simply speaking, X.25 packet switching means that, after receiving a packet from
an X.25 port or Annex G DLCI, a switch will select a certain X.25 port or Annex G
DLCI to send the packet according to the related destination information
contained in the packet. Introducing X.25 switching enables the system to
implement packet switching function at packet layer. The device can act as a
packet switch.
Figure 62 Network diagram for X.25 switching
Host A Host B
To configure X.25 switching, use the following commands:



Enable X.25 switching x25 switching Required
Disabled by default
Add an X.25 Add a PVC interface interface-type Select either one
switching interface-number
route
x25 vc-range { bi-channel ltc htc
in-channel lic hic [ bi-channel ltc
htc ] [ out-channel loc hoc ] |
x25 switch pvc pvc-number1
interface-number [ dlci
dlci-number ] pvc pvc-number2
[ option ]
Add an SVC x25 switch svc [ -number ]
x.121-address [ sub-dest
destination-address | sub-source
source-address ] * interface
[ dlci dlci-number ]
Enabling/Disabling X.25 switching only affects call establishment, and not affects
the established links.
The switching routes can be configured after x.25 switching enabled. If you
disable the switching (using undo x25 switching command) after configuring
some switching routes, then
■ All static SVC routes will display invisible, while PVC routes display visible.
■ If you execute the x25 switching command again without restart, SVC routes
will be restored and visible upon using the display command.
■ At this time, if you execute the save command and restart, all SVC and PVC
routes will be lost.
n Since the default two-way channel range: LTC=1, HTC=1024 does not support
Configuring X.25 Load Overview of X.25 load sharing

Sharing Using the hunt group feature in X.25 protocol, network providers can provide the
load sharing function on X.25 packet switching network. X.25 load sharing can
implement the load sharing between different DTEs or between different links in
the same DTE, to ensure that link overload will not occur when a large number of
users access the same address.
X.25 load sharing is provided by DCE. To implement load sharing on X.25

network, you need to configure a set of DTE/DCE interfaces (synchronous serial
interface or XOT channel) as a hunt group on the remote DCE, and to assign an
X.121 address to this hunt group. When accessing the DTE in hunt group, other
devices in the network need to call the hunt group address. After receiving call
request packet, the remote DCE will select a line from hunt group and send
incoming call packet based on different channel selection policies (round-robin or

vc-number). Different calls will be distributed on various lines in hunt group to

implement load sharing.
Note that X.25 hunt group selects different transmission lines only during VC call
establishment. Once the whole VC completes the establishment and enters data
transfer phase, X.25 hunt group will not function any longer and data transfer will
be processed based on the normal VC. Since PVC is in data transfer phase after
establishment and experiences no call establishment and call clearing processes,
X.25 load sharing can function only on SVC, and not on PVC.
In an X.25 hunt group, the position of all DTEs is identical, and they have the same
X.121 address. DTEs inside hunt group can call other DTEs outside hunt group
according to the normal mode. When accessing hunt group, the devices outside
hunt group can not know which device they are accessing, and the line selection is
controlled by the DCE configured with hunt group.
The DTE address in hunt group can either be the same as the hunt group address,
or different from that. X.25 hunt group supports the substitution between the
source address and the destination address. You can use the destination address
substitution function to hide the DTE address inside hunt group, and the DTE
outside hunt group only knows the hunt group address, to strengthen the
network security inside hunt group. You can use the source address substitution
function to hide the DTE address outside hunt group, because the DTE inside hunt
group cannot know the source address of a call connection but the substituted
address, thus protecting users’ privacy.
Figure 63 X.25 network load sharing
HG 1
8888
Terminal A 9999
Server A
X.25 packet
switching
network
Router A
Terminal B
9999
Server B
Terminal C
As shown in the above figure, server A and server B, which be configured with a
hunt group HG 1, provide users with the same service. Server A and server B
addresses are 9999, and the hunt group address is 8888. Enabling the destination
address substitution function on Router A means that the address 8888 is replaced
by the address 9999. When a user transacts a service, the user terminal will send a
call to the destination address 8888. Such calls from any terminal are directed
towards the address 9999, which is transmitted to server A or server B via Router
A. The load sharing between server A and server B is implemented to lower the
pressure on a single server.

X.25 hunt group supports two call channel selection policies: round-robin mode
and vc-number mode. However, a hunt group only uses one policy.
■ The round-robin mode uses a cyclic selection method to select next interface or
XOT channel inside hunt group for each call. For example, in the above figure,
if the hunt group HG 1 uses the round-robin mode, the call will be sent in turn
to server A or server B.
■ The vc-number mode selects the interface with the maximum idle logic
channels inside hunt group for each call. For example, in the above figure, if
the hunt group HG 1 uses the vc-number mode, the remaining logic channels
of the lines between server A and DCE are 500, while those of the lines
between server B and DCE are 300. Thus, the first 200 calls will be sent to
server A, and the subsequent calls will be sent in turn to server A or server B.
X.25 hunt group supports synchronous serial interface and XOT channel, and can
select the available lines between them indistinctly. However, since XOT channel
cannot calculate the number of logic channels, it will not be added to the hunt
group that uses the vc-number selection policy.
X.25 network load sharing is configured on DCE device. In most cases, your device
is used as DTE device in X.25 network. The network providers provide the load
sharing function on packet switch. In this way, no special configuration is required
on the device. For the specific configuration procedure, refer to the previous
chapters. When it is used as DCE device in X.25 network, it provides load sharing
function for DTE device. At this time, X.25 load sharing needs to be configured on
it.
n You need not configure the hunt group address, and only need to set the
destination address as the hunt group address on the source DTE.
To configure X.25 load sharing, use the following commands:

Not enabled by default
Create an X.25 hunt group x25 hunt-group hunt-group-name Required
and enter its view { round-robin | vc-number }
Add an interface or Annex G channel interface interface-type Required
DLCI to the hunt group interface-number [ dlci
dlci-number ]
Add an XOT channel to the channel xot ip-address
hunt group
Exit to system view quit -

Create an X.25 switching x25 switch svc x.121-address Required
route to the hunt group [ sub-dest destination-address |
Not created by default.
sub-source source-address ] *
hunt-group hunt-group-name
Note that:

■ A hunt group can have 10 synchronous serial interfaces, Annex G DLCI or XOT
channels at most.
■ XOT channel cannot be added to the hunt group that uses vc-number channel
selection policy.
Configuring X.25 Closed Overview

User Group Closed user group (CUG) is a call restriction service provided by X.25 among all its
optional services. It governs call receiving and initiating capabilities of users (DTEs),
allowing users in the same CUG to call each other while forbidding users in
different CUGs to do so. This allows a private data communication subnet to form
over public X.25 data communications networks for an organization.
One user may belong to multiple CUGs. When the user calls another user in a
CUG, the CUG number is included in its capability negotiation message. The user
may also be set not to belong to any CUG, in which case the capability message
does not carry CUG information.
When used as data communication equipment (DCE), CUG function is shown in

the following figure.
Figure 64 CUG function implementation
Call 1
Bar outgoing
Release call
X.25 network
Call 2
Bar incoming
Release call
n Call 1: DTE originates a call, but outgoing capability is barred, so the call is
removed by DCE with CUG enabled.
Call 2: DCE receives a call request and requests a connection with DTE. CUG
function is enabled on DCE and the incoming capability is barred, so the call is
removed by DCE.
■ CUG function
You must enable CUG function first before configuring it, which by default is not
enabled.
After CUG function is enabled, all calls, including those with or without CUG
facilities are suppressed. You can also define some suppression policies for CUG to
process calls in different ways.
Two types of CUG suppression policies are available. One is to suppress all
incoming calls, where the system removes the CUG facilities of all incoming calls
with CUG facilities. The other is to suppress the incoming calls matching the
mapping specified as preference rule, where the system removes the CUG facilities

only of those incoming calls matching the mapping specified as preference rule,
but lets other incoming calls with CUG facilities pass through. The details are:
1 Incoming suppression policy, in which the system lets the incoming calls without
CUG facilities pass through, but suppresses the incoming calls with CUG facilities
but without access configuration configured by the CUG mapping rule.
2 Outgoing suppression policy, in which the system lets the outgoing calls without
CUG facilities pass through, but suppresses the outgoing calls with CUG facilities
but without access configuration configured by the CUG mapping rule.
3 All suppression policy, in which the systems removes CUG facilities (if any) and
make call processing for all incoming calls. This policy is ineffective to outgoing
calls.
4 Preference mapping suppressing policy, in which the system removes CUG facilities
and make call processing for the incoming calls with CUG facilities and with
preference mapping rule, but lets the incoming calls without preference mapping
rule pass through. This policy is ineffective to outgoing calls.
n You can only configure the CUG function on an X.25 interface working as DCE,
that is, you must specify the serial interface as DCE when specifying the X.25
protocol on it.
■ CUG mapping and suppression rule
CUG mapping refers to CUG number conversation from local end (DTE) to
network end (X.25) during CUG call processing. For example, when processing the
call from the DTE with CUG 10 to DTE with CUG 20, the system first searches the
mapping table for this mapping entry: if the table has this entry, it forwards the
packets, if not, it denies the forwarding.
You can define suppression rules in configuring CUG mapping, including three
types:
■ Outgoing call restriction

■ Incoming call restriction
■ Specifying as preference rule
Specifying as preference rule depends on CUG suppression policy. That is, if the
suppression policy is configured as only suppressing the CUG of preference
mapping, then the system removes the CUG facilities in the incoming call packet
of this mapping and makes call processing.
n You must configure CUG function on X.25 DCE interface, that is, you must specify
it as DCE end in encapsulating X.25 protocol on serial interface.
To configure CUG, use the following commands:

interface-number

X.25 PAD Remote Access Service 305

Enable CUG function and x25 cug-service Required
configure suppression policy [ incoming-access |
Disabled by default
outgoing-access | suppress { all |
preferential } ] *
Configure a local CUG to x25 local-cug local-cug-number Required
network CUG mapping and network-cug
Not configured by
define suppression rule network-cug-number
default
[ no-incoming | no-outgoing |
preferential ]*
n The x25 cug-service and x25 local-cug commands are supported only on the
X.25 DCE interface, that is, you need to specify the interface as DCE when
encapsulating X.25 protocol on the serial interface.
X.25 PAD Remote

Access Service
Introduction to X.25 PAD Packet assembly/disassembly (PAD) is an X.25 specific concept.
Traditionally, only X.25 terminals could connect to an X.25 network. These

terminals must be packet terminals that support X.25 procedures in terms of
hardware and software. However, many terminals in common use are non-X.25
terminals. They either have no intelligence available with packet terminals or have
intelligence but do not support X.25 procedures. Examples of such terminals are
keyboards, monitors, and printers. To allow these devices to communicate on X.25
networks, X.25 PAD was developed.
X.25 PAD provides a mechanism to connect non-X.25 terminals to an X.25

network. As shown in the figure below, a PAD facility is placed between non-X.25
terminals and an X.25 network, allowing them to communicate with other
terminals across the X.25 network.
Figure 65 Interfacing function of PAD
Non-X.25
terminal
Non-X.25
X.25 procedure procedure
X.25 network
X.25 PAD functions to provide:
■ X.25 procedures support for connectivity and communication with X.25

networks
■ Non-X.25 procedures support for connectivity with non-X.25 terminals.
■ Capabilities allowing non-X.25 terminals to set up calls, transmit data, and
clear calls.
■ Capabilities allowing non-X.25 terminals to observe and modify interface
parameters to accommodate to different terminals.

X.25 PAD facilities are thus regarded procedures translators or network servers,
helping different terminals access X.25 networks.
The system implements X.29 and X.3 protocols in the X.25 PAD protocol suite. In
addition, it implements X.29-based Telnet. This allows you to telnet to a remote
router through X.25 PAD when IP-based Telnet is not preferred for security sake, as
shown in the figure below.
Figure 66 Log onto a remote router through X.25 PAD
S 2/0 S2/0
X.25 network
Router A Router B
Configuring X.25 PAD Place an X.25 PAD call to log onto a remote device
If two routers on an X.25 network support X.25 PAD, you can use the pad
command to place an X.25 PAD call on one router (the client) to log onto the
other router (the server). If authentication is configured, the server will
authenticate the client before allowing it to log in.
After logging onto the server, you can access the configuration interface on the
server.
You can nest a pad command within another pad command or a telnet
command. By nesting commands, you can do the following on your router:
■ Place an X.25 PAD call to log onto another router; and from that router, place
another X.25 PAD call to log onto a third router, and so on.
■ Telnet to another router; and from that router, place an X.25 call to log onto a
third router, and so on.
■ Place an X.25 PAD call to log onto another router; and from that router, telnet
to a third router, and so on.
To ensure transmission, limit nesting operations within three.
Logout operations are done in the reverse direction. You can execute the quit
command multiple times to log out the currently logged-in router and all the
in-between routers one by one.
Set the delay waiting for the response to an Invite Clear message
The server end of X.25 PAD may send an Invite Clear message to the client, for
example, after receiving an exit request from client or in order to release the link.
At the same time, a timer is started. If no response is received upon expiration of
the timer, the server will clear the link.
To configure X.25 PAD, use the following commands:



Set the delay waiting for the x29 timer inviteclear-time Optional
response to an Invite Clear seconds
Defaults to 5 seconds
message
Exit to user view quit -
Place an X.25 PAD call to the pad x.121-address Required
specified X.121 address
Troubleshooting X.25 Symptom: Failed to log onto a remote device after placing an X.25 PAD call to the
PAD remote device. The system prompted the destination address was unreachable.
Solution:
Check that:
■ The two ends of the X.25 PAD call are connected through an X.25 network and
the physical connection is normal. The serial interfaces used for connection are
encapsulated with X.25 and both of them support X.25 PAD. One end is DCE,
the other is DTE, both using the same encapsulation type (ietf or nonstandard).
■ The destination X.121 address is correct. It must be the one assigned to the
intended serial interface at server end.
■ Check that X.25 switching is disabled, or a route is available to the server end
when X.25 switching is enabled. In the former case, the default route is used to
route the call. In the second case, at least one route must be configured for
routing the call.
Configuring X.25 over

TCP (XOT)
Introduction to XOT X.25 over TCP (XOT) carries X.25 packets over TCP to interconnect two X.25
Protocol networks across an IP network. The following figure presents an XOT application
environment.
Figure 67 Typical XOT application
IP network
Router B Router C
X.25 network X.25 network
Router A Router D

At present, since IP network is used widely, it is necessary, in practice, to carry X.25

data and implement the interconnection between X.25 networks via IP network.
The traditional X.25 protocol belongs to layer 3 (network layer) of OSI 7-layer
model, and it can obtain the reliable data transmission link via LAPB protocol.
Since TCP has such mechanisms as error retransmission and window flow control
to ensure the reliability of the link, it can be used by X.25 protocol. XOT
establishes a TCP tunnel connection between X.25 networks at both ends, and
X.25 packet, as the data of application layer, is carried over TCP, i.e. TCP serves as
the “link layer” protocol of X.25. Router B, Router C and IP network in the middle
can be looked upon as a big “X.25 switch”, and the data sent by Router A is
directly switched to Router D via this “switch”.
XOT characteristics conform to the RFC1613 standard, which features as follows:
■ Supporting SVC application. The routers at both ends can dynamically establish
an SVC by sending call packet, and this SVC will be automatically cleared when
no data is transmitted.
■ Supporting PVC application. After being configured with a PVC, the routers at
both ends directly enter the data transmission status without establishing a call.
Moreover, this PVC will not be dynamically deleted when no data is
transmitted.
■ Supporting Keepalive attribute of TCP. If Keepalive is not configured, TCP
connection will still not be cleared or cleared after a long time even if the
connection is interrupted. However, after Keepalive is configured, TCP will
timely detect the availability of the link. If TCP does not receive the response
from the peer for many times, it will initiatively clear its connection.
XOT implementation principle (taking SVC as an example):
As shown in the above figure, when transmitting data, Router A first sends a call
request packet to establish VC. After receiving this call packet and judging it as
XOT application, Router B will establish a TCP connection with Router C, then add
XOT header to X.25 call packet and encapsulate it into TCP, finally transmit it to
Router C. After deleting TCP and XOT header, Router C transfers the call request
packet to Router D via X.25 local switching. After receiving it, Router D will give
out call acknowledgement until the link is completely established to transmit data.
The whole process for establishment and application of TCP connection is
transparent for Router A and Router D that do not care whether data is forwarded
via IP network or X.25 network.
Configuration Procedure Configure XOT

To configure XOT, use the following commands:

interface-number


Specify an IP address for the IP ip address ip-address { mask Required
side interface | mask-length }
Make sure the IP network
or operates normally
ip address unnumbered
interface-number
Configure an Configure an x25 switch svc [ -number ] Required
XOT route to SVC XOT route x.121-address [ sub-dest
route packet destination-address |
from X.25 via sub-source source-address ]
IP network * xot ip-address&<1-6>
[ xot-option ]
x25 switch svc [ -number ] Select either one
destination-address |
sub-source source-address ]
* interface interface-type
interface-number
Configure a interface interface-type
PVC XOT route interface-number
in interface
x25 vc-range { bi-channel
view
ltc htc [ out-channel loc
hoc ] | in-channel lic hic
x25 xot pvc pvc-number1
ip-address interface
interface-type
interface-number pvc
pvc-number2 [ xot-option |
packet-size input-packet
output-packet |
window-size
input-window-size
output-window-size ] *
Configure XOT optional Refer to “Configure XOT Optional
attribute optional attributes” on page
309
n ■
■
In SVC mode, X.25 routes are required.
Since the default two-way channel range: LTC=1, HTC=1024 does not support
■ For IP address configuration, refer to “IP Addressing Configuration” on page
623.
Configure XOT optional attributes

After TCP link is established, TCP will also not be cleared easily even if the link is
interrupted. However, after the Keepalive attribute is configured, the router will
periodically send the detection packet to check the availability of the link. If it has
not received the acknowledgement after sending packets for many times, the
router will deem the link fault and will initiatively clear TCP connection.

To configure XOT optional attributes, use the following commands:

Configure the SVC x25 switch svc x.121-address [ sub-dest Optional
Keepalive and source destination-address | sub-source source-address ]
attributes xot ip-address&<1-6> [ xot-option ]
Configure the PVC interface interface-type interface-number -
Keepalive and source
x25 xot pvc pvc-number1 ip-address interface Optional
attributes
interface-type interface-number pvc
pvc-number2 [ xot-option | packet-size
input-packet output-packet | window-size
input-window-size output-window-size ]*
Table 7 Options of the xot-option field
Option Indicates
timer seconds Keepalive timer for the XOT connection, in the range 1 to 3600
seconds. Upon its timeout the router begins to send keepalive
packets to test availability of the connection
retry times The maximum number of Keepalive packet sending attempts, in
the range 3 to 3600. When the number of keepalive packet
sending attempts exceeds the limit, the XOT connection is
disconnected
source interface-type Interface where the XOT connection is initiated
interface-number
Configuring X.25 over

FR
Introduction to X.25 X.25 over FR carries X.25 packets over FR to interconnect two X.25 networks
over FR across an FR network, as shown in the following figure.
Figure 68 X.25 Over FR network diagram
FR network
Router B Router C
X.25 network X.25 network
Router A Router D

Configuring X.25 over FR 311
Configuring SVC X.25 over FR is an extension to X.25 switching, so you need enable X.25 switch
Application of X.25 over first.
FR
To configure SVC application of X.25 over FR, use the following commands:

interface-number
Specify the link layer protocol link-protocol fr Required
as FR [ nonstandard | ietf ]
PPP by default
Specify the FR interface type fr interface-type { dce | dte | Required
nni }
DTE by default
Configure an FR DLCI and fr dlci dlci-number Required
enter its view
Configure the FR DLCI as annexg { dce | dte } Required
Annex G DLCI
Configure the SVC route x25 switch svc [ -number ] Required
After receiving a packet on
the SVC, the packet is
forwarded via a local
interface. Use this command
interface-number
to configure the local forward
interface.
Configure the X.25 over FR x25 switch svc [ -number ] Required
SVC route x.121-address [ sub-dest
interface-number dlci
dlci-number
Configuring PVC X.25 over FR is an extension to X.25 switching, so you need enable X.25 switch
Application of X.25 over first.
FR
To configure SVC application of X.25 over FR, use the following commands:

Create an X.25 template x25 template { name } Required
Specify the VC range x25 vc-range { bi-channel Required
ltc htc [ out-channel loc hoc ]
| in-channel lic hic


Configure a PVC route under x25 switch pvc pvc-number1 Required
the X.25 template interface interface-type
dlci-number ] pvc
pvc-number2 [ option ]
interface-number
Configure the link layer link-protocol fr Required
protocol as FR [ nonstandard | ietf ]
PPP by default
Configure the FR interface fr interface-type { dce | dte | Required
type nni }
DTE by default
Configure an FR DLCI and fr dlci dlci-number Required
enter its view
Configure the FR DLCI as annexg { dce | dte } Required
Annex G DLCI
Apply the X.25 Template to x25-template name Required
the Annex G DLCI
interface-number
Configure the link layer link-protocol x25 [ dce Required
protocol as X.25 |dte ] [ ietf | nonstandard ]
PPP by default
Configure a PVC route x25 switch pvc pvc-number1 Required
dlci-number ] pvc
pvc-number2 [ option ]
Configuring X2T
Introduction X.25 to TCP switch (X2T) connects X.25 to TCP/IP networks, allowing the access
between X.25 and IP hosts.
Figure 69 Network diagram for X2T
X.25 terminal Router IP host
TCP
TCP
X2T
X.25 X.25 IP IP
LAPB LAPB Data Link Layer Data Link Layer
Physical Layer Physical Layer
The X.25 terminal has an X.121 address to the IP host. Whenever the router
receives an X.25 call request packet, it checks the destination address of X.121 in
the packet and looks up in the X2T routing table for a match. If there is a
matching route, the router will set up a TCP connection with the host at the

Configuring X2T 313
destination IP address of the X2T route. After that, the router will extract the pure
data from the X.25 packet and send them to the IP host through the TCP
connection.
The IP host can go through the IP address on the interface of the IP network to
access the X.25 host. Whenever the router receives a TCP connection request, it
checks the destination IP address and TCP port number of the TCP connection and
looks up in the X2T routing table for a match. If there is a match, the router will
set up an X.25 SVC destined to the host at the associated destination X.121
address of the X2T route. After that, the router will extract the pure data from the
TCP packet and send them to the X.25 host through the X.25 SVC. If the router
sets up a PVC connection with X.25 host, it transmits the data directly to X.25
host through X.25 PVC.
Configuration Procedure To configure X2T, use the following commands:

Configure X.25 interface Refer to “Configuring X.25 Required
Unnecessary to specify an
page 286.
X.121 address for the
interface
Configure IP interface Refer to IP Services volume. Required
Configure an X.25-to-IP X2T translate x25 x.121-address Required
forwarding route ip ip-address port
port-number
Configure an Configure a PVC translate ip ip-address port Select either one.
IP-to-X.25 forwarding port-number pvc
X2T route for PVC interface-type
forwarding link interface-number
route pvc-number
Configure an translate ip ip-address port
SVC route and a port-number x25
forwarding x.121-address
route for SVC
x25 switch svc [ -number ]
link
destination-address ]
[ sub-source
source-address ] * interface
interface-type
dlci-number ]
c CAUTION:
■ Number of X2T mapping entries varies by device. The maximum number of
entries is 100 by default, including both entries configured using the translate
ip and translate x25 commands.
■ When specifying a port number using the translate ip command, for an IP
address using one port, specify port 102, for an IP address using multiple ports,
specify port numbers from 1024 to 5000 instead of well known port numbers
such as 21, 23 to avoid network failures.

Displaying and
Maintaining LAPB and To do... Use the command... Remarks
X.25 Display interface information display interface [interface-type Available in any
interface-number ] view
Display X.25 alias table display x25 alias-policy [ interface
Display X.25 address mapping display x25 map
table
Display CUG configuration display x25 cug { local-cug
[ local-cug-number ] | network-cug
[ network-cug-number ] }
Display X.25 PAD (Packet display x25 pad [ pad-id ]
Assembler/Disassembler)
connection information
Display X.25 switching table display x25 switch-table svc
{ dynamic | static }
Display X.25 PVC switching display x25 switch-table pvc
table
Display X.25 virtual circuit display x25 vc [ lci-number ]
Display X.25 XOT VCs display x25 xot
Display X2T dynamic display x25 x2t switch-table
switching table
Display X.25 hunt group display x25 hunt-group-info Available in any
information [ hunt-group-name ] view
Clear X.25 interface statistics reset x25 { counters interface Available in user
or VC interface-type interface-number | vc view
interface-number [ vc-number ] }
Clear (reset) an XOT link reset xot local local-ip-address
local-port remote remote-ip-address
remote-port
Clear the LAPB statistic reset lapb statistics
information
LAPB Configuration Network requirements

Example Two routers are directly connected back to back via serial interfaces encapsulated
with LAPB that can transmit IP datagrams directly.
Network diagram
Figure 70 Direct connection of two routers via serial interfaces (LAPB)
S 2/0 S2 /0
10 .1 .1.2/8 10.1.1.1 /8
Router A Router B
# Enter interface view.

LAPB Configuration Example 315
# Assign an IP address for the interface.
# Configure the link layer protocol of the interface as LAPB, and specify it to work
in DTE mode.
[RouterA -Serial2/0] link-protocol lapb dte
# Configure other LAPB parameters (If the link is sound enough and a higher rate
is desired, you can increase the traffic control parameters modulo to 128, k to
127, but the connected parties must always keep the configured parameters in
consistency.
[RouterA-Serial2/0] lapb modulo 128

[RouterA-Serial2/0] lapb window-size 127
[RouterA-Serial2/0] shutdown
[RouterA-Serial2/0] undo shutdown
# Configure the link layer protocol of the interface as LAPB, and specify it to work
in DCE mode.
[RouterB-Serial2/0] link-protocol lapb dce
# Configure other LAPB parameters (If the link is sound enough and a higher rate
is desired, you can increase the traffic control parameters modulo to 128, k to
127, but the connected parties must always keep the configured parameters in
consistency.
[RouterB-Serial2/0] lapb modulo 128

[RouterB-Serial2/0] lapb window-size 127
[RouterB-Serial2/0] shutdown
[RouterB-Serial2/0] undo shutdown
Note that the IP addresses of the two connected interfaces must be in the same
network segment. If they are not on the same network segment, you need to
configure a static route in between and make sure the traffic control parameters
of both sides are the same.

X.25 Configuration
Examples
Direct Connection of Network requirements

Two Routers via Serial As shown in the following figure, two routers are directly connected; IP packets
Interfaces (One can be transmitted between serial interfaces over X.25 link layer protocol. Only
Mapping) one IP to X.121 mapping is available on Router A.
Network diagram
Figure 71 Direct connection of two routers through serial interfaces (X.25)
S 2/0 S 2/0
202 .38.60 .1 /24 202 .38 .60 .2 /24
X 121 address: 20112451 X121 address: 20112452
Router A Router B
1 Configure RouterA:
# Enter interface view
# Configure the link layer protocol of the interface as X.25, and configure the
interface to operate in DTE mode.
[RouterA-Serial2/0] link-protocol x25 dte
# Assign an X.121 address to the interface.
[RouterA-Serial2/0] x25 x121-address 20112451
# Configure address mapping to the peer.
[RouterA-Serial2/0] x25 map ip 202.38.60.2 x121-address 20112452
# Configure the maximum packet size allowed and the window size.
[RouterA-Serial2/0] x25 packet-size 1024 1024

[RouterA-Serial2/0] x25 window-size 5 5

# Configure the link layer protocol of the interface as X.25, and specify it to
operate in DCE mode.
[RouterB-Serial2/0] link-protocol x25 dce
#Assign an X.121 address for the interface.
[RouterB-Serial2/0] x25 x121-address 20112452
[RouterB-Serial2/0] x25 map ip 202.38.60.1 x121-address 20112451
[RouterB-Serial2/0] x25 packet-size 1024 1024

[RouterB-Serial2/0] x25 window-size 5 5
Note that, since IP to X.121 mapping is available, IP addresses of both ends can be
on different network segments and no static route is needed.
Direct Connection of Network requirements

Two routers through As shown in the following figure, two routers are connected directly; IP packets
Serial Interfaces (Two can be transmitted between serial interfaces over X.25 link layer protocol. Two IP
Mappings) to X.121 mappings are available on Router A.
Network diagram
Figure 72 Direct connection of two routers via serial interfaces (X.25)
S 2/0 S2/0
202 .38.160 .1/24 202 .38.160.2/24
X 121 address: 20112451 X121 address: 20112452
Router A Router B
1 Configure RouterA
# Configure the link layer protocol as X.25 and the interface to operate in DTE
mode.

# Assign an X.121 address for the interface.
# Configure address mappings to the peer.


#Configure the link layer protocol of the interface as X.25 and specify the
interface to operate in DCE mode.

# Since the peer (Router A) has two IP addresses corresponding to the X.121
address at the local end (Router B) and the local IP address is not in the first
mapping, two VCs will be created when connection being established, so you
need to specify the maximum number of VCs in the mapping as 2.
[RouterB-Serial2/0] x25 vc-per-map 2

Connecting the Router Network requirements

to X.25 Public Packet As shown in the following figure, Routers A, B, and C are connected to the same
Network X.25 network. The requirements are:
■ The IP addresses of the interfaces Serial 2/0 of the three routers are
168.173.24.1/24, 168.173.24.2/24 and 168.173.24.3/24.
■ The X.121 addresses assigned to the three routers are 30561001, 30561002,
and 30561003.
■ The standard window size supported by the packet network: both receiving
window and sending window are 5.
■ The standard maximum packet size: both the maximum receiving packet size
and the maximum sending packet size are 512.
■ Channel range: permanent virtual circuit range, incoming-only channel range
and outgoing-only channel range are disabled, and two-way channel range is
[1, 32].
Network diagram
Figure 73 Connecting the router to X.25 public packet network
S 2/0
168 .173 .24 .2 /24
X121 address: 30561002
Router B
X.25 network
S2 /0
168 .173 .24.1 /24 S2/0
Router A X121 address: 30561001 168.173.24.3/24
X121 address: 30561003
Router C
[RouterA] interface Serial 2/0
# Access the public packet network, and configure the router to operate in DTE
mode.

[RouterA-Serial2/0] x25 vc-range bi-channel 1 32

[RouterB] interface Serial 2/0
# Access public packet network, and configure the router to operate in DTE mode.
[RouterB-Serial2/0] link-protocol x25 dte

[RouterB-Serial2/0] x25 vc-range bi-channel 1 32
[RouterC] interface Serial 2/0
# Access public packet network, configure the router to operate in DTE mode.
[RouterC-Serial2/0] link-protocol x25 dte

[RouterC-Serial2/0] x25 x121-address 30561003
[RouterC-Serial2/0] x25 window-size 5 5
[RouterC-Serial2/0] x25 packet-size 512 512
[RouterC-Serial2/0] x25 vc-range bi-channel 1 32
[RouterC-Serial2/0] x25 map ip 168.173.24.1 x121-address 30561001
Configuring VC Range Network requirements

The link layer protocol of the router interface Serial 2/0 is X.25, and VC ranges as
follows: PVC range [1, 8], incoming-only channel range [9, 16], two-way channel
range [17, 1024], and outgoing-only channel range is disabled.
[Router-Serial2/0] link-protocol x25
[Router-Serial2/0] x25 vc-range in-channel 9 16 bi-channel 17 1024
[Router-Serial2/0] shutdown
[Router-Serial2/0] undo shutdown
Transmitting IP Network requirements

Datagrams through X.25 ■ In the following diagram, the PVC range that the packet network allows is [1,
PVCs 8]. The PVC numbers assigned to Router A and Router B are 3 and 4.
■ The IP addresses of LAN 1 and LAN 2 are 202.38.165.0/24 and
196.25.231.0/24.

■ It is required to exchange route information between LAN 1 and LAN 2 using

RIP, so that Host A and Host B can exchange information without any static
route.
Network diagram
Figure 74 Carry IP datagrams over X.25 PVC
X.25 network
PVC 3 PVC 4
S2/0 S2/0
192.149.13.1/24 192.149 .13 .2/24
X121 address: 1004358901 X121 address: 1004358902
Router A Router B
Eth1 /0 Eth1/0
202 .38 .165 .1/24 196 .25.231 .1/24
LAN 1 LAN 2
Host A Host B
# Configure interface Ethernet 1/0.
[RouterA-Ethernet1/0] ip address 202.38.165.1 255.255.255.0
# Configure interface Serial 2/0.

[RouterA-Serial2/0] link-protocol x25
[RouterA-Serial2/0] x25 pvc 3 ip 192.149.13.2 x121-address 100435890
2 broadcast packet-size 512 512 window-size 5 5
# Enable RIP.
[RouterA] rip
[RouterA-rip-1] network 192.0.0.0


[RouterB-Serial2/0] link-protocol x25
[RouterB-Serial2/0] x25 pvc 4 ip 192.149.13.1 x121-address 100435890
1 broadcast packet-size 512 512 window-size 5 5
# Enable RIP.
[RouterB] rip
As you go through the above configuration procedure, you may be probably

puzzled due to different PVC numbers (that is, 3 and 4 in this scenario) on Router
A and Router B. You should distinguish between “VC” and “logic-channel”.
Virtual circuit refers to the end-to-end logic link between the calling DTE and the
called DTE, while logic channel refers to the logic link between two directly
connected devices (either between DTE and DCE, or between the ports of two
packet switching exchanges). A virtual circuit consists of several logic channels,
and each logic channel has a separate number. Hence, a VC between Router A
and Router B can be the one shown in the following figure (suppose this VC
passes four packet switches in the network).
Figure 75 One VC consisting of several logic-channels
X.25 network
LC 24
LC 243 LC 3
LC 3 LC 4
Router A Router B
Therefore, the PVC 3 and PVC 4 mentioned in the example actually refer to the
numbers of the logic-channels between the routers and the PBXs directly
connected. The two sides of the PVC can identify the same PVC by using their
logic-channel numbers, however, without the likelihood of causing any mistake.
This is why no strict distinction is made between “virtual circuit” and “logic
channel”.

X.25 Subinterface Network requirements

Configuration Example In the following figure, Router A is configured with two subinterfaces, which are
connected with Router B and Router C. Router D operates as an X.25 switch. It is
desired that Router A can communicate with Router B and Router C respectively.
Network diagram
Figure 76 X.25 subinterface configuration
S2/0
Router A Router D 20.1.1.1/16 Router C
X 121 address:300
S 2/0.1 S 2/0 S2/2
10 .1.1.2/16 S 2/1
S 2/0.2
20 .1.1.2/16
X 121 address:100
S 2/0
10 .1 .1.1/16
X 121 address:200
Router B
# Configure subinterface Serial 2/0.1, and X.25 mapping to Router B.
[RouterA-Serial2/0] interface serial 2/0.1

[RouterA-Serial2/0.1] x25 map ip 10.1.1.1 x121-address 200
# Configure subinterface serial 2/0.2, and X.25 mapping to Router C.
[RouterA-Serial2/0.1] interface serial 2/0.2

[RouterA-Serial2/0.2] x25 map ip 20.1.1.1 x121-address 300

4 Configure Router D as an X.25 switch

[RouterD] interface serial 2/0
[RouterD-Serial2/0] link-protocol x25 dce
[RouterD-Serial2/0] quit
# Configure SVC switching routes,
[RouterD] x25 switching

[RouterD] x25 switch svc 100 interface serial 2/0
SVC Application of XOT Network requirements

Router B and Router C are connected through Ethernet interfaces. Set up a TCP
connection between them to deliver data between Serial 2/0 of Router A and
Serial 2/0 of Router D. Configure SVCs and XOT.
Network diagram
Figure 77 Network diagram for XOT SVC
Router B Router C
XOT
Eth1 /0 Eth1/0
S2/0 10 .1 .1.1/8 10.1.1 .2/8 S2 /0
S2/0 S2/0
1.1 .1.1/8 1 .1.1.2/8
X121 address:1 X 121 address:2
Router A Router D
# Configure basic X.25.
[RouterA-Serial2/0] link-protocol x25 dte ietf

[RouterD-Serial2/0] link-protocol x25 dte ietf
[RouterD-Serial2/0] x25 x121-address 2
[RouterD-Serial2/0] x25 map ip 1.1.1.1 x121-address 1
[RouterD-Serial2/0] ip address 1.1.1.2 255.0.0.0
# Enable X.25 switching.
[RouterB] x25 switching
# Configure local X.25 switching, specifying packets to X.121 address 1 to pass

through Serial 2/0.
[RouterB] x25 switch svc 1 interface serial 2/0
# Configure XOT switching, specifying an X.25 switching route to XOT channel.
[RouterB] x25 switch svc 2 xot 10.1.1.2
# Configure Serial 2/0.

[RouterB-Serial2/0] link-protocol x25 dce ietf

[RouterC] x25 switching
# Configure local X.25 switching, specifying packets to X.121 address 2 to pass

through Serial 2/0.
[RouterC] x25 switch svc 2 interface serial 2/0
# Configure XOT switching, specifying an X.25 switching route to XOT channel.
[RouterC] x25 switch svc 1 xot 10.1.1.1

[RouterC-Serial2/0] link-protocol x25 dce ietf

[RouterC] interface ethernet 1/0

[RouterC-Ethernet1/0] ip address 10.1.1.2 255.0.0.0
PVC Application of XOT Network requirements

Router B and Router C are connected through Ethernet interfaces. Set up a TCP
connection between them to deliver data between Serial 2/0 of Router A and
Serial 2/0 of Router D. Configure PVCs and XOT.
Network diagram
Figure 78 Network diagram for XOT PVC application
Router B XOT Router C
Eth1/0 Eth1/0
S2/0 10.1.1 .1/8 10.1.1.2/8 S2 /0
PVC 1 PVC 2
S2/0 S2/0
1.1.1.1/8 1.1 .1.2/8
X121 address :1111 X121 address :2222
Router A Router D
[RouterA-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterD-Serial2/0] link-protocol x25 dte ietf
[RouterD-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterD-Serial2/0] x25 pvc 2 ip 1.1.1.1 x121-address 1111
# Enable x.25 switching.
# Configure Serial 2/0 and XOT route.


[RouterB-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterB-Serial2/0] x25 xot pvc 1 10.1.1.2 interface serial 2/0 pvc 2
# Configure Ethernet 1/0.

# Configure Serial 2/0 and XOT route.

[RouterC-Serial2/0] link-protocol x25 dce ietf
[RouterC-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024
[RouterC-Serial2/0] x25 xot pvc 2 10.1.1.1 interface serial 2/0 pvc 1

SVC Application of X.25 Network requirements

over FR In the following figure, Router A is connected to Router B, Router C to Router D
through X.25. Router B is connected to Router C through FR. Configure FR Annex
G DLCI 100 on the two routers to interconnect the two X.25 networks, enabling
Host A and Host B to communicate with each other.
Network diagram
Figure 79 Network diagram for X.25 over FR SVC configuration
Router A Router B Router C Router D

S2/0 S2 /1 S2/0
S2/0 S2/1 S2/0

Eth1/0 1.1.1.1/24 1.1 .1.2/24
Eth1/0
X121 address :1 X121 address:2
Host A Host B
# Configure X.25 basic functions.


[RouterD-Serial2/0] link-protocol x25 dte
[RouterD-Serial2/0] x25 map ip 1.1.1.1 x121-address 1
# Configure Serial 2/0 as X.25 interface.

# Configure Serial 2/1 as FR interface.

# Configure the FR Annex G DLCI.

[RouterB-fr-dlci-Serial2/1-100] annexg dce
# Configure X.25 local switching.
# Configure X.25 over FR switching.
[RouterB] x25 switch svc 2 interface serial 2/1 dlci 100

# Configure Serial 2/0 as X.25 interface.

[RouterC-Serial2/0] link-protocol x25 dce

# Configure Serial 2/1 as FR interface.

[RouterC-Serial2/1] fr dlci 100

[RouterC-fr-dlci-Serial2/1-100] annexg dte
# Configure X.25 local switching.
[RouterC] x25 switch svc 2 interface serial 2/0
# Configure X.25 over FR switching.
[RouterC] x25 switch svc 1 interface serial 2/1 dlci 100
PVC Application of X.25 Network requirements

over FR In the following figure, Router A is connected to Router B, Router C to Router D
through X.25. Router B is connected to Router C through FR. Configure FR Annex
G DLCI 100 on the two routers to interconnect the two X.25 networks, enabling
Host A and Host B to communicate with each other.
Network diagram
Figure 80 Network diagram for X.25 over FR SVC configuration
Router A Router B Router C Router D

S2 /0 S2/1 S 2/0
S 2/0 S 2/1 S 2/0

Eth1/0 1 .1.1.1/24 1.1.1.2 /24
Eth1 /0
X 121 address:1 X121 address:2
Host A Host B

[RouterD-Serial2/0] link-protocol x25 dte
[RouterD-Serial2/0] x25 vc-range bi-channel 10 20
[RouterD-Serial2/0] x25 pvc 1 ip 1.1.1.1 x121-address 1
# Configure the PVC switching route on X.25 interface Serial 2/0.

[RouterB-Serial2/0] x25 switch pvc 1 interface serial 2/1 dlci 100 pvc 1
# Configure an X.25 template.
[RouterB] x25 template switch

[RouterB-x25-switch] x25 vc-range bi-channel 10 20
# Configure the PVC switching route for the template.
[RouterB-x25-switch] x25 switch pvc 1 interface serial 2/0 pvc 1
# Configure FR interface Serial 2/1.


[RouterB-fr-dlci-Serial2/1-100] annexg dce
# Apply the X.25 template to the FR Annex G DLCI.
[RouterB-fr-dlci-Serial2/1-100] x25-template switch

# Configure the PVC switching route on the X.25 interface Serial 2/0.

[RouterC-Serial2/0] link-protocol x25 dce
[RouterC-Serial2/0] x25 vc-range bi-channel 10 20
[RouterC-Serial2/0] x25 switch pvc 1 interface serial 2/1 dlci 100 pvc 1

# Configure an X.25 template.
[RouterC] x25 template switch

[RouterC-x25-switch] x25 vc-range bi-channel 10 20
# Configure the PVC switching route for the template.
[RouterC-x25-switch] x25 switch pvc 1 interface serial 2/0 pvc 1
# Configure FR interface Serial 2/1.


# Apply the X.25 template to the FR Annex G DLCI.
[RouterC-fr-dlci-Serial2/1-100] x25-template switch
X.25 Load Sharing Network requirements

Application ■ You need to configure hunt group on Router A used as X.25 switch, and
enable destination address and source address substitution function, so that
the calls from X.25 terminal can be sent to Router B, Router C and Router E via
the load sharing function. As X.25 switch.
■ Router D that connects with Router A and Router E is used to implement XOT
function.
■ As DTEs in hunt group, Router B, Router C and Router E provide the same
service for X.25 terminal.
■ Router B and Router A use X.25, Router C and A use FR. Apply Annex G on
DLCI to make the two routers communicate to each other.

Network diagram
Figure 81 Network diagram for typical X.25 hunt group configuration
Hg 1
X121 address:2222
Router B
S2/0
X.25 terminal X121 address:8888
X121 address:1111
S2/3 S2 /2
S 2/0
S2/4 S2/1 X121 address:8888
S2/0 Eth1/0
10.1.1.1/24 Router C
X.25 terminal
Router A
X121 address:1112
Router D S2/0
Eth1/0 X121 address:8888
10.1.1.2/24
S2/0
Router E
X.25 terminal
X121 address:1113
# Configure the link layer protocol of the interface Serial 2/0 as X.25, and
configure it to operate in DCE mode.
[RouterA-Serial2/0] link-protocol x25 dce
# In the same way as listed above, configure the link layer protocol of the interface
Serial 2/2, Serial 2/3, and Serial 2/4 as X.25 and configure them to operate in DCE
mode.
# Configure Serial 2/1 as an FR DCE.

# Configure an FR Annex G DLCI.

[RouterA-fr-dlci-Serial2/1-100] annexg dce


[RouterA] x25 switching
# Create X.25 hunt group hg1.
[RouterA] x25 hunt-group hg1 round-robin
# Add interfaces Serial 2/2, Serial 2/1, and XOT channel to the hunt group.
[RouterA-hg-hg1] channel interface serial 2/2

[RouterA-hg-hg1] channel interface serial 2/1 dlci 100
[RouterA-hg-hg1] channel xot 10.1.1.2
[RouterA-hg-hg1] quit
# Configure X.25 switching route forwarded towards the hunt group hg1, and
enable destination address and source address substitution, substituting 3333 and
8888 for source and destination addresses of packets destined to hunt group
address 2222.
[RouterA] x25 switch svc 2222 sub-dest 8888 sub-source 3333 hunt-group hg1
# Configure X.25 switching route forwarded to X.25 terminal.
[RouterA] x25 switch svc 1111 interface serial 2/3

# Configure the link layer protocol of interface Serial 2/0 as X.25, and configure it
to operate in DTE mode.
[RouterC] x25 template vofr
[RouterC-x25-vofr] x25 x121-address 8888
[RouterC-x25-vofr] quit
# Enable FR on Serial 2/0.

# Configure FR Annex G DLCI.

# Apply the X.25 template to the DLCI.

[RouterC-fr-dlci-Serial2/0-100] x25-template vofr

4 Configure Router E.
# Configure the link layer protocol on Serial 2/0 as X.25 and configure it to
operate in DTE mode.
<RouterE> system-view
[RouterE] interface serial 2/0
[RouterE-Serial2/0] link-protocol x25 dte
[RouterE-Serial2/0] x25 x121-address 8888
5 Configure Router D.
[RouterD] x25 switching
# Configure the link layer protocol of the interface Serial 2/0 as X.25, and
configure it to operate in DCE mode.
# Assign an IP address for the interface Ethernet 1/0
[RouterD] interface ethernet 1/0

[RouterD-Ethernet1/0] ip address 10.1.1.2 255.255.255.0
[RouterD-Ethernet1/0] quit
# Configure an X.25 switching route to an XOT channel
[RouterD] x25 switch svc 3333 xot 10.1.1.1
# Configure an X.25 switching route to Router E
Implementing X.25 Load Network requirements

Sharing Function for IP IP networks in different regions are connected via X.25 packet switching network
Datagram Transmission to carry data over X.25 network. Meanwhile, the network providers provide X.25
network load sharing function, and a user can perform the relative settings in
conjunction with it on local terminal to implement the line load sharing when
different clients access the server.

Network diagram
Figure 82 Transmit IP data over X.25 hunt group
Eth1 /0 S2/0
10.1.1 .1/16 1.1.1.1 /24
X121 address :1111 S 2/0
1.1.1.3 /24
Host A Router A X121 address:3333 Eth1/0
10.1.1.2 /16 Server A
X.25 packet 10.3.1.1/24
switching 10.3.1 .2/24
Eth1 /0 network S 2/1
Router C
10.2.1 .1/16 2.1.1.3 /24
S2/0 X121 address:3333
1.1.1.2 /24
X121 address :2222
Host B Router B Server B
10.2.1.2 /16 10.3.1 .3/24
In this example, since the network providers have configured load sharing on the
packet switch, you only need to configure X.25 switching.
Note that there have been two lines connected to the same peer on Router C, so
you must configure a virtual IP address and two static routes on the interface Serial
2/1 to “cheat” the router. In this way, Router C will deem that there are two
routes towards the network segment 10.1.1.0, to implement the load sharing.

[RouterA-Serial2/0] x25 vc-per-map 2
# Configure a static route to Router C.
[RouterC] ip route-static 10.3.1.0 24 1.1.1.3



[RouterB-Serial2/0] x25 vc-per-map 2
# Configure a static route to Router C.
[RouterB] ip route-static 10.3.1.0 24 1.1.1.3



# Configure static routes to Router A and Router B.

TCP/IP Header Network requirements

Compression Protocol As shown in the following figure, two routers are connected directly.
Application

Network diagram
Figure 83 Network diagram for TCP/IP header compression protocol application
S 2/0 S2/0
16 .16 .16 .1/16 16.16.16.2/16
X 121 address:1001 X121 address:1002
Router A Router B
1 Configure RouterA
# Configure the link layer protocol of Serial 2/0 as X.25, and configure the
interface to operate in DTE mode.
[RouterA-serial2/0] link-protocol x25 dte ietf
# Assign an x121 address for the interface.
[RouterA-serial2/0] x25 x121-address 1001
[RouterA-serial2/0] ip address 16.16.16.1 255.255.0.0
# Enable TCP/IP header compression.
[RouterA-serial1/0] x25 map compressedtcp 16.16.16.2 x121-address 10

02
# Configure the link layer protocol of Serial 2/0 as X.25, and configure the
interface to operate in DCE mode.
[RouterB-serial2/0] link-protocol x25 dce ietf
[RouterB-serial2/0] x25 x121-address 1002
[RouterB-serial2/0] ip address 16.16.16.2 255.255.0.0
# Enable TCP/IP header compression.
[RouterB-serial2/0] x25 map compressedtcp 16.16.16.1 x121-address 1001

X.25 PAD Configuration Network requirements

Example As shown in the following figure, Router A is connected to Router B through an
X.25 network. It is required that Router B could place X.25 PAD calls to log onto
Router A and then configure Router A.
Network diagram
Figure 84 Network diagram for X.25 PAD configuration
S 2/0 S2/0
X 121 address:1 X 121 address:2
X.25 network
Router A Router B
# Add a PAD user.
[RouterA] local-user pad1
[RouterA-luser-pad1] password simple pad1
[RouterA-luser-pad1] service-type pad
[RouterA-luser-pad1] quit
# Access a user-interface, and on it configure authentication mode and protocol

type.
[RouterA] user-interface vty 0 4

[RouterA-ui-vty0-4] authentication-mode scheme
[RouterA-ui-vty0-4] protocol inbound pad
[RouterA-ui-vty0-4] quit
# Configure domain user X.25 to use the local authentication scheme.
[RouterA] domain x25

[RouterA-isp-x25] authentication ppp local
[RouterA-isp-x25] quit
# Configure the link layer protocol of the interface Serial 2/0 as X.25. Configure
the interface to operate in DTE mode.


# Configure the link layer protocol of the interface Serial 2/0 as X.25. Configure
the interface to operate in DCE mode.

X2T Configuration Example 339

[RouterB] quit
# Place an X.25 PAD call to Router A.
<RouterB> pad 1
Trying 1...Open
Username:pad1
Password:pad1
X2T Configuration
Example
X2T SVC Configuration Network requirements

Example The router connects X.25 and IP networks together. In this connection, the X.25
terminal communicates with the router through SVC and the X2T technology
applied on the router enables the communication between X.25 terminal and IP
host.
Network diagram
Figure 85 Network diagram for X2T SVC
S2 /0 Eth1/0
X121 address:1111 10.1.1.1 /24 10 .1.1.2/24
X.25 network IP network

X.25 terminal Router Host
X121 address:2222
[Router] x25 switching

[Router-Serial2/0] link-protocol x25 dce
[Router-Serial2/0] x25 x121-address 1111
[Router] interface ethernet 1/0

[Router-Ethernet1/0] ip address 10.1.1.1 255.255.255.0
[Router-Ethernet1/0] quit
# Configure an X.25 route.
[Router] x25 switch svc 2222 interface serial 2/0

# Configure an X2T route.
[Router] translate ip 10.1.1.1 port 102 x25 2222

[Router] translate x25 1111 ip 10.1.1.2 port 102
X2T PVC Configuration Network requirements

Example The router connects X.25 and IP networks together. In this connection, the X.25
terminal communicates with the router through PVC and the X2T technology
applied on the router enables the communication between IP host and X.25
terminal.
Network diagram
Figure 86 Network diagram for X2T PVC
Eth1/0
S 2/0 10 .1 .1.2/24
10.1.1.1/24
X.25 network
IP network
PVC 1
X.25 terminal Router Host
[Router] x25 switching

[Router-Serial2/0] link-protocol x25 dce
[Router-Serial2/0] x25 vc-range in-channel 10 20 bi-channel 30 1024

# Configure an X2T route.
[Router] translate ip 10.1.1.1 port 102 pvc serial2/0 1
Troubleshooting LAPB
Configuration
LAPB (or X.25) of Two Symptom

Sides Always Being Link layer protocol LAPB (or X.25) of two sides is always down.
Down
Analysis
A possible reason is that the two sides are working in the same mode (DTE or
DCE).

Troubleshooting
Enable the debugging on both sides. If one side sends SABM frames and the other
sends FRMR frames cyclically, the two sides are working in the same mode (DTE or
DCE). Change the working mode of one side to solve it.
Failed to Ping the Other Symptom

Side with X.25 on Both Despite X.25 is up on both sides, the other side can not be pinged.
Sides Being Up
Analysis
The maximum length of frames set at one side is too small.
Troubleshooting
Enable the debugging on both sides. If one side discards incoming frames without
delivering them to the upper layer, it indicates the maximum length of frames set
for this side is too small. Change the frame length configuration of this side.
Troubleshooting X.25 Assume that the layer 2 LAPB of X.25 is up.

Configuration
X.25 of Two Sides Symptom

Always Being Down X.25 of two sides is always down although LAPB of two sides is up.
with LAPB of two sides
Being Up Analysis
A possible reason is that the two sides are working in the same mode (DTE or
DCE).
Troubleshooting
Change the working mode of one side.
Failed to Ping the Other Symptom

Side with X.25 on Both Despite X.25 is up on both sides, the other side can not be pinged.
Sides Being Up
Analysis
The following are possible causes:
■ The local X.121 address is not configured.
■ The address mapping of the two sides is not configured on the local end.
■ The peer’s X.121 address is not configured.
■ The address mapping of the two sides is not configured on the remote end.
■ The channel range is not correct.
■ Some wrong user facilities are carried.
Troubleshooting
■ If addresses are not correct, change them to the correct ones.
■ For the last two causes, you need contact the network administration to get
the correct channel range and user facilities.

Continuous Resets and Symptom

Clears of the VC The virtual circuit can be set up, but is frequently reset or cleared during data
Established transmission.
Analysis
The symptom may be caused by erroneous flow control parameter settings.
Troubleshooting
■ If the two sides are connected directly, verify the output window and input
window of the local match the input window and output window of the
remote.
■ If both sides are connected to the public packet network, consult the network
administration for the correct flow control parameters.
PVC Setup Request Symptom

Rejected The request to set permanent virtual circuits (PVCs) is rejected.
Analysis
A possible reason is that the PVC range is disabled.
Troubleshooting
If the assigned PVC number is in the disabled PVC channel range, X.25 will surely
reject the PVC setup request. In this case, enable the permanent virtual circuit
channel range.
Failed to Ping through Symptom

the XOT SVC Configured After configuring SVC application of XOT, unable to ping through.
Analysis
The physical status and protocol status of the interface are not up, or the SVC/XOT
configuration is not correct.
Troubleshooting
Perform the following procedure to remove the fault.
■ First verify the physical connection status and protocol status of the interface
are UP.
■ If the interface status is DOWN, check whether the physical connections and
lower layer configurations are correct.
■ If the interface configuration is correct, check whether SVC is configured
properly.
■ If the SVC configuration is also correct, check whether XOT is configured
properly.
Failed to Ping through Symptom

the XOT PVC Configured After configuring PVC application of XOT, unable to ping through.

Analysis
The physical status and protocol status of the interface are not up, or the PVC/XOT
configuration is not correct.
Troubleshooting
■ First check whether the physical connection status and protocol status of the
interface are UP.
■ If the interface status is DOWN, check whether the physical connections and
lower layer configurations are correct.
■ If the interface configuration is correct, check whether the PVC is configured
properly.
■ If the PVC configuration is also correct, check whether XOT is configured
properly.


LINK AGGREGATION OVERVIEW
15
n Link aggregation is not supported on MSR 20 series routers. It is only supported on

interfaces of 16FSW/24FSW modules of MSR 30/MSR 50 series routers.
Link aggregation aggregates multiple physical Ethernet ports into one logical link,
also called a logical group, to increase reliability and bandwidth.
This chapter covers these topics:
■ “Link Aggregation Overview” on page 345

■ “LACP” on page 345
■ “Load Sharing in a Link Aggregation Group” on page 349
■ “Aggregation Port Group” on page 349
Link Aggregation Link aggregation allows you to increase bandwidth by distributing

incoming/outgoing traffic on the member ports in an aggregation group. In
addition, it provides reliable connectivity because these member ports can
dynamically back up each other.
■ “LACP” on page 345

■ “Consistency Considerations for Ports in an Aggregation” on page 346
LACP The link aggregation control protocol (LACP), as defined in IEEE 802.3ad, is used
for link aggregation control.
LACP interacts with its peer by sending link aggregation control protocol data
units (LACPDUs).
By adding a port to a static aggregation group, you can enable LACP on the port.
After LACP is enabled on a port, the port sends an LACPDU to notify the remote
system of its system LACP priority, system MAC address, port LACP priority, port
number, and operational key. Upon receipt of an LACPDU, the remote system
compares the received information with the information received on other ports to
determine the ports that can operate as selected ports. This allows the two
systems to reach an agreement on whether a port is a selected port.
When aggregating ports, link aggregation control automatically assigns each port
an operational key based on its rate, duplex mode, and other basic configurations.
In an aggregation group, the selected ports share the same operational key.

346 CHAPTER 15: LINK AGGREGATION OVERVIEW
Consistency To participate in traffic sharing, member ports in an aggregation must use the
Considerations for Ports same configurations with respect to STP, QoS, GVRP, VLAN, port attributes, MAC
in an Aggregation address learning, and so on, as shown in the following table.
Table 8 Consistency considerations for ports in an aggregation
Category Considerations
STP State of port-level STP (enabled or disabled)
Attribute of the link (point-to-point or otherwise) connected to the port
Port path cost
STP priority
Maximum transmission rate
Loop protection
Root protection
Port type (whether the port is an edge port)
QoS Traffic policing
Traffic shaping
Congestion avoidance
Physical interface rate limiting
Strict priority (SP) queuing
Weighted round robin (WRR) queuing
Hardware weighted fair queuing (HWFQ)
Port priority
Policy setting on the port
Port priority trust mode
Flow template
GVRP GVRP state on ports (enabled or disabled)
GVRP registration type
GARP timers
VLAN VLANs carried on the port
Default VLAN ID on the port
Link type of the port, which can be trunk, hybrid, or access
Port attribute Port rate
Duplex mode
Up/down state of the link
Isolation group membership of the port
MAC address MAC address learning capability
learning
Setting of maximum number of MAC addresses that can be learned on
the port
Forwarding of frames with unknown destination MAC addresses after the
upper limit of the MAC address table is reached
Approaches to Link Two ways are available for implementing link aggregation, as described in
Aggregation “Manual Link Aggregation” on page 347 and “Static LACP Link aggregation” on
page 348.

Approaches to Link Aggregation 347
Manual Link Overview

Aggregation In the manual aggregation approach, aggregation groups are created
administratively. On the ports in a manual aggregation group, LACP is disabled.
Port states in a manual aggregation

In a manual aggregation group, ports are either selected or unselected. Selected
ports can receive and transmit data frames whereas unselected ones cannot.
Among all selected ports, the one with the lowest port number is the master port
and others are member ports.
When setting the state of ports in a manual aggregation group, the system
considers the following:
■ Select a port from the ports in up state, if any, in the order of full duplex/high
speed, full duplex/low speed, half duplex/high speed, and half duplex/low
speed, with the full duplex/high speed being the most preferred. If two ports
with the same duplex mode/speed pair are present, the one with the lower
port number wins out. Then, place those ports in up state with the same
speed/duplex pair, link state and basic configuration in selected state and all
others in unselected state.
■ When all ports in the group are down, select the port with the lowest port
number as the master port and set all ports (including the master) in unselected
state.
■ Place the ports that cannot aggregate with the master in unselected state, for
example, as the result of the cross-board aggregation restriction.
Manual aggregation limits the number of selected ports in an aggregation group.

When the limit is exceeded, the system changes the state of selected ports with
greater port numbers to unselected until the number of selected ports drops
under the limit.
In addition, unless the master port should be selected, a port that joins the group
after the limit is reached will not be placed in selected state even if it should be in
normal cases. This is to prevent the ongoing service on selected ports from being
interrupted. You need to avoid the situation however as the selected/unselected
state of a port may become different after a reboot.
n The maximum number of selected ports in a manual aggregation group varies by

device.
Port Configuration Considerations in manual aggregation

As mentioned above, in a manual aggregation group, only ports with
configurations consistent with those of the master port can become selected.
These configurations include port rate, duplex mode, link state and other basic
configurations described in “Consistency Considerations for Ports in an
Aggregation” on page 346."
You need to maintain the basic configurations of these ports manually to ensure
consistency. As one configuration change may involve multiple ports, this can
become troublesome if you need to do that port by port. As a solution, you may
add the ports to an aggregation group where you can make configuration for all
member ports.

When the configuration of some port in a manual aggregation group changes, the
system does not remove the aggregation; instead, it re-sets the
selected/unselected state of the member ports and re-selects a master port.
Static LACP Link Overview

aggregation Static aggregation groups are created manually. Adding a port to a static
aggregation group also enables LACP on it.
Port states in static aggregation

In a static aggregation group, ports can be selected or unselected, where both can
receive and transmit LACPDUs but only selected ports can receive and transmit
data frames. The selected port with the lowest port number is the master port and
all others are member ports.
All member ports that cannot aggregate with the master are placed in unselected
state. These ports include those using the basic configurations different from the
master port or those located on a board different from the master port because of
the cross-board aggregation restriction.
Member ports in up state can be selected if they have the configuration same as
that of the master port. The number of selected ports however, is limited in a static
aggregation group. When the limit is exceeded, the local and remote systems
negotiate the state of their ports as follows:
1 Compare the actor and partner system IDs that each comprises a system LACP
priority plus a system MAC address as follow:
■ First compare the system LACP priorities. The system with lower system LACP
priority wins out.
■ If they are the same, compare the system MAC addresses. The system with the
smaller ID has higher priority. (the lower the LACP priority, the smaller the MAC
address, and the smaller the device ID)
2 Compare the port IDs that each comprises a port LACP priority and a port number
on the system with higher ID as follows:
■ Compare the port LACP priorities. The port with lower port LACP priority wins
out.
■ If two ports with the same port LACP priority are present, compare their port
numbers. The state of the ports with lower IDs then change to selected and the
state of the ports with higher IDs to unselected, so does the state of their
corresponding remote ports. (the lower the LACP priority, the smaller the port
number, and the smaller the port ID)
n The maximum number of selected ports in a static aggregation group varies by

device.
Port configuration considerations in static aggregation

Like in a manual aggregation group, in a static LACP aggregation group, only
ports with configurations consistent with those of the master port can become
selected. These configurations include port rate, duplex mode, link state and other
basic configurations described in “Consistency Considerations for Ports in an
Aggregation” on page 346."

Load Sharing in a Link Aggregation Group 349
You need to maintain the basic configurations of these ports manually to ensure
consistency. As one configuration change may involve multiple ports, this can
become troublesome if you need to do that port by port. As a solution, you may
add the ports to an aggregation group where you can make configuration for all
member ports.
When the configuration of some port in a static aggregation group changes, the
system does not remove the aggregation; instead, it re-sets the
selected/unselected state of the member ports and re-selects a master port.
Load Sharing in a Link Link aggregation groups fall into load sharing aggregation groups and non-load
Aggregation Group sharing aggregation groups depending on their support to load sharing.
A load sharing aggregation group can contain at least one selected port but a
non-load sharing aggregation group can contain only one.
Link aggregation groups perform load sharing depending on availability of

hardware resources. When hardware resources are available, link aggregation
groups created containing at least two selected ports perform load sharing, while
link aggregation groups created with only one selected port perform load sharing
depending on the model of your device. After hardware resources become
depleted, link aggregation groups work in non-load sharing mode.
n ■ After you remove all ports but one selected port from a load sharing
aggregation group, whether the group continues to perform load sharing
varies with device models.
■ The load sharing implementation and the number of load sharing aggregation
groups supported varies with device models.
Aggregation Port As mentioned earlier, in a manual or static aggregation group, a port can be
Group selected only when its configuration is the same as that of the master port in
terms of duplex/speed pair, link state, and other basic configurations. Their
configuration consistency requires administrative maintenance, which is
troublesome after you change some configuration.
To simplify configuration, port-groups are provided allowing you to configure for

all ports in individual groups at one time. One example of port-groups is
aggregation port group.
Upon creation or removal of a link aggregation group, an aggregation port-group

which cannot be administratively created or removed is automatically created or
removed. In addition, you can only assign/remove a member port to/from an
aggregation port-group by assigning/removing it from the corresponding link
aggregation group.
For more information about port-groups, refer to “Configuring a Port Group” on

page 92 and “Ethernet Interface Configuration” on page 89.


LINK AGGREGATION CONFIGURATION
16
This chapter covers these topics:
■ “Configuring Link Aggregation” on page 351
■ “Displaying and Maintaining Link Aggregation” on page 353
■ “Link Aggregation Configuration Example” on page 353
Configuring Link When configuring link aggregation, go to these sections for information you are
Aggregation interested in:
■ “Configuring a Manual Link Aggregation Group” on page 351
■ “Configuring a Static LACP Link Aggregation Group” on page 352
■ “Assigning a Name for an Aggregation Group” on page 352
■ “Entering Aggregation Port Group View” on page 353
Configuring a Manual Follow these steps to configure a manual aggregation group:

Link Aggregation Group
Create a manual aggregation link-aggregation group agg-id Required
group mode manual
Enter Ethernet interface view interface interface-type --
interface-number
Assign the Ethernet port to the port link-aggregation group Required
aggregation group agg-id
Note that:
■ You may create a manual aggregation group by changing the type of an

existing static aggregation group. If the specified group contains ports, its
group type changes to manual with LACP disabled on its member ports; if not,
its group type directly changes to manual.
■ An aggregation group cannot contain ports with static MAC addresses/black
hole MAC addresses configured or 802.1x enabled.
■ Whether the destination port of a mirroring group or a port with a MAC
address learning limit can join an aggregation group depends on the model of
your device.
■ You can remove all ports in a manual aggregation group by removing the
group. If this group contains only one port, you can remove the port only by
removing the group.

352 CHAPTER 16: LINK AGGREGATION CONFIGURATION
■ To guarantee a successful aggregation, ensure that the ports at the two ends of
each link to be aggregated are consistent in selected/unselected state.
Configuring a Static Follow these steps to configure a static aggregation group:

LACP Link Aggregation
Group To do... Use the command... Remarks
Configure the system LACP lacp system-priority Optional
priority system-priority
32768 by default.
Changing system LACP
priority can affect the
selected/unselected state of
the ports in the group.
Create a static LACP link-aggregation group Required
aggregation group agg-id mode static
Enter Ethernet interface view interface interface-type --
interface-number
Configure the port LACP lacp port-priority Optional
priority port-priority-value
32768 by default.
Changing port LACP priority
can affect the
selected/unselected state of
the ports in the group.
Add the Ethernet port to the port link-aggregation Required
aggregation group group agg-id
Note that:
■ You can change a manual aggregation group containing no port to a static

LACP aggregation group.
■ An aggregation group cannot contain ports with static MAC addresses/black
hole MAC addresses configured or 802.1x-enabled.
■ Whether the destination port of a mirroring group or a port with a MAC
address learning limit can join an aggregation group depends on the model of
your device.
■ Removing a static LACP aggregation group causes LACP being disabled on all
the ports in the aggregation group.
■ For static LACP aggregation group containing only one port, you can remove
the port from the aggregation group only by removing the group.
n When making configuration, be aware that after a load-balancing aggregation

group changes to a non-load balancing group due to resources exhaustion, either
of the following may happen:
■ Forwarding anomaly resulted from inconsistency of the two ends in the
number of selected ports.
■ Some protocols such as GVRP malfunction because the state of the remote
port connected to the master port is unselected.
Assigning a Name for an Follow these steps to assign a name for an aggregation group:
Aggregation Group

Displaying and Maintaining Link Aggregation 353

Assign a name for an link-aggregation group Required
aggregation group agg-id description agg-name
None is configured by default.
Entering Aggregation In aggregation port group view, you can make configuration for all the member
Port Group View ports in a link aggregation group at one time.
Follow these steps to enter aggregation port group view:

Enter aggregation port group port-group aggregation agg-id --
view
c CAUTION: In aggregation port group view, you can configure aggregation related
settings such as STP, VLAN, QoS, GVRP, MAC address learning, but cannot add or
remove member ports.
Displaying and
Maintaining Link To do... Use the command... Remarks
Aggregation Display the local system ID display lacp system-id Available in any
view
Display detailed information display link-aggregation interface Available in any
about link aggregation for interface-type interface-number [ to view
the specified port or ports interface-type interface-number ]
Display summaries for all link display link-aggregation summary Available in any
aggregation groups view
Display detailed information display link-aggregation verbose Available in any
about specified or all link [ agg-id ] view
aggregation groups
Clear the statistics about reset lacp statistics [ interface Available in user
LACP for specified or all ports interface-type interface-number [ to view
interface-type interface-number ] ]
Link Aggregation Network requirements

Configuration Device A aggregates ports Ethernet 1/1 through Ethernet 1/3 to form one link
Example connected to Device B and performs load sharing among these ports.
Create an IPv6 service-loop group and assign port Ethernet 1/1 to the group.

354 CHAPTER 16: LINK AGGREGATION CONFIGURATION
Network diagram
Figure 87 Network diagram for link aggregation
Device A
Eth1/1
Eth1/2
Eth1/3
Link aggregation
Eth1/1
Eth1/2
Eth1/3
Device B
n This example only describes how to configure link aggregation on Device A. To

achieve link aggregation, do the same on Device B.
1 In manual aggregation approach
# Create manual aggregation group 1.
[DeviceA] link-aggregation group 1 mode manual
# Add ports Ethernet 1/1 through Ethernet 1/3 to the group.

[DeviceA-Ethernet1/1] port link-aggregation group 1
[DeviceA-Ethernet1/1] interface ethernet 1/2
2 In static aggregation approach
# Create static aggregation group 1.
[DeviceA] link-aggregation group 1 mode static
# Add ports Ethernet 1/1 through Ethernet 1/3 to the group.


MODEM CONFIGURATION
17
When configuring modem, go to these sections for information you are interested
in:
■ “Modem Configuration” on page 355
■ “Modem Configuration Example” on page 356
Overview Modem is a network device that is widely used. It is important for a device to
properly manage and control the use of modem in a network. However, there are
many modem manufacturers and various modem models. Even though all of them
support the AT command set and are compliant with the industry standard, each
type of modem differs somewhat on the implementations and command details.
The device provides the following functions for managing a modem.
1 Intercommunicate with the equipment of other vendors. The asynchronous serial

interfaces of the participating parties are working in flow mode interconnected via
modems.
2 Provide comprehensive debugging information for modem maintenance and
monitoring.
Modem Configuration Follow these steps to configure your modem:
Operation Command Description

Enter user interface view user-interface { first-num1 -
[ last-num1 ] | { aux | console |
tty | vty } first-num2
[ last-num2 ] }
Configure the modem dial-in modem { both | call-in | Required
and dial-out permission call-out }
Modem call-in and call-out
are denied by default.
Set the maximum interval modem timer answer Optional
allowed between picking up
The interval defaults to 30
the handset and dialing when
seconds.
a user try to establish a
connection
Configure modem answer Refer to “Configuring the Optional
mode. Modem Answer Mode” on page
Not recommended.
356

356 CHAPTER 17: MODEM CONFIGURATION

Configure modem through Refer to “Configuring Modem Optional
the AT commands Using the AT Commands” on
page 356
Configure modem callback service modem-callback Optional
Modem calling back is
denied by default.
Configuring the Modem You need to configure the modem answer mode depending on the answer state
Answer Mode of the connected external modem. When the modem is in auto-answer mode (AA
LED of the modem lights), configure the modem auto-answer command to
prevent the device from sending an answer instruction after the modem answers
automatically. If the modem is in non-auto answer mode, configure the undo
modem auto-answer command.
n If the modem answer mode configured is not consistent with the current answer
mode of the connected modem, the modem may operate improperly. So, do not
perform the operation unless absolutely needed.
Follow these steps to configure your modem answer mode:

Enter user interface view user-interface { first-num1 -
[ last-num1 ] | { aux | console
| tty | vty } first-num2
[ last-num2 ] }
Configure the modem to modem auto-answer Required
work in auto-answer mode
The modem works in
non-auto answer mode by
default.
Configuring Modem Follow these steps to configure your modem through the AT commands:
Using the AT Commands
Enter corresponding interface interface-type -
interface-number
interface view
Configure modem sendat at-string Required
through the AT
The command works in the mode of
commands
asynchronous serial interface
(including synchronous/asynchronous
operating in the asynchronous mode),
AUX interface or AM interface.
Modem Configuration Network requirements

Example Interface Serial 2/0 on your device connects to a remote Cisco router through DCC
dialup. When data needs transmission from IP address 1.1.1.1/16 to IP address

Troubleshooting 357
2.2.2.2/16, your device can automatically dial to the remote end through DCC for
data transmission, as shown in the network diagram.
For more information about DCC dialup, refer to “DCC Configuration” on page
153.
Network diagram
Figure 88 Network of the configuration for the router to manage the modem
S2/0 S2/0
1.1.1.1/16 2.2.2.2/16
PSTN
Router Modem Modem Cisco Router
1 Configure Router:
[Router-Serial2/0] dialer timer enable 5
[Router-Serial2/0] dialer number 666666
[Router] user-interface tty 1
For information about DCC commands, refer to “DCC Configuration” on page
153.
2 Configuring the Cisco router
For details, refer to Cisco documentation.
Troubleshooting Symptom:
Modem is in abnormal status (such as the dial tone or busy tone keeps humming
for a long time).
Solution:
■ Execute the commands shutdown and undo shutdown on the device

physical interface connected to the modem to check whether the modem has
been restored to normal status.
■ If the modem is still in abnormal status, you can re-power the modem.

358 CHAPTER 17: MODEM CONFIGURATION

PORT MIRRORING CONFIGURATION
18
When configuring port mirroring, go to these sections for information you are
interested in:
■ “Port Mirroring Overview” on page 359
■ “Configuring Local Port Mirroring” on page 360
■ “Displaying and Maintaining Port Mirroring” on page 361
■ “Examples of Typical Port Mirroring Configuration” on page 361
Port Mirroring
Overview
Introduction to Port Port mirroring allows you to duplicate the packets passing specified ports to the
Mirroring destination mirroring port. As destination mirroring ports usually have data
monitoring devices connected to them, you can analyze the packets duplicated to
the destination mirroring port on these devices so as to monitor and troubleshoot
the network.
Figure 89 A port mirroring implementation
Implementation of Port Local port mirroring is implemented through local port mirroring groups.
Mirroring
In a local port mirroring group, the source ports and the destination port are in the
same local port mirroring group. Packets passing through the source ports are
duplicated and then are forwarded to the destination port.

360 CHAPTER 18: PORT MIRRORING CONFIGURATION
Configuring Local Port Follow these steps to configure local port mirroring:
Mirroring
Create a local mirroring group mirroring-group groupid Required
local
Add ports to In system view mirroring-group groupid You can add ports to a port
the port mirroring-port mirroring group as source
mirroring mirroring-port-list { both | ports in either system view
group as inbound | outbound } or interface view.
source ports
In interface view interface interface-type In system view, you can add
interface-number multiple ports to a port
mirroring group at one
or
time. While in interface
controller cpos view, you can only add the
interface-number current port to a port
mirroring group.
[ mirroring-group groupid ]
mirroring-port { both | The support for source port
inbound | outbound } configuration in CPOS
interface view varies with
quit
device models.
Add a port to In system view mirroring-group groupid You can add a destination
the mirroring monitor-port port to a port mirroring
group as the monitor-port-id group in either system view
destination or interface view. They
In interface view interface interface-type
port achieve the same purpose.
interface-number
[ mirroring-group groupid ]
monitor-port
n ■ A local mirroring group is effective only when it has both source ports and the
destination port configured.
■ Layer 2 Ethernet ports, Layer 3 Ethernet interfaces, POS interfaces, and CPOS
interfaces can all be source mirroring ports, depending on device models.
■ Layer 2 Ethernet ports, Layer 3 Ethernet interfaces, and tunnel interfaces can all
be destination mirroring ports, depending on device models.
■ Do not enable STP, MSTP, or RSTP on destination ports for fear of interrupting
the device operation.
■ On some types of devices, aggregation ports can be destination ports.
■ Other restrictions concerning destination port exist. Refer to the user manuals
of your device for more information.
■ A port mirroring group can contain multiple source ports and only one
destination port.
■ A port can belong to only one port mirroring group.
■ The destination port and the source ports of a port mirroring group can only be
on the same board.
■ The destination port and the source ports of port mirroring groups created on
SIC-4FSW, DSIC-9FSW, and MSR20-21 Fabrics cannot be in different VLANs. So
make sure all the ports in a port mirroring group belong to the same VLAN
before you create the port mirroring group. For an existing port mirroring
group, removing a member port from the VLAN invalidates the port mirroring

Displaying and Maintaining Port Mirroring 361
group. In this case, you need to remove the port mirroring group and then
create another one.
■ Only Layer 2 ports support port mirroring.
Displaying and Follow these steps to display and maintain port mirroring:
Maintaining Port
Mirroring To do... Use the command... Remarks
Display the configuration of a display mirroring-group Available in any view
port mirroring group { groupid | local }
Examples of Typical
Port Mirroring
Configuration
Local Port Mirroring Network requirements

Configuration Example The user’s network is described as follows:
■ Department 1 is connected to port Ethernet 1/1 of Device C through Device A.
■ Department 2 is connected to port Ethernet 1/2 of Device C through Device B.
■ The Server is connected to port Ethernet 1/3 of Device C.
It is desired to monitor the packets sent and received by Department 1 and

Department 2 on the Server.
This can be achieved by configuring a local port mirroring group. Perform the
following configuration on Device C.
■ Configure port Ethernet 1/1 and Ethernet 1/2 as source mirroring ports.
■ Configure port Ethernet 1/3 as the destination mirroring port.
Network diagram
Figure 90 Network diagram for local port mirroring configuration
Department 1 Device A
Eth1/1
Eth1/3
Eth1/2
Device C Server
Department 2 Device B
# Enter system view.

362 CHAPTER 18: PORT MIRRORING CONFIGURATION
<DeviceC> system-view
# Create a local port mirroring group.
[DeviceC] mirroring-group 1 local
# Add port Ethernet 1/1 and Ethernet 1/2 to the port mirroring group as source
ports. Add port Ethernet 1/3 to the port mirroring group as the destination port.
[DeviceC] mirroring-group 1 mirroring-port ethernet 1/1 ethernet 1/2 both

[DeviceC] mirroring-group 1 monitor-port ethernet 1/3
# Display the configuration of all the port mirroring groups.
[DeviceC] display mirroring-group all

mirroring-group 1:
type: local
status: active
mirroring port:
Ethernet1/1 both
Ethernet1/2 both
monitor port: Ethernet1/3
After finishing the configuration, you can monitor all the packets received and
sent by Department 1 and Department 2 on the Server.

PPP AND MP CONFIGURATION
19
This document is organized as follows:
■ “PPP and MP Configuration” on page 363
■ “PPPoE Configuration” on page 393
When configuring PPP and MP, go to these sections for information you are
interested in:
■ “Introduction to PPP and MP” on page 363

■ “Configuring MP” on page 374
■ “Configuring PPP Link Efficiency Mechanism” on page 376
■ “Displaying and Maintaining PPP/MP/PPP Link Efficiency Mechanism” on page
379
■ “Troubleshooting PPP Configuration” on page 392
Introduction to PPP
and MP
PPP Point-to-point protocol (PPP) is a link layer protocol that carries network layer
packets over point-to-point links. It has found wide application because it can
provide user authentication, support synchronous/asynchronous communication,
and can be extended easily.
PPP defines a whole set of protocols, including link control protocol (LCP), network
control protocol (NCP), and authentication protocols like password authentication
protocol (PAP) and challenge handshake authentication protocol (CHAP), where,
■ LCP is responsible for establishing, removing and monitoring data links.

■ NCP is used to negotiate the format and type of the packets over data links.
■ PAP and CHAP are used for network security
PAP authentication
PAP is a two-way handshake authentication protocol using plain text password. It
operates in the following way:
1 The requester sends its username and password to the authenticator.
2 The authenticator then checks if the username and password are correct
according to its local user list and then return responses accordingly (Acknowledge
or Not Acknowledge).

364 CHAPTER 19: PPP AND MP CONFIGURATION
Figure 91 PAP Authentication
Authenticator Authenticatee
Sending the user

name and the
password
Ack or Not Ack
During PAP authentication, the password is transmitted on the link in plain text. In
addition, the authenticatee sends the username and the password repeatedly
through the established PPP link until the authentication is over. So PAP is not a
secure authentication protocol. It cannot prevent attacks.
CHAP authentication
Challenge-handshake authentication protocol (CHAP) is a three-way handshake
authentication protocol using ciphertext password.
Currently, two types of CHAP authentication exist: one-way CHAP authentication

and two-way CHAP authentication. By one-way CHAP authentication, one side of
the link acts as the authenticator and the other acts as the authenticatee. By
two-way authentication, each side serves as both the authenticator and the
authenticatee. Normally, one-way CHAP authentication is adopted.
CHAP authentication is performed as follows:
1 The authenticator actively initiates an authentication request by sending a

randomly generated packet (Challenge) carrying its own username to the
authenticatee.
2 When the authenticatee receives the authentication request, it looks up its local
user database for a password matching to the username in the packet. If a match
is found, the authenticatee encrypts this packet based on the packet ID, password
and the MD5 algorithm; and then sends back to the authenticator a Response
carrying the generated ciphertext and its own username.
3 If the authenticatee fails to find a match, it will check its local interface for the
default CHAP password. If the CHAP password has been configured, the
authenticatee encrypts this packet based on the packet ID, the default password
and the MD5 algorithm; and then sends back to the authenticator a Response
carrying the generated ciphertext and its own username.
4 After receiving the Response, the authenticator encrypts the original randomly
generated packet based on the authenticatee password it keeps and the MD5
algorithm. The authenticator then compares the result of the encryption with the
ciphertext received, and returns an Acknowledge or Not Acknowledge packet
depending on the comparison result.

Introduction to PPP and MP 365
Figure 92 CHAP Authentication
Authenticator Authenticatee
Challenge
Rsponse
Ack or Not Ack
Operating mechanism of PPP

PPP operates in the following procedure:
1 Enter the Establish phase before setting up a PPP link
2 Perform LCP negotiation in the Establish phase, which includes the operating
mode (SP or MP), the authentication mode and the maximum transmission unit
(MTU). If the negotiation is successful, LCP will enter the Opened status, indicating
that the underlying layer link has been established.
3 If the authentication (the remote verifies the local or the local verifies the remote)
is configured, the process comes to the Authenticate phase and starts the
CHAP/PAP authentication
4 If the authentication fails, it will come to the Terminate phase to remove the link
and the LCP will go down. If the authentication succeeds, it will proceed to start
the network negotiation (NCP). In this case, the LCP state is still Opened, while the
state of IP control protocol (IPCP) is changed from Initial to Request.
5 NCP negotiation supports the negotiation of IPCP, which primarily refers to the
negotiation of the IP addresses of the two parties. NCP negotiation is conducted
for the purpose of selecting and configuring a network layer protocol. Only the
network layer protocol that has been agreed upon by the two parties in the NCP
negotiation can send packets over the PPP link.
6 The PPP link will remain for communications until an explicit LCP or NCP frame
close it or some external events take place (for example, the intervention of the
user).
Figure 93 PPP operation flow chart
Dead UP Establish OPENED Authenticate
FAIL FAIL
SUCCESS/NONE
DOWN CLOSING
Terminate Network

For the details of PPP, refer to RFC 1661.
MP Multilink PPP (MP) provides an approach to increasing bandwidth. It allows

multiple PPP links to form an MP bundle. After receiving a packet, MP segments (if
the packet is large) the packet into fragments and distributes them over multiple
PPP links to the remote end. After the remote end receives these fragments, it
assembles them into a packet and passes the packet to the network layer.
Implementation
You can configure MPs through virtual templates (VT) or MP-group interfaces. VTs
are used to configure virtual access interfaces. After binding multiple PPP links to
an MP, you need to create a VA interface for the MP to enable it to exchange data
with the peers. VT and MP-group differ in the following.
■ Configuring MP through VT interfaces can involve an authentication process.
The device locates the interfaces associated to a specified VT according to the
username provided by the peers, and creates a bundle (called VT channel in the
system) corresponding to an MP link based on the configurations of the
template.
■ Multiple bundles can be created on the same virtual template interface, each of
which is an MP link. From the perspective of the network layer, these links form
a point to multipoint network topology. In this sense, virtual template
interfaces are more flexible than MP-group interfaces.
■ Bundling mode can be used to distinguish multiple bundles created on a VT
interface. You can use the ppp mp binding-mode command in VT interface
view to specify the bundling mode. Three bundling modes are available:
authentication, both (the default), and descriptor. The authentication
mode specifies to bundle links according to username, the descriptor mode
specifies to bundle links according to the peer descriptor (which is determined
during LCP negotiation), and the both mode specifies to bundle links
according to both username and descriptor.
■ MP-group interfaces are intended only for MP. On an MP-group interface, only
one bundle is allowed. Compared with VT interfaces, the configuration of
MP-group interfaces is simpler and easier, and accordingly is fast and effective,
easy to configure and understand.
Negotiation
MP negotiation involves two processes: first LCP negotiation, and then NCP
negotiation.
■ LCP negotiation, during which both sides negotiate the common LCP
parameters and check whether their peer interface is working in the MP mode.
If not, the LCP negotiation fails. After the LCP negotiation succeeds, NCP
negotiation starts.
■ NCP negotiation, which are performed based on the NCP parameters of the
MP-group interface or the specified VT interface. NCP parameters on physical
interfaces are not effective.
MP link is established after the NCP negotiation succeeds.
Functions
MP functions to:

Configuring PPP 367
■ Increase bandwidth, or dynamically increase/reduce bandwidth in combination

with dial control center (DCC)
■ Load sharing
■ Backup
■ Decrease transmission delay through fragmentation
MP can work on any physical or virtual interfaces encapsulated with PPP, such as
serial, ISDN BRI/PRI, and PPPoX (PPPoE, PPPoA, or PPPoFR). However, a multilink
bundle is preferred to include only one type of interfaces.
Configuring PPP
Configuring PPP Follow these steps to configure PPP:

Enter the specified interface view interface interface-type -
interface-number
Configure the link layer protocol link-protocol ppp Optional
encapsulated on the interface as
By default, PPP is used.
PPP
Configure the Configure the Refer to “Configuring the Optional
local device to local device to Local Device to
PPP authentication is
authenticate the authenticate the Authenticate the Peer
disabled by default
peer either PAP peer using PAP Using PAP” on page 368
or CHAP)
Configure the Refer to “Configuring the
local device to Local Device to
authenticate the Authenticate the Peer
peer using Using CHAP” on page 368
CHAP
Configure the Configure the Refer to “Configuring the Optional
local device to local device to Local Device to Be
PPP authentication is
be be Authenticated by the Peer
disabled by default
authenticated by authenticated by Using PAP” on page 369
the peer (either the peer using
PAP or CHAP) PAP
Configure the Refer to “Configuring the
local device to Local Device to Be
be Authenticated by the Peer
authenticated by Using CHAP” on page 369
the peer using
CHAP
Configure PPP negotiation Refer to “Configuring PPP Optional
parameters Negotiation” on page 370
Configure PPP link quality control Refer to “Configuring PPP Optional
(LQC) Link Quality Control” on
page 373
Enable the PPP accounting Refer to “Enabling the PPP Optional
statistics function Accounting Statistics
Function” on page 373

n This chapter only discusses local authentication. For information about the remote
AAA authentication, refer to “AAA/RADIUS/HWTACACS Configuration” on page
1751.
Configuring the Local Follow these steps to configure the local device to authenticate the peer using
Device to Authenticate PAP:
the Peer Using PAP
Enter the specified interface interface interface-type -
Configure the local device to ppp authentication-mode Required
authenticate the peer using pap [ [ call-in ] domain
If this command is used
PAP isp-name ]
without specifying the
domain keyword, the
system-default domain named
“system” will be used. The
authentication mode is local
authentication and the
address pool for address
allocation must be the one
configured for this domain
Create local user, and enter local-user username Required
local user view
Configure a password for the password { cipher | simple } Required
local user password
Configure service type of the service-type ppp Required
local user as well as other [ callback-nocheck |
attributes callback-number
callback-number |
[ :subcall-number ] ]
Create an ISP domain, or domain { isp-name | default Optional
enter an existing ISP domain { disable | enable
view isp-name } }
Configure domain user to use authentication ppp local Optional
local authentication scheme
n For detailed description on how to create a local user and configure its attributes,
and how to create a domain and configure its attributes, refer to “Configuring
Local User Attributes” on page 1767.
Configuring the Local Follow these steps to configure the local device to authenticate the peer using
Device to Authenticate CHAP:
the Peer Using CHAP

Configuring PPP 369

Configure the local device to ppp authentication-mode Required
authenticate the peer using chap [ [ call-in ] domain
If this command is used
CHAP isp-name ]
without specifying the
domain, the system-default
domain named system applies
by default. The authentication
mode is local authentication
and the address pool for
address allocation must be the
one configured for this
domain.
Configure local username ppp chap user username Required
Create local user, and enter local-user username Required
local user view
Configure a password for the password { cipher | simple } Required
local user password
Configure service type of the service-type ppp Required
local user as well as other [ callback-nocheck |
attributes callback-number
callback-number |
[ :subcall-number ] ]
Create an ISP domain, or domain { isp-name | default Optional
enter an existing ISP domain { disable | enable
view isp-name } }
Configure domain user to use authentication ppp local Optional
local authentication scheme
n For detailed description on how to create a local user and configure its attributes,
and how to create a domain and configure its attributes, refer to “Configuring
Local User Attributes” on page 1767.
Configuring the Local Follow these steps to configure the local device to be authenticated by the peer
Device to Be using PAP:
Authenticated by the
Peer Using PAP To do... Use the command... Remarks
Set the PAP username and ppp pap local-user username Required
password when configuring the password { cipher | simple }
By default, the username
local device to be authenticated password
and password are null.
by the peer using PAP
Configuring the Local Follow these steps to configure the local device to be authenticated by the peer
Device to Be using CHAP:
Authenticated by the
Peer Using CHAP Use the

Use the
Enter the specified interface view interface -
interface-type
interface-number
Configure local username ppp chap user Required
username
Configure local user Exit to system view quit -
and its corresponding
Create local user, and local-user Optional
password
enter local user view username
Configure local user’s password { cipher | Optional
password simple } password
Configure the default Configure the default ppp chap Optional
CHAP authentication CHAP password when password { cipher |
password implementing CHAP simple } password
authentication
Configuring PPP Introduction to PPP negotiation parameters

Negotiation PPP negotiation parameters include: timeout interval negotiation, IP address
negotiation and DNS address negotiation.
Timeout interval negotiation: In PPP negotiation, if, during the timeout interval,
the local device does not receive the response packet from the peer, PPP will
resend the last packet. The time ranges from 1 to 10 seconds.
IP address negotiation can be implemented in the following two ways:
■ Configure the device as client: when the local interface, with PPP encapsulated,
is not configured with an IP address, whereas its peer is configured with an IP
address, you can configure IP address negotiation for the local interface so that
it can receive IP address allocated from its peer. This configuration applies to
the situation when you access internet via ISP, and obtain an IP address from
the ISP.
■ Configure the device as server: If the device is configured as a server to allocate
IP address for its peer, you should first configure a local IP address pool in
domain view or system view, indicate the scope of the address pool, and then
specify the address pool used for the interface in interface view.
In PPP address negotiation, a device can also be configured to negotiate DNS

address, through which the device can either allocate DNS address to the peer, or
receive DNS address from the peer. Generally speaking, if the device is connected
with a PC through PPP, you should configure the device to allocate DNS address
for the peer. In doing so, the PC can access the Internet directly using the domain
name. Or, if the device is connected with an access server of a carrier through PPP,
you should configure the device to accept or actively request a DNS address from
its peer. In this way, the device can use the DNS address allocated by the access
server to resolve domain name.
Configuring PPP negotiation parameters

Follow these steps to configure PPP negotiation parameters:

Configuring PPP 371

Configure the timeout interval ppp timer negotiate Optional
of PPP negotiation seconds
Configure IP address Refer to “Configuring IP Optional
negotiation address negotiation” on page
371
Configure DNS address Refer to “Configuring DNS Optional
negotiation address negotiation” on page
372
Configuring IP address negotiation

Follow these steps to configure IP address negotiation:
Use the
interface-type
interface-number
Configure IP address Configure the device Refer to the section Required
negotiation (as either client as client below
or server)
Configure the device Refer to the section Required
as server below
1 Configuring the device as client
Follow these steps to configure the device as client:

interface-number
Configure IP address of the interface to ip address ppp-negotiate Required
be negotiable
2 Configuring the device as server
Follow these steps to configure the device as server for PPP users do not need
authentication:



Assign an IP Define global ip pool pool-number Required
address for the address pool and low-ip-address
If remote address pool
peer using global use it to allocate [ high-ip-address ]
is configured without
address pool or an IP address for
interface interface-type specifying pool-number,
directly specify an the peer
interface-number the global address pool 0
IP address for the
is used by default.
peer (use either remote address pool
method) [ pool-number ]
Directly specify interface interface-type Required
an IP address for interface-number
the peer
remote address
ip-address
Follow the following steps to configure the device as server for PPP users that need
authentication:

Enter the specified domain domain domain-name Required
view
Define domain address pool ip pool pool-number Required
low-ip-address
[ high-ip-address ]
Assign IP address for PPP user remote address pool Required
through domain address pool [ pool-number ]
If remote address pool is
configured but without
specifying pool-number, the
address pool under this
domain is used in turn for IP
address allocation.
Forbid the remote end to use ppp ipcp remote-address Optional
fixed IP address configured by forced
By default, IP address
itself
negotiation in PPP IPCP does
not forbid the remote end to
use fixed IP address
configured by itself.
Note that the domain used in defining the pool address is the domain specified
when performing PPP authentication.
Configuring DNS address negotiation

Follow these steps to configure DNS address negotiation:

interface-number

Configuring PPP 373

Configure Enable the local device ppp ipcp dns Required
DNS address to assign DNS server primary-dns-address
By default, DNS server
negotiation address for the peer [ secondary-dns-address
address negotiation is
based on ]
disabled
actual needs
Enable the device to ppp ipcp dns Required
accept the DNS server admit-any
By default, DNS server
address assigned by the
address negotiation is
peer or actively request
disabled.
its peer for the DNS
server address (use ppp ipcp dns request Required
either of the two)
By default, a device is
disabled from requesting
its peer for the DNS
server address actively.
Configuring PPP Link Introduction to PPP link quality control

Quality Control PPP link quality control (LQC) can monitor the real-time quality of PPP links
(including those in MP bundles). A link goes down when its quality drops below
the close percentage and goes up when its quality recovers above the
resume-percentage. To avoid frequent flapping, a delay is involved before a link is
reused.
Before you enable PPP LQC, the PPP interface sends keepalives to the peer every
some time. After you enable LQC on the interface, it sends link quality reports
(LQRs) instead of keepalives to monitor the link.
When link quality is normal, the system calculates link quality based on each LQR
and disables the link if the results of two consecutive calculations are below the
close-percentage. Once the link is disabled, the system starts to calculate link
quality every ten LQRs, and brings the link up if the results of three consecutive
calculations are higher than the resume-percentage. This means a disabled link
must experience 30 keepalive periods before it can go up again. If a large
keepalive period is specified, it may take long time for the link to go up.
Follow these steps to configure PPP link quality control:

Enter the specified interface interface-type -
Enable PPP LQC ppp lqc close-percentage Required
[ resume-percentage ]
By default, resume-percentage is
equal to close-percentage
Enabling the PPP Introduction to PPP accounting statistics

Accounting Statistics PPP can generate traffic-based accounting statistics on each PPP link. The statistics
Function include the amount of the inbound and outbound information (in terms of bytes
and the number of the packets) on a link. The information can be used by AAA
application modules for accounting and control purpose.

Enabling the PPP accounting statistics function

Following these steps to enable the PPP accounting statistics function:

interface-number
Enable the PPP accounting ppp account-statistics Required
statistics function enable
Configuring MP
Configuring MP Using a Introduction

VT Interface When configuring MP via VT interface, you can do one of the following:
■ Assign physical interfaces to the virtual template using the ppp mp
virtual-template command. In this case, the configuration of authentication
is optional. Without authentication, the system binds links according to the
remote endpoint descriptor. With authentication, the system bundles links
according to both remote username and endpoint descriptor.
■ Associate a username with the virtual template. When bundling links, the
system searches for the associated virtual template interface according to the
provided valid username and bundles links according to the username and the
remote endpoint descriptor. To ensure a successful link negotiation, you must
configure the ppp mp command and two-way authentication (CHAP or PAP)
on the bundled interfaces.
n ■ When the ppp mp virtual-template command is configured on an interface,

the system does not look for a VT interface by username. Instead, it looks for
the template configured by the command.
■ You must configure the interfaces to be bundled in the same way.
■ In practice, you may configure one-way authentication, where one end
associates physical interfaces to a virtual template interface and the other end
searches for the virtual template interface by username.
■ A virtual template interface is preferred to provide only one service, such as MP,
L2TP, or PPPoE.
When configuring MP on the virtual template interface, you can use either
username or endpoint descriptor or both. The username discussed here refers to
the remote username received during PAP or CHAP authentication performed
when setting up a PPP connection. An endpoint descriptor, which uniquely
identifies a device, refers to the remote endpoint descriptor received during LCP
negotiation. The system distinguishes among the MP bundles on a virtual template
interface by username and endpoint descriptor.
Follow these steps to configure MP on the virtual template interface:

Configuring MP 375

Create and enter VT interface virtual-template Required
interface number
Associate a Associate a interface interface-type -
physical physical interface-number
interface or interface
ppp mp virtual-template Required
a username with the
number
with the VT virtual Specify the number of VT
interface template interface to be bundled on the
interface interface
(use either
method) Refer to “Configuring PPP” on Optional
page 367
PPP authentication has no
effect on the setup of MP
Associate a ppp mp user username bind Required
username virtual-template number
Associate VT interface with MP
with the VT
users
interface
interface interface-type -
interface-number
ppp mp Required
Configure the interface
encapsulated with PPP to work
in MP mode
Refer to “Configuring PPP” on Required
page 367
Configure other optional Refer to “Configuring other Optional
parameters optional parameters” on page
375
Configuring other optional parameters

Follow these steps to configure other optional parameters:

Create and enter MP VT interface virtual-template Required
interface or dialer interface number
view
interface dialer number
Specify the binding mode on ppp mp binding-mode Optional
VT interface { authentication | both |
By default, MP binding is
descriptor }
based on both the PPP
authentication username and
the descriptor.
Configure the maximum ppp mp max-bind Optional
number of links in MP bundle max-bind-num
16 by default
This command is available in
VT interface view and dialer
interface view.


Configure the minimum ppp mp min-bind Optional
number of links in MP bundle min-bind-num
0 by default, which means MP
dialup relies on traffic
detection.
This command is available in
dialer interface view only. The
min-bind-num argument
should be not greater than
max-bind-num
Configure the minimum size ppp mp min-fragment size Optional
of outgoing MP packet to be
fragmented
n ■ After you have configured the ppp mp max-bind command or the ppp mp
min-bind command, you must shutdown and then undo shutdown all the
relevant physical interfaces before the modification takes effect.
■ When MP binding is only based on descriptors, users cannot be differentiated.
So, to bind users to different groups, use the keyword both in the command.
■ When MP binding is only based on authentication usernames, peer devices
cannot be differentiated. So, authentication username-based MP binding
cannot be used when multiple peer devices exist.
■ For a VT interface, if a static route is used, you are recommended to specify the
next hop rather than the outgoing interface. If the outgoing interface must be
specified, make sure that the physical interfaces bound in the VT are effective
to ensure normal transport of packets.
■ For detailed description on configuring MP parameters in Dialer interface view,
refer to “Configuring MP for DCC” on page 168.
Configuring an Follow these steps to configure MP via MP-group:

MP-group
Create an MP-group interface mp-group number Required
Assign the interface to the ppp mp mp-group number Required
specified MP-group
Configuring PPP Link Four mechanisms are available for improving transmission efficiency on PPP links.
Efficiency Mechanism They are IP header compression (IPHC), Stac Lempel-Ziv standard (STAC LZS)
compression on PPP packets, V. Jacobson Compressing TCP/IP Headers (VJ TCP
header compression), and link fragmentation and interleaving (LFI).
IP header compression
IPHC is a host-to-host protocol used to support real-time multimedia services such
as voice and video over IP networks. To decrease the bandwidth consumed by
headers, you may enable IP header compression on PPP links to compress RTP

Configuring PPP Link Efficiency Mechanism 377
(including IP, UDP, and RTP) headers or TCP headers. The following describes how
compression operates by taking RTP header compression as an example.
The real-time transport protocol (RTP) is virtually a UDP protocol using fixed port
number and format. The protocol includes a 40-byte header and a data section.
There is a concern that the 40-byte header which is composed of a 20-byte IP
header, an 8-byte UDP header and a 12-byte RTP header, is too large when
compared with the 20 bytes to 160 bytes typical payloads of RTP. To reduce
unnecessary bandwidth consumption, you can use IPHC to compress headers.
After compression, the 40-byte header can be reduced to 2 to 5 bytes. If the
payload is 40 bytes, the compression ratio will be (40+40) / (40+5), about 1.78,
which is very efficient. The process of IPHC is illustrated in the following figure.
Figure 94 IP header compression
Incoming
packets RTP header compression
Output
queue
Queue
Traffic
classifying
Non-RTP traffic
Stac LZS compression

Stac LZS compression is a link-layer data compression standard developed by Stac
Electronics. Stac LZS is a Lempel-Ziv-based algorithm that compresses only packet
payloads. It replaces a continuous data flow with binary code that can
accommodate to the change of data. While allowing for more flexibility, this
requires more CPU resources.
VJ TCP header compression

VJ TCP header compression was defined in RFC 1144 for use on low-speed links.
Each TCP/IP packet transmitted over a TCP connection contains a typical 40-byte
TCP/IP header containing an IP header and a TCP header that are 20-byte long
each. The information in some fields of these headers, however, is unchanged
through the lifetime of the connection and needs sending only once, while the
information in some other fields changes but regularly and within a definite range.
Based on this idea, VJ TCP header compression may compress a 40-byte TCP/IP
header to 3 to 5 bytes. It can significantly improve the transmission speed of some
applications, such as FTP, on a low-speed serial link like PPP.
Link Fragmentation and Interleaving

On the low speed serial link, real-time interactive communication (such as Telnet
and VoIP) is performed, and block and delay may occur when large packets are
transmitted. For example, if a voice packet arrives when large packets are being
scheduled and waiting for being transmitted, it has to wait until all the large
packets have been transmitted. As for the real-time applications, large packets can

cause block and delay, consequently, the remote end cannot hear continuous
speech. It is required by the interactive voice that the end-to-end delay cannot be
larger than 100-150 ms.
Dispatching a large packet of 1500 bytes through a 56-kbps line, perhaps will take
215 ms, this will exceed the delay point that one can tolerate. LFI is a method for
fragmenting larger packets and adding both the smaller packets and fragments of
the large packet to the queue. The fragmented datagrams are reassembled at the
destination. LFI can reduce delay of real-time packets on relatively slow bandwidth
links.
The following figure describes the process of link fragmentation and interleaving.
When large packets and small voice packets arrives at an interface at the same
time, the large packets are fragmented into small fragments. If the interface is
configured with WFQ, the voice packets and these small fragments are interleaved
together and put into the WFQ.
Figure 95 Link fragmentation and interleaving
WFQ
Fragmentation
Large packet
Output queue
WFQ
Traffic
Voice packet classifying
Configuring IPHC Follow these steps to configure IPHC:
Use the
Create an MP-group interface mp-group Required
number
interface-type
interface-number
Configure Enable IPHC ppp compression Required
IPHC iphc
(optional) [ nonstandard ]
Configure the maximum number of ppp compression Optional
TCP header compression connections iphc
16 by default
tcp-connections
number
Configure the maximum number of ppp compression Optional
RTP header compression connections iphc
16 by default
rtp-connections
number

Displaying and Maintaining PPP/MP/PPP Link Efficiency Mechanism 379
Use the
Enable Stac-LZS compression on the interface ppp compression Optional
stac-lzs
disabled by default
Currently,
outbound expedite
forwarding is not
applicable on links
with Stac-LZS
compression
enabled. So, it is
recommended that
you disable
outbound expedite
forwarding before
performing this
operation.
Enable VJ TCP header compression on PPP ip tcp vjcompress Optional
interface
disabled by default
Configure PPP link Enter VT interface interface Required
fragmentation and view or MP-group virtual-template
interleaving (optional) interface view number
interface mp-group
number
Enable LFI ppp mp lfi Required
Disable by default
Configure the ppp mp lfi Required
maximum time delay delay-per-frag time
10 ms by default
of LFI fragments
Displaying and
Maintaining To do... Use the command...
PPP/MP/PPP Link Display the information about an display interface mp-group [ mp-number ]
Efficiency Mechanism existing MP-group interface
Display the information about a VA display virtual-access [ dialer dialer-number | vt
interface vt-number | user user-name | peer peer-address |
va-number ] *
Display the information about an display interface virtual-template [ number ]
existing VT
Display the information about an MP display ppp mp [ interface interface-type
interface interface-number ]
Display the statistics on TCP header display ppp compression iphc tcp [ interface-type
Display statistics on RTP header display ppp compression iphc rtp [ interface-type
Display statistics on Stac LZS header display ppp compression stac-lzs [ interface-type
Clear all statistics on IP header reset ppp compression iphc [ interface-type

PPP and MP
Configuration
Example
PAP Authentication Network requirements

Example As shown in Figure 96, Router A and Router B are interconnected through the
interface Serial 2/0, and Router A is required to authenticate Router B using PAP.
Network diagram
Figure 96 Network diagram for PAP and CHAP authentication

S2/0 S 2/0
200.1.1.1 /16 200 .1.1.2/16
Router A Router B
[RouterA] local-user user2
[RouterA-luser-user2] service-type ppp
[RouterA-luser-user2] password simple pass2
[RouterA-luser-user2] quit
[RouterA-Serial2/0] ppp authentication-mode pap domain system
[RouterA-Serial2/0] ip address 200.1.1.1 16
[RouterA] domain system
[RouterA-isp-system] authentication ppp local
[RouterB-Serial2/0] ppp pap local-user user2 password simple pass2
[RouterB-Serial2/0] ip address 200.1.1.2 16
CHAP Authentication Network requirements

Example As shown in Figure 96, Router A is required to use CHAP to authenticate Router B.
Approach I: use local username and password to perform CHAP
[RouterA-luser-user2] password simple hello
[RouterA-Serial2/0] ppp chap user user1

[RouterA-Serial2/0] ppp authentication-mode chap domain system

[RouterA]domain system
2 Configure router B.
[RouterB-luser-user1] password simple hello
[RouterB-Serial2/0] ppp chap user user2
Approach II: use default CHAP password to perform authentication
[RouterA-Serial2/0] ppp authentication-mode chap domain system
[RouterB-Serial2/0] ppp chap user user2
[RouterB-Serial2/0] ppp chap password simple hello
If you configure the ppp authentication-mode chap command without

specifying the domain keyword, the default domain named system is adopted at
the time of authentication and local authentication applies by default.
MP Configuration Network requirements

Example Figure 97 presents a scenario, where:
■ On an E1 interface of Router A, four channels are created with interface names
being Serial 2/0:1, Serial 2/0:2, Serial 2/0:3, and Serial 2/0:4 respectively.
■ On Router B, two channels are created with interface names being Serial 2/0:1
and Serial 2/0:2 respectively. The same is done on Router C.
Do the following:
■ Bind two channels on Router A with the two channels on Router B and another
two channels with the two channels on Router C.

■ Adopt binding authentication.
Network diagram
Figure 97 Network diagram for MP configuration

Router B Host
S 2/0
Host Host
S 2/0
DDN
Router A
Host
S 2/0
Host
Router C Host
# Add the users for Router B and Router C
[RouterA] local-user router-b
[RouterA-luser-router-b] password simple router-b
[RouterA] local-user router-c
[RouterA-luser-router-c] password simple router-c
[RouterA-luser-router-c] quit
# Specify the virtual-templates for the two users.
[RouterA] ppp mp user router-b bind virtual-template 1

[RouterA] ppp mp user router-c bind virtual-template 2
# Configure the virtual-templates

# Assign interfaces Serial 2/0:1, Serial 2/0:2, Serial 2/0:3, and Serial 2/0:4 to MP
channels, taking Serial 2/0:1 for an example.
[RouterA] interface serial 2/0:1

[RouterA-Serial2/0:1] link-protocol ppp
[RouterA-Serial2/0:1] ppp mp
[RouterA-Serial2/0:1] ppp authentication-mode pap domain system
[RouterA-Serial2/0:1] ppp pap local-user router-a password simple router-a
[RouterA-Serial2/0:1] quit
# Configure the users in the domain to use the local authentication scheme.


# Add a user for Router A
[RouterB] local-user router-a
[RouterB-luser-router-a] password simple router-a
[RouterB-luser-router-a] quit
# Specify the virtual-template for this user and perform PPP negotiation by using
the NCP information of this template
[RouterB] ppp mp user router-a bind virtual-template 1
# Configure operating parameters of the virtual-template

# Assign interfaces Serial 2/0:1 and Serial 2/0/:2 to the MP channel, taking Serial
2/0:1 for an example.

[RouterB-Serial2/0:1] ppp mp
[RouterB-Serial2/0:1] ppp authentication-mode pap domain system
[RouterB-Serial2/0:1] ppp pap local-user router-b password simple router-b
3 Configure Router C:
# Add a user for Router A
[RouterC] local-user router-a
[RouterC-luser-router-a] password simple router-a
[RouterC-luser-router-a] quit
# Specify a virtual-template for this user and the NCP information of the template
will be used for PPP negotiation.
[RouterC] ppp mp user router-a bind virtual-template 1
# Configure operating parameters of the virtual-template

# Assign interfaces Serial 2/0:1 and Serial 2/0:2 to the MP channel, taking Serial
2/0:1 for an example.
[RouterC] interface serial 2/0:1

[RouterC-Serial2/0:1] ppp mp
[RouterC-Serial2/0:1] ppp authentication-mode pap domain system
[RouterC-Serial2/0:1] ppp pap local-user router-c password simple router-c
[RouterC-Serial2/0:1] quit

[RouterC] domain system

Three Types of MP Network requirements

Binding Mode As showed in the figure below, Router A and Router B are connected together
through serial ports, Serial 2/0 to Serial 2/0 and Serial 2/1 to Serial 2/1 respectively.
Three binding modes that are demonstrated are directly Virtual-Template binding
mode, authentication binding mode and MP-group interface binding mode.
Network diagram
Figure 98 Network diagram for MP binding mode configuration

S2 /0 S2/0
MP
Router A S2 /1 S2/1 Router B
1 Directly assign physical interfaces to a virtual template interface
Configure Router A:
# Configure the username and password of Router B
[RouterA] local-user rtb
[RouterA-luser-rtb] password simple rtb
[RouterA-luser-rtb] service-type ppp
[RouterA-luser-rtb] quit
# Create a virtual template interface and assign an IP address to it.

[RouterA-Virtual-Template1] ip address 8.1.1.1 24
[RouterA-Virtual-Template1] ppp mp binding authentication
[RouterA-Virtual-Template1] interface serial 2/1

[RouterA-Serial2/1] ppp pap local-user rta password simple rta
[RouterA-Serial2/1] ppp mp virtual-template 1
[RouterA] interface serial2/0



[RouterA-isp-system] quit
Configure Router B:
# Configure the username and password of Router A
[RouterB] local-user rta
[RouterB-luser-rta] password simple rta
[RouterB-luser-rta] service-type ppp
[RouterB-luser-rta] quit
# Create a virtual-template interface and assign an IP address to it.

[RouterB-Virtual-Template1] ip address 8.1.1.2 24
[RouterB-Virtual-Template1] ppp mp binding authentication

[RouterB-Serial2/1] ppp authentication-mode pap domain system
[RouterB-Serial2/1] ppp pap local-user rtb password simple rtb
[RouterB-Serial2/1] ppp mp virtual-template 1

# Configure the users in the domain to use local authentication scheme.

[RouterB-isp-system] authentication ppp local
Verify the results on Router A:
[RouterA] display ppp mp

Template is Virtual-Template1
Bundle rtb, 2 member, Master link is Virtual-Template1:0

0 lost fragments, 0 reordered, 0 unassigned, 0 interleaved,

sequence 0/0 rcvd/sent
The bundled member channels are:
Serial2/1
Serial2/0
Check information about virtual access interfaces:
[RouterA] display virtual-access

----------------Slot 1----------------
Virtual-Template1:0 current state : UP
Line protocol current state : UP
Description : Virtual-Template1:0 Interface
The Maximum Transmit Unit is 1500
Link layer protocol is PPP
LCP opened, MP opened, IPCP opened, OSICP opened, MPLSCP opened
Physical is MP
Output queue : (Urgent queue : Size/Length/Discards) 0/500/0
Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0
5 minutes input rate 0 bytes/sec, 0 packets/sec
5 minutes output rate 0 bytes/sec, 0 packets/sec
6 packets input, 66 bytes, 0 drops
6 packets output, 66 bytes, 0 drops
The display about Router A is similar.
On Router B ping the IP address 8.1.1.1.
[RouterB] ping 8.1.1.1

PING 8.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 8.1.1.1: bytes=56 Sequence=1 ttl=255 time=29 ms
--- 8.1.1.1 ping statistics ---

5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 29/30/31 ms
Because PPP authentication is configured on the physical interface, the bundle

field in the output of the display ppp mp command is identified by remote
username. If authentication is disabled, the bundle field should be identified by
the remote endpoint descriptor.
In addition, you can view the state of MP virtual channels by viewing the state of
virtual access interfaces with the display virtual-access command.
2 Associate remote username with virtual template interface
Configure Router A:

# Assign a virtual-template to user RTB
[RouterA] ppp mp user rtb bind virtual-template 1
# Create a virtual-template and configure the IP address

[RouterA-Virtual-Template1] ip address 8.1.1.1 24
[RouterA-Virtual-Template1] ppp mp binding authentication

[RouterA-Serial2/1] ppp mp

[RouterA-Serial2/0] ppp mp
# Configure the user in the domain to use the local authentication scheme

Configure Router B
# Configure the username and password of Router A
# Assign a virtual-template to user RTA
[RouterB] ppp mp user rta bind virtual-template 1

# Create a virtual-template and configure the IP address

[RouterB-Virtual-Template1] ip address 8.1.1.2 24
[RouterB-Virtual-Template1] ppp mp binding authentication

[RouterB-Serial2/1] ppp mp

[RouterB-Serial2/0] ppp mp
# Apply user authentication to domain users.

Verify the results on Router A:
<RouterA> display ppp mp

Bundle rtb, 2 member, Master link is Virtual-Template1:0
Serial2/1
Serial2/0
Verify the results on Router B:
[RouterB] display ppp mp

Bundle rta, 2 member, Master link is Virtual-Template1:0
Serial2/1
Serial2/0

# Check information about virtual access interfaces:
[RouterB] display virtual-access

Virtual-Template1:0 current state : UP
Description : Virtual-Template1:0 Interface
LCP opened, MP opened, IPCP opened, OSICP opened, MPLSCP opened
Physical is MP
# On Router B, ping the remote IP address 8.1.1.1:
[RouterB] ping 8.1.1.1


0.00% packet loss
Incorrect configuration:
If you intend to bind interfaces serial 2/1 and serial 2/0 into the same MP, but you
configured one as ppp mp while the other as ppp mp virtual-template 1, the
system will bind the two interfaces into different MP.
3 Configure MP bundle on an MP-group interface
In addition to virtual template interfaces, the system provides MP-group interfaces

to implement MP bundling. This implementation is similar to directly assigning
physical interfaces to a virtual template.
Configure Router A:
# Create an MP-group interface, and configure its IP address

[RouterA] interface mp-group 1

[RouterA-Mp-group1] ip address 111.1.1.1 24
[RouterA-Mp-group1] interface serial 2/1

[RouterA-Serial2/1] ppp mp mp-group 1

[RouterA-Serial2/0] ppp mp mp-group 1

Configure Router B
# Configure username and password for Router A
# Create Mp-group interface and configure its IP address
[RouterB] interface mp-group 1

[RouterB-Mp-group1] ip address 111.1.1.2 24
[RouterB-Mp-group1] quit

[RouterB-Serial2/1] ppp mp mp-group 1


[RouterB-Serial2/0] ppp mp mp-group 1

Verify the results on Router A
[RouterA] display ppp mp

Mp-group is Mp-group1
Bundle Multilink, 2 member, Master link is Mp-group1
Serial2/0
Serial2/0
# Check the state of Mp-group1
[RouterA] display interface Mp-group 1

Mp-group1 current state : UP
Description : Mp-group1 Interface
The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
Internet Address is 111.1.1.1/24
LCP opened, MP opened, IPCP opened, MPLSCP opened
Physical is MP
# On Router A, ping the remote IP address:
[RouterA] ping 111.1.1.2


0.00% packet loss

Note that in this approach to MP binding, all users are bound together and the
concept of virtual access is not involved.
Troubleshooting PPP Symptom 1: Link never turns into up state.

Configuration
Solution: This problem may arise because of the PPP authentication failure due to
the incorrect configuration of PPP authentication parameters.
Enable the debugging of PPP, and you will see the information describing that LCP
went up upon a successful LCP negotiation but went down after the PAP or CHAP
negotiation.
Symptom 2: Physical link failed in going up.
Solution: Execute the display interface serial type number command to view
the current interface statuses, including:
serial number is administratively down, line protocol is down", which indicates

that the interface has been shut down by the administrator.
serial number is down, line protocol is down", which indicates that the interface is
not active or the physical layer has not gone up yet.
Virtual-template number is down, line protocol is spoofing up", which indicates

that this interface is a dialer interface and the call establishment attempt has
failed.
serial number is up, line protocol is up", which indicates that the link negotiation,
i.e., the LCP negotiation on this interface has succeeded.
serial number is up, line protocol is down", which indicates that this interface is
active, but link negotiation has failed.

PPPOE CONFIGURATION
20
When configuring PPPoE, go to these sections for information you are interested
in:
■ “Introduction to PPPoE” on page 393
■ “Configuring PPPoE Server” on page 394
■ “Configuring PPPoE Client” on page 395
■ “Displaying and Maintaining PPPoE” on page 397
■ “PPPoE Configuration Example” on page 397
Introduction to PPPoE PPPoE

Point-to-point protocol over Ethernet (PPPoE) connects a network of hosts formed
by Ethernet to a remote access device to gain access to the Internet. It allows you
to perform access control and accounting on a per-host basis. As it is highly
cost-effective, PPPoE is widely adopted, for example, in network constructions for
residential areas.
PPPoE adopts the client/server model. It provides point-to-point connectivity over

Ethernet by encapsulating PPP packets in Ethernet frames.
PPPoE is divided into two distinct phases: discovery and PPP session.
■ Discovery phase
When a host wants to start a PPPoE process, it must first identify the MAC address
of the Ethernet on the access end and create the SESSION ID of PPPoE. This is the
very purpose of the discovery phase.
■ PPP session phase
After entering the session phase of PPPoE, the system can encapsulate the PPP
packet as the payload of PPPoE frame into an Ethernet frame and then send the
Ethernet frame to the peer. In the frame, the SESSION ID must be the one
determined at the discovery phase, MAC address must be the address of the peer,
and the PPP packet section begins with the Protocol ID. In the Phase of Session,
either the host or the server may send PPPoE Active Discovery Terminate (PADT)
packets to notify the other to end this Session.
For more information about PPPoE, refer to RFC 2516.
PPPoE server
The device allows you to configure PPPoE server which provide the following
functions:

394 CHAPTER 20: PPPOE CONFIGURATION
■ Dynamic IP address allocation.

■ Multiple authentication methods such as local authentication and
RADIUS/TACACS+. Along with ASPF and packet filter, it provides strong
defense for your network.
PPPoE server is applicable to campus networks where Ethernet is used for

connecting to the Internet. This however, requires installation of PPPoE client
dialup software on hosts.
PPPoE client
PPPoE is widely used in ADSL broadband access applications. Generally, a host
must be installed with PPPoE client dialing software in order to access the Internet
via ADSL. Currently, the PPPoE client, or PPPoE client dialup, is available on the
device to enable users to access the Internet without installing client dial-up
software on the hosts. Moreover, all the hosts on the same LAN can share the
same ADSL account.
Figure 99 Network diagram for PPPoE client
PPPoE Server
PPPoE Session ADSL Modem
PPPoE Client
Host A Host B
As shown in the above figure, PCs on the Ethernet are connected to the device
where PPPoE client runs. The data destined to the Internet first reaches the router
and is encapsulated in PPPoE there. After leaving the router, it passes through the
ADSL modem attached to the router and then the ADSL access server before
reaching the Internet. This can be done without PPPoE client dial-up software.
Configuring PPPoE PPPoE server can be configured on physical Ethernet interfaces or virtual Ethernet
Server interfaces generated by ADSL interface. For more information on the
configuration of PPPoE server on virtual Ethernet interface, refer to “ATM and DSL
Interface Configuration” on page 71.
Follow these steps to configure PPPoE server:

Configuring PPPoE Client 395

Create VT and enter its view interface virtual-template -
number
Configure PPP parameters Refer to “Configuring PPP” on Optional
(including authentication type, IP page 367
address negotiation, etc)
Enter the specified Ethernet interface ethernet Required
interface interface-number
Enable PPPoE on Ethernet pppoe-server bind Required
interface virtual-template number
Disabled by default
Configure the maximum number pppoe-server max-sessions Optional
of PPPoE sessions that can be remote-mac number
100 by default
created on a remote MAC
address
of PPPoE sessions that can be local-mac number
100 by default
created on a local MAC address
of PPPoE sessions that can be total number
4096 by default
created on the system
Configure authentication and For detailed information, refer to Optional
accounting on PPP users “AAA for PPP Users by a
HWTACACS Server” on page 1784.
Disable PPPoE Server to produce pppoe-server log-information Optional
PPP log information off
Enabled by default
n For a virtual template interface, if a static route is used, you are recommended to
specify the next hop rather than the outgoing interface. If the outgoing interface
must be specified, make sure that the physical interface bound in the virtual
template is effective to ensure normal transport of packets.
Configuring PPPoE
Client
Introduction to PPPoE PPPoE client configuration tasks include dialer interface configuration and PPPoE
Client session configuration.
Before configuring PPPoE session, you should first configure a dialer interface and
configure a dialer bundle on the interface. Each PPPoE session uniquely
corresponds to a dialer bundle and each dialer bundle uniquely corresponds to a
dialer interface. Thus, a PPPoE session can be created via a dialer interface.
PPPoE session can be configured on a physical Ethernet interface or a virtual

Ethernet (VE) interface created on an ADSL interface. When a device is connecting
to the Internet through an ADSL interface, it is necessary to configure PPPoE
session on the virtual Ethernet interface; when a device is connecting to an ADSL
Modem and then the Internet via an Ethernet interface, it is necessary to configure
the PPPoE session on the Ethernet interface.

For more information on the configuration of PPPoE session on virtual Ethernet

interface, refer to the relevant part of PPPoEoA configuration in “ATM and DSL
Interface Configuration” on page 71 in Access Manual.
Configuration Procedure Follow these steps to configure PPPoE client:

Configure dialer rule dialer-rule dialer-group Required
{ protocol-name { permit | deny } | acl
acl-number }
Create a dialer interface interface dialer number Required
Create a dialer user dialer user username Required
Configure IP address of the ip address { address mask | Required
interface ppp-negotiate }
Configure dialer bundle of dialer bundle bundle-number Required
the interface
Configure dialer group of the dialer-group group-number Required
interface
Enter Ethernet interface view interface ethernet interface-number -
Create a PPPoE session and pppoe-client dial-bundle-number Required
specify the dialer bundle for number [ no-hostuniq ]
the session [ idle-timeout seconds
[ queue-length packets ] ]
n Depending on your requirement, you may need to configure PPP authentication

etc on dialer interface. For detailed description on how to configure a dialer
interface, refer to “DCC Configuration” on page 153.
Resetting/Deleting a Introduction to resetting/deleting a PPPoE session

PPPoE Session The device supports two kinds of PPPoE connection mode: permanent on-line
mode and packet triggering mode.
■ Permanent on-line mode: When the physical line is up, the device will quickly
initiate PPPoE call to create a PPPoE session. The PPPoE session will always exist
unless the user deletes it.
■ Packet triggering mode: When the physical line is up, the device will not
immediately initiate PPPoE call. Only when there is data transmission
requirement will the router initiate PPPoE call to create a PPPoE session. If the
free time of a PPPoE link exceeds the value set by user, the router will
automatically terminate the PPPoE session.
Resetting/deleting a PPPoE session

Follow these steps to reset/delete a PPPoE session:

Displaying and Maintaining PPPoE 397

Terminate a PPPoE session at reset pppoe-client { all | In user view
the client end and recreate the dial-bundle-number number }
session later
Terminate a PPPoE session at reset pppoe-server { all | interface
the server end interface-type interface-number |
virtual-template number }
Terminate a PPPoE session at undo pppoe-client In Ethernet interface

the client end and never dial-bundle-number number view or virtual
recreate it again Ethernet interface
view
Displaying and
Maintaining PPPoE To do... Use the command... Remarks
Display statistics and state display pppoe-server session { all Available in any view
information about PPPoE | packet }
server sessions.
Display statistics and state display pppoe-client session Available in any view
information about PPPoE { packet | summary }
client sessions. [ dial-bundle-number number ]
PPPoE Configuration
Example
PPPoE Server Network requirements

Configuration Example In Figure 100, the hosts, acting as PPPoE client, access the Internet through the
router. The router acts as the PPPoE server, performing local authentication and
assigning IP address for the users through address pool.
Network diagram
The router is connected to the Ethernet through the interface Ethernet 1/0 and the
Internet through Serial 2/0.
Figure 100 PPPoE network diagram
Host A
Router
Eth 1/ 0 S2 / 0
Internet
Host B
# Add a PPPoE user

[Sysname] local-user user1
[Sysname-luser-user1] password simple pass1
[Sysname-luser-user1] service-type ppp
[Sysname-luser-user1] quit
# Configure PPPoE parameters on the router:
[Sysname] interface ethernet 1/0

[Sysname-Ethernet1/0] pppoe-server bind virtual-template 1
[Sysname-Ethernet1/0] quit
# Configure virtual-template parameters on the router:
[Sysname] interface virtual-template 1

[Sysname-Virtual-Template1] ppp authentication-mode chap domain system
[Sysname-Virtual-Template1] ppp chap user user1
[Sysname-Virtual-Template1] remote address pool 1
[Sysname-Virtual-Template1] ip address 1.1.1.1 255.0.0.0
[Sysname-Virtual-Template1] quit
[Sysname] domain system

[Sysname-isp-system] authentication ppp local
# Add a local IP address pool containing nine IP addresses.
[Sysname-isp-system] ip pool 1 1.1.1.2 1.1.1.10
After these configurations, you should then install a PPPoE client software on each
host, and configure a username and a password (in this case, user1 and pass1,
respectively). As such, the hosts can run PPPoE and can access the Internet
through the router.
If you have configured radius-scheme or hwtacacs-scheme using the

authentication ppp command, you will need to configure RADIUS/HWTACACS
to enable the system to perform AAA. For detailed configuration procedures, refer
to “AAA/RADIUS/HWTACACS Configuration” on page 1751.
PPPoE Client Network requirements

Configuration Example Router A and Router B are connected to each other by interface Ethernet 1/0.
Router A authenticates Router B using PAP or CHAP.
Network diagram
Figure 101 Network diagram for PPPoE client
PPPoE Server PPPoE Client
Eth 1/ 0 Eth1/ 0
Router A Router B

1 PAP authentication:
a Configure Router A as PPPoE server
# Add a PPPoE user.
# Configure the parameters of the virtual template.

[RouterA-Virtual-Template1] ppp authentication-mode pap
[RouterA-Virtual-Template1] remote address 1.1.1.2
# Configure PPPoE server.

[RouterA-Ethernet1/0] pppoe-server bind virtual-template 1
b Configure Router B as PPPoE client
[RouterB-Dialer1] dialer user user2
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] ppp pap local-user user2 password simple hello
# Configure PPPoE session.

[RouterB-Ethernet1/0] pppoe-client dial-bundle-number 1
2 CHAP authentication:
a Configure Router A as PPPoE server
# Add a PPPoE user.

[RouterA-Virtual-Template1] ppp authentication-mode chap
[RouterA-Virtual-Template1] ppp chap user user1


[RouterA-Virtual-Template1] remote address 1.1.1.2
# Configure PPPoE server.

[RouterA-Ethernet1/0] pppoe-server bind virtual-template 1
b Configure Router B as PPPoE client
[RouterB-Dialer1] dialer user user2
[RouterB-Dialer1] ip address ppp-negotiate
[RouterB-Dialer1] ppp chap user user2
[RouterB-luser-user1] password simple hello
# Configure a PPPoE session.

[RouterB-Ethernet1/0] pppoe-client dial-bundle-number 1
Connecting a LAN to the Network requirements

Internet via ADSL ■ PCs in a LAN access the Internet through Router A, which is connected in
Modem permanent on-line mode to the DSLAM through an ADSL modem.
■ The username and password of the ADSL account are user1 and 123456
respectively.
■ Enable the PPPoE client function on Router A, allowing the hosts on the LAN to
access the Internet without PPPoE client software.
■ Router B is operating as PPPoE server. It is connected to the DSLAM through
interface atm 2/0, providing RADIUS authentication and accounting.

Network diagram
Figure 102 Connect a LAN to the Internet through ADSL
DSLAM Router B
ATM 1/ 0 PPPoE Server
Modem
Eth 1/ 1
192. 168. 1. 1/ 24
Router A PPPoE Client
Eth1/ 0
Host A Host B Host C
1 Configure Router A as PPPoE client
# Configure the dialer interface.
[RouterA-Dialer1] ip address ppp-negotiate
[RouterA-Dialer1] ppp pap local-user user1 password cipher 123456

[RouterA-Ethernet2/0] pppoe-client dial-bundle-number 1
# Configure the LAN interface and the default route.

[RouterA] ip route-static 0.0.0.0 0 dialer 1
If the IP addresses of the PCs in the LAN are private addresses, you need to
configure NAT (Network Address Translation) on the device. The NAT
configuration will not be elaborated here. For details, refer to “NAT-PT
2 Configure Router B as PPPoE server

# Add a PPPoE user
[RouterB-luser-user1] password simple 123456
# Configure the ATM interface.
[RouterB] interface atm 1/0

[RouterB-Atm1/0] pvc 0/32
[RouterB-atm-pvc-Atm1/0-0/32] map bridge virtual-ethernet 1
[RouterB-atm-pvc-Atm1/0-0/32] quit
[RouterB-Atm1/0] quit
# Enable PPPoE server on the virtual Ethernet interface.
[RouterB] interface virtual-ethernet 1

[RouterB-Virtual-Ethernet1] pppoe-server bind virtual-template 1
[RouterB-Virtual-Ethernet1] mac-address 0022-0022-00c1
[RouterB-Virtual-Ethernet1] quit

[RouterB-Virtual-Template1] ppp authentication-mode pap domain system
[RouterB-Virtual-Template1] remote address pool 1
# Apply RADIUS authentication to the domain users.

[RouterB-isp-system] authentication ppp radius-scheme cams
# Add a local IP address pool that contains nine IP addresses.
[RouterB-isp-system] ip pool 1 1.1.1.2 1.1.1.10

# Configure RADIUS scheme
[RouterB] radius scheme cams

[RouterB-radius-cams] primary authentication 10.110.91.146 1812
[RouterB-radius-cams] primary accounting 10.110.91.146 1813
[RouterB-radius-cams] key authentication expert
[RouterB-radius-cams] key accounting expert
[RouterB-radius-cams] server-type extended
[RouterB-radius-cams] user-name-format with-domain
[RouterB-radius-cams] quit
For detailed configuration of RADIUS, refer to “Configuring RADIUS” on page

1769.

Using ADSL as Backup Network requirements

Line The router is connected to the network center via DDN dedicated line and ADSL,
where the ADSL is the backup of the DDN dedicated line. When a fault occurs to
the DDN dedicated line, the router can still initiate a PPPoE call and access the
network center via the ADSL. If there is no packet transmission on ADSL for 2
minutes, the PPPoE session will terminate automatically. Later on, if there are new
packets that need forwarding, the PPPoE session will be recreated.
Network diagram
Figure 103 Network diagram for using ADSL as backup line
Modem
Eth 1/0 ADSL
Router S2/ 0 DDN

Network Center
Configure the router:
# Configure a dialer interface.
[Router] interface dialer 1
[Router-Dialer1] dialer user user1
[Router-Dialer1] dialer-group 1
[Router-Dialer1] dialer bundle 1
[Router-Dialer1] ip address ppp-negotiate
[Router-Dialer1] interface ethernet 2/0

[Router-Ethernet2/0] pppoe-client dial-bundle-number 1 idle-timeout 120
# Configure the DDN interface Serial 2/0.

[Router-Serial2/0] standby interface dialer 1
# Configure the static route to the peer.
[Router] ip route 0.0.0.0 0 serial 1/0 preference 60

[Router] ip route 0.0.0.0 0 dialer 1 preference 70
Accessing the Internet Network requirements

through an ADSL The router has an ADSL interface ATM 1/0, through which it can access the
Interface Internet directly rather than via an ADSL modem.

Network diagram
Figure 104 Accessing the Internet through an ADSL interface
Internet
ATM1/ 0
Router
# Configure a dialer interface
[Router-Dialer1] dialer user mypppoe
[Router-Dialer1] dialer bundle 1
# Configure a VE interface
[Router-Dialer1] interface virtual-ethernet 1

[Router-Virtual-Ethernet1] mac 0001-0002-0003
[Router-Virtual-Ethernet1] quit
[Router]interface atm 1/0.1
[Router-atm1/0.1]pvc to_adsl_a 0/60
[Router-atm-pvc-atm1/0.1-0/60-to_adsl_a] map bridge virtual-ethernet 1
[Router-atm-pvc-atm1/0.1-0/60-to_adsl_a] quit
[Router-atm1/0.1] quit
[Router] interface virtual-ethernet 1

[Router-Virtual-Ethernet1] pppoe-client dial-bundle-number 1 idle-timeout 120
[Router-Virtual-Ethernet1] quit
# Configure a default route.
[Router]ip route-static 0.0.0.0 0.0.0.0 dialer 1

BRIDGING CONFIGURATION
21
When configuring bridging functionalities, go to the following sections for the
information you are interested in:
■ “Bridging Overview” on page 405
■ “Bridging Configuration Task List” on page 409
■ “Displaying and Maintaining Bridging Configurations” on page 412
■ “Transparent Bridging Configuration Examples” on page 412
n Presently the devices support only transparent bridging, so this document provides
information about transparent bridging only.
Bridging Overview
Introduction to Bridging A bridge is a store-and-forward device that connects and transfers traffic between
local area network (LAN) segments at the data-link layer. In some small-sized
networks, especially those with dispersed distribution of users, the use of bridges
can reduce the network maintenance costs, without requiring the end users to
perform special configurations on the devices.
In applications, there are four major kinds of bridging technologies: transparent

bridging, source-route bridging (SRB), translational bridging, and source-route
translational bridging (SR/TLB).
Transparent bridging is used to bridge LAN segments of the same physical media
type, primarily in Ethernet environments. Typically, a transparent bridging device
keeps a bridge table, which contains mappings between destination MAC
addresses and outbound interfaces.
Presently the devices support the following transparent bridging features:
■ Bridging over Ethernet

■ Bridging over point-to-point (PPP) and high-level data link control (HDLC) links
■ Bridging over X.25 links
■ Bridging over frame relay (FR) links
■ Inter-VLAN transparent bridging
■ Routing and bridging are simultaneously supported
Major Functionalities of Maintaining the bridge table

Bridges A bridge relies on its bridge table to forward data. A bridge table consists two
parts: MAC address list and interface list. Once connected to a physical LAN

406 CHAPTER 21: BRIDGING CONFIGURATION
segment, a bridge listens to all Ethernet frames on the segments. When it receives
an Ethernet frame, it extracts the source MAC address of the frame and creates a
mapping entry between this MAC address and the interface on which the
Ethernet frame was received.
As shown in Figure 105, Hosts A, B, C and D are attached to two LAN segments,
of which LAN segment 1 is connected with bridge interface 1 while LAN segment
2 is connected with bridge interface 2. When Host A sends an Ethernet frame to
Host B, both bridge interface 1 and Host B receive this frame.
Figure 105 Host A sends an Ethernet frame to Host B on LAN segment 1

MAC address : 00 e0.fcbb .bbbb
MAC address : 00 e0.fcaa .aaaa
Host A Host B
Source address Destination address

00e0 .fcaa .aaaa 00e0. fcbb .bbbb
LAN segment 1
Bridge interface 1
Bridge
Bridge interface 2
LAN segment 2
Host C Host D
MAC address : 00 e0.fccc .cccc MAC address : 00 e0.fcdd .dddd
As the bridge receives the Ethernet frame on bridge interface 1, it determines that
Host A is attached to bridge interface 1 and creates a mapping between the MAC
address of Host A and bridge interface 1 in its bridge table, as shown in
Figure 106.
Figure 106 The bridge determines that Host A is attached to interface 1
MAC address : 00 e0.fcaa . aaaa MAC address : 00e0.fcbb .bbbb
Host A Host B

00e0.fcaa .aaaa 00e0.fcbb .bbbb
Bridge table LAN segment 1

MAC address Interface Bridge interface 1
00 e0. fcaa. aaaa 1
Bridge
Bridge interface 2
LAN segment 2
Host C Host D
MAC address : 00 e0.fccc . cccc MAC address : 00e0.fcdd .dddd

Bridging Overview 407
When Host B responds to Host B, the bridge also hears the Ethernet frame from
Host B. As the frame is received on bridge interface 1, the bridge determines that
Host B is also attached to bridge interface 1, and creates a mapping between the
MAC address of Host B and bridge interface 1 in its bridge table, as shown in
Figure 107.
Figure 107 The bridge determines that Host B is also attached to interface 1
MAC address : 00 e0.fcaa .aaaa MAC address: 00e0.fcbb .bbbb
Host A Host B
00 e0.fcbb . bbbb 00e0.fcaa . aaaa

00e 0. fcaa.aaaa 1
Bridge
00e 0. fcbb.bbbb 1
Bridge interface 2
LAN segment 2
Host C Host D
MAC address : 00 e0.fccc .cccc MAC address: 00e0.fcdd .dddd
Finally, the bridge obtains all the MAC-interface mappings (assume that all hosts
are in use), as shown in Figure 108.
Figure 108 The final bridge table
MAC address : 00 e0.fcaa .aaaa MAC address : 00e0.fcbb .bbbb
Host A Host B

00 e0.fcaa .aaaa 1
Bridge
00 e0.fcbb .bbbb 1
00 e0.fccc.cccc 2 Bridge interface 2
00 e0.fcdd .dddd 2
LAN segment 2
Host C Host D
MAC address : 00 e0.fccc .cccc MAC address : 00e0.fcdd .dddd

Forwarding and filtering

The bridge makes data forwarding or filtering decisions based on the following
scenarios:
■ When Host A sends an Ethernet frame to Host C, the bridge searches its bridge
table and finds out that Host C is attached to bridge interface 2, and forwards
the Ethernet frame out of bridge interface 2, as shown in Figure 109.
Figure 109 Forwarding
MAC address : 00e0.fcaa .aaaa MAC address : 00e0. fcbb . bbbb
Host A Host B

00e0 .fcaa. aaaa 00e0. fccc. cccc

00e0. fcaa. aaaa 1
Bridge
00e0. fcbb. bbbb 1
00e0.fccc . cccc 2 Bridge interface 2
00e0. fcdd. dddd 2
LAN segment 2
00e0 .fcaa .aaaa 00e0.fccc .cccc

Host C Host D
MAC address : 00e0.fccc .cccc MAC address : 00e 0. fcdd.dddd
■ When Host A sends an Ethernet frame to Host B, as Host B is on the same LAN
segment with Host A, the bridge filters the Ethernet frame instead of
forwarding it, as shown in Figure 110.
Figure 110 Filtering
MAC address : 00e0.fcaa .aaaa MAC address : 00e0.fcbb . bbbb
Host A Host B

00e0 .fcaa .aaaa 00 e0. fcbb. bbbb
LAN segment 1
Bridge table
00e 0.fcaa .aaaa 1
Bridge
00e 0.fcbb . bbbb 1
00e 0.fccc . cccc 2 Bridge interface 2
00e 0.fcdd .dddd 2

LAN segment 2
Host C Host D
MAC address : 00e0.fccc .cccc MAC address : 00e0.fcdd .dddd

Bridging Configuration Task List 409
■ When Host A sends an Ethernet frame to Host C, if the bridge does not find a
MAC-to-interface mapping about Host C in its bridge table, the bridge
forwards the Ethernet frame to all interfaces except the interface on which the
frame was received, as shown in Figure 111.
Figure 111 The proper MAC-to-interface mapping is not found in the bridge table
MAC address : 00 e0.fcaa . aaaa MAC address : 00 e0.fcbb.bbbb
Host A Host B
00 e0.fcaa . aaaa 00e0.fcbb .bbbb
LAN segment 1
Bridge table
00e0.fcaa .aaaa 1
Bridge
00e0. fcbb .bbbb 1
Bridge interface 2
LAN segment 2
Host C Host D
MAC address : 00 e0.fccc .cccc MAC address : 00 e0.fcdd .dddd
c CAUTION: When a bridge receives a broadcast or multicast frame, it forwards the

frame to all interfaces other than the receiving interface.
Bridging Complete these tasks to configure bridging:

Configuration Task
List Tasks Remarks
“Configuring Basic Bridging Functionalities” on page 409 Required
“Configuring Bridge Table Entries” on page 411 Optional
“Configuring Bridge Routing” on page 411 Optional
Configuring Basic
Bridging
Functionalities
n ■ When configuring transparent bridging over ATM, you need to enable

transmission and receiving of bridged frames on the PVC.
■ When configuring transparent bridging over PPP, you need to configure PPP on
the corresponding interface as the link layer protocol for interface
encapsulation.
■ When configuring transparent bridging over multilink PPP (MP), you need to
configure PPP on the corresponding interface as the link layer protocol for
interface encapsulation, create a virtual template interface and associate the
physical interface with the virtual template interface.

■ When configuring transparent bridging over FR, you need to configure FR on

the corresponding interface as the link layer protocol for interface
encapsulation, configure the FR interface type (optional, DTE by default) and
configure a virtual circuit. When establishing transparent bridging over FR, you
need to configure mappings between bridge addresses and data link
connection identifier (DLCI) addresses.
■ When configuring transparent bridging over X.25, you need to configure X.25
on the corresponding interface as the link layer protocol for interface
encapsulation and configure the work mode and datagram format of the
interface. When establishing transparent bridging over X.25, you need to
configure mappings between bridge addresses and X.25 addresses defined in
X.121.
■ When configuring transparent bridging HDLC, you need to configure HDLC as
the link layer protocol for interface encapsulation.
■ When configuring inter-VLAN transparent bridging, you need to configure the
encapsulation format of the Ethernet sub-interfaces and the corresponding
VLAN IDs. When establishing inter-VLAN transparent bridging, you need to add
the configured Ethernet sub-interfaces into a bridge set.
Follow these steps to configure basic bridging functionalities

Enable bridging bridge enable Required
Disabled by default
Enable a bridge set bridge bridge-set enable Required
No bridge set is enabled by default
interface-number
Add the current bridge-set bridge-set Required
interface into a bridge
An interface is not in any bridge
set
set by default.
An interface cannot be add into
two or more bridge sets
Configure an fr map bridge dlci broadcast Required for transparent bridging
FR-to-bridging mapping over FR
Configure an X.25 to x25 map bridge Required for transparent bridging
bridging mapping x121-address x.121-address over X.25
broadcast
Enable bridged traffic interface atm Required for transparent bridging
over a PVC { interface-number | over ATM
If you configure both the map
pvc { pvc-name [ vpi/vci ] |
bridge virtual-ethernet and
vpi/vci } map bridge-group commands,
only the map bridge
map bridge-group broadcast
virtual-ethernet takes effect.
For more information about ATM configuration, refer to “ATM and DSL Interface

Configuring Bridge Table Entries 411
Configuring Bridge Typically, a bridge dynamically creates and maintains a bridge table based on the
Table Entries correlations between the MAC addresses it learned and the corresponding
interfaces. The administrator, however, can manually configure some bridge table
entries, which will never get aged out.
The aging time of a dynamic bridge table entry refers to the lifetime of the entry
before it is deleted from the table. When the aging timer of a dynamic table entry
expires, the system deletes the entry from the table.
Follow these steps to configure a bridge table:

Enable dynamic address bridge bridge-set learning Optional
learning
Enabled by default
Configure a static bridge table bridge bridge-set Optional
entry mac-address mac-address
No static table entry is
{ deny | permit } [ dlsw |
configured by default
interface-number ]
Configure aging time of bridge aging-time seconds Optional
dynamic bridge table entries
Configuring Bridge Bridge routing provides a forward capability that combines bridging and routing.
Routing When data of a given protocol is exchanged between bridge interfaces, bridging
occurs; when data of a given protocol is exchanged between a bridge set and a
non-bridge-set network, the protocol can be routed. Before the built-in routing
and bridging functionalities are not activated, all protocol data can only be
bridged. With the built-in routing and bridging functionalities activated,
datagrams of the specified protocol can be either bridged or routed, and
switching between bridging and routing can be implemented flexibly through
configuration commands.
A bridge-template interface is a virtual route-selecting interface, on which various

network layer properties can be configured. By configuring a bridge-template
interface, you can connect the corresponding bridge set to a routed network. A
bridge set can have only one bridge-template interface. The number of a
bridge-template interface is the number of the bridge set it represents.
By default, if a bridge set contains Ethernet interfaces, its bridge-template

interface will use the MAC address of a random Ethernet interface. If the bridge
set contains no Ethernet interfaces, its bridge-template interface will use the
system default MAC address, of which the first 5 bytes depends on the device
model and the last byte is the number of the ridge set.
If bridge sets by the same bridge set number are enabled on two or more devices
and a bridge-template interface is created for each of these bridges sets while no
Ethernet interfaces have been added into these bridge sets, these bridge-template
interfaces will use exactly the same default MAC address. This will cause MAC
address conflict. To avoid this situation, you can different MAC addresses on
different bridge-template interfaces.

Follow these steps to bridge routing:

Enable bridge routing bridge routing-enable Required
Disabled by default
Create a bridge-template interface bridge-template Required
interface and enter bridge-set
No bridge-template interface
bridge-template interface
view
Configure a MAC address for mac-address mac-address Optional
the bridge-template interface
Configure routing or bridging bridge bridge-set routing Optional
of the specified network layer { ip | ipx }
By default, routing if network
protocol(s) on bridge set
bridge bridge-set bridging layer protocols is disabled
{ ip | ipx | others }
Displaying and
Maintaining Bridging To do... Use the command... Remarks
Configurations View bridge set information display bridge information Available in any
[ bridge-set bridge-set ] view
View the statistics information display interface bridge-template Available in any
of a virtual bridge-template [interface-number] view
interface
View bridge table information display bridge address-table Available in any
[ bridge-set bridge-set | dlsw | view
interface-number | mac mac-address]
[ dynamic | static ]
View the statistics information display bridge traffic [ bridge-set Available in any
of bridged traffic bridge-set | dlsw | interface view
Clear bridge table entries reset bridge address-table Available in user
[ bridge-set bridge-set | dlsw | view
interface-number ]
Clear the statistics reset bridge traffic [ bridge-set Available in user
information of bridged traffic bridge-set | dlsw | interface view
Transparent Bridging
Configuration
Examples
Transparent Bridging Network requirements

over ATM As shown in Figure 112, LAN 1 and LAN 2 are attached to Router A and Router B
respectively, which are interconnected through their respective ATM interfaces.
Configure the two routers to enable transparent bridging between the two LAN
segments.

Network diagram
Figure 112 Network diagram for transparent bridging over ATM configuration
LAN 1
LAN 2
Eth1/0 ATM5/0 ATM5/0 Eth1/0
Router A Router B
[RouterA-Ethernet1/0] interface atm 5/0
[RouterA-Atm5/0] pvc 32/50
[RouterA-atm-pvc-Atm5/0-32/50] map bridge-group broadcast
[RouterA-atm-pvc-Atm5/0-32/50] quit
[RouterA-Atm5/0] bridge-set 1
[RouterB ]bridge 1 enable
[RouterB-Ethernet1/0] interface atm 5/0
[RouterB-Atm5/0] pvc 32/50
[RouterB-atm-pvc-Atm5/0-32/50] map bridge-group broadcast
[RouterB-atm-pvc-Atm5/0-32/50] quit
[RouterB-Atm5/0] bridge-set 1

over PPP As shown in Figure 113, LAN 1 and LAN 2 are attached to Router A and Router B
respectively, which are interconnected over PPP. Configure the two routers to
enable transparent bridging between the two LAN segments.
Network diagram
Figure 113 Network diagram for transparent bridging over PPP configuration
LAN 1
LAN 2
Eth 1 /0 S2/0 S2 /0 Eth 1/0
Router A Router B


[RouterA-Serial2/0] bridge-set 1
[RouterB-Serial2/0] bridge-set 1

over MP As shown in Figure 114, LAN 1 and LAN 2 are attached to Router A and Router B
respectively, which are interconnected over multilink PPP. Configure the two
routers to enable transparent bridging between the two LAN segments.
Network diagram
Figure 114 Network diagram for transparent bridging over MP configuration
S2/1 S2 /1
LAN 1
LAN 2
Eth1 /0 Eth1/0
S2/0 S2/0
Router A Router B
[RouterA-virtual-template1] bridge-set 1
[RouterA-virtual-template1] quit


[RouterB-virtual-template1] bridge-set 1
[RouterB-virtual-template1] quit

over FR As shown in Figure 115, LAN 1 and LAN 2 are attached to Router A and Router B
respectively, which are interconnected over FR. Configure the two routers to
Network diagram
Figure 115 Network diagram for transparent bridging over FR configuration

LAN 1
S2 /0
LAN 2
Eth1 /0 Eth1/0
S 2/0
Router A Router B
[RouterA-Serial2/0] fr map bridge 50 broadcast


[RouterB-Serial2/0] fr map bridge 50 broadcast

X.25 As shown in Figure 116, LAN 1 and LAN 2 are attached to Router A and Router B
respectively, which are interconnected over X.25. Configure the two routers to
Network diagram
Figure 116 Network diagram for transparent bridging over X.25 configuration
LAN 1
S2 /0
LAN 2
Eth1 /0 Eth1/0
S 2/0
Router A Router B
[RouterA-Serial2/0] link-protocol x25 dce
[RouterA-Serial2/0] x25 map bridge x121-address 200 broadcast
[RouterB-Serial2/0] link-protocol x25
[RouterB-Serial2/0] x25 map bridge x121-address 100 broadcast

over HDLC As shown in Figure 117, LAN 1 and LAN 2 are attached to Router A and Router B
respectively, which are interconnected over an HDLC link. Configure the two
routers to enable transparent bridging between the two LAN segments.

Network diagram
Figure 117 Network diagram for transparent bridging over HDLC configuration
LAN 1
S2 /0
LAN 2
Eth1 /0 Eth1/0
S 2/0
Router A Router B
[RouterA-Serial2/0] link-protocol hdlc
[RouterB-Serial2/0] link-protocol hdlc
Inter-VLAN Transparent Network requirements

Bridging As shown in Figure 118, Router A and Router B are interconnected through a
network cable. Configure the bridging functionality on the sub-interfaces of the
routers to bridge traffic between the two bridges constituted with the two routers.
Network diagram
Figure 118 Network diagram for inter-VLAN transparent bridging configuration
Eth1 /0 Eth1/0
Eth1/2 Eth1/2
Router A Router B
Eth1/1 Eth1/1

[RouterA-Ethernet1/2.1] quit
[RouterB] interface ethernet 1/2.1
[RouterB-Ethernet1/2.1] vlan-type dot1q vid 1
[RouterB-Ethernet1/2.1] bridge-set 1
[RouterB-Ethernet1/2.1] quit
[RouterB] interface ethernet 1/2.2
[RouterB-Ethernet1/2.2] vlan-type dot1q vid 2
[RouterB-Ethernet1/2.2] bridge-set 2
Bridging with FR Network requirements

Sub-Interface Support As shown in Figure 119, Router A and Router B are interconnected through a FR
link. Enable bridging on the FR sub-interfaces Serial2/0.1 and Serial2/0.2 so that
traffic between Host A and Host B can be bridged through bridge set 1 and traffic
between Host C and Host D can be bridged through bridge set 2.
In this example, Router B is a DCE device.

Network diagram
Figure 119 Network diagram for bridging with FR sub-interface support
Host A Host B
Eth1 /0 Eth1/0
S2/0 S2/0
Router A Router B
Eth1/1 Eth1/1
Host C Host D
[RouterA] interface serial 2/0.1
[RouterA-Serial2/0.1] fr map bridge 50 broadcast
[RouterA-Serial2/0.1] bridge-set 1
[RouterA-Serial2/0.1] quit
[RouterA] interface serial 2/0.2
[RouterA-Serial2/0.2] fr map bridge 60 broadcast
[RouterA-Serial2/0.2] bridge-set 2

[RouterB] interface serial 2/0.1
[RouterB-Serial2/0.1] fr map bridge 50 broadcast
[RouterB-Serial2/0.1] bridge-set 1
[RouterB-Serial2/0.1] quit
[RouterB] interface serial 2/0.2
[RouterB-Serial2/0.2] fr map bridge 60 broadcast
[RouterB-Serial2/0.2] bridge-set 2
c CAUTION: In this example, the sub-interfaces can also be configured as

point-to-point (P2P) FR sub-interfaces. In this case, it is not necessary to use the fr
map command on point-to-point FR sub-interfaces; however, you need to
configure the same DLCI at both the DCE and DTE sides by using the fr dlci
command. This is an alternative method of configuring bridging over FR.
Bridge Routing Network requirements

As shown in Figure 120, three host PCs are attached to Ethernet1/0, Ethernet1/1
and Ethernet1/2 of a router respectively. Configure a bridge set and enable routing
of traffic passing each interface in the bridge set.
Network diagram
Figure 120 Network diagram for bridge routing configuration
Bridge -Template 1
1.1.1.1/16
Eth 1/0 Eth1/2
2.1 .1.1/ 16
Eth 1/1
Bridge set 1
[Router] bridge enable
[Router] bridge routing-enable
[Router] bridge 1 enable
[Router] bridge 1 routing ip
[Router-Ethernet1/0] bridge-set 1
[Router-Ethernet1/1] bridge-set 1
[Router] interface bridge-template 1
[Router-Bridge-template1] ip address 1.1.1.1 255.255.0.0
[Router-Bridge-template1] quit

ISDN CONFIGURATION
22
When configuring ISDN, go to these sections for information you are interested in:
■ “Introduction to ISDN” on page 421
■ “Configuring ISDN” on page 422
■ “Displaying and Maintaining ISDN” on page 434
■ “ISDN Configuration Example” on page 434
Introduction to ISDN Derived from integrated digital network (IDN), integrated services digital network
(ISDN), provides end-to-end digital connectivity and supports an extensive ranges
of services, covering both voice and non-voice services.
ISDN furnishes a finite set of standard multi-purpose user-network interfaces

(UNIs). In ITU-T I.412 recommendation, two types of UNIs are specified: basic rate
interface (BRI) with bandwidth of 2B + D and primary rate interface (PRI) with
Bandwidth of 30B + D or 23B + D. Where,
■ B channel is a user channel, used to transmit such user information as voice

and data with a transmission rate of 64 kbit/s.
■ D channel is a control channel, which transmits the public channel signaling.
These signals are used to control the calls on the B channel of the same
interface. The rate of D channel is 16 kbit/s (BRI) or 64 kbit/s (PRI). The ITU-T
Q.921 is a data link layer protocol of D channel. It defines the rule for Layer 2
information interchange via D channel from the user to a network interface
and supports the access of a layer 3 entity. The ITU-T Q.931 is a network layer
protocol of D channel. It provides a measure for creating, maintaining and
terminating network connection between communication application entities.
Call control (CC) is a further encapsulation of Q.931, which forwards the
message from the network side to CC for CC to perform information
interchange with higher layer applications such as DCC.
Figure 121 ISDN D channel protocol stack
CC
Layer 3
Q.931
Layer 2 Q.921 LAPD
Layer 1 BRI PRI
The ISDN protocols proposed by ITU-T provides different services in different areas,
forming the ISDN protocols that are suitable for different regions, such as NTT

422 CHAPTER 22: ISDN CONFIGURATION
(Nippon Telegraph and Telephone Corporation) in Japan, ETSI (European

Telecommunications Standards Institute) in Europe, NI (National ISDN), AT&T 5ESS,
and ANSI (American National Standard Institute) in North America. Besides the
default DSS1 ISDN protocol, the router supports the basic calling function of NTT,
ETSI, ATT, ANSI, NI, NI2, and Q.SIG protocols, but does not support the
supplementary functions or network-side functions of these protocols.
NI protocol used in North America is only applied to BRI interface. The ISDN
network uses SPID (Service Profile Identification) as the ID of different services, and
the switch provides the corresponding service to the terminal user according to the
SPID. Each B channel corresponds to a SPID. Only after having employed the SPID
to perform the SPID handshake interaction, can the user proceed with normal
calling and disconnection process. Therefore, after the Q.921 establishes link
successfully and before the Q.931 calling processing starts, the user needs to
obtain SPID to interact with the switch to perform the Layer 3 (Q.931)
initialization, then he can start normal calling and disconnect process., otherwise,
the calling will fail.
By far, there are three ways to obtain the SPID on one BRI interface over the ISDN
in North America.
■ Manually input the SPID consisting of 9 to 20 digits.

■ 14-digit SPID (Generic SPID Format). The former 10 digits are input by the user,
and the latter 4 digits can only be “0101”.
■ Allocate by SPCS (Stored Program Control Switching System) through
Automated SPID Selection Regulation.
The former two ways to obtain SPID are regarded as static configuration methods,
and the third one is taken as dynamic negotiation method. If the user does not
specify a SPID in static method, the system will adopt dynamic method by default.
Configuring ISDN
Configuring ISDN BRI Follow these steps to configure ISDN BRI:

Enter specified ISDN BRI interface interface-type -
Configure the BRI interface to isdn link-mode p2p Optional
operate in the point-to-point
By default, a BRI interface
mode
operates in the
point-to-multipoint mode, in
which a BRI interface operating
on the network side can have
multiple end devices attached to
it.
Set ISDN protocol type isdn protocol-type Optional
protocol
The ISDN protocol on the BRI
interface is DSS1 protocol by
default.


Set ISDN protocol mode isdn protocol-mode Optional
mode
An ISDN BRI interface operates in
user mode by default.
Currently, only BSV board can
operate on the network side.
Configure the negotiation Refer to “ISDN Optional
parameters of ISDN Layer 3 Configuration” on page
protocol 421
Configure the SPID Refer to “ISDN Optional
parameters about ISDN NI Configuration” on page
protocol 421
Configure the called number Refer to “ISDN Optional
and subaddress to be Configuration” on page
checked during a incoming 421
call
Configure to send calling Refer to “ISDN Optional
number during an outgoing Configuration” on page
call 421
Set the local management Refer to “ISDN Optional
ISDN B channel Configuration” on page
421
Configure ISDN B channel Refer to “ISDN Optional
selection mode Configuration” on page
421
Configure statistics about Refer to “ISDN Optional
ISDN message Configuration” on page
receiving/sending 421
Configure the allowed Refer to “ISDN Optional
incoming calling number Configuration” on page
421
Configure TEI treatment on Refer to “ISDN Optional
the BRI interface Configuration” on page
421
Configure ISDN BRI leased Refer to “ISDN Optional
line Configuration” on page
421
Configure permanent link Refer to “ISDN Optional
function on ISDN BRI link Configuration” on page
layer 421
Configuring ISDN PRI Follow these steps to configure ISDN PRI:

Enter specified ISDN PRI interface interface interface-type -
Set ISDN protocol type isdn protocol-type Optional
protocol
The ISDN protocol on the
PRI interface is DSS1
protocol by default.


Set ISDN protocol mode isdn protocol-mode mode Optional
An ISDN PRI interface
operates in user mode by
default.
Configure the negotiation Refer to “ISDN Optional
parameters of ISDN Layer 3 Configuration” on page
protocol 421
Configure the called number and Refer to “ISDN Optional
subaddress to be checked during a Configuration” on page
incoming call 421
Configure to send calling number Refer to “ISDN Optional
during an outgoing call Configuration” on page
421
Set the local management ISDN B Refer to “ISDN Optional
channel Configuration” on page
421
Configure ISDN B channel selection Refer to “ISDN Optional
mode Configuration” on page
421
Configure ISDN PRI sliding window Refer to “ISDN Optional
size Configuration” on page
421
Configure statistics about ISDN Refer to “ISDN Optional
message receiving/sending Configuration” on page
421
Configure the allowed incoming Refer to “ISDN Optional
calling number Configuration” on page
421
Configuring the Follow these steps to configure the negotiation parameters of ISDN layer 3
Negotiation Parameters protocol:
of ISDN Layer 3 Protocol
interface-number
Set the length of the call isdn crlength Optional
reference adopted when the call-reference-length
The call reference length is
ISDN interface initiates a call
two bytes for CE1 PRI and
CT1 PRI interfaces and one
byte for BRI interfaces by
default.
Configure the router to switch isdn ignore connect-ack Optional
the ISDN protocol state to
By default, in the event that
ACTIVE to start the data and
the router is communicating
voice service communications
with an exchange, the ISDN
after sending a CONNECT
protocol must wait for the
message without having to
CONNECT ACK in response to
wait for a CONNECT ACK
the CONNECT message
message.
before it can switch to the
ACTIVE state to start the data
and voice service
communications.


Configure to disable ISDN to isdn ignore hlc Optional
carry the HLC information
By default, HLC information
element in SETUP messages
element is carried in SETUP
when placing voice calls
messages when placing voice
call.
Configure to disable ISDN to isdn ignore llc Optional
carry the LLC information
By default, LLC information
element in SETUP messages
element is carried in SETUP
when placing voice calls
messages when placing voice
call.
Configure the ISDN protocol isdn ignore Optional
to ignore the processing on sending-complete
As for the data exchange
the Sending Complete [ incoming | outgoing ]
performed between a router
Information Element
and an ISDN switch, the
default is as follows.
For an incoming call, the
router checks the received
Setup messages for the
Sending Complete
Information Element to
determine whether or not the
number is received
completely. If a Setup
message does contain the
Sending Complete
Information Element, the
number is not received
completely.
For outgoing calls, a Setup
message containing the
Sending Complete
Information Element indicates
that the number is sent
completely.
Configure the time-interval of isdn l3-timer timer-name Optional
ISDN Layer 3 time-interval
By default, configure the
duration of an ISDN L3 timer
as (in seconds):
T301 defaults to 240
T302 defaults to 15
T303 defaults to 4
T304 defaults to 30
T305 defaults to 30
T308 defaults to 4
T309 defaults to 90
T310 defaults to 40
T313 defaults to 4
T316 defaults to 120
T322 defaults to 4


Set the type and code scheme isdn number-property Optional
of calling or called numbers in number-property [ calling |
By default, the system selects
incoming or outgoing ISDN called ] [ in | out ]
ISDN number type and code
calls
scheme depending on upper
layer service. For detailed
information, refer to Table 9.
Set the called number of ISDN isdn overlap-sending Optional
interface to send in overlap [digits ]
In “full-sending” mode, all
mode. In this mode, the digits
the digits of each called
of each called number will be
number will be collected and
sent separately and the
sent at a time by default.
number of the digits sent
each time can be sent by the
user.
Table 9 Types and code schemes of ISDN numbers
Field (Bit) value

Type Code scheme
Protocol 8 7 6 5 4 3 2 1 Definition
Field (Bit) value
Type Code scheme
ANSI 0 0 0 User-specified
0 1 0 National network identification
0 1 1 International network identification
0 0 0 0 Unknown/user-specified
0 0 0 1 Carrier identification code
0 0 1 1 Data network identification code (ITU-T
Recommendation X.121)
AT&T 0 0 0 Unknown
0 0 1 International number
0 1 0 National number
1 0 0 Subscriber number
0 0 0 0 Unknown
0 0 0 1 ISDN/telephony numbering loan
(Recommendation E.164/E.163)
1 0 0 1 Private numbering plan

Field (Bit) value

Type Code scheme
DSS1 0 0 0 Unknown
0 1 1 Network specific number
1 1 0 Abbreviated number
1 1 1 Reserved for extension
0 0 0 0 Unknown
0 0 0 1 ISDN/telephony numbering plan
(Recommendation E.164)
0 0 1 1 Data numbering plan (Recommendation X.121)
0 1 0 0 Telex numbering plan (Recommendation F.69)
1 0 0 0 National standard numbering plan
1 1 1 1 Reserved for extension
ETSI 0 0 0 Unknown
1 1 0 Abbreviated number
1 1 1 Reserved for extension
0 0 0 0 Unknown
0 0 1 1 Data numbering plan (Recommendation X.121)
0 1 0 0 Telex numbering plan (Recommendation F.69)
1 0 0 0 National standard numbering plan
1 1 1 1 Reserved for extension
NI 0 0 0 0 0 0 0 Unknown number in Unknown numbering plan
0 0 1 0 0 0 1 International number in ISDN numbering plan
(Rec. E.164)
0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec.
E.164)
0 1 1 1 0 0 1 Network specific number in private numbering
plan
1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan
(Rec. E.164)
1 1 0 1 0 0 1 Abbreviated number in private numbering plan

Field (Bit) value

Type Code scheme
NTT 0 0 0 Unknown
0 0 0 0 Unknown
QSIG 0 0 0 0 0 0 0 Unknown number in Unknown numbering plan
0 0 0 0 0 0 1 Unknown number in ISDN/Telephony numbering
plan (ITU-T Rec.E.164/E.163)
0 0 1 0 0 0 1 International number in ISDN/Telephony
numbering plan (ITU-T Rec.E.164/E.163)
0 1 0 0 0 0 1 National number in ISDN/Telephony numbering
plan (ITU-T Rec.E.164/E.163)
0 1 1 0 0 0 1 Subscriber number in ISDN/Telephony
numbering plan (ITU-T Rec.E.164/E.163)
0 0 0 1 0 0 1 Unknown number in private numbering plan
0 0 1 1 0 0 1 Level 2 regional number in private numbering
plan
plan
0 1 1 1 0 0 1 PISN specific number in private numbering plan
plan
n The undefined bits in all the protocols are reserved for other purposes.
Configuring the SPID of You may configure SPID on the BRI interfaces that are running the ISDN NI
the ISDN NI Protocol protocol.
Follow these steps to configure the SPID parameters of the ISDN NI protocol:

interface-number


Set the SPID Set the SPID value of B1 isdn spid1 spid [ ldn ] Required
types on the on the BRI interface
isdn spid2 spid [ ldn ] SPID is obtained via
BRI interface adopting NI protocol.
dynamic negotiation by
adopting NI
Set the SPID value of B2 default.
protocol as
on the BRI interface
NIT, static and
adopting NI protocol.
dynamic.
When Enable the SPID isdn spid auto_trigger Optional
configuring, negotiation on the BRI
A BRI interface does not
only one of interface adopting NI
originate a SPID
them can be protocol.
negotiation request
available once.
unless triggered by a call
by default.
On the BRI interface isdn spid nit NIT does not apply on
adopting NI protocol, BRI interfaces by default.
set the processing
mode of SPID to NIT,
i.e., non-initializing
terminal mode.
Set the service type supported by SPID isdn spid service SPID needs to support
[ audio | data | speech ] speech and data service
simultaneously.
Set the time-interval of timer TSPID on isdn spid timer seconds Optional
the BRI interface adopting NI protocol.
The time-interval of
timer TSPID is 30
seconds by default.
Set the number of times of resending isdn spid resend times Optional
message on the BRI interface adopting NI
Once by default.
protocol.
Setting the Called If a called number or subaddress is specified, the system will deny an incoming
Number or Sub-Address digital call if the calling party sends a wrong called number or subaddress or does
to Be Checked During a not send at all.
Digital Incoming Call
Follow these steps to configure the called number or sub-address to be checked
during a digital incoming call:

Enter specified interface interface interface-type -
Set the called number or isdn check-called-number Optional
sub-address to be checked called-party-number
No called number or sub-address
during a digital incoming [ :subaddress ]
is configured by default. When
call
configuring this command, the
called number and subaddress
are separated with string "space:
space".
Configuring to Send The purpose for setting this command is to reduce cost in some networks that
Calling Number During charge the calling side by providing advantageous accounting numbers for users.
an Outgoing Call
Follow these steps to configure to send calling number during an outgoing call:


Enter specifies interface view interface interface-type -
interface-number
Configure to send calling isdn calling calling-number Optional
number during an outgoing
Calling number is not sent by
call
default.
Setting the Local Configured with isdn bch-local-manage command, the router operates in local
Management ISDN B B-channel management mode to select available B channels for calls. Despite this,
Channel the connected exchange has higher priority in B channel selection. If the B channel
the router selected for a call is different from the one indicated by the exchange,
the one indicated by the exchange is used for communication.
Configured with the isdn bch-local-manage exclusive command, the router

operates in exclusive local B-channel management mode. In this mode, the B
channel selected by the router must be adopted for communication. In the
Channel ID information element of the call Setup message sent for a call, the
router indicates that the B channel is mandatory and unchangeable. If the
connected exchange indicates a B channel different from the one selected by the
router, call failure occurs.
Follow these steps to set the local management ISDN B channel:

Set the local isdn bch-local-manage Local ISDN B channel management is
management ISDN B [ exclusive ] not configured and the remote end is
channel responsible for B channel
management by default.
Exclusive local management mode for
ISDN B channels is applied to network
side for the device. If the device
serves as user side connected with
ISDN switch, and the B channel
indicated by the exchange is
inconsistent with the one required by
the local end, call failure occurs.
Configuring ISDN B Follow these steps to configure ISDN B channel selection mode:
Channel Selection Mode
interview interface-number


Configure ISDN B channel isdn bch-select-way Optional
ascending or descending { ascending | descending }
ISDN B channel ascending selection
selection mode
mode is adopted by default. When
the switch manages B channel, this
command takes no effect. (For
more information about
configuring local management
ISDN B channel, refer to “ISDN
Configuration” on page 421).
Configuring the Sliding Follow these steps to configure the size of the sliding window on the PRI interface:
Window Size on the PRI
interface-number
Configure the sliding window isdn pri-slipwnd-size Optional
size on the PRI interface or { window-size | default }
The sliding window on the PRI
restore the default.
interface defaults to 7.
Configuring Statistics Follow these steps to configure the statistics about ISDN message
About ISDN Message receiving/sending:
Receiving/Sending
interface-number
Set ISDN to start the statistics of isdn statistics start Required
message receiving/sending
Set ISDN to stop the statistics of isdn statistics stop Required
message receiving/sending
Display ISDN statistics isdn statistics display [ flow ] Required
Set ISDN to continue the statistics isdn statistics continue Optional
of information received by ISDN
Clear ISDN statistics isdn statistics clear Optional
Configuring to Check Follow these steps to configure to check the calling number when an incoming
the Calling Number call comes:
When an Incoming Call
Comes To do... Use the command... Remarks
interface-number
Configure to check the calling isdn caller-number Required
number when an incoming caller-number
Execute this command to
call comes
configure limited incoming
calls.

Configuring TEI Follow these steps to configure TEI treatment on the BRI interface:
Treatment on the BRI
Enter specified BRI interface interface bri -
Request the switch for a new isdn two-tei Optional
TEI each time a B channel on
All B channels on the BRI
the BRI interface places a call.
interface use the same TEI by
default.
Configuring ISDN BRI ISDN leased lines are implemented by establishing MP semi-permanent
Leased Line connections. This requires that the PBXs of your telecommunication service
provider provide leased lines and are connected to the remote devices.
Follow these steps to configure ISDN BRI Leased Line:

Enter specified BRI interface interface bri -
Configure the B channel for dialer isdn-leased { 128k | No B channel on the ISDN BRI
ISDN leased line connection. number } interface is configured for
leased line connection by
default.
n ■
■
Before you can use this command, you must configure C-DCC.
For description of DCC configuring, refer to “DCC Configuration” on page 153.
Configuring Permanent To enable a BRI interface to set up the Q.921 link automatically and maintain the
Link Function on ISDN link permanently even when no calls are received from the network layer, you may
BRI Link Layer configure the isdn q921-permanent command. If the two-tei mode is also
configured on the interface, two such links will be present.
You may need to configure permanent Q.921 link mode where the ISDN NI
protocol is adopted to ensure the success of every call attempt.
Follow these steps to configure Q.921 permanent link mode for an ISDN BRI
interface:

Enter specified BRI interface interface interface-type -
Set the Q.921 link on the BRI dialer isdn-leased { 128k | Required
interface in permanent state. number }
The Q.921 links on BRI
interfaces are not in
permanent state by default.

n On PRI interfaces, Q.921 layer negotiates to enter multi-framing state immediately

after the user side and the network side connects correctly. On BRI interfaces,
however, the Q.921 layer transits to the multi-framing state only after being
triggered by a call and the Q.921 link that has been set up will be torn down if no
Layer 3 call is received before the T.325 timer expires.
Specifying an ISDN BRI On a BRI interface operating on the network side, the T325 timer is triggered
Interface to be in when the link is torn down on data link layer and deactivating requests are sent
Permanent Active State from data link layer to physical layer when the timer expires. Deactivating request
on Physical Layer causes BRI interface to turn to active mode on physical layer and thus helps reduce
power consumption. To make a BRI interface to remain in the active state on
physical layer even if no link exists on the data link layer, you can perform the
operations listed in the following table, through which you can disable
deactivating request sending.
Follow these steps to specify an ISDN BRI interface to be in permanent active state
on physical layer:

Enter specified BRI interface interface interface-type -
Specify the BRI interface to be permanent-active Optional
in permanent active state on
A BRI interface is not in
physical layer
permanent active state on
physical layer
n ■
■
The support for this function varies with device models.
This function is only applicable to BRI interfaces operating in the network side
mode. Currently, only BSV board can operate on network side.
■ This function is different from the permanent link function. The former
maintains the active state of BRI interfaces on physical layer and is only
applicable to BRI interfaces operating on the network side. It cannot activate
the BRI interfaces that are in inactive state on physical layer. The latter,
however, enables BRI interfaces to enter Q.921 multi-framing state
immediately after the user side and the network side connects correctly. It is
only applicable to BRI interfaces operating on the user side. If you enable the
permanent link function while no Q.921 link is established, the system
attempts to establish Q.921 links.
Enabling Remote Follow these steps to enable remote powering on an ISDN BRI interface:
Powering on an ISDN
BRI Interface To do... Use the command... Remarks
Enter specified BRI interface interface-type -
Enable remote powering power-source Optional
on the interface
The remote powering function is
disabled on an ISDN BRI interface by
default.

n ■
■
The support for this function varies with device models.
This function is available to BSV interfaces operating in the network side mode.
Currently, only BSV board can operate in the network side mode. For example,
you can enable this function on a BSV interface operating in the network side
mode to provide power supply to the ISDN digital phone sets attached to the
interface.
Displaying and
Maintaining ISDN To do... Use the command... Remarks
Display the active calling Display isdn active-channel Available in any view.
information on an ISDN [ interface interface-type
interface interface-number ]
Display the current status of display isdn call-info Available in any view.
an ISDN interface [ interface interface-type
interface-number ]
Display the history record of display isdn call-record Available in any view.
an ISDN call [ interface interface-type
interface-number ]
Display the system parameters display isdn parameters Available in any view.
of ISDN protocol Layer 2 and { protocol | interface
Layer 3 running on the interface-type
interface. interface-number ]
Display the information of display isdn spid interface Available in any view.
SPID on the BRI interface interface-type
adopting NI protocol interface-number ]
Shut down the current BRI shutdown Available in ISDN interface
interface view
Bring up the current BRI undo shutdown Available in ISDN interface
interface view
ISDN Configuration
Example

through ISDN PRI Lines As shown in the figure below, Router A is connected with Router B through ISDN
PRI lines.

Network diagram
Figure 122 Network diagram for ISDN configuration

Router A
CE /PRI 1/0
202.38 .154 .1 /16
8810152
ISDN network
CE/PRI 1/0
202 .38.154.2/16
8810154
Router B
# Create an ISDN PRI interface.
[RouterA] controller e1 1/0
[RouterA-E1 1/0] pri-set
[RouterA-E1 1/0] quit
# Configure an ISDN PRI interface.

[RouterA-Serial1/0:15] ip address 202.38.154.1 255.255.0.0
[RouterA-Serial1/0:15] isdn protocol-type dss1
[RouterA-Serial1/0:15] dialer enable-circular
[RouterA-Serial1/0:15] dialer route ip 202.38.154.2 8810154
[RouterA-Serial1/0:15] dialer-group 1
Follow the same procedures to configure Router B.

through ISDN BRI Lines As shown in the following figure, Router A is connected to Router B through NI
Running NI protocol of ISDN BRI lines.

Network diagram
Figure 123 Network diagram for ISDN NI protocol configuration

Router A
BRI2/0
202.38 .154 .1 /16
8810152
ISDN network
BRI2/0
202 .38 .154 .2 /16
8810154
Router B
# Configure the dialing parameters on ISDN BRI interface.
[RouterA-Bri2/0] quit
# Configure ISDN NI protocol parameter to make the B channel of BRI interface

support static SPID value, and set the negotiation message to be resent twice
when there is no reply.

[RouterA-Bri2/0] isdn protocol-type ni
[RouterA-Bri2/0] isdn spid1 12345
[RouterA-Bri2/0] isdn spid2 23456
[RouterA-Bri2/0] isdn spid resend 2
Follow the same procedures to configure Router B.
Using ISDN BRI Leased Network requirements

Line to Implement MP As shown in the following figure, Router A is connected to Router B through two
Bundling BRI leased lines, which are used for MP bundling.

Network diagram
Figure 124 Using ISDN BRI leased lines to implement MP bundling

Router A
BRI2/0
202.38 .154 .1 /16
ISDN network
BRI2/0
202 .38 .154 .2 /16
Router B
[RouterA] interface bri2/0
[RouterA-Bri2/0] ppp mp virtual-template 5
[RouterB] interface Bri2/0
[RouterB-Bri2/0] link-protocol ppp
[RouterB-Bri2/0] ppp mp virtual-template 5
[RouterB-Bri2/0] dialer isdn-leased 0
[RouterB-Bri2/0] dialer isdn-leased 1
[RouterB-Bri2/0] quit
n ■ At present, only virtual-template is used as the template for MP binding using

ISDN leased line.
■ As leased lines do not require dialing, you do not need to configure dial
numbers.
■ The system accepts MP bundles formed by multiple ISDN leased lines, which
can be 64K, 128K, or both. For detailed information, refer to the three ways to
configure MP bundles discussed in “PPP and MP Configuration” on page 363
and “PPPoE Configuration” on page 393.

Configuring ISDN 128K Network requirements

Leased Lines Router A and Router B are connected by connecting their ISDN BRI interfaces
through a 128K leased line.
Network diagram
Figure 125 Network diagram for ISDN 128K leased line connection
BRI2/ 0 BRI2/ 0
100. 1. 1.1 /24 100. 1. 1.2 /24
ISDN network
Router A Router B
[RouterA-Bri2/0] dialer isdn-leased 128k
[RouterB-Bri2/0] dialer isdn-leased 128k
n You do not need to configure a dial number because setup of leased line
connection does not involve dial process.
After you configure a lease line successfully, you can dial through. To view state
about the interfaces, execute the following commands:
<RouterA> display interface bri 2/0

Bri2/0 current state :UP
Line protocol current state :UP (spoofing)
Description : Bri2/0 Interface
The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
baudrate is 128000 bps, Timeslot(s) Used: 1, 2
Internet Address is 100.1.1.1/24
Encapsulation is ISDN

Output queue : (Protocol queue : Size/Length/Discards) 0/500/0
Last 300 seconds input rate 0.00 bytes/sec, 0.00 packets/sec
Last 300 seconds output rate 0.00 bytes/sec, 0.00 packets/sec
Input: 0 packets, 0 bytes

0 broadcasts, 0 multicasts
2 errors, 0 runts, 0 giants,
2 CRC, 0 align errors, 0 overruns,
0 dribbles, 0 aborts, 0 no buffers
0 frame errors
Output:0 packets, 0 bytes
0 errors, 0 underruns, 0 collisions
0 deferred
<RouterA> display interface bri 2/0:1

Bri2/0:1 current state :UP
Description : Bri2/0:1 Interface
baudrate is 128000 bps, Timeslot(s) Used: 1, 2
LCP opened, IPCP opened, OSICP opened
0 frame errors
0 deferred
<RouterA> display interface bri 2/0:2

Bri2/0:2 current state :DOWN
Description : Bri2/0:2 Interface
baudrate is 64000 bps, Timeslot(s) Used: NULL
LCP initial
0 frame errors
0 deferred

As you can see, the state of interface Bri 2/0:1 is up, its speed is 128 kbps, and
channels (timeslots used) B1 and B2 are in use; the state of Bri 2/0:2 is down, and
the field of timeslots used is NULL.
Interoperating with Network requirements

DMS100 Switches Router D is connected to a DMS100 switch of the carrier, using the access number
of 8810148. The ISDN lines on interface BRI 2/0 are allocated two SPIDs and LDNs;
they are:
spid1 = 31427583620101, LDN1 = 1234567
spid2 = 31427583870101, LDN2 = 7654321
In addition, the username and password for dialing are user and hello respectively.
Router D needs to place an MP call on interface Bri 2/0 to obtain an address from
the carrier for accessing the Internet.
Network diagram
Figure 126 Interoperate with the DMS 100
Router NT1 DMS 100
BRI2/0 8810148
SPID1:31427583620101,LDN1= 1234567
SPID1:31427583870101,LDN1= 7654321
# Enable IP packet-triggered dial.
# Encapsulate interface BRI 2/0 with MP.
[Router] interface bri 2/0

[Router-Bri2/0] link-protocol ppp
[Router-Bri2/0] ppp mp
# Enable C-DCC.
[Router-Bri2/0] dialer enable-circular

[Router-Bri2/0] dialer-group 1
[Router-Bri2/0] dialer circular-group 1
# Configure ISDN parameters.
[Router-Bri2/0] isdn protocol-type ni

[Router-Bri2/0] isdn two-tei
[Router-Bri2/0] isdn number-property 0
[Router-Bri2/0] isdn spid1 31427583620101 1234567
[Router-Bri2/0] isdn spid2 31427583870101 7654321
[Router-Bri2/0] isdn spid service data

Troubleshooting 441
[Router-Bri2/0] isdn spid service speech

[Router-Bri2/0] quit
# Configure a dialer interface.

[Router-Dialer1] link-protocol ppp
[Router-Dialer1] ppp pap local-user user password simple hello
[Router-Dialer1] dialer threshold 0 in-out
[Router-Dialer1] ppp mp
[Router-Dialer1] dialer enable-circular
[Router-Dialer1] dialer number 8810148
[Router-Dialer1] quit
# Configure the static route to the segment 65.0.0.0 where the network access
server is located.
[Router] ip route-static 65.0.0.0 255.0.0.0 Dialer 1 preference 60
To interoperate with the DMS 100, you must configure two commands: isdn
two-tei and isdn number-property 0. The isdn two-tei command allows each
call on the BRI interface to use a unique TEI. The isdn number-property 0
command sets the numbering plan and numbering type in the called-party
information element in ISDN Q.931 SETUP messages to unknown.
In addition, if the carrier allocates an LDN, you must configure it.
The dialer threshold 0 in-out command configured on interface dialer 1 allows

the system to bring up another B channel automatically after bringing up a BRI
link. This can be done without presence of a flow control mechanism and the links
that have been brought up will not disconnect automatically.
Two routers are interconnected via ISDN PRI line and they cannot ping through
each other.
Solution:
■ Execute the display isdn call-info command. If there is no prompt in the

system, it indicates there is no ISDN PRI interface. Thus it is necessary to
configure corresponding interfaces. For specified configuration method, refer
to “CE1/PRI Interface” on page 106 and “CT1/PRI Interface” on page 110. If
the ISDN is not in multi-frame operation status on a PRI interface, or if ISDN is
not in TEI configured status on a BRI interface, it may not physically connected
well.
■ If the Q.921 maintaining has been enabled, and the ISDN on PRI is in
multi-frame creation mode and that on BRI is in TEI configured mode, check
whether dial-up configuration is wrong. If the maintaining information “Q921
send data fail(L1 return failure).” is output, it indicates that physical layer has
no been activated. In this case, execute the shutdown or undo shutdown
command to disable or re-enable corresponding interfaces.

■ Check whether the dial-up configuration is correct. If dial-up is correctly

configured and the maintaining information “Q921 send data fail(L1 return
failure).” is not output, ISDN line may be not connected well.

MSTP CONFIGURATION
23
When configuring MSTP, go to these sections for information you are interested
in:
■ “MSTP Overview” on page 443
■ “Configuring the Root Bridge” on page 459
■ “Configuring Leaf Nodes” on page 470
■ “Performing mCheck” on page 474
■ “Configuring Protection Functions” on page 479
■ “Displaying and Maintaining MSTP” on page 481
MSTP Overview
Introduction to STP Functions of STP

The Spanning Tree Protocol (STP) was established based on the 802.1D standard
of IEEE to eliminate physical loops at the data link layer in a local area network
(LAN). Devices running this protocol detect loops in the network by exchanging
information with one another and eliminate loops by selectively blocking certain
ports until the loop structure is pruned into a loop-free network structure. This
avoids proliferation and infinite recycling of packets that would occur in a loop
network and prevents deterioration of the packet processing capability of network
devices caused by duplicate packets received.
In the narrow sense, STP refers to the STP protocol defined in IEEE 802.1d; in the
broad sense, it refers to the STP protocol defined in IEEE 802.1d and various
enhanced spanning tree protocols derived from the STP protocol.
Protocol Packets of STP

STP uses bridge protocol data units (BPDUs), also known as configuration
messages, as its protocol packets.
STP identifies the network topology by transmitting BPDUs between STP compliant
network devices. BPDUs contain sufficient information for the network devices to
complete the spanning tree computing.
In STP, BPDUs come in two types:
■ Configuration BPDUs, used for calculating spanning trees and maintaining the
spanning tree topology.
■ Topology change notification (TCN) BPDUs, used for notifying concerned
devices of network topology changes, if any.

444 CHAPTER 23: MSTP CONFIGURATION
Basic concepts in STP

1 Root bridge
A tree network must have a root; hence the concept of “root bridge” has been
introduced in STP.
There is one and only one root bridge in the entire network, and the root bridge
can change alone with changes of the network topology. Therefore, the root
bridge is not fixed.
Upon network convergence, the root bridge generates and sends out
configuration BPDUs at a certain interval, and other devices just forward the
BPDUs. This mechanism ensures topological stability.
2 Root port
On a non-root bridge device, the root port is the port nearest to the root bridge.
The root port is responsible for communicating with the root bridge. A
non-root-bridge device has one and only one root port. The root bridge has no
root port.
3 Designated bridge and designated port
Refer to Table 10 for the description of designated bridge and designated port.
Table 10 Description of designated bridge and designated port
Classification Designated bridge Designated port

For a device The device directly connected with The port through which the
this device and responsible for designated bridge forwards
forwarding BPDUs BPDUs to this device
For a LAN The device responsible for The port through which the
forwarding BPDUs to this LAN designated forwards BPDUs to
segment this LAN segment
Figure 127 shows designated bridges and designated ports. In the figure, AP1 and
AP2, BP1 and BP2, and CP1 and CP2 are ports on Device A, Device B, and Device
C respectively.
■ If Device A forwards BPDUs to Device B through AP1, the designated bridge for
Device B is Device A, and the designated port is the port AP1 on Device A.
■ Two devices are connected to the LAN: Device B and Device C. If Device B
forwards BPDUs to the LAN, the designated bridge for the LAN is Device B, and
the designated port is the port BP2 on Device B.

MSTP Overview 445
Figure 127 A schematic diagram of designated bridges and designated ports
Device A
AP1 AP2
BP1 CP1
Device B Device C
BP 2 CP2
LAN
n All the ports on the root bridge are designated ports.
4 Path cost
Path cost is a reference value used for link selection in STP. By calculating the path
cost, STP selects relatively “robust” links and blocks redundant links, and finally
prunes the network into a loop-free tree structure.
How STP works

STP identifies the network topology by transmitting configuration BPDUs between
network devices. Configuration BPDUs contain sufficient information for network
devices to complete the spanning tree computing. Important fields in a
configuration BPDU include:
■ Root bridge ID: consisting of root bridge priority and MAC address.
■ Root path cost: the cost of the shortest path to the root bridge.
■ Designated bridge ID: designated bridge priority plus MAC address.
■ Designated port ID, designated port priority plus port name.
■ Message age: age of the configuration BPDU while it propagates in a network.
■ Max age: maximum age of the configuration BPDU maintained in a device.
■ Hello time: configuration BPDU interval.
■ Forward delay: forward delay of the port.
n For the convenience of description, the description and examples below involve
only four parts of a configuration BPDU
■ Root bridge ID (in the form of device priority)
■ Root path cost
■ Designated bridge ID (in the form of device priority)
■ Designated port ID (in the form of port name)
1 Specific computing process of the STP algorithm
■ Initial state

Upon initialization of a device, each port generates a BPDU with itself as the root
bridge, in which the root path cost is 0, designated bridge ID is the device ID, and
the designated port is the local port.
■ Selection of the optimum configuration BPDU
Each device sends out its configuration BPDU and receives configuration BPDUs
from other devices.
The process of selecting the optimum configuration BPDU is as follows:
Table 11 Selection of the optimum configuration BPDU
Step Description
1 Upon receiving a configuration BPDU on a port, the device performs the
following processing:
■ If the received configuration BPDU has a lower priority than that of the
configuration BPDU generated by the port, the device will discard the
received configuration BPDU without doing any processing on the
configuration BPDU of this port.
■ If the received configuration BPDU has a higher priority than that of the
configuration BPDU generated by the port, the device will replace the
content of the configuration BPDU generated by the port with the
content of the received configuration BPDU.
2 The device compares the configuration BPDUs of all the ports and chooses
the optimum configuration BPDU.
n Principle for configuration BPDU comparison

■ The configuration BPDU that has the lowest root bridge ID has the highest
priority.
■ If all the configuration BPDUs have the same root bridge ID, they will be
compared for their root path costs. If the root path cost in a configuration
BPDU plus the path cost corresponding to this port is S, the configuration
BPDU with the smallest S value has the highest priority.
■ If all configuration BPDU have the same root path cost, they will be compared
for their designated bridge IDs, then their designated port IDs, and then the IDs
of the ports on which they are received. The smaller the ID, the higher message
priority.
■ Selection of the root bridge
At network initialization, each STP-compliant device on the network assumes itself

to be the root bridge, with the root bridge ID being its own device ID. By
exchanging configuration BPDUs, the devices compare one another’s root bridge
ID. The device with the smallest root bridge ID is elected as the root bridge.
■ Selection of the root port and designated ports
The process of selecting the root port and designated ports is as follows:

MSTP Overview 447
Table 12 Selection of the root port and designated ports
Step Description
1 A non-root-bridge device regards the port through which it received the
optimum configuration BPDU as the root port.
2 Based on the configuration BPDU and the path cost of the root port, the device
calculates a designated port configuration BPDU for each of the rest ports.
■ The root bridge ID is replaced with that of the configuration BPDU of the
root port.
■ The root path cost is replaced with that of the configuration BPDU of the
root port plus the path cost corresponding to the root port.
■ The designated bridge ID is replaced with the ID of this device.
■ The designated port ID is replaced with the ID of this port.
3 The device compares the calculated configuration BPDU with the configuration
BPDU on the port of which the port role is to be determined, and proceeds the
following according to the comparison result:
■ If the calculated configuration BPDU is superior, the device will consider this
port as the designated port, and the configuration BPDU on the port will be
replaced with the calculated configuration BPDU, which will be sent out
periodically.
■ If the configuration BPDU on the port is superior, the device will block this
port without updating its configuration BPDU, so that the port will only
receive BPDUs, but not send any, and will not forward data.
n When the network topology is stable, only the root port and designated ports
forward traffic, while other ports are all in the blocked state - they only receive STP
packets but do not forward user traffic.
Once the root bridge, the root port on each non-root bridge and designated ports
have been successfully elected, the entire tree-shaped topology has been
constructed.
The following is an example of how the STP algorithm works. The specific network
diagram is shown in Figure 128. In the feature, the priority of Device A is 0, the
priority of Device B is 1, the priority of Device C is 2, and the path costs of these
links are 5, 10 and 4 respectively.
Figure 128 Network diagram for STP algorithm
Device A
With priority 0
AP 1 AP 2
5
10
BP 1
BP 2
4 CP 1
CP 2
Device B
With priority 1
Device C
With priority 2

■ Initial state of each device
The following table shows the initial state of each device.
Table 13 Initial state of each device
Device Port name BPDU of port

Device A AP1 {0, 0, 0, AP1}
AP2 {0, 0, 0, AP2}
Device B BP1 {1, 0, 1, BP1}
BP2 {1, 0, 1, BP2}
Device C CP1 {2, 0, 2, CP1}
CP2 {2, 0, 2, CP2}
■ Comparison process and result on each device
The following table shows the comparison process and result on each device.
Table 14 Comparison process and result on each device
BPDU of port
after
Device Comparison process comparison
Device A ■ Port AP1 receives the configuration BPDU of Device B {1, AP1: {0, 0, 0,
0, 1, BP1}. Device A finds that the configuration BPDU of AP1}
the local port {0, 0, 0, AP1} is superior to the configuration
AP2: {0, 0, 0,
received message, and discards the received configuration
AP2}
BPDU.
■ Port AP2 receives the configuration BPDU of Device C {2,
0, 2, CP1}. Device A finds that the BPDU of the local port
{0, 0, 0, AP2} is superior to the received configuration
BPDU, and discards the received configuration BPDU.
■ Device A finds that both the root bridge and designated
bridge in the configuration BPDUs of all its ports are
Device A itself, so it assumes itself to be the root bridge. In
this case, it does not make any change to the
configuration BPDU of each port, and starts sending out
configuration BPDUs periodically.

MSTP Overview 449
BPDU of port
after
Device B ■ Port BP1 receives the configuration BPDU of Device A {0, BP1: {0, 0, 0,
0, 0, AP1}. Device B finds that the received configuration AP1}
BPDU is superior to the configuration BPDU of the local
BP2: {1, 0, 1,
port {1, 0,1, BP1}, and updates the configuration BPDU of
BP2}
BP1.
■ Port BP2 receives the configuration BPDU of Device C {2,
0, 2, CP2}. Device B finds that the configuration BPDU of
the local port {1, 0, 1, BP2} is superior to the received
configuration BPDU, and discards the received
configuration BPDU.
■ Device B compares the configuration BPDUs of all its Root port BP1:
ports, and determines that the configuration BPDU of BP1
{0, 0, 0, AP1}
is the optimum configuration BPDU. Then, it uses BP1 as
the root port, the configuration BPDUs of which will not Designated port
be changed. BP2:
■ Based on the configuration BPDU of BP1 and the path cost {0, 5, 1, BP2}
of the root port (5), Device B calculates a designated port
configuration BPDU for BP2 {0, 5, 1, BP2}.
■ Device B compares the computed configuration BPDU {0,
5, 1, BP2} with the configuration BPDU of BP2. If the
computed BPDU is superior, BP2 will act as the designated
port, and the configuration BPDU on this port will be
replaced with the computed configuration BPDU, which
will be sent out periodically.

BPDU of port
after
Device C ■ Port CP1 receives the configuration BPDU of Device A {0, CP1: {0, 0, 0,
0, 0, AP2}. Device C finds that the received configuration AP2}
BPDU is superior to the configuration BPDU of the local
CP2: {1, 0, 1,
port {2, 0, 2, CP1}, and updates the configuration BPDU of
BP2}
CP1.
■ Port CP2 receives the configuration BPDU of port BP2 of
Device B {1, 0, 1, BP2} before the message was updated.
Device C finds that the received configuration BPDU is
superior to the configuration BPDU of the local port {2, 0,
2, CP2}, and updates the configuration BPDU of CP2.
By comparison: Root port CP1:
■ The configuration BPDUs of CP1 is elected as the optimum {0, 0, 0, AP2}
configuration BPDU, so CP1 is identified as the root port,
Designated port
the configuration BPDUs of which will not be changed.
CP2:
■ Device C compares the computed designated port
{0, 10, 2, CP2}
configuration BPDU {0, 10, 2, CP2} with the configuration
BPDU of CP2, and CP2 becomes the designated port, and
the configuration BPDU of this port will be replaced with
the computed configuration BPDU.
■ Next, port CP2 receives the updated configuration BPDU CP1: {0, 0, 0,
of Device B {0, 5, 1, BP2}. Because the received AP2}
configuration BPDU is superior to its old one, Device C
CP2: {0, 5, 1,
launches a BPDU update process.
BP2}
■ At the same time, port CP1 receives configuration BPDUs
periodically from Device A. Device C does not launch an
update process after comparison.
By comparison: Blocked port
CP2:
■ Because the root path cost of CP2 (9) (root path cost of
the BPDU (5) + path cost corresponding to CP2 (4)) is {0, 0, 0, AP2}
smaller than the root path cost of CP1 (10) (root path cost
Root port CP2:
of the BPDU (0) + path cost corresponding to CP2 (10)),
the BPDU of CP2 is elected as the optimum BPDU, and {0, 5, 1, BP2}
CP2 is elected as the root port, the messages of which will
not be changed.
■ After comparison between the configuration BPDU of CP1
and the computed designated port configuration BPDU,
port CP1 is blocked, with the configuration BPDU of the
port remaining unchanged, and the port will not receive
data from Device A until a spanning tree computing
process is triggered by a new condition, for example, the
link from Device B to Device C becomes down.
After the comparison processes described in the table above, a spanning tree with
Device A as the root bridge is stabilized, as shown in Figure 129.

MSTP Overview 451
Figure 129 The final computed spanning tree
Device A
With priority 0
AP 1 AP 2
BP 1
BP 2
4
CP 2
Device B
With priority 1
Device C
With priority 2
n To facilitate description, the spanning tree computing process in this example is

simplified, while the actual process is more complicated.
2 The BPDU forwarding mechanism in STP
■ Upon network initiation, every router regards itself as the root bridge,
generates configuration BPDUs with itself as the root, and sends the
configuration BPDUs at a regular interval of hello time.
■ If it is the root port that received the configuration BPDU and the received
configuration BPDU is superior to the configuration BPDU of the port, the
device will increase message age carried in the configuration BPDU by a certain
rule and start a timer to time the configuration BPDU while it sends out this
configuration BPDU through the designated port.
■ If the configuration BPDU received on the designated port has a lower priority
than the configuration BPDU of the local port, the port will immediately sends
out its better configuration BPDU in response.
■ If a path becomes faulty, the root port on this path will no longer receive new
configuration BPDUs and the old configuration BPDUs will be discarded due to
timeout. In this case, the device will generate a configuration BPDU with itself
as the root and sends out the BPDU. This triggers a new spanning tree
computing process so that a new path is established to restore the network
connectivity.
However, the newly computed configuration BPDU will not be propagated

throughout the network immediately, so the old root ports and designated ports
that have not detected the topology change continue forwarding data through
the old path. If the new root port and designated port begin to forward data as
soon as they are elected, a temporary loop may occur.
3 STP timers
STP calculations need three important timing parameters: forward delay, hello
time, and max age.
■ Forward delay is the delay time for device state transition. A path failure will
cause re-calculation of the spanning tree, and the spanning tree structure will

change accordingly. However, the new configuration BPDU as the calculation

result cannot be propagated throughout the network immediately. If the newly
elected root port and designated ports start to forward data right away, a
temporary loop is likely to occur. For this reason, as a mechanism for state
transition in STP, a newly elected root port or designated port requires twice
the forward delay time before transitioning to the forwarding state, when the
new configuration BPDU has been propagated throughout the network.
■ Hello time is the time interval at which a device sends hello packets to the
surrounding devices to ensure that the paths are fault-free.
■ Max age is a parameter used to determine whether a configuration BPDU held
by the device has expired. A configuration BPDU beyond the max age will be
discarded.
Introduction to MSTP Why MSTP

1 Disadvantages of STP and RSTP
STP does not support rapid state transition of ports. A newly elected root port or
designated port must wait twice the forward delay time before transitioning to the
forwarding state, even if it is a port on a point-to-point link or it is an edge port,
which directly connects to a user terminal rather than to another device or a
shared LAN segment.
The rapid spanning tree protocol (RSTP) is an optimized version of STP. RSTP allows
a newly elected root port or designated port to enter the forwarding state much
quicker under certain conditions than in STP. As a result, it takes a shorter time for
the network to reach the final topology stability.
n ■ In RSTP, a newly elected root port can enter the forwarding state rapidly if this
condition is met: The old root port on the device has stopped forwarding data
and the upstream designated port has started forwarding data.
■ In RSTP, a newly elected designated port can enter the forwarding state rapidly
if this condition is met: The designated port is an edge port or a port connected
with a point-to-point link. If the designated port is an edge port, it can enter
the forwarding state directly; if the designated port is connected with a
point-to-point link, it can enter the forwarding state immediately after the
device undergoes handshake with the downstream device and gets a response.
Although RSTP support rapid network convergence, it has the same drawback as
STP does: All bridges within a LAN share the same spanning tree, so redundant
links cannot be blocked based on VLANs, and the packets of all VLANs are
forwarded along the same spanning tree.
2 Features of MSTP
The multiple spanning tree protocol (MSTP) overcomes the shortcomings of STP
and RSTP. In addition to support for rapid network convergence, it also allows data
flows of different VLANs to be forwarded along their own paths, thus providing a
better load sharing mechanism for redundant links. For description about VLANs,
refer to “VLAN Configuration” on page 487.
MSTP features the following:

MSTP Overview 453
■ MSTP supports mapping VLANs to MST instances by means of a

VLAN-to-instance mapping table. MSTP can save communication overheads
and resource usage by mapping multiple VLANs to one MST instance.
■ MSTP divides a switched network into multiple regions, each containing
multiple spanning trees that are independent of one another.
■ MSTP prunes loop networks into a loop-free tree, thus avoiding proliferation
and endless recycling of packets in a loop network. In addition, it provides
multiple redundant paths for data forwarding, thus supporting load sharing of
VLAN data in the data forwarding process.
■ MSTP is compatible with STP and RSTP.
Basic concepts in MSTP

Assume that all the four switches in Figure 130 are running MSTP. In light with the
diagram, the following paragraphs will present some basic concepts of MSTP.
Figure 130 Basic concepts in MSTP
Region A0
VLAN 1 mapped to instance 1
VLAN 2 mapped to instance 2
Other VLANs mapped CIST
BPDU BPDU
CST
B
C
D
Region D0 BPDU
VLAN 1 mapped to instance1, Region B0
B as regional root bridge VLAN 1 mapped to instance 1
VLAN 2 mapped to instance2, VLAN 2 mapped to instance 2
C as regional root bridge Other VLANs mapped CIST
Region C0
Other VLANs mapped CIST VLAN 1 mapped to instance1
VLANs 2 and 3mapped to instance 2
Other VLANs mapped CIST
1 MST region
A multiple spanning tree region (MST region) is composed of multiple devices in a

switched network and network segments among them. These devices have the
following characteristics:
■ All are MSTP-enabled,

■ They have the same region name,
■ They have the same VLAN-to-instance mapping configuration,
■ They have the same MSTP revision level configuration, and
■ They are physically linked with one another.
In area A0 in Figure 130, for example, all the device have the same MST region
configuration:
■ The same region name

■ The same VLAN-to-instance mapping (VLAN 1 is mapped to MST instance 1,

VLAN 2 to MST instance 2, and the rest to the command and internal spanning
tree (CIST). CIST refers to MST instance 0)
■ The same MSTP revision level (not shown in the figure)
Multiple MST regions can exist in a switched network. You can use an MSTP
command to group multiple devices to the same MST region.
2 VLAN-to-instance mapping table
As an attribute of an MST region, the VLAN-to-instance mapping table describes

the mapping relationships between VLANs and MST instances. In Figure 130, for
example, the VLAN-to-instance mapping table of region A0 describes that the
same region name, the same VLAN-to-instance mapping (VLAN 1 is mapped to
MST instance 1, VLAN 2 to MST instance 2, and the rest to CIST). MSTP achieves
load balancing by means of the VLAN-to-instance mapping table.
3 IST
Internal spanning tree (IST) is a spanning tree that runs in an MST region.
ISTs in all MST regions and the common spanning tree (CST) jointly constitute the
common and internal spanning tree (CIST) of the entire network. An IST is a
section of the CIST in the given MST region.
In Figure 130, for example, the CIST has a section in each MST region, and this
section is the IST in the respective MST region.
4 CST
The CST is a single spanning tree that connects all MST regions in a switched
network. If you regard each MST region as a “device”, the CST is a spanning tree
calculated by these devices through STP or RSTP. For example, the red lines in
Figure 130 describe the CST.
5 CIST
Jointly constituted by ISTs and the CST, the CIST is a single spanning tree that
connects all devices in a switched network.
In Figure 130, for example, the ISTs in all MST regions plus the inter-region CST
constitute the CIST of the entire network.
6 MSTI
Multiple spanning trees can be generated in an MST region through MSTP, one
spanning tree being independent of another. Each spanning tree is referred to as a
multiple spanning tree instance (MSTI). In Figure 130, for example, multiple
spanning tree can exist in each MST region, each spanning tree corresponding to a
VLAN. These spanning trees are called MSTIs.
7 Regional root bridge

MSTP Overview 455
The root bridge of the IST or an MSTI within an MST region is the regional root
bridge of the MST or that MSTI. Based on the topology, different spanning trees in
an MST region may have different regional roots. For example, in region D0 in
Figure 130, the regional root of instance 1 is device B, while that of instance 2 is
device C.
8 Common root bridge
The common root bridge is the root bridge of the CIST. In Figure 130, for example,
the common root bridge is a device in region A0.
9 Boundary port
A boundary port is a port that connects an MST region to another MST

configuration, or to a single spanning-tree region running STP, or to a single
spanning-tree region running RSTP.
During MSTP computing, a boundary port assumes the same role on the CIST and
on MST instances. Namely, if a boundary port is master port on the CIST, it is also
the master port on all MST instances within this region. In Figure 130, for example,
if a device in region A0 is interconnected with the first port of a device in region
D0 and the common root bridge of the entire switched network is located in
region A0, the first port of that device in region D0 is the boundary port of region
D0.
n Currently, the device is not capable of recognizing boundary ports. When the
device interworks with a third party’s device that supports boundary port
recognition, the third party’s device may malfunction in recognizing a boundary
port.
10 Roles of ports
In the MSTP computing process, port roles include root port, designated port,
master port, alternate port, backup port, and so on.
■ Root port: a port responsible for forwarding data to the root bridge.
■ Designated port: a port responsible for forwarding data to the downstream
network segment or device.
■ Master port: A port on the shortest path from the entire region to the common
root bridge, connecting the MST region to the common root bridge.
■ Alternate port: The standby port for the root port or master port. When the
root port or master port is blocked, the alternate port becomes the new root
port or master port.
■ Backup port: The backup port of designated ports. When a designated port is
blocked, the backup port becomes a new designated port and starts
forwarding data without delay. When a loop occurs while two ports of the
same MSTP device are interconnected, the device will block either of the two
ports, and the backup port is that port to be blocked.
A port can assume different roles in different MST instances.

Figure 131 Port roles
Connecting to the
common root bridge
Edge port
MST region Port 2

Port 1
Master port Alternate port

A
B C
Port 6
Port 5
Backup port
D
Designated
port
Port 3 Port 4
Figure 131 helps understand these concepts. Where,
■ Devices A, B, C, and D constitute an MST region.

■ Port 1 and port 2 of device A connect to the common root bridge.
■ Port 5 and port 6 of device C form a loop.
■ Port 3 and port 4 of device D connect downstream to other MST regions.
11 Port states
In MSTP, port states fall into the following tree:
■ Forwarding: the port learns MAC addresses and forwards user traffic;
■ Learning: the port learns MAC addresses but does not forwards user traffic;
■ Discarding: the port neither learns MAC addresses nor forwards user traffic.
n When in different MST instances, a port can be in different states.
A port state is not exclusively associated with a port role. Table 15 lists the port
state(s) supported by each port role (“√” indicates that the port supports this
state, while “-” indicates that the port does not support this state).
Table 15 Ports states supported by different port roles
Root
port/Master Designated
Role \State port port Alternate port Backup port
Forwarding √ √ - -
Learning √ √ - -
Discarding √ √ √ √

MSTP Overview 457
How MSTP works

MSTP divides an entire Layer 2 network into multiple MST regions, which are
interconnected by a computed CST. Inside an MST region, multiple spanning trees
are generated through computing, each spanning tree called an MST instance.
Among these MST instances, instance 0 is the IST, while all the others are MSTIs.
Similar to STP, MSTP uses configuration BPDUs to compute spanning trees. The
only difference between the two protocols being in that what is carried in an
MSTP BPDU is the MSTP configuration on the device from which this BPDU is sent.
1 CIST computing
By comparison of configuration BPDUs, the device with the highest priority is

elected as the root bridge of the CIST. MSTP generates an IST within each MST
region through computing, and, at the same time, MSTP regards each MST region
as a single device and generates a CST among these MST regions through
computing. The CST and ISTs constitute the CIST of the entire network.
2 MSTI computing
Within an MST region, MSTP generates different MSTIs for different VLANs based
on the VLAN-to-instance mappings.
MSTP performs a separate computing process, which is similar to spanning tree

computing in STP, for each spanning tree. For details, refer to “How STP works”
on page 445.
In MSTP, a VLAN packet is forwarded along the following paths:
■ Within an MST region, the packet is forwarded along the corresponding MSTI.
■ Between two MST regions, the packet is forwarded along the CST.
Implementation of MSTP on devices

MSTP is compatible with STP and RSTP. STP and RSTP protocol packets can be
recognized by devices running MSTP and used for spanning tree computing.
In addition to basic MSTP functions, many management-facilitating special

functions are provided, as follows:
■ Root bridge hold

■ Root bridge backup
■ Root guard
■ BPDU guard
■ Loop guard
■ TC-BPDU guard
■ Support for hot swapping of interface cards and active/standby switchover.
Protocols and Standards MSTP is documented in:

■ IEEE 802.1D: Spanning Tree Protocol
■ IEEE 802.1w: Rapid Spanning Tree Protocol
■ IEEE 802.1s: Multiple Spanning Tree Protocol

Configuration Task Before configuration, you need to know the position of each device in each MST
List instance: root bridge or leave node. In each instance, one, and only one device
acts as the root bridge, while all others as leaf nodes.
Task Remarks
“Configuring the Root “Configuring an MST Region” Required
Bridge” on page 459 on page 459
“Specifying the Root Bridge or a Optional
Secondary Root Bridge” on page
460
“Configuring the Work Mode of Optional
MSTP Device” on page 462
“Configuring the Priority of the Optional
Current Device” on page 462
“Configuring the Maximum Optional
Hops of an MST Region” on
page 463
“Configuring the Network Optional
Diameter of a Switched
“Configuring Timers of MSTP” Optional
on page 464
“Configuring the Timeout Optional
Factor” on page 465
Transmission Rate of Ports” on
page 466
“Configuring Ports as Edge Optional
Ports” on page 467
“Configuring Whether Ports Optional
Connect to Point-to-Point Links”
on page 467
“Configuring the Mode a Port Optional
Uses to Recognize/Send MSTP
Packets” on page 468
“Enabling the Output of Port Optional
State Transition Information” on
page 469
“Enabling the MSTP Feature” on Required
page 469

Task Remarks
“Configuring Leaf “Configuring an MST Region” Required
Nodes” on page 470 on page 470
“Configuring the Work Mode of Optional
MSTP” on page 470
“Configuring the Timeout Optional
Factor” on page 470
Transmission Rate of Ports” on
page 470
“Configuring Ports as Edge Optional
“Configuring Path Costs of Optional
“Configuring Port Priority” on Optional
page 473
“Configuring Whether Ports Optional
Connect to Point-to-Point Links”
on page 473
“Configuring the Mode a Port Optional
Uses to Recognize/Send MSTP
“Enabling the MSTP Feature” on Required
page 474
“Performing mCheck” on page 474 Optional
“Configuring Digest Snooping” on page 475 Optional
“Configuring No Agreement Check” on page 477 Optional
“Configuring Protection Functions” on page 479 Optional
n If both GVRP and MSTP are enabled on a device at the same time, GVRP packets
will be forwarded along the CIST. Therefore, if both GVRP and MSTP are running
on the same device and you wish to advertise a certain VLAN within the network
through GVRP, make sure that this VLAN is mapped to the CIST (instance 0) when
configuring the VLAN-to-instance mapping table. For detailed information of
GVRP, refer to “GVRP Configuration” on page 271.
Configuring the Root

Bridge
Configuring an MST Configuration procedure

Region Follow these steps to configure an MST region:

Enter MST region view stp region-configuration -
Configure the MST region region-name name Optional
name
The MST region name is the
MAC address by default


Configure the instance instance-id vlan Optional
VLAN-to-instance mapping vlan-list
Use either command
table
vlan-mapping modulo
All VLANs in an MST region
modulo
are mapped to MST instance
0 by default.
Configure the MSTP revision revision-level level Optional
level of the MST region
0 by default
Activate MST region active region-configuration Required
configuration manually
Display all the configuration check region-configuration Optional
information of the MST region
Display the currently effective display stp Optional
MST region configuration region-configuration
The display command can be
information
executed in any view
n Two device belong to the same MST region only if they are configure to have the
same MST region name, the same VLAN-to-instance mapping entries in the MST
region and the same MST region revision level, and they are interconnected via a
physical link.
The configuration of MST region-related parameters, especially the

VLAN-to-instance mapping table, will cause MSTP to launch a new spanning tree
computing process, which may result in network topology instability. To reduce the
possibility of topology instability caused by configuration, MSTP will not
immediately launch a new spanning tree computing process when processing MST
region-related configurations; instead, such configurations will take effect only if
you:
■ activate the MST region-related parameters suing the active

region-configuration command, or
■ enable MSTP using the stp enable command.
Configuration example
# Configure the MST region name to be “info”, the MSTP revision level to be 1,
and VLAN 2 through VLAN 10 to be mapped to instance 1 and VLAN 20 through
VLAN 30 to instance 2.
[Sysname] stp region-configuration
[Sysname-mst-region] region-name info
[Sysname-mst-region] instance 1 vlan 2 to 10
[Sysname-mst-region] instance 2 vlan 20 to 30
[Sysname-mst-region] revision-level 1
[Sysname-mst-region] active region-configuration
Specifying the Root MSTP can determine the root bridge of a spanning tree through MSTP computing.
Bridge or a Secondary Alternatively, you can specify the current device as the root bridge using the
Root Bridge commands provided by the system.

Specifying the current device as the root bridge of a specific spanning tree
Follow these steps to specify the current device as the root bridge of a specific
spanning tree:

Specify the current device as stp [ instance instance-id ] Required
the root bridge of a specific root primary
The device does not function
spanning tree
as the root bridge by default
Specifying the current device as a secondary root bridge of a specific

spanning tree
Follow these steps to specify the current device as a secondary root bridge of a
specific spanning tree:

Specify the current device as a stp [ instance instance-id ] Required
secondary root bridge of a root secondary
By default, a device does not
specific spanning tree
function as a secondary root
bridge
Note that:
■ Upon specifying the current device as the root bridge or a secondary root
bridge, you cannot change the priority of the device.
■ You can configure the current device as the root bridge or a secondary root
bridge of an MST instance, which is specified by instance instance-id in the
command. If you set instance-id to 0, the current device will be the root bridge
or a secondary root bridge of the CIST.
■ The current device has independent roles in different instances. It can act as the
root bridge or a secondary root bridge of one instance while it can also act as
the root bridge or a secondary root bridge of another instance. However, the
same device cannot be the root bridge and a secondary root bridge in the same
instance at the same time.
■ There is one and only one root bridge in effect in a spanning tree instance. If
two or more devices have been designated to be root bridges of the same
spanning tree instance, MSTP will select the device with the lowest MAC
address as the root bridge.
■ You can specify multiple secondary root bridges for the same instance. Namely,
you can specify secondary root bridges for the same instance on two or more
than two device.
■ When the root bridge of an instance fails or is shut down, the secondary root
bridge (if you have specified one) can take over the role of the instance.
However, if you specify a new root bridge for the instance at this time, the
secondary root bridge will not become the root bridge. If you have specified
multiple secondary root bridges for an instance, when the root bridge fails,
MSTP will select the secondary root bridge with the lowest MAC address as the
new root bridge.

■ Alternatively, you can also specify the current device as the root bridge by
setting by priority of the device to 0. For the device priority configuration, refer
to “Configuring the Priority of the Current Device” on page 462.
# Specify the current device as the root bridge of MST instance 1 and a secondary
root bridge of MST instance 2.
[Sysname] stp instance 1 root primary
[Sysname] stp instance 2 root secondary
Configuring the Work MSTP and RSTP can recognize each other’s protocol packets, so they are mutually
Mode of MSTP Device compatible. However, STP is unable to recognize MSTP packets. For hybrid
networking with legacy STP devices and full interoperability with RSTP-compliant
devices, MSTP supports three work modes: STP-compatible mode, RSTP mode,
and MSTP mode.
■ In STP-compatible mode, all ports of the device send out STP BPDUs,
■ In RSTP mode, all ports of the device send out RSTP BPDUs. If the device
detects that it is connected with a legacy STP device, the port connecting with
the legacy STP device will automatically migrate to STP-compatible mode.
■ In MSTP mode, all ports of the device send out MSTP BPDUs. If the device
detects that it is connected with a legacy STP device, the port connecting with
the legacy STP device will automatically migrate to STP-compatible mode.
Follow these steps to configure the MSTP work mode:

Configure the work mode of stp mode { stp | rstp | mstp } Optional
MSTP
MSTP mode by default
# Configure MSTP to work in STP-compatible mode.
[Sysname] stp mode stp
Configuring the Priority The priority of a device determines whether it can be elected as the root bridge of
of the Current Device a spanning tree. A lower value indicates a higher priority. By setting the priority of
a device to a low value, you can specify the device as the root bridge of spanning
tree. An MSTP-compliant device can have different priorities in different MST
instances.
Follow these steps to configure the priority of the current device:



Configure the priority of the stp [ instance instance-id ] Optional
current device priority priority
32768 by default
c CAUTION:
■ Upon specifying the current device as the root bridge or a secondary root
bridge, you cannot change the priority of the device.
■ During root bridge selection, if all devices in a spanning tree have the same
priority, the one with the lowest MAC address will be selected as the root
bridge of the spanning tree.
# Set the device priority in MST instance 1 to 4096.
[Sysname] stp instance 1 priority 4096
Configuring the By setting the maximum hops of an MST region, you can restrict the region size.
Maximum Hops of an The maximum hops setting configured on the regional root bridge will be used as
MST Region the maximum hops of the MST region.
After a configuration BPDU leaves the root bridge of the spanning tree in the MST
region, its hop count is decremented by 1 whenever it passes a device. When its
hop count reaches 0, it will be discarded by the device that has received it. As a
result, devices beyond the maximum hops are unable to take part in spanning tree
computing, and thereby the size of the MST region is restricted.
When a device becomes the root bridge of the CIST or MSTI of an MST region, the
maximum hop in the configuration BPDUs generated by this device defines the
network diameter of the spanning tree to define how far the spanning tree can
reach in this MST region. All the devices other than the root bridge in the MST
region use the maximum hop value set for the root bridge.
Follow these steps to configure the maximum hops of the MST region

Configure the maximum hops stp max-hops hops Optional
of the MST region
20 by default
n A larger maximum hops setting means a larger size of the MST region. Only the
maximum hops configured on the regional root bridge can restrict the size of the
MST region.
# Set the maximum hops of the MST region to 30.
[Sysname] stp max-hops 30

Configuring the Any two stations in a switched network are interconnected through specific paths,
Network Diameter of a which are composed of a series of devices. Represented by the number of devices
Switched Network on a path, the network diameter is the path that comprises more devices than any
other among these paths.
Follow these steps to configure the network diameter of the switched network:

Configure the network diameter of the stp bridge-diameter Optional
switched network bridge-number
7 by default
n ■ Network diameter is a parameter that indicates network size. A bigger network

diameter represents a larger network size.
■ Based on the network diameter you configured, MSTP automatically sets an
optimal hello time, forward delay, and max age for the device.
■ The configured network diameter is effective for the CIST only, and not for
MSTIs.
# Set the network diameter of the switched network to 6.
[Sysname] stp bridge-diameter 6
Configuring Timers of MSTP involves three timers: forward delay, hello time and max age. You can
MSTP configure these three parameters for MSTP to calculate spanning trees.
Follow these steps to configure the timers of MSTP:

Configure the forward delay stp timer forward-delay Optional
timer centi-seconds
1,500 centiseconds (15
seconds) by default
Configure the hello time timer stp timer hello centi-seconds Optional
200 centiseconds (2 seconds)
by default
Configuring the max age stp timer max-age Optional
timer centi-seconds
2,000 centiseconds (20
seconds) by default
These three timers set on the root bridge of the CIST apply on all the devices on
the entire switched network.
c CAUTION:
■ The length of the forward delay time is related to the network diameter of the
switched network. Typically, the larger the network diameter is, the longer the

forward delay time should be. Note that if the forward delay setting is too
small, temporary redundant paths may be introduced; if the forward delay
setting is too big, it may take a long time for the network to resume
connectivity. We recommend that you use the default setting.
■ An appropriate hello time setting enables the device to timely detect link
failures on the network without using excessive network resources. If the hello
time is set too long, the device will take packet loss on a link for link failure and
trigger a new spanning tree computing process; if the hello time is set too
short, the device will send repeated configuration BPDUs frequently, which
adds to the device burden and causes waste of network resources. We
recommend that you use the default setting.
■ If the max age time setting is too small, the network devices will frequently
launch spanning tree computing and may take network congestion to a link
failure; if the max age setting is too large, the network may fail to timely detect
link failures and fail to timely launch spanning tree computing, thus reducing
the auto-sensing capability of the network. We recommend that you use the
default setting.
The setting of hello time, forward delay and max age must meet the following
formulae; otherwise network instability will frequently occur.
■ 2 × (forward delay - 1 second) ƒ max age

■ Ma x age ƒ 2 × (hello time + 1 second)
We recommend that you specify the network diameter in the stp

bridge-diameter bridge-number command and let MSTP automatically calculate
an optimal setting of these three timers.
# Set the forward delay to 1,600 centiseconds, hello time to 300 centiseconds,
and max age to 2,100 centiseconds.
[Sysname] stp timer forward-delay 1600
[Sysname] stp timer hello 300
[Sysname] stp timer max-age 2100
Configuring the Timeout After the network topology is stabilized, each non-root-bridge device forwards
Factor configuration BPDUs to the surrounding devices at the interval of hello time to
check whether any link is faulty. Typically, if a device does not receive a BPDU from
the upstream device within nine times the hello time, it will assume that the
upstream device has failed and start a new spanning tree computing process.
In a very stable network, this kind of spanning tree computing may occur because
the upstream device is busy. In this case, you can avoid such unwanted spanning
tree computing by lengthening the timeout time.
Follow these steps to configure the timeout factor:



Configure the timeout factor stp timer-factor number Optional
of the device
3 by default
Timeout time = timeout factor × 3 × hello time.

n ■
■ Typically, we recommend that you set the timeout factor to 5, or 6, or 7 for a

stable network.
# Set the timeout factor to 6.
[Sysname] stp timer-factor 6
Configuring the The maximum transmission rate of a port refers to the maximum number of MSTP
Maximum Transmission packets that the port can send within each hello time.
Rate of Ports
The maximum transmission rate of an Ethernet port is related to the physical
status of the port and the network structure.
Following these steps to configure the maximum transmission rate of a port or a
group of ports:

Enter Ethernet Enter Ethernet interface interface-type User either command
or port group
Enter port port-group { manual interface view, the setting is
view
group view port-group-name | effective on the current port
aggregation agg-id } only; configured in port
group view, the setting is
effective on all ports in the
port group.
Configure the maximum stp transmit-limit Optional
transmission rate of the port(s) packet-number
10 by default
n ■ If the maximum transmission rate setting of a port is too big, the port will send
a large number of MSTP packets within each hello time, thus using excessive
network resources. We recommend that you use the default setting.
■ Refer to “Aggregation Port Group” on page 349 for information about port
groups.
# Set the maximum transmission rate of port Ethernet 1/0 to 5.
[Sysname-Ethernet1/0] stp transmit-limit 5

Configuring Ports as If a port directly connects to a user terminal rather than another device or a shared
Edge Ports LAN segment, this port is regarded as an edge port. When a network topology
change occurs, an edge port will not cause a temporary loop. Therefore, if you
specify a port as an edge port, this port can transition rapidly from the blocked
state to the forwarding state without delay.
Following these steps to specify a port or a group of ports as edge port(s):

or port group
view
port group.
Configure the port(s) as edge stp edged-port enable Required
port(s)
All Ethernet ports are
non-edge ports by default
n ■ With BPDU guard disabled, when a port set as an edge port receives a BPDU
from another port, it will become a non-edge port again. In this case, you must
reset the port before you can configure it to be an edge port again.
■ If a port directly connects to a user terminal, configure it to be an edge port
and enable BPDU guard for it. This enables the port to transition to the
forwarding state while ensuring network security.
# Configure Ethernet1/0 to be an edge port.
[Sysname-Ethernet1/0] stp edged-port enable
Configuring Whether A point-to-point link is a link directly connecting with two devices. If the two ports
Ports Connect to across a point-to-point link are root ports or designated ports, the ports can
Point-to-Point Links rapidly transition to the forwarding state after a proposal-agreement handshake
process.
Following these steps to configure whether a port or a group of ports connect to
point-to-point links:



or port group
view
port group.
Configure whether the port(s) stp point-to-point { auto | Optional
connect to point-to-point links force-false | force-true }
The default setting is auto;
namely the device
automatically detects
whether an Ethernet port
connects to a point-to-point
link
n ■ As for aggregated ports, all ports can be configured as connecting to

point-to-point links. If a port works in auto-negotiation mode and the
negotiation result is full duplex, this port can be configured as connecting to a
point-to-point link.
■ If a port is configured as connecting to a point-to-point link, the setting takes
effect for the port in all MST instances. If the physical link to which the port
connects is not a point-to-point link and you force it to be a point-to-point link
by configuration, the configuration may incur a temporary loop.
# Configure port Ethernet 1/0 as connecting to a point-to-point link.
[Sysname-Ethernet1/0] stp point-to-point force-true
Configuring the Mode a A port can send/recognize MSTP packets that are of the following two formats:
Port Uses to ■ 802.1s-compliant standard format
Recognize/Send MSTP
Packets ■ Compatible format
By default, the packet format recognition mode of a port is auto, namely the port
automatically distinguishes the two MSTP packet formats, and determines the
format of packets it will send based on the recognized format. You can configure
the MSTP packet format to be used by a port. After the configuration, when
working in MSTP mode, the port sends and receives only MSTP packets of the
format you have configured to communicate with devices that send the same
format of packets.
Follow these steps to configure the mode a port uses to recognize/send MSTP
packets:



or port group
view
port group.
Configure the mode the port stp compliance { auto | Optional
uses to recognize/send MSTP dot1s | legacy }
auto by default
packets
n ■ In MSTP mode, if a port is configured to recognize/send MSTP packets in a

mode other than auto, and if it receives a packet in the format different from
the specified type, that port will become a designated port and remain in the
discarding state to prevent the occurrence of a loop.
■ If a port receives MSTP packets of different formats frequently, this means that
the MSTP packet formation configuration contains error. In this case, if the port
is working in MSTP mode, it will be disabled for protection. Those ports closed
thereby can be restored only by the network administers.
# Configure Ethernet 1/0 to receive and send only standard-format MSTP packets.
[Sysname-Ethernet1/0] stp compliance dot1s
Enabling the Output of In a large-scale, MSTP-enabled network, there are a large number of MSTP
Port State Transition instances, so ports may frequently transition from one state to another. In this
Information situation, you can enable the device to output the port state transition information
of all STP instances or the specified STP instance so as to monitor the port states in
real time.
Follow these steps to enable output of port state transition information:

Enable output of port state stp port-log { all | instance Optional
transition information of all instance-id }
Whether this function is
instances or a particular
enabled by default varies with
instance
device models.
Enabling the MSTP Configuration procedure

Feature Follow these steps to enable the MSTP feature:

Enable the MSTP feature for stp enable Required
the device
Disabled by default


or port group
view
port group.
Enable the MSTP feature for stp enable Optional
the port(s)
By default, MSTP is enabled
for all ports after it is enabled
for the device globally
n ■ You must enable MSTP for the device before any other MSTP-related
configuration can take effect.
■ To control MSTP flexibly, you can use the stp disable or undo stp command
to disable the MSTP feature for certain ports so that they will not take part in
spanning tree computing and thus to save the device’s CPU resources.
# Enable MSTP for the device and disable MSTP for port Ethernet 1/0.
[Sysname] stp enable
[Sysname-Ethernet1/0] stp disable
Configuring Leaf
Nodes
Configuring an MST Refer to “Configuring an MST Region” on page 459.

Region
Configuring the Work Refer to “Configuring the Work Mode of MSTP Device” on page 462.
Mode of MSTP
Configuring the Timeout Refer to “Configuring Timers of MSTP” on page 464.

Factor
Configuring the Refer to “Configuring the Maximum Transmission Rate of Ports” on page 466.
Maximum Transmission
Rate of Ports
Configuring Ports as Refer to “Configuring Ports as Edge Ports” on page 467.

Edge Ports
Configuring Path Costs Path cost is a parameter related to the rate of port-connected links. On an
of Ports MSTP-compliant device, ports can have different priorities in different MST

instances. Setting an appropriate path cost allows VLAN traffic flows to be

forwarded along different physical links, thus to enable per-VLAN load balancing.
The device can automatically calculate the default path cost; alternatively, you can
also configure the path cost for ports.
Specifying a standard that the device uses when calculating the default
path cost
You can specify a standard for the device to use in automatic calculation for the
default path cost. The device supports the following standards:
■ dot1d-1998: The device calculates the default path cost for ports based on
IEEE 802.1D-1998.
■ dot1t: The device calculates the default path cost for ports based on IEEE
802.1t.
■ legacy: The device calculates the default path cost for ports based on a private
standard.
Follow these steps to specify a standard for the device to use when calculating the
default path cost:

Specify a standard for the device stp pathcost-standard Optional
to use when calculating the { dot1d-1998 | dot1t | legacy }
legacy by default
default path cost of the link
connected with the device
Table 16 Link speed vs. path cost
Link speed Duplex state 802.1D-1998 802.1t Private standard

0 - 65535 200,000,000 200,000
10 Mbps Single Port 100 2,000,000 2,000
Aggregated 100 1,000,000 1,800
Link 2 Ports
100 666,666 1,600
Aggregated
100 500,000 1,400
Link 3 Ports
Aggregated
Link 4 Ports
100 Mbps Single Port 19 200,000 200
Aggregated 19 100,000 180
Link 2 Ports
19 66,666 160
Aggregated
19 50,000 140
Link 3 Ports
Aggregated
Link 4 Ports

Table 16 Link speed vs. path cost
Link speed Duplex state 802.1D-1998 802.1t Private standard

1000 Mbps Single Port 4 20,000 20
Link 2 Ports
4 6,666 16
Aggregated
4 5,000 14
Link 3 Ports
Aggregated
Link 4 Ports
10 Gbps Single Port 2 2,000 2
Link 2 Ports
2 666 1
Aggregated
2 500 1
Link 3 Ports
Aggregated
Link 4 Ports
n In the calculation of the path cost value of an aggregated link, 802.1D-1998 does
not take into account the number of ports in the aggregated link. Whereas,
802.1T takes the number of ports in the aggregated link into account. The
calculation formula is: Path Cost = 200,000,000/link speed (in 100 kbps), where
link speed is the sum of the link speed values of the non-blocked ports in the
aggregated link.
Configuring Path Costs of Ports

Follow these steps to configure the path cost of ports:

or port group
view
port group.
Configure the path cost of the stp [ instance instance-id ] Optional
port(s) cost cost
By default, MSTP
automatically calculates the
path cost of each port
c CAUTION:
■ If you change the standard that the device uses in calculating the default path
cost, the port path cost value set through the stp cost command will be out of
effect.
■ When the path cost of a port is changed, MSTP will re-compute the role of the
port and initiate a state transition. If you use 0 as instance-id, you are setting
the path cost of the CIST.

Configuring Port Priority The priority of a port is an import basis that determines whether the port can be
elected as the root port of device. If all other conditions are the same, the port
with the highest priority will be elected as the root port.
On an MSTP-compliant device, a port can have different priorities in different MST

instances, and the same port can play different roles in different MST instances, so
that data of different VLANs can be propagated along different physical paths,
thus implementing per-VLAN load balancing. You can set port priority values
based on the actual networking requirements.
Follow these steps to configure the priority of a port or a group of ports:

or port group
view
port group.
Configure port priority stp [ instance instance-id ] Optional
port priority priority
128 for all Ethernet ports by
default
n ■ When the priority of a port is changed, MSTP will re-compute the role of the
port and initiate a state transition.
■ Generally, a lower configured value priority indicates a higher priority of the
port. If you configure the same priority value for all the Ethernet ports on the a
device, the specific priority of a port depends on the index number of that port.
Changing the priority of an Ethernet port triggers a new spanning tree
computing process.
# Set the priority of port Ethernet 1/0 to 16 in MST instance 1.
[Sysname-Ethernet1/0] stp instance 1 port priority 16
Configuring Whether Refer to “Configuring Whether Ports Connect to Point-to-Point Links” on page
Ports Connect to 467.
Point-to-Point Links
Configuring the Mode a Refer to “Configuring the Mode a Port Uses to Recognize/Send MSTP Packets” on
Port Uses to page 468.
Recognize/Send MSTP
Packets

Enabling Output of Port Refer to “Enabling the Output of Port State Transition Information” on page 469.
State Transition
Information
Enabling the MSTP Refer to “Enabling the MSTP Feature” on page 469.
Feature
Performing mCheck Ports on an MSTP-compliant device have three working modes: STP compatible
mode, RSTP mode, and MSTP mode.
In a switched network, if a port on the device running MSTP (or RSTP) connects to
a device running STP, this port will automatically migrate to the STP-compatible
mode. However, if the device running STP is removed, this will not be able to
migrate automatically to the MSTP (or RSTP) mode, but will remain working in the
STP-compatible mode. In this case, you can perform an mCheck operation to force
the port to migrate to the MSTP (or RSTP) mode.
You can perform mCheck on a port through two approaches, which lead to the
same result.
Configuration MSTP has been correctly configured on the device.

Prerequisites
Configuration Procedure Perform global mCheck

Follow these steps to perform global mCheck:

Perform mCheck stp mcheck Required
Perform mCheck in Ethernet interface view

Follow these steps to perform mCheck in Ethernet interface view:

interface-number
Perform mCheck stp mcheck Required
c CAUTION: The stp mcheck command is meaningful only when the device works
in the MSTP (or RSTP) mode, not in the STP-compatible mode.
Configuration Example # Perform mCheck on port Ethernet 1/0.
Method 1: Perform mCheck globally.
[Sysname] stp mcheck

Configuring Digest Snooping 475
Method 2: Perform mCheck in Ethernet interface view
[Sysname-Ethernet1/0] stp mcheck
Configuring Digest As defined in IEEE 802.1s, interconnected devices are in the same region only
Snooping when the region related configuration (domain name, revision level,
VLAN-to-instance mappings) on them is identical. An MSTP enabled device
identifies devices in the same MST region via checking the configuration ID in
BPDU packets. The configuration ID includes the region name, revision level,
configuration digest that is in 16-byte length and is the result computed via the
HMAC-MD5 algorithm based on VLAN-to-instance mappings.
Since MSTP implementations differ with vendors, the configuration digest

computed using private key is different; hence different vendors’ devices in the
same MST region can not communicate with each other.
Enabling the Digest Snooping feature on the associated port can make a device
communicate with another vendor’s device in the same MST region.
Configuration Associated devices of different vendors are interconnected and run MSTP.
Prerequisites
Configuration Procedure Follow these steps to configure Digest Snooping:

or port group
view
port group.
Enable digest snooping on the stp config-digest-snooping Required
interface
Enable digest snooping stp config-digest-snooping Optional
globally
c CAUTION:
■ You can only enable the Digest Snooping feature on the device connected to
another vendor’s device that use private key to compute the configuration
digest.
■ With the Digest Snooping feature enabled, comparison of configuration digest
is not needed for in-the-same-region check, so the VLAN-to-instance mappings
must be the same on associated ports.

■ With global Digest Snooping enabled, modification of VLAN-to-instance

mappings and removing of the current region configuration using the undo
stp region-configuration command are not allowed. You can only modify
the region name and revision level.
■ You need to enable this feature both globally and on associated ports to make
it take effect. It is recommended to enable the feature on all associated ports
first and then globally, making all configured ports take effect, and disable the
feature globally to disable it on all associated ports.
■ It is not recommended to enable Digest Snooping on the MST region edge port
to avoid loops.
■ It is recommended to enable Digest Snooping first and then MSTP. Do not
enable Digest Snooping when the network works well to avoid traffic
interruption.
Configuration Example Network requirements

■ Device A and Device B connect to a third-party’s router and all the routers are in
the same region.
■ Enable Digest Snooping on Device A and Device B so that the three routers can
communicate with one another.
Network diagram
Figure 132 Digest Snooping configuration
Third -party device
Root port
Designated port
Eth 1 /1 Eth 1 /0 Blocked port
Eth 1 /0 Eth 1 /1
Eth 1 / 1 Eth 1/ 0
Device A Device B
1 Enable Digest Snooping on Device A.
# Enable Digest Snooping on Ethernet 1/0.
[DeviceA-Ethernet1/0] stp config-digest-snooping
# Enable global Digest Snooping.
[DeviceA] stp config-digest-snooping
2 Enable Digest Snooping on Device B (the same as above, omitted).

Configuring No Agreement Check 477
Configuring No Two types of packet are used for rapid state transition on designated RSTP and
Agreement Check MSTP ports:
■ Proposal: Packets sent by designated ports to request rapid transition
■ Agreement: Packets used to acknowledge rapid transition requests
Both RSTP and MSTP devices can perform rapid transition operation on a
designated port only when the port receives an agreement packet from the
downstream device. The differences between RSTP and MSTP devices are:
■ For MSTP, the downstream device’s root port sends an agreement packet only
after it receives an agreement packet from the upstream device.
■ For RSTP, the down stream device sends an agreement packet regardless of
whether an agreement packet from the upstream device is received.
Figure 133 and Figure 134 show the rapid state transition mechanism on MSTP
and RSTP designated ports.
Figure 133 Rapid state transition mechanism on the MSTP designated port
Upstream switch Downstream switch
Proposal for rapid transition Root port blocks other

non-edge ports
Agreement Root port changes to forwarding
to upstream switch
em ent
Agr e
Designated port Root port
changes to
Designated port
forwarding state
Figure 134 Rapid state transition mechanism on the RSTP designated port
Upstream switch Downstream switch
Proposal for rapid transition

Root port blocks other non -
edge ports, changes to
forwarding state and sends
agreement packet to upstream
ent switch
em
Agr e
Designated port Root port

changes to
Designated port
forwarding state
If the upstream device comes from another vendor, the rapid state transition
implementation may be limited. For example, when the upstream device adopts
RSTP, the downstream device adopts MSTP and does not support RSTP mode, the
root port on the downstream device receives no agreement packet from the

upstream device and thus sends no agreement packets to the upstream device. As
a result, the designated port of the upstream device fails to transit rapidly and can
only change to the Forwarding state after a period twice the Forward Delay.
In this case, you can enable the No Agreement Check feature on the downstream
device’s port to perform rapid state transition.
Prerequisites ■ A device is the upstream one that is connected to another vendor’s MSTP
supported device via a point-to-point link.
■ Configure the same region name, revision level and VLAN-to-instance
mappings on the two devices, making them in the same region.
Configuration Procedure Following these steps to configure No Agreement Check:

or port group
view
port group.
Enable No Agreement Check stp no-agreement-check Required
n The No Agreement Check feature can only take effect on the root port or
Alternate port after enabled.

■ Device A connects to a third-party’s device that has a different MSTP
implementation. Both devices are in the same region.
■ The third-party’s device is the regional root bridge, and device A is the
downstream device.
Network diagram
Figure 135 No Agreement Check configuration
Third-party device
Eth 1/1
Eth 1/0
Root port
Designated port
Device A

Configuring Protection Functions 479
# Enable No Agreement Check on Ethernet 1/0 of Device A.
<DeviceA > system-view
[DeviceA-Ethernet1/0] stp no-agreement-check
Configuring An MSTP-compliant device supports the following protection functions:

Protection Functions ■ BPDU guard
■ Root guard
■ Loop guard
■ TC-BPDU attack guard
n Among loop guard, root guard and edge port setting, only one function can take
effect on the same port at the same time.
Configuration MSTP has been correctly configured on the device.

prerequisites
Enabling BPDU Guard
n We recommend that you enable BPDU guard on your device.
For access layer devices, the access ports generally connect directly with user
terminals (such as PCs) or file servers. In this case, the access ports are configured
as edge ports to allow rapid transition of these ports. When these ports receive
configuration BPDUs, the system will automatically set these ports as non-edge
ports and starts a new spanning tree computing process. This will cause network
topology instability. Under normal conditions, these ports should not receive
configuration BPDUs. However, if someone forges configuration BPDUs
maliciously to attack the devices, network instability will occur.
MSTP provides the BPDU guard function to protect the system against such
attacks. With the BPDU guard function enabled on the devices, when edge ports
receive configuration BPDUs, MSTP will close these ports and notify the NMS that
these ports have been closed by MSTP. Those ports closed thereby can be restored
only by the network administers.
Following these steps to enable BPDU guard:

Enable the BPDU guard stp bpdu-protection Required
function for the device
Disabled by default
Enabling Root Guard
n We recommend that you enable root guard on your device.

The root bridge and secondary root bridge of a panning tree should be located in
the same MST region. Especially for the CIST, the root bridge and secondary root
bridge are generally put in a high-bandwidth core region during network design.
However, due to possible configuration errors or malicious attacks in the network,
the legal root bridge may receive a configuration BPDU with a higher priority. In
this case, the current legal root bridge will be superseded by another device,
causing undesired change of the network topology. As a result of this kind of
illegal topology change, the traffic that should go over high-speed links is drawn
to low-speed links, resulting in network congestion.
To prevent this situation from happening, MSTP provides the root guard function
to protect the root bridge. If the root guard function is enabled on a port, this port
will keep playing the role of designated port on all MST instances. Once this port
receives a configuration BPDU with a higher priority from an MST instance, it
immediate sets that instance port to the listening state, without forwarding the
packet (this is equivalent to disconnecting the link connected with this port). If the
port receives no BPDUs with a higher priority within twice the forwarding delay,
the port will revert to its original state.
Follow these steps to enable root guard:

or port group
view
port group.
Enable the root guard function stp root-protection Required
for the ports(s)
Disabled by default
Enabling Loop Guard
n We recommend that you enable loop guard on your device.
By keeping receiving BPDUs from the upstream device, a device can maintain the
state of the root port and other blocked ports. However, due to link congestion or
unidirectional link failures, these ports may fail to receive BPDUs from the
upstream device. In this case, the downstream device will reselect the port roles:
those ports failed to receive upstream BPDUs will become designated ports and
the blocked ports will transition to the forwarding state, resulting in loops in the
switched network. The loop guard function can suppress the occurrence of such
loops.
If a loop guard-enabled port fails to receive BPDUs from the upstream device, and
if the port took part in STP computing, all the instances on the port, no matter
what roles they play, will be set to, and stay in, the Discarding state.
Follow these steps to enable loop guard:

Displaying and Maintaining MSTP 481

or port group
view
port group.
Enable the loop guard function stp loop-protection Required
for the ports(s)
Disabled by default
Enabling TC-BPDU When receiving a TC-BPDU (a PDU used as notification of topology change), the
Attack Guard device will delete the corresponding forwarding address entry. If someone forges
TC-BPDUs to attack the device, the device will receive a larger number of
TC-BPDUs within a short time, and frequent deletion operations bring a big
burden to the device and hazard network stability.
With the TC-BPDU guard function enabled, the device limits the maximum
number of times of immediately deleting forwarding address entries within 10
seconds after it receives TC-BPDUs to the value set with the stp tc-protection
threshold command (assume the value is X). At the same time, the system
monitors whether the number of TC-BPDUs received within that period of time is
larger than X. If so, the device will perform another deletion operation after that
period of time elapses. This prevents frequent deletion of forwarding address
entries.
Follow these steps to enable TC-BPDU attack guard

Enable the TC-BPDU attack guard stp tc-protection enable Optional
function
Enabled by default
Configure the maximum number of stp tc-protection threshold Optional
times the device deletes forwarding number
6 by default
address entries within a certain
period of time immediately after it
receives a TC-BPDU
n We recommend that you keep this function enabled.
Displaying and
Maintaining MSTP To do... Use the command... Remarks
View the information about the display stp abnormal-port Available in any view
ports that are blocked abnormally
View the information about the display stp down-port Available in any view
port blocked by STP


View the information of port role display stp [ instance Available in any view
calculation history for the specified instance-id ] history
MSTP instance or all MSTP
instances
View the statistics of TC/TCN display stp [ instance Available in any view
BPDUs sent and received by all instance-id ] tc
ports in the specified MSTP
instance or all MSTP instances
View the status information and display stp [ instance Available in any view
statistics information of MSTP instance-id ] [ interface
interface-list ] [ brief ]
View the MST region display stp Available in any view
configuration information that has region-configuration
taken effect
View root bridge information of all display stp root Available in any view
MSTP instances
View the list of VLANs with VLAN display stp ignored-vlan Available in any view
Ignore enabled
Clear the statistics information of reset stp [ interface Available in user view
MSTP interface-list ]
MSTP Configuration Network requirements

Example Configure MSTP so that packets of different VLANs are forwarded along different
spanning trees. The specific configuration requirements are as follows:
■ All devices on the network are in the same MST regions.
■ Packets of VLAN 10 are forwarded along MST region 1, those of VLAN 30 are
forwarded along MST instance 3, those of VLAN 40 are forwarded along MST
instance 4, and those of VLAN 20 are forwarded along MST instance 0.
■ Device A and Device B are convergence layer devices, while Device C and
Device D are access layer devices. VLAN 10 and VLAN 30 are terminated on the
convergence layer devices, and VLAN 40 is terminated on the access layer
devices, so the root bridges of MST instance 1 and MST instance 3 are Device A
and Device B respectively, while the root bridge of MST instance 4 is Device C.
Network diagram
Figure 136 Network diagram for MSTP configuration
Device A Device B
Permit: all VLAN s
Permit: Permit:
VLANs 10, 20 VLANs 20, 30
Permit: Permit:
VLANs 10, 20 VLANs 20, 30
Permit: VLANs 20, 40

Device C Device D

n “Permit:” beside each link in the figure is followed by the VLANs the packets of
which are permitted to pass this link.
1 Configuration on Device A
# Enter MST region view.
[DeviceA] stp region-configuration
[DeviceA-mst-region] region-name example
[DeviceA-mst-region] instance 1 vlan 10
[DeviceA-mst-region] revision-level 0
# Configure the region name, VLAN-to-instance mappings and revision level of the
MST region.
[DeviceA-mst-region] active region-configuration

[DeviceA-mst-region] quit
# Define Device A as the root bridge of MST instance 1.
[DeviceA] stp instance 1 root primary
# View the MST region configuration information that has taken effect.
[DeviceA] display stp region-configuration

Oper configuration
Format selector :0
Region name :example
Revision level :0
Instance Vlans Mapped

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
4 40
2 Configuration on Device B
[DeviceB] stp region-configuration
[DeviceB-mst-region] region-name example
[DeviceB-mst-region] instance 1 vlan 10
[DeviceB-mst-region] revision-level 0
MST region.
[DeviceB-mst-region] active region-configuration

[DeviceB-mst-region] quit

# Define Device B as the root bridge of MST instance 3.
[DeviceB] stp instance 3 root primary
[DeviceB] display stp region-configuration

Oper configuration
Format selector :0
Revision level :0

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
4 40
3 Configuration on Device C
<DeviceC> system-view
[DeviceC] stp region-configuration
[DeviceC-mst-region] region-name example
[DeviceC-mst-region] instance 1 vlan 10
[DeviceC-mst-region] revision-level 0
MST region.
[DeviceC-mst-region] active region-configuration

[DeviceC-mst-region] quit
# Define Device C as the root bridge of MST instance 4.
[DeviceC] stp instance 4 root primary
[DeviceC] display stp region-configuration

Oper configuration
Format selector :0
Revision level :0

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
4 40
4 Configuration on Device D

<DeviceD> system-view
[DeviceD] stp region-configuration
[DeviceD-mst-region] region-name example
[DeviceD-mst-region] instance 1 vlan 10
[DeviceD-mst-region] revision-level 0
MST region.
[DeviceD-mst-region] active region-configuration

[DeviceD-mst-region] quit
[DeviceD] display stp region-configuration

Oper configuration
Format selector :0
Revision level :0

0 1 to 9, 11 to 29, 31 to 39, 41 to 4094
1 10
3 30
4 40


VLAN CONFIGURATION
24
When configuring VLAN, go to these sections for information you are interested
in:
■ “Introduction to VLAN” on page 487
■ “Configuring Basic VLAN Attributes” on page 489
■ “Configuring VLAN Interface Basic Attributes” on page 490
■ “Configuring a Port-Based VLAN” on page 491
■ “Displaying and Maintaining VLAN” on page 494
■ “VLAN Configuration Examples” on page 495
Introduction to VLAN
VLAN Overview Ethernet is a network technique based on CSMA/CD (carrier sense multiple
access/collision detect) mechanism. As the medium is shared in an Ethernet,
network performance degrades with the increasing of the number of the hosts in
the network. If the number of the hosts in the network reaches a certain level,
problems caused by collisions, broadcasts, and so on emerge, which may cause
the network operating improperly. Although switch prevents collisions between
LANs, it still cannot block broadcast packets. VLAN, however, divides a LAN into
multiple logical LANs, with each being a broadcast domain. Hosts in the same
VLAN can communicate with each other just like in a LAN, and hosts from
different VLANs cannot communicate directly. In this way, broadcast packets are
confined in VLANs, as illustrated in the following figure.
Figure 137 A VLAN diagram
VLAN 2 VLAN 2
Switch A Switch B
Router
VLAN 5 VLAN 5

488 CHAPTER 24: VLAN CONFIGURATION
A VLAN is not restricted by physical factors, that is to say, hosts that reside in
different network segments may belong to the same VLAN, users in a VLAN can
be connected to the same switch, or span across multiple switches or routers.
VLAN technology has the following advantages:
1 Broadcast traffic is confined to each VLAN, reducing bandwidth utilization and

improving network performance.
2 LAN security is improved. Packets in different VLANs cannot communicate with
each other directly. That is, users in a VLAN cannot interact directly with users in
other VLANs, unless routers or Layer 3 switches are used.
3 A more flexible way to establish virtual working groups. With VLAN technology,
clients can be allocated to different working groups, and users from the same
group do not have to be within the same physical area, making network
construction and maintenance much easier and more flexible.
VLAN Fundamental To enable packets being distinguished by the VLANs they belong to, a field used to
identify VLANs is added to packets. As common switches operate on the data link
layer of the OSI model, they only process Layer 2 encapsulation information and
the field thus needs to be inserted to the Layer 2 encapsulation information of
packets.
The format of the packets carrying the fields identifying VLANs is defined in IEEE
802.1Q, which is issued in 1999.
In the header of a traditional Ethernet packet, the field following the destination
MAC address and the source MAC address is protocol type, which indicates the
upper layer protocol type. Figure 138 illustrates the format of a traditional
Ethernet packet, where DA stands for destination MAC address, SA stands for
source MAC address, and Type stands for upper layer protocol type.
Figure 138 The format of a traditional Ethernet packet
DA&SA Type Data
IEEE802.1Q defines a four-byte VLAN Tag field between the DA&SA field and the
Type field to carry VLAN-related information, as shown in Figure 139.
Figure 139 The position and the format of the VLAN Tag field
VLAN Tag
DA&SA TPID Priority CFI VLAN ID Type
The VLAN Tag field comprises four sub-fields: the tag protocol identifier (TPID)
field, the Priority field, the canonical format indicator (CFI) field, and the VLAN ID
field.
■ The TPID field, 16 bits in length and with a value of 0x8100, indicates that a
packet carries a VLAN tag with it.

Configuring Basic VLAN Attributes 489
■ The Priority field, three bits in length, indicates the 802.1p priority of a packet.
For information about packet priority, refer to “Priority Mapping” on page
1675.
■ The CFI field, one bit in length, specifies whether or not the MAC addresses are
encapsulated in standard format when packets are transmitted across different
medium. With the field set to 0, MAC addresses are encapsulated in standard
format; with the field set to 1, MAC addresses are encapsulated in
non-standard format. The filed is 0 by default.
■ The VLAN ID field, 12 bits in length and with its value ranging from 0 to 4095,
identifies the ID of the VLAN a packet belongs to. As VLAN IDs of 0 and 4095
are reserved by the protocol, the actual value of this field ranges from 1 to
4094.
A network device determines the VLAN to which a packet belongs to by the VLAN
ID field the packet carries. The VLAN tag determines the way a packet is
processed. For more information, refer to “Introduction to Port-Based VLAN” on
page 491.
n The frame format mentioned here is that of Ethernet II. Besides Ethernet II
encapsulation, other types of encapsulation, including 802.2 LLC, 802.2 SNAP,
and 802.3 raw are also supported. The VLAN tag fields are also added to packets
adopting these encapsulation formats for VLAN identification.
VLAN Classification Based on different criteria, VLANs can be classified into different categories. The
following types are the most commonly used:
■ Port-based
■ MAC address-based
■ Protocol-based
■ IP-subnet-based
■ Policy-based
■ Other types
This chapter covers port-based VLAN, MAC-address-based VLAN, protocol-based

VLAN, and IP-subnet-based VLAN. For ports with all these types of VLANs created
on them, packets of different VLANs are identified in this order by default:
MAC-address-based VLAN, IP-subnet-based VLAN, protocol-based VLAN, and
port-based VLAN.
Configuring Basic Follow the following steps to configure basic VLAN attributes:
VLAN Attributes
Create VLANs vlan { vlan-id1 [ to Optional
vlan-id2 ] | all }
Using this command can create multiple
VLANs.


Enter VLAN view vlan vlan-id Required
The VLAN must be created first before
entering its view; otherwise, using the
command creates a VLAN and enters its
view.
By default, only one default VLAN (that
is, VLAN 1) exists in the system.
Specify a descriptive description text Optional
string for the VLAN
VLAN ID used by default, for example,
"VLAN 0001"
Configuring VLAN Hosts of different VLANs cannot communicate directly. That is, routers or Layer 3
Interface Basic switches are needed for packets to travel across different VLANs. VLAN interfaces
Attributes are used to forward VLAN packets on Layer 3.
VLAN interfaces are Layer 3 virtual interfaces (which do not exist physically on
devices) used for Layer 3 interoperability between different VLANs. Each VLAN can
have one VLAN interface. Packets of a VLAN can be forwarded on network layer
through the corresponding VLAN interface. As each VLAN forms a broadcast
domain, a VLAN can be an IP network segment and the VLAN interface can be the
gateway to enable IP address-based Layer 3 forwarding.
Follow the following steps to configure VLAN interface basic attributes:

Create a VLAN interface or interface vlan-interface Required
enter VLAN interface view vlan-interface-id
This command leads you to VLAN
interface view if the VLAN interface
already exists.
Configure an IP address for ip address ip-address Optional
the VLAN interface { mask | mask-length }
[ sub ]
Specify the descriptive description text Optional
character string for the
VLAN interface name used by
VLAN interface
default
Bring up the VLAN undo shutdown Optional
interface
By default, a VLAN interface is up.
The state of a VLAN interface also
depends on the states of the ports
in the VLAN. If all the ports in the
VLAN are down, the VLAN interface
is down; if one or more ports in the
VLAN are up, the VLAN interface is
up.
If a VLAN interface is manually shut
down, the VLAN interface is always
down regardless of the states of
ports in the VLAN.

n Before creating a VLAN interface, ensure that the corresponding VLAN already
exists. Otherwise, the specified VLAN interface will not be created.
Configuring a
Port-Based VLAN
Introduction to This is the simplest and yet the most effective way of classifying VLANs. It groups
Port-Based VLAN VLAN members by port. After added to a VLAN, a port can forward the packets of
the VLAN.
Port link type

Based on the tag handling mode, a port’s link type can be one of the following
three:
■ Access port: the port only belongs to one VLAN, normally used to connect user
device;
■ Trunk port: the port can belong to multiple VLANs, can receive/send packets for
multiple VLANs, normally used to connect network devices;
■ Hybrid port: the port can belong to multiple VLANs, can receive or send
packets for multiple VLANs, used to connect either user or network devices;
The differences between Hybrid and Trunk port:
■ A Hybrid port allows packets of multiple VLANs to be sent without the Tag
label;
■ A Trunk port only allows packets from the default VLAN to be sent without the
Tag label.
Default VLAN
You can configure the default VLAN for a port. By default, VLAN 1 is the default
VLAN for all ports. However, this can be changed as needed.
■ An Access port only belongs to one VLAN. Therefore, its default VLAN is the
VLAN it resides in and cannot be configured.
■ You can configure the default VLAN for the Trunk port or the Hybrid port as
they can both belong to multiple VLANs.
■ After deletion of the default VLAN using the undo vlan command, the default
VLAN for an Access port will revert to VLAN 1, whereas that for the Trunk or
Hybrid port remains, meaning the port can use a nonexistent VLAN as the
default VLAN.
Configured with the default VLAN, a port handles packets in the following ways:

Inbound packets handling

If no tag is
carried in the If a tag is carried in the Outbound packets
Port type packet packet handling
Access Port Tag the packet ■ Receive the packet if its Strip the Tag and send the
with the default VLAN ID is the same as packet as the VLAN ID is
VLAN ID the default VLAN ID the same with the default
VLAN ID
■ Discard the packet if its
VLAN ID is different
from the default VLAN
ID
Trunk port Check whether ■ Receive the packet if ■ Strip the Tag and send ■
the default VLAN the VLAN ID is in the list the packet if the VLAN
ID of the port is in of VLANs allowed to ID is the same as the
the list of VLANs pass through the port default VLAN ID
allowed to pass
■ Discard the packet if ■ Keep the tag and send
through the port,
the VLAN ID is not in the packet if the VLAN
if yes, tag the
the list of VLANs ID is not the same as
packet with the
allowed to pass the default VLAN ID but
default VLAN ID; if
through the port allowed to pass
no, discard the
through the port
packet
Hybrid port Send the packet if the
VLAN ID is allowed to pass
through the port. Use the
port hybrid vlan
command to configure
whether the port keeps or
strips the tags when
sending packets of a VLAN
(including default VLAN).
Configuring the There are two ways to configure Access-port-based VLAN: one way is to configure
Access-Port-Based VLAN in VLAN view, the other way is to configure in Ethernet port view or port group
view.
Follow the following steps to configure the Access-port-based VLAN:

Enter VLAN view vlan vlan-id Required
The VLAN must be created first
before entering its view
Add an Access port to the port interface-list Required
current VLAN
By default, system will add all ports
to VLAN 1
Follow the following steps to configure the Access-port-based VLAN (in Ethernet
port view or port group view):



port view or port view interface-number
Configured in Ethernet port
port group
Enter port port-group aggregation view, the setting is effective
view
group view agg-id on the current port only;
configured in port group
view, the setting is effective
on all ports in the port group.
Configure the port link type as port link-type access Optional
Access
The link type of a port is
Access by default
Add the current Access port to port access vlan vlan-id Optional
a specified VLAN
By default, all Access ports
belong to VLAN 1
n ■ Ensure that you create a VLAN first before trying to add an Access port to the
VLAN.
group.
Configuring the A Trunk port may belong to multiple VLANs, and you can only perform this
Trunk-Port-Based VLAN configuration in Ethernet port view or port group view.
Follow the following steps to configure the Trunk-port-based VLAN:

port group
view
Configure the port link type as port link-type trunk Required
Trunk
Allow a specified VLAN to pass port trunk permit vlan Required
through the current Trunk port { vlan-id-list | all }
By default, all Trunk ports
belong to VLAN 1 only
Configure the default VLAN port trunk pvid vlan vlan-id Optional
for the Trunk port
VLAN 1 is the default by
default
n ■ To convert a Trunk port into a Hybrid port (or vice versa), you need to use the
Access port as a medium. For example, the Trunk port has to be configured as
an Access port first and then a Hybrid port.
■ The default VLAN ID on the Trunk ports of the local and peer devices must be
the same. Otherwise, packets cannot be transmitted properly.
■ Refer to“Aggregation Port Group” on page 349 for information about port
group.

Configuring the A Hybrid port may belong to multiple VLANs, and this configuration can only be
Hybrid-Port-Based VLAN performed in Ethernet port view or port group view.
Follow the following steps to configure the Hybrid-port-based VLAN:

port group
view
Configure the port link type as port link-type hybrid Required
Hybrid
Allow a specified VLAN to pass port hybrid vlan vlan-id-list Required
through the current Hybrid { tagged | untagged }
By default, all Hybrid ports
port
belong to VLAN 1
Configure the default VLAN of port hybrid pvid vlan Optional
the Hybrid port vlan-id
VLAN 1 is the default by
default
n ■ To configure a Trunk port into a Hybrid port (or vice versa), you need to use the
Access port as a medium. For example, the Trunk port has to be configured as
an Access port first and then a Hybrid port.
■ Ensure that a VLAN already exists before configuring it to pass through a
certain Hybrid port.
■ The default VLAN ID on the Hybrid ports of the local and the peer devices must
be the same. Otherwise, packets of the local default VLAN cannot be
transmitted properly.
groups.
Displaying and
Maintaining VLAN To do... Use the command... Remarks
Display VLAN information display vlan [ vlan-id1 [ to Available in any view
vlan-id2 ] | all | dynamic |
interface-number.subnumber |
reserved | static]
Display VLAN interface display interface vlan-interface Available in any view
information [ vlan-interface-id ]
Clear the statistics on a VLAN reset counters interface Available in user view
interface [ interface-type
[ interface-number ] ]
n The reset counters interface command can be used to clear the statistics on a
VLAN interface. For more information, refer to “Ethernet Interface Configuration”
on page 89.

VLAN Configuration Examples 495
VLAN Configuration Network requirements

Examples ■ Device A connects to Device B through the Trunk port Ethernet 1/0;
■ The default VLAN ID of the port is 100;
■ This port allows packets from VLAN 2, VLAN 6 to VLAN 50, and VLAN 100 to
pass through.
Network diagram
Figure 140 Network diagram for port-based VLAN configuration
Eth1/0
Eth1/0
Device A Device B
# Create VLAN 2, VLAN 6 through VLAN 50, and VLAN 100.
[DeviceA] vlan 2
[DeviceA-vlan2] quit
[DeviceA] vlan 100
[DeviceA-vlan100] vlan 6 to 50
Please wait... Done.
# Enter the Ethernet 1/0 interface view.
[DeviceA] interface Ethernet 1/0
# Configure Ethernet 1/0 as a Trunk port and configure its default VLAN ID as 100.

[DeviceA-Ethernet1/0] port trunk pvid vlan 100
# Configure Ethernet 1/0 to deny packets of VLAN 1 to pass. (All ports allow
packets of VLAN 1 to pass by default.)
[DeviceA-Ethernet1/0] undo port trunk permit vlan 1
# Configure Ethernet 1/0 to permit packets of VLAN 2, VLAN 6 through VLAN 50,
and VLAN 100.
[DeviceA-Ethernet1/0] port trunk permit vlan 2 6 to 50 100

2 Configure Device B following similar steps as that of Device A.
Verification
Verifying the configuration of Device A is similar to that of Device B. so only Device
A is taken for example here.
# Display the information about Ethernet 1/0 of Device A to verify the above
configurations.

<DeviceA> display interface ethernet 1/0

Ethernet1/0 current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0000-5600-0000
Description: Ethernet1/0 Interface
Loopback is not set
Unknown-speed mode, unknown-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation
Flow-control is not enabled
The Maximum Frame Length is 1500
Broadcast MAX-ratio: 100%
Unicast MAX-ratio: 100%
Multicast MAX-ratio: 100%
Allow jumbo frame to pass
PVID: 100
Mdi type: auto
Link delay is 0(sec)
Port link-type: trunk
VLAN passing 2, 6-50, 100
VLAN permitted: 1(default vlan), 2, 6-50, 100
Trunk port encapsulation: IEEE 802.1q
Port priority: 0
Last 300 seconds input: 0 packets/sec 0 bytes/sec
Last 300 seconds output: 0 packets/sec 0 bytes/sec
Input (total): 0 packets, 0 bytes
Input (normal): 0 packets, 0 bytes
Input: 0 input errors, 0 runts, 0 giants, 0 throttles
0 CRC, 0 frame, 0 overruns, 0 aborts
0 ignored, 0 parity errors
Output (total): 0 packets, 0 bytes
0 broadcasts, 0 multicasts, 0 pauses
Output (normal): 0 packets, 0 bytes
0 broadcasts, 0 multicasts, 0 pauses
Output: 0 output errors, 0 underruns, 0 buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
0 lost carrier, 0 no carrier
The output above shows that:
■ The port is a trunk port.

■ The default VLAN is VLAN 100.
■ The port permits packets of VLAN 2, VLAN 6 through VLAN 50, and VLAN 100.
So the configuration is successful.

VOICE VLAN CONFIGURATION
25
When configuring Voice VLAN, go to these sections for information you are
interested in:
■ “Introduction to Voice VLAN” on page 497
■ “Configuring the Voice VLAN” on page 500
■ “Displaying and Maintaining Voice VLAN” on page 501
■ “Voice VLAN Configuration Examples” on page 502
n ■ Voice VLAN automatic mode and secure mode are not supported on MSR 20
series routers.
■ Voice VLAN automatic mode and secure mode are not supported on SIC-4FSW
and DSIC-9FSW modules.
■ Voice VLAN automatic mode and secure mode are supported on 16FSW and
24FSW modules.
Introduction to Voice Voice VLANs are configured specially for voice traffic. By adding the ports that
VLAN connect voice devices to voice VLANs, you can configure quality of service (QOS
for short) attributes for the voice traffic, increasing transmission priority and
ensuring voice quality. A device determines whether a received packet is a voice
packet by checking its source MAC address. Packets containing source MAC
addresses that comply with the voice device Organizationally Unique Identifier
(OUI for short) addresses are regarded as voice traffic, and are forwarded in the
voice VLANs.
You can configure the OUI addresses in advance or use the default OUI addresses
as listed in Table 17.
Table 17 The default OUI addresses of devices
Number OUI address Vendors

1 0001-e300-0000 Siemens phone
2 0003-6b00-0000 Cisco phone
3 0004-0d00-0000 Avaya phone
4 00d0-1e00-0000 Pingtel phone
5 0060-b900-0000 Philips/NEC phone
6 00e0-7500-0000 Polycom phone
7 00e0-bb00-0000 3Com phone

498 CHAPTER 25: VOICE VLAN CONFIGURATION
n ■ As the first 24 bits of a MAC address (in binary format), an OUI address is a
globally unique identifier assigned to a vendor by IEEE (Institute of Electrical
and Electronics Engineers).
■ The default OUI address can be configured/removed manually.
Working Modes of Voice A voice VLAN can operate in two working modes: automatic mode and manual
VLAN mode (the mode here refers to the way of adding a port to a voice VLAN).
■ In automatic mode, the system identifies the source MAC address contained in
the protocol packets (untagged packets) sent when the IP phone is powered on
and matches it against the OUI addresses. If a match is found, the system will
automatically add the port into the Voice VLAN and apply ACL rules to ensure
the packet precedence. An aging time can be configured for the voice VLAN.
The system will remove a port from the voice VLAN if no voice packet is
received from it after the aging time. The adding and deleting of ports are
automatically realized by the system.
■ In manual mode, the IP phone access port needs to be added to the voice
VLAN manually. It then identifies the source MAC address contained in the
packet, matches it against the OUI addresses. If a match is found, the system
issues ACL rules and configures the precedence for the packets. In this mode,
the operation of adding ports to the voice VLAN and removing ports from the
voice VLAN are carried out by the administrators.
■ Both modes forward tagged packets according to their tags.
The following table lists the co-relation between the working modes of a voice
VLAN, the voice traffic type of an IP phone, and the interface modes of a VLAN
interface.
Voice VLAN
operating mode Voice traffic type Interface link type
Automatic mode Tagged voice traffic Access: the traffic type is not supported
Trunk: supported provided that the default
VLAN of the access port exists and is not a
voice VLAN and that the access port belongs
to the voice VLAN
Hybrid: supported provided that the default
voice VLAN. Besides, the default VLAN need to
be in the list of tagged VLANs whose packets
can pass through the access port
Untagged voice traffic Access, Trunk, Hybrid: not supported

Introduction to Voice VLAN 499
Voice VLAN
operating mode Voice traffic type Interface link type
Manual mode Tagged voice traffic Access: not supported
voice VLAN and that the access port belongs
to the default VLAN
Hybrid: supported provided that the default
VLAN of the access port exists and is not the
voice VLAN. Besides, the voice VLAN must be
in the list of tagged VLANs whose packets can
pass through the access port
Untagged voice traffic Access: supported provided that the default
VLAN of the access port is a voice VLAN
VLAN of the access port is a voice VLAN and
that the access port allows packets from the
voice VLAN to pass through
Hybrid port: supported provided that the
default VLAN of the access port is a voice
VLAN and that the voice VLAN is in the list of
untagged VLANs whose packets are allowed
to pass through the access port
c CAUTION:
■ If the voice traffic sent by an IP phone is tagged and that the access port has
802.1x authentication and Guest VLAN enabled, assign different VLAN IDs for
the voice VLAN, the default VLAN of the access port, and the 802.1x guest
VLAN.
■ If the voice traffic sent by an IP phone is untagged, to realize the voice VLAN
feature, the default VLAN of the access port can only be configured as the
voice VLAN. Note that at this time 802.1 x authentication function cannot be
realized.
n ■ The default VLANs for all ports are VLAN 1. Using commands, users can either
configure the default VLAN of a port, or configure to allow a certain VLAN to
pass through the port. For more information, refer to “Configuring a
Port-Based VLAN” on page 491.
■ Use the display interface command to display the default VLAN and the
VLANs that are allowed to go through a certain port.
Security Mode and Ports that have the voice VLAN feature enabled can be divided into two modes
Normal Mode of Voice based on their filtering mechanisms applied to inbound packets.
VLAN ■ Security mode: only voice packets with source OUI MAC addresses can pass
through the inbound port (with the voice VLAN feature enabled), other
non-voice packets will be discarded, including authentication packets, such as
802.1 authentication packet.
■ Normal mode: both voice packets and non-voice packets are allowed to pass
through an inbound port (with the voice VLAN feature enabled), the former
will abide by the voice VLAN forwarding mechanism whereas the latter normal
VLAN forwarding mechanism.

It is recommended that you do not mix voice packets with other types of data in a
voice VLAN. If necessary, please ensure that the security mode is disabled.
Configuring the Voice

VLAN
Configuration ■ Create the corresponding VLAN before configuring the voice VLAN;
Prerequisites ■ As a default VLAN, VLAN 1 does not need to be created. However, it cannot be
enabled with the voice VLAN feature.
Configuring Voice VLAN Follow the following steps to configure the voice VLAN under automatic mode:
under Automatic Mode
Configure the aging time of voice vlan aging minutes Optional
the voice VLAN
Only applicable to ports in
automatic mode and defaults
to 1,440 minutes
Enable the security mode of voice vlan security enable Optional
the voice VLAN
Enabled by default
Configure the OUI address for voice vlan mac-address oui Optional
the voice VLAN mask oui-mask [ description
By default, each voice VLAN
text ]
has 8 default OUI addresses as
listed in Table 17.
Enable the global voice VLAN voice vlan vlan-id enable Required
feature
interface-number
Configure the working mode voice vlan mode auto Optional
on a port as automatic
Automatic mode by default
The working mode of the
voice VLAN on each port is
independent of each other.
Enable the voice VLAN feature voice vlan enable Required
on the interface
n ■ The default VLAN of a port in automatic mode cannot be configured as voice

VLAN. Otherwise, the system will prompt error information.
■ Issuing of the voice vlan security enable command and the undo voice
vlan security enable command only takes effect before the voice VLAN
attribute is enabled globally.
Configuring Voice VLAN Follow the following steps to configure the voice VLAN under manual mode:
under Manual Mode
Enable the security mode of a voice vlan security enable Optional
voice VLAN
Enabled by default

Displaying and Maintaining Voice VLAN 501

Configure the OUI address of a voice vlan mac-address oui Optional
voice VLAN mask oui-mask [ description
By default, each voice VLAN
text ]
has 8 default OUI addresses
as listed in Table 17.
Enable the global voice VLAN voice vlan vlan-id enable Required
feature
interface-number
Configure the working mode undo voice vlan mode auto Required
as manual
Disabled by default
Add the ports Access port Refer to “Configuring the Select one of the three
in manual Access-Port-Based VLAN” on operations listed.
mode to the page 492.
After you add an access port
voice VLAN
Trunk port Refer to “Configuring the to a voice VLAN, the voice
Trunk-Port-Based VLAN” on VLAN becomes the default
page 493. VLAN of the port
automatically.
Hybrid port Refer to “Configuring the
Hybrid-Port-Based VLAN” on
page 494.
Configure the Trunk port Refer to “Configuring the Optional
voice VLAN as Trunk-Port-Based VLAN” on
This operation is required if
the default page 493
the input voice traffic is
VLAN of the
Hybrid port Refer to “Configuring the untagged. If the input voice
port
Hybrid-Port-Based VLAN” on traffic is tagged, the voice
page 494. VLAN cannot be configured
as the default VLAN.
Enable the voice VLAN feature voice vlan enable Required
on the port
n ■ At the same time, only one VLAN of a device can have the voice VLAN feature
enabled.
■ A port that has the Link Aggregation Control Protocol (LACP for short) enabled
cannot have the voice VLAN feature enabled at the same time.
■ A dynamic VLAN becomes a static VLAN automatically after it is enabled with
the voice VLAN feature.
■ Issuing of the voice vlan security enable command and the undo voice
vlan security enable command only takes effect before the voice VLAN
feature is enabled globally.
■ If the port is enabled with voice VLAN in manual mode, you need to add the
port to the voice VLAN manually to validate the voice VLAN.
Displaying and
Maintaining Voice To do... Use the command... Remarks
VLAN Display the voice VLAN state display voice vlan state Available in any view
Display the OUI addresses display voice vlan oui Available in any view
currently supported by system

Voice VLAN
Configuration
Examples
A Configuration Network requirement

Examples of the Voice ■ Create VLAN 2 and configure it as a voice VLAN with an aging time of 100
VLAN under Automatic minutes.
Mode
■ The voice traffic sent by the IP phones is tagged. Configure Ethernet 1/1 as a
Hybrid port and as the access port, with VLAN 6 as the default VLAN.
■ The device allows voice packets from Ethernet 1/1 with an OUI address of
0011-2200-0000 and a mask of ffff-ff00-0000 to be forwarded through the
voice VLAN.
Network diagram
Figure 141 Voice VLAN under automatic mode
Device A Device B
Internet
VLAN 2
Eth1/1 Eth2/1
VLAN 2
010-1001 0755 -2002

OUI: 0011 -2200 -0000
Mask: ffff-ff00-0000
# Create VLAN 2 and VLAN 6.
[DeviceA] vlan 2
[DeviceA] vlan 6
# Configure the voice VLAN aging time.
[DeviceA] voice vlan aging 100
# Configure the OUI address 0011-2200-0000 as the legal address of the voice
VLAN.
[DeviceA] voice vlan mac-address 0011-2200-0000 mask ffff-ff00-0000

description test
# Enable the global voice VLAN feature.
[Sysname] voice vlan 2 enable
# Configure the working mode of the voice VLAN of Ethernet 1/1 as automatic.
(Optional, by default, the voice VLAN works in automatic mode)


[Sysname-Ethernet1/1] voice vlan mode auto
# Configure Ethernet 1/1 as a Hybrid port.
[DeviceA-Ethernet1/1] port link-type access

[DeviceA-Ethernet1/1] port link-type hybrid
# Configure the default VLAN of the port as VLAN 6 and allow packets from VLAN
6 to pass through the port.
[DeviceA-Ethernet1/1] port hybrid pvid vlan 6

[DeviceA-Ethernet1/1] port hybrid vlan 6 tagged
# Enable the voice VLAN feature on the port.
[DeviceA-Ethernet1/1] voice vlan enable

[DeviceA-Ethernet1/1] return
Verification
# Display information about the OUI addresses, OUI address masks, and
descriptive strings.
<DeviceA> display voice vlan oui
Oui Address Mask Description
0001-e300-0000 ffff-ff00-0000 Siemens phone
0003-6b00-0000 ffff-ff00-0000 Cisco phone
0004-0d00-0000 ffff-ff00-0000 Avaya phone
0011-2200-0000 ffff-ff00-0000 test
00d0-1e00-0000 ffff-ff00-0000 Pingtel phone
0060-b900-0000 ffff-ff00-0000 Philips/NEC phone
00e0-7500-0000 ffff-ff00-0000 Polycom phone
00e0-bb00-0000 ffff-ff00-0000 3com phone
# Display the current Voice VLAN state.
<DeviceA> display voice vlan state

Voice VLAN status: ENABLE
Voice VLAN ID: 2
Voice VLAN security mode: Security
Voice VLAN aging time: 100 minutes
Voice VLAN enabled port and its mode:
PORT MODE
--------------------------------
Ethernet1/1 AUTO
<DeviceA>
A Configuration Network requirement

Examples of Voice VLAN ■ Create VLAN 2 and configure it as a voice VLAN.
under Manual Mode
■ IP phone type is untagged with the Hybrid port Ethernet 1/1 being the access
port.

■ Ethernet 1/1 works in manual mode. It only allows voice packets with an OUI
address of 0011-2200-0000, a mask of ffff-ff00-0000, and a descriptive string
of “test” to be forwarded.
Network diagram
Figure 142 Voice VLAN under manual mode
Device A Device B
Internet
VLAN 2
Eth1/1 Eth2/1
VLAN 2
010-1001 0755 -2002

OUI: 0011 -2200 -0000
Mask: ffff-ff00-0000
# Configure the voice VLAN to work in security mode and only allows legal voice
packets to pass through the voice VLAN enabled port. (Optional, enabled by
default)
[DeviceA] voice vlan security enable
# Configure the OUI address 0011-2200-0000 as the legal voice VLAN address.
[DeviceA] voice vlan mac-address 0011-2200-0000 mask ffff-ff00-0000

description test
# Create VLAN 2. Enable voice VLAN feature for it.
[DeviceA] vlan 2
[DeviceA] voice vlan 2 enable
# Configure Ethernet 1/1 to work in manual mode.

[DeviceA-Ethernet1/1] undo voice vlan mode auto
# Configure Ethernet 1/1 as a Hybrid port.
[DeviceA-Ethernet1/1]port link-type access

[DeviceA-Ethernet1/1]port link-type hybrid
# Configure the default VLAN of Ethernet 1/1 as voice VLAN and add it to the list
of tagged VLANs whose packets can pass through the port.
[DeviceA-Ethernet1/1] port hybrid pvid vlan 2

[DeviceA-Ethernet1/1] port hybrid vlan 2 untagged
# Enable the voice VLAN feature of Ethernet 1/1.

[DeviceA-Ethernet1/1] voice vlan enable
Verification
# Display information about the OUI addresses, OUI address masks, and
descriptive strings.
<DeviceA> display voice vlan oui
Oui Address Mask Description
0001-e300-0000 ffff-ff00-0000 Simens phone
0003-6b00-0000 ffff-ff00-0000 Cisco phone
0004-0d00-0000 ffff-ff00-0000 Avaya phone
0011-2200-0000 ffff-ff00-0000 test
00d0-1e00-0000 ffff-ff00-0000 Pingtel phone
0060-b900-0000 ffff-ff00-0000 Philips/NEC phone
00e0-7500-0000 ffff-ff00-0000 Polycom phone
00e0-bb00-0000 ffff-ff00-0000 3com phone
# Display the current Voice VLAN state.
<DeviceA> display voice vlan state

Voice VLAN status: ENABLE
Voice VLAN ID: 2
Voice VLAN security mode: Security
Voice VLAN aging time: 100 minutes
Voice VLAN enabled port and its mode:
PORT MODE
--------------------------------
Ethernet1/1 MANUAL


PORT ISOLATION CONFIGURATION
26
When configuring port isolation, go to these sections for information you are
interested in:
■ “Introduction to Port Isolation” on page 507
■ “Configuring Isolation Groups” on page 507
■ “Displaying and Maintaining Isolation Groups” on page 508
■ “Port Isolation Configuration Example” on page 508
Introduction to Port To implement Layer 2 isolation, you can add different ports to different VLANs.
Isolation However, this will waste the limited VLAN resource. With port isolation, the ports
can be isolated within the same VLAN. Thus, you need only to add the ports to the
isolation group to implement Layer 2 isolation. This provides you with more secure
and flexible networking schemes.
Presently:
■ A device supports only one isolation group, which is created automatically by

the system as Isolation Group 1. The user can neither delete this isolation group
nor create any other isolation group.
■ There is no restriction on the number of ports to be added to an isolation
group.
n ■ When a port in an aggregation group is configured as the ordinary port for

some isolation group, the other ports of the aggregation group can be added
to the isolation group as ordinary ports.
■ For details of an aggregation group, refer to “Link Aggregation Overview” on
page 345.
Port isolation is independent of the VLAN the port belongs to. For ports belonging
to different VLANs, Layer 2 data of each port is isolated. Within the same VLAN,
Layer 2 data can be forwarded between ports within the isolation group and ports
outside the isolation group.
Configuring Isolation
Groups
Adding a Port to the Follow these steps to add a port to the isolation group
Isolation Group

508 CHAPTER 26: PORT ISOLATION CONFIGURATION

or port group
view
port group.
Add the port to the isolation port-isolate enable Required
group as an ordinary port
No ports are added to the
isolation group by default.
n Refer to “Aggregation Port Group” on page 349 for information about port
groups.
Displaying and
Maintaining Isolation To do... Use the command... Remarks
Groups Display isolation group display port-isolate group Available in any view
isolation
Port Isolation Networking Requirement

Configuration ■ Users Host A, Host B, and Host C are connected to Ethernet 1/1, Ethernet 1/2,
Example and Ethernet 1/3 of Device.
■ Device is connected to an external network through Ethernet 1/0.
■ Ethernet 1/1, Ethernet 1/2, Ethernet 1/3, and Ethernet 1/0 belong to the same
VLAN. It is desired that Host A, Host B, and Host C cannot exchange Layer 2
frames with each other, but can access the external network.
Networking diagram
Figure 143 Networking diagram for port isolation configuration
Internet
Eth1/0
Device
Eth1/1 Eth1/3
Eth1/2
# Add ports Ethernet 1/1, Ethernet 1/2 and Ethernet 1/3 to the isolation group.

Port Isolation Configuration Example 509
<Device> system-view
[Device] interface ethernet 1/1
[Device-Ethernet1/1] port-isolate enable
[Device-Ethernet1/1] quit
[Device-Ethernet1/2] quit
# Display the information about the isolation group.
<Device> display port-isolate group

Port-isolate group information:
Uplink port support: NO
Group ID: 1
Ethernet1/1 Ethernet1/2 Ethernet1/3

510 CHAPTER 26: PORT ISOLATION CONFIGURATION

DYNAMIC ROUTE BACKUP
27 CONFIGURATION
n Currently, the dynamic route backup function is available to the following dialup
interfaces: dialer interfaces, PRI interfaces, BRI interfaces, serial interfaces
operating in the asynchronous mode, AM interface, and AUX interfaces.
Overview
Concept As a new way of route backup, the dynamic route backup function adopts dial
control center (DCC) to dynamically maintain dialup links, that is, the dynamic
route backup function implements route-based dialup backup.
The dynamic route backup function combines the backup function and the
routing function well, proving reliable connections and standard dial-on-demand
services.
Features The dynamic route backup function is mainly used to backup dynamic routes, and
moreover, it can also backup static routes and directly-connected routes.
The dynamic route backup function is not dedicated a specific interface or link,
and it is appropriate for implementations with multiple interfaces and multiple
routers.
With the dynamic route backup function enabled, the backup link will be started
automatically when the primary link disconnects, causing no dialup delay
(excluding the time for route convergence).
The dynamic route backup function is independent of specific routing protocols,

and it can collaborate with routing information protocol version 1 (RIP-1), RIP-2,
open shortest path first (OSPF), intermedia system-intermedia system (IS-IS),
border gateway protocol (BGP) and so on. However, some routing protocols (such
as BGP) use the preferred routes by default. When the backup link is activated
after the primary link to the monitored network segment is disconnected, it will
learn routes to the monitored network segment through BGP. When the primary
link is activated again, it will learn routes to the monitored network segment
through BGP. However, the routes that the primary link learn may not be the
preferred routes, so the routes learned by the backup link may continue to be
used. In this case, dynamic route monitoring fails, and the backup link cannot be
hanged up even after the primary link restores.
For BGP, you need to take the following measures to solve this problem:
■ Assign a higher IP address to the backup link that that to the primary link

512 CHAPTER 27: DYNAMIC ROUTE BACKUP CONFIGURATION
■ Allow a route to be learned by multiple links through configuring load

balancing
Implementation Through configuring the network segment to be monitored, a backup link can be
enabled when the primary link fails. The dynamic route backup function monitors
routes and activates a backup link in the following sequence:
1 The system monitors whether routes to the monitored network segment need to
be updated, and checks whether there is at least one valid route to the monitored
network segment.
2 If there is at least one valid route to the monitored network segment, and the
route is originated from another interface with the dynamic route backup function
disabled, the primary link is considered to be connective.
3 Otherwise, the primary link is considered to be disabled and unavailable, and the
backup link will be activated for dialup.
4 After the backup link is activated, the dialup link will transfer communication data.
When the primary link restores, the backup link can be either disconnected
immediately or disconnected after the timer expires as configured.
Dynamic Route
Backup Configuration
Creating Dynamic Route You can create dynamic route backup groups in one of the following two ways:
Backup Groups
1 Create multiple dynamic route backup groups, which each monitors different
network segment. The logical relationship among these network segments is
“OR”, that is, the backup link will be activated when there is no valid route to one
of these network segments. For each dynamic route backup group, a link is dialed
or hanged on a dialup interface.
2 Create a multiple dynamic route backup group to monitor multiple network
segments. The logical relationship among these network segments is “AND”, that
is, the backup link will be activated when there is no valid route to any of these
network segments. When the backup link is to be activated, check whether the
dialer route command is enabled on the dialup interfaces of these monitored
network segments in sequence. The backup link is enabled on the first-checked
interface with the dialer route command enabled. Note that only one link can be
activated.
Table 18 Create dynamic route backup groups

Create a dynamic route standby routing-rule Required
backup group and add the group-number ip ip-address
By default, no dynamic route
network segment to be { mask | mask-length }
backup group is created.
monitored to this group
n ■ The IP address specified in the standby routing-rule command must be the

same as that specified in the dialer route command.

■ Refer to “Dynamic Route Backup Configuration” on page 511 for more

information about the dialer route command.
Enabling the Dynamic

Table 19 Enable the dynamic route backup function on a backup interface
Route Backup Function
on a Backup Interface Operation Command Description
interface-number
Enable the dynamic standby routing-group Required
route backup function group-number
By default, the dynamic route backup
function is disabled.
n Before enabling the dynamic route backup function on a backup interface, make
sure that DCC has been enabled on the backup interface.
Configuring Backup Link In order to avoid route instability, you can disconnect the backup link after a
Disconnection Delay specified delay after the primary link is connected.
Table 20 Configure backup link disconnection delay

interface-number
Configure backup link standby timer routing-disable Optional
disconnection delay seconds
By default, the backup link
disconnection delay is 20
seconds.
Dynamic Route
Backup Configuration
Example
Example I Network requirements

■ Router B is connected to Router A and Router C through serial interfaces, and
X.25 is enabled on the two links.
■ Router A and Router C are connected to the ISDN switched network through
ISDN BRI interfaces. Router A and Router C can dial each other. The telephone
number of Router C is 8810052.
■ The serial interfaces are in the network segment 10.0.0.0/8, and the BRI
interfaces are in the network segment 20.0.0.0/8.
■ As the master device of the dynamic route backup function, Router A monitors
the network segment 30.0.0.0/8 on Router C.

Network diagram
Figure 144 Network diagram for dynamic route backup configuration
Router B
X.25 X.25
S2/0 S2/1
S2/0 S2 /1
10.0 .0.1/8 BRI3 /0 BRI3/0 10 .0.0.2/8
Loop 1
20.0.0.1 /8 20.0.0.2/8 30.0.0 .0/8
ISDN
Router A Router C
# Configure a dialer rule.
# Configure dialup parameters for BRI 3/0.

[RouterA-Bri3/0] ip address 20.0.0.1 8
# Configure Serial 2/0 and enable X.25 on it.

[RouterA-Serial2/0] x25 map ip 10.0.0.2 x121-address 15 broadcast
# Configure the dynamic routing protocol RIP.
[RouterA] rip
[RouterA-rip-1] import-route direct
[RouterA-rip-1] quit
# Create a dynamic route backup group.
[RouterA] standby routing-rule 1 ip 30.0.0.1 32
# Configure to make the priority of routes on dialup interfaces lower than that of
serial interfaces.


[RouterA-Bri3/0] rip metricin 2
# Enable the dynamic route backup function.
[RouterA-Bri3/0] standby routing-group 1

# Enable X.25 on Router B.
# Enable switching interfaces for X.25.

# Create two SVC routes.


[RouterC-Bri3/0] ip address 20.0.0.2 8
[RouterC-Bri3/0] quit

[RouterC-Serial2/1] link-protocol x25 dte ietf
[RouterC-Serial2/1] x25 map ip 10.0.0.1 x121-address 10 broadcast
[RouterC-Serial2/1] ip address 10.0.0.2 8
# Configure the interface loopback 1.
[RouterC] interface loopback 1

[RouterC-Loopback1] ip address 30.0.0.1 32
[RouterC-Loopback1] quit

[RouterC] rip
[RouterC-rip-1] network 10.0.0.0
[RouterC-rip-1] import-route direct
Example II Network requirements

■ Router A and Router B are directly connected through a serial interface, and
they are both connected to the ISDN switched network through ISDN BRI
interfaces. Router A and Router B can dial each other. The telephone number
of Router B is 8810052.
■ The serial interfaces are in the network segment 10.0.0.0/8, and the BRI
interfaces are in the network segment 20.0.0.0/8.
the network segment 40.0.0.0/8, which is connected to Loopback1 interface
of Router B.
Network diagram
Router A S2 /0 S 2/0
Router B Loop 1
10 .0.0.1/8 10 .0.0.2/8 40.0.0.1/32
BRI3/0 BRI3/0
20 .0 .0.1/8 20.0 .0.2/8
ISDN

[RouterA-Bri3/0] ip address 20.0.0.1 8


# Configure the dynamic routing protocol OSPF.
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 10.0.0.0 0.255.255.255
[RouterA-ospf-1-area-0.0.0.0] import-route direct
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
serial interfaces.
[RouterA] interface bri3/0

[RouterA-Bri3/0] ospf cost 2000
[RouterA-Bri3/0] ospf network-type broadcast
# Enable the dynamic route backup function.
[RouterA-Bri3/0] standby routing-group 1


[RouterB-Bri3/0] ip address 20.0.0.2 8

[RouterB] interface loopback 1

[RouterB-Loopback1] ip address 40.0.0.1 32
[RouterB-Loopback1] quit
# Configure the dynamic routing protocol OSPF.

[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 10.0.0.0 0.255.255.255
[RouterB-ospf-1-area-0.0.0.0] import-route direct
Example III Network requirements

■ Router A is connected to Router B through a X.25 network.
■ Router A and Router B are connected to the ISDN switched network through
ISDN BRI interfaces. Router A and Router B can dial each other through the
shared DCC. The telephone number of Router A is 8810010, and that of
Router B is 8810052.
the network segment 30.0.0.0/8 on Router B.
■ Normally, the X.25 link functions as the primary link between Router A and
Router B. When the route to the network segment where Router B resides
disconnects (for example, when the X.25 network fails), Router A will activate
the ISDN BRI link automatically.
Network diagram
Router A BRI3/0 BRI3/0 Router B

20 .0.0.1/24 20.0.0.2 /24
ISDN BRI Dedicated line Loop 1
30.0.0 .0/8
S2/0 S2/0
10.0.0 .1/8 10.0 .0.2/8
X.25
# Configure a dialer rule and configure a local user database.
# Configure the shared DCC on Dialer 0.


[RouterA-Dialer0] link-protocol ppp
[RouterA-Dialer0] ip address 20.0.0.1 24
[RouterA-Dialer0] standby routing-group 1
# Bind BRI 3/0 to Dialer 0.


[RouterA-Serial2/0] x25 map ip 10.0.0.2 x121-address 20 broadcast
[RouterA] rip
serial interfaces.

[RouterA-Bri3/0] rip metricin 2
# Configure a dialer rule and configure a local user database.
# Configure the shared DCC on Dialer 0.

[RouterB-Dialer0] link-protocol ppp

[RouterB-Dialer0] ip address 20.0.0.2 24


[RouterB-Bri3/0] dialer bundle-member 1
[RouterB-Bri3/0] ppp authentication-mode pap
[RouterB-Bri3/0] ppp pap local-user userb password simple userb

[RouterB-Serial2/0] link-protocol x25 dte ietf
[RouterB-Serial2/0] x25 map ip 10.0.0.1 x121-address 10 broadcast

[RouterB-Loopback1] ip address 30.0.0.1 32
[RouterB-Loopback1] quit
[RouterB] rip
[RouterB-rip-1] import-route direct
Using One Dynamic Network requirements

Route Group to Monitor ■ Router A and Router B are connected through a FR network, and they are
Multiple Network connected to each other through an ISDN switched network at the same time.
Segments Router A and Router B can dial each other. The telephone number of Router A
is 660330, and that of Router B is 660220.
the three network segments 10.0.0.1/8, 11.0.0.1/8, and 12.0.0.1/8 on Router
B.
■ Normally, the FR link functions as the primary link between Router A and
Router B. When there is no valid route to any of the three network segments
(that is, the logical relationship among the three network segments is "AND"),
Router A will activate the backup link.

Network diagram
Eth1/0
10 .0 .0.1/8
Router A S2 /1:15 S 2/1 :15 Router B Eth1/1

2.0.0.1/8 2 .0.0.2/8 11 .0 .0.1/8
ISDN PRI line
Eth1/2
S2/0 S 2/0 12 .0 .0.1/8
1.0.0 .1/8 1.0.0.2/8
DLCI:100 DLCI:200
FR
n This network diagram just illustrates a simple implementation. In real practice, the
monitored network segments may be distributed on multiple devices.
# Create a dynamic route backup group to monitor three network segments.
[RouterA] standby routing-rule 1 ip 10.0.0.0 255.0.0.0

# Bind the CE1 interface into a pri-set.
[RouterA] controller E1 2/1

[RouterA-E1 2/1] pri-set
[RouterA-E1 2/1] quit
# Configure Serial 2/0 as a FR interface.

[RouterA-Serial2/0] fr inarp
# Configure DCC polling on the PRI interface Serial 2/1:15.

[RouterA-Serial2/1:15] ip address 2.0.0.1 255.0.0.0
[RouterA-Serial2/1:15] dialer enable-circular

[RouterA-Serial2/1:15] dialer-group 1
[RouterA-Serial2/1:15] dialer route ip 10.0.0.0 mask 8 660220
[RouterA-Serial2/1:15] standby routing-group 1
[RouterA] rip
serial interfaces.

[RouterA-Serial2/1:15] rip metricin 2
[RouterB] system
# Bind the CE1 interface into a pri-set.
[RouterB] controller E1 2/1

[RouterB-E1 2/1] pri-set
[RouterB-E1 2/1] quit
# Configure Serial 2/0 as a FR interface.

[RouterB-Serial2/0] fr inarp
# Configure DCC polling on the PRI interface Serial 2/1:15.

[RouterB-Serial2/1:15] ip address 2.0.0.2 255.0.0.0
[RouterB-Serial2/1:15] dialer enable-circular
[RouterB-Serial2/1:15] dialer-group 1
[RouterB-Serial2/1:15] dialer route ip 2.0.0.1 mask 8 660330
[RouterB-Serial2/1:15] quit



[RouterB] rip
[RouterB-rip-1] import-route direct


LOGICAL INTERFACE CONFIGURATION
28
n This section introduces basic configurations about logical interfaces. For the
configurations about the data link layer, network layer and some special features,
refer to the relevant sections in the Access Volume and IP Service Volume.
Logical Interface A logical interface (also known as virtual interface) refers to an interface that can
Overview implements data switching but does not exist physically. Logical interfaces include
dial interfaces, loopback interfaces, null interfaces, sub-interfaces, multilink
point-to-point protocol group (MP-group) interfaces, multilink frame relay (MFR)
interfaces, backup center logical channels, virtual templates (VTs), and so on.
Dialer Interface A dialer interface is designed for configuring dial control center (DCC) parameters.
A physical interface can inherit configuration information through binding itself to
a dialer interface. The following interfaces on a device support dialing:
asynchronous serial interfaces (including synchronous/asynchronous serial
interfaces operating in asynchronous mode), AUX interfaces, AM interfaces, ISDN
BRI interfaces and ISDN PRI interfaces.
DCC is a routing technology used for interconnecting routers through public

switched network (PSTN or ISDN), and DCC provides dial-on-demand service. In
some occasions, channels are established and communication is implemented
among routers only when necessary, so the information transmitted between
routers is bursty and small-sized. DCC provides a flexible and economic solution
for such implementations.
n Refer to “DCC Configuration” on page 153 for more information about DCC.
Loopback Interface
Introduction to A loopback interface is a software-only virtual interface. The physical layer state
Loopback Interface and link layer protocols of a loopback interface are always up except when the
loopback interface is manually shut down. A loopback interface can be configured
with an IP address. For saving IP address resources, the IP address of an loopback
interface is coupled with a 32-bit mask. Routing protocols can be enabled on a
loopback interface, and a loopback interface is capable of sending and receiving
routing protocol packets.
Loopback interfaces have various uses, for example, the IP address of a loopback
interface can be used as the source addresses of all the IP packets that the local
device generates. As loopback interface addresses are stable and are unicast
addresses, they are usually used to identify devices. In some cases, configuring an

526 CHAPTER 28: LOGICAL INTERFACE CONFIGURATION
authentication server/security server to permit/deny packets with a specific

loopback interface address as their source IP addresses can permit/deny all the
packets sourced from the corresponding device. In this way, the packet filtering
rules are simplified. Note that, when a loopback interface is used for source
address binding, you need to make sure that the route from the loopback
interface to the peer is reachable. In this case, all the data packets destined for the
loopback interface are sent to the device itself, and the device does not forward
these packets.
Because a loopback interface is always up, it can be used for some special
purposes. For example, if the router ID of a device is not available, some dynamic
routing protocol uses the highest loopback interface address of the device as the
router ID.
Configuring a Loopback
Table 21 Configure a loopback interface
Interface
Create a Loopback interface interface loopback -
and enter Loopback interface number
view
Shut down a loopback shutdown Optional
interface manually
Always in the up state by default
c CAUTION:
■ Only 32-bit subnet masks can be configured for Loopback interfaces.
■ Parameters such as IP addresses and IP routes can be configured on Loopback
interfaces. Refer to “IP Addressing Configuration” on page 623 for detailed
configurations.
Null Interface
Introduction to Null Null interfaces are completely software-like logical interfaces. Null interfaces are
Interface always up. However, they can neither forward data packets nor have IP addresses
or link layer protocols configured on them. With a null interface specified as the
next hop of a static route to a specific network segment, any packets routed to the
network segment are dropped. If you configure to send unwanted traffic to the
null interface of a device, the unwanted traffic will be filtered. In this way,
complicated ACL configurations are saved.
For example, the static route configuration command ip route-static 92.101.0.0

255.255.0.0 null 0 will have all the packets destined to the network segment
92.101.0.0/16 discarded.
Configuring a Null
Table 22 Configure a null interface
Interface

Sub-interface 527
Table 22 Configure a null interface

Enter null interface view interface null 0 Required
By default, null interface 0 is existing on a
device and can neither be created nor
removed.
Sub-interface
Introduction to Sub-interfaces are logical virtual interfaces configured on a primary interface. The
Sub-interface primary interface can be either a physical interface (such as a layer-3 Ethernet
interface) or a logical interface (such as an MFR interface). A sub-interface can
share the physical-layer parameters of the primary interface and also have its own
link-layer and network-layer parameters configured. Disabling or enabling an
sub-interface has no effect on the corresponding primary interface, but state
changes of the primary interface affect the sub-interfaces. A sub-interface can
operate properly only when the primary interface operates properly.
With the sub-interface feature enabled, you can configure multiple sub-interfaces
for a single physical interface of a device, thus improving the flexibility of
networking implementation.
The following physical interfaces support sub-interfaces:
■ Ethernet interfaces. With a VLAN ID configured for an Ethernet sub-interface,

the sub-interface supports IPX; with a VLAN ID configured for an Ethernet
sub-interface, the sub-interface supports both IPX and IP at the same time.
■ WAN interfaces with their data link layer protocols being frame relay, whose
sub-interfaces support IP and IPX.
■ WAN interfaces with their data link layer protocols being X.25, whose
sub-interfaces support IP and IPX.
■ ATM interfaces, whose sub-interfaces support only IP.
Configuring an Ethernet Configure operation parameters for an Ethernet sub-interface

Sub-interface An Ethernet sub-interface can solve the problem that layer-3 Ethernet interfaces
cannot identify VLAN packets.
Through configuring multiple sub-interfaces on an Ethernet interface and setting

the encapsulation type and associated VLAN for each sub-interface. You can have
packets of different VLANs forwarded on different sub-interfaces, thus improving
the flexibility of networking implementations.
Table 23 Configure an Ethernet sub-interfaces


Table 23 Configure an Ethernet sub-interfaces

Create an Ethernet interface ethernet Required
sub-interface and enter the interface-number.subnumber
If the specified Ethernet
Ethernet sub-interface view
sub-interface does not exist,
this command first creates the
sub-interface and then enters
the sub-interface view.
n ■ By default, no VLAN is associated to sub-interfaces created by using the

interface command.
■ IP parameters and IPX parameters can be configured on Ethernet
sub-interfaces. Refer to the “IP Addressing Configuration” on page 623 and
“IPX Configuration” on page 2217 for detailed configurations.
c CAUTION: In terms of VLANs

■ An Ethernet sub-interface cannot send and receive packets properly before the
VLAN associated with the Ethernet sub-interface is activated.
■ The VLAN associated with the Ethernet sub-interface of the local device must
be the same as the VLAN associated with the Ethernet sub-interface of the
peer device. Otherwise, packets cannot be transmitted properly.
Display and maintain Ethernet sub-interfaces

After the above configuration, you can use the display command in any view to
view the configuration information of the Ethernet sub-interface, so as to verify
the configuration.
You can use the reset command in user view to clear the statistics on the VLAN
associated with the specified sub-interface.
Table 24 Display and maintain Ethernet sub-interfaces
Operation Command
Display the information about a sub-interface display interface interface-type
Display the information about the VLAN of a display vlan interface interface-type
sub-interface interface-number.subnumber
n For more information about the display vlan interface command and the reset
command, refer to the display vlan command in “Introduction to VLAN” on page
487.
Configuring a WAN Configure sub-interfaces for a WAN interface with link-layer protocol
Sub-interfaces being frame relay
1 Create a sub-interface
Table 25 Create a sub-interface


Sub-interface 529

Enter serial interface view interface serial Required
interface-number
Set the link-layer protocol of link-protocol fr Required
the interface to frame relay [ nonstandard | ietf | mfr
By default, the link-layer
interface-number]
protocol of an interface is PPP.
Create an sub-interface for interface serial Required
the serial interface and enter interface-number.subnumber
By default,
the corresponding view [ p2mp | p2p ]
point-to-multipoint
sub-interfaces are created.
2 Configure relevant operation parameters
On sub-interfaces of a WAN interface with link-layer protocol being frame relay,

you can configure:
■ Frame relay address mapping different from the that of the WAN interface (also
known as the primary interface)
■ IP addresses in a network segment different from the network segment that
the WAN interface resides
■ IPX network numbers and IPX operation parameters different from those of the
WAN interface
■ Virtual circuits corresponding to a sub-interface
For the detailed configuration information, refer to “Frame Relay Configuration”

on page 235 and “IPX Configuration” on page 2217.
Configure sub-interfaces for a WAN interface with link-layer protocol

being X.25
1 Create a sub-interface

Enter serial interface view interface serial Required
interface-number
Set the link-layer protocol of link-protocol x25 [ dte | Required
the interface to X.25 dce ] [ ietf | nonstandard ]
By default, the link-layer
protocol of an interface is PPP.
Create an sub-interface for interface serial Required
the serial interface and enter interface-number.subnumber
By default,
the corresponding view [ p2mp | p2p ]
point-to-multipoint
On sub-interfaces of a WAN interface with link-layer protocol being X.25, you can
configure:

■ X.25 address mapping different from that of the WAN interface (also known as
the primary interface)
■ IPX network numbers and IPX operation parameters different from those of the
WAN interface
For the detailed configuration information, refer to “X.25 and LAPB

Configuration” on page 283 and “IPX Configuration” on page 2217.
Create an ATM sub-interface

1 Create an ATM sub-interface
Table 27 Create an ATM sub-interface

Create an ATM interface atm Required
sub-interface and enter interface-number.sub
If the specified ATM sub-interface does not
the ATM sub-interface number [ p2mp |
exist, this command first creates the
view p2p ]
sub-interface and then enters the
sub-interface view.
By default, point-to-multipoint
On ATM sub-interfaces, you can configure:

For the detailed configuration information, refer to “ATM and DSL Interface
Ethernet Sub-interface Network requirements

Configuration Example As shown in Figure 148, the encapsulation type for the VLAN ports of Switch 1
and Switch 2 is dot1q, workstation A and C belong to VLAN 10, and workstation
B and D belong to VLAN 20. It is required that:
■ The IP addresses of router subinterfaces Ethernet 3/0.10, Ethernet 3/0.20,
Ethernet 4/0.10, and Ethernet 4/0.20 are 1.0.0.1/8, 2.0.0.1/8, 3.0.0.1/8, and
4.0.0.1/8.
■ Work station A can intercommunicate with work station B, and work station C
can intercommunicate with work station D, that is, devices connected to the
same switch but belonging to different VLANs can intercommunicate with each
other.
■ Work station A can intercommunicate with work station C, and work station B
can intercommunicate with work station D, that is, devices connected to

Sub-interface 531
different switches but belonging to the same VLAN can intercommunicate with
each other.
■ Work station A can intercommunicate with work station D, and work station B
can intercommunicate with work station C, that is, devices connected to
different switches and belonging to different VLANs can intercommunicate
with each other.
Network diagram
Figure 148 Network diagram for Ethernet sub-interface configuration
Internet
Eth4/0.20
Router 4.0.0.1/8
VLAN 20 Switch B
Eth4/0.10
3.0.0.1/8
VLAN 10
Eth3/0.10 Eth3/0.20
1.0.0.1/8 2.0.0.1/8
VLAN 10 VLAN 20
Host C Host D
Switch A 3.3.3.3/8 4.4.4.4/8
VLAN 10 VLAN 20
Host A Host B
1.1.1.1/8 2.2.2.2/8
VLAN 10 VLAN 20
1 Configure Router:
# Create Ethernet sub-interfaces (Ethernet 3/0.10, Ethernet 3/0.20, Ethernet

4/0.10, and Ethernet 4/0.20) and configure IP addresses for them. Set the
encapsulation type and the related VLAN ID for each sub-interface. Note that the
encapsulation type of an Ethernet sub-interface must be consistent with that of
switch ports.
[Router] interface ethernet 3/0.10
[Router-Ethernet3/0.10] ip address 1.0.0.1 255.0.0.0
[Router-Ethernet3/0.10] quit

WAN Sub-interface Network requirements

Configuration Example ■ WAN interface Serial 1/0 of Router A is connected to Router B and Router C
through the public frame relay network.
■ Allow LAN 1 to access LAN 2 and LAN 3 at the same time through Serial 1/0 by
configuring sub-interfaces for Serial 1/0 of Router A.
Network diagram
Figure 149 Network diagram for WAN sub-interface configuration
LAN 2
2.2.0.0/16
S2/0
1.1.1.2/24
DLCI =50
S1/0.1
1.1.1.1/24 Router B
DLCI =50
LAN 1
2.1.0.0/16 FR
S1/0.2
1.1.2.1/24 Router C
S2/0
Router A DLCI =60 1.1.2.2/24
DLCI =60
LAN 3
2.3.0.0/16
# Enter Serial 1/0 interface view.
[Sysname] interface serial 1/0
# Set the link-layer protocol to frame relay.
[Sysname-Serial1/0] link-protocol fr
# Specify the frame relay terminal type as DTE.
[Sysname-Serial1/0] fr interface-type dte

[Sysname-Serial1/0] quit
# Create a point-to-point sub-interface Serial 1/0.1.
[Sysname] interface serial 1/0.1 p2p
# Set the IP address of Serial 1/0.1 to 202.38.160.1/24.
[Sysname-Serial1/0.1] ip address 202.38.160.1 255.255.255.0
# Assign a virtual circuit with DLCI being 50 to Serial 1/0.1.

Configuring MP-group Interfaces 533
[Sysname-Serial1/0.1] fr dlci 50
[Sysname-fr-dlci-Serial1/0.1-50] quit
[Sysname-Serial1/0.1] quit
# Create a point-to-point sub-interface Serial 1/0.2 for Serial 1/0.
[Sysname] interface serial 1/0.2 p2p
# Set the IP address of Serial 1/0.2 to 202.38.161.1/24.
[Sysname-Serial1/0.2] ip address 202.38.161.1 255.255.255.0
# Assign a virtual circuit with DLCI being 60 to Serial 1/0.2.
[Sysname-Serial1/0.2] fr dlci 60
[Sysname- fr-dlci-Serial1/0.2-60] quit
[Sysname-Serial1/0.2] quit
# Configure static routes from Router A to LAN 2 and LAN 3.
[Sysname] ip route-static 129.10.0.0 255.255.0.0 202.38.160.2

[Sysname] ip route-static 129.11.0.0 255.255.0.0 202.38.161.2
2 The configurations of Router B and Router C are similar to that of Router A and
thus omitted.
Configuring MP-group MP-group interfaces are used in multilink PPP (MP). MP-group interfaces are
Interfaces dedicated interfaces for MP and do not support other implementations. Refer to
“PPP and MP Configuration” on page 363 for more information about MP-group.
Table 28 Create an MP-group interface

Create an MP-group interface interface mp-group Required
and enter the MP-group mp-number
If the specified MP-group
interface view
interface does not exist, this
command first creates the
interface and then enters the
interface view.
View the state information display interface mp-group You can execute this
about the MP-group interface [ mp-number ] command in any view.
Configuring MFR An MFR interface is a logical interface. An MFR interface is a bundle of physical
Interface frame relay links. Sub-interfaces can be configured for an MFR interface, thus
providing high-rate and broad-bandwidth links for a frame relay network. Refer to
“Frame Relay Configuration” on page 235 for detailed information.
Table 29 Create an MFR interface


Table 29 Create an MFR interface

Create an MFR primary interface mfr Required
interface and enter MFR interface-number
If the specified MFR primary
primary interface view
interface does not exist, this
command first creates the
interface and then enters the
interface view.
Create an MFR sub-interface interface mfr Required
and enter MFR sub-interface interface-number.subnumber
If the specified MFR
view
sub-interface does not exist,
this command first creates the
sub-interface and then enters
the sub-interface view.
View the configuration and display interface mfr Available in any view
state information about an [ interface-number |
MFR interface interface-number.subnumber
]
View the configuration display mfr [ interface Available in any view
information and statistics interface-type
information about an MFR interface-number | verbose ]
bundling and bundled links
n Refer to “Configuring Multilink Frame Relay” on page 258 for detailed information
about MFR interface parameters.
VT and VA Interface
Introduction to VT and A virtual template (VT) is a template used for configuring a virtual access (VA)
VA interface interface. VTs are mainly used in VPN and MP implementations.
After a VPN session is established, a VA interface is necessary for data exchange

with the peer end. In this case, the system will select a VT based on the user
configurations, and then create a VA interface dynamically. Refer to “Configuring
VPN Instances” on page 1481 for VPN-relevant configurations.
When multiple PPP links are bundled into an MP, a VA interface is also necessary
for data exchange with the peer end. In this case, the system will also select a VT
so as to create a VA interface dynamically. Refer to “PPP and MP Configuration”
on page 363 for more information about MP.
Configuring VT In VPN and MP implementations, creation and removal of VA interfaces are

automatic and transparent to users. You just need to configure VPN or MP on the
corresponding physical interface, create and configure a VT, and then associate
this VT with the corresponding physical interface.
Create a VT
Table 30 Create a VT


VT and VA Interface 535
Table 30 Create a VT

Create a VT and enter VT view interface virtual-template Required
number
If the specified VT does not
exist, this command first
creates the VT and then
enters the VT view.
Set the maximum number of broadcast-limit link number Optional
links that can send multicast
By default, up to 30 links in a
or broadcast packets in a VT
VT can send multicast or
broadcast packets.
n Before removing a VT, make sure that all the virtual interfaces derived from the VT
are removed and the VT is not being used.
Configure VT operation parameters

Compared to normal physical interfaces, a VT supports only PPP on the link layer
and IP on the network layer. You can configure the following operation
parameters for a VT:
■ Operation parameters for PPP
■ IP address of a virtual interface
■ IP address (or IP address pool) to be assigned to the PPP peer
For the detailed configuration information, refer to “PPP and MP Configuration”

on page 363.
Associate a VT with relevant physical interfaces

When necessary, the system will automatically create VA interfaces, which will
adopt the parameters defined in a specific VT. You need not create and configure
VA interfaces manually. VA interfaces will be removed due to underlying layer
disconnection or user intervention.
In VPN implementations, you need to associate layer-2 tunneling protocol (L2TP)

with a VT. Refer to the “L2TP Configuration” on page 1601 for details. In MP
implementations, you need to associate MP users with a VT. Refer to “PPP and MP
Configuration” on page 363 for detailed information.
Displaying and After the above configuration, you can use the display command in any view to
Maintaining VTs and VA view the configuration information about the VTs and VA interfaces, so as to verify
Interfaces the configuration.
Table 31 Display VTs and VA interfaces
Operation Command
Display the status of the display interface virtual-template number
specified VT
Display the status of the VA display virtual-access [ dialer dialer-number | vt
interface vt-number | user user-name | peer peer-address |
va-number ]*

Troubleshooting Before troubleshooting, you must determine the VT is used for creating virtual
interfaces for VPN or MP. Then, you can locate the VT failures in a specified
implementation.
Symptom
Virtual interfaces cannot be created.
Solution
The causes may be:
■ No IP address is configured for the VT. As a result, PPP negotiation fails, so the
VA interface cannot be brought up.
■ When PPP authentication parameters are incorrect, PPP negotiation fails if the
peer device is not the user defined by the local device. As a result, the VA
interface cannot be brought up.
■ If the IP address (or IP address pool) to be assigned to the peer is not configured
for the VT, the VA interface cannot provide IP addresses when the peer device
requires the local device to. In this case, the VA interface cannot be brought up.
Configuring VE
Introduction to VE A virtual Ethernet (VE) interface is a logical interface implemented on interface

boards. VE interfaces are mainly used in point to point protocol over Ethernet over
ATM (PPPoEoA).
PPPoEoA is a structure of 3 layers: the top layer is PPP, the middle layer is PPP over
Ethernet (PPPoE), and the bottom layer is PPPoEoA. Note that the parameters for
PPPoE are configured through VE interfaces on the interface boards of the access
device. Refer to “ATM and DSL Interface Configuration” on page 71 for detailed
information.
Configuring VE When configuring a permanent virtual channel (PVC) to transfer PPPoEoA packets,
you must specify a VE interface corresponding to the PVC. Otherwise, PVC cannot
be configured. A VE interface corresponds to only one PVC bearing PPPoEoA. A VE
interface which has been associated with a PVC cannot be removed.
Table 32 Configure a VE Interface

Create a VE interface interface Required
and enter the VE virtual-ethernet
If the specified VE interface does not exist, this
interface view number
command first creates the VE interface and
then enters the VE interface view.
You can configure up to 1,024 VE interfaces.
n ■ The configuration of a VE interface is similar to that of an Ethernet interface.

Refer to “Ethernet Interface Configuration” on page 89 for the configuration
procedure.

Configuring VE 537
■ The displaying and maintenance of a VE interface is similar to that of an

Ethernet interface. Refer to “Maintaining and Displaying an Ethernet Interface”
on page 97 for the configuration procedure.
■ Refer to “PPPoE Configuration” on page 393 for PPPoEoA configuration.


CPOS INTERFACE CONFIGURATION
29
When configuring ATM/DSL interface, go to these sections for information you are
interested in:
■ “Configuring a CPOS Interface” on page 544
■ “Configuring an E1 Channel” on page 545
■ “Configuring a T1 Channel” on page 545
■ “Displaying and Maintaining CPOS Interfaces” on page 546
■ “Troubleshooting CPOS Interfaces” on page 546
Overview This section covers these topics:

■ “SONET/SDH” on page 539
■ “SDH Frame Structure” on page 540
■ “Terms” on page 540
■ “Multiplexing E1/T1 Channels to Form STM-1” on page 541
■ “Calculating E1/T1 Channel Sequence Numbers” on page 541
■ “Overhead Byte” on page 542
■ “CPOS Interface Application Scenario” on page 543
SONET/SDH Synchronous optical network (SONET), a synchronous transmission system defined

by ANSI, is an international standard transmission protocol. It adopts optical
transmission.
In SDH defined by CCIT (today’s ITU-T), adoption of synchronous multiplexing and

flexible mapping allows you to add/drop low-speed tributary signals from SDH
signal without large amount of multiplexing/demultiplexing devices. This reduces
signal attenuation and device investment.
CPOS Low-speed tributary signals are called channels when they are multiplexed to form
SDH signals. CPOS, the channelized POS interface, makes full use of SDH to
provide precise bandwidth division, reduce the number of low-speed physical
interfaces on devices, enhance their redistribution capacity, and improve the
access capacity of dedicated lines.
CPOS interfaces are mainly used to enhance the devices’ redistribution capacity for
low-speed access. CPOS interfaces are mainly of two rates: STM-1 (155 mbps) and
STM-16c (2.5 Gbps).

540 CHAPTER 29: CPOS INTERFACE CONFIGURATION
SDH Frame Structure The frame structure of SDH signal STM-N is described in the following part.
Low-speed tributary signals should distribute in one frame regularly and evenly for
the convenience of adding/dropping them in high-speed signal. ITU-T specifies
that STM-N frames adopt the structure of rectangle blocks in bytes, as illustrated
in the following figure:
Figure 150 STM-N frame structure
9 x 270 x N (bytes)
1 Regenerator
2 section
3 overhead
4 AU-PTR
5 Payload
6 Multiplex
7 section
8 overhead
9
9xN 261 x N
STM-N is a rectangle-block frame structure of 9 rows x 270 x N columns, where

the N in STM-N equals the N columns. N takes the value 1, 4, 16, and so on,
indicating the number of STM-1 signals that form SDH signal.
The STM-N frame structure consists of three parts: section overhead (SOH), which
includes regenerator section overhead (RSOH) and multiplex section overhead
(MSOH); administration unit pointer (AU-PTR); and payload. AU-PTR is the pointer
that indicates the location of the first byte of payload in an STM-N frame so that
the receiving end can correctly extract payload.
Terms ■ Multiplex Unit: A basic SDH multiplex unit includes multiple containers (C-n),
virtual containers (VC-n), tributary units (TU-n), tributary unit groups (TUG-n),
administrative units (AU-n) and administrative unit groups (AUG-n), where n is
the hierarchical sequence number of unit level.
■ Container: Information structure unit that carries service signals at different
rates. G.709 defines the criteria for five standard containers: C-11, C-12, C-2,
C-3 and C-4.
■ Virtual container (VC): Information structure unit supporting channel layer
connection of SDH. It terminates an SDH channel. VC is divided into
lower-order and higher-order VCs. VC-4 and VC-3 in AU-3 are higher-order
virtual containers.
■ Tributary unit (TU) and tributary unit group (TUG): TU is the information
structure that provides adaptation between higher-order and lower-order
channel layers. TUG is a set of one or more TUs whose location is fixed in
higher-order VC payload.

Overview 541
■ Administrative unit (AU) and administrative unit group (AUG): AU is the

information structure that provides adaptation between higher-order channel
layer and multiplex section layer. AUG is a set of one or more AUs that have
fixed location in the payload of STM-N.
Multiplexing E1/T1 In SDH multiplexing recommended by G.709, there are more than one path for a
Channels to Form STM-1 valid payload to be multiplexed to form STM-N. The following figure illustrates the
multiplexing process from E1 and T1 to STM-1.
Figure 151 Process of multiplexing E1 channels to form STM-1
x1 x1
STM-1 AUG-1 AU-4 VC-4
x3
x3 TUG-3
Multiplexing x7 C-12: 2.048 Mbps

AU-3 VC-3
Mapping
Aligning x7 TUG-2 TU-12 VC-12 C-12
x3
Figure 152 Process of multiplexing T1 channels to form STM-1
x1 x1
STM-1 AUG-1 AU-4 VC-4
x3
x3 TUG-3
Multiplexing AU-3 VC-3 x7 C-11: 1.544 Mbps

Mapping
Aligning x7 TUG-2 TU-11 VC-11 C-11
x4
In actual applications, different countries and regions may adopt different

multiplexing structures. To ensure interoperability, the multiplex mode command
is provided on CPOS interfaces. This allows you to select the AU-3 or AU-4
multiplexing structure.
Calculating E1/T1 Since CPOS interfaces adopt the byte interleaved multiplexing mode, the
Channel Sequence lower-order VCs are not arranged in order in a higher-order VC. To understand
Numbers how TU numbers are calculated, see the following example where E1 channels are
multiplexed to form STM-1 through the AU-4.
As shown in Figure 151, when the AU-4 path is used, the multiplexing structure
for 2 Mbps is 3-7-3. The formula for calculating the TU-12 sequence numbers of
different locations in the same VC-4 is as follows:
Sequence number of TU-12 = TUG-3 number + (TUG-2 number - 1) x 3 + (TU-12

Number - 1) x 21

The two TU-12s are called adjacent, if they have the same TUG-3 number and
TUG-2 number but different TU-12 numbers with a discrepancy of 1.
n The numbers in the aforementioned formula refer to the location numbers in a

VC-4 frame. TUG-3 can be numbered in the range 1 to 3; TUG-2 in the range 1 to
7 and TU-12 in the range 1 to 3. TU-12 numbers indicate the order in which the
63 TU-12s in a VC-4 frame are multiplexed, that is, E1 channel numbers.
Figure 153 Order of TUG-3s, TUG-2s, and TU-12s in a VC-4 frame
TU-12 1
1 1
VC-4 TUG-3 TUG-2 TU-12 2
TU-12 3
TU-12 1
2
TUG-2 TU-12 2
. TU-12 3
2
.
. TU-12 1
TUG-3 7
TUG-2 TU-12 2
3
TUG-3 TU-12 3
You can calculate TU-12 numbers in the same way when the AU-3 path is used.
When 63 E1 channels or 84 T1 channels are configured on a CPOS interface, you

can reference E1 or T1 channels by referencing the numbers in the range 1 to 63
or 1 to 84. When connecting your device to channelized STM-1 interfaces on
devices of other vendors, you should consider the possible numbering differences
result from different channel referencing approaches.
Overhead Byte SDH provides layered monitoring and management of precise division.
It provides monitoring at section and channel levels, where sections are subdivided
into regenerator and multiplex sections, and channels are subdivided into
higher-order and lower-order paths. These monitoring functions are implemented
using overhead bytes.
n SDH provides a variety of overhead bytes, but only those involved in CPOS
configuration are discussed in this section. For more information about overhead
bytes, refer to related books.
■ SOH
Section overhead (SOH) consists of regenerator section overhead (RSOH) and

multiplex section overhead (MSOH).
The regeneration section trace message J0 is included in RSOH to send the section
access point identifier repeatedly. Based on the identifier, the receiver can make
sure that it is in continuous connection with the sender. This byte can be any
character in the network of the same operator. If networks of two operators are

Overview 543
involved, however, the sending and receiving devices at network borders must use
the same J0 byte. With the j0 byte, operators can detect and troubleshoot faults in
advance or use less time to recover networks.
■ POH
The payload of an STM-N frame includes path overhead (POH), which monitors
low-speed tributary signals.
While SOH monitors the section layer, POH monitors the path layer. POH is divided
into higher-order path overhead and lower-order path overhead.
Higher-order path overhead monitors paths at the VC-4/VC-3 level.
Similar to the J0 byte, the higher-order VC-N path trace byte J1 is included in the
higher-order path overhead to send the higher-order path access point identifier
repeatedly. Based on the identifier, the receiving end of the path can make sure
that it is in continuous connection with the specified sending end. The J1 byte at
the receiving and transmission ends should be matched.
The path signal label byte C2 is also included in the higher-order path overhead to
indicate the multiplexing structure of VC frames and the property of payload, for
instance, whether the path is carrying services, what type of services are carried,
and how they are mapped. The sender and receiver must use the same C2 byte.
CPOS Interface At present, some government agencies and enterprises use low-end and
Application Scenario mid-range devices to access transmission networks through E1/T1 leased lines.
Users who require bandwidth between E1 and T3 (44 Mbps), data centers for
example lease multiple E1/T1 lines.
The bandwidth of all these users is aggregated to one or more CPOS interfaces
through a transmission network, and then connected to a high-end device where
the low-end devices are uniquely identified by timeslots.
In actual applications, the connection between these low-end devices and the
CPOS interfaces likely involves more than one transmission networks and as such,
may require relay. This is similar to the scenario where low-end devices are
connected to a high-end device through one or multiple E1/T1 leased lines.

Figure 154 A CPOS implementation
Transmission
network Internet
Router A
N x 2 Mbps
E1
Access
network N x 64 kbps
N x 64 kbps
N x 64 kbps
Configuring a CPOS Follow these steps to configure a CPOS interface:

Interface
Enter CPOS interface view controller cpos cpos-number Required
Set the framing format frame-format { sdh | sonet } Optional
The default is SDH.
Set the loopback mode loopback { local | remote } Optional
Disabled by default
Configure the AUG multiplex mode { au-3 | Optional
multiplexing mode au-4 }
Available only in SDH framing.
The default is AU-4.
Configuring the SOH and flag { j0 j0-string | j1 j1-string Optional
higher-order path overhead | c2 c2-value }
The following are the
bytes
defaults:
Cyclic sending of hexadecimal
01 for J0 for backward
compatibility.
Cyclic sending of the
character string NetEngine for
J1.
Hexadecimal 02 for C2.
Configure E1 or T1 channel See “CPOS Interface Optional
attributes Configuration” on page 539.

Configuring an E1 Channel 545
n E1 configuration is supported on the CPOS (E) interface module while T1

configuration is supported on the T1 CPOS (T) interface module.
Configuring an E1 Follow these steps to configure an E1 channel:

Channel
Enter CPOS interface view controller cpos Required
cpos-number
Set the E1 framing format e1 e1-number set Optional
frame-format { crc4 |
no-crc4 }
Set the clock mode for E1 E1 e1-number set clock Optional
{ master | slave }
Set the loopback mode for E1 e1 e1-number set loopback Optional
Disabled by default
Configure the Configure E1 e1 e1-number unframed Required
E1 operating to operate in
The default is channelized
mode (in unframed
mode.
either mode
approach)
Configure E1 undo e1 e1-number Optional
to operate in unframed
channelized
mode
mode and set
timeslot e1 e1-number channel-set Required
bundling set-number timeslot-list
Timeslot bundling is disabled
range
by default.
n E1 configuration is supported on the CPOS (E) interface module.
Configuring a T1 Follow these steps to configure a T1 channel:

Channel
Enter CPOS interface view controller cpos Required
cpos-number
Set the T1 framing format t1 t1-number set Optional
frame-format { esf | sf }
The default is ESF.
Set the clock mode for T1 t1 t1-number set clock Optional
{ master | slave }
Set the loopback mode for T1 t1 t1-number set loopback Optional
Disabled by default


Configure the Configure T1 t1 t1-number unframed Required
T1 operating to operate in
mode (in unframed
mode.
either mode
approach)
Configure T1 undo t1 t1-number Optional
to operate in unframed
channelized
mode
t1 t1-number channel-set Required
set-number timeslot-list
Timeslot bundling is disabled
range [ speed { 56k | 64k } ]
by default.
n T1 configuration is supported on the CPOS (T) interface module.
Displaying and
Maintaining CPOS To do... Use the command... Remarks
Interfaces Display information about display controller cpos Available in any view
channels on a specified or all [ cpos-number ]
CPOS interfaces
Display information about a display controller cpos Available in any view
specified E1 channel on a cpos-number e1 e1-number
CPOS interface
Display information about a display controller cpos Available in any view
specified T1 channel on a cpos-number t1 t1-number
CPOS interface
Display information about a display interface serial Available in any view
serial interface formed by interface-number/channel-nu
E1/T1 channels mber:set-number
Shut down the CPOS physical shutdown Available in CPOS interface
interface view
Bring the CPOS physical undo shutdown Available in CPOS interface
interface up. view
Shut down an E1 channel e1 e1-number shutdown Available in CPOS interface
view
Bring an E1 channel up undo e1 e1-number Available in CPOS interface
shutdown view
Shut down a T1 channel t1 t1-number shutdown Available in CPOS interface
view
Bring a T1 channel up undo t1 t1-number Available in CPOS interface
shutdown view
n ■ For those physical interfaces that are not connected to cables, shut down them
with the shutdown command to avoid anomalies resulted from interference.
■ As the command can disable the interface, use it with caution.
Troubleshooting CPOS Symptom:

Interfaces Connect the CPOS interface of the device to that of another vendor through SDH,
bundle E1 channels on the interface to form a serial interface and encapsulate it
with PPP.

Troubleshooting CPOS Interfaces 547
Perform the display interface serial command to check information on interface

status. It shows that the physical state of the interface is UP, but the link protocol is
DOWN; and loopback, though not configured, is detected on some interfaces.
Solution:
The fault is very likely caused if the multiplex unit configurations on the SDH
transmission device mismatch the E1 channel numbers on the CPOS interface on
your device. This can result in timeslot inconsistency at the two ends of
transmission and as such, PPP negotiation failures and LCP anomalies.
Besides, if an idle timeslot on a loopback serial interface on the transmission

device is used in transmission, the information that loopback is detected is
displayed. Use the debugging ppp lcp error command to check loopback
information.
Follow these steps to solve the problem:
■ Use the display controller cpos e1 command to view the multiplexing paths
of the E1 channels or calculate the multiplexing path as shown in section
“Calculating E1/T1 Channel Sequence Numbers” on page 541.
■ Check the configurations on the transmission devices against the calculating
result in the last step to make sure the same E1 multiplexing path is configured.


ARP CONFIGURATION
30
When configuring ARP, go to these sections for information you are interested in:
■ “ARP Overview” on page 549
■ “Configuring ARP” on page 552
■ “Configuring Gratuitous ARP” on page 554
■ “Configuring ARP Source Suppression” on page 555
■ “Configuring Authorized ARP” on page 555
■ “Displaying and Maintaining ARP” on page 559
ARP Overview
ARP Function Address resolution protocol (ARP) is used to resolve an IP address into a data link
layer address.
An IP address is the address of a host at the network layer. To send a network layer
packet to a destination host, the device must know the data link layer address
(such as the MAC address) of the destination host. To this end, the IP address must
be resolved into the corresponding data link layer address.
n Unless otherwise stated, the data link layer addresses that appear in this chapter
refer to the 48-bit Ethernet MAC addresses.
ARP Message Format Figure 155 ARP message format
Hardware address length

Protocol address length
Target
HardwareProtocol OP Sender hardware Sender protocol Target hardware protocol
type type address address address
address
2 2 1 1 2 6 4 6 4
28-byte ARP request /response
The following explains the fields in Figure 155.
■ Hardware type: This field specifies the type of a hardware address. The value
“1” represents an Ethernet address.
■ Protocol type: This field specifies the type of the protocol address to be
mapped. The hexadecimal value “0x0800” represents an IP address.

550 CHAPTER 30: ARP CONFIGURATION
■ Hardware address length: Length of a hardware address in bytes. For an

Ethernet address, the value of the hardware address length field is “6”.
■ Protocol address length: Length of a protocol address, in bytes. For an IP(v4)
address, the value of the protocol address length field is "4".
■ OP: Operation code. This field specifies the type of ARP message. For example,
the value "1" represents an ARP request, "2" represents an ARP reply, and "4"
represents a reverse ARP request.
■ Sender hardware address: This field specifies the hardware address of the
device sending the message.
■ Sender protocol address: This field specifies the protocol address of the device
sending the message.
■ Target hardware address: This field specifies the hardware address of the device
the message is being sent to.
■ Target protocol address: This field specifies the protocol address of the device
the message is being sent to.
ARP Process Suppose that Host A and Host B are on the same subnet and that Host A sends a
message to Host B, as shown in Figure 156. The resolution process is as follows:
1 Host A looks in its ARP mapping table to see whether there is an ARP entry for
Host B. If Host A finds it, Host A uses the MAC address in the entry to encapsulate
the IP packet into a data link layer frame and sends the frame to Host B.
2 If Host A finds no entry for Host B, Host A buffers the packet and broadcasts an
ARP request, in which the source IP address and source MAC address are
respectively the IP address and MAC address of Host A and the destination IP
address and MAC address are respectively the IP address of Host B and an all-zero
MAC address. Because the ARP request is sent in broadcast mode, all hosts on this
subnet can receive the request, but only the requested host (namely, Host B) will
process the request.
3 Host B compares its own IP address with the destination IP address in the ARP
request. If they are the same, Host B saves the source IP address and source MAC
address into its ARP mapping table, encapsulates its MAC address into an ARP
reply, and unicasts the reply to Host A.
4 After receiving the ARP reply, Host A adds the MAC address of Host B into its ARP
mapping table for subsequent packet forwarding. Meanwhile, Host A
encapsulates the IP packet and sends it out.

ARP Overview 551
Figure 156 ARP address resolution process
Host A Host B
192.168.1.1 192.168.1.2
0002- 6779-0 f4c 00a 0-2470 -febd
Sender MAC Sender IP Target MAC Target IP

address address address address
0002 -6779 -0f4c 192.168 .1.1 0000 -0000- 0000 192 .168 .1 .2
Sender MAC Sender IP Target MAC Target IP

address address address address
00a 0-2470 -febd 192.168 .1.2 0002 -6779 -0f4c 192 .168 .1 .1
When Host A and Host B are not on the same subnet, Host A first sends an ARP
request to the gateway. The destination IP address in the ARP request is the IP
address of the gateway. After obtaining the MAC address of the gateway from an
ARP reply, Host A encapsulates the packet and sends it to the gateway.
Subsequently, the gateway broadcasts the ARP request, in which the destination IP
address is the one of Host B. After obtaining the MAC address of Host B from
another ARP reply, the gateway sends the packet to Host B.
ARP Mapping Table After obtaining the destination MAC address, the device adds the IP-to-MAC
mapping into its own ARP mapping table. This mapping is used for forwarding
packets with the same destination in future.
An ARP mapping table contains ARP entries, which fall into two categories:
dynamic and static.
1 A dynamic entry is automatically created and maintained by ARP. It can get aged,
be updated by a new ARP packet, or be overwritten by a static ARP entry. When
the aging timer expires or the interface goes down, the corresponding dynamic
ARP entry will be removed.
2 A static ARP entry is manually configured and maintained. It cannot get aged or be
overwritten by a dynamic ARP entry. It can be permanent or non-permanent.
■ A permanent static ARP entry can be directly used to forward data. When
configuring a permanent static ARP entry, you must configure a VLAN and
outbound interface for the entry besides the IP address and MAC address.
■ A non-permanent static ARP entry cannot be directly used for forwarding data.
When configuring a non-permanent static ARP entry, you only need to
configure the IP address and MAC address. When forwarding IP packets, the
device sends an ARP request. If the source IP and MAC addresses in the
received ARP reply are the same as the configured IP and MAC addresses, the
device adds the interface receiving the ARP reply into the static ARP entry. Now
the entry can be used for forwarding IP packets.
n Usually ARP dynamically implements and automatically seeks mappings from IP

addresses to MAC addresses, without manual intervention.

Configuring ARP
Configuring a Static ARP A static ARP entry is effective when the device works normally. However, when a
Entry VLAN or VLAN interface to which a static ARP entry corresponds is deleted, the
entry, if permanent, will be deleted, and if non-permanent and resolved, will
become unresolved.
Follow these steps to configure a static ARP entry:

Configure a permanent static arp static ip-address Required
ARP entry mac-address vlan-id
No permanent static ARP
interface-type
entry is configured by default.
interface-number
[ vpn-instance
vpn-instance-name ]
Configure a non-permanent arp static ip-address Required
static ARP entry mac-address [ vpn-instance
No non-permanent static ARP
vpn-instance-name ]
entry is configured by default.
c CAUTION:
■ The vlan-id argument must be the ID of an existing VLAN which corresponds to
the ARP entries. In addition, the Ethernet interface following the argument
must belong to that VLAN. A VLAN interface must be created for the VLAN.
■ Before using the command with the vpn-instance keyword to configure a
permanent static ARP entry, you need to create a VPN instance and bind it to
the VLAN interface.
Configuring the Follow these steps to set the maximum number of ARP entries dynamically learned
Maximum Number of on an interface:
ARP Entries Dynamically
Learned on an Interface To do... Use the command... Remarks
interface-number
Set the maximum number of arp max-learning-num Required
ARP entries dynamically number
1,024 by default
learned on an interface
Setting Aging Time for After dynamic ARP entries expire, the system will delete them from the ARP
Dynamic ARP Entries mapping table. You can adjust the aging time for dynamic ARP entries according
to the actual network condition.
Follow these steps to set aging time for dynamic ARP entries:


Configuring ARP 553

Set aging time for dynamic arp timer aging aging-time Optional
ARP entries
20 minutes by default
Enabling the ARP Entry The ARP entry check can control the device to learn multicast MAC addresses.
Check With the ARP entry check enabled, the device cannot learn any ARP entry with a
multicast MAC address. Configuring such a static ARP entry is not allowed either;
otherwise, the system prompts error information.
After the ARP entry check is disabled, the device can learn the ARP entry with a
multicast MAC address, and you can also configure such a static ARP entry on the
device.
Follow these steps to enable the ARP entry check:

Enable the ARP entry check arp check enable Optional
Enabled by default. That is,
the device does not learn
multicast MAC addresses.
Enabling the Support for When learning MAC addresses, if the device finds that the source IP address of an
ARP Requests from a ARP packet and the IP address of the inbound interface are not on the same
Natural Network subnet, the device will further judge whether these two IP addresses are on the
same natural network.
Suppose that the IP address of VLAN-interface 10 is 10.10.10.5/24 and this

interface receives an ARP packet from 10.11.11.1/8. Because these two IP
addresses are not on the same subnet, VLAN-interface 10 cannot process the
packet. With this feature enabled, the device will make judgment on natural
network basis. Because the IP address of VLAN-interface 10 is a Class A address
and its default mask length is 8, these two IP addresses are on the same natural
network. In this way, VLAN-interface 10 can learn the MAC address of the source
IP address 10.11.11.1.
Follow these steps to enable the support for ARP requests from a natural network:

Enable the support for ARP naturemask-arp enable Required
requests from a natural
Disabled by default
network
ARP Configuration Network requirement

Example ■ Enable the ARP entry check.
■ Set the aging time for dynamic ARP entries to 10 minutes.
■ Enable the support for ARP requests from a natural network.

■ Set the maximum number of dynamic ARP entries that Ethernet 1/0 can learn
to 1,000.
■ Add a static ARP entry, with the IP address being 192.168.1.1/24, the MAC
address being 00e0-fc01-0000, and the outbound interface being Ethernet 1/0
of VLAN 10.
[Sysname] arp check enable
[Sysname] arp timer aging 10
[Sysname] naturemask-arp enable
[Sysname] vlan 10
[Sysname-vlan10] quit
[Sysname] interface vlan-interface 10
[Sysname- vlan-interface10] quit
[Sysname-Ethernet1/0] port access vlan 10
[Sysname-Ethernet1/0] arp max-learning-num 1000
[Sysname] arp static 192.168.1.1 00e0-fc01-0000 10 ethernet1/0
Configuring
Gratuitous ARP
Introduction to A gratuitous ARP packet is a special ARP packet, in which the source IP address
Gratuitous ARP and destination IP address are both the IP address of the sender, the source MAC
address is the MAC address of the sender, and the destination MAC address is a
broadcast address.
A device can implement the following functions by sending gratuitous ARP

packets:
■ Determining whether its IP address is already used by another device.

■ Informing other devices of its MAC address change so that they can update
their ARP entries.
A device receiving a gratuitous ARP packet can add the information carried in the
packet to its own dynamic ARP mapping table if it finds no corresponding ARP
entry for the ARP packet in the cache.
Configuring Gratuitous Follow these steps to configure gratuitous ARP:

ARP
Enable the device to send gratuitous-arp-sending Required
gratuitous ARP packets when enable
By default, a device cannot
receiving ARP requests from
send gratuitous ARP packets
another network segment
when receiving ARP requests
from another network
segment.


Enable the gratuitous ARP gratuitous-arp-learning Required
packet learning function enable
Configuring ARP
Source Suppression
Introduction to ARP If hosts on a network attack the device by sending large amounts of IP packets
Source Suppression whose IP addresses cannot be resolved, the following consequences will be
resulted in:
■ The device sends large amounts of ARP request messages to the destination
subnet, which increases the load of the destination subnet.
■ The device continuously resolves destination IP addresses, which increase the
load of the CPU.
To protect the device against this kind of attack, you can enable the ARP source
suppression function. With the function enabled, whenever the number of
packets with unresolvable IP addresses that a host on the network sends to the
device within five seconds exceeds the specified threshold, the device drops all
subsequent packets with the same source IP address in another five coming
seconds. This helps in protecting the device against the attack.
Configuring ARP Source

Suppression To do... Use the command... Remarks
Enable ARP source arp source-suppression Required
suppression enable
Disabled by default
Set the maximum number of arp source-suppression Optional
packets with the same source limit limit-value
10 by default
IP address but unresolvable
destination IP addresses that
the device can receive in five
seconds
Configuring
Authorized ARP
n This feature is only supported on Layer 3 Ethernet interfaces.
Introduction to Authorized ARP entries are generated based on DHCP leases or security entries for
Authorized ARP DHCP clients.
Authorized ARP can prevent attacks from illegal clients, and allow only legal clients
to access network resources, thus enhancing product security. With authorized
ARP enabled, an interface is disabled from learning dynamic ARP entries.
Static ARP entries can overwrite authorized ARP entries, and authorized ARP
entries can overwrite dynamic ARP entries. But authorized ARP entries cannot

overwrite static ARP entries, and dynamic ARP entries cannot overwrite authorized
ARP entries. The aging mechanism of authorized ARP entries is independent from
that of dynamic ARP entries.
Configuring Authorized Enabling authorized ARP

ARP Follow these steps to enable authorized ARP:

interface-number
Enable authorized ARP on the arp authorized enable Required
interface
Not enabled by default.
Configuring the aging time for authorized ARP entries

Follow these steps to configure the aging time for authorized ARP entries:

interface-number
Configure the aging time for arp authorized time-out Optional
authorized ARP entries seconds
Example for Configuring Network requirements

Authorized ARP on a ■ Router A acts as a DHCP server with an IP address pool of 10.1.1.0/24.
DHCP Server
■ Router B is a DHCP client which obtains an IP address of 10.1.1.2/24 from the
DHCP server.
Network diagram
Figure 157 Network diagram for authorized ARP configuration
DHCP DHCP
server client
Eth1 /0
10 .1 .1.1/24 Eth1/0
Router A Router B
# Configure the IP address of Ethernet 1/0.
[RouterA-Ethernet1/0] ip address 10.1.1.1 24
# Configure DHCP.

[RouterA] dhcp enable

[RouterA] dhcp server ip-pool 1
[RouterA-dhcp-pool-1] network 10.1.1.0 mask 255.255.255.0
[RouterA-dhcp-pool-1] quit
# Enter Layer 3 Ethernet interface view.
# Configure the DHCP server to support authorized ARP.
[RouterA-Ethernet1/0] dhcp update arp
# Enable authorized ARP.
[RouterA-Ethernet1/0] arp authorized enable
# Configure the aging time for authorized ARP entries.
[RouterA-Ethernet1/0] arp authorized time-out 120

[RouterB-Ethernet1/0] ip address dhcp-alloc
3 After Router B obtains the IP address from Router A, display the authorized ARP
information on Router A.
[RouterA] display arp all
Type: S-Static D-Dynamic A-Authorized
IP Address MAC Address VLAN ID Interface Aging Type
10.1.1.2 0012-3f86-e94c N/A Eth1/0 1 A
Example for Configuring Network requirements

Authorized ARP on a ■ Router A acts as a DHCP server with an IP address pool of 10.10.1.0/24.
DHCP Relay Agent
■ Router B is a DHCP relay agent, which conveys IP address 10.10.1.2/24 from
the DHCP server to the DHCP client (Router C).

Network diagram
Figure 158 Network diagram for authorized ARP configuration
DHCP
relay agent
Eth1/0 Eth1/1
10 .1.1.2/24 10 .10 .1.1/24
Router B
DHCP DHCP
server Eth1 /0 Eth1/0 client
10 .1 .1.1/24
Router A Router C
# Configure the IP address of Ethernet 1/0.
# Configure DHCP.

[RouterA-dhcp-pool-1] gateway-list 10.10.1.1
[RouterA] ip route-static 10.10.1.0 24 10.1.1.2
# Enable DHCP.
[RouterB] dhcp enable
# Configure the IP addresses of Ethernet 1/0 and Ethernet 1/1.

[RouterB-Ethernet1/0] ip address 10.1.1.2 24
# Enable DHCP relay agent on Ethernet 1/1.
[RouterB-Ethernet1/1] dhcp select relay

# Add the DHCP server 10.1.1.1 to DHCP server group 1.

Displaying and Maintaining ARP 559
[RouterB] dhcp relay server-group 1 ip 10.1.1.1
# Correlate Ethernet 1/1 to DHCP server group 1.

[RouterB-Ethernet1/1] dhcp relay server-select 1
# Configure the DHCP server to support authorized ARP.
[RouterB-Ethernet1/1] dhcp update arp
# Enable authorized ARP.
[RouterB-Ethernet1/1] arp authorized enable
# Configure the aging time for authorized ARP entries.
[RouterB-Ethernet1/1] arp authorized time-out 120

[RouterC-Ethernet1/0] ip address dhcp-alloc
[RouterC-Ethernet1/0] quit
4 After Router B obtains the IP address from Router A, display the authorized ARP
information on Router B.
[RouterB] display arp all
Type: S-Static D-Dynamic A-Authorized
IP Address MAC Address VLAN ID Interface Aging Type
10.10.1.2 0012-3f86-e94c N/A Eth1/1 1 A
Displaying and
Maintaining ARP To do... Use the command... Remarks
Display the ARP entries in the display arp { { all | dynamic | Available in any view
ARP mapping table static } | vlan vlan-id |
interface-number }
[ [ verbose ] [ | { begin |
exclude | include } string ] |
count ]
Display the ARP entries for a display arp ip-address Available in any view
specified IP address [ verbose ] [ | { begin |
exclude | include } string ]
Display the ARP entries for a display arp vpn-instance Available in any view
specified VPN instance vpn-instance-name [ | { begin
| exclude | include } string |
count ]
Display the aging time for display arp timer aging Available in any view
dynamic ARP entries
Display the configuration display arp Available in any view
information of ARP source source-suppression
suppression


Clear ARP entries from the reset arp { all | dynamic | Available in user view
ARP mapping table static | interface
interface-type
interface-number }

PROXY ARP CONFIGURATION
31
When configuring proxy ARP, go to these sections for information you are
interested in:
■ “Proxy ARP Overview” on page 561
■ “Enabling Proxy ARP” on page 561
■ “Displaying and Maintaining Proxy ARP” on page 562
Proxy ARP Overview For an ARP request of a host on a network to be forwarded to an interface that is
on the same network but isolated at Layer 2 or a host on another network, the
device connecting the two physical or virtual networks must be able to respond to
the request. This is achieved by proxy ARP.
Proxy ARP implements Layer 3 communication between interfaces isolated at

Layer 2 or located on different networks.
In one of the following cases, you need to enable the local proxy ARP:
■ Devices connected to different isolated layer 2 ports in the same VLAN need to
implement layer 3 communication.
■ With the super VLAN function enabled, devices in different sub VLANs need to
implement layer 3 communication.
■ With the isolate-user-vlan function enabled, devices in different second VLANs
need to implement layer 3 communication.
Enabling Proxy ARP Follow these steps to enable proxy ARP in VLAN interface view/Ethernet interface
view or enable local proxy ARP in VLAN interface view:

interface-number
Enter VLAN interface/Ethernet
interface view to enable the
proxy ARP.
Enable proxy ARP proxy-arp enable Required
Disabled by default
Enable local proxy ARP local-proxy-arp enable Required
Disabled by default

562 CHAPTER 31: PROXY ARP CONFIGURATION
Displaying and
Maintaining Proxy To do... Use the command... Remarks
ARP Display whether proxy ARP is display proxy-arp Available in any view
enabled [ interface interface-type
interface-number ]
Display whether local proxy display local-proxy-arp Available in any view
ARP is enabled [ interface interface-type
interface-number ]
Proxy ARP
Configuration
Examples
Proxy ARP Configuration Network requirements

Example Host A and Host D are on the same subnet. But from the angle of the device, they
are located in different subnets. Configure proxy ARP on the device to enable the
communication between Host A and Host D.
Network diagram
Figure 159 Network diagram for proxy ARP
Host A Host B
192.168.10.100/16
0000.0c94.36aa
Subnet A
Eth1/0
192 .168 .10 .99 /24
Router
Eth1/1
192.168.20.99/24
Subnet B
192 .168 .20 .200 /16

0000 .0 c94 .36 dd
Host C Host D
1 Configure the IP address 192.168.10.99/24 for Ethernet 1/0 and
192.168.20.99/24 for Ethernet 1/1.
2 Configure ARP on the device to enable the communication between Host A and
Host D.
[Router-Ethernet1/0] proxy-arp enable

Proxy ARP Configuration Examples 563

[Router-Ethernet1/1] proxy-arp enable
Local Proxy ARP Network requirements

Configuration Example ■ Host A and Host B belong to the same VLAN, and are connected to Ethernet
in Case of Port Isolation 1/0 and Ethernet 1/1 of the switch respectively.
■ The switch is connected to the router via Ethernet 1/2.
■ Ethernet 1/0 and Ethernet 1/1 isolated at Layer 2 can implement Layer 3
communication.
Network diagram
Figure 160 Network diagram for local proxy ARP between isolated ports
Router
Eth1/0
VLAN 2
Vlan -int2
192 .168 .10 .100 /16
VLAN 2
port-isolate group2
Eth1/2
uplink -port
Eth1/0
Eth1/1
Host A Switch Host B

192 .168 .10.99/16 192.168.10.200 /16
n ■
■
The switch in this diagram is a distributed device.
The switch isolates all traffic in this configuration example, so you need to
configure local proxy ARP on VLAN-interface 2 of the router to enable the
communication between Host A and Host B. If the two ports (Ethernet 1/0 and
Ethernet 1/1) on the switch are isolated only at Layer 2, you can enable the
communication between the two hosts by configuring local proxy ARP directly
on VLAN-interface 2 of the switch.
1 Configure the Switch
# Add Ethernet 1/0, Ethernet 1/1 and Ethernet 1/2 to VLAN 2. Host A and Host B
are isolated and unable to exchange Layer 2 packets.
<Switch> system-view
[Switch] port-isolate group 2
[Switch] vlan 2
[Switch-vlan2] port ethernet 1/0
[Switch-vlan2] quit

564 CHAPTER 31: PROXY ARP CONFIGURATION
[Switch] interface ethernet 1/0

[Switch-Ethernet1/0] port-isolate enable group 2
[Switch-Ethernet1/0] interface ethernet 1/1
[Switch-Ethernet1/1] port-isolate enable group 2
[Switch-Ethernet1/1] interface ethernet 1/2
[Switch-Ethernet1/2] port-isolate uplink-port group 2
2 Configure the Router
# Create VLAN 2, and add Ethernet 1/0 to VLAN 2.
[Router] vlan 2
[Router-vlan2] port ethernet 1/0
[Router-vlan2] interface vlan-interface 2
[Router-Vlan-interface2] ip address 192.168.10.100 255.255.0.0
Ping Host B on Host A to verify that Host B cannot be pinged, which indicates they
are isolated at Layer 2.
# Configure local proxy ARP to let Host A and Host B communicate at Layer 3.
[Router-Vlan-interface2] local-proxy-arp enable

[Router-Vlan-interface2] quit
Ping Host B on Host A to verify that Host B can be pinged, which indicates Layer 3
communication is implemented.

DHCP OVERVIEW
32
This document is organized as follows:
■ “DHCP Overview” on page 565
■ “DHCP Server Configuration” on page 573
■ “DHCP Relay Agent Configuration” on page 589
■ “DHCP Client Configuration” on page 599
■ “DHCP Snooping Configuration” on page 601
■ “BOOTP Client Configuration Example” on page 606
Introduction to DHCP The fast expansion and growing complexity of networks result in scarce IP
addresses assignable to hosts. Meanwhile, with the wide application of wireless
networks, the frequent movement of laptops across networks requires that the IP
addresses be changed accordingly. Therefore, related configurations on hosts
become more complex. Dynamic host configuration protocol (DHCP) was
introduced to solve these problems.
DHCP is built on a client-server model, in which the client sends a configuration

request and then the server returns a reply to send configuration parameters such
as an IP address to the client.
A typical DHCP application, as shown in Figure 161, includes a DHCP server and
multiple clients (PCs and laptops).
Figure 161 A typical DHCP application
DHCP client DHCP client

DHCP server
n When residing in a different subnet from the DHCP server, the DHCP client can get
the IP address and other configuration parameters from the server via a DHCP

566 CHAPTER 32: DHCP OVERVIEW
relay agent. For information about the DHCP relay agent, refer to “Introduction to
DHCP Relay Agent” on page 589.
DHCP Address
Allocation
Allocation Mechanisms DHCP supports three mechanisms for IP address allocation.

■ Manual allocation: The network administrator assigns an IP address to a client
like a WWW server, and DHCP conveys the assigned address to the client.
■ Automatic allocation: DHCP assigns a permanent IP address to a client.
■ Dynamic allocation: DHCP assigns an IP address to a client for a limited period
of time, which is called a lease. Most clients obtain their addresses in this way.
Dynamic IP Address Figure 162 Dynamic IP address allocation process

Allocation Procedure
DHCP client DHCP server
(1) DHCP-DISCOVER
(2) DHCP-OFFER
(3) DHCP-REQUEST
(4) DHCP-ACK
As shown in the figure above, a DHCP client obtains an IP address from a DHCP
server via four steps:
1 The client broadcasts a DHCP-DISCOVER message to locate a DHCP server.

2 A DHCP server offers configuration parameters such as an IP address to the client
in a DHCP-OFFER message. The sending mode of the DHCP-OFFER is determined
by the flag field in the DHCP-DISCOVER message. Refer to “DHCP Message
Format” on page 567 for related information.
3 If several DHCP servers send offers to the client, the client accepts the first received
offer, and broadcasts it in a DHCP-REQUEST message to formally request the IP
address.
4 All DHCP servers receive the DHCP-REQUEST message, but only the server to
which the client sent a formal request for the offered IP address returns a
DHCP-ACK message to the client, confirming that the IP address has been
allocated to the client, or returns a DHCP-NAK unicast message, denying the IP
address allocation.
n ■ After the client receives the DHCP-ACK message, it will probe whether the IP
address assigned by the server is in use by broadcasting gratuitous ARP. If the
client receives no response within specified time, the client can use this IP

DHCP Message Format 567
address. Otherwise, the client sends a DHCP-DECLINE message to the server to

request an IP address again.
■ If there are multiple DHCP servers, IP addresses offered by other DHCP servers
are assignable to other clients.
IP Address Lease The IP address dynamically allocated by a DHCP server to a client has a lease. After
Extension the lease duration elapses, the IP address will be reclaimed by the DHCP server. If
the client wants to use the IP address again, it has to extend the lease duration.
After the half lease duration elapses, the DHCP client will send the DHCP server a
DHCP-REQUEST unicast message to extend the lease duration. Upon availability of
the IP address, the DHCP server returns a DHCP-ACK unicast confirming that the
client’s lease duration has been extended, or a DHCP-NAK unicast denying the
request.
If the client receives the DHCP-NAK message, it will broadcast another

DHCP-REQUEST message for lease extension after 7/8 lease duration elapses. The
DHCP server will handle the request as above mentioned.
DHCP Message Format Figure 163 gives the DHCP message format, which is based on the BOOTP
message format and involves eight types. These types of messages have the same
format except that some fields have different values. The numbers in parentheses
indicate the size of each field in octets.
Figure 163 DHCP message format
0 7 15 23 31
op (1) htype (1) hlen (1) hops (1)
xid (4)
secs (2) flags (2)
ciaddr (4)
yiaddr (4)
siaddr (4)
giaddr (4)
chaddr (16)
sname (64)
file (128)
options (variable)
■ op: Message type defined in option field. 1 = REQUEST, 2 = REPLY

■ htype,hlen: Hardware address type and length of a DHCP client.
■ hops: Number of relay agents a request message traveled.
■ xid: Transaction ID, a random number chosen by the client to identify an IP
address allocation.
■ secs: Filled in by the client, the number of seconds elapsed since the client
began address acquisition or renewal process. Currently this field is reserved
and set to 0.

■ flags: The leftmost bit is defined as the BROADCAST (B) flag. This flag indicates
whether the DHCP server sends a reply back by unicast or broadcast. If this flag
is set to 0, the DHCP server sent a reply back by unicast; if this flag is set to 1,
the DHCP server sent a reply back by broadcast. The remaining bits of the flags
field are reserved.
■ ciaddr: Client IP address.
■ yiaddr: ’your’ (client) IP address, assigned by the server.
■ siaddr: Server IP address, from which the clients obtained configuration
parameters.
■ giaddr: The first relay agent IP address a request message traveled.
■ chaddr: Client hardware address.
■ sname: The server host name, from which the client obtained configuration
parameters.
■ file: Bootfile name and routing information, defined by the server to the client.
■ options: Optional parameters field that is variable in length, which includes the
message type, lease, DNS IP address, WINS IP address and so forth.
DHCP Options
DHCP Options Overview The DHCP message adopts the same format as the Bootstrap Protocol (BOOTP)
message for compatibility, but differs from it in the option field, which identifies
the new features of DHCP.
DHCP uses the option field in DHCP messages to carry control information and
network configuration parameters, implementing dynamic address allocation and
providing more network configuration information for clients.
Figure 164 shows the DHCP option format.
Figure 164 DHCP option format
0 7 15
Option type Option length
Value (variable)
Introduction to DHCP The common DHCP options are:

Options ■ Option 6: DNS server option. It specifies the DNS server IP address to be
assigned to the client.
■ Option 51: IP address lease option.
■ Option 53: DHCP message type option. It identifies the type of the DHCP
message.
■ Option 55: Parameter request list option. It is used by a DHCP client to request
specified configuration parameters. The option contains values that correspond
to the parameters requested by the client.

DHCP Options 569
■ Option 66: TFTP server name option. It specifies a TFTP server to be assigned to
the client.
■ Option 67: Bootfile name option. It specifies the bootfile name to be assigned
to the client.
■ Option 150: TFTP server IP address option. It specifies the TFTP server IP address
to be assigned to the client.
For more information about DHCP options, refer to RFC 2132.
Self-Defined Options Some options, such as Option 43, have no unified definitions in RFC 2132. The
formats of some self-defined options are introduced as follows.
Vendor-specific option (Option 43)

DHCP servers and clients exchange vendor-specific information through messages
containing the vendor-specific option (Option 43). Upon receiving a DHCP
message requesting Option 43 (in Option 55), the DHCP server returns a response
message containing Option 43 to assign vendor-specific information to the DHCP
client.
The DHCP client can obtain the preboot executive environment (PXE) server
address through Option 43, to further obtain the bootfile or other control
information from the PXE server.
Figure 165 shows the format of Option 43.
Figure 165 Format of Option 43
0 7 15 23 31
Option type (0x2B) Option length Sub-option type (0x80) Sub-option length
PXE server list (variable)
...
For scalability sake, the PXE server address is configured as a sub-option of Option
43 so that the DHCP client can obtain more information through Option 43. The
value of the sub-option type is 0x80.
Figure 166 shows the format of the PXE server address list. Currently, the value of
the PXE server type can only be 0.
Figure 166 Format of PXE server address list
0 7 15
PXE server type (0x0000)
Server number
Server IP addresses (variable)

Relay agent option (Option 82)

Option 82 is the relay agent option in the option field of the DHCP message. It
records the location information of the DHCP client. When a DHCP relay agent
receives a client’s request, it adds Option 82 to the request message and sends it
to the server.
The administrator can locate the DHCP client to further implement security control
and accounting. The server supporting Option 82 can also use such information to
define individual assignment policies of IP address and other parameters for the
clients.
Option 82 involves at most 255 sub-options. At least one sub-option must be

defined. Now the DHCP relay agent supports two sub-options: sub-option 1
(Circuit ID) and sub-option 2 (Remote ID).
Option 82 has no unified definition. Its padding formats vary with vendors.
Currently the device supports two padding formats: normal and verbose.
1 Normal padding format
The padding contents for sub-options in the normal padding format are:
■ sub-option 1: Padded with the VLAN ID and interface number of the interface
that received the client’s request. The following figure gives its format. The
value of the sub-option type is 1, and that of the circuit ID type is 0.
Figure 167 Sub-option 1 in normal padding format
0 7 15 23 31
Sub-option type (0x01) Length (0x06) Circuit ID type (0x00) Length (0x04)
VLAN ID Interface number
■ sub-option 2: Padded with the MAC address of the interface that received the
client’s request. The following figure gives its format. The value of the
sub-option type is 2, and that of the remote ID type is 0.
Figure 168 Sub-option 2 in normal padding format
0 7 15 23 31
Sub-option type (0x02) Length (0x08) Remote ID type (0x00) Length (0x06)
MAC Address
2 Verbose padding format:
The padding contents for sub-options in the verbose padding format are:
■ sub-option 1: Padded with the user-specified access node identifier (ID of the
device that adds Option 82 in DHCP messages), and type, number, PVC
identifier (used when the interface type is ATM), and VLAN ID of the interface
that received the client’s request. Its format is shown in the following figure.

Figure 169 Sub-option 1 in verbose padding format
Sub-option type (0x01) Length Node identifier
Interface type Interface number
PVC identifier VLAN ID
n In the above figure, except that the VLAN ID field has a fixed length of 2 bytes, all
the other padding contents of sub-option 1 are length variable.
■ sub-option 2: Padded with the MAC address of the interface that received the
client’s request. It has the same format as that in normal padding format, as
shown in Figure 168.
Option 184
Option 184 is a reserved option, and parameters in the option can be defined as
needed. The device supports Option 184 carrying the voice related parameters, so
a DHCP client with voice functions can get an IP address along with specified voice
parameters from the DHCP server.
Option 184 involves the following sub-options:
■ Sub-option 1: IP address of the primary network calling processor, which is a

server serving as the network calling control source and providing program
downloads.
■ Sub-option 2: IP address of the backup network calling processor that DHCP
clients will contact when the primary one is unreachable.
■ Sub-option 3: Voice VLAN ID and the result whether DHCP clients take this ID
as the voice VLAN or not.
■ Sub-option 4: Failover route that specifies the destination IP address and the
called number (SIP users use such IP addresses and numbers to communicate
with each other) that a SIP user uses to reach another SIP user when both the
primary and backup calling processors are unreachable.
n You must define sub-option 1 to make other sub-options take effect.
Protocols and ■ RFC2131:Dynamic Host Configuration Protocol

Standards ■ RFC2132:DHCP Options and BOOTP Vendor Extensions
■ RFC1542:Clarifications and Extensions for the Bootstrap Protocol


DHCP SERVER CONFIGURATION
33
When configuring the DHCP server, go to these sections for information you are
interested in:
■ “Introduction to DHCP” on page 565
■ “DHCP Server Configuration Task List” on page 575
■ “Enabling DHCP” on page 575
■ “Enabling the DHCP Server on an Interface” on page 575
■ “Configuring an Address Pool for the DHCP Server” on page 576
■ “Configuring the DHCP Server Security Functions” on page 582
■ “Configuring the Handling Mode for Option 82” on page 584
■ “Displaying and Maintaining the DHCP Server” on page 585
■ “DHCP Server Configuration Examples” on page 585
■ “Troubleshooting DHCP Server Configuration” on page 588
n ■ The DHCP server configuration is supported only on Layer 3 Ethernet interfaces

(or subinterfaces), virtual Ethernet interfaces, VLAN interfaces, serial interfaces,
and loopback interfaces. The secondary IP address pool configuration is not
supported on serial or loopback interfaces.
■ DHCP Snooping must be disabled on the DHCP server.
Introduction to DHCP
Server
Application The DHCP server is well suited to the network where:

Environment ■ It is hard to implement manual configuration and centralized management.
■ The hosts are more than the assignable IP addresses and it is impossible to
assign a fixed IP address to each host. For example, an ISP limits the number of
hosts to access the Internet at a time, so lots of hosts need to acquire IP
addresses dynamically.
■ A few hosts need fixed IP addresses.
DHCP Address Pool Address pool structure

The DHCP server selects an IP address from an address pool and sends it together
with other parameters to the client.
The address pool database is organized as a tree. The root of the tree is the
address pool for natural networks, branches are address pools for subnets, and

574 CHAPTER 33: DHCP SERVER CONFIGURATION
leaves are addresses statically bound to clients. For the same level address pools, a
previously configured pool has a higher selection priority than a new one.
At the very beginning, subnetworks inherit network parameters and clients inherit
subnetwork parameters. Therefore, common parameters, the DNS server address
for example, should be configured at the highest (network or subnetwork) level of
the tree.
After establishment of the inheritance relationship, the new configuration at the

higher level of the tree will be:
■ Inherited if the lower level has no such configuration, or

■ Overridden if the lower level has such configuration.
n The IP address lease does not have any inheritance
Principles for selecting an address pool

The DHCP server observes the following principles to select an address pool to
assign IP addresses to clients:
1 If there is an address pool where IP addresses are statically bound to the MAC
addresses or IDs of clients, the DHCP server will select this address pool and assign
statically bound IP addresses to clients. For the configuration of this address pool,
refer to “Configuring manual address allocation” on page 576.
2 Otherwise, the DHCP server will select the smallest address pool that contains the
IP address of the interface receiving DHCP requests, regardless of the mask. If no IP
address is available in the smallest address pool, the DHCP server will fail to assign
addresses to clients because it will not assign those in the father address pool to
clients. For the configuration of the smallest address pool, refer to “Configuring
dynamic address allocation” on page 577.
For example, two address pools are configured on the DHCP server. The ranges of
IP addresses that can be dynamically assigned are 1.1.1.0/24 and 1.1.1.0/25
respectively. If the IP address of the interface receiving DHCP requests is
1.1.1.1/25, the DHCP server will select IP addresses for clients from the 1.1.1.0/25
address pool. If no IP address is available in the 1.1.1.0/25 address pool, the DHCP
server will fail to assign addresses to clients. If the IP address of the interface
receiving DHCP requests is 1.1.1.130/25, the DHCP server will select IP addresses
for clients from the 1.1.1.0/24 address pool.
n Keep the IP addresses for dynamic allocation within the subnet where the
interface of the DHCP server resides to avoid wrong IP address allocation.
IP Address Allocation A DHCP server assigns an IP address to a client according to the following
Sequence sequence:
1 The IP address manually bound to the client’s MAC address or ID
2 The IP address that was ever assigned to the client
3 The IP address designated by the Option 50 field in a DHCP-DISCOVER message
4 The first IP address found in a proper DHCP address pool
5 The IP address that was a conflict or passed its lease duration

DHCP Server Configuration Task List 575
If no IP address is assignable, the server will not respond.
DHCP Server To configure the DHCP server feature, perform the tasks described in the following
Configuration Task sections:
List
Task Remarks
“Enabling DHCP” on page 575 Required
“Enabling the DHCP Server on an Interface” on page 575 Optional
“Configuring an Address Pool for the DHCP Server” on page 576 Required
“Configuring the DHCP Server Security Functions” on page 582 Optional
“Configuring the Handling Mode for Option 82” on page 584 Optional
Enabling DHCP Enable DHCP before performing other configurations.

Enable DHCP dhcp enable Required
Disabled by default
Enabling the DHCP With the DHCP server enabled on an interface, upon receiving a client’s request,
Server on an Interface the DHCP server will assign an IP address from its address pool to the DHCP client.
Follow these steps to enable the DHCP server on an interface:

interface-number
Enable the DHCP server on an dhcp select server Optional
interface global-pool [ subaddress ]
Enabled by default.
n The subaddress keyword is valid only when the server and client are on the same
subnet. If a DHCP relay agent exists in between, regardless of subaddress, the
DHCP server will select an IP address from the address pool of the subnet which
contains the primary IP address of the DHCP relay agent’s interface (connected to
the client).
When the DHCP server and client are on the same subnet, the server will
■ With subaddress specified, assign an IP address from the address pool of the
subnet which the secondary IP address of the server’s interface connected to
the client belongs to, or assign from the first secondary IP address if several
secondary IP addresses exist. If no secondary IP address is configured for the
interface, the server is unable to assign an IP address to the client.
■ Without subaddress specified, assign an IP address from the address pool of
the subnet which the primary IP address of the server’s interface (connected to
the client) belongs to.

Configuring an
Address Pool for the
DHCP Server
Configuration Task List To configure an address pool, perform the tasks described in the following
sections:
Task Remarks
“Creating a DHCP Address Pool” on page 576 Required
“Configuring an Address “Configuring manual address Required to configure either
Allocation Mechanism” on allocation” on page 576 of the two
page 576
“Configuring dynamic
address allocation” on page
577
“Configuring a Domain Name Suffix for the Client” on page Optional
578
“Configuring DNS Servers for the Client” on page 578
“Configuring WINS Servers and NetBIOS Node Type for the
Client” on page 579
“Configuring the BIMS server Information for the Client” on
page 579
“Configuring Gateways for the Client” on page 580
“Configuring Option 184 Parameters for the Client with Voice
Service” on page 580
“Configuring the TFTP Server and Bootfile Name for the
Client” on page 581
“Configuring Self-Defined DHCP Options” on page 581
Creating a DHCP To create a DHCP address pool, use the following commands:
Address Pool
Create a DHCP address pool dhcp server ip-pool Required
and enter its view pool-name
No DHCP address pool is
created by default.
Configuring an Address
Allocation Mechanism
c CAUTION: You can configure either the static binding or dynamic address
allocation for an address pool as needed.
It is required to specify an address range for the dynamic address allocation. A

static binding is a special address pool containing only one IP address.
Configuring manual address allocation

Some DHCP clients such as a WWW server need fixed IP addresses. You can create
a static binding of a client’s MAC or ID to IP address in the DHCP address pool.

When the client with the MAC address or ID requests an IP address, the DHCP
server will find the IP address from the binding for the client.
A DHCP address pool now supports only one static binding, which can be a
MAC-to-IP or ID-to-IP binding.
To configure the static binding in a DHCP address pool, use the following
commands:

Enter DHCP address pool view dhcp server ip-pool -
pool-name
Bind IP addresses statically static-bind ip-address Required
ip-address [ mask-length |
No IP addresses are
mask mask ]
statically bound by default
Bind MAC Specify the MAC static-bind mac-address Required to configure either
addresses or address mac-address of the two
IDs statically
Specify the ID static-bind Neither is bound statically
client-identifier by default
client-identifier
n ■ Use the static-bind ip-address command together with static-bind

mac-address or static-bind client-identifier command to accomplish a
static binding configuration.
■ In a DHCP address pool, if you execute the static-bind mac-address
command before the static-bind client-identifier command, the latter will
overwrite the former and vice versa.
■ If you use the static-bind ip-address, static-bind mac-address, or
static-bind client-identifier command repeatedly in the DHCP address pool,
the new configuration will overwrite the previous one.
■ The IP address of the static binding cannot be an interface address of the DHCP
server. Otherwise, an IP address conflict may occur and the bound client cannot
obtain an IP address correctly.
■ The ID of the static binding must be identical to the ID displayed by using the
display dhcp client verbose command on the client. Otherwise, the client
cannot obtain an IP address.
Configuring dynamic address allocation

You need to specify one and only one address range using a mask for the dynamic
address allocation.
To avoid address conflicts, the DHCP server excludes IP addresses used by the GW,
FTP server and so forth from dynamic allocation.
You can specify the lease duration for a DHCP address pool different from others,
and a DHCP address pool can only have the same lease duration. A lease does not
enjoy the inheritance attribute.
To configure the dynamic address allocation, use the following commands:


pool-name
Specify an IP address range network network-address Required
[ mask-length | mask mask ]
Not specified by default,
meaning no assignable
address.
Specify the address lease expired { day day [ hour Optional
duration hour [ minute minute ] ] |
One day by default.
unlimited }
Exclude IP addresses from dhcp server forbidden-ip Optional
automatic allocation low-ip-address
Except IP addresses of the
[ high-ip-address ]
DHCP server interfaces, all
addresses in the DHCP
address pool are assignable by
default.
n ■ In DHCP address pool view, using the network command repeatedly

overwrites the previous configuration.
■ Using the dhcp server forbidden-ip command repeatedly can specify
multiple IP address ranges not assignable.
Configuring a Domain You can specify a domain name suffix in each DHCP address pool on the DHCP
Name Suffix for the server for the clients. With this suffix assigned, the client needs only input part of a
Client domain name, and the system will add the domain name suffix for name
resolution. For details about DNS, refer to “DNS Overview” on page 609.
To configure a domain name suffix in the DHCP address pool, use the following
commands:

pool-name
Specify the domain name domain-name domain-name Required
suffix for the client
Configuring DNS Servers When a DHCP client wants to access a host on the Internet via the host name, it
for the Client contacts a domain name system (DNS) server holding host name-to-IP address
mappings to get the host IP address. You can specify up to eight DNS servers in the
DHCP address pool.
To configure DNS servers in the DHCP address pool, use the following commands:



pool-name
Specify DNS servers for the dns-list ip-address&<1-8> Required
client
Configuring WINS A Microsoft DHCP client using NetBIOS protocol contacts a Windows Internet
Servers and NetBIOS Naming Service (WINS) server for name resolution. Therefore, the DHCP server
Node Type for the Client should assign a WINS server address when assigning an IP address to the client.
You can specify up to eight WINS servers in a DHCP address pool.
You need to specify in a DHCP address pool a NetBIOS node type for the client to
approach name resolution. There are four NetBIOS node types:
■ b (broadcast)-node: The b-node client sends the destination name in a

broadcast message. The destination returns its IP address to the client after
receiving the message.
■ p (peer-to-peer)-node: The p-node client sends the destination name in a
unicast message to the WINS server, and the WINS server returns the
destination IP address.
■ m (mixed)-node: A combination of broadcast first and peer-to-peer second.
The m-node client broadcasts the destination name, if no response, then
unicasts the destination name to the WINS server to get the destination IP
address.
■ h (hybrid)-node: A combination of peer-to-peer first and broadcast second. The
h-node client unicasts the destination name to the WINS server, if no response,
then broadcasts it to get the destination IP address.
To configure WINS servers and NetBIOS node type in the DHCP address pool, use
the following commands:

pool-name
Specify WINS server IP nbns-list ip-address&<1-8> Required (optional for b-node)
addresses for the client
No address is specified by
default
Specify the NetBIOS node type netbios-type { b-node | Required
h-node | m-node | p-node }
n If b-node is specified for the client, you need to specify no WINS server address.
Configuring the BIMS A DHCP client performs regular software update and backup using configuration
server Information for files obtained from a branch intelligent management system (BIMS) server.
the Client Therefore, the DHCP server needs to offer DHCP clients the BIMS server IP address,
port number, shared key from the DHCP address pool.

To configure the BIMS server IP address, port number, and shared key in the DHCP
address pool, use the following commands:

Enter DHCP address pool view dhcp server ip-pool pool-name -
Specify the BIMS server IP bims-server ip ip-address [ port Required
address, port number, and port-number ] sharekey key
shared key
Configuring Gateways DHCP clients that want to access hosts outside the local subnet request gateways
for the Client to forward data. You can specify gateways in each address pool for clients and the
DHCP server will assign gateway addresses while assigning an IP address to the
clients. Up to eight gateways can be specified in a DHCP address pool.
To configure the gateways in the DHCP address pool, use the following
commands:

pool-name
Specify gateways gateway-list Required
ip-address&<1-8>
No gateway is specified by
default.
Configuring Option 184 To assign voice calling parameters along with an IP address to DHCP clients with
Parameters for the voice service, you need to configure Option 184 on the DHCP server. For
Client with Voice Service information about Option 184, refer to “Option 184” on page 571.
If option 55 in the request from a DHCP client contains option 184, the DHCP
server will return parameters specified in option 184 to the client. The client then
can initiate a call using parameters in Option 184.
To configure option 184 parameters in the DHCP address pool, use the following
commands:

pool-name
Specify the IP address of the voice-config ncp-ip Required
primary network calling ip-address
processor
Specify the IP address of the voice-config as-ip ip-address Optional
backup network calling
processor
Configure the voice VLAN voice-config voice-vlan Optional
vlan-id { disable | enable }


Specify the failover IP address voice-config fail-over Optional
ip-address dialer-string
No failover IP address is
specified by default
n Specify an IP address for the network calling processor before performing other
configuration.
Configuring the TFTP This task is to specify the IP address and name of a TFTP server and the bootfile
Server and Bootfile name in the DHCP address pool. The DHCP clients use these parameters to
Name for the Client contact the TFTP server, requesting the configuration file used for system
initialization, which is called autoconfiguration. The request process of the client is
described below:
1 When a router starts up without loading any configuration file, the system sets an
active interface (such as the interface of the default VLAN or a Layer 3 Ethernet
interface) as the DHCP client to request from the DHCP server parameters such as
an IP address and name of a TFTP server, and the bootfile name.
2 After getting related parameters, the DHCP client will send a TFTP request to
obtain the configuration file from the specified TFTP server for system initialization.
If the client cannot get such parameters, it will perform system initialization
without loading any configuration file.
To implement auto-configuration, you need to specify the IP address and name of

a TFTP server and the bootfile name in the DHCP address pool on the DHCP server,
but you do not need to perform any configuration on the DHCP client.
When option 55 in the requesting client message contains parameters of option

66, option 67, or option 150, the DHCP server will return the IP address and name
of the specified TFTP server, and bootfile name to the client.
To configure the IP address and name of the TFTP server and the bootfile name in
the DHCP address pool, use the following commands:

pool-name
Specify the TFTP server tftp-server ip-address Optional
ip-address
Specify the name of the TFTP tftp-server domain-name Optional
server domain-name
Specify the bootfile name bootfile-name Optional
bootfile-name
Configuring By configuring self-defined DHCP options, you can

Self-Defined DHCP ■ Define new DHCP options. New configuration options will come out with
Options DHCP development. To support these new options, you can add them into the
attribute list of the DHCP server.

■ Define existing DHCP options. Some options have no unified definitions in RFC
2132; however, vendors can define such options as Option 43 as needed. The
self-defined DHCP option enables DHCP clients to obtain vendor-specific
information.
■ Expand existing DHCP options. When the current DHCP options cannot meet
the customer’s requirements (for example, you cannot use the dns-list
command to configure more than eight DNS server addresses), you can expand
these options.
To configure a self-defined DHCP option in the DHCP address pool, use the
following commands:

Enter DHCP address pool dhcp server ip-pool pool-name -
view
Configure a self-defined option code { ascii ascii-string | hex Required
DHCP option hex-string&<1-16> | ip-address
No DHCP option is
ip-address&<1-8> }
Table 33 Description of common options
Corresponding
Option Name command Parameter
3 Router Option gateway-list ip-address
6 Domain Name Server Option dns-list ip-address
15 Domain Name domain-name ascii
44 NetBIOS over TCP/IP Name Server nbns-list ip-address
Option
46 NetBIOS over TCP/IP Node Type netbios-type hex
Option
51 IP Address Lease Time expired hex
58 Renewal (T1) Time Value expired hex
59 Rebinding (T2) Time Value expired hex
66 TFTP server name tftp-server ascii
67 Bootfile name bootfile-name ascii
43 Vendor Specific Information - hex
c CAUTION:
■ Be careful when configuring self-defined DHCP options because the
configuration of these options may affect the DHCP operation process.
■ When you use self-defined option (Option 51) to configure the IP address lease
duration, convert the lease duration into seconds in hexadecimal notation.
Configuring the DHCP This configuration is necessary to secure DHCP services on the DHCP server.
Server Security
Functions

Configuring the DHCP Server Security Functions 583
Configuration Before performing this configuration, complete the following configuration on the
Prerequisites DHCP server:
■ Enable DHCP
■ Configure the DHCP address pool
Enabling Unauthorized There are unauthorized DHCP servers on networks, which reply DHCP clients with
DHCP Server Detection wrong IP addresses.
With this feature enabled, when receiving a DHCP message with the siaddr field
not being 0 from a client, the DHCP server will record the value of the siaddr field
in the message and the receiving interface. The administrator can use this
information to check out any DHCP unauthorized servers.
To enable unauthorized DHCP server detection, use the following commands:

Enable unauthorized DHCP dhcp server detect Required
server detection
Disabled by default
n With the unauthorized DHCP server detection enabled, the device puts a record
once for each DHCP server. The administrator needs to find unauthorized DHCP
servers from the log information.
Configuring IP Address To avoid IP address conflicts, the DHCP server checks whether the address to be
Conflict Detection assigned is in use via sending ping packets.
The DHCP server pings the IP address to be assigned using ICMP. If the server gets
a response within the specified period, the server will ping another IP address;
otherwise, the server will ping the IP addresses once again until the specified
number of ping packets are sent. If still no response, the server will assign the IP
address to the requesting client (The DHCP client probes the IP address by sending
gratuitous ARP packets).
To configure IP address conflict detection, use the following commands:

Specify the number of dhcp server ping Optional
ping packets packets number
One ping packet by default.
The value "0" indicates that the DHCP
server does not perform any ping collision
detection.
Configure the timeout dhcp server ping Optional
value for ping packets timeout milliseconds
500 ms by default.
The value "0" indicates that the DHCP
server does not perform any ping collision
detection.

Configuring the DHCP A DHCP server can work in cooperation with authorized ARP to block illegal
Server to Support clients, avoid learning incorrect ARP entries and guard against attacks such as
Authorized ARP MAC address spoofing. Only the clients that have valid leases on the DHCP server
are considered legal clients.
When authorized ARP is enabled, the ARP automatic learning function is disabled.
ARP entries can only be added by the authentication module, the DHCP server,
which notifies authorized ARP to add/delete/change authorized ARP entries when
adding/deleting/changing IP address leases. Thus, only the clients that have
obtained IP addresses from the DHCP server can access the network normally,
while other clients are considered illegal clients and are unable to access the
network.
Follow these steps to configure the DHCP server to support authorized ARP:

interface-number
Configure the DHCP server to dhcp update arp Required
support authorized ARP
Not supported by default.
n ■
■
Authorized ARP can only be configured on Layer 3 interfaces.
When the working mode of the interface is changed from DHCP server to
DHCP relay agent, neither the IP address leases nor the authorized ARP entries
will be deleted. However, these ARP entries may conflict with the new static
entries generated on the DHCP relay agent; therefore, you are recommended
to delete the existing IP address leases when changing the interface working
mode to DHCP relay agent.
■ Disabling the DHCP server to support authorized ARP will not delete the IP
address leases, but will notify authorized ARP to delete the corresponding
authorized ARP entries.
■ For more information about authorized ARP, refer to “Configuring Authorized
ARP” on page 555.
Configuring the When the DHCP server receives a message with Option 82, if the server is
Handling Mode for configured to handle Option 82, it will return a response message carrying Option
Option 82 82 to assign an IP address to the requesting client.
If the server is configured to ignore Option 82, it will assign an IP address to the
client without adding Option 82 in the response message.
Configuration prerequisites
Before performing this configuration, complete the following configuration on the
DHCP server:
■ Enable DHCP
■ Configure the DHCP address pool

Displaying and Maintaining the DHCP Server 585
Configuring the handling mode for Option 82

To enable the DHCP server to handle Option 82, use the following commands:

Enable the server to handle dhcp server relay Optional
Option 82 information enable
Enabled by default
n To support Option 82, it is required to perform configuration on both the DHCP

server and relay agent. Refer to “Configuring the DHCP Relay Agent to Support
Option 82” on page 595 for related configuration details.
Displaying and
Maintaining the DHCP To do... Use the command... Remarks
Server Display information about IP display dhcp server conflict { all | ip Available in any
address conflicts ip-address } view
Display information about display dhcp server expired { all | ip
lease expiration ip-address | pool [ pool-name ] }
Display information about display dhcp server free-ip
assignable IP addresses
Display IP addresses excluded display dhcp server forbidden-ip
from dynamic allocation in
the DHCP address pool
Display information about display dhcp server ip-in-use { all | ip
bindings ip-address | pool [ pool-name ] }
Display information about display dhcp server statistics
DHCP server statistics
Display information about the display dhcp server tree { all | pool
address pool tree [ pool-name ] }
organization
Clear information about IP reset dhcp server conflict { all | ip Available in user
address conflicts ip-address } view
Clear information about reset dhcp server ip-in-use { all | ip
dynamic bindings ip-address | pool [ pool-name ] }
Clear information about reset dhcp server statistics
DHCP server statistics
n Using the save command does not save DHCP server lease information. Therefore,
when the system boots up or the reset dhcp server ip-in-use command is
executed, no lease information will be available in the configuration file. In this
case, the server will deny the request for lease extension from a client and the
client needs to request an IP address again.
DHCP Server
Configuration
Examples
DHCP Server DHCP networking involves two types:

Configuration Example

■ The DHCP server and client are on the same subnet and perform direct
message delivery.
■ The DHCP server and client are not on the same subnet and communicate with
each other via a DHCP relay agent.
The DHCP server configuration for the two types is the same.
Network requirements
■ The DHCP server (Router A) assigns IP address to clients on the subnet
10.1.1.0/24, which is subnetted into 10.1.1.0/25 and 10.1.1.128/25.
■ The IP addresses of Ethernet1/1 and Ethernet1/2 on Router A are 10.1.1.1/25
and 10.1.1.129/25 respectively.
■ In the subnet 10.1.1.0/25, the address lease duration is ten days and twelve
hours, domain name suffix aabbcc.com, DNS server address 10.1.1.2, WINS
server address 10.1.1.4, and gateway address 10.1.1.126.
■ In the subnet 10.1.1.128/25, the address lease duration is five days, domain
name suffix aabbcc.com, DNS server address 10.1.1.2, and gateway address
10.1.1.254, and there is no WINS server address.
■ The domain name and DNS server address on the subnets 10.1.1.0/25 and
10.1.1.128/25 are the same. Therefore, a domain name and DNS server
address can be configured only for the subnet 10.1.1.0/24 and the subnet
10.1.1.128/25 can inherit the configuration of the subnet 10.1.1.0/24.
n In this example, the number of requesting clients connected to Ethernet1/1 should

be less than 122, and that of clients connected to Ethernet1/2 less than 124.
Network diagram
Figure 170 A DHCP network
Client WINS server Client Client
10.1.1 .4/25
Eth1 /1 Eth1/2
10.1.1.126 /25 10.1.1.1/25 10 .1.1.129/25 10.1.1 .254 /25
Gateway A Router A Gateway B

10.1.1 .2/25 DHCP server
Eth1/1
Router B
DNS server Client Client
Client
Specify IP addresses for interfaces (omitted).
Configure the DHCP server
# Enable DHCP

DHCP Server Configuration Examples 587
# Exclude IP addresses from dynamic allocation (addresses of the DNS server, WINS
server, and gateways).
[RouterA] dhcp server forbidden-ip 10.1.1.2

# Configure DHCP address pool 0 (address range, client domain name suffix and
DNS server address).

[RouterA-dhcp-pool-0] domain-name aabbcc.com
[RouterA-dhcp-pool-0] dns-list 10.1.1.2
# Configure DHCP address pool 1 (address range, gateway, WINS server, and lease
duration).

[RouterA-dhcp-1] network 10.1.1.0 mask 255.255.255.128
[RouterA-dhcp-1] gateway-list 10.1.1.126
[RouterA-dhcp-1] expired day 10 hour 12
[RouterA-dhcp-pool-1] nbns-list 10.1.1.4
[RouterA-dhcp-1] quit
# Configure DHCP address pool 2 (address range, gateway and lease duration).

[RouterA-dhcp-pool-2] expired day 5
[RouterA-dhcp-pool-2] gateway-list 10.1.1.254
Self-Defined Option Network requirements

Configuration Example ■ The DHCP client (Router B) obtains the IP address and PXE server addresses
from the DHCP server (Router A).
■ The IP address that Router B obtains belongs to the network segment
10.1.1.0/24.
■ The PXE server addresses that Router B obtains are 1.2.3.4 and 2.2.2.2.
Network diagram
Figure 171 Network diagram for self-defined option configuration (a router as the DHCP
server)
Eth1 /0
10 .1 .1.1/24 Eth1/0
Router A Router B
DHCP server DHCP client
1 Specify IP address for interface Ethernet 1/0 (omitted)
2 Configure the DHCP server

# Enable DHCP.
# Configure DHCP address pool 0.

[RouterA-dhcp-pool-0] option 43 hex 80 0B 00 00 02 01 02 03 04 02 02 02 02
Troubleshooting DHCP Symptom

Server Configuration A client’s IP address obtained from the DHCP server conflicts with another IP
address.
Analysis
A host on the subnet may have the same IP address.
Solution
1 Disconnect the client’s network cable and ping the client’s IP address on another
host with a long timeout time to check whether there is a host using the same IP
address.
2 If a ping response is received, the IP address has been manually configured on the
host. Execute the dhcp server forbidden-ip command on the DHCP server to
exclude the IP address from dynamic allocation.
3 Connect the client’s network cable. Release the IP address and obtain another one
on the client. Take WINDOW XP as an example, run cmd to enter into DOS
window. Type ipconfig/release to relinquish the IP address and then
ipconfig/renew to obtain another IP address.

DHCP RELAY AGENT CONFIGURATION
34
When configuring the DHCP relay agent, go to these sections for information you
are interested in:
■ “Introduction to DHCP Relay Agent” on page 589
■ “DHCP Relay Agent Configuration Task List” on page 591
■ “Configuring the DHCP Relay Agent” on page 591
■ “Displaying and Maintaining the DHCP Relay Agent Configuration” on page
596
■ “DHCP Relay Agent Configuration Example” on page 596
■ “Troubleshooting DHCP Relay Agent Configuration” on page 597
n ■ The DHCP relay agent configuration is supported only on Layer 3 Ethernet

interfaces (or subinterfaces), virtual Ethernet interfaces, VLAN interfaces, and
serial interfaces.
■ DHCP Snooping must be disabled on the DHCP relay agent.
Introduction to DHCP
Relay Agent
Application Since DHCP clients request IP addresses via broadcast messages, the DHCP server
Environment and clients must be on the same subnet. Therefore, a DHCP server must be
available on each subnet. It is not practical.
DHCP relay agent solves the problem. Via a relay agent, DHCP clients
communicate with a DHCP server on another subnet to obtain configuration
parameters. Thus, DHCP clients on different subnets can contact the same DHCP
server for ease of centralized management and cost reduction.
Fundamentals Figure 172 shows a typical application of the DHCP relay agent.

590 CHAPTER 34: DHCP RELAY AGENT CONFIGURATION
Figure 172 DHCP relay agent application
IP network
DHCP relay agent
DHCP client DHCP client DHCP server
No matter whether a relay agent exists or not, the DHCP server and client interact
with each other in a similar way (see “Dynamic IP Address Allocation Procedure”
on page 566). The following describes the forwarding process on the DHCP relay
agent.
Figure 173 DHCP relay agent work process
DHCP client DHCP relay DHCP server
DHCP-DISCOVER DHCP-DISCOVER
(broadcast) (unicast)
DHCP-OFFER
DHCP-OFFER (unicast)
DHCP-REQUEST DHCP-REQUEST
(broadcast) (unicast)
DHCP-ACK
DHCP-ACK (unicast)
As shown in the figure above, the DHCP relay agent works as follows:
1 After receiving a DHCP-DISCOVER or DHCP-REQUEST broadcast message from a

DHCP client, the DHCP relay agent fills the giaddr field of the message with its IP
address and forwards the message to the designated DHCP server in unicast
mode.
2 Based on the giaddr field, the DHCP server returns an IP address and other
configuration parameters to the relay agent, which conveys it to the client via
broadcast.
DHCP Relay Agent Option 82 records the location information of the DHCP client. The administrator
Support for Option 82 can locate the DHCP client to further implement security control and accounting.
For more information, refer to “Relay agent option (Option 82)” on page 570.
If the DHCP relay agent supports Option 82, it will handle a client’s request
according to the contents defined in Option 82, if any. The handling strategies are
described in the table below.

DHCP Relay Agent Configuration Task List 591
If a reply returned by the DHCP server contains Option 82, the DHCP relay agent
will remove the Option 82 before forwarding the reply to the client.
If a client’s
requesting Handling Padding
message has... strategy format The DHCP relay agent will...
Option 82 Drop Random Drop the message.
Keep Random Forward the message without changing
Option 82.
Replace normal Forward the message after replacing the
original Option 82 with the Option 82
padded in normal format.
verbose Forward the message after replacing the
original Option 82 with the Option 82
padded in verbose format.
no Option 82 - normal Forward the message after adding the
Option 82 padded in normal format.
- verbose Forward the message after adding the
Option 82 padded in verbose format.
DHCP Relay Agent Complete the following tasks to configure the DHCP relay agent:
Configuration Task
List Task Remarks
“Enabling DHCP” on page 591 Required
“Enabling the DHCP Relay Agent on Interfaces” on page 591 Required
“Correlating a DHCP Server Group with Relay Agent Interfaces” on Required
page 592
“Configuring the DHCP Relay Agent to Send a DHCP-Release Request” Optional
on page 593
“Configuring the DHCP Relay Agent Security Functions” on page 593 Optional
“Configuring the DHCP Relay Agent to Support Option 82” on page Optional
595
Configuring the DHCP

Relay Agent
Enabling DHCP Enable DHCP before performing other DHCP-related configurations.

Enable DHCP dhcp enable Required
Disabled by default
Enabling the DHCP Relay With this task completed, upon receiving a DHCP request from an enabled
Agent on Interfaces interface, the relay agent will forward the request to a DHCP server for address
allocation.
To enable the DHCP relay agent on interfaces, use the following commands:


Enter interface view Interface interface-type -
interface-number
Enable the DHCP relay agent dhcp select relay Required
on the current interface With DHCP enabled,
interfaces work in the DHCP
server mode.
n ■ If you enabled the DHCP relay agent on an Ethernet subinterface, a client

connected must also use a subinterface to guarantee normal communication
with the relay agent. In this case, if the client is a PC, it cannot obtain an IP
address.
■ If the DHCP client obtains an IP address via the DHCP relay agent, the address
pool of the subnet which the IP address of the DHCP relay agent belongs to
must be configured on the DHCP server. Otherwise, the DHCP client cannot
obtain a correct IP address.
Correlating a DHCP To improve reliability, you can specify several DHCP servers as a group on the
Server Group with Relay DHCP relay agent and correlate a relay agent interface with the server group.
Agent Interfaces When the interface receives requesting messages from clients, the relay agent will
forward them to all the DHCP servers of the group.
To correlate a DHCP server group with relay agent interfaces, use the following
commands:

Specify a DHCP server group dhcp relay server-group Required
number and servers in the group-id ip ip-address
group
interface-number
Correlate the DHCP server dhcp relay server-select Required
group with the current group-id
By default, no interface is
interface
correlated with any DHCP
server group.
n ■ You can specify at most twenty DHCP server groups on the relay agent and at
most eight DHCP server addresses for each DHCP server group.
■ The IP addresses of DHCP servers and those of relay agent’s interfaces cannot
be on the same subnet. Otherwise, the client cannot obtain an IP address.
■ A DHCP server group can correlate with one or multiple DHCP relay agent
interfaces, while a relay agent interface can only correlate with one DHCP
server group. Using the dhcp relay server-select command repeatedly
overwrites the previous configuration. However, if the specified DHCP server
group does not exist, the interface still uses the previous correlation.
■ The group-id in the dhcp relay server-select command was specified by the
dhcp relay server-group command.

Configuring the DHCP Sometimes, you need to release a client’s IP address manually on the DHCP relay
Relay Agent to Send a agent. With this task completed, the DHCP relay agent can actively send a
DHCP-Release Request DHCP-RELEASE request that contains the client’s IP address to be released. Upon
receiving the DHCP-RELEASE request, the DHCP server then releases the IP address
for the client.
To configure the DHCP relay agent to send a DHCP-RELEASE request, use the
following commands:

Configure the DHCP relay agent to send a dhcp relay release ip Required
DHCP-RELEASE request client-ip
Configuring the DHCP Creating static bindings and enable invalid IP address check
Relay Agent Security The DHCP relay agent can dynamically record clients’ IP-to-MAC bindings to
Functions generate a dynamic binding after clients got IP addresses. It also supports static
binding, which means you can manually configure IP-to-MAC bindings on the
DHCP relay agent, so that users can access external network using fixed IP
addresses.
For avoidance of invalid IP address configuration, you can configure the DHCP
relay agent to check whether a requesting client’s IP and MAC addresses match a
binding on it (both dynamic and static bindings). If not, the client cannot access
outside networks via the DHCP relay agent.
To create a static binding and enable invalid IP address check, use the following
commands:

Create a static binding dhcp relay security static Optional
ip-address mac-address
No static binding is created by
[ interface interface-type
default
interface-number ]
interface-number
Enable invalid IP address dhcp relay address-check Required
check { disable | enable }
Disabled by default
n ■ The dhcp relay address-check command can be executed only on Layer 3

Ethernet interfaces (including sub-interfaces) and VLAN interfaces.
■ The dhcp relay address-check enable command is independent of other
commands of the DHCP relay agent. That is, the invalid address check takes
effect when this command is executed, regardless of whether other commands
are used.
■ You are recommended to configure IP address check on the interface enabled
with the DHCP relay agent; otherwise, the valid DHCP clients may not be
capable of accessing networks.

■ When using the dhcp relay security static command to bind an interface to a
static binding entry, make sure that the interface is configured as a DHCP relay
agent; otherwise, address entry conflicts may occur.
Configuring dynamic binding update interval

Via the DHCP relay agent, a DHCP client sends a DHCP-RELEASE unicast message
to the DHCP server to relinquish its IP address. In this case the DHCP relay agent
simply conveys the message to the DHCP server, thus it does not remove the IP
address from its bindings. To solve this, the DHCP relay agent can update dynamic
bindings at a specified interval.
The DHCP relay agent uses the IP address of a client and the MAC address of the
DHCP relay interface to regularly send a DHCP-REQUEST message to the DHCP
server.
■ If the server returns a DHCP-ACK message or does not return any message
within a specified interval, which means the IP address is assignable now, the
DHCP relay agent will update its bindings by aging out the binding entry of the
IP address.
■ If the server returns a DHCP-NAK message, which means the IP address is still
in use, the relay agent will not age it out.
To configure dynamic binding update interval, use the following commands:

Configure binding dhcp relay security tracker Optional
update interval { interval | auto }
auto by default (auto interval is
calculated by the relay agent
according to the number of bindings)
Configuring the DHCP relay agent to support authorized ARP

A DHCP relay agent can work in cooperation with authorized ARP to block illegal
clients, to avoid learning incorrect ARP entries and to guard against attacks such
as MAC address spoofing. Only the clients whose IP-to-MAC binding are recorded
on the DHCP relay agent are considered legal clients.
When authorized ARP is enabled on the DHCP relay agent, the ARP automatic
learning function is disabled. ARP entries can only be added by the authentication
module, the DHCP relay agent, which notifies authorized ARP to
add/delete/change authorized ARP entries when adding/deleting/changing
dynamic IP-to-MAC bindings. Thus, only the clients that have passed the
authentication of the DHCP relay agent can access the network normally, while
other clients are considered illegal clients and unable to access the network.
Follow these steps to configure the DHCP relay agent to support authorized ARP:

interface-number


Configure the DHCP relay dhcp update arp Required
agent to support authorized
Not supported by default.
ARP
n ■
■
Authorized ARP can only be configured on Layer 3 interfaces.
Disabling the DHCP relay agent to support authorized ARP will not delete
dynamic bindings, but will notify authorized ARP to delete the corresponding
authorized ARP entries.
■ Since the DHCP relay agent does not notify the authorized ARP module of the
static bindings, you need to configure the corresponding static ARP entries for
authorized ARP.
■ For more information about authorized ARP, refer to “Configuring Authorized
ARP” on page 555.
Enabling unauthorized DHCP servers detection

There are invalid DHCP servers on networks, which reply DHCP clients with wrong
IP addresses. These invalid DHCP servers are unauthorized DHCP servers.
With this feature enabled, upon receiving a DHCP message with the siaddr field (IP
address of the server assigning IP addresses to clients) not being 0 from a client,
the DHCP relay agent will record the value of the siaddr field and the information
on the interface receiving the DHCP message. The administrator can use this
information to check out any DHCP unauthorized servers.
To enable unauthorized DHCP server detection, use the following commands:

Enable unauthorized DHCP dhcp relay server-detect Required
server detection
Disabled by default
n With the unauthorized DHCP server detection enabled, the device puts a record
once for each DHCP server. The administrator needs to find unauthorized DHCP
servers from the log information. After the recorded information of a DHCP server
is cleared, a new record will be put for the DHCP server.
Configuring the DHCP Prerequisites

Relay Agent to Support You need to complete the following tasks before configuring the DHCP relay
Option 82 agent to support Option 82.
■ Enabling DHCP
■ Enabling the DHCP relay agent on the specified interface
■ Correlating a DHCP server group with relay agent interfaces
Configuring the DHCP relay agent to support Option 82

Use the following commands for this configuration:


interface-number
Enable the relay agent to dhcp relay information Required
support Option 82 enable
Configure the handling dhcp relay information Optional
strategy for requesting strategy { drop | keep |
replace by default.
messages containing Option replace }
82
Configure the padding format dhcp relay information Optional
for Option 82 format { normal | verbose
normal by default.
[ node-identifier { mac |
sysname | user-defined
node-identifier } ] }
n ■ To support Option 82, it is required to perform related configuration on both

the DHCP server and relay agent. Refer to “Configuring the Handling Mode for
Option 82” on page 584 for DHCP server configuration of this kind.
■ If the handling strategy of the DHCP relay agent is configured as replace, you
need to configure a padding format for Option 82. If the handling strategy is
keep or drop, you need not configure any padding format.
■ If sub-option 1 (node identifier) of Option 82 is padded with the device name
(sysname) of a node, the device name must contain no spaces. Otherwise, the
DHCP relay agent will drop the message.
Displaying and
Relay Agent Display information about DHCP display dhcp relay { all | Available in any view
Configuration server groups correlated to a interface interface-type
specified or all interfaces interface-number }
Display information about bindings display dhcp relay security Available in any view
of DHCP relay agents [ ip-address | dynamic | static ]
Display statistics information about display dhcp relay security Available in any view
bindings of DHCP relay agents statistics
Display information about the display dhcp relay security Available in any view
refreshing interval for entries of tracker
dynamic IP-to-MAC bindings
Display information about the display dhcp relay Available in any view
configuration of a specified or all server-group { group-id | all }
DHCP server groups
Display packet statistics on relay display dhcp relay statistics Available in user view
agent [ server-group { group-id |
all } ]
Clear packet statistics from relay reset dhcp relay statistics Available in user view
agent [ server-group group-id ]
DHCP Relay Agent Network requirements

Configuration Ethernet1/1 of the DHCP relay agent (Router A) connects to the subnet where
Example DHCP clients reside. The IP address of Ethernet1/1 is 10.10.1.1/24, and the IP

Troubleshooting DHCP Relay Agent Configuration 597
address of Ethernet1/2 is 10.1.1.2/24 that communicates with the DHCP server

10.1.1.1/24. As shown in the figure below, Router A forwards messages between
DHCP clients and the DHCP server.
Network diagram
Figure 174 Network diagram for DHCP relay agent (on a router)
Eth1 /1 Eth1/2
10 .10 .1 .1/24 10.1.1.2/24
Eth1 /0
10.1.1 .1/24
Router A Router B
DHCP relay agent DHCP server
# Enable DHCP.
# Enable the DHCP relay agent on Ethernet1/1.

[RouterA-Ethernet1/1] dhcp select relay
# Configure DHCP server group 1 with the DHCP server 10.1.1.1, and correlate
DHCP server group 1 with Ethernet1/1.
[RouterA] dhcp relay server-group 1 ip 10.1.1.1
[RouterA-Ethernet1/1] dhcp relay server-select 1
n ■ Performing configuration on the DHCP server is also required to guarantee the

client-server communication via the DHCP relay agent. Refer to “DHCP Server
Configuration Examples” on page 585 for DHCP server configuration
information.
■ If the DHCP relay agent and server are on different subnets, routes in between
must be reachable.
Troubleshooting DHCP Symptom

Relay Agent DHCP clients cannot obtain any configuration parameters via the DHCP relay
Configuration agent.

Analysis
Some problems may occur with the DHCP relay agent or server configuration.
Enable debugging and execute the display command on the DHCP relay agent to
view the debugging information and interface state information for locating the
problem.
Solution
Check that:
■ The DHCP is enabled on the DHCP server and relay agent.
■ The address pool on the same subnet where DHCP clients reside is available on
the DHCP server.
■ The routes between the DHCP server and DHCP relay agent are reachable.
■ The relay agent interface connected to DHCP clients is correlated with correct
DHCP server group and IP addresses for the group members are correct.

DHCP CLIENT CONFIGURATION
35
When configuring the DHCP client, go to these sections for information you are
interested in:
■ “Introduction to DHCP Client” on page 599
■ “Enabling the DHCP Client on an Interface” on page 599
■ “Displaying and Maintaining the DHCP Client” on page 600
■ “DHCP Client Configuration Example” on page 600
n ■ The DHCP client configuration is supported only on Layer 3 Ethernet interfaces

(or subinterfaces), and VLAN interfaces.
■ When multiple VLAN interfaces with the same MAC address use DHCP for IP
address acquisition via a relay agent, the DHCP server cannot be a Windows
2000 Server or Windows 2003 Server.
■ You are not recommended to enable both the DHCP client and the DHCP
Snooping on the same device. Otherwise, DHCP Snooping entries may fail to
be generated, or the DHCP client may fail to obtain an IP address.
Introduction to DHCP With the DHCP client enabled on an interface, the interface will use DHCP to
Client obtain configuration parameters such as an IP address from the DHCP server.
Enabling the DHCP Follow these steps to enable the DHCP client on an interface:
Client on an Interface
interface-number
Enable the DHCP client on the ip address dhcp-alloc Required
interface [ client-identifier mac
Disabled by default
interface-type
interface-number ]
n ■ An interface can be configured to acquire an IP address in multiple ways, but

these ways are exclusive. The latest configuration will overwrite the previous
configuration.
■ After the DHCP client is enabled on an interface, no secondary IP address is
configurable for the interface.
■ If the IP address assigned by the DHCP server shares a network segment with
the IP addresses of other interfaces on the device, the DHCP client enabled
interface will not request any IP address of the DHCP server unless the

600 CHAPTER 35: DHCP CLIENT CONFIGURATION
conflicted IP address is manually deleted and the interface is made UP again by

first executing the shutdown command and then the undo shutdown
command or the DHCP client is enabled on the interface by executing the
undo ip address dhcp-alloc and ip address dhcp-alloc commands in
sequence.
Displaying and
Client Display specified display dhcp client [ verbose ] Available in any view
configuration information [ interface interface-type
interface-number ]
DHCP Client Network requirements

Configuration On a LAN, Router B contacts the DHCP server via Ethernet1/1 to obtain an IP
Example address.
Network diagram
See Figure 170.
The following is the configuration on Router B shown in Figure 170.
# Enable the DHCP client on Ethernet1/1.
[RouterB-Ethernet1/1] ip address dhcp-alloc
n To implement the DHCP client-server model, you need to perform related

configuration on the DHCP server. For details, refer to “DHCP Server Configuration
Examples” on page 585.

DHCP SNOOPING CONFIGURATION
36
When configuring DHCP snooping, go to these sections for information you are
interested in:
■ “DHCP Snooping Overview” on page 601
■ “Configuring DHCP Snooping Basic Functions” on page 602
■ “Displaying and Maintaining DHCP Snooping” on page 602
■ “DHCP Snooping Configuration Example” on page 602
n ■
■
The DHCP snooping is supported only on Layer 2 Ethernet interfaces.
DHCP Snooping supports no link aggregation. If a Layer 2 Ethernet interface is
added into an aggregation group, DHCP Snooping configuration on it will not
take effect. When the interface is removed from the group, DHCP Snooping
can take effect.
■ The DHCP snooping enabled device does not work if it is between the DHCP
relay agent and DHCP server, and it can work when it is between the DHCP
client and relay agent or between the DHCP client and server.
■ The DHCP Snooping enabled device cannot be a DHCP server or DHCP relay
agent.
■ You are not recommended to enable the DHCP client, BOOTP client, and DHCP
be generated, or the BOOTP client/DHCP client may fail to obtain an IP address.
c CAUTION: Only H3C MSR series routers equipped with 16-port or 24-port layer 2
interface cards support the DHCP Snooping function.
DHCP Snooping
Overview
Function of DHCP As a DHCP security feature, DHCP snooping can implement the following:
Snooping
Recording IP-to-MAC mappings of DHCP clients
For security sake, a network administrator needs to record the mapping between a
client’s IP address obtained from the DHCP server and the client’s MAC address.
DHCP snooping can meet the need.
DHCP snooping records clients’ MAC and IP addresses by reading their

DHCP-REQUEST and DHCP-ACK messages from trusted ports. The network
administrator can check out which IP addresses are assigned to the DHCP clients
with the display dhcp-snooping command.

602 CHAPTER 36: DHCP SNOOPING CONFIGURATION
Ensuring DHCP clients to obtain IP addresses from valid DHCP servers

If there is an unauthorized DHCP server on a network, the DHCP clients may
obtain invalid IP addresses. With DHCP snooping, the ports of a device can be
configured as trusted or untrusted, ensuring the clients to obtain IP addresses from
authorized DHCP servers.
■ Trusted: A trusted port is connected to a valid DHCP server directly or indirectly.
It forwards DHCP messages normally, guaranteeing that DHCP clients can
obtain valid IP addresses.
■ Untrusted: An untrusted port is connected to an invalid DHCP server. The
DHCP-ACK or DHCP-OFFER packets received from the port are discarded,
preventing DHCP clients from receiving invalid IP addresses.
Configuring DHCP Follow these steps to configure DHCP snooping basic functions:
Snooping Basic
Functions To do... Use the command... Remarks
Enable DHCP snooping dhcp-snooping Required
interface-number
Specify the port as trusted dhcp-snooping trust Required
Untrusted by default.
n You must specify the ports connected to the valid DHCP servers as trusted to
ensure that DHCP clients can obtain valid IP addresses. The trusted port and the
port connected to the DHCP client must be in the same VLAN.
Displaying and
Maintaining DHCP To do... Use the command... Remarks
Snooping Display DHCP snooping address display dhcp-snooping Available in any view
binding information
Display information about trusted display dhcp-snooping trust
ports
Clear DHCP snooping address reset dhcp-snooping { all | ip Available in user view
binding information ip-address }
DHCP Snooping Network requirements

Configuration ■ Switch B is connected to a DHCP server through Ethernet1/1, and to two DHCP
Example clients through Ethernet1/2 and Ethernet1/3.
■ Ethernet1/1 forwards DHCP server responses while the other two do not.
■ Switch B records clients’ IP-to-MAC address bindings in DHCP-REQUEST
messages and DHCP-ACK messages received from trusted ports.

DHCP Snooping Configuration Example 603
Network diagram
Figure 175 Network diagram for DHCP snooping configuration
Switch A
DHCP server
Eth 1/ 1 Switch B
DHCP snooping
Eth 1/ 2 Eth1/ 3
# Enable DHCP snooping.
<SwitchB> system-view
[SwitchB] dhcp-snooping
# Specify Ethernet1/1 as trusted.
[SwitchB] interface ethernet 1/1

[SwitchB-Ethernet1/1] dhcp-snooping trust

604 CHAPTER 36: DHCP SNOOPING CONFIGURATION

BOOTP CLIENT CONFIGURATION
37
While configuring a bootstrap protocol (BOOTP) client, go to these sections for
■ “Introduction to BOOTP Client” on page 605
■ “Configuring an Interface to Dynamically Obtain an IP Address through
BOOTP” on page 606
■ “Displaying and Maintaining BOOTP Client Configuration” on page 606
■ “BOOTP Client Configuration Example” on page 606
n ■ BOOTP client configuration only applies to Layer 3 Ethernet interfaces

(including sub-interfaces) and VLAN interfaces.
■ If several VLAN interfaces sharing the same MAC address obtain IP addresses
through a BOOTP relay agent, the BOOTP server cannot be a Windows 2000
Server or Windows 2003 Server.
■ You are not recommended to enable both the DHCP client and the DHCP
be generated, or the BOOTP client may fail to obtain an IP address.
Introduction to BOOTP
Client
BOOTP Application After you specify an interface of a device as a BOOTP client, the interface can use
BOOTP to get information (such as IP address) from the BOOTP server, which
simplifies your configuration.
Before using BOOTP, an administrator needs to configure a BOOTP parameter file

for each BOOTP client on the BOOTP server. The parameter file contains
information such as MAC address and IP address of a BOOTP client. When a
BOOTP client originates a request to the BOOTP server, the BOOTP server will
search for the BOOTP parameter file and return the corresponding configuration
information.
Because you need to configure a parameter file for each client on the BOOTP
server, BOOTP usually runs under a relatively stable environment. If the network
changes frequently, Dynamic Host Configuration Protocol (DHCP) is applicable.
n Because a DHCP server can interact with a BOOTP client, you can use the DHCP
server to configure an IP address for the BOOTP client, without any BOOTP server.

606 CHAPTER 37: BOOTP CLIENT CONFIGURATION
Obtaining an IP Address
Dynamically
n A DHCP server can take the place of the BOOTP server in the following dynamic IP
address acquisition.
A BOOTP client dynamically obtains an IP address from a BOOTP server in the

following way:
1 The BOOTP client broadcasts a BOOTP request, which contains its own MAC
address.
2 The BOOTP server receives the request and searches the configuration file for the
corresponding IP address according to the MAC address of the BOOTP client. The
BOOTP server then returns a BOOTP response to the BOOTP client.
3 The BOOTP client obtains the IP address from the received the response.
Protocols and Standards Some protocols and standards related to BOOTP include:
1 RFC 951: Bootstrap Protocol (BOOTP)
2 RFC 2132: DHCP Options and BOOTP Vendor Extensions
3 RFC 1542: Clarifications and Extensions for the Bootstrap Protocol
Configuring an Follow these steps to configure an interface to dynamically obtain an IP address:

Interface to
Dynamically Obtain an To do... Use the command... Remarks
IP Address through Enter system view system-view -
BOOTP Enter interface view interface interface-type -
interface-number
Configure an interface to ip address bootp-alloc Required
dynamically obtain IP address
By default, an interface does
through BOOTP
not use BOOTP to obtain an IP
address.
Displaying and
Maintaining BOOTP To do... Use the command... Remarks
Client Configuration Display related information on display bootp client Available in any view
a BOOTP client [ interface interface-type
interface-number ]
BOOTP Client Network requirements

Configuration The interface Ethernet1/1 of Router B acting as a client is connected to the LAN to
Example obtain an IP address from the DHCP server by using BOOTP.
Network diagram
See Figure 170.
The following describes only the configuration on Router B serving as a client.

BOOTP Client Configuration Example 607
# Configure Ethernet1/1 to dynamically obtain an IP address by using BOOTP.
[RouterB-Ethernet1/1] ip address bootp-alloc
n To make the BOOTP client to obtain an IP address from the DHCP server, you need
to perform additional configurations on the DHCP server. For details, refer to
“DHCP Server Configuration Examples” on page 585.

608 CHAPTER 37: BOOTP CLIENT CONFIGURATION

DNS CONFIGURATION
38
When configuring DNS, go to these sections for information you are interested in:
■ “DNS Overview” on page 609
■ “Configuring the DNS Client” on page 611
■ “Configuring the DNS Proxy” on page 612
■ “Displaying and Maintaining DNS” on page 612
■ “DNS Configuration Examples” on page 613
■ “Troubleshooting DNS Configuration” on page 618
n This document only covers IPv4 DNS configurations. For IPv6 DNS configuration
information, refer to “IPv6 Basics Configuration” on page 655.
DNS Overview Domain name system (DNS) is a distributed database used by TCP/IP applications
to translate domain names into corresponding IP addresses. With DNS, you can
use easy-to-remember domain names in some applications and let the DNS server
translate them into correct IP addresses.
There are two types of DNS services, “Static Domain Name Resolution” on page
609 and “Dynamic Domain Name Resolution” on page 609. Each time the DNS
server receives a name query it checks its static DNS database before looking up
the dynamic DNS database. Reduction of the searching time in the dynamic DNS
database would increase efficiency. Some frequently used addresses can be put in
the static DNS database.
Static Domain Name The static domain name resolution means setting up mappings between domain
Resolution names and IP addresses. IP addresses of the corresponding domain names can be
found in the static DNS database when you use applications such as telnet.
Dynamic Domain Name Resolving procedure

Resolution Dynamic domain name resolution is implemented by querying the DNS server. The
resolution procedure is as follows:
1 A user program sends a name query to the resolver in the DNS client.
2 The DNS resolver looks up the local domain name cache for a match. If a match is
found, it sends the corresponding IP address back. If not, it sends a query to the
DNS server.
3 The DNS server looks up the corresponding IP address of the domain name in its
DNS database. If no match is found, it sends a query to a higher DNS server. This
process continues until a result, whether success or failure, is returned.

610 CHAPTER 38: DNS CONFIGURATION
4 The DNS client returns the resolution result to the application after receiving a
response from the DNS server.
Figure 176 Dynamic domain name resolution
Request Request
User
program Resolver
Response Response
DNS server
Save Read
Cache
DNS client
Figure 176 shows the relationship between user program, DNS client, and DNS
server.
The resolver and cache comprise the DNS client. The user program and DNS client
can run on the same machine or different machines, while the DNS server and the
DNS client usually must run on different machines.
Dynamic domain name resolution allows the DNS client to store latest mappings
between domain names and IP addresses in the dynamic domain name cache.
There is no need to send a request to the DNS server for a repeated query next
time. The aged mappings are removed from the cache after some time, and latest
entries are required from the DNS server. The DNS server decides how long a
mapping is valid, and the DNS client gets the information from DNS messages.
DNS suffixes
The DNS client normally holds a list of suffixes which can be defined by users. It is
used when the name to be resolved is incomplete. The resolver can supply the
missing part. For example, a user can configure com as the suffix for aabbcc.com.
The user only needs to type aabbcc to get the IP address of aabbcc.com. The
resolver can add the suffix and delimiter before passing the name to the DNS
server.
■ If there is no dot in the domain name (for example, aabbcc), the resolver will
consider this as a host name and add a DNS suffix before query. The original
domain name (for example, aabbcc) is used if the query fails.
■ If there is a dot in the domain name (for example, www.aabbcc), the resolver
will directly use this domain name for query. If the query fails, the resolver adds
a DNS suffix for another query.
■ If the dot is at the end of the domain name (for example, aabbcc.com), the
resolver will consider it as a fully qualified domain name (FQDN) and return the
query result, success or a failure. Hence, the dot (.) at the end of the domain
name is called the terminating symbol.
Currently, the device supports static and dynamic DNS services.

Configuring the DNS Client 611
n If an alias is configured for a domain name on the DNS server, the device can
resolve the alias into the IP address of the host.
DNS Proxy Introduction to DNS proxy

A DNS proxy forwards DNS requests and replies between DNS clients and a DNS
server.
As shown in Figure 177, the DNS client sends DNS requests to the DNS proxy,
which forwards the requests to the designated DNS server, and conveys the replies
from the DNS server to the client.
The DNS proxy simplifies network management. When the DNS server address is
changed, you only need to change the configuration on the DNS proxy instead of
on each DNS client.
Figure 177 DNS proxy networking application
DNS client
DNS proxy
IP network
DNS server
DNS client DNS client
Operation of a DNS proxy

1 A DNS client considers the DNS proxy as the DNS server, and sends a DNS request
to the DNS proxy, that is, the destination address of the request is the IP address of
the DNS proxy.
2 The DNS proxy searches the local static domain name resolution table after
receiving the request. If the requested information exists in the table, the DNS
proxy returns a DNS reply to the client.
3 If the requested information does not exist in the static domain name resolution
table, the DNS proxy sends the request to the designated DNS server for domain
name resolution.
4 After receiving a reply from the DNS server, the DNS proxy forwards the reply to
the DNS client.
Configuring the DNS

Client
Configuring Static Follow these steps to configure static domain name resolution:
Domain Name
Resolution To do... Use the command... Remarks


Configure a mapping ip host hostname Required
between host name and IP ip-address
No mapping between host name
address in the static DNS
and IP address is configured in the
database
static DNS database by default.
n The IP address you last assign to the host name will overwrite the previous one if
there is any.
You may create up to 50 static mappings between domain names and IP

addresses.
Configuring Dynamic Follow these steps to configure dynamic domain name resolution:
Domain Name
Resolution To do... Use the command... Remarks
Enable dynamic domain name dns resolve Required
resolution
Disabled by default
Configure an IP address for dns server ip-address Required
the DNS server
No IP address is configured for
the DNS server by default.
Configure DNS suffixes dns domain domain-name Optional
No DNS suffix is configured by
default
n You may configure up to six DNS servers and ten DNS suffixes.
Configuring the DNS Follow these steps to configure the DNS proxy:
Proxy
Enable DNS proxy dns proxy enable Required
Displaying and
Maintaining DNS To do... Use the command... Remarks
Display the static DNS display ip host Available in any
database view
Display the DNS server display dns server [ dynamic ]
information
Display the DNS suffixes display dns domain [ dynamic ]
Display the information in the display dns dynamic-host
dynamic domain name cache
Display the DNS proxy table display dns proxy table
Clear the information in the reset dns dynamic-host Available in user
dynamic domain name cache view

DNS Configuration
Examples
Static Domain Name Network requirements

Resolution Device uses the static domain name resolution to access Host with IP address
Configuration Example 10.1.1.2 through domain name host.com.
Network diagram
Figure 178 Network diagram for static domain name resolution
10 .1 .1.2/24
10.1 .1.1/24
host.com
Device Host
# Configure a mapping between host name host.com and IP address 10.1.1.2.
[Sysname] ip host host.com 10.1.1.2
# Execute the ping host.com command to verify that the device can use the static
domain name resolution to get the IP address 10.1.1.2 corresponding to
host.com.
[Sysname] ping host.com

PING host.com (10.1.1.2):
56 data bytes, press CTRL_C to break
--- host.com ping statistics ---

0.00% packet loss
Dynamic Domain Name Network requirements

Resolution ■ The IP address of the DNS server is 2.1.1.2/16 and the DNS suffix is com.
Configuration Example
■ Device serving as a DNS client uses the dynamic domain name resolution and
DNS suffix to access the host with the domain name being host.com and the IP
address 3.1.1.1/16.

Network diagram
Figure 179 Network diagram for dynamic domain name resolution
IP network
2.1.1.2 /16
2.1.1.1/16 1.1.1.1 /16 3.1.1 .1/16
host.com
Device
DNS server Host
DNS client
n ■ Before performing the following configuration, make sure that there is a route
between the device and the host, and configurations are done on both the
device and the host. For the IP addresses of the interfaces, see Figure 179.
■ This configuration may vary with different DNS servers. The following
configuration is performed on a Windows 2000 server.
1 Configure the DNS server
# Enter DNS server configuration page.
Select Start > Programs > Administrative Tools > DNS.
# Create zone com.
In Figure 180, right click Forward Lookup Zones, select New zone, and then
follow the instructions to create a new zone com.

Figure 180 Create a zone
# Create a mapping between host name and IP address.
Figure 181 Add a host
In Figure 181, right click zone com, and then select New Host to bring up a
dialog box as shown in Figure 182. Enter host name host and IP address 3.1.1.1.

Figure 182 Add a mapping between domain name and IP address
2 Configure the DNS client
# Enable dynamic domain name resolution.
[Sysname] dns resolve
# Specify the DNS server 2.1.1.2.
[Sysname] dns server 2.1.1.2
# Configure com as the name suffix.
[Sysname] dns domain com

3 Configuration verification
# Execute the ping host command on the device to verify that the
communication between the device and the host is normal and that the
corresponding destination IP address is 3.1.1.1.
[Sysname] ping host

Trying DNS resolve, press CTRL_C to break
Trying DNS server (2.1.1.2)
0.00% packet loss


100.00% packet loss
DNS Proxy Network requirements

Configuration Example ■ Specify Device A as the DNS server of Device B (the DNS client).
■ Device A acts as a DNS proxy. The IP address of the real DNS server is 4.1.1.1.
■ Device B implements domain name resolution through Device A.
Network diagram
Figure 183 Network diagram for DNS proxy
Device B
DNS client 4.1.1 .1/24
DNS server
Device A
2.1.1.1 /24
DNS proxy
2.1.1 .2/24 1.1 .1.1/24
IP network
3.1.1 .1/24
host.com
Host
n Before performing the following configuration, assume that Device A, the DNS
server, and the host are reachable to each other and the IP addresses of the
interfaces are configured as shown in Figure 183.
1 Configure the DNS server
This configuration may vary with different DNS servers. When a Windows 2000
server acts as the DNS server, refer to “Dynamic Domain Name Resolution
Configuration Example” on page 613 for related configuration information.
2 Configure the DNS proxy
[DeviceA] dns server 4.1.1.1
# Enable DNS proxy.
[DeviceA] dns proxy enable

3 Configure the DNS client

# Enable the domain name resolution function.
[DeviceB] dns resolve
[DeviceB] dns server 2.1.1.2

4 Configuration verification
# Execute the ping host.com command on Device B to verify that the host can be
pinged after the host’s IP address 3.1.1.1 is resolved.
[DeviceB] ping host.com

Trying DNS resolve, press CTRL_C to break
Trying DNS server (2.1.1.2)

0.00% packet loss
Troubleshooting DNS Symptom

Configuration After enabling the dynamic domain name resolution, the user cannot get the
correct IP address.
Solution
■ Use the display dns dynamic-host command to check that the specified
domain name is in the cache.
■ If there is no defined domain name, check that dynamic domain name
resolution is enabled and the DNS client can communicate with the DNS server.
■ If the specified domain name is in the cache, but the IP address is incorrect,
check that the DNS client has the correct IP address of the DNS server.
■ Check the mapping between the domain name and IP address is correct on the
DNS server.

IP ACCOUNTING CONFIGURATION
39
When configuring IP accounting, go to these sections for information you are
interested in:
■ “Introduction to IP Accounting” on page 619
■ “Configuring IP Accounting” on page 619
■ “IP Accounting Configuration Example” on page 620
■ “Displaying and Maintaining IP Accounting Configuration” on page 622
Introduction to IP The IP accounting feature implements the statistics of incoming and outgoing IP
Accounting packets on the router. These IP packets include those sent and forwarded by the
router normally as well as those denied by the firewall.
The statistics of the IP accounting includes information such as source and

destination IP addresses, protocol number, packet sum, and byte sum. The
statistics results of IP packets passing the firewall and those matching the IP
accounting rule are respectively stored and displayed.
Each IP accounting rule consists of an IP address and its mask, namely, a subnet
address, which is the result of ANDing the IP address with its mask. IP packets are
sorted as follows:
■ If a firewall is configured on an interface and incoming and outgoing IP packets

are denied by the firewall, these IP packets are counted in the firewall-denied
table.
■ If the source or destination IP address of the IP packets passing the interface or
the firewall, if configured, matches a network address in the IP accounting rule,
the packets are counted in the interior table. Otherwise, the packets are
counted in the exterior table.
■ If the statistics information of an entry in an accounting table is not updated
within its aging time, the router considers that the entry time out and deletes
them.
Configuring IP
Accounting
Configuration Assign an IP address and mask to the interface on which the IP accounting feature
Prerequisites needs to be enabled. If necessary, configure a firewall on the interface.
Configuration Procedure Follow these steps to configure IP accounting:

620 CHAPTER 39: IP ACCOUNTING CONFIGURATION

Enable the IP accounting feature ip count enable Required
Configure the aging time for an IP ip count timeout Optional
accounting entry minutes
720 minutes (namely, 12
hours) by default.
Set the maximum number of IP ip count Optional
accounting entries in the interior table interior-threshold
512 by default.
number
Set the maximum number of entries in ip count Optional
the exterior table exterior-threshold
0 by default.
number
Configure IP accounting rules ip count rule { mask | Required.
mask-length }
Up to 32 rules can be
configured.
If no rule is configured,
the current packets are
not concerned and are all
counted in the exterior
table.
Enter interface view interface interface-type --
interface-number
Configure the Count incoming IP ip count Required
type of packet packets on the inbound-packets
Select at least one type of
accounting current interface
packet accounting.
Count outgoing IP ip count Otherwise, no IP packets
packets on the outbound-packets are to be counted on the
current interface current interface.
Count firewall-denied ip count
incoming packets on firewall-denied
the current interface inbound-packets
Count firewall-denied ip count
outgoing packets on firewall-denied
the current interface outbound-packets
IP Accounting
Configuration
Example
Network Requirements As shown in Figure 184, the router is connected to Host A and Host B through
Ethernet interfaces.
Enable IP accounting on Ethernet1/0 of the router to count the IP packets from

Host A to Host B, with the aging time for IP accounting entries being 24 hours.

IP Accounting Configuration Example 621
Network Diagram Figure 184 Network diagram for IP accounting configuration
Eth 1/ 0 Eth1/1
1.1 .1. 2/ 24 2.2 .2. 1/ 24
Host A Router Host B

1.1. 1. 1/24 2. 2. 2. 2/24
Configuration Procedure ■ Configure the router.
# Enable IP accounting.
[Router] ip count enable
# Configure an IP accounting rule.
[Router] ip count rule 1.1.1.1 24
# Set the aging time to 1440 minutes (24 hours).
[Router] ip count timeout 1440
# Set the maximum number of accounting entries in the interior table to 100.
[Router] ip count interior-threshold 100
# Set the maximum number of accounting entries in the exterior table to 20.
[Router] ip count exterior-threshold 20
# Assign Ethernet1/0 an IP address and count both incoming and outgoing IP

packets on it.

[Router-Ethernet1/0] ip address 1.1.1.2 24
[Router-Ethernet1/0] ip count inbound-packets
[Router-Ethernet1/0] ip count outbound-packets
# Assign Ethernet1/1 an IP address.

[Router-Ethernet1/1] ip address 2.2.2.1 24
■ Configure Host A and Host B.
# Configure static routes from Host A to Host B and from Host B to Host A. Ping
Host B from Host A.
Omitted.
■ Display the IP accounting information.
# Display IP accounting information on the router.

622 CHAPTER 39: IP ACCOUNTING CONFIGURATION
[Router] display ip count inbound-packets interior

1 Inbound streams information in interior list:
SrcIP DstIP Protocol Pkts Bytes
1.1.1.1 2.2.2.2 ICMP 4 240
[Router] display ip count outbound-packets interior
1 Outbound streams information in interior list:
SrcIP DstIP Protocol Pkts Bytes
2.2.2.2 1.1.1.1 ICMP 4 240
n The two hosts can be replaced by other types of network devices such as routers.
Displaying and
Maintaining IP To do... Use the command... Remarks
Accounting Display the IP display ip count rule Available in any view
Configuration accounting rules
Display IP accounting display ip count { inbound-packets | Available in any view
information outbound-packets } { exterior |
firewall-denied | interior }
Clear IP accounting reset ip count { all | exterior | firewall | Available in user view
information interior }
n After you configure a new IP accounting rule, it is possible that some originally
rule-incompliant packets from a subnet comply with the new rule. Information
about these packets is then saved in the interior table. The exterior table, however,
may still contain information about these packets. Therefore, in some cases, the
interior and exterior tables contain statistics information about the IP packets from
the same subnet. The statistics information in the exterior table will be removed
when the aging time expires.

IP ADDRESSING CONFIGURATION
40
When assigning IP addresses to interfaces on your device, go to these sections for
■ “IP Addressing Overview” on page 623
■ “Configuring IP Addresses” on page 625
■ “Configuring IP Unnumbered” on page 628
■ “Displaying and Maintaining IP Addressing” on page 630
IP Addressing
Overview
IP Address Classes IP addressing uses a 32-bit address to identify each host on a network. An
example is 01010000100000001000000010000000 in binary. To make IP
addresses in 32-bit form easier to read, they are written in dotted decimal
notation, each being four octets in length, for example, 10.1.1.1 for the address
just mentioned.
Each IP address breaks down into two parts:
■ Net-id: First several bits of the IP address defining a network, also known as
class bits.
■ Host-id: Identifies a host on a network.
For administration sake, IP addresses are divided into five classes. Which class an IP
address belongs to depends on the first one to four bits of the net-id, as shown in
the following figure (the blue part identifies the address class).
Figure 185 IP address classes
0 7 15 23 31
Class A 0 Net-id Host-id
Class B 1 0 Net-id Host-id
Class C 1 1 0 Net-id Host-id
Class D 1 1 1 0 Multicast address
Class E 1 1 1 1 Reserved
Table 34 describes the address ranges of these five classes. Currently, the first
three classes of IP addresses are used in quantities.

624 CHAPTER 40: IP ADDRESSING CONFIGURATION
Table 34 IP address classes and ranges
Class Address range Description

A 0.0.0.0 to 127.255.255.255 The IP address 0.0.0.0 is used by a host
at bootstrap for temporary
communication. This address is never a
valid destination address.
Addresses starting with 127 are reserved
for loopback test. Packets destined to
these addresses are processed locally as
input packets rather than sent to the
link.
B 128.0.0.0 to 191.255.255.255 --
C 192.0.0.0 to 223.255.255.255 --
D 224.0.0.0 to 239.255.255.255 Multicast address.
E 240.0.0.0 to 255.255.255.255 Reserved for future use except for the
broadcast address 255.255.255.255.
Special Case IP The following IP addresses are for special use, and they cannot be used as host IP
Addresses addresses:
■ IP address with an all-zero net ID: Identifies a host on the local network. For
example, IP address 0.0.0.16 indicates the host with a host ID of 16 on the
local network.
■ IP address with an all-zero host ID: Identifies a network.
■ IP address with an all-one host ID: Identifies a directed broadcast address. For
example, a packet with the destination address of 192.168.1.255 will be
broadcasted to all the hosts on the network 192.168.1.0.
Subnetting and Masking In 1980s, subnetting was developed to address the risk of IP address exhaustion
resulting from fast expansion of the Internet. The idea is to break a network down
into smaller networks called subnets by using some bits of the host-id to create a
subnet-id. To identify the boundary between the host-id and the combination of
net-id and subnet-id, masking is used. (When subnetting is not adopted, a mask
identifies the boundary between the host-id and the host-id.)
Each subnet mask comprises 32 bits related to the corresponding bits in an IP

address. In a subnet mask, the part containing consecutive ones identifies the
combination of net-id and subnet-id whereas the part containing consecutive
zeros identifies the host-id.
Figure 186 shows how a Class B network is subnetted.
Figure 186 Subnet a Class B network
0 7 15 23 31
Class B address 1 0 Net-id Host-id
Mask 11111111111111110000000000000000
Subnetting Net-id Subnet-id Host-id
Mask 11111111111111111111111110000000

While allowing you to create multiple logical networks within a single Class A, B,
or C network, subnetting is transparent to the rest of the Internet. All these
networks still appear as one. As subnetting adds an additional level, subnet-id, to
the two-level hierarchy with IP addressing, IP routing now involves three steps:
delivery to the site, delivery to the subnet, and delivery to the host.
In the absence of subnetting, some special addresses such as the addresses with
the net-id of all zeros and the addresses with the host-id of all ones, are not
assignable to hosts. The same is true of subnetting. When designing your
network, you should note that subnetting is somewhat a tradeoff between
subnets and accommodated hosts. For example, a Class B network can
accommodate 65,534 (216 - 2. Of the two deducted Class B addresses, one with
an all-ones host-id is the broadcast address and the other with an all-zeros host-id
is the network address) hosts before being subnetted. After you break it down
into 512 (29) subnets by using the first 9 bits of the host-id for the subnet, you
have only 7 bits for the host-id and thus have only 126 (27 - 2) hosts in each
subnet. The maximum number of hosts is thus 64,512 (512 × 126), 1022 less after
the network is subnetted.
Class A, B, and C networks, before being subnetted, use these default masks (also
called natural masks): 255.0.0.0, 255.255.0.0, and 255.255.255.0 respectively.
IP Unnumbered Logically, to enable IP on an interface, you must assign this interface a unique IP
address. Yet, you can borrow an IP address already configured on one of other
interfaces on your device instead. This is called IP unnumbered and the interface
borrowing the IP address is called IP unnumbered interface.
You may need to use IP unnumbered to save IP addresses either when available IP
addresses are inadequate or when an interface is brought up but for occasional
use.
Configuring IP Besides directly assigning an IP address to an interface, you may configure the
Addresses interface to obtain one through BOOTP, DHCP, or PPP address negotiation as
alternatives. If you change the way an interface obtains an IP address, from
manual assignment to BOOTP for example, the IP address obtained from BOOTP
will overwrite the old one manually assigned.
n ■
■
Support for IP address acquisition modes varies by device.
This chapter only covers how to assign an IP address manually. For other
approaches, refer to “DHCP Address Allocation” on page 566 and “PPP and MP
Assigning an IP Address You may assign an interface multiple IP addresses, one primary and multiple
to an Interface secondaries, to connect multiple logical subnets on the same physical subnet.
Follow these steps to assign an IP address to an interface:



interface-number
Assign an IP address to the ip address ip-address { mask | Required
Interface mask-length } [ sub ]
No IP address is assigned by
default.
c CAUTION:
■ The primary IP address you assigned to the interface can overwrite the old one
if there is any.
■ You cannot assign secondary IP addresses to an interface using BOOTP, DHCP,
or PPP address negotiation.
■ The primary and secondary IP addresses you assign to the interface can be
located on the same network segment. However, this should not violate the
rule that different physical interfaces on your device, a primary interface and its
subinterfaces, or the subinterfaces on a father interface must reside on
different network segments.
IP Addressing Network requirements

Configuration Example As shown in Figure 187, Ethernet1/0 on a router is connected to a LAN comprising
two segments: 172.16.1.0/24 and 172.16.2.0/24.
To enable the hosts on the two network segments to access the external network
through Router, and enable the hosts on the two network segments to
communicate with each other, do the following:
■ Assign a primary IP address and a secondary IP address to Ethernet 1/0 on the

router.
■ Set the router as the gateway on all hosts.
Network diagram
Figure 187 Network diagram for IP address configuration

172.16.1.0/24 Router
Host B
Eth1/0
172.16.1.1 /24
172 .16 .1 .2/24 172.16.2.1 /24 sub
172 .16.2.2/24
Host A
172.16.2.0/24

# Assign a primary IP address and a secondary IP address to Ethernet1/0.
[Router-Ethernet1/0] ip address 172.16.2.1 255.255.255.0 sub
# Set the gateway address to 172.16.1.1 on the PCs attached to 172.16.1.0/24,

and to 172.16.2.1 on the PCs attached to 172.16.2.0/24.
# Use the ping command to verify the connectivity between the router and a host
on the subnet 172.16.1.0/24.
<Router> ping 172.16.1.2


0.00% packet loss
The information shown above indicates the router can communicate with the host
on the subnet 172.16.1.0/24.
# Use the ping command to verify the connectivity between the router and a host
on the subnet 172.16.2.0/24.
<Router> ping 172.16.2.2


0.00% packet loss
The information shown above indicates the router can communicate with the
hosts on the subnet 172.16.2.0/24.
# Use the ping command to verify the connectivity between the hosts on the
subnet 172.16.1.0/24 and hosts on subnet 172.16.2.0/24. Ping Host B on Host A
to verify that the ping operation is successful.

Configuring IP
Unnumbered
Configuration Assign a primary IP address to the interface from which you want to borrow the IP
Prerequisites address. Alternatively, you may configure the interface to obtain one through
BOOTP, DHCP, or PPP negotiation.
Configuration Procedure Follow these steps to configure IP unnumbered on an interface:

interface-number
Specify the current interface ip address unnumbered Required
to borrow the IP address of interface interface-type
The interface does not borrow
the specified interface interface-number
IP addresses from other
interfaces by default.
c CAUTION:
■ Serial, dial, POS, and ATM interfaces can borrow IP addresses from Layer 3
Ethernet interfaces or other interfaces.
■ Layer 3 Ethernet interfaces, tunnel interfaces and loopback interfaces cannot
borrow IP addresses of other interfaces, but other interfaces borrow IP
addresses of these interfaces.
■ One interface cannot borrow an IP address from an unnumbered interface.
■ Multiple interfaces can use the same unnumbered IP address.
■ The IP address of the borrowing interface always keeps consistent and varies
with that of the borrowed interface. That is, if an IP address is configured for
the borrowed interface, the IP address of the borrowing interface is the same
as that of the borrowed interface; if no IP address is configured for the
borrowed interface, no IP address is assigned for the borrowing interface.
IP Unnumbered Network requirements

Configuration Example Two routers on an intranet are connected to each other through serial interfaces
across DDN, and they each connect to a LAN through Ethernet interfaces.
To save IP addresses, configure the serial interfaces to borrow IP addresses from

the Ethernet interfaces.

Configuring IP Unnumbered 629
Network diagram
Figure 188 Network diagram for IP unnumbered configuration
DDN
S 2/1 S 2/1
Router A Router B
Eth1 / 1 Eth 1 /1
172 .16. 10 . 1/ 24 172 . 16. 20. 1/24
# Assign a primary IP address to Ethernet1/1.
# Configure Serial2/1 to borrow an IP address from Ethernet1/1.

[RouterA-Serial2/1] ip address unnumbered interface ethernet 1/1
# Create a route to the Ethernet segment attached to Router B, specifying

interface Serial2/1 as the outgoing interface.
[RouterA] ip route-static 172.16.20.0 255.255.255.0 serial 2/1

# Assign a primary IP address to Ethernet1/1.
# Configure interface Serial2/1 to borrow an IP address from Ethernet1/1.

[RouterB-Serial2/1] ip address unnumbered interface ethernet 1/1
# Create a route to the Ethernet segment attached to Router A, specifying

interface Serial2/1 as the outgoing interface.
[RouterB] ip route-static 172.16.10.0 255.255.255.0 serial 2/1

3 Ping a host attached to Router B from Router A to verify the configuration.


0.00% packet loss
The output shows that the host can be pinged.
Displaying and
Addressing Display information about a display ip interface Available in any view
specified or all L3 interfaces [ interface-type
interface-number ]
Display brief information display ip interface brief Available in any view
about a specified or all Layer 3 [ interface-type
interfaces interface-number ]

IP PERFORMANCE CONFIGURATION
41
When configuring IP performance, go to these sections for the information you
are interested in:
■ “IP Performance Overview” on page 631
■ “Enabling the Device to Forward Directed Broadcasts” on page 631
■ “Configuring TCP Attributes” on page 633
■ “Configuring ICMP to Send Error Packets” on page 636
■ “Displaying and Maintaining IP Performance” on page 638
IP Performance In some network environments, you need to adjust the IP parameters to achieve
Overview best network performance. IP performance configuration includes:
■ Enabling the device to forward directed broadcasts
■ Configuring the maximum TCP segment size (MSS) of the interface
■ Enabling the SYN Cookie feature and protection against Naptha attack
■ Configuring TCP timers
■ Configuring the TCP buffer size
■ Enabling ICMP error packets sending
Enabling the Device to Directed broadcasts refer to broadcast packets sent to a specific network. In the
Forward Directed destination IP address of a directed broadcast, the network ID is a network-specific
Broadcasts number and the host ID is all ones. Enabling the device to receive and forward
directed broadcasts to a directly connected network will give hackers an
opportunity to attack the network. Therefore, the device is disabled from receiving
and forwarding directed broadcasts by default. However, you should enable the
feature when:
■ Using the UDP Helper function to convert broadcasts to unicasts and forward
them to a specified server.
■ Using the Wake on LAN function to forward directed broadcasts to a PC on the
remote network.
Enabling the Device to Follow these steps to enable the device to forward directed broadcasts:
Forward Directed
Broadcasts To do... Use the command... Remarks
interface-number

632 CHAPTER 41: IP PERFORMANCE CONFIGURATION

Enable the interface to ip forward-broadcast [ acl Required
forward directed broadcasts acl-number ]
to a directly connected
network
n ■ You can reference an ACL to forward only directed broadcasts permitted by the
ACL.
■ If you execute the ip forward-broadcast acl command on an interface
repeatedly, the last execution overwrites the previous one. If the command
executed last time does not include the acl acl-number, the ACL configured
previously will be removed.

As shown in Figure 189, the host’s interface and Ethernet1/1 of Router A are on
the same network segment (1.1.1.0/24). Interface Ethernet 1/1 of Router A and
interface Ethernet 1/0 of Router B are on another network segment (2.2.2.0/24).
The default gateway of the host is Ethernet 1/1 (IP address 1.1.1.2/24) of Router
A. Configure a static route on Router B to enable the reachability between the
host and Router B.
Network diagram
Figure 189 Network diagram for forwarding directed broadcasts
Eth1/ 1 Eth 1/ 0 Eth 1/ 0

1. 1. 1.1 /24 1 . 1.1 .2/ 24 2. 2.2 .2/ 24 2.2 .2. 1 / 24
Host Router A Router B
■ Configure Router A
# Enable the interface Ethernet 1/0 on Router A to forward directed broadcasts.
[RouterA-Ethernet1/0] ip forward-broadcast
# Configure IP addresses for the interfaces Ethernet 1/1 and Ethernet 1/0.

■ Configure Router B
# Configure a static route to the host.
[RouterB] ip route-static 1.1.1.1 24 2.2.2.2

# Configure an IP address for the interface Ethernet 1/0.

■ Configure the host
# Set the IP address of the network interface card (NIC) connected to Router A to
1.1.1.1, the subnet mask to 255.255.255.0, and the gateway address to 1.1.1.2.
After the above configurations, if you ping the subnet broadcast address
(2.2.2.255) of interface Ethernet 1/0 of Router A on the host, the ping packets can
be received by interface Ethernet 1/0 of Router B. However, if you disable the ip
forward-broadcast command, the interface Ethernet 1/0 of Router B cannot
receive the ping packets.
Configuring TCP
Attributes
Configuring TCP MSS for An interface’s TCP MSS determines whether the TCP packets of the interface need
the Interface to be fragmented. If the size of a packet is smaller than the TCP MSS, the packet is
not fragmented; otherwise, it will be fragmented according to the TCP MSS.
Follow these steps to configure TCP MSS of the interface:

interface-number
Configure TCP MSS of the tcp mss value Required
interface
TCP MSS is 1460 bytes by
default.
n So far the interfaces that support this configuration include: Layer 3 Ethernet
interface, serial port, ATM interface, POS interface, dial port, Tunnel interface,
virtual Ethernet interface and virtual interface template.
Enabling the SYN Cookie As a general rule, the establishment of a TCP connection involves the following
Feature three handshakes:
1 The request originator sends a SYN message to the target server.
2 After receiving the SYN message, the target server establishes a TCP
semi-connection in the SYN_RECEIVED state, returns a SYN ACK message to the
originator, and waits for a response.
3 After receiving the SYN ACK message, the originator returns an ACK message.
Thus, the TCP connection is established.
Malicious attackers may mount SYN Flood attacks during TCP connection
establishment. They send SYN messages to the server to establish TCP
connections, but they never make any response to SYN ACK messages. As a result,

a large amount of TCP semi-connections are established, resulting in heavy

resource consumption and making the server unable to handle services normally.
The SYN Cookie feature can prevent SYN Flood attacks. After receiving a TCP
connection request, the server directly returns a SYN ACK message, instead of
establishing a TCP semi-connection. Only after receiving an ACK message from
the client can the server establish a connection, and then enter the ESTABLISHED
state. In this way, large amounts of TCP semi-connections could be avoided to
prevent the server from SYN Flood attacks.
Follow these steps to enable the SYN Cookie feature:

Enable the SYN Cookie tcp syn-cookie enable Required
feature
n ■ If the MD5 authentication is enabled, the SYN Cookie feature will not function.
After the MD5 authentication is disabled, the configured SYN Cookie feature
will be enabled automatically.
■ With the SYN Cookie feature enabled, only the MSS, instead of the window’s
zoom factor and timestamp, is negotiated during TCP connection
establishment.
Enabling Protection Naptha attacks are similar to the SYN Flood attacks. Attackers can perform Naptha
Against Naptha Attack attacks by using the six TCP connection states (CLOSING, ESTABLISHED,
FIN_WAIT_1, FIN_WAIT_2, LAST_ACK, and SYN_RECEIVED), and SYN Flood
attacks by using only the SYN_RECEIVED state.
Naptha attackers control a huge amount of hosts to establish TCP connections

with the server, keep these connections in the same state (any of the six), and
request for no data so as to exhaust the memory resource of the server. As a result,
the server cannot process normal services.
The protection against Naptha attack reduces the risk of the server being attacked
by accelerating the aging of TCP connections in a state. After the protection
against Naptha attack is enabled, the device periodically checks the number of
TCP connections in each state. If it detects that the number of TCP connections in
a state exceeds the maximum number, it will accelerate the aging of TCP
connections in such a state.
Follow these steps to enable the protection against Naptha attack

Enable the protection against tcp anti-naptha enable Required
Naptha attack


Configure the maximum of tcp state { closing | Optional
TCP connections in a state established | fin-wait-1 |
5 by default.
fin-wait-2 | last-ack |
syn-received } If the maximum number of
connection-number number TCP connections in a state is
0, the aging of TCP
connections in this state will
not be accelerated.
Configure the TCP state check tcp timer check-state Optional
interval timer-value
n ■ With the protection against Naptha attack enabled, the device will periodically
check and record the number of TCP connections in each state.
■ With the protection against Naptha attack enabled, if the device detects that
the number of TCP connections in a state exceeds the maximum number, the
device will consider that there is a Naptha attack and accelerate the aging of
these TCP connections. The device will not stop accelerating the aging of TCP
connections until the number of TCP connection in such a state is less than
80% of the maximum number.
Configuring TCP TCP optional parameters that can be configured include:

Optional Parameters ■ synwait timer: When sending a SYN packet, TCP starts the synwait timer. If no
response packets are received within the synwait timer timeout, the TCP
connection is not successfully created.
■ finwait timer: When the TCP connection is in FIN_WAIT_2 state, finwait timer
will be started. If no FIN packets are received within the timer timeout, the TCP
connection will be terminated. If FIN packets are received, the TCP connection
state changes to TIME_WAIT. If non-FIN packets are received, the system
restarts the timer from receiving the last non-FIN packet. The connection is
broken after the timer expires.
■ Size of TCP receive/send buffer
Follow these steps to configure TCP optional parameters:

Configure TCP synwait timer’s tcp timer syn-timeout Optional
timeout value time-value
By default, the timeout value
is 75 seconds.
Configure TCP finwait timer’s tcp timer fin-timeout Optional
timeout value time-value
By default, the timeout value
is 675 seconds.
Configure the size of TCP tcp window window-size Optional
receive/send buffer
By default, the buffer is 8
kilobytes.
c CAUTION: The actual length of the finwait timer is determined by the following
formula: Actual length of the finwait timer = (Configured length of the finwait
timer - 75) + configured length of the synwait timer.

Configuring ICMP to Sending error packets is a major function of ICMP protocol. In case of network
Send Error Packets abnormalities, ICMP packets are usually sent by the network or transport layer
protocols to notify corresponding devices so as to facilitate control and
management.
Advantage of sending ICMP error packets

There are three kinds of ICMP error packets: redirect packets, timeout packets and
destination unreachable packets. Their sending conditions and functions are as
follows.
1 Sending ICMP redirect packets
A host may have only a default route to the default gateway in its routing table
after startup. The default gateway will send ICMP redirect packets to the source
host and notify it to reselect a correct next hop router to send the subsequent
packets, if the following conditions are satisfied:
■ The receiving and forwarding interfaces are the same.

■ The selected route has not been created or modified by ICMP redirect packet.
■ The selected route is not the default route of the device.
■ There is no source route option in the packet.
ICMP redirect packets function simplifies host administration and enables a host to
gradually establish a sound routing table to find out the best route
2 Sending ICMP timeout packets
If the device received an IP packet with a timeout error, it drops the packet and
sends an ICMP timeout packet to the source.
The device will send an ICMP timeout packet under the following conditions:
■ If the device finds the destination of a packet is not itself and the TTL field of
the packet is 1, it will send a “TTL timeout” ICMP error message.
■ When the device receives the first fragment of an IP datagram whose
destination is the device itself, it will start a timer. If the timer times out before
all the fragments of the datagram are received, the device will send a
“reassembly timeout” ICMP error packet.
3 Sending ICMP destination unreachable packets
If the device receives an IP packet with the destination unreachable, it will drop the
packet and send an ICMP destination unreachable error packet to the source.
Conditions for sending this ICMP packet:
■ If neither a route nor the default route for forwarding a packet is available, the
device will send a “network unreachable” ICMP error packet.
■ If the destination of a packet is local while the transport layer protocol of the
packet is not supported by the local device, the device sends a “protocol
unreachable” ICMP error packet to the source.

Configuring ICMP to Send Error Packets 637
■ When receiving a packet with the destination being local and transport layer
protocol being UDP, if the packet’s port number does not match the running
process, the device will send the source a “port unreachable” ICMP error
packet.
■ If the source uses “strict source routing” to send packets, but the intermediate
device finds the next hop specified by the source is not directly connected, the
device will send the source a “source routing failure” ICMP error packet.
■ When forwarding a packet, if the MTU of the sending interface is smaller than
the packet but the packet has been set “Don’t Fragment”, the device will send
the source a “fragmentation needed and Don’t Fragment (DF)-set” ICMP error
packet.
Disadvantage of sending ICMP error packets

Although sending ICMP error packets facilitates network control and
management, it still has the following disadvantages:
■ Sending a lot of ICMP packets will increase network traffic.
■ If receiving a lot of malicious packets that cause it to send ICMP error packets,
the device’s performance will be reduced.
■ As the redirection function increases the routing table size of a host, the host’s
performance will be reduced if its routing table becomes very large.
■ If a host sends malicious ICMP destination unreachable packets, end users may
be affected.
To prevent such problems, you can disable the device from sending ICMP error
packets.
Follow these steps to disable sending ICMP error packets:

Disable sending ICMP undo ip redirects Required
redirection packets
Enabled by default.
Disable sending ICMP timeout undo ip ttl-expires Required
packets
Enabled by default.
Disable sending ICMP undo ip unreachables Required
destination unreachable
Enabled by default.
packets
n ■ The device stops sending “network unreachable” and “source route failure”
ICMP error packets after sending ICMP destination unreachable packets is
disabled. However, other destination unreachable packets can be sent
normally.
■ The device stops sending “TTL timeout” ICMP error packets after sending ICMP
timeout packets is disabled. However, “reassembly timeout” error packets will
be sent normally.

Displaying and
Performance Display current TCP display tcp status Available in any
connection state view
Display TCP connection display tcp statistics
statistics
Display UDP statistics display udp statistics
Display statistics of IP packets display ip statistics
Display statistics of ICMP display icmp statistics
flows
Display socket information display ip socket [ socktype sock-type ]
[ task-id socket-id ]
Display FIB forward display fib [ | { begin | include |
information exclude } string | acl acl-number |
ip-prefix ip-prefix-name ]
Display FIB forward display fib ip-address1 [ { mask1 |
information matching the mask-length1 } [ ip-address2 { mask2 |
specified destination IP mask-length2 } | longer ] | longer ]
address
Display statistics about the FIB display fib statistics
items
Clear statistics of IP packets reset ip statistics Available in user
view
Clear statistics of TCP reset tcp statistics
connections
Clear statistics of UDP flows reset udp statistics

IP UNICAST POLICY ROUTING
42 CONFIGURATION
When configuring IP unicast policy routing, go to these sections for information

you are interested in:
■ “Introduction to IP Unicast Policy Routing” on page 639
■ “IP Unicast Policy Routing Configuration” on page 639
■ “Displaying and Maintaining IP Unicast Policy Routing Configuration” on page
642
■ “IP Unicast Policy Routing Configuration Examples” on page 643
Introduction to IP Policy routing (also known as policy based routing) is a routing mechanism based
Unicast Policy Routing on the user-defined policies. Different from the traditional destination-based
routing mechanism, policy routing enables you to implement policies (based on
the source address, address length, and other criteria) that make packets flexibly
take different paths.
Policy routing involves system policy routing and interface policy routing:
■ System policy routing applies to locally generated packets, instead of

forwarded packets.
■ Interface policy routing applies to forwarded packets (arriving on an interface),
instead of locally generated packets (for example, ping packets).
As a rule, policy routing takes precedence over destination-based routing. That is,
policy routing is applied when packets match a policy, and otherwise,
destination-based routing is applied. However, if a default outgoing interface (next
hop) is configured, the destination-based routing takes precedence over policy
routing.
Configuring IP Unicast
Policy Routing
Defining a Policy A policy can consist of multiple nodes identified by node numbers. The smaller the
node number is, the higher the priority of the node’s policy is. A policy, which
consists of if-match clauses and apply clauses, is used to import a route to
forward IP packets.
An if-match clause specifies a matching rule on a node while an apply clause

specifies an action to be taken for packets.

640 CHAPTER 42: IP UNICAST POLICY ROUTING CONFIGURATION
There is an AND relationship between if-match clauses on a node. That is to say, a

packet must satisfy all matching rules specified by all if match clauses for the
node before the action specified by the apply clause is taken.
Currently, two types of if-match clause are available: if-match packet-length

and if-match acl. In each policy, you can specify only one if-match clause for
each type.
There are five types of apply clauses: apply ip-precedence, apply

output-interface, apply ip-address next-hop, apply default
output-interface, and apply ip-address default next-hop. You can specify
only one apply clause for each type in a policy. In the case that a packet satisfies
all if-match rules on a node, the priorities of these types of apply clauses are
ranked as follows:
■ apply ip-precedence: If configured, this clause will always be executed.

■ apply output-interface and apply ip-address next-hop: The apply
output-interface clause takes precedence over the apply ip-address
next-hop clause. This means that only the apply output-interface clause will
be executed when both are configured.
■ apply default output-interface and apply ip-address default next-hop:
Alike, the apply default output-interface clause takes precedence over the
apply ip-address default next-hop clause. This means that only the apply
default output-interface clause is executed when both are configured. Either
of these two clauses is executed only when no outgoing interface or next hop
is defined for packets, or only when the defined outgoing interface or next hop
is invalid and the destination address does not have a corresponding route in
the routing table.
There is an OR relationship between nodes of a policy. That is, if a packet matches

a node, it satisfies the policy.
When configuring policy nodes, you need to specify the match mode as permit or
deny:
■ permit: Specifies the match mode as permit on a policy node. If a packet

satisfies all rules defined by if-match clauses on the policy node, the apply
clauses are executed. If not, the packet will go to the next policy node for a
match.
■ deny: Specifies the match mode as deny on a policy node. When a packet
satisfies all rules defined by if-match clauses on the policy node, the packet
will be rejected and will not go to the next policy node for a match.
A packet satisfying the match rules on a node will not go to the other nodes. If the
packet does not satisfy the match rules on any node, the packet will be forwarded
by means of looking up the routing table.
You can define two next hops or two outgoing interfaces at most for a policy. In
this way, packets are forwarded in turn from the two outgoing interfaces or two
next hops to achieve load sharing.
Follow these steps to configure policies:

Configuring IP Unicast Policy Routing 641

Create a policy or policy-based-route policy-name Required
policy node and enter [ deny | permit ] node node-number
policy view
Define a packet if-match packet-length min-len Optional
length match rule max-len
Define an ACL match if-match acl acl-number Optional
rule
Set the packet apply ip-precedence { type | value} Optional
precedence
Set outgoing apply output-interface Optional
interfaces interface-type interface-number
Two interfaces at most can be
[ track track-entry-number ]
specified to send matched IP
[ interface-type interface-number
packets. These two interfaces
[ track track-entry-number ] ]
are simultaneously active to
achieve load sharing.
For non-P2P interfaces
(broadcast and NBMA
interfaces) such as Ethernet
interface, multiple next hops
are possible, and thus packets
may not be forwarded
successfully.
Set next hops apply ip-address next-hop Optional
ip-address [ track track-entry-number ]
Two next hops at most can be
[ ip-address [ track
specified. These two next
track-entry-number ] ]
hops are simultaneously active
to achieve load sharing.
Set default outgoing apply default output-interface Optional
interfaces interface-type interface-number
Two default outgoing
[ track track-entry-number ]
interfaces at most can be
[ interface-type interface-number
specified. These two
[ track track-entry-number ] ]
interfaces are simultaneously
active to achieve load sharing.
Set default next hops apply ip-address default next-hop Optional
ip-address [ track track-entry-number ]
Two default next hops at
[ ip-address [ track
most can be specified. These
track-entry-number ] ]
two next hops are
simultaneously active to
achieve load sharing.
n You can use the apply output-interface command to configure two outgoing
interfaces or the apply ip-address next-hop command two next hops. If you
want to modify either of the two outgoing interfaces or next hops, you can
execute the apply output-interface interface-type interface-number command
or apply ip-address next-hop ip-address command to overwrite the earlier one.
If you want to modify the two outgoing interfaces or next hops, you can directly
specify two interfaces or next hops before executing the apply output-interface
or apply ip-address next-hop command.
Enabling System Policy Policy routing includes system policy routing and interface policy routing. In most
Routing cases, the interface policy routing is used for the consideration of ordinary
forwarding and security.

The system policy routing is used to route packets generated by the local device.
You can enable the interface policy routing and the system policy routing
respectively. Only one policy can be referenced when system policy routing is
enabled.
Follow these steps to enable the system policy routing:

Enable system policy routing ip local policy-based-route Required.
and reference a policy policy-name
Enabling Interface Policy Interface policy routing is applied to packets arriving on an interface. Only one
Routing policy can be referenced when the policy routing is enabled on an interface.
Follow these steps to enable interface policy routing:

interface-number
Enable interface policy routing and ip policy-based-route Required
reference a policy policy-name
Displaying and
Maintaining IP Unicast To do... Use the command... Remarks
Policy Routing Display information about display ip policy-based-route Available in any
Configuration system and interface policy view
routing
Display the setting display ip policy-based-route setup
information of policy routing { interface interface-type interface-number
| local | policy-name }
Display policy routing display ip policy-based-route statistics
statistics { interface interface-type interface-number
| local }
Display the information of display policy-based-route
policy routing based on a [ policy-name ]
specified policy
Clear the statistics of policy reset policy-based-route statistics Available in user
routing based on a specified [ policy-name ] view
policy

IP Unicast Policy
Routing Configuration
Examples
Configuring Policy Network requirements

Routing Based on Source As shown in Figure 190, define policy aaa for policy routing so that TCP packets
Address arriving at the interface Ethernet 1/0 are forwarded via Serial 2/0 and other
packets are forwarded by means of looking up the routing table.
■ Node 5 indicates packets matching ACL 3101 are sent to the interface Serial
2/0.
■ Node 10 indicates packets matching ACL 3102 do not go through policy
routing.
Network diagram
Figure 190 Network diagram for policy routing based on source address
Internet
Router
S2/ 0 S2/1
Eth1/ 0
Subnet A
10. 110 .0. 0/ 16
Host A Host B
# If the device supports the firewall function, set the default filtering mode of the
firewall to deny.
[Router] firewall default deny
# Define the ACLs.
[Router] acl number 3101

[Router-acl-adv-3101] rule permit tcp
[Router-acl-adv-3101] quit
[Router] acl number 3102
[Router-acl-adv-3102] rule permit ip
[Router-acl-adv-3102] quit
# Define Node 5 of policy aaa so that TCP packets matching ACL 3101 are
forwarded to the interface Serial 2/0.

[Router] policy-based-route aaa permit node 5

[Router-policy-based-route] if-match acl 3101
[Router-policy-based-route] apply output-interface serial 2/0
[Router-policy-based-route] quit
# Define Node 10 of policy aaa so that policy routing will not be applied to packets
matching ACL 3102 and these packets will be forwarded by means of looking up
the routing table.
[Router] policy-based-route aaa deny node 10

[Router-policy-based-route] if-match acl 3102
[Router-policy-based-route] quit
# Apply policy aaa to interface Ethernet 1/0.

[Router-Ethernet1/0] ip policy-based-route aaa

Routing Based on Packet Policy routing is enabled and the policy lab1 is referenced on the interface
Size Ethernet 1/0 of Router A. Packets with a size of 64 to 100 bytes are forwarded to
150.1.1.2/24, while packets with a size of 101 to 1,000 bytes are forwarded to
151.1.1.2/24. All other packets are forwarded by means of looking up the routing
table.
Network diagram
Figure 191 Network diagram for policy routing based on packet size
60 윟 100 bytes
S 2 /0 S 2 /0
Router A 150 .1 .1 . 1/ 24 150 . 1 .1 .2 / 24 Router B
Eth 1 / 0 S2 /1 S 2 /1
192 .1 . 1 . 1/ 24 151 .1 .1. 1 / 24 151 . 1 .1 .2 / 24
Enable policy
routing on Eth 1/ 0
101 윟 1000 bytes
■ Configuration on Router A.
# Configure RIP.
[RouterA] rip
# Apply policy lab1 to interface Ethernet 1/0 to handle incoming packets.


[RouterA-Ethernet1/0] ip policy-based-route lab1
# Forward IP packets with a size of 64 to 100 bytes to the next hop 150.1.1.2 and
those with a size of 101 to 1,000 bytes to the next hop 151.1.1.2.
[RouterA] rip
[RouterA] policy-based-route lab1 permit node 10
[RouterA-policy-based-route] if-match packet-length 64 100
[RouterA-policy-based-route] apply ip-address next-hop 150.1.1.2
[RouterA-policy-based-route] quit
[RouterA] policy-based-route lab1 permit node 20
[RouterA-policy-based-route] if-match packet-length 101 1000
[RouterA-policy-based-route] apply ip-address next-hop 151.1.1.2
■ Configuration on Router B
# Configure RIP.
[RouterB] rip


UDP HELPER CONFIGURATION
43
When configuring UDP Helper, go to these sections for information you are
interested in:
■ “Introduction to UDP Helper” on page 647
■ “Configuring UDP Helper” on page 648
■ “Displaying and Maintaining UDP Helper” on page 648
■ “UDP Helper Configuration Example” on page 649
n UDP Helper can be currently configured on VLAN interfaces and Layer 3 Ethernet
interfaces (including subinterfaces) only.
Introduction to UDP Sometimes, a host needs to forward broadcasts to obtain network configuration
Helper information or request the names of other devices on the network. However, if the
server or the device to be requested is located in another broadcast domain, the
host cannot obtain such information through broadcast.
To solve this problem, the device provides the UDP Helper function to relay
specified UDP packets. In other words, UDP Helper functions as a relay agent that
converts UDP broadcast packets into unicast packets and forwards them to a
specified destination server.
With UDP Helper enabled, the device decides whether to forward a received UDP
broadcast according to the UDP destination port number of the packet.
■ If the destination port number of the packet matches the one pre-configured
on the device, the device modifies the destination IP address in the IP header,
and then sends the packet to the specified destination server.
■ If not, the device sends the packet to the upper layer protocol for processing.
By default, with UDP Helper enabled, the device forwards broadcast packets with
the six UDP destination port numbers listed in Table 35.
Table 35 List of default UDP ports
Protocol UDP port number

Trivial file transfer protocol (TFTP) 69
Domain name system (DNS) 53
Time service 37
NetBIOS name service (NetBIOS-NS) 137
NetBIOS datagram service (NetBIOS-DS) 138
Terminal access controller access control system (TACACS) 49

648 CHAPTER 43: UDP HELPER CONFIGURATION
Configuring UDP Follow these steps to configure UDP Helper:

Helper
Enable UDP Helper udp-helper enable Required
Disabled by default
Enable the forwarding of udp-helper port Optional
packets with a specified UDP { port-number | dns |
By default, the UDP helper
destination port number netbios-ds | netbios-ns |
enabled device forwards
tacacs | tftp | time }
broadcast packets with any of
the destination port numbers
69, 53, 37, 137, 138, and 49.
interface-number
Configure the destination udp-helper server ip-address Required
server to which UDP packets
By default, no destination
are to be forwarded
server is configured.
c CAUTION:
■ On the devices supporting the directed broadcast suppression function, the
receiving of directed broadcasts to a directly connected network is disabled by
default. As a result, UDP Helper is available only when the ip
forward-broadcast command is configured in system view. For details about
the ip forward-broadcast command, refer to “IP Performance Configuration”
on page 631.
■ The UDP Helper enabled device cannot forward DHCP broadcast packets. That
is to say, the UDP port number cannot be set to 67 or 68.
■ The dns, netbios-ds, netbios-ns, tacacs, tftp, and time keywords
correspond to the six default UDP port numbers. You can configure these
default UDP port numbers by specifying port numbers or the corresponding
parameters. For example, udp-helper port 53 and udp-helper port dns
specify the same UDP port number.
■ When you view the configuration information by using the display
current-configuration command, the UDP Helper configuration of the
default ports will not be displayed. UDP Helper configuration of these ports will
be displayed only after UDP Helper is disabled.
■ The configuration of all UDP ports (including the default ports) is removed if
you disable UDP Helper.
■ You can configure up to 256 UDP port numbers to enable the forwarding of
packets with these UDP port numbers.
■ You can configure up to 20 destination servers on an interface.
Displaying and
Maintaining UDP To do... Use the command... Remarks
Helper Displays the information of display udp-helper server Available in any view
forwarded UDP packets [ interface interface-type
interface-number ]

UDP Helper Configuration Example 649

Clear statistics about packets reset udp-helper packet Available in user view
forwarded
UDP Helper Network requirements

Configuration The IP address of the interface Ethernet 1/0 on Router A is 10.110.1.1/16,
Example connecting to the network segment 10.110.0.0/16. Enable the forwarding of
broadcast packets with UDP destination port number 55 to the destination server
10.2.1.1/16.
Network diagram
Figure 192 Network diagram for UDP Helper configuration
Eth1/0
Eth1 /0 Server
10.110. 1.1 /16
10.2.1 .1/ 16
IP network
Router A Router B
n The following configuration assumes that a route from Router A to the network
segment 10.2.0.0/16 is available.
# Enable UDP Helper.
[RouterA] udp-helper enable
# Enable the forwarding of broadcast packets with the UDP destination port
number 55.
[RouterA] udp-helper port 55
# Specify the server with the IP address of 10.2.1.1 as the destination server to
which UDP packets are to be forwarded.

[RouterA-Ethernet1/0] udp-helper server 10.2.1.1

650 CHAPTER 43: UDP HELPER CONFIGURATION

URPF CONFIGURATION
44
When configuring URPF, go to these sections for information you are interested in:
■ “URPF Overview” on page 651
■ “Configuring URPF” on page 652
URPF Overview
Basic Concepts Unicast reverse path forwarding (URPF) protects a network against attacks based
on source address spoofing.
Attackers launch attacks by creating a series of packets with forged source

addresses. For applications using IP-address-based authentication, this type of
attacks allows unauthorized users to access the system in the name of authorized
users, or even access the system as the administrator. Even if the attackers cannot
receive any response packets, the attacks are still disruptive to the attacked target.
Figure 193 Source address spoofing attack
1.1.1.8/8 2.2.2.1/8
Source IP address : 2.2.2.1/8
As shown in Figure 193, Router A originates a request to the server (Router B) by

sending a packet with a forged source IP address 2.2.2.1/8, and Router B sends a
packet to the real IP address 2.2.2.1/8 in response to the request. This type of
illegal packets will attack Router B and Router C.
URPF can prevent source address spoofing attacks.
Processing Flow URPF provides two types of check in common use: strict and loose. In addition, it
supports ACL check and default route check.
The URPF processing flow is as follows:
1 If the source address of a packet is found in the FIB table:

■ In strict approach, URPF does a reverse lookup for the outgoing interfaces of
the packet. If at least one outgoing interface matches the incoming interface,
the packet passes the check. Otherwise, the packet is dropped. (Reverse lookup
means looking up the outgoing interfaces of the packet with the source IP
address being the destination IP address.)

652 CHAPTER 44: URPF CONFIGURATION
■ In loose approach, URPF does a reverse lookup for the outgoing interfaces of
the packet. As long as an outgoing interface exists (no matter whether the
outgoing interface is consistent with the incoming interface), the packet passes
the check. Otherwise, the packet is dropped.
2 If the source address is not found in the FIB table, URPF makes a decision based on
the configuration of default route (the one configured on the router that received
the packet) and the allow-default-route keyword.
■ If a default route is available but the allow-default-route keyword is not
configured, the packet is rejected no matter which check approach is taken.
■ If both a default route and the allow-default-route argument are configured,
URPF’s decision depends on check approach. In strict approach, URPF lets the
packet pass and be forwarded normally if the outgoing interface of the default
route is the interface where the packet is received, and otherwise rejects it. In
loose approach, URPF lets the packet pass and be forwarded directly.
3 The packet will come to ACL check if and only if it is rejected. If the packet passes
ACL check, it is forwarded as normal; otherwise, it is discarded.
Configuring URPF Follow these steps to configure URPF:

interface-number
Enable URPF check ip urpf { loose | strict } Required
[ allow-default-route ] [ acl
acl-number ]

FAST FORWARDING CONFIGURATION
45
When configuring fast forwarding, go to these sections for the information you
are interested in:
■ “Introduction to Fast Forwarding” on page 653
■ “Configuring Fast Forwarding” on page 654
■ “Displaying and Maintaining Fast Forwarding” on page 654
Introduction to Fast Forwarding efficiency is a key index of the performance of a router. In an ordinary
Forwarding forwarding process, when a router receives a packet, it copies the packet from the
interface memory to the CPU. Then, the CPU searches the routing table for routes
matching the destination address to fix the best route and encapsulate the packet
into a proper link layer frame. Finally, the link layer frame is copied to the output
queue through direct memory access (DMA) for forwarding. The system bus will
be involved twice in this process and the forwarding of each packet will repeat this
process.
Fast forwarding employs cache and the data-flow-based technology to handle

packets. The data on the Internet is generally based on data flow, which is a
specific application between two hosts, for example, the operation of using FTP to
transfer a file. A data flow is usually described by five tuples (source IP address,
source port number, destination IP address, destination port number, and protocol
number). When the first packet is forwarded by means of searching the routing
table, corresponding routing information is generated in the cache so that the
subsequent packets in the flow can be forwarded by means of searching the cache
directly. As a result, fast forwarding reduces the IP packet queue and routing time
and enhances forwarding throughput of IP packets. In addition, because the
routing table is already optimized in the cache, the searching speed is especially
high.
Fast forwarding is currently implemented:
■ On all kinds of high-speed interfaces (including sub-interfaces), such as

Ethernet, synchronous PPP, Frame Relay and HDLC interfaces.
■ On PPP MP links.
■ On IPHC compression or VJ compression enabled PPP links.
■ When a packet filter is configured.
■ When an application specific packet filter (ASPF) is configured.
■ When network address translation (NAT) is configured.
■ When generic routing encapsulation (GRE) is configured.

654 CHAPTER 45: FAST FORWARDING CONFIGURATION
Fast forwarding can improve the packet forwarding efficiency greatly.
The performance of fast forwarding is sometimes affected by some attributes, for

example, packet queue management and packet header compression. Although
fast forwarding can process segmented IP packets, it does not support
re-segmentation of IP packets.
Configuring Fast Follow these steps to configure fast forwarding:

Forwarding
interface-number
Enable fast forwarding on the ip fast-forwarding Optional
interface in the inbound or [ inbound | outbound ]
By default, fast forwarding is
outbound direction
enabled in both the inbound
and outbound directions.
Displaying and
Maintaining Fast To do... Use the command... Remarks
Forwarding Display the information in the display ip fast-forwarding Available in any view
fast forwarding cache cache
Clear the information in the reset ip fast-forwarding Available in user view
fast-forwarding cache cache

IPV6 BASICS CONFIGURATION
46
When configuring IPv6 basics, go to these sections for information you are
interested in:
■ “IPv6 Overview” on page 655
■ “IPv6 Basics Configuration Task List” on page 664
■ “Configuring Basic IPv6 Functions” on page 665
■ “Configuring IPv6 NDP” on page 666
■ “Configuring PMTU Discovery” on page 670
■ “Configuring IPv6 TCP Properties” on page 671
■ “Configuring IPv6 FIB-Based Forwarding” on page 671
■ “Configuring ICMPv6 Packet Sending” on page 672
■ “Configuring IPv6 DNS” on page 673
■ “Displaying and Maintaining IPv6 Basics Configuration” on page 674
■ “IPv6 Configuration Example” on page 675
■ “Troubleshooting IPv6 Basics Configuration” on page 678
IPv6 Overview Internet protocol version 6 (IPv6), also called IP next generation (IPng), was
designed by the Internet Engineering Task Force (IETF) as the successor to Internet
protocol version 4 (IPv4). The significant difference between IPv6 and IPv4 is that
IPv6 increases the IP address size from 32 bits to 128 bits.
This section covers the following:
■ “IPv6 Features” on page 655

■ “Introduction to IPv6 Address” on page 657
■ “Introduction to IPv6 Neighbor Discovery Protocol” on page 659
■ “IPv6 PMTU Discovery” on page 663
■ “Introduction to IPv6 DNS” on page 664
■ “Protocols and Standards” on page 664
IPv6 Features Header format simplification

IPv6 cuts down some IPv4 header fields or move them to the IPv6 extension
headers to reduce the length of the basic IPv6 header. IPv6 uses the basic header
with a fixed length, thus making IPv6 packet handling simple and improving
forwarding efficiency. Although the IPv6 address size is four times that of IPv4

656 CHAPTER 46: IPV6 BASICS CONFIGURATION
addresses, the size of basic IPv6 headers is 40 bytes and is only twice that of IPv4
headers (excluding the Options field).
Figure 194 Comparison between IPv4 packet header format and basic IPv6 packet header
format
0 3 7 15 23 31 0 3 11 15 23 31
Traffic
Ver HL ToS Total length Ver Flow label
class
Next
Identification F Fragment offset Payload length Hop limit
header
TTL Protocol Header checksum
Source address (32 bits)

Source address (128 bits)
Destination address (32 bits)
Options Padding
IPv4 header
Destination address (128 bits)
Basic IPv 6 header
Adequate address space

The source and destination IPv6 addresses are both 128 bits (16 bytes) long. IPv6
can provide 3.4 x 1038 addresses to completely meet the requirements of
hierarchical address division as well as allocation of public and private addresses.
Hierarchical address structure

IPv6 adopts the hierarchical address structure to quicken route search and reduce
the system source occupied by the IPv6 routing table by means of route
aggregation.
Automatic address configuration

To simplify the host configuration, IPv6 supports stateful and stateless address
configuration.
■ Stateful address configuration means that a host acquires an IPv6 address and
related information from a server (for example, DHCP server).
■ Stateless address configuration means that a host automatically configures an
IPv6 address and related information on the basis of its own link-layer address
and the prefix information advertised by the router.
In addition, a host can generate a link-local address on the basis of its own
link-layer address and the default prefix (FE80::/64) to communicate with other
hosts on the same link.
Built-in security
IPv6 uses IPSec as its standard extension header to provide end-to-end security.
This feature provides a standard for network security solutions and improves the
interoperability between different IPv6 applications.

IPv6 Overview 657
QoS support
The Flow Label field in the IPv6 header allows the device to label packets in a flow
and provide special handling for these packets.
Enhanced neighbor discovery mechanism

The IPv6 neighbor discovery protocol is implemented through a group of Internet
Control Message Protocol Version 6 (ICMPv6) messages that manages the
information exchange between neighbor nodes on the same link. The group of
ICMPv6 messages takes the place of Address Resolution Protocol (ARP) messages,
Internet Control Message Protocol version 4 (ICMPv4) router discovery messages,
and ICMPv4 redirection messages and provides a series of other functions.
Flexible extension headers

IPv6 cancels the Options field in IPv4 packets but introduces multiple extension
headers. In this way, IPv6 enhances the flexibility greatly to provide scalability for IP
while improving the handling efficiency. The Options field in IPv4 packets contains
40 bytes at most, while the size of IPv6 extension headers is restricted by that of
IPv6 packets.
Introduction to IPv6 IPv6 address format

Address An IPv6 address is represented as a series of 16-bit hexadecimals, separated by
colons. An IPv6 address is divided into eight groups, and the 16 bits of each group
are represented by four hexadecimal numbers which are separated by colons, for
example, 2001:0000:130F:0000:0000:09C0:876A:130B.
To simplify the representation of IPv6 addresses, zeros in IPv6 addresses can be

handled as follows:
■ Leading zeros in each group can be removed. For example, the

above-mentioned address can be represented in shorter format as
2001:0:130F:0:0:9C0:876A:130B.
■ If an IPv6 address contains two or more consecutive groups of zeros, they can
be replaced by the double-colon :: option. For example, the above-mentioned
address can be represented in the shortest format as
2001:0:130F::9C0:876A:130B.
c CAUTION: The double-colon :: option can be used only once in an IPv6 address.
Otherwise, the device is unable to determine how many zeros that double-colons
represent when converting them to zeros to restore a 128-bit IPv6 address.
An IPv6 address consists of two parts: address prefix and interface ID. The address
prefix and the interface ID are respectively equivalent to the network ID and the
host ID in an IPv4 address.
An IPv6 address prefix is written in IPv6-address/prefix-length notation, where

IPv6-address is an IPv6 address in any of the notations, and prefix-length is a
decimal number indicating how many bits from the utmost left of an IPv6 address
are the address prefix.
IPv6 address classification

IPv6 addresses fall into three types: unicast address, multicast address, and anycast
address.

■ Unicast address: An identifier for a single interface, similar to an IPv4 unicast

address. A packet sent to a unicast address is delivered to the interface
identified by that address.
■ Multicast address: An identifier for a set of interfaces (typically belonging to
different nodes), similar to an IPv4 multicast address. A packet sent to a
multicast address is delivered to all interfaces identified by that address.
■ Anycast address: An identifier for a set of interfaces (typically belonging to
different nodes). A packet sent to an anycast address is delivered to one of the
interfaces identified by that address (the nearest one, according to the routing
protocols’ measure of distance).
n There are no broadcast addresses in IPv6. Their function is superseded by multicast

addresses.
The type of an IPv6 address is designated by the first several bits called format
prefix. Table 36 lists the mappings between address types and format prefixes.
Table 36 Mapping between address types and format prefixes
Type Format prefix (binary) IPv6 prefix ID

Unicast Unassigned address 00...0 (128 bits) ::/128
address
Loopback address 00...1 (128 bits) ::1/128
Link-local address 1111111010 FE80::/10
Site-local address 1111111011 FEC0::/10
Global unicast other forms -
address
Multicast address 11111111 FF00::/8
Anycast address Anycast addresses are taken from unicast address space
and are not syntactically distinguishable from unicast
addresses.
Unicast address
There are several forms of unicast address assignment in IPv6, including
aggregatable global unicast address, link-local address, and site-local address.
■ The aggregatable global unicast address, equivalent to an IPv4 public address,
is provided for network service providers. This type of address allows efficient
route prefix aggregation to restrict the number of global routing entries.
■ The link-local address is used for communication between link-local nodes in
neighbor discovery and stateless autoconfiguration. Routers must not forward
any packets with link-local source or destination addresses to other links.
■ IPv6 unicast site-local addresses are similar to private IPv4 addresses. Routers
must not forward any packets with site-local source or destination addresses
outside of the site (equivalent to a private network).
■ Loopback address: The unicast address 0:0:0:0:0:0:0:1 (represented in the
shortest format as ::1) is called the loopback address and may never be
assigned to any physical interface. Like the loopback address in IPv4, it may be
used by a node to send an IPv6 packet to itself.
■ Unassigned address: The unicast address “::” is called the unassigned address
and may not be assigned to any node. Before acquiring a valid IPv6 address, a

IPv6 Overview 659
node may fill this address in the source address field of an IPv6 packet, but may
not use it as a destination IPv6 address.
Multicast address
IPv6 multicast addresses listed in Table 37 are reserved for special purpose.
Table 37 Reserved IPv6 multicast addresses
Address Application
FF01::1 Node-local scope all-nodes multicast address
FF02::1 Link-local scope all-nodes multicast address
FF01::2 Node-local scope all-routers multicast address
FF02::2 Link-local scope all-routers multicast address
FF05::2 Site-local scope all-routers multicast address
Besides, there is another type of multicast address: solicited-node address. A

solicited-node multicast address is used to acquire the link-layer addresses of
neighbor nodes on the same link, and is also used for duplicate address detection
(DAD). Each IPv6 unicast or anycast address has one corresponding solicited-node
address. The format of a solicited-node multicast address is:
FF02:0:0:0:0:1:FFXX:XXXX. Where, FF02:0:0:0:0:1 FF is permanent and consists of
104 bits, and XX:XXXX is the last 24 bits of an IPv6 unicast or anycast address.
Interface identifier in IEEE EUI-64 format

Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a
link and they are required to be unique on that link. Interface identifiers in IPv6
unicast addresses are currently required to be 64 bits long. An interface identifier
in IEEE EUI-64 format is derived from the link-layer address of that interface.
Interface identifiers in IPv6 addresses are 64 bits long, while MAC addresses are 48
bits long. Therefore, the hexadecimal number FFFE needs to be inserted in the
middle of MAC addresses (behind the 24 high-order bits). To ensure the interface
identifier obtained from a MAC address is unique, it is necessary to set the
universal/local (U/L) bit (the seventh high-order bit) to “1”. Thus, an interface
identifier in IEEE EUI-64 format is obtained.
Figure 195 Convert a MAC address into an EUI-64 interface identifier
MAC address: 0012-3400-ABCD
Represented in binary : 0000000000010010 0011010000000000 1010101111001101
Insert FFFE: 0000000000010010 0011010011111111 1111111000000000 1010101111001101
Set U/L bit: 0000001000010010 0011010011111111 1111111000000000 1010101111001101
EUI-64 address: 0212:34FF:FE00:ABCD
Introduction to IPv6 IPv6 neighbor discovery protocol (NDP) uses five types of ICMPv6 messages to
Neighbor Discovery implement the following functions:
Protocol ■ “Address resolution” on page 660

■ “Neighbor reachability detection” on page 661

■ “Duplicate address detection” on page 661
■ “Router/prefix discovery and address autoconfiguration” on page 662
■ “Redirection” on page 663
Table 38 lists the types and functions of ICMPv6 messages used by the NDP.
Table 38 Types and functions of ICMPv6 messages
ICMPv6 message Number Function

Neighbor solicitation (NS) 135 Used to acquire the link-layer address of a
message neighbor
Used to verify whether the neighbor is
reachable
Used to perform a duplicate address
detection
Neighbor advertisement (NA) 136 Used to respond to an NS message
message
When the link layer changes, the local node
initiates an NA message to notify neighbor
nodes of the node information change.
Router solicitation (RS) 133 After started, a node sends an RS message
message to request the router for an address prefix
and other configuration information for the
purpose of autoconfiguration.
Router advertisement (RA) 134 Used to respond to an RS message
message
With the RA message suppression disabled,
the router regularly sends an RA message
containing information such as address
prefix and flag bits
Redirect message 137 When a certain condition is satisfied, the
default gateway sends a redirect message
to the source host so that the host can
reselect a correct next hop router to
forward packets.
The NDP mainly provides the following functions:
Address resolution
Similar to the ARP function in IPv4, a node acquires the link-layer addresses of
neighbor nodes on the same link through NS and NA messages. Figure 196 shows
how node A acquires the link-layer address of node B.

IPv6 Overview 661
Figure 196 Address resolution
Host A Host B
ICMP type = 135 NS

Src = A
Dst = solicited-node multicast address of B
Data = link layer address of A
ICMP type = 136
NA Src = B
Dst = A
Data = link layer address of B
The address resolution procedure is as follows:
1 Node A multicasts an NS message. The source address of the NS message is the

IPv6 address of an interface of node A and the destination address is the
solicited-node multicast address of node B. The NS message contains the link-layer
address of node A.
2 After receiving the NS message, node B judges whether the destination address of
the packet corresponds to the solicited-node multicast address. If yes, node B can
learn the link-layer address of node A, and then unicast an NA message containing
its link-layer address.
3 Node A acquires the link-layer address of node B from the NA message. After that,
node A and node B can communicate.
Neighbor reachability detection

After node A acquires the link-layer address of its neighbor node B, node A can
verify whether node B is reachable according to NS and NA messages.
1 Node A sends an NS message whose destination address is the IPv6 address of
node B.
2 If node A receives an NA message from node B, node A considers that node B is
reachable. Otherwise, node B is unreachable.
Duplicate address detection

After node A acquires an IPv6 address, it will perform duplicate address detection
(DAD) to determine whether the address is being used by other nodes (similar to
the gratuitous ARP function of IPv4). DAD is accomplished through NS and NA
messages. Figure 196 shows the DAD procedure.

Figure 197 Duplicate address detection
Host A Host B
2000::1
ICMP type = 135 NS

Src = ::
Dst = FF02::1:FF00:1
Data = 2000::1
ICMP type = 136
NA Src = 2000::1
Dst = FF02::1
Target address = 2000::1
The DAD procedure is as follows:
1 Node A sends an NS message whose source address is the unassigned address ::

and destination address is the corresponding solicited-node multicast address of
the IPv6 address to be detected. The NS message contains the IPv6 address.
2 If node B uses this IPv6 address, node B returns an NA message. The NA message
contains the IPv6 address of node B.
3 Node A learns that the IPv6 address is being used by node B after receiving the NA
message from node B. Otherwise, node B is not using the IPv6 address and node A
can use it.
Router/prefix discovery and address autoconfiguration

Router/prefix discovery means that a node locates the neighboring routers, and
learns the prefix of the network where the node is located, and other
configuration parameters from the received RA message.
Stateless address autoconfiguration means that a node automatically configures

an IPv6 address according to the information obtained through router/prefix
discovery.
The router/prefix discovery is implemented through RS and RA messages. The

router/prefix discovery procedure is as follows:
1 After started, a node sends an RS message to request the router for the address
prefix and other configuration information for the purpose of autoconfiguration.
2 The router returns an RA message containing information such as prefix
information option and flag bits. (The router also regularly sends an RA message.)
3 The node automatically configures an IPv6 address and other information for its
interface according to the address prefix and other configuration parameters in
the RA message.
n ■ In addition to an address prefix, the prefix information option also contains the
preferred lifetime and valid lifetime of the address prefix. After receiving a
periodic RA message, the node updates the preferred lifetime and valid lifetime
of the address prefix accordingly.
■ An automatically generated address is applicable within the valid lifetime and
will be removed when the valid lifetime times out.

IPv6 Overview 663
Redirection
When a host is started, its routing table may contain only the default route to the
gateway. When certain conditions are satisfied, the gateway sends an ICMPv6
redirect message to the source host so that the host can select a better next hop to
forward packets (similar to the ICMP redirection function in IPv4).
The gateway will send an IPv6 ICMP redirect message when the following
conditions are satisfied:
■ The receiving interface is the forwarding interface.

■ The selected route itself is not created or modified by an IPv6 ICMP redirect
message.
■ The selected route is not the default route.
■ The forwarded IPv6 packet does not contain any routing header.
IPv6 PMTU Discovery The links that a packet passes from the source to the destination may have
different MTUs. In IPv6, when the packet size exceeds the link MTU, the packet
will be fragmented at the source end so as to reduce the processing pressure of
the forwarding device and utilize network resources rationally.
The path MTU (PMTU) discovery mechanism is to find the minimum MTU of all
links in the path from the source to the destination. Figure 198 shows the working
procedure of the PMTU discovery.
Figure 198 Working procedure of the PMTU discovery
MTU = 1500 MTU = 1500 MTU = 1350 MTU = 1400
Source
Packet with MTU = 1500
ICMP error: packet too big;
use MTU = 1350
Packet with MTU = 1350
Packet received
The working procedure of the PMTU discovery is as follows:
1 The source host uses its MTU to fragment packets and then sends them to the
destination host.
2 If the MTU supported by the forwarding interface is less than the packet size, the
forwarding device will discard the packet and return an ICMPv6 error packet
containing the interface MTU to the source host.
3 After receiving the ICMPv6 error packet, the source host uses the returned MTU to
fragment the packet again and then sends it.
4 Step 2 to step 3 are repeated until the destination host receives the packet. In this
way, the minimum MTU of all links in the path from the source host to the
destination host is determined.

Introduction to IPv6 DNS In the IPv6 network, a domain name system (DNS) supporting IPv6 converts
domain names into IPv6 addresses, instead of IPv4 addresses.
However, just like an IPv4 DNS, an IPv6 DNS also covers static domain name
resolution and dynamic domain name resolution. The function and
implementation of these two types of domain name resolution are the same as
those of an IPv4 DNS. For details, refer to “DNS Configuration” on page 609.
Usually, the DNS server connecting IPv4 and IPv6 networks not only contain A
records (IPv4 addresses), but also AAAA records (IPv6 addresses). The DNS server
can convert domain names into IPv4 addresses or IPv6 addresses. In this way, the
DNS server implements the functions of both IPv6 DNS and IPv4 DNS.
Protocols and Standards Protocols and standards related to IPv6 include:

■ RFC 1881: IPv6 Address Allocation Management
■ RFC 1887: An Architecture for IPv6 Unicast Address Allocation
■ RFC 1981: Path MTU Discovery for IP version 6
■ RFC 2375: IPv6 Multicast Address Assignments
■ RFC 2460: Internet Protocol, Version 6 (IPv6) Specification.
■ RFC 2461: Neighbor Discovery for IP Version 6 (IPv6)
■ RFC 2462: IPv6 Stateless Address Autoconfiguration
■ RFC 2463: Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification
■ RFC 2464: Transmission of IPv6 Packets over Ethernet Networks
■ RFC 2526: Reserved IPv6 Subnet Anycast Addresses
■ RFC 3307: Allocation Guidelines for IPv6 Multicast Addresses
■ RFC 3513: Internet Protocol Version 6 (IPv6) Addressing Architecture
■ RFC 3596: DNS Extensions to Support IP Version 6
IPv6 Basics Complete the following tasks to perform IPv6 basics configuration:
Configuration Task
List Task Remarks
“Configuring Basic IPv6 Functions” on page 665 Required
“Configuring IPv6 NDP” on page 666 Optional
“Configuring PMTU Discovery” on page 670 Optional
“Configuring IPv6 TCP Properties” on page 671 Optional
“Configuring IPv6 FIB-Based Forwarding” on page 671 Optional
“Configuring ICMPv6 Packet Sending” on page 672 Optional
“Configuring IPv6 DNS” on page 673 Optional

Configuring Basic IPv6 Functions 665
Configuring Basic IPv6

Functions
Enabling the IPv6 Packet Before IPv6-related configurations, you need to enable the IPv6 packet forwarding
Forwarding Function function. Otherwise, an interface cannot forward IPv6 packets even if an IPv6
address is configured, resulting in communication failures in the IPv6 network.
Follow these steps to enable the IPv6 packet forwarding function:

Enable the IPv6 packet ipv6 Required
forwarding function
Configuring an IPv6 IPv6 site-local addresses and aggregatable global unicast addresses can be
Unicast Address configured in either of the following ways:
■ EUI-64 format: When the EUI-64 format is adopted to form IPv6 addresses, the
IPv6 address prefix of an interface is the configured prefix, and the interface
identifier is derived from the link-layer address of the interface.
■ Manual configuration: IPv6 site-local addresses or aggregatable global unicast
addresses are configured manually.
IPv6 link-local addresses can be configured in either of the following ways:
■ Automatic generation: The device automatically generates a link-local address

for an interface according to the link-local address prefix (FE80::/64) and the
link-layer address of the interface.
■ Manual assignment: IPv6 link-local addresses can be assigned manually.
Follow these steps to configure an IPv6 unicast address:

interface-number
Configure an Manually assign an ipv6 address Required to use any of the
IPv6 IPv6 address { ipv6-address two commands
aggregatable prefix-length |
By default, no site-local
global unicast ipv6-prefix/prefix-length }
address or aggregatable
address or
Adopt the EUI-64 ipv6 address global unicast address is
site-local
format to form an ipv6-prefix/prefix-length configured for an
address
IPv6 address interface.


Configure an Automatically ipv6 address auto Optional
IPv6 link-local generate a link-local
By default, after an IPv6
address link-local address
site-local address or
Manually assign a ipv6 address aggregatable global
link-local address ipv6-address link-local unicast address is
for an interface configured for an
interface, a link-local
address will be generated
automatically.
n ■ After an IPv6 site-local address or aggregatable global unicast address is

configured for an interface, a link-local address will be generated automatically.
The automatically generated link-local address is the same as the one
generated by using the ipv6 address auto link-local command. If a link-local
address is manually assigned to an interface, this link-local address takes effect.
If the manually assigned link-local address is removed, the automatically
generated link-local address takes effect.
■ The manual assignment takes precedence over the automatic generation. That
is, if you first adopt the automatic generation and then the manual
assignment, the manually assigned link-local address will overwrite the
automatically generated one. If you first adopt the manual assignment and
then the automatic generation, the automatically generated link-local address
will not take effect and the link-local address of an interface is still the manually
assigned one. If you delete the manually assigned address, the automatically
generated link-local address is validated.
■ The undo ipv6 address auto link-local command can be used only after the
ipv6 address auto link-local command is executed. However, if an IPv6
site-local address or aggregatable global unicast address is already configured
for an interface, the interface still has a link-local address because the system
automatically generates one for the interface. If no IPv6 site-local address or
aggregatable global unicast address is configured, the interface has no
link-local address.
■ The manually configured global unicast address takes precedence over the one
automatically generated. If a global unicast address has been generated on an
interface when you configure another one with the same address prefix, the
latter overwrites the previous one. After that, the overwritten global unicast
address will not be restored even if the manually configured one is removed. A
new global unicast address will be generated based on the address prefix
information in the RA message that the device receives for the next time.
Configuring IPv6 NDP
Configuring a Static The IPv6 address of a neighbor node can be resolved into a link-layer address
Neighbor Entry dynamically through NS and NA messages or through a manually configured static
neighbor entry.
The device uniquely identifies a static neighbor entry according to the IPv6 address
and the Layer 3 interface ID. Currently, there are two configuration methods:
■ Configure an IPv6 address and link-layer address for a Layer 3 interface.

■ Configure an IPv6 address and link-layer address for a port in a VLAN.
Follow these steps to configure a static neighbor entry:

Configure a static ipv6 neighbor ipv6-address mac-address { vlan-id Required
neighbor entry port-type port-number | interface interface-type
interface-number }
c CAUTION: You can adopt either of the two methods above to configure a static
neighbor entry for a VLAN interface.
■ After a static neighbor entry is configured by using the first method, the device
needs to resolve the corresponding Layer 2 port information of the VLAN
interface.
■ If you adopt the second method to configure a static neighbor entry, you
should ensure that the corresponding VLAN interface exists and that the layer 2
port specified by port-type port-number belongs to the VLAN specified by
vlan-id. After a static neighbor entry is configured, the device relates the VLAN
interface to an IPv6 address to uniquely identify a static neighbor entry.
Configuring the The device can dynamically acquire the link-layer address of a neighbor node and
Maximum Number of add it into the neighbor table through NS and NA messages. Too large a neighbor
Neighbors Dynamically table from which neighbor entries can be dynamically acquired may lead to the
Learned forwarding performance degradation of the device. Therefore, you can restrict the
size of the neighbor table by setting the maximum number of neighbors that an
interface can dynamically learn. When the number of dynamically learned
neighbors reaches the threshold, the interface will stop learning neighbor
information.
Follow these steps to configure the maximum number of neighbors dynamically

learned:

interface-number
Configure the maximum ipv6 neighbors Optional
number of neighbors max-learning-num number
The value ranges from 1 to
dynamically learned by an
2,048 and defaults to 1,024.
interface
Configuring Parameters You can configure whether the interface sends an RA message, the interval for
Related to an RA sending RA messages, and parameters in RA messages. After receiving an RA
Message message, a host can use these parameters to perform corresponding operations.
Table 39 lists the configurable parameters in an RA message and their
descriptions.

Table 39 Parameters in an RA message and their descriptions
Parameters Description
Cur hop limit When sending an IPv6 packet, a host uses the value of this parameter
to fill the Cur Hop Limit field in IPv6 headers. Meanwhile, the value of
this parameter is equal to the value of the Cur Hop Limit field in
response messages of the device.
Prefix information After receiving the prefix information advertised by the device, the
options hosts on the same link can perform stateless autoconfiguration
operations.
M flag This field determines whether hosts use the stateful autoconfiguration
to acquire IPv6 addresses.
If the M flag is set to 1, hosts use the stateful autoconfiguration to
acquire IPv6 addresses (for example, through a DHCP server).
Otherwise, hosts use the stateless autoconfiguration to acquire IPv6
addresses, that is, hosts configure IPv6 addresses according to their
own link-layer addresses and the prefix information issued by the
router.
O flag This field determines whether hosts use the stateful autoconfiguration
to acquire information other than IPv6 addresses.
If the O flag is set to 1, hosts use the stateful autoconfiguration to
acquire information other than IPv6 addresses (for example, through a
DHCP server). Otherwise, hosts use the stateless autoconfiguration to
acquire information other than IPv6 addresses.
Router lifetime This field is used to set the lifetime of the router that sends RA
messages to serve as the default router of hosts. According to the
router lifetime in the received RA messages, hosts determine whether
the router sending RA messages can serve as the default router.
Retrans timer If the device fails to receive a response message within the specified
time after sending an NS message, the device will retransmit the NS
message.
Reachable time If the neighbor reachability detection shows that a neighbor is
reachable, the device considers the neighbor is reachable within the
specified reachable time. If the device needs to send a packet to a
neighbor after the specified reachable time expires, the device will
reconfirm whether the neighbor is reachable.
n The values of the Retrans Timer field and the Reachable Time field configured for
an interface are sent to hosts via RA messages. Furthermore, this interface sends
NS messages at intervals of Retrans Timer and considers a neighbor reachable
within the time of Reachable Time.
Follow these steps to configure parameters related to an RA message:

Configure the current ipv6 nd hop-limit value Optional
hop limit
64 by default.
interface-number
Disable the RA message undo ipv6 nd ra halt Optional
suppression
By default, RA messages are
suppressed.


Configure the ipv6 nd ra interval Optional
maximum and max-interval-value
By default, the maximum interval
minimum intervals for min-interval-value
for sending RA messages is 600
sending RA messages
seconds, and the minimum interval
is 200 seconds.
The device sends RA messages at
intervals of a random value
between the maximum interval and
the minimum interval.
The minimum interval should be
less than or equal to 0.75 times the
maximum interval.
Configure the prefix ipv6 nd ra prefix { ipv6-prefix Optional
information options in prefix-length |
By default, no prefix information is
RA messages ipv6-prefix/prefix-length }
configured in RA messages, and the
valid-lifetime preferred-lifetime
IPv6 address of the interface
[ no-autoconfig [ off-link ]*
sending RA messages is used as the
prefix information.
Set the M flag bit to 1 ipv6 nd autoconfig Optional
managed-address-flag
By default, the M flag bit is set to 0,
that is, hosts acquire IPv6 addresses
through stateless
autoconfiguration.
Set the O flag bit to 1 ipv6 nd autoconfig Optional
other-flag
By default, the O flag bit is set to 0,
that is, hosts acquire other
information through stateless
autoconfiguration.
Configure the router ipv6 nd ra router-lifetime Optional
lifetime in RA messages value
Set the NS ipv6 nd ns retrans-timer Optional
retransmission timer value
By default, the local interface sends
NS messages at intervals of 1000
milliseconds, and the value of the
Retrans Timer field in RA messages
sent by the local interface is 0.
Set the reachable time ipv6 nd nud reachable-time Optional
value
By default, the neighbor reachable
time on the local interface is 30000
milliseconds, and the value of the
Reachable Timer field in RA
messages is 0.
c CAUTION: The maximum interval for sending RA messages should be less than or
equal to the router lifetime in RA messages. The minimum interval for sending RA
messages should be 0.75 times the maximum interval for sending RA messages or
less.
Configuring the Number An interface sends a neighbor solicitation (NS) message for DAD after acquiring an
of Attempts to Send an IPv6 address. If the interface does not receive a response within a specified time
NS Message for DAD (determined by the ipv6 nd ns retrans-timer command), it continues to send an
NS message. If it still does not receive a response after the number of attempts to

send an NS message reaches the maximum, the acquired address is considered

usable.
Follow these steps to configure the attempts to send an NS message for DAD:

interface-number
Configure the number of ipv6 nd dad attempts value Optional
attempts to send an NS
1 by default. When the value
message for DAD
argument is set to 0, DAD is
disabled.
Configuring PMTU
Discovery
Configuring the IPv6 routers do not support packet fragmentation. After an IPv6 router receives an
Interface MTU IPv6 packet, if the packet size is greater than the MTU of the forwarding interface,
the router will discard the packet. Meanwhile, the router sends the MTU to the
source host through an ICMPv6 packet - Packet Too Big message. The source host
fragments the packet according to the MTU and resends it. To reduce the extra
flow overhead resulting from packets being discarded, a proper interface MTU
should be configured according to the actual networking environment.
Follow these steps to configure the interface MTU:

interface-number
Configure the interface MTU ipv6 mtu mtu-size Optional
1,500 bytes by default.
Configuring a Static You can configure a static PMTU for a specified destination IPv6 address. When a
PMTU for a Specified source host sends packets through an interface, it compares the interface MTU
IPv6 Address with the static PMTU of the specified destination IPv6 address. If the packet size is
larger than the smaller one between the two values, the host fragments the
packet according to the smaller value.
Follow these steps to configure a static PMTU for a specified address:

Configure a static PMTU for a ipv6 pathmtu ipv6-address Required
specified IPv6 address [ value ]
By default, no static PMTU is
configured.

Configuring IPv6 TCP Properties 671
Configuring the Aging After the MTU of the path from the source host to the destination host is
Time for PMTU dynamically determined (refer to “IPv6 PMTU Discovery” on page 663), the source
host sends subsequent packets to the destination host on basis of this MTU. After
the aging time expires, the dynamically determined PMTU is removed and the
source host re-determines an MTU to send packets through the PMTU mechanism.
The aging time is invalid for static PMTU.
Follow these steps to configure the aging time for PMTU:

Configure aging time for ipv6 pathmtu age age-time Optional
PMTU
10 minutes by default.
Configuring IPv6 TCP The TCP properties you can configure include:
Properties ■ synwait timer: When a SYN packet is sent, the synwait timer is triggered. If no
response packet is received before the synwait timer expires, the TCP
connection establishment fails.
■ finwait timer: When the TCP connection status is FIN_WAIT_2, the finwait
timer is triggered. If no packet is received before the finwait timer expires, the
TCP connection is terminated. If a FIN packet is received, the TCP connection
status becomes TIME_WAIT. If other packets are received, the finwait timer is
reset from the last received packet and the connection is terminated after the
finwait timer expires.
■ Size of the IPv6 TCP sending/receiving buffer.
Follow these steps to configure TCP properties:

Set the finwait timer of TCP tcp ipv6 timer fin-timeout Optional
packets wait-time
Set the synwait timer of TCP tcp ipv6 timer syn-timeout Optional
packets wait-time
Set the size of the TCP tcp ipv6 window size Optional
sending/receiving buffer
8 KB by default
Configuring IPv6 With the caching function of IPv6 FIB enabled, the device searches the FIB cache
FIB-Based Forwarding when forwarding packets, thus reducing the time in searching IP packets and
improving the forwarding efficiency.
In the load sharing mode of IPv6 FIB, the device can decide how to select an equal
cost multi-path (ECMP) route to forward packets. Currently, two load sharing
modes are supported:

■ Load sharing based on the HASH algorithm: A certain algorithm based on the
source IPv6 address and destination IPv6 address is adopted to select an ECMP
route to forward packets.
■ Load sharing based on polling: Each ECMP route is used in turn to forward
packets.
Follow these steps to configure the IPv6 FIB-based forwarding:

Enable the caching function of IPv6 ipv6 fibcache Required
FIB
Disabled by default
Configure Configure the load ipv6 Optional
the IPv6 FIB sharing based on fib-loadbalance-type
By default, the load sharing
load sharing the HASH algorithm hash-based
based on polling is
mode
Configure the load undo ipv6 adopted, that is, each
sharing based on fib-loadbalance-type ECMP route is used in turn
polling hash-based to forward packets.
Configuring ICMPv6
Packet Sending
Configuring the If too many ICMPv6 error packets are sent within a short time in a network,
Maximum ICMPv6 Error network congestion may occur. To avoid network congestion, you can control the
Packets Sent in an maximum number of ICMPv6 error packets sent within a specified time, currently
Interval by adopting the token bucket algorithm.
You can set the capacity of a token bucket, namely, the number of tokens in the
bucket. In addition, you can set the update period of the token bucket, namely,
the interval for updating the number of tokens in the token bucket to the
configured capacity. One token allows one ICMPv6 error packet to be sent. Each
time an ICMPv6 error packet is sent, the number of tokens in a token bucket
decreases by one. If the number of ICMPv6 error packets successively sent exceeds
the capacity of the token bucket, subsequent ICMPv6 error packets cannot be sent
out until the number of tokens in the token bucket is updated and new tokens are
added to the bucket.
Follow these steps to configure the capacity and update period of the token
bucket:


Configuring IPv6 DNS 673

Configure the capacity ipv6 icmp-error { bucket Optional
and update period of bucket-size | ratelimit
By default, the capacity of a token
the token bucket interval } *
bucket is 10 and the update period is
100 milliseconds. That is, at most 10
IPv6 ICMP error packets can be sent
within these 100 milliseconds.
The update period “0” indicates that
the number of ICMPv6 error packets
sent is not restricted.
Enable Sending of If hosts are capable of replying multicast echo requests, Host A can attack Host B
Multicast Echo Replies by sending an echo request with the source being Host B to a multicast address,
then all the hosts in the multicast group will send echo replies to Host B.
Therefore, to prevent such an attack, a device is disabled from replying multicast
echo requests by default.
Follow these steps to enable sending of multicast echo replies:

Enable sending of multicast ipv6 icmpv6 Required
echo replies multicast-echo-reply
enable
Configuring IPv6 DNS
Configuring Static IPv6 Configuring static IPv6 domain name resolution is to establish the mapping
Domain Name between host name and IPv6 address. When applying such applications as Telnet,
Resolution you can directly use a host name and the system will resolve the host name into an
IPv6 address. Each host name can correspond to only one IPv6 address.
Follow these steps to configure static IPv6 domain name resolution:

Configure a host name and the ipv6 host hostname ipv6-address Required
corresponding IPv6 address
Configuring Dynamic You can use the following command to enable the dynamic domain name
IPv6 Domain Name resolution function. In addition, you should configure a DNS server so that a query
Resolution request message can be sent to the correct server for resolution. The system can
support at most six DNS servers.
You can configure a DNS suffix so that you only need to enter part of a domain
name and the system can automatically add the preset suffix for address
resolution. The system can support at most 10 DNS suffixes.
Follow these steps to configure dynamic IPv6 domain name resolution:


Enable the dynamic dns resolve Required
domain name resolution
function
Configure an IPv6 DNS dns server ipv6 Required
server ipv6-address
If the IPv6 address of the DNS
[ interface-type
server is a link-local address, you
interface-number ]
need to specify a value for
interface-type and
interface-number.
Configure the DNS suffix. dns domain domain-name Required
By default, no domain name suffix
is configured, that is, the domain
name is resolved according to the
input information.
n The dns resolve and dns domain commands are the same as those of IPv4 DNS.
For details about the commands, refer to “DNS Configuration” on page 609.
Displaying and
Maintaining IPv6 To do... Use the command... Remarks
Basics Configuration Display DNS suffix information display dns domain [ dynamic ] Available in
any view
Display IPv6 dynamic domain name display dns ipv6 dynamic-host
cache information.
Display IPv6 DNS server display dns ipv6 server [ dynamic ]
information
Display the IPv6 FIB entries display ipv6 fib [ ipv6-address ]
Display the total number of routes display ipv6 fibcache
in the IPv6 FIB cache
Display the mappings between display ipv6 host
host names and IPv6 addresses in
the static DNS database
Display the IPv6 information of an display ipv6 interface [ brief ]
interface [ interface-type [interface-number ] ]
Display neighbor information display ipv6 neighbors { ipv6-address |
all | dynamic | interface interface-type
interface-number | static | vlan vlan-id }
[ | { begin | exclude | include } string ]
Display the total number of display ipv6 neighbors { all | dynamic |
neighbor entries satisfying the interface interface-type
specified conditions interface-number | static | vlan vlan-id }
count
Display the PMTU information of display ipv6 pathmtu { ipv6-address |
an IPv6 address all | dynamic | static }
Display information related to a display ipv6 socket [ socktype
specified socket socket-type ] [ task-id socket-id ]
Display the statistics of IPv6 display ipv6 statistics
packets and ICMPv6 packets
Display the IPv6 TCP connection display tcp ipv6 statistics
statistics


Display the IPv6 TCP connection display tcp ipv6 status Available in
status any view
Display the IPv6 UDP connection display udp ipv6 statistics
statistics
Clear IPv6 dynamic domain name reset dns ipv6 dynamic-host Available in
cache information user view
Clear FIB cache entries reset ipv6 fibcache
Clear IPv6 neighbor information reset ipv6 neighbors { all | dynamic |
interface-number | static }
Clear the corresponding PMTU reset ipv6 pathmtu { all | static |
dynamic}
Clear the statistics of IPv6 and reset ipv6 statistics
ICMPv6 packets
Clear all IPv6 TCP connection reset tcp ipv6 statistics
statistics
Clear the statistics of all IPv6 UDP reset udp ipv6 statistics
packets
n The display dns domain command is the same as the one of IPv4 DNS. For
details about the commands, refer to “DNS Configuration” on page 609.
IPv6 Configuration Network requirements

Example Two routers are directly connected through Ethernet interfaces. Different types of
IPv6 addresses are configured for the interfaces to verify the connectivity between
the routers. The IPv6 prefix in the EUI-64 format is 2001::/64, the aggregatable
global unicast address of Router A is 3001::1/64 and 4001::1/64, and that of
Router B is 3001::2/64.
Network diagram
Figure 199 Network diagram for IPv6 address configuration (on routers)
Router A Router B
Eth1 /0 Eth1/0
■ Configuration on Router A
# Enable the IPv6 packet forwarding function.
[RouterA] ipv6
# Configure interface Ethernet 1/0 to automatically generate a link-local address.

[RouterA-Ethernet1/0] ipv6 address auto link-local
# Configure an EUI-64 address for interface Ethernet 1/0.

[RouterA-Ethernet1/0] ipv6 address 2001::/64 eui-64
# Assign an aggregatable global unicast address for interface Ethernet 1/0.
[RouterA-Ethernet1/0] ipv6 address 3001::1/64

[RouterA-Ethernet1/0] ipv6 address 4001::1/64
# Allow interface Ethernet 1/0 to advertise RA messages.
[RouterA-Ethernet1/0] undo ipv6 nd ra halt

Enable the IPv6 packet forwarding function.
[RouterB] ipv6
# Configure interface Ethernet 1/0 to automatically generate a link-local address.

[RouterB-Ethernet1/0] ipv6 address auto link-local
# Configure an EUI-64 address for Ethernet 1/0.
[RouterB-Ethernet1/0] ipv6 address 2001::/64 eui-64
# Assign an aggregatable global unicast address for interface Ethernet 1/0.
[RouterB-Ethernet1/0] ipv6 address 3001::2/64
# Enable the stateless address autoconfiguration function on Ethernet 1/0.
[RouterB-Ethernet1/0] ipv6 address auto
Verification
# Display the IPv6 information of the interface on Router A.
[RouterA-Ethernet1/0] display ipv6 interface ethernet 1/0
Ethernet1/0 current state :UP
Line protocol current state :UP
IPv6 is enabled, link-local address is FE80::20F:E2FF:FE00:1024
Global unicast address(es):
2001::20F:E2FF:FE00:1024, subnet is 2001::/64
3001::1, subnet is 3001::/64
4001::1, subnet is 4001::/64
Joined group address(es):
FF02::1:FF00:1
FF02::1:FF00:0
FF02::1:FF00:1024
FF02::2
FF02::1
MTU is 1500 bytes
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND retransmit interval is 1000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds

ND router advertisements are sent every 600 seconds

ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses
# Display the IPv6 information of the interface on Router B.
[RouterB-Ethernet1/0] display ipv6 interface ethernet 1/0

Ethernet1/0 current state :UP
IPv6 is enabled, link-local address is FE80::20F:E2FF:FE00:2
2001::20F:E2FF:FE00:2, subnet is 2001::/64
3001::2, subnet is 3001::/64
4001::20F:E2FF:FE00:2, subnet is 4001::/64 [AUTOCFG]
[valid lifetime 4641s/preferred lifetime 4637s]
FF02::1:FF00:0
FF02::1:FF00:2
FF02::2
FF02::1
MTU is 1500 bytes
ND DAD is enabled, number of DAD attempts: 1
# From Router A, ping the link-local address, EUI-64 address, aggregatable global
unicast address, and automatically generated address of Router B. If the
configurations are correct, the above four types of IPv6 addresses can be pinged.
c CAUTION: When you ping a link-local address, you should use the “-i” parameter
to specify an interface for the link-local address.
<RouterA-Ethernet1/0> ping ipv6 FE80::20F:E2FF:FE00:2 -i ethernet 1/0
PING FE80::20F:E2FF:FE00:2 : 56 data bytes, press CTRL_C to break
Reply from FE80::20F:E2FF:FE00:2
bytes=56 Sequence=1 hop limit=64 time = 4 ms
--- FE80::20F:E2FF:FE00:2 ping statistics ---
0.00% packet loss
<RouterA-Ethernet1/0> ping ipv6 2001::20F:E2FF:FE00:2
PING 2001::20F:E2FF:FE00:2 : 56 data bytes, press CTRL_C to break
Reply from 2001::20F:E2FF:FE00:2

--- 2001::20F:E2FF:FE00:2 ping statistics ---

0.00% packet loss
<RouterA-Ethernet1/0> ping ipv6 3001::2
PING 3001::2 : 56 data bytes, press CTRL_C to break
Reply from 3001::2
Reply from 3001::2
Reply from 3001::2
Reply from 3001::2
Reply from 3001::2
--- 3001::2 ping statistics ---

0.00% packet loss
[RouterA-Ethernet1/0] ping ipv6 4001::20F:E2FF:FE00:2
PING 4001::20F:E2FF:FE00:2 : 56 data bytes, press CTRL_C to break
--- 4001::20F:E2FF:FE00:2 ping statistics ---

0.00% packet loss
Troubleshooting IPv6 Symptom

Basics Configuration The peer IPv6 address cannot be pinged.
Solution
■ Carry out the display current-configuration command in any view or the
display this command in system view to check that the IPv6 packet
forwarding function is enabled.
■ Carry out the display ipv6 interface command in any view to check that the
IPv6 address of the interface is correct and that the interface is up.
■ Carry out the debugging ipv6 packet command in user view to enable the
debugging for IPv6 packets and make judgment according to the debugging
information.

NAT-PT CONFIGURATION
47
When configuring NAT-PT, go to these sections for information you are interested
in:
■ “NAT-PT Overview” on page 679
■ “Configuring NAT-PT” on page 681
■ “Displaying and Maintaining NAT-PT” on page 686
■ “NAT-PT Configuration Example” on page 687
■ “Troubleshooting NAT-PT” on page 690
NAT-PT Overview The IPv6 application is a gradual process in which IPv4 networks and IPv6
networks will co-exist to communicate with each other for a long period of time.
The Network Address Translation - Protocol Translation (NAT-PT) realizes translation
between IPv4 and IPv6 addresses, implementing communications between IPv4
and IPv6 networks. For example, it can enable a host in an IPv6 network to access
the FTP server in an IPv4 network.
As shown in Figure 200, NAT-PT runs on the device on the border between IPv4
and IPv6 networks. The NAT-PT process is implemented on the device, which is
transparent to both IPv4 and IPv6 networks. Users between IPv6 networks and
IPv4 networks can communicate, without any change to host configurations of
the existing IPv4 networks.
Figure 200 Network diagram for NAT-PT
IPv4 host NAT -PT IPv6 host
In view of the following limitations, NAT-PT is not recommended in some

applications (for example, tunneling is recommended in the case where an IPv6
host needs to communicate with another IPv6 host across an IPv4 network).
■ The request and response packets of a same session must be translated by the
same NAT-PT device.
■ The Options field in the IPv4 packet header cannot be translated.
■ NAT-PT does not provide end-to-end security.
Currently, NAT-PT supports ICMP, DNS, FTP, and other protocols that employ the
network layer protocol but have no address information in the protocol messages.
To get more information about NAT-PT, go to these topics:

680 CHAPTER 47: NAT-PT CONFIGURATION
■ “NAT-PT Mechanism” on page 680

■ “Implementing NAT-PT” on page 680
NAT-PT Mechanism There are three NAT-PT mechanisms to realize the translation between IPv4 and
IPv6 addresses: “Static NAT-PT mapping” on page 680, “Dynamic NAT-PT
mapping” on page 680, and “NAPT-PT” on page 680.
Static NAT-PT mapping

Static NAT-PT mapping means that translation between IPv6 and IPv4 addresses is
realized by using the one-to-one relationship manually configured between IPv6
addresses and IPv4 addresses.
Dynamic NAT-PT mapping

Different from static mapping, dynamic mapping does not provide the one-to-one
relationship between IPv6 addresses and IPv4 addresses.
For a dynamic mapping, an address pool needs to be created first. After that, an
available address is assigned from the address pool to accomplish the mapping
between one IPv6 address and one IPv4 address.
NAPT-PT
Network address port translation - protocol translation (NAPT-PT) realizes the IPv6
to IPv4 translation for TCP/UDP port numbers based on dynamic IP address
translation. With NAPT-PT, different IPv6 addresses can correspond to one IPv4
address. Different IPv6 hosts are distinguished by different port numbers so that
these IPv6 hosts can share one IPv4 address to accomplish the address translation.
Implementing NAT-PT Session initiated by an IPv6 host:
Figure 201 NAT-PT implementation (session initiated by an IPv6 host)
IPv4: 8.0.0.2 IPv6: 3001::5

IPv6: 3001:2 IPv4: 8.0.0.5
IPv4 host NAT- PT IPv6 host

Source: 8.0.0.5 Source: 3001 ::5
Destination: 8.0.0.2 Destination: 3001 ::2
Source: 8.0.0.2 Source: 3001 ::2

Destination: 8.0.0.5 Destination: 3001 ::5
The NAT-PT implementation process for a session initiated by an IPv6 host is as

follows:
1 A packet from an IPv6 host to an IPv4 host reaches the NAT-PT device. The NAT-PT
device translates the source IPv6 address of the packet into an IPv4 address
according to the static or dynamic IPv6-to-IPv4 mappings.
2 The NAT-PT device translates the destination address of the packet into an IPv4
address according to the IPv4-to-IPv6 mapping, if configured, on the IPv4 network
side. Without any mapping configured on the IPv4 network side, if the least
significant 32 bits of the destination IPv6 address in the packet can be directly

NAT-PT Configuration Task List 681
translated into a valid IPv4 address, the destination IPv6 address is translated into
an IPv4 address. Otherwise, the translation fails.
3 After the source and destination IPv6 addresses of the packet are translated into
IPv4 addresses, the NAT-PT device forwards the packet to an IPv4 host. Meanwhile,
the IPv6-to-IPv4 address mappings are stored in the NAT-PT device.
4 After packets originated from the IPv4 host to the IPv6 host arrive at the NAT-PT,
they swap the source and destination IPv4 addresses according to the stored
mappings to forward the packets to the IPv6 host.
Session initiated by an IPv4 host:

The NAT-PT implementation process for a session initiated by an IPv4 host is as
follows:
1 A packet from an IPv4 host to an IPv6 host reaches the NAT-PT device. The NAT-PT
device translates the source IPv4 address of the packet into an IPv6 address
according to the static or dynamic IPv4-to-IPv6 mappings.
2 The NAT-PT device translates the destination IPv4 address of the packet into an
IPv6 address according to the IPv6-to-IPv4 mapping on the IPv6 network side.
3 After the source and destination IPv4 addresses of the packet are translated into
IPv6 addresses, the NAT-PT device forwards the packet to the IPv6 host.
Meanwhile, the IPv4-to-IPv6 address mapping is stored in the NAT-PT device.
4 After packets originated from the IPv6 host to the IPv4 host arrive at the NAT-PT,
they swap the source and destination IPv6 addresses according to the stored
mapping to forward the response packet to the IPv4 host.
Protocols and Standards ■ RFC 2765: Stateless IP/ICMP Translation Algorithm

■ RFC 2765: Network Address Translation - Protocol Translation (NAT-PT)
NAT-PT Configuration To configure the NAT-PT feature, complete the tasks in the following sections:
Task List
Task Remarks
“Enabling NAT-PT” on page 682 Required
“Configuring a NAT-PT Prefix” on page 682 Optional
“Configuring Mappings for IPv4 Hosts Accessing IPv6 Hosts” on page Required
682
“Configuring Mappings for IPv6 Hosts Accessing IPv4 Hosts” on page Required
683
“Configuring the NAT-PT Session Timeout Time for Different Protocol Optional
“Configuring the Maximum Number of Sessions” on page 686 Optional
“Configuring the ToS/Traffic Class Field in a Packet After NAT-PT” on Optional
page 686
Configuring NAT-PT
Configuration Before implementing NAT-PT, you must enable the IPv6 forwarding function on the
Prerequisites device and configure an IPv4 or IPv6 address as required on the interface that
requires NAT-PT.

Enabling NAT-PT Follow these steps to enable NAT-PT:

interface-number
Enable NAT-PT natpt enable Required.
Disabled by default
Configuring a NAT-PT A NAT-PT prefix is used for configuring dynamic IPv4-to-IPv6 and IPv6-to-IPv4
Prefix mappings.
You can configure such a dynamic IPv6-to-IPv4 mapping rule as follows:
When a packet is sent from an IPv6 network to an IPv4 network, the NAT-PT device
receiving the packet will detect the prefix of the destination IPv6 address of the
packet. An IPv6-to-IPv4 translation will be performed only when the prefix is the
same as the configured one.
For dynamic IPv4-to-IPv6 mappings, if the source IPv4 address complies with the
specified ACL rule, a NAT-PT prefix will be added to translate the source IPv4
address into an IPv6 address.
Follow these steps to configure a NAT-PT prefix:

Configure a NAT-PT natpt prefix natpt-prefix [ interface Required
prefix interface-type interface-number [ nexthop
ipv4-address ] ]
c CAUTION:
■ The NAT-PT prefix must not be the same as the network address of the NAT-PT
enabled interface on the IPv6 network.
■ To delete a NAT-PT prefix that has been referenced by another command, you
need to cancel the reference configuration first.
Configuring Mappings Mappings for IPv4 hosts accessing IPv6 hosts refer to the IPv4-to-IPv6 NAT of
for IPv4 Hosts Accessing packets. When a packet is sent from an IPv4 network to an IPv6 network, the
IPv6 Hosts source IPv4 address is translated to an IPv6 address in accordance with the
configured mappings.
There are static and dynamic mappings for IPv4 hosts to access IPv6 hosts.
■ A static IPv4-to-IPv6 mapping is used to translate a source IPv4 address into a

corresponding IPv6 address.
■ A dynamic IPv4-to-IPv6 mapping means that if the source IPv4 address
complies with the specified ACL rule, a NAT-PT prefix will be added to translate
the source IPv4 address into an IPv6 address.

Follow these steps to configure mappings for IPv4 hosts accessing IPv6 hosts:
Use the
Configure Configure static mappings natpt v4bound Configure either
mappings for IPv4 for IPv4 hosts accessing IPv6 static { ipv4-address static mappings or
hosts accessing hosts ipv6-address | dynamic mappings
IPv6 hosts v6server protocol
protocol-type
ipv4-address
ipv4-port-number
ipv6-address
ipv6-port-number }
Configure dynamic natpt v4bound
mappings for IPv4 hosts dynamic acl
accessing IPv6 hosts number acl-number
prefix natpt-prefix
n ■ The natpt-prefix argument specified in the natpt v6bound dynamic prefix

natpt-prefix interface interface-type interface-number command must have
been configured with the natpt prefix command.
■ For ACL configuration, refer to “Configuring ACLs” on page 1881.
Configuring Mappings Mappings for IPv6 hosts accessing IPv4 hosts refer to the IPv6-to-IPv4 NAT of
for IPv6 Hosts Accessing packets. When a packet is sent from an IPv6 network to IPv4 network, the source
IPv4 Hosts IPv6 address is translated to an IPv4 address in accordance with the configured
mappings.
There are static and dynamic mappings for IPv6 hosts accessing IPv4 hosts.
■ A static IPv6-to-IPv4 mapping is used to translate a source IPv6 address into a

corresponding IPv4 address.
■ A dynamic IPv6-to-IPv4 mapping means that if the source IPv6 address
complies with the rule of an IPv6 ACL or the destination IPv6 address contains a
NAT-PT prefix, the source IPv6 address will be translated into an IPv4 address in
the specified NAT-PT address pool or an IPv4 address of the specified interface.
The device provides four types of dynamic mappings.
■ Combination 1: Combination of an IPv6 ACL with an address pool
If the source IPv6 address of a packet matches the specified IPv6 ACL, the source
IPv6 address will be translated into an IPv4 address of the specified address pool.
■ Combination 2: Combination of an IPv6 ACL with an interface address
If the source IPv6 address of a packet matches the specified IPv6 ACL, the source
IPv6 address will be translated into an IPv4 address of the specified interface.
■ Combination 3: Combination of a NAT-PT prefix with an address pool
If the destination IPv6 address of a packet contains a NAT-PT prefix, the source IPv6
address will be translated into an IPv4 address of the specified address pool.

■ Combination 4: Combination of a NAT-PT prefix with an interface address
If the destination IPv6 address of a packet contains a NAT-PT prefix, the source IPv6
address will be translated into an IPv4 address of the specified interface.
If combination 1 or combination 3 is used to configure dynamic mappings for IPv6

hosts accessing IPv4 hosts, you need to configure a NAT-PT address pool.
A NAT-PT address pool is a group of successive IPv4 addresses and is used to

translate an IPv6 packet into an IPv4 packet dynamically. When an IPv6 packet is
sent from an IPv6 network to an IPv4 network, if the dynamic NAT-PT of
combination 1 or 3 is set, the NAT-PT device will select an IPv4 address from the
NAT-PT address pool as the source IPv4 address of the IPv6 packet.
Follow these steps to configure mappings for IPv6 hosts accessing IPv4 hosts:

Configure static or Configure static natpt v6bound Use either static
dynamic mappings mappings for IPv6 hosts static ipv6-address mappings or dynamic
for IPv6 hosts accessing IPv4 hosts ipv4-address mappings.
accessing IPv4
Configure dynamic See the table below.
hosts
mappings for IPv6 hosts
accessing IPv4 hosts
Follow these steps to configure dynamic mapping for IPv6 hosts accessing IPv4
hosts:


Configure a NAT-PT address pool and natpt address-group Configure
define a dynamic IPv6-to-IPv4 mapping rule group-number start-ipv4-address any of the
as follows: end-ipv4-address four types of
dynamic
If the source IPv6 address of an IPv6 packet natpt v6bound dynamic acl6
mappings.
matches the specified IPv6 ACL rule, the number acl-number
source IPv6 address will be translated into address-group address-group
an IPv4 address of the specified address [ no-pat ]
pool.
Define a dynamic IPv6-to-IPv4 mapping natpt v6bound dynamic acl6
rule as follows: number acl-number interface
If the source IPv6 address of an IPv6 packet
matches the specified IPv6 ACL rule, the
source IPv6 address will be translated into
an IPv4 address of the specified interface.
Configure a NAT-PT address pool and natpt address-group
define a dynamic IPv6-to-IPv4 mapping rule group-number start-ipv4-address
as follows: end-ipv4-address
If the destination IPv6 address of an IPv6 natpt v6bound dynamic prefix
packet contains a NAT-PT prefix, the source natpt-prefix address-group
IPv6 address will be translated into an IPv4 address-group [ no-pat ]
address of the specified address pool.
Define a dynamic IPv6-to-IPv4 mapping natpt v6bound dynamic prefix
rule as follows: natpt-prefix interface
If the destination IPv6 address of an IPv6
packet contains the NAT-PT prefix, the
source IPv6 address will be translated into
an IPv4 address of the specified interface.
n ■ The natpt-prefix argument specified in the natpt v6bound dynamic prefix

natpt-prefix interface interface-type interface-number command must have
been configured with the natpt prefix command.
■ For ACL configuration, refer to “Configuring ACLs” on page 1881.
Configuring the NAT-PT You can set the timeout time for NAT-PT sessions of different protocol packets
Session Timeout Time according to the actual conditions. NAT-PT will stop after the NAT-PT session of a
for Different Protocol specified protocol packet times out.
Packets
Follow these steps to configure NAT-PT session timeout time for different protocol
packets:



Configure the NAT-PT natpt aging-time Required
session timeout time for { default | { dns | finrst |
The defaults are as follows:
different protocol frag | icmp | syn | tcp |
packets udp } time-value } 10 seconds for a DNS packet,
5 seconds for a FINRST packet,
5 seconds for a FRAG packet,
20 seconds for a ICMP packet,
240 seconds for a SYN packet,
40 seconds for a UDP packet, and
86400 seconds for a TCP packet
Configuring the You can set the maximum number of concurrent sessions that the system allows.
Maximum Number of When the number of concurrent sessions reaches the maximum number, no new
Sessions session will be established any longer.
Follow these steps to configure the maximum number of sessions:

Configure the maximum natpt max-session Required
number of NAT-PT sessions max-number
2,048 by default
Configuring the You can set the ToS/Traffic Class field in packets after NAT-PT to 0 or to the value
ToS/Traffic Class Field in of the corresponding Traffic Class/ToS field in packets before NAT-PT.
a Packet After NAT-PT
Follow these steps to set the ToS and Traffic Class fields in packets after NAT-PT:

Set the Traffic Class field in natpt turn-off traffic-class Required
IPv6 packets translated from
Same as that of the ToS field
IPv4 packets to 0.
in IPv4 packets by default.
Set the ToS field in IPv4 natpt turn-off tos Required
packets translated from IPv6
Same as that of the Traffic
packets to 0.
Class field in IPv6 packets by
default.
Displaying and
Maintaining NAT-PT To do... Use the command... Remarks
Display all NAT-PT configuration display natpt all Available in any view
information
Display the configuration display natpt Available in any view
information of a NAT-PT address address-group
pool
Display the static and dynamic display natpt Available in any view
NAT-PT address mappings address-mapping


Display the NAT-PT session timeout display natpt aging-time Available in any view
time
Display the NAT-PT fragment display natpt Available in any view
session information frag-sessions
Display the dynamic NAT-PT display natpt session { all Available in any view
session information. | icmp | tcp | udp }
Display NAT-PT statistics display natpt statistics Available in any view
information.
Clear dynamic NAT-PT address reset natpt Available in user view
mappings. dynamic-mappings
Clear all NAT-PT statistics reset natpt statistics Available in user view
information
Available in user view
NAT-PT Configuration
Example
Configuring Dynamic Network requirements

IPv6-to-IPv4 Mappings An IPv4 network is connected to an IPv6 network through a NAT-PT device -
Router B. Dynamic IPv6-to-IPv4 mappings are configured on Router B so that IPv6
hosts can access IPv4 hosts but IPv4 hosts cannot access IPv6 hosts.
Network diagram
Figure 202 Network diagram for dynamic IPv6-to-IPv4 mapping configuration

S2/ 0 S 2/0
8.0 .0. 2/ 24 2001::2/64
S 2/0 S 2/1
8 . 0. 0.1 /24 2001 ::1 /64
IPv4 network IPv 6 network
■ Configure Router A in the IPv4 network
■ Configure Router C in the IPv6 network
[RouterC] ipv6
[RouterC-Serial2/0] ipv6 address 2001::2/64
# Configure a default route to Router B.
[RouterC] ipv6 route-static 3001:: 16 2001::1


# Configure an interface address and enable NAT-PT on the interface.
[RouterB] ipv6
[RouterB-Serial2/0] natpt enable
[RouterB-Serial2/1] ipv6 address 2001::1/64
# Configure a NAT-PT prefix.
[RouterB] natpt prefix 3001::
# Configure a NAT-PT address pool.
[RouterB] natpt address-group 1 8.0.0.10 8.0.0.19
# Configure dynamic mappings for IPv6 hosts accessing IPv4 hosts.
[RouterB] natpt v6bound dynamic prefix 3001:: address-group 1
Verification
If you carry out the ping ipv6 3001::0800:0002 command on Router C after
completing the configurations above, you should receive a response packet.
At this time, you can see on Router B the established NAT-PT session.
[RouterB] display natpt session all
NATPT Session Info:

No IPV6Source IPV4Source Pro
IPV6Destination IPV4Destination
1 2001::0002 ^57259 8.0.0.19 ^12288 ICMP
3001::0800:0002 ^ 0 8.0.0.2 ^ 0
Configuring Static Network requirements

IPv4-to-IPv6 and An IPv4 network is connected to an IPv6 network through a NAT-PT device -
IPv6-to-IPv4 Mappings Router B. Static IPv4-to-IPv6 and IPv6-to-IPv4 mappings configured on Router B so
that the IPv4 and IPv6 networks can access each other.
Network diagram
Figure 203 Network diagram for NAT-PT (static IPv4-to-IPv6 and IPv6-to-IPv4 mappings)
Router B
Router A S2/ 0 S 2/0 Router C
8.0 .0. 2/ 24 2001::2 /64
S 2/0 S 2/1
8 .0. 0.1 /24 2001 ::1 /64
IPv4 network IPv6 network

■ Configure Router A in the IPv4 network
[RouterA] ip route-static 0.0.0.0 0 serial 2/0
■ Configure Router C in the IPv6 network
[RouterC] ipv6
[RouterC-Serial2/0] ipv6 address 2001::2/64
[RouterC] ipv6 route-static :: 0 serial 2/0
# Configure an interface address and enable NAT-PT on the interface.
[RouterB] ipv6
[RouterB-Serial2/1] ipv6 address 2001::1/64
# Configure a NAT-PT prefix.
[RouterB] natpt prefix 3001::
# Configure a static IPv4-to-IPv6 mapping.
[RouterB] natpt v4bound static 8.0.0.2 3001::5
# Configure a static IPv6-to-IPv4 mapping.
[RouterB] natpt v6bound static 2001::2 8.0.0.5
Verification
After the above configurations, using the ping 8.0.0.5 command on Router A can
receive responses, and you can view the following NAT-PT session information on
Router B using the display command.
NATPT Session Info:
1 3001::0005 ^ 0 8.0.0.2 ^ 0 ICMP
2001::0002 ^ 0 8.0.0.5 ^ 0
Using the ping ipv6 3001::5 command on Router C can receive response packets,
and you can view the following NAT-PT session information on Router B using the
display command.


NATPT Session Info:
1 2001::0002 ^ 0 8.0.0.5 ^ 0 ICMP
3001::0005 ^ 0 8.0.0.2 ^ 0
NAT-PT NAT-PT is abnormal.
Solution:
■ Enable debugging for NAT-PT.
■ Locate the fault according to the debugging information of the device, and
then make further judgments by using other commands. During debugging,
check whether the source address of a packet is translated correctly. If not, it is
possible that the address pool is configured incorrectly.

DUAL STACK CONFIGURATION
48
When configuring dual stack, go to these sections for information you are
interested in:
■ “Dual Stack Overview” on page 691
■ “Configuring Dual Stack” on page 691
Dual Stack Overview Dual stack is the most direct approach to making IPv6 nodes compatible with IPv4
nodes. The best way for an IPv6 node to be compatible with an IPv4 node is to
maintain a complete IPv4 stack. A network node that supports both IPv4 and IPv6
is called a dual stack node. A dual stack node configured with an IPv4 address and
an IPv6 address can have both IPv4 and IPv6 packets transmitted.
For an upper layer application supporting both IPv4 and IPv6, either TCP or UDP
can be selected at the transport layer, while IPv6 stack is preferred at the network
layer. Figure 204 illustrates the IPv4/IPv6 dual stack in relation to the IPv4 stack.
Figure 204 IPv4/IPv6 dual stack in relation to IPv4 stack (on Ethernet)
IPv4 application IPv4/IPv6 application
TCP UDP TCP UDP
IPv4 IPv4 IPv6

Protocol ID: Protocol ID: Protocol ID:
0x0800 0x0800 0x86DD
Ethernet Ethernet
IPv4 stack Dual stack
Configuring Dual You must enable the IPv6 packet forwarding function before dual stack.
Stack Otherwise, the device cannot forward IPv6 packets even if IPv6 addresses are
configured for interfaces.
Follow these steps to configure dual stack on a gateway:

Enable the IPv6 packet forwarding function ipv6 Required
Disabled by
default.

692 CHAPTER 48: DUAL STACK CONFIGURATION

interface-number
Configure an IPv4 address for the interface ip address ip-address Required
{ mask | mask-length }
By default, no IP
[ sub ]
address is
configured.
Configure an Configure Manually specify ipv6 address Use either
IPv6 address IPv6 an IPv6 address { ipv6-address command
on the global prefix-length |
By default, no
interface unicast ipv6-address/prefix-lengt
local address or
address or h}
global unicast
local
Configure an IPv6 ipv6 address address is
address
address in the ipv6-address/prefix-lengt configured on an
EUI-64 format h eui-64 interface
Configure Automatically ipv6 address auto Optional
IPv6 create an IPv6 link-local
By default, after
link-local link-local address
you configured an
address
Manually specify ipv6 address IPv6 local address
an IPv6 link-local ipv6-address link-local or global unicast
address address, a link
local address is
automatically
created.
c CAUTION: For more information about IPv6 address, refer to “Introduction to IPv6
Address” on page 657.

TUNNELING CONFIGURATION
49
When configuring tunneling, go to these sections for information you are
interested in:
■ “Introduction to Tunneling” on page 693
■ “Tunneling Configuration Task List” on page 700
■ “Configuring an IPv6 Manually Configured Tunnel” on page 700
■ “Configuring Automatic IPv4-Compatible IPv6 Tunnel” on page 704
■ “Configuring 6to4 Tunnel” on page 708
■ “Configuring ISATAP Tunnel” on page 714
■ “Configuring IPv4 over IPv4 Tunnel” on page 717
■ “Displaying and Maintaining Tunneling Configuration” on page 730
■ “Troubleshooting Tunneling Configuration” on page 730
n A tunnel interface number is in the X format, where X ranges from 0 to 1023.
Introduction to The expansion of Internet results in scarce IPv4 addresses. Although the
Tunneling technologies such as temporary IPv4 address allocation and network address
translation (NAT) relieve the problem of IPv4 address shortage to some extent, they
not only increase the overhead in address resolution and processing, but also lead
to high-level application failures. Furthermore, they will still face the problem that
IPv4 addresses will eventually be used up. Internet protocol version 6 (IPv6)
adopting the 128-bit addressing scheme completely solves the above problem.
Since significant improvements have been made in address space, security,
network management, mobility, and QoS, IPv6 becomes one of the core standards
for the next generation Internet protocol. IPv6 is compatible with all protocols
except IPv4 in the TCP/IP suite. Therefore, IPv6 can completely take the place of
IPv4.
Before IPv6 becomes the dominant protocol, the network using the IPv6 protocol
stack is expected to communicate with the Internet using IPv4. Therefore, an
IPv6-IPv4 interworking technology must be developed to ensure the smooth
transition from IPv4 to IPv6. In addition, the interworking technology should
provide efficient, seamless information transfer. The Internet Engineering Task
Force (IETF) set up the next generation transition (NGTRANS) working group to
study problems about IPv4-to-IPv6 transition and efficient, seamless IPv4-IPv6
interworking. Currently, multiple transition technologies and interworking

694 CHAPTER 49: TUNNELING CONFIGURATION
solutions are available. With their own characteristics, they are used to solve
communication problems in different transition stages under different
environments.
Currently, there are three major transition technologies: dual stack (RFC2893),
tunneling (RFC2893), and NAT-PT (RFC2766).
Tunneling is an encapsulation technology, which utilizes one network transport

protocol to encapsulate packets of another network transport protocol and
transfer them over the network. A tunnel is a virtual point-to-point connection. In
practice, a tunnel interface can be considered as a virtual interface that supports
only point-to-point connection. One tunnel provides one channel to transfer
encapsulated packets. Packets can be encapsulated and decapsulated at both
ends of a tunnel. Tunneling refers to the whole process from data encapsulation to
data transfer to data decapsulation.
n ■ For related configuration about the dual protocol stack, refer to “Dual Stack
■ For related configuration about NAT-PT, refer to “Configuring NAT-PT” on page
681.
■ In addition, the device supports IPv6 on the provider edge routers (6PE) - a
transition technology.
IPv6 over IPv4 Tunnel Principle

The IPv6 over IPv4 tunneling mechanism encapsulates an IPv4 header in IPv6 data
packets so that IPv6 packets can pass an IPv4 network through a tunnel to realize
interworking between isolated IPv6 networks, as shown in Figure 205.
c CAUTION: The devices at both ends of an IPv6 over IPv4 tunnel must support
IPv4/IPv6 dual stack.
Figure 205 Principle of IPv6 over IPv4 tunnel
IPv 4 header IPv 6 header IPv6 data

IPv 6 header IPv6 data IPv6 header IPv 6 data
IPv 4 network
IPv6 over IPv4 tunnel
Dual stack router Dual stack router
IPv 6 host IPv6 host
The IPv6 over IPv4 tunnel processes packets in the following way:
1 A host in the IPv6 network sends an IPv6 packet to the device at the source end of
the tunnel.
2 After determining according to the routing table that the packet needs to be
forwarded through the tunnel, the device at the source end of the tunnel

encapsulates an IPv4 header in the IPv6 packet and forwards it through the
physical interface of the tunnel.
3 The encapsulated packet goes through the tunnel to reach the device at the
destination end of the tunnel. The device at the destination end decapsulates the
packet if the destination address of the encapsulated packet is the device itself.
4 The device at the destination end of the tunnel forwards the packet according to
the destination address in the decapsulated IPv6 packet. If the destination address
is the device itself, the device at the destination end forwards the IPv6 packet to
the upper-layer protocol for processing.
Configured tunnel and automatic tunnel

An IPv6 over IPv4 tunnel can be established between hosts, between hosts and
devices, and between devices. The tunnel destination needs to forward packets if
the tunnel destination is not the eventual destination of the IPv6 packet.
According to the way the IPv4 address of the tunnel destination is acquired,
tunnels are divided into configured tunnel and automatic tunnel.
■ If the tunnel destination is not the eventual destination of the IPv6 packet, the
device at the destination end of the tunnel (usually a router) will decapsulate
the IPv6 packet and forward it to the eventual destination after the IPv6 packet
reaches the tunnel destination. In this case, the IPv4 address of the tunnel
destination cannot be acquired from the destination address of the IPv6 packet
and it needs to be configured manually. Such a tunnel is called configured
tunnel.
■ If the tunnel destination is just the eventual destination of the IPv6 packet, an
IPv4 address can be embedded into an IPv6 address so that the IPv4 address of
the tunnel destination can automatically be acquired from the destination
address of the IPv6 packet. Such a tunnel is called automatic tunnel.
Type
According to the way an IPv6 packet is encapsulated, IPv6 over IPv4 tunnels are
divided into the following types:
■ IPv6 manually configured tunnel
■ Automatic IPv4-compatible IPv6 tunnel
■ 6to4 tunnel
■ ISATAP tunnel
■ IPv6-over-IPv4 GRE tunnel (GRE tunnel for short)
Among the above tunnels, the IPv6 manually configured tunnel and GRE tunnel
are configured tunnels, while the automatic IPv4 compatible IPv6 tunnel, 6to4
tunnel, and intra-site automatic tunnel address protocol (ISATAP) tunnel are
automatic tunnels.
1 IPv6 manually configured tunnel
A manually configured tunnel is a point-to-point link. One link is a separate

tunnel. The IPv6 manually configured tunnel is mainly used for stable connections
requiring regular secure communication between two border routers or between a
border router and a host, or for connections to remote IPv6 networks.

2 Automatic IPv4-compatible IPv6 tunnel
An automatic IPv4-compatible IPv6 tunnel is a point-to-multipoint link.

IPv4-compatible IPv6 addresses are adopted at both ends of such a tunnel. The
address format is 0:0:0:0:0:0:a.b.c.d/96, where a.b.c.d represents an embedded
IPv4 address. The tunnel destination is automatically determined by the embedded
IPv4 address, which makes it easy to create a tunnel for IPv6 over IPv4. However,
an automatic IPv4-compatible IPv6 tunnel must use IPv4-compatible IPv6
addresses and it is still dependent on IPv4 addresses. Therefore, automatic
IPv4-compatible IPv6 tunnels have limitations.
3 6to4 tunnel
■ Ordinary 6to4 tunnel
An automatic 6to4 tunnel is a point-to-multipoint tunnel and is used to connect

multiple isolated IPv6 domains over an IPv4 network to remote IPv6 networks. The
embedded IPv4 address in an IPv6 address is used to automatically acquire the
destination of the tunnel. The automatic 6to4 tunnel adopts 6to4 addresses. The
address format is 2002:abcd:efgh:subnet number::interface ID/64, where
abcd:efgh represents the 32-bit source IPv4 address of the 6to4 tunnel, in
hexadecimal notation. For example, 1.1.1.1 can be represented by 0101:0101.
The tunnel destination is automatically determined by the embedded IPv4 address,
which makes it easy to create a 6to4 tunnel.
Since the 16-bit subnet number of the 64-bit address prefix in 6to4 addresses can
be customized and the first 48 bits in the address prefix are fixed by a permanent
value and the IPv4 address of the tunnel source or destination, it is possible that
IPv6 packets can be forwarded by the tunnel. A 6to4 tunnel interconnects IPv6
networks and overcomes the limitations of an automatic IPv4-compatible IPv6
tunnel.
■ 6to4 relay
A 6to4 tunnel can connect networks whose address prefix is 2002::/16. However,
IPv6 network addresses with the prefix such as 2001::/16 may also be used in IPv6
networks. In order for these addresses to be reachable, a 6to4 router must be used
as a gateway to forward packets to IPv6 networks. Such a router is called 6to4
relay router. As shown in Figure 206, a static route must be configured on the
border routers in the 6to4 network and the next-hop address must be the 6to4
address of the 6to4 relay router. In this way, all packets destined for the IPv6
network will be forwarded to the 6to4 relay router, and then to the IPv6 network.
Thus, interworking between the 6to4 network (with the address prefix starting
with 2002) and the IPv6 network is realized.

Figure 206 Principle of 6to4 tunnel and 6to4 relay
6to4 router
6to4 network
Site 2
l
t un ne Router B
6to4 router 6to 4
6to4 network IPv4 network

Site 1
Router A 6 to4
tu nn
el 6to4 relay
IPv6 network
Site 3
Router C
4 ISATAP tunnel
With the application of the IPv6 technology, there will be more and more IPv6
hosts in the existing IPv4 network. The ISATAP tunneling technology provides a
satisfactory solution for IPv6 application. An ISATAP tunnel is a point-to-point
automatic tunnel. The destination of a tunnel can automatically be acquired from
the embedded IPv4 address in the destination address of an IPv6 packet. When an
ISATAP tunnel is used, the destination address of an IPv6 packet and the IPv6
address of a tunnel interface both adopt special addresses: ISATAP addresses. The
ISATAP address format is prefix(64bit):0:5EFE:ip-address. The ip-address is in the
form of a.b.c.d or abcd:efgh, where abcd:efgh represents a 32-bit source IPv4
address. Through the embedded IPv4 address, an ISATAP tunnel can automatically
be created to transfer IPv6 packets. The ISATAP tunnel is mainly used for
connections between IPv6 routers or between a host and an IPv6 router in the IPv4
network.
Figure 207 Principle of ISATAP tunnel
IPv 4 address:
2 .1. 1. 1/ 24
IPv6 network IPv4 network IPv 6 address:
ISATAP tunnel FE80 ::5EFE: 0201 :0101
3 FFE::5 EFE:0201 : 0101
IPv6 host ISATAP router IPv4/IPv6 host
5 GRE tunnel
IPv6 packets can be carried over GRE tunnels to pass through the IPv4 network by
using standard GRE protocol to encapsulate them. Like the IPv6 manually
configured tunnel, a GRE tunnel is a point-to-point link, too. Each link is a separate
tunnel. The GRE tunnel is mainly used for stable connections requiring regular
secure communication between border routers or between a host and a border
router. For related configurations, refer to “GRE Configuration” on page 1589.
IPv4 over IPv4 Tunnel Introduction to IPv4 over IPv4 tunneling protocol
IPv4 over IPv4 tunneling protocol (RFC1853) is developed for IP data packet
encapsulation so that data can be transferred from one IPv4 network to another
IPv4 network.

Encapsulation and decapsulation

Packets to be transferred through a tunnel undergo an encapsulation process and
decapsulation process. Figure 208 shows these two processes.
Figure 208 Principle of IPv4 over IPv4 tunnel
IPv 4 header IPv 4 header IPv4 data

IPv 4 header IPv4 data IPv4 header IPv 4 data
IPv 4 network
IPv4 tunnel
Router A Router B
IPv 4 host IPv 4 host

■ Encapsulation
The encapsulation process is as follows:
1 The interface of Router A connecting to an IPv4 host receives an IP packet and

submits it to the IP protocol stack for processing.
2 The IP protocol stack determines how to route the packet according to the
destination address in the IP header. If the destination of the packet the IPv4 host
connected to Router B, the packet is sent to Router A’s tunnel interface that is
connected to Router B.
3 After the tunnel interface receives the packet, the packet is encapsulated and
submitted to the IP protocol stack for processing. The IP protocol stack determines
the outgoing interface of the tunnel according to the IP header.
■ Decapsulation
Contrary to the encapsulation process, the decapsulation process is as follows:
1 The IP packet received from the IPv4 network interface is sent to the IP protocol
stack which checks the protocol number in the IP header.
2 If the protocol number is IPv4, the IP packet is sent to the tunnel module for
decapsulation
3 The decapsulated IP packet is sent back to the IP protocol stack for processing.
IPv4/IPv6 over IPv6 Introduction to IPv4/IPv6 over IPv6 tunneling protocol

Tunnel IPv4/IPv6 over IPv6 tunneling protocol (RF2473) is developed for IPv4 or IPv6 data
packet encapsulation so that encapsulated packets can be transmitted over an
IPv6 network. The encapsulated packets are IPv6 tunnel packets.

Figure 209 Principle of IPv4/IPv6 over IPv6 tunnel
IPv6 header Original data

Original data Original data
Private IPv 6 network Private

network A IPv6 tunnel network B
Router A Router B
Host A Host B
As shown in Figure 209, original data refers to IPv4 or IPv6 packets.
Encapsulation and decapsulation

The encapsulation process is as follows:
1 After receiving the original packet, the interface of Router A connecting private
network A submits it to the corresponding data module for processing. The data
module then determines how to route the packet.
2 If the destination of the packet is Host B connected to Router B, the packet is sent
to Router A’s tunnel interface that is connected to Router B.
3 After receiving the packet, the tunnel interface adds an IPv6 header to it and
submits it to the IPv6 module for processing.
4 The IPv6 module re-determines a route according to the destination address in the
IPv6 header.
Contrary to the encapsulation process, the decapsulation process is as follows:
1 The packet received from the IPv6 network interface is sent to the IPv6 module for
processing.
2 If the passenger protocol is IPv4 or IPv6, the packet is sent to the tunnel processing
module for decapsulation.
3 The decapsulated packet is sent to the corresponding protocol module for the
secondary route processing.
c CAUTION: GRE can realize the IPv4/IPv6 over IPv6 tunnel function. For related
configurations, refer to “GRE Configuration” on page 1589.
6PE Overview IPv6 on the provider edge routers (6PE) is a transition technology by which Internet
service providers (ISPs) can use existing IPv4 backbone networks to provide the
access capability for sparsely populated IPv6 networks.
The major concept of the 6PE is that the IPv6 routing information of users is
converted into IPv6 routing information with labels and is spread into IPv4
backbone networks of ISPs through internal border gateway protocol (IBGP)
sessions. When IPv6 packets are forwarded, traffic will be labeled after entering
tunnels of backbone networks. The tunnels can be GRE tunnels or MPLS LSPs.

Figure 210 Network diagram for 6PE
CE IPv4/MPLS network CE
IBGP
IPv 6 network 6PE 6PE IPv6 network
Customer site Customer site
n “P” in the above figure refers to a backbone router in the network of a service
provider. P is not directly connected with a CE and is required to have the basic
MPLS capability.
When an ISP wants to utilize the existing IPv4/MPLS network to provide IPv6 traffic
switching capability through MPLS, only the PE routers need to be upgraded.
Therefore, it is undoubtedly a high efficient solution that ISPs use the 6PE
technology as an IPv6 transition mechanism. Furthermore, the operation risk of
the 6PE technology is very low.
n For more information or configuration related to 6PE, refer to “Configuring 6PE”

on page 1029.
Tunneling Complete these tasks to configure the tunneling feature:

Configuration Task
List Task Remarks
Configuring IPv6 over IPv4 GRE “Configuring an IPv6 Optional
tunnel Manually Configured Tunnel”
on page 700
“Configuring Automatic Optional
IPv4-Compatible IPv6 Tunnel”
on page 704
“Configuring 6to4 Tunnel” Optional
on page 708
“Configuring ISATAP Tunnel” Optional
on page 714
“Configuring IPv4 over IPv4 Tunnel” on page 717 Optional
Configuring an IPv6
Manually Configured
Tunnel
Configuration IP addresses are configured for interfaces such as VLAN interface, Ethernet
Prerequisites interface, and loopback interface on the device so that they can communicate.
These interfaces serve as the source interface of a tunnel interface to ensure that
the tunnel destination address is reachable.

Configuration Procedure Follow these steps to configure an IPv6 manually configured tunnel:

Enable the IPv6 packet forwarding ipv6 Required
function
By default, the IPv6
packet forwarding
Create a tunnel interface and enter interface tunnel number Required
tunnel interface view
By default, there is no
tunnel interface on the
device.
Configure an Configure a global ipv6 address Required
IPv6 address unicast IPv6 address { ipv6-address
Use any command.
for the tunnel or a site-local address prefix-length |
interface ipv6-address/prefix-length By default, no IPv6 global
} unicast address or
site-local address is
ipv6 address
configured for the tunnel
ipv6-address/prefix-length
interface.
eui-64
Configure a link-local ipv6 address auto Optional
IPv6 address link-local
A link-local address will
ipv6 address ipv6-address automatically be created
link-local when an IPv6 global
unicast address or
configured.
Configure the tunnel to be an IPv6 tunnel-protocol Required
manually configured tunnel ipv6-ipv4
By default, the tunnel is a
GRE tunnel. The same
tunnel type should be
configured at both ends
of the tunnel. Otherwise,
packet delivery will fail.
Configure a source address or source { ip-address | Required
interface for the tunnel interface-type
By default, no source
interface-number }
address or interface is
configured for the tunnel.
Configure a destination address for destination ip-address Required
the tunnel
address is configured for
the tunnel.
Configure the MTU of IPv6 packets ipv6 mtu mtu-size Optional
sent over the tunnel interface
The default value varies
with devices.
n For the configuration of MTU of IPv6 packets sent over a tunnel interface, refer to
the ipv6 mtu command in “Configuring the Interface MTU” on page 670.
c CAUTION:
■ After a tunnel interface is deleted, all the above features configured on the
tunnel interface will be deleted.

■ If the addresses of the tunnel interfaces at the two ends of a tunnel are not in
the same subnet, a forwarding route through the tunnel to the peer must be
configured so that the encapsulated packet can be forwarded normally. You
can configure static or dynamic routes. IP addresses must be configured at
both ends of the tunnel. For detailed configuration, refer to “Static Routing
and Dynamic Routing” on page 817.
■ When you configure a static route, you need to configure a route to the
destination address (the destination IPv6 address of the packet, instead of the
IPv4 address of the tunnel destination) and set the next-hop to the tunnel
interface number or network address at the local end of the tunnel. Such
configurations must be performed at both ends of the tunnel.
■ The destination address of a tunnel packet must not be within the subnet of
the tunnel interfaces.
■ Before configuring dynamic routes, you must enable the dynamic routing
protocol on the tunnel interfaces at both ends. For related configurations, refer
to “Static Routing and Dynamic Routing” on page 817.
■ The destination address of the route configured on the tunnel interface and
the address of the tunnel interface must not be in the same subnet.

Two IPv6 networks are connected through an IPv6 manually configured tunnel
between Router A and Router B. As shown in Figure 211, Ethernet 1/0 on Router
A can communicate with Ethernet 1/0 on Router B normally and an IPv4 packet
route is available between.
Network diagram
Figure 211 Network diagram for an IPv6 manually configured tunnel
IPv4 netwok
Dual stack Dual stack

Eth1/0 Eth1/0
192.168.100.1/24 192 .168 .50.1/24
Router A Router B
The following example shows how to configure an IPv6 manually configured
tunnel between Router A and Router B. Before configuration, you must specify IP
addresses for the source and destination of the tunnel.
# Configure an IPv4 address for Ethernet1/0.
# Enable the IPv6 forwarding function.

[RouterA] ipv6
# Configure an IPv6 manually configured tunnel.
[RouterA] interface tunnel 0

[RouterA-Tunnel0] ipv6 address 3001::1/64
[RouterA-Tunnel0] source Ethernet 1/0
[RouterA-Tunnel0] destination 192.168.50.1
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4
[RouterB] ipv6
# Configure an IPv6 manually configured tunnel.
[RouterB] interface tunnel 0

[RouterB-Tunnel0] ipv6 address 3001::2/64
[RouterB-Tunnel0] source Ethernet 1/0
[RouterB-Tunnel0] destination 192.168.100.1
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4
Configuration verification
After the above configurations, display the status of the tunnel interfaces on
Router A and Router B, respectively:
[RouterA] display ipv6 interface tunnel 0
Tunnel0 current state :UP
IPv6 is enabled, link-local address is FE80::C0A8:6401
3001::1, subnet is 3001::/64
FF02::1:FFA8:6401
FF02::1:FF00:1
FF02::2
FF02::1
MTU is 1500 bytes
[RouterB] display ipv6 interface tunnel 0

IPv6 is enabled, link-local address is FE80::C0A8:3201
3001::2, subnet is 3001::/64

FF02::1:FFA8:3201
FF02::1:FF00:2
FF02::2
FF02::1
MTU is 1500 bytes
# Ping the IPv6 address of the peer tunnel interface from Router A:
[RouterA] ping ipv6 3001::2

Reply from 3001::2
Reply from 3001::2
Reply from 3001::2
Reply from 3001::2
Reply from 3001::2

0.00% packet loss
Configuring
Automatic
IPv4-Compatible IPv6
Tunnel
These interfaces serve as the source interface of the virtual tunnel interface to
ensure that the tunnel destination address is reachable.
Configuration Procedure Follow these steps to configure an automatic IPv4-compatible IPv6 tunnel:

forwarding function
By default, the IPv6 packet
forwarding function is
disabled.
Create a tunnel interface and interface tunnel number Required
enter tunnel interface view
By default, there is no tunnel
interface on the device.


Configure an Configure an ipv6 address { ipv6-address Required
IPv6 address for IPv6 global prefix-length |
Use either command.
the tunnel unicast address ipv6-address/prefix-length }
interface or site-local By default, no IPv6 global
ipv6 address
address unicast address or site-local
address is configured for the
eui-64
tunnel interface.
Configure an ipv6 address auto Optional
IPv6 link-local link-local
By default, a link-local
address
ipv6 address ipv6-address address will automatically be
link-local generated when an IPv6
global unicast or site-local
interface.
Configure an automatic tunnel-protocol ipv6-ipv4 Required
IPv4-compatible IPv6 tunnel auto-tunnel
configured at both ends of
the tunnel. Otherwise,
interface-number }
Configure the MTU of IPv6 ipv6 mtu mtu-size Optional
packets sent over the tunnel
The default value varies with
interface
devices.
n For the configuration of the MTU of IPv6 packets sent over a tunnel interface, refer
to the ipv6 mtu command in “Configuring the Interface MTU” on page 670.
c CAUTION:
■ Only one automatic tunnel can be created at the same tunnel source.
■ No destination address needs to be configured for an automatic
IPv4-compatible IPv6 tunnel.
can configure static or dynamic routes. For the detailed configuration, refer to
“Static Routing and Dynamic Routing” on page 817.
■ The automatic tunnel interfaces encapsulated with the same protocol cannot
share the same source IP address.
■ Automatic tunnels do not support dynamic routing.
destination address (the destination IP address of the packet, instead of the
interface number or network address at the local end of the tunnel. Such a
route must be configured at both ends of the tunnel.


Between Router A and Router B is an IPv4 network. It is required that an IPv6
connection be established through an automatic IPv4-compatible IPv6 tunnel
between the two dual-stack routers.
Network diagram
Figure 212 Network diagram for an automatic IPv4-compatible IPv6 tunnel
Dual stack Dual stack

S 2/0 S2 /0
2 .1. 1. 1/ 8 2. 1. 1.2 /8
IPv4 netwok
Tunnel 0 Tunnel 0
:: 2.1 .1. 1/ 96 ::2. 1. 1.2/ 96
Router A Router B
The following example shows how to configure an automatic IPv4-compatible IPv6
tunnel between Router A and Router B. No address needs to be specified for the
tunnel destination because the destination address can automatically be obtained
from the IPv4 address embedded in the IPv4-compatible IPv6 address.
[RouterA] ipv6
# Configure a serial address.

# Configure an automatic IPv4-compatible IPv6 tunnel.
[RouterA] interface tunnel0

[RouterA-Tunnel0] ipv6 address ::2.1.1.1/96
[RouterA-Tunnel0] source serial 2/0
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 auto-tunnel
[RouterB] ipv6
# Configure a serial address.

# Configure an automatic IPv4-compatible IPv6 tunnel.

[RouterB] interface tunnel0

[RouterB-Tunnel0] ipv6 address ::2.1.1.2/96
[RouterB-Tunnel0] source serial 2/0
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 auto-tunnel
After the above configurations, display the status of the tunnel interfaces on
Router A and Router B, respectively.
[RouterA] display ipv6 interface tunnel 0
IPv6 is enabled, link-local address is FE80::201:101
::2.1.1.1, subnet is ::/96
FF02::1:FF01:101
FF02::2
FF02::1
MTU is 1500 bytes
[RouterB] display ipv6 interface tunnel 0

::2.1.1.2, subnet is ::/96
FF02::1:FF01:102
FF02::2
FF02::1
MTU is 1500 bytes
# Ping the IPv4-compatible IPv6 address of the peer tunnel interface from Router
A.
[RouterA] ping ipv6 ::2.1.1.2

PING ::2.1.1.2 : 56 data bytes, press CTRL_C to break
Reply from ::2.1.1.2
--- ::2.1.1.2 ping statistics ---


0.00% packet loss

Configuring 6to4
Tunnel
These interfaces serve as the source interface of the tunnel to ensure that the
tunnel destination address is reachable.
Configuration Procedure Follow these steps to configure a 6to4 tunnel:

function
packet forwarding
device.
Configure an IPv6 Configure an IPv6 ipv6 address Required.
address for the global unicast { ipv6-address
Use either command.
tunnel interface address or prefix-length |
site-local address ipv6-address/prefix-length By default, no IPv6 global
} unicast address or
ipv6 address
interface.
eui-64
Configure an IPv6 ipv6 address auto Optional
link-local address link-local
ipv6 address address will automatically
ipv6-address link-local be generated when an
IPv6 global unicast
address or site-local
address is configured.
Set a 6to4 tunnel tunnel-protocol Required
ipv6-ipv4 6to4
interface-number }
configured for the
tunnel.
sent over the tunnel interface
with devices.

c CAUTION:
■ Only one automatic tunnel can be configured at the same tunnel source.
■ No destination address needs to be configured for an automatic tunnel
because the destination address can automatically be obtained from the IPv4
address embedded in the IPv4-compatible IPv6 address.
Configuration Example 1 Network requirements

Isolated IPv6 networks are interconnected through a 6to4 tunnel established in the
IPv4 network.
Network diagram
Figure 213 Network diagram for a 6to4 tunnel
IPv4 netwok
6to4 router 6to4 router
Eth1/0 Eth1 /0
2.1 .1.1/24 5.1.1 .1/24
Eth1/1 Eth1/1
2002:0201 :0101 :1::1/64 2002 :0501 :0101 :1::1/64
Router A Router B
Host A Host B
2002:0201 :0101 :1::2/64 2002 :0501:0101 :1 ::2/64
The following example shows how to configure a 6to4 tunnel between border
routers on isolated IPv6 networks. After the IPv4 address 2.1.1.1 is converted into
an IPv6 address, the address prefix is 2002:0201:0101::/64. The configured static
route directs all traffic destined for the IPv6 address with the prefix 2002::/16 to
the tunnel interface of the 6to4 tunnel.
■ Configuration on Router A.

[RouterA] ipv6
# Configure an IPv4 address for Ethernet 1/0.

# Configure a route from Ethernet1/0 of Router A to Ethernet1/0 of Router B.

(Here the next-hop address of the static route is represented by [nexthop]. In
practice, you should configure the real next-hop address according to the
network.)
[RouterA] ip route-static 5.1.1.1 24 [nexthop]

[RouterA-Ethernet1/1] ipv6 address 2002:0201:0101:1::1/64
# Configure a 6to4 tunnel.

[RouterA-Tunnel0] ipv6 address 2002:201:101::1/64
[RouterA-Tunnel0] source ethernet 1/0
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
[RouterA-Tunnel0] quit
# Configure a static route whose destination address is 2002::/16 and next-hop is

the tunnel interface.
[RouterA] ipv6 route-static 2002:: 16 tunnel0

[RouterB] ipv6


network.)
[RouterB] ip route-static 2.1.1.1 24 [nexthop]


[RouterB-Ethernet1/1] ipv6 address 2002:0501:0101:1::1/64

[RouterB-Tunnel0] ipv6 address 2002:0501:0101::1/64
[RouterB-Tunnel0] source Ethernet1/0
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4
[RouterB-Tunnel0] quit

[RouterB] ipv6 route-static 2002:: 16 tunnel0
After the above configuration, ping Host B from Host A or ping Host A from Host
B.
D:\>ping6 -s 2002:201:101:1::2 2002:501:101:1::2
Pinging 2002:501:101:1::2
from 2002:201:101:1::2 with 32 bytes of data:
Reply from 2002:501:101:1::2: bytes=32 time=13ms

Reply from 2002:501:101:1::2: bytes=32 time<1ms
Ping statistics for 2002:501:101:1::2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 13ms, Average = 3ms
Configuration Example 2 Network requirements

Router A is a 6to4 router, and 6to4 addresses are used on its IPv6 network. Router
B serves as a 6to4 relay router and is connected to the IPv6 network. It is required
that hosts in the 6to4 network can access the IPv6 network via Router B.

Network diagram
Figure 214 Network diagram for a 6to4 relay
IPv4 netwok
6to4 router 6to4 relay
Eth1/0 Eth1 /0
2.1 .1.1/24 6.1.1 .1/24
Eth1/1 Eth1/1
2002:0201 :0101 :1::1/64 2001 ::1/64
Router A Router B
Host A Host B
2002:0201 :0101 :1::2/64 2001 ::2 /16
The configuration on a 6to4 relay router is the same as that on an ordinary 6to4
router. However, a 6to4 relay router can be connected to not only a 6to4 network,
but also an IPv6 network.
In order for the 6to4 network connecting Router A to communicate with the IPv6
network connecting Router B, you need to configure a static route on Router A
and specify the next-hop address for the static route as the address of the
interface tunnel 0 of the 6to4 router.
[RouterA] ipv6


network.)
[RouterA] ip route-static 6.1.1.1 24 [nexthop]
# Configure a 6to4 address for Ethernet 1/1.
[RouterA] interface Ethernet 1/1

[RouterA-Ethernet1/1] ipv6 address 2002:0201:0101:1::1/64


[RouterA-Tunnel0] ipv6 address 2002:0201:0101::1/64
[RouterA-Tunnel0] source ethernet 1/0
[RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4

# Configure the default route to the IPv6-only network.
[RouterA] ipv6 route-static :: 0 2001:0601:0101::1

[RouterB] ipv6
[RouterB] ipv6

network.)
[RouterB] ip route-static 2.1.1.1 24 [nexthop]

[RouterB-Ethernet1/1] ipv6 address 2001::1/16

[RouterB-Tunnel0] ipv6 address 2001:0601:0101::1/64
[RouterB-Tunnel0] source Ethernet1/0
[RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4


After the above configuration, ping Host B from Host A.
D:\>ping6 -s 2002:201:101:1::2 2001::2
Pinging 2001::2
from 2002:201:101:1::2 with 32 bytes of data:
Reply from 2001::2: bytes=32 time=13ms

Reply from 2001::2: bytes=32 time<1ms
Ping statistics for 2001::2:

Configuring ISATAP
Tunnel
Configuration Procedure Follow these steps to configure an ISATAP tunnel:

function
disabled.
Create a tunnel interface and enter interface tunnel Required
tunnel interface view number
device.
address for the global unicast { ipv6-address
Use either command.
tunnel interface address or site-local prefix-length |
address ipv6-address/prefix-lengt By default, no IPv6 global
h} unicast address is
ipv6 address
interface.
ipv6-address/prefix-lengt
h eui-64
Configure an IPv6 ipv6 address auto Optional
ipv6 address address will automatically
ipv6-address link-local be generated when an
IPv6 global unicast
address or link-local
address is configured.

Configuring ISATAP Tunnel 715

Set the tunnel to an ISATAP tunnel tunnel-protocol Required
ipv6-ipv4 isatap
Configure a source address or interface source { ip-address | Required
for the tunnel interface-type
interface-number }
configured for the
tunnel.
Configure the MTU of IPv6 packets sent ipv6 mtu mtu-size Optional
over the tunnel interface
with devices.
c CAUTION:

The destination address of a tunnel is an ISATAP address. It is required that IPv6
hosts in the IPv4 network can access the IPv6 network via an ISATAP tunnel.
Network diagram
Figure 215 Network diagram for an ISATAP tunnel
Eth1/0 Eth1/1
3001 ::1 /64 2.1.1.1 /8
IPv6 host ISATAP router ISATAP host

IPv6 address: IPv4 address :
3001 ::2/64 2.1.1.2 /32
IPv6 address :
FE80:5EFE:0201 :0102
2001 :5 EFE0201 :0102

The following example shows how to configure an ISATAP tunnel between the
router and the ISATAP host, which allows a separate ISATAP host to access the IPv6
network.
■ Configuration on the ISATAP router
[Router] ipv6
# Configure addresses for interfaces.
[Router] interface ethernet1/0

[Router-Ethernet1/0] ipv6 address 3001::1/64
# Configure an ISATAP tunnel.
[Router] interface tunnel 10

[Router-Tunnel0] ipv6 address 2001::1/64 eui-64
[Router-Tunnel0] source ethernet 1/1
[Router-Tunnel0] tunnel-protocol ipv6-ipv4 isatap
# Disable the RA suppression so that hosts can acquire information such as the
address prefix from the RA message released by the ISATAP router.
[Router-Tunnel0] undo ipv6 nd ra halt

■ Configuration on the ISATAP host
The specific configuration on the ISATAP host is related to its operating system.
The following example shows the configuration of the host running the Windows
XP.
# On a Windows XP-based host, the ISATAP interface is usually interface 2.

Configure an IPv4 address for the ISATAP router to complete the configuration on
the host. The information on the ISATAP interface is as follows:
C:\>ipv6 if 2
Interface 2: Automatic Tunneling Pseudo-Interface
{48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE}
does not use Neighbor Discovery
does not use Router Discovery
routing preference 1
EUI-64 embedded IPv4 address: 0.0.0.0
router link-layer address: 0.0.0.0
preferred link-local fe80::5efe:2.1.1.2, life infinite
link MTU 1280 (true link MTU 65515)
current hop limit 128
reachable time 42500ms (base 30000ms)
retransmission interval 1000ms
DAD transmits 0

# A link-local address (fe80::5efe:2.1.1.2) in the ISATAP format is automatically

generated for the ISATAP interface. Configure an IPv4 address for the ISATAP
router on the ISATAP interface.
C:\>ipv6 rlu 2 2.1.1.1
After carrying out the above command, look at the information on the ISATAP
interface.
C:\>ipv6 if 2
Interface 2: Automatic Tunneling Pseudo-Interface
{48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE}
does not use Neighbor Discovery
uses Router Discovery
routing preference 1
EUI-64 embedded IPv4 address: 2.1.1.2
router link-layer address: 2.1.1.1
preferred global 2001::5efe:2.1.1.2, life 29d23h59m46s/6d23h59m46s (
public)
preferred link-local fe80::5efe:2.1.1.2, life infinite
link MTU 1500 (true link MTU 65515)
current hop limit 255
reachable time 42500ms (base 30000ms)
retransmission interval 1000ms
DAD transmits 0
# By comparison, it is found that the host acquires the address prefix 2001::/64
and automatically generates the address 2001::5efe:2.1.1.2. Meanwhile, “uses
Router Discovery” is displayed, indicating that the router discovery function is
enabled on the host. At this time, ping the IPv6 address of the tunnel interface of
the router. If the address is successfully pinged, an ISATAP tunnel is established.
After the above configuration, the ISATAP host can access the host in the IPV6
network.
Configuring IPv4 over

IPv4 Tunnel
Configuration Procedure Follow these steps to configure an IPv4 over IPv4 tunnel:



Configure an IPv4 address for ip address ip-address { mask | Required
the tunnel interface mask-length } [ sub ]
By default, no IPv4 address is
interface.
Set the tunnel to an IPv4 over tunnel-protocol ipv4-ipv4 Optional
IPv4 tunnel
By default, the tunnel is a GRE
tunnel. The same tunnel type
should be configured at both
ends of the tunnel. Otherwise,
By default, no source address
interface-number }
or interface is configured for
the tunnel.
Configure a destination destination ip-address Required
address for the tunnel
tunnel.
Configure the MTU for the mtu mtu-size Optional
tunnel interface
devices.
c CAUTION:
■ Two or more tunnel interfaces using the same encapsulation protocol must
have different source and destination addresses.
■ If the tunnel interface is the source interface, the source address is the primary
IP address of the source interface.
protocol on the tunnel interfaces at both ends of the tunnel. Such a route must
be configured at both ends of the tunnel. For related configurations, refer to
related contents in “Static Routing and Dynamic Routing” on page 817.

The two subnets Group 1 and Group 2 running IPv4 are interconnected via an IPv4
over IPv4 tunnel between Router A and Router B.

Network diagram
Figure 216 Network diagram for an IPv4 over IPv4 tunnel
Router A Router B
S2/0 S2/1
2.1.1 .1/24 3 .1.1.1/24
IPv4 netwok
Tunnel1 Tunnel 2
Eth1/0 10.1.2.1 /24 10 .1.2.2/24 Eth1/0
10.1 .1.1/24 10.1.3 .1/24
IPv4 IPv4
Group 1 Group 2
# Configure an IPv4 address for Serial2/0 (the physical interface of the tunnel).

# Create the interface tunnel 1.
# Configure an IPv4 address for the interface tunnel 1.
[RouterA-Tunnel1] ip address 10.1.2.1 255.255.255.0
# Configure the tunnel encapsulation mode.
# Configure a source address for the interface tunnel 1 (IP address of Serial2/0).
[RouterA-Tunnel1] source 2.1.1.1
# Configure a destination address for the interface tunnel 1 (IP address of Serial
2/1 of Router B).
[RouterA-Tunnel1] destination 3.1.1.1

# Configure a static route from Router A through the interface tunnel 1 to Group
2.
[RouterA] ip route-static 10.1.3.0 255.255.255.0 tunnel 1

# Configure an IPv4 address for Serial 2/1 (the physical interface of the tunnel).

[RouterB-Tunnel2] ip address 10.1.2.2 255.255.255.0
# Configure the source address for the interface tunnel 2 (IP address of Serial 2/1).
[RouterB-Tunnel2] source 3.1.1.1
# Configure a destination address for the interface tunnel 2 (IP address of Serial2/0
of Router A).
[RouterB-Tunnel2] destination 2.1.1.1

# Configure a static route from Router B through the interface tunnel 2 to Group
1.
[RouterB] ip route-static 10.1.1.0 255.255.255.0 tunnel 2
After the above configuration, display the status of the tunnel interfaces on Router
A and Router B, respectively.
[RouterA] display interface Tunnel1
Tunnel1 current state: UP
Line protocol current state: UP
Description: Tunnel1 Interface
Internet Address is 10.1.2.1/24 Primary
Encapsulation is TUNNEL, aggregation ID not set
Tunnel source 192.13.2.1, destination 131.108.5.2
Tunnel protocol/transport IP/IP
Last 300 seconds input: 0 bytes/sec, 0 packets/sec
Last 300 seconds output: 0 bytes/sec, 0 packets/sec

0 packets input, 0 bytes

0 input error
0 packets output, 0 bytes
0 output error
[RouterB] display interface Tunnel2

Tunnel source 131.108.5.2, destination 192.13.2.1
Tunnel protocol/transport IP/IP
0 input error
0 output error
# Ping the IPv4 address of the peer interface Ethernet1/0 from Router A.


0.00% packet loss

IPv6 Tunnel
Configuration IPv6 addresses are configured for interfaces such as VLAN interface, Ethernet

forwarding function
By default, the IPv6 packet
disabled.


Configure an IPv4 address for ip address ip-address { mask | Required
the tunnel interface mask-length } [ sub ]
By default, no IPv4 address is
interface.
Configure the tunnel type tunnel-protocol ipv4-ipv6 Optional
By default, the tunnel is a GRE
tunnel. The same tunnel type
should be configured at both
ends of the tunnel. Otherwise,
Configure the source address source { ipv6-address | Required
or interface for the tunnel interface-type
By default, no source address
interface interface-number }
or interface is configured for
the tunnel.
Configure the destination destination ipv6-address Required
address for the tunnel
interface
tunnel.
Configure the MTU of IPv6 ipv6 mtu mtu-size Optional
packets sent over a tunnel
interface
devices.
c CAUTION:
“Static Routing and Dynamic Routing” on page 817. Two or more tunnel
interfaces using the same encapsulation protocol must have different source
and destination addresses.

The two subnets Group 1 and Group 2 of the private network running IPv4 are
interconnected over the IPv6 network by using an IPv4 over IPv6 tunnel between
Router A and Router B.

Network diagram
Router A Router B
S2/0 S2/1
2002 ::1:1/64 2002 ::2:1/24
IPv6 network
Tunnel 1 Tunnel 2
Eth1/0 30.1.2.1/24 30.1 .2.2/24 Eth1 /0
30.1 .1.1/24 30 .1 .3.1/24
IPv4 IPv4
Group 1 Group 2
[RouterA] ipv6


[RouterA-Serial2/0] ipv6 address 2002::1:1 64
[RouterA-Tunnel1] ip address 30.1.2.1 255.255.255.0
[RouterA-Tunnel1] source 2002::1:1
2/1 of Router B).
[RouterA-Tunnel1] destination 2002::2:1


2.
[RouterA] ip route-static 30.1.3.0 255.255.255.0 tunnel 1

[RouterB] ipv6


[RouterB-Serial2/1] ipv6 address 2002::2:1 64
[RouterB-Tunnel2] ip address 30.1.2.2 255.255.255.0
# Configure the source address for the interface tunnel 2 (IP address of Serial 2/1).
[RouterB-Tunnel2] source 2002::2:1
of Router A).
[RouterB-Tunnel2] destination 2002::1:1

1.
[RouterB] ip route-static 30.1.1.0 255.255.255.0 tunnel 2
[RouterA] display interface Tunnel1


Tunnel source 2002::0001:0001, destination 2002::0002:0001
Tunnel encapsulation-limit is disable
Tunnel protocol/transport IP/IPv6
0 input error
0 output error
[RouterB] display interface Tunnel2

Tunnel source 2002::0002:0001, destination 2002::0001:0001
Tunnel encapsulation-limit is disable
Tunnel protocol/transport IP/IPv6
0 input error
0 output error


0.00% packet loss

IPv6 Tunnel
Configuration IPv6 addresses are configured for interfaces such as VLAN interface, Ethernet


function
packet forwarding
device.
address for the global unicast { ipv6-address Use any command.
tunnel interface address or prefix-length |
By default, no IPv6
site-local address ipv6-address/prefix-lengt
h}
ipv6 address
ipv6-address/prefix-lengt
h eui-64
Configure an IPv6 ipv6 address auto
ipv6 address
ipv6-address link-local
Set the tunnel to an IPv6 over IPv6 tunnel-protocol Optional
tunnel ipv6-ipv6
Configure a source address or source { ipv6-address | Required
interface-number }
Configure the destination address for destination ipv6-address Required
the tunnel interface
the tunnel.
Configure the maximum number of encapsulation-limit Optional
nested encapsulations of a packet [ number ]
By default, the maximum
number of nested
encapsulations is not
limited. The default
maximum number of
nested encapsulations is 4
if you execute this
command without the
number argument.
sent over a tunnel interface
with devices.

c CAUTION:
“Static Routing and Dynamic Routing” on page 817. Two or more tunnel
interfaces using the same encapsulation protocol must have different source
and destination addresses.
■ Only the IPv6 over IPv6 tunnel has a maximum number of nested
encapsulations of a packet.

The two subnets Group 1 and Group 2 running IPv6 are interconnected by using
an IPv6 over IPv6 tunnel between Router A and Router B.
Network diagram
Router A Router B
S2 /0 S2/1
2002 ::11:1/64 2002::22:1/64
IPv6 network
Tunnel 1 Tunnel 2
Eth1 /0 2002 :2 ::1/64 2002 ::2:2/64 Eth1/0
2002:1::1/64 2002:3::1 /64
IPv6 IPv6
Group 1 Group 2
[RouterA] ipv6

[RouterA-Ethernet1/0] ipv6 address 2002::11:1 64


[RouterA-Serial2/0] ipv6 address 2002::11:1 64
[RouterA-Tunnel1] ipv6 address 2002:2::11:1 64
[RouterA-Tunnel1] source 2002::11:1
2/1 of Router B).
[RouterA-Tunnel1] destination 2002::22:1

2.
[RouterA] ipv6 route-static 2002:3:: 64 tunnel 1

[RouterB] ipv6

[RouterB-Ethernet1/0] ipv6 address 2002:3::1 64

[RouterB-Serial2/1] ipv6 address 2002::22:1 64
[RouterB-Tunnel2] ipv6 address 2002:2::2 64

# Configure a source address for the interface tunnel 2 (IP address of Serial 2/1).
[RouterB-Tunnel2] source 2002::22:1
of Router A).
[RouterB-Tunnel2] destination 2002::11:1

1.
[RouterB] ipv6 route-static 2002:1:: 64 tunnel 2
[RouterA] display ipv6 interface Tunnel1
2002:2::1, subnet is 2002:2::/64
FF02::1:FF00:1320
FF02::1:FF00:1
FF02::2
FF02::1
MTU is 1500 bytes
[RouterB] display ipv6 interface Tunnel2

2002:2::2, subnet is 2002:2::/64
FF02::1:FF00:2420
FF02::1:FF00:2
FF02::2
FF02::1
MTU is 1500 bytes

[RouterA] ping ipv6 2002:3::1

PING 2002:3::1 : 56 data bytes, press CTRL_C to break
Reply from 2002:3::1
--- 2002:3::1 ping statistics ---

0.00% packet loss
Displaying and
Maintaining Tunneling To do... Use the command... Remarks
Configuration Display information related to display interface tunnel Available in any view
a specified tunnel interface [ number ]
Display IPv6 information display ipv6 interface Available in any view
related to a specified tunnel tunnel number
interface
n For details about BGP, refer to “BGP Configuration” on page 825.
Troubleshooting Symptom: After the configuration of related parameters such as tunnel source
Tunneling address, tunnel destination address, and tunnel type, the tunnel interface is still
Configuration not up.
Solution: Follow the steps below:
1 The common cause is that the physical interface of the tunnel source is not up.
Use the display interface tunnel or display ipv6 interface tunnel commands
to view whether the physical interface of the tunnel source is up or down. If the
physical interface is down, use the debugging tunnel event command in user
view to view the cause.
2 Another possible cause is that the tunnel destination is unreachable. Use the
display ipv6 routing-table or display ip routing-table command to view
whether the tunnel destination is reachable. If no routing entry is available for
tunnel communication in the routing table, configure related routes.

IPV6 UNICAST POLICY ROUTING
50 CONFIGURATION
When configuring IPv6 unicast policy routing, go to these sections for information
you are interested in:
■ “Introduction to IPv6 Unicast Policy Routing” on page 731
■ “Configuring IPv6 Unicast Policy Routing” on page 731
■ “Displaying and Maintaining IPv6 Unicast Policy Routing Configuration” on
page 734
■ “IPv6 Unicast Policy Routing Configuration Examples” on page 734
Introduction to IPv6 Policy routing (also known as policy based routing) is a routing mechanism based
Unicast Policy Routing on the user-defined policies. Different from the traditional destination-based
routing mechanism, policy routing enables you to implement policies (based on
the source address, address length, and other criteria) that make packets flexibly
take different routes.
Policy routing involves system policy routing and interface policy routing:
■ System policy routing applies to locally generated packets only, instead of

forwarded packets. In most cases, interface policy routing applies;
■ Interface policy routing applies to incoming packets on an interface, instead of
locally generated packets (for example, ping packets).
In general, policy routing takes precedence over destination-based routing. That is,
policy routing is applied when packets match the policy, and otherwise,
destination-based routing is applied. However, if a default outgoing interface (next
hop) is configured, the destination-based routing takes precedence over policy
routing.
Configuring IPv6
Unicast Policy Routing
Defining an IPv6 Policy An IPv6 policy can consist of multiple nodes identified by node number. The
smaller a node number is, the higher the priority the node has. A policy, which
consists of if-match clauses and apply clauses, is used to route IPv6 packets.
An if-match clause defines what kind of packets can pass, and an apply clause
defines the action for forwarding permitted packets.
Currently, two types of if-match clause are available: if-match packet-length

and if-match acl6. In each policy, you can specify only one if-match clause for
each type.

732 CHAPTER 50: IPV6 UNICAST POLICY ROUTING CONFIGURATION
There are six types of apply clauses: apply ipv6-precedence, apply

output-interface, apply ipv6-address next-hop, apply default
output-interface, apply ipv6-address default next-hop, and apply
destination-based-forwarding. You can specify only one apply clause for each
type in a policy. In the case that a packet satisfies all if-match clauses on a node,
the priorities of these types of apply clauses are ranked as follows:
■ apply ipv6-precedence: If configured, this clause will always be executed.

■ apply output-interface and apply ipv6-address next-hop: The apply
output-interface clause takes precedence over the apply ipv6-address
next-hop clause. This means that only the apply output-interface clause will
be executed when both are configured.
■ apply default output-interface and apply ipv6-address default next-hop:
Alike, the apply default output-interface clause takes precedence over the
apply ipv6-address default next-hop clause. This means that only the apply
default output-interface clause is executed when both are configured. Either
of these two clauses is executed only when neither outgoing interface nor next
hop is available for the packets, and the destination address does not have a
corresponding route in the routing table.
■ apply destination-based-forwarding: Enables IPv6 destination based
forwarding. If this clause is configured, denied packets can still be forwarded
through matching a route in the routing table. If not, denied packets are
discarded.
There is an AND relationship between if-match clauses on a node. That is to say, a

packet must satisfy all matching rules specified by all if match clauses for the
node before the action specified by the apply clause is taken. There is an OR
relationship between nodes of a policy. That is, if a packet matches a node, it
passes the policy.
When configuring policy nodes, you need to specify the match mode as permit or
deny:
■ permit: Specifies the match mode as permit for a policy node. If a packet
satisfies all rules defined by if-match clauses on the policy node, the apply
clauses are executed. If not, the packet will go to the next policy node for a
match.
■ deny: Specifies the match mode as deny for a policy node. When a packet
satisfies all rules defined by if-match clauses on the policy node, the packet
will be denied and will not go to the next policy node for a match.
A packet satisfying the match rules on a node of a policy will not go to the other
nodes. If the packet does not satisfy the match rules of all nodes of the policy, the
packet cannot pass the policy and will be forwarded through the routing table.
You can define five next hops or five outgoing interfaces at most for an IPv6 policy,
implementing load balancing based on data steams.
Follow theses steps to define an IPv6 policy:

Configuring IPv6 Unicast Policy Routing 733

Create a policy or policy node ipv6 policy-based-route Required
and enter policy view policy-name [ deny | permit ]
Not created by default.
node sequence-num
Define an IPv6 packet length if-match packet-length Optional
match rule min-len max-len
Define an IPv6 ACL match rule if-match acl6 acl6-number Optional
Set a precedence for apply ipv6-precedence Optional
permitted IPv6 packets { type | value }
Set an outgoing interface for apply output-interface Optional
the permitted IPv6 packets interface-type
interface-number
Set a next hop for the apply ipv6-address Optional
permitted IPv6 packets next-hop ipv6-address
Set a default outgoing apply default Optional
interface for the permitted output-interface
IPv6 packets interface-type
interface-number
Set a default next hop for the apply ipv6-address default Optional
permitted IPv6 packets next-hop ipv6-address
Enable destination based apply Optional
forwarding for IPv6 packets destination-based-forwardi
ng
n ■ If a policy node has neither if-match nor apply clauses configured, all packets
can pass it and will not match against any other node. The statistics of IPv6
unicast policy routing will not be changed, though.
■ If a policy node has if-match clauses but has no apply clauses configured, all
packets will match against these if-match clauses, while no apply clauses are
applicable to matched packets. The matched packets will not go to the next
node for a match. The statistics of IPv6 unicast policy routing will not be
changed, though.
■ If a policy node has no if-match but has apply clauses configured, all packets
can pass it, then are permitted or denied if the permit or deny keyword is
specified. They will not match against any other node. In this case, the statistics
of IPv6 unicast policy routing will be changed.
■ If a non existent ACL is referenced, the ACL based match rule will not take
effect.
■ If a local Ethernet interface, sub Ethernet interface or a Virtual-Template
interface is specified as the outgoing interface, packets can be forwarded
through the interface but the communication will fail, since the interface is a
broadcast interface. Therefore, you need to specify a next hop.
■ If the match mode of a policy node is deny, no apply clauses will be executed.
Packets that passed the match criteria are routed through the routing table, so
neither debug information nor statistics for the denied packets will be
available.
Enabling IPv6 System IPv6 system policy routing is used to route packets generated by the local device.
Policy Routing Only one policy can be referenced when system policy routing is enabled.

Follow these steps to enable IPv6 system policy routing:

Enable IPv6 system policy ipv6 local Required
routing and reference a policy policy-based-route
policy-name
Enabling IPv6 Interface Interface policy routing is applied to packets arriving on an interface. Only one
Policy Routing policy can be referenced when policy routing is enabled on an interface.
Follow these steps to enable IPv6 interface policy routing:

interface-number
Enable IPv6 interface policy ipv6 policy-based-route Required
routing and reference a policy policy-name
Displaying and
Unicast Policy Routing Display information about display ipv6 config Available in any view
Configuration configured IPv6 policy routing policy-based-route
[ policy-name ]
Display information about display ipv6
system policy routing and policy-based-route
interface policy routing
Display the configuration display ipv6
information of the IPv6 policy policy-based-route setup
routing { policy-name | interface
interface-type
interface-number | local }
Display the statistics of IPv6 display ipv6
policy routing policy-based-route
statistics { interface
interface-type
interface-number | local }
IPv6 Unicast Policy

Routing Configuration
Examples

Routing Based on Source As shown in the following figure, define the policy aaa for policy routing so that
Address TCP packets arriving on the interface Ethernet 1/0 are forwarded via Serial 2/0 and
other packets are forwarded through the routing table.
■ Node 5 indicates packets matching ACL 3101 are sent to the interface Serial
2/0.

■ Node 10 indicates packets matching ACL 3102 do not go through policy

routing.
Network diagram
Figure 219 Network diagram for policy routing based on source address
Internet
Router
S2/0 S2/1
Eth1/0
Subnet A
10 ::110 /64
Host A Host B
# Define ACLs, making ACL 3001 match TCP packets, and ACL 3002 match IPv6
packets.
[Router] ipv6
[Router] acl ipv6 number 3001
[Router-acl6-adv-3001] rule permit tcp
[Router-acl6-adv-3001] quit
[Router] acl ipv6 number 3002
[Router-acl6-adv-3002] rule permit ipv6
[Router-acl6-adv-3002] quit
# Define Node 5 of policy aaa so that TCP packets are forwarded to the interface
Serial 2/0.
[Router] ipv6 policy-based-route aaa permit node 5

[Router-pbr6-aaa-5] if-match acl6 3001
[Router-pbr6-aaa-5] apply output-interface serial 2/0
[Router-pbr6-aaa-5] quit
# Define Node 10 of policy aaa so that policy routing will not be applied to packets
matching ACL 3102 and these packets will be forwarded through the routing
table.
[Router] ipv6 policy-based-route aaa deny node 10

[Router-pbr6-aaa-10] if-match acl6 3002
[Router-pbr6-aaa-10] quit
# Apply the policy aaa to the interface Ethernet 1/0 to enable policy routing.


[Router-Ethernet1/0] ipv6 address 10::110 64
[Router-Ethernet1/0] ipv6 policy-based-route aaa

Routing Based on Packet The policy lab1 is applied to the interface Ethernet 1/0 of Router A. Packets with a
Size size from 64 to 100 bytes are forwarded to 150::2/64, while packets with a size
from 101 to 1,000 bytes are forwarded to 151::2/64. All other packets are
forwarded through the routing table.
Network diagram
Figure 220 Network diagram for policy routing based on packet size
60̚100bytes
S2/0 S2/0
Router A Router B
150::1/24 150::2/24
S2/1 S2/1
151::1/24 151::2/24
Enable policy
routing on Eth 1/0 101̚1000bytes
# Configure RIPng.
[RouterA] ipv6
[RouterA] ripng 1
[RouterA-ripng-1] quit
[RouterA-Serial2/0] ipv6 address 150::1 64
[RouterA-Serial2/0] ripng 1 enable
# Apply the policy lab1 to the interface Ethernet 1/0 to handle incoming packets.

[RouterA-Ethernet1/0] ipv6 address 192::1 64
[RouterA-Ethernet1/0] ripng 1 enable
[RouterA-Ethernet1/0] ipv6 policy-based-route lab1
# Forward IP packets with a size from 64 to 100 bytes to the next hop 150::2/64
and those with a size from 101 to 1,000 bytes to the next hop 151::2/64.
[RouterA] ipv6 policy-based-route lab1 permit node 10

[RouterA-pbr6-lab1-10] if-match packet-length 64 100

[RouterA-pbr6-lab1-10] apply ipv6-address next-hop 150::2

[RouterA-pbr6-lab1-10] quit
[RouterA] ipv6 policy-based-route lab1 permit node 20
[RouterA-pbr6-lab1-20] if-match packet-length 101 1000
[RouterA-pbr6-lab1-20] apply ipv6-address next-hop 151::2
# Configure RIPng.
[RouterB] ipv6
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterB-Serial2/0] ipv6 address 150::2 64
[RouterB-Serial2/0] ripng 1 enable


TERMINAL ACCESS CONFIGURATION
51
Introduction to Terminal access refers to the connection of a terminal to a router through an

Terminal Access asynchronous interface for data exchange with a front-end processor (FEP) or
another terminal through the router.
Three types of network devices are used in terminal access:
■ Terminal: A terminal is a character device generally connected to another

device through a serial interface cable. A user inputs characters by using the
terminal keyboard. Then, the characters are transferred to another device
through the serial interface cable. After processing the characters, the device
returns the result to the terminal, which then displays the result on its screen.
■ Terminal access initiator (hereinafter referred to as initiator): An initiator sends a
TCP connection request and serves as the client of the TCP connection.
Generally, a router is used as an initiator
■ Terminal access receiver (hereinafter referred to as receiver): A receiver
responds to a TCP connection request and serves as the server of the TCP
connection. A receiver can be an FEP or a router. An FEP is a system installed
with an application program for banking, postal service, taxation, customs, civil
aviation, and so on. An FEP can be a Unix server or a Linux server.
Once a TCP connection is established, the router, functioning as either the

terminal access initiator or receiver, can transparently transmit the data from the
terminal to the peer over the TCP connection. Transparent means that no manual
or extra operation is required.
Introduction to Terminal Access Types
Three types of terminal access are used in different applications: true type terminal
(TTY) access, Telnet terminal access, and remote terminal connection (RTC) access.
TTY terminal access and Telnet terminal access are used to help implement services
between a terminal and an FEP, with a router being the initiator, the FEP being the
receiver. The difference between them is the way of establishing a TCP connection
between the initiator and the receiver. RTC terminal access is used to monitor
terminal data. It is initiated by a router and received by another router. The
following describe the three types of terminal access:
Introduction to TTY Terminal Access

The initiator and receiver of TTY terminal access are a router and an FEP. The
service terminal is connected to the router through an asynchronous serial
interface. The router is connected to the FEP through a network. Application
services run on the FEP. The FEP interacts with the router through the ttyd
program, and the router pushes the service display to the service terminal. The

740 CHAPTER 51: TERMINAL ACCESS CONFIGURATION
router transports data transparently between the connected service terminal and
FEP to implement service interaction and processing.
The TTY terminal access solution implements the fixed terminal number function
and offers many enhanced functions such as dynamic multi-service switching,
real-time screen saving, terminal reset, and data encryption. Meanwhile, the FEP
provides professional terminal management software, enriching the system
functions while simplifying the management. In addition, the combination of TTY
terminal access and routers makes remote offices possible and implementation of
IP telephony more easy, offering a solution for establishing high-efficient networks
with diverse functions.
Introduction to Telnet Terminal Access

The initiator and receiver of Telnet terminal access are a router and an FEP. A
service terminal is connected to the router (Telnet client) through an asynchronous
serial interface. The router is connected to the FEP (Telnet server) through a
network. Application services run on the FEP. The FEP interacts with the router
through Telnet, thereby implementing data exchange between the terminal and
the FEP.
Telnet terminal access implements the following basic functions: up to eight VTYs
supported on a terminal, TTY terminal access or Telnet terminal access used by the
VTYs on a terminal, menu screen switching, VTY service fast switching, and
terminal screen saving.
Introduction to RTC Terminal Access

The initiator and receiver of RTC terminal access are routers. RTC terminal access is
another typical application of terminal access. It interconnects a local terminal and
a remote terminal through routers for data exchange and data monitoring. At
present, RTC terminal access supports the asynchronous mode only.
In asynchronous RTC terminal access, the monitoring terminal at the data center
and the monitored terminal are each connected to a different router through an
asynchronous serial interface, and the routers exchange data with each other
through an IP network. Normally, the router connected to the monitoring device
acts as the terminal access initiator (the RTC client). The monitoring device is
always ready to initiate a connection request at any time to access the data on the
monitored device. The router connected to the monitored terminal acts as the
terminal access receiver (the RTC server) and is always ready to receive the
connection requests from the monitoring device and send monitored data in
response.
RTC terminal access mainly serves the following three purposes:
■ Enabling the monitoring device to manage and monitor remote terminals,

■ Collecting data from the remote terminals.
■ Fulfilling the functions of a multiplexing device and transmitting data over IP
networks for easy network upgrade.
Typical Applications of Terminal access is widely used in the systems in which large numbers of FEPs are
Terminal Access deployed, such as banking, postal service, taxation, customs, and civil aviation.
This manual uses a banking system as an example to describe terminal access

functions, configuration, and applications. Figure 221 shows a typical terminal

access application.
Figure 221 Typical application of terminal access
Bank outlet Branch
TTY/Telnet receiver
FEP
Service terminal
TTY/Telnet
TTY/Telnet initiator
Router A IP network Router B
RTC Server RTC Client

RTC
Monitored device Monitoring device
As shown in the figure above, the arrowhead of a dotted line indicates the
direction of an established TCP connection, from the initiator to the receiver.
The purple dotted line represents TTY/Telnet terminal access. The bank outlet is
connected to the FEP of the branch through Router A, which is capable of terminal
access, over an IP network. Banking services run on the FEP, and the information
entered by an employee at the bank outlet is sent to the FEP through Router A.
The FEP then sends the corresponding service display to the service terminal
through Router A, thereby implementing data exchange between the outlet and
the branch.
The orange dotted line represents RTC terminal access. Router B acts as an RTC
client and Router A the RTC server. Router B initiates monitoring requests and
Router A, upon receiving a monitoring request, sends the data from the monitored
terminal to the monitoring device through Router B, so as to implement terminal
monitoring.
Terminal Access Feature The following table lists the features of terminal access. “All” in this table means
List that all the terminal access types, including TTY, Telnet, and RTC (RTC client or RTC
server), support the feature.
Supporting terminal access

Feature type Description
“Source address binding” on page 743 TTY, Telnet, RTC client -
“Terminal menu” on page 743 TTY, Telnet -
“Fast VTY service switching” on page TTY, Telnet, RTC client -
744
“VTY redrawing” on page 744 TTY -

Supporting terminal access

Feature type Description
“Idle connection timeout” on page 744 All -
“Terminal number fixing” on page 744 TTY -
“Data encryption” on page 745 TTY -
“Automatic link establishment” on TTY, Telnet, RTC client -
page 745
“Automatic link teardown” on page All -
745
“One-to-one access” on page 745 TTY -
“Terminal display language All -
configuration” on page 746
“Screen saving” on page 746 TTY, Telnet, RTC client -
“Read blocking” on page 746 All -
“Terminal reset” on page 746 TTY, Telnet, RTC client -
“Connectivity test” on page 746 TTY, Telnet For Telnet terminal
access, only the
connectivity test
between the
terminal and the
router is supported.
“Data send delay” on page 746 All -
“TCP buffer parameter configuration” All -
on page 746
“Terminal buffer parameter All -
configuration” on page 747
“Threshold for VTY switching failure RTC client -
times” on page 747
“Receiver VTY switching rules” on RTC server -
page 747
“RTC terminal authentication” on page RTC client, RTC server -
747
“Terminal access multi-instance” on All -
page 747
“Server connection authentication” on TTY -
page 747
Statistics support All See “Displaying and
Maintaining Terminal
Access
Configuration” on
page 769
Debugging information support All See “System
Maintaining and
Debugging” on page
2119.
Terminal Access Features Figure 222 shows a terminal access implementation.

Figure 222 Network diagram for terminal access
Source address binding

The principle of source IP address binding is to configure an IP address on a stable
interface (the loopback interface or dialer interface is recommended) and use this
address as the source IP address of the upstream TCP connection from the router
through IP unnumbered configuration.
If an FEP runs, the IP address of the router connected to the FEP needs to be
authenticated. Therefore, when the dial-up backup function is used in a wide area
network (WAN), if the primary link fails, the router begins to use the backup
interface. In that case, the IP address of the router is changed, and the
authentication fails if source IP address binding is not implemented. To avoid such
failures, configure source IP address binding on the router to use a fixed IP address
to establish a TCP connection with the FEP.
For security or some other reason, the actual IP address used in the upstream TCP
connection on the router may need to be hidden and another IP address needs to
be used. In that case, you also need to configure source IP address binding.
Make sure the FEP and the router’s IP address is reachable to each other.
Terminal menu
Terminal menu allows you to bring up the menu interface by pressing the menu
hotkey at the terminal. The menu interface displays the services provided by each
VTY on the terminal. By entering a service option, you can switch to the
corresponding service display. The menu interface displays:
TTY ACCESS SYSTEM
VERSION 3.0

1. SELECT VTY(0): chuxu_zhu

2. SELECT VTY(1): chuxu_bei
0. QUIT
INPUT YOUR CHOICE:
Fast VTY service switching

The characteristics of banking services require each bank branch to provide
services such as deposit and corporate services. However, a terminal at an outlet
can process only one type of service. To solve this problem, the terminal access
feature of the router implements the VTY switching function, enabling a terminal
to process multiple services at the same time and to switch between the services
dynamically.
In terminal access, each terminal is divided into eight virtual type terminals (VTYs)
logically, each of which can be configured to correspond to a service (also known
as an application). An operator of a terminal can press the VTY switching menu
hotkey to bring up the VTY switching menu and select a VTY to switch between
different services dynamically. This allows more flexible use of terminal access. In
addition, the VTY switching feature provides the screen saving function. When an
operator switches from service 1 to service 2, the operating interface of service 1 is
automatically saved. When the operator switches from service 2 back to service 1,
the original operating interface is automatically restored. If the original operating
interface is lost due to a fault, the operator can use the terminal redrawing
function to recover it.
VTY redrawing
You can set the VTY redrawing hotkey on the router. When a terminal does not
display the normal terminal interface for some reasons (for example, when illegible
characters appear after the terminal is turned off and then turned on), pressing
the terminal redrawing hotkey can restore the normal terminal interface.
Idle connection timeout

If the idle connection timeout function is enabled and no data is transmitted
between the initiator and receiver within the idle connection timeout period, the
initiator and receiver are disconnected from each other automatically.
Terminal number fixing

As shown in Figure 222, the terminal access program running on the router
connected to the terminal enables the terminals to access the FEPs. The terminals
are connected to the router through asynchronous serial interfaces. The router
numbers all the terminals. On the other side, the router connects to multiple FEPs
over the network. Each FEP runs multiple applications. Terminal access universally
numbers all the applications, regardless of whether these applications are running
on the same FEP or on multiple FEPs. With the numbering of the terminals and the
applications and the special processing through the router, the mappings between
the terminals and the banking services are established to implement fixed terminal
numbering.

Data encryption
Due to the extensive use of terminal access in banking systems, the requirements
of data security become higher and higher. The terminal access data encryption
function can be used to encrypt the data transmitted between the router and FEPs
to improve data security.
As shown in Figure 223, data is transmitted in ciphertext between Router A and

the FEP. Router A and the FEP that runs the program ttyd are responsible for data
encryption and decryption. At present, the advanced encryption standard (AES)
encryption is supported.
Figure 223 Data encryption procedure between the router and the FEP
Automatic link establishment

The terminal access feature supports the automatic link establishment function.
You can enable this function and configure the automatic link establishment time
in terminal template view. When the terminal is in the “ok” state (meaning the
physical connection is normal), the initiator automatically establishes a TCP
connection to the receiver after the specified period. If the automatic link
establishment function is disabled on the terminal, a link needs to be established
manually. In this mode, the initiator establishes a TCP connection to the receiver
only after you enter a character on the terminal.
Automatic link teardown

The terminal access feature supports the automatic link teardown function. You
can enable the function and configure the automatic teardown time for the
terminal in terminal template view. When the terminal device and the initiator are
disconnected from each other, the terminal enters the “down” state. Then after
the specified period of time, the initiator automatically tears down the TCP
connection to the receiver. In this case, the TCP connection remains active if the
automatic link teardown function is disabled.
One-to-one access
In one-to-one access, each terminal communicates with the FEP through a TCP
connection to achieve optimum communication quality and highest
communication speed under various link states. High terminal echo rates can still
be achieved over low-speed links through parameter adjustments. Frequent and
massive printing needs of users can also be satisfied in this mode.

Terminal display language configuration

The initiator generally sends some unsolicited information, such as menus and link
establishment information, to the terminal. To meet different language needs, the
prompt information can be displayed in either English or Chinese (the default).
Screen saving
Some types of terminals provide the screen saving function, enabling the terminals
to switch to the corresponding screen upon receiving the specified screen code,
such as E!10Q. When you perform VTY service fast switching, the router sends a
screen code to the terminal, which switches to the corresponding operation
interface after saving the current operation interface.
To save the screens of multiple VTYs, you need to set different screen codes for
these VTYs and make sure the number of screen codes supported by the terminal
is greater than the number of configured VTYs. Note that this function needs
terminal support. In addition, the screen codes that can be identified vary with
terminal types and the number of supported screen codes may also be different.
For details, refer to the corresponding terminal manuals.
Read blocking
Terminal data read blocking means that, if the router has not sent data received
from the terminal successfully, the router stops receiving data from the terminal
until all the data is sent successfully. Generally, you need to enable this function
only when the transmission rate between the router and the FEP is less than that
between the router and the terminal.
Terminal reset
In case the terminal fails to communicate with the receiver, you can press the
terminal reset hotkey on the terminal so that the initiating router will first
disconnect and then reestablish the TCP connection with the receiver.
Connectivity test
You can set the terminal test hotkey on the router. By pressing the test hotkey on
the terminal, you can test the connectivity between the terminal and the router
and the TCP connectivity between the terminal and the FEP.
Data send delay

After data send delay is configured on the router, upon receiving data from the
terminal, the router will not send the data to the FEP until the specified period
elapses. This allows the information collected within the specified period to be
sent together, thus increasing bandwidth utilization.
TCP buffer parameter configuration

Terminal access allows you to perform two types of buffer parameter
configuration operations: TCP buffer and terminal buffer. TCP buffer is used to
store the data exchanged between the sender and receiver. Terminal buffer is used
to store the data exchanged between the sender and the terminal.
You can set some parameters of TCP connection, including receive buffer size,
transmit buffer size, non-delay attribute, keepalive interval and transmission times.

Terminal buffer parameter configuration

You can set the parameters of terminal buffer, including whether to clear the
buffer before receiving data, receive buffer size, transmit buffer threshold, and the
maximum size of data to be sent to the terminal at one time.
Threshold for VTY switching failure times

When an RTC client needs to initiate a connection to an RTC server, it first initiates
a connection to the RTC server that corresponds to the VTY with the lowest
number. If the number of connection failures exceeds the threshold configured,
the RTC client will initiate a connection to the RTC server that corresponds to the
VTY with the second lowest number.
Receiver VTY switching rules

If the RTC server is configured to switch between VTYs based on priority (the
lower the VTY number, the higher the priority) and the VTY number corresponding
to a new connection request is less than the VTY number corresponding to the
existing connection, the RTC server tears down the existing connection and begins
to use the new connection for communication. If the RTC server is not configured
to perform VTY switching based on priority and a connection is already
established, the RTC server will ignore any new connection request.
RTC terminal authentication

In terminal access, the RTC server can perform password authentication for RTC
clients to enhance security. Authentication succeeds only when the passwords
configured on the RTC server and the RTC client are the same.
Terminal access multi-instance

Terminal access multi-instance means that terminal access supports VPN
multi-instance. That is, some of the terminals connected to the router can be
grouped in one VPN domain and some other in another VPN domain. This allows a
terminal to access the FEP or remote router that is in the same VPN domain as the
terminal.
Server connection authentication

In practice, some users need to use the FEP to perform necessary authentication
on the connected router to enhance data security. At present, two authentication
modes are supported: character string-based authentication and MAC-based
authentication.
In character string-based authentication, which is similar to password

authentication, the same authentication character string is configured on the FEP
and the router. To establish a connection with the FEP, the router sends the
authentication character string to the FEP, and the FEP checks whether the
authentication character string is correct. If yes, the authentication succeeds; if
not, the authentication fails and the connection attempt fails.
The difference between MAC-based authentication and character string-based

authentication is that the MAC addresses configured on the FEP and the router are
the same. This MAC address is the MAC address of an interface on the router (You
can specify this MAC address with a command).

Terminal Access Specifications of the terminal access initiator

Specifications
No. Item Description
1 Maximum number of TTYs 255 (This number is subject to the number of
router interfaces available for terminal access. For
TTY terminal access, this number is also subject to
the number of FEPs that can be configured.)
2 Maximum number of APPs 2,040
3 Maximum number of VTYs 8
supported by each TTY
4 Types of interfaces supported by ■ Asynchronous serial interface: 3AS, 8AS, 16AS,
terminal access 8ASE, 16ASE
■ Synchronous/ Asynchronous serial interface:
2SA, 4SA, 2S1B, 8LSA, 4SAE, 8SAE
■ AUX interface
5 Terminal emulation type VT100
6 Terminal baud rate 300 bps to 115,200 bps
Specifications of the terminal access receiving router

1 Maximum number of TTYs 255 (This number is subject to the number of
router interfaces available for terminal access.)
2 Maximum number of APPs 2,040
3 Maximum number of VTYs 8
supported by each TTY
Specifications of the terminal access receiving FEP

1 Maximum number of VTYs supported 250
by a Unix FEP
2 Maximum number of VTYs supported 160
by a Linux FEP
3 Supported Unix versions ■ SCO OpenServer 5.0.5
■ SCO UnixWare 7.1 (only for the
one-to-one mode)
■ Sun OS 5.7
■ IBM AIX 4.3.3
■ HP UX 10.20, 11.0
4 Supported Linux version Red Hat Linux 9.0
Configuration Task You need to perform configuration on the initiator and the receiver respectively as
List required. RTC terminal access is initiated and received by routers. TTY terminal
access and Telnet terminal access are initiated by a router and received by a FEP.
Functionally, the configuration commands fall into three types: basic configuration
commands, advanced configuration commands, and display and maintenance
commands. Basic configuration commands are the commands that must be used
for normal operation of terminal access. Advanced configuration commands are

used for implementing the extended functions of terminal access. Display and
maintenance commands are used for displaying and debugging terminal access.
In terms of view, the configuration commands can be classified as the commands

available in user view, commands available in system view, commands available in
template view, and commands available in interface view. Most important
configurations of the terminal access system are performed in templates. You can
save a series of router parameter configurations in a template. When applying a
template to an interface, (an asynchronous interface, for example), the system
creates a TTY according to the contents of the template and the specified terminal
number, and sets up VTYs on the basis of the configuration information in the
template. If you modify a template that was applied to an interface, you can use
the update changed-config command to update the configuration of the
terminal using the template. For convenience, you can configure multiple
templates at the same time and apply the templates on different interfaces. Note
that only one template can be applied on one interface.
Complete the following tasks to configure terminal access.
Configuration task Description

Configure TTY terminal access “Configuring the TTY Optional
Initiator” on page 749
“Configuring the TTY Optional
Receiver” on page 752
Configure Telnet terminal access “Configuring the Telnet Optional
Initiator” on page 755
“Configuring Telnet Optional
Receiver” on page 758
Configure RTC terminal access “Configuring the RTC Optional
Initiator (RTC Client)” on
page 759
“Configuring the RTC Optional
Receiver (RTC Server)” on
page 763
TTY Terminal Access Configuring the TTY Initiator

Configuration
Follow these steps to perform basic TTY initiator configuration:

Enable terminal access on rta server enable Required
the router
Disabled by default
Create a terminal template rta template template-name Required
and enter terminal
template view
Configure a TTY VTY vty vty-number tty remote Required
ip-address port-number [ source
After this configuration, Telnet
source-ip ]
VTYs can be configured in this
template, but RTC client VTYs
or RTC server VTYs cannot.


Exit terminal template view quit -
interface-number
Configure the async mode flow Required
asynchronous serial
By default, an asynchronous
interface to operate in the
serial interface operates in the
flow mode
protocol mode and an AUX
interface the flow mode.
Apply the template to the rta terminal template-name Required
interface terminal-number
Exit interface view quit -
Enter TTY user interface user-interface { first-num1 -
view [ last-num1 ] | tty first-num2
[ last-num2 ] }
Enable software flow flow-control software Required
control of the data on the
By default, the flow control
current user interface
mode is none; that is, no flow
control is implemented.
n ■ For details about the async mode flow command, refer to the async mode
command in “WAN Interface Configuration” on page 99.
■ After a template is applied on an interface, you need to set the flow control
mode of the user interface corresponding to the interface to software flow
control. You can use the display user-interface command to display the
associations between interfaces and user interfaces.
■ For details about the user-interface command, refer to the user-interface
command in “User Interface Configuration” on page 2155.
■ For details about the flow-control software command, refer to the
flow-control command in “User Interface Configuration” on page 2155.
Follow these steps to perform advanced TTY initiator configuration:

Configure the global rta source-ip ip-address Optional
source IP address of TCP
connection
Bind the MAC address of rta bind mac-address Optional
the interface for service interface interface-type
connection authentication interface-number
Bind the character string rta bind string string Optional
for service connection
authentication
Enter terminal template rta template -
view template-name
Configure the automatic auto-close time Optional
link teardown time
0 seconds by default; that is, no
automatic link teardown is
performed.


Configure the automatic auto-link time Optional
link establishment time
automatic link establishment is
performed.
Bind a VPN instance bind vpn-instance Optional
vpn-name
Enable data encryption data protect router-unix Optional
By default, data encryption is
disabled between the router and
the Unix FEP.
Enable terminal data read data read block Optional
blocking
Disabled by default
Configure the terminal data send delay Optional
data send delay milliseconds
0 milliseconds by default; that is,
there is no send delay.
Configure the router not driverbuf save Optional
to clear the terminal
By default, the router clears the
receive buffer after the
terminal receive buffer after the
TCP connection is
TCP connection is established.
established
Configure the terminal driverbuf size size Optional
receive buffer size
8 KB by default
Configure the TCP idle-timeout seconds Optional
connection idle timeout
0 seconds by default; that is, the
time
connection never times out.
Configure the menu menu hotkey Optional
hotkey ascii-code&<1-3>
Use the print menu command
before using this command.
Configure a screen code menu screencode string Optional
for the menu screen
before using this command.
Configure the language of print language { chinese | Optional
the print information english }
Chinese by default
Enable the router to print print information Optional
information on the
Enabled by default
terminal
Configure to print terminal print connection-info Optional
connection information on
By default, terminal connection
the terminal
information is printed on the
terminal.
before using this command
Enable to print menu on print menu Optional
the terminal
Enabled by default.
Use the print information
command before using this
command


Configure the VTY redrawkey Optional
redrawing hotkey ascii-code&<1-3>
Configure the terminal resetkey ascii-code&<1-3> Optional
reset hotkey
Configure the maximum sendbuf bufsize size Optional
size of data to be sent to a
terminal at one time
Configure the terminal sendbuf threshold value Optional
send buffer threshold
Configure the connectivity testkey ascii-code&<1-3> Optional
test hotkey
Configure TCP parameters tcp { keepalive time count Optional
| nodelay | recvbuf-size
By default, receive buffer size is
recvsize | sendbuf-size
2,048 bytes, send buffer size is
sendsize }
2,048 bytes, delay is enabled,
keepalive interval is 50 seconds,
and the number of times for
transmitting a keepalive is 3.
Configure a description for vty vty-number Optional
a VTY description string
Configure the character vty vty-number Optional
string for triggering VTY screencode string
screen saving
Configure the VTY vty vty-number hotkey Optional
switching hotkey ascii-code&<1-3>
Update the configuration update changed-config Optional
n ■ If both the global source IP address and the source IP address for a VTY are
configured, the one for the VTY is used.
■ The TCP parameters must be configured before TCP connections are
established. If you configure the parameters after a TCP connection is
established, the TCP connection must be reestablished for the parameters to
take effect. Pressing the reset hotkey on the terminal can reestablish the TCP
connection.
■ Receive buffer size must be configured before the terminal template is applied.
If you configure the receive buffer size after a terminal template is applied, you
need to remove the application of the terminal template and apply the terminal
template again for the receive buffer size to take effect.
■ The ASCII value of the hotkey must be different from the ASCII value of any
other hotkey configured on the device. Otherwise, hotkey conflicts will occur.
For example, the hotkey value cannot be set to 17 or 19 because these two
values are used for the hotkeys of flow control. In addition, using the hotkey
may not get a response rapidly when the terminal displays too much data.
Configuring the TTY Receiver
The receiver of TTY terminal access is an FEP. The main program of terminal access
at an FEP is the program ttyd (ttyd executable), which implements the data

exchange with the router-side programs. To configure your FEP, refer to the related
sections in “FEP Installation and Configuration” on page 771.

for TTY Terminal Access The deposit services run on the Unix server, whose IP address is 1.1.254.77/16. The
listening port of the ttyd program on the Unix server is 9010.
The router is connected to four terminals through its four asynchronous interfaces.
The source IP address to be bound is 2.2.2.1/32.
Network diagram
Figure 224 Network diagram for TTY terminal access configuration
Perform the following configuration in one-to-one mode:
■ Configure the initiator (router).
# Enable terminal access.
[Sysname] rta server enable
■ # Create a template and enter template view.
[Sysname] rta template temp1
# Configure a VTY application.
[Sysname-rta-template-temp1] vty 0 tty remote 1.1.254.77 9010

[Sysname-rta-template-temp1] quit
# Configure the Ethernet interface.

[Sysname-Ethernet0/0] ip address 1.1.247.88 255.255.0.0
# Create a Loopback interface and configure source IP address binding.

[Sysname] interface loopback 0

[Sysname-loopback0] ip address 2.2.2.1 255.255.0.0
[Sysname-loopback0] quit
[Sysname] rta source-ip 2.2.2.1
# Apply the template to the asynchronous serial interfaces.
[Sysname] interface async 1/0

[Sysname-Async1/0] async mode flow
[Sysname-Async1/0] rta terminal temp1 1
[Sysname-Async1/0] interface async 1/1
# Configure software flow control.
[Sysname] user-interface tty 17 20

[Sysname-ui-tty17-20] flow-control software
■ Configure the receiver (Unix server).
Perform the following configuration by referring to “FEP Installation and

Configuration” on page 771. The following uses SCO OpenServer Unix as an
example.
1 # Edit the file /etc/ttyd.conf.

serverport 9010
mode 1
ttyp40 2.2.2.1 1
ttyp41 2.2.2.1 2
ttyp42 2.2.2.1 3
ttyp43 2.2.2.1 4
2 Modify system configuration file /etc/inittab
Suppose the terminals operate in the active terminal mode. Check whether the
pseudo terminal devices have been configured in the file inittab. Edit the file
/etc/inittab and see whether the following information is available. If not, add this
information.
C40:234:respawn:/etc/getty ttyp40 m
After adding, execute the init q command to bring the configuration into effect.
# init q
The above are basic configurations. After verifying terminal connectivity to the
server, you can proceed with other configurations.

3 Add a route on the FEP.

# route add 2.2.2.1 -netmask 255.255.0.0 1.1.247.88
Telnet Terminal Access Configuring the Telnet Initiator

Configuration
Follow these steps to perform basic Telnet initiator configuration:

Enable terminal access rta server enable Required
on the router
Disabled by default
Create a terminal rta template template-name Required
template and enter
terminal template view
Configure a Telnet VTY vty vty-number telnet remote Required
ip-address [ port-number ] [ source
After this configuration, the
source-ip ]
template can be configured
with Telnet VTYs, but not RTC
client VTYs or RTC server VTYs.
Exit terminal template quit -
view
interface-number
The interface type must be
supported by terminal access.
asynchronous serial
interface to operate in
the flow mode
Apply the template to rta terminal template-name Required
an interface terminal-number
Exit interface view. quit -
Enter TTY user user-interface { first-num1 -
interface view [ last-num1 ] | tty first-num2
[ last-num2 ] }
control of data on the


Follow these steps to perform advanced Telnet initiator configuration:

source IP address of
TCP connection
Enter terminal rta template template-name -
template view
Configure the auto-close time Optional
automatic link
teardown time
automatic link teardown is
performed.
Configure the auto-link time Optional
automatic link
establishment time
performed.
Bind a VPN instance bind vpn-instance vpn-name Optional
Enable terminal data data read block Optional
read blocking
Disabled by default
Configure the terminal data send delay milliseconds Optional
data send delay
0 milliseconds by default; that is,
there is no send delay.
Configure the router driverbuf save Optional
not to clear the
terminal receive buffer
terminal receive buffer after a TCP
after a TCP connection
connection is established.
is established
Configure the terminal driverbuf size number Optional
buffer size
connection idle
timeout time
Configure the menu menu hotkey Optional
hotkey ascii-code&<1-3>
Configure menu printing before
configuring the menu hotkey.
Configure a screen menu screencode string Optional
code for the menu
screen
Configure to print print connection-info Optional
terminal connection
information on the
information is printed on the
terminal
terminal.
command


Configure the router to print information Optional
print information on
By default, the router prints
the terminal
information on the terminal
Configure the router to print menu Optional
print the menu
By default, the menu is printed on
the terminal.
command
Configure the print language { chinese | Optional
language of the print english }
Chinese by default
information
Set the terminal reset resetkey ascii-code&<1-3> Optional
hotkey
Configure the sendbuf bufsize size Optional
maximum size of data
to be sent at one time
Set the terminal testkey ascii-code&<1-3> Optional
connectivity test
hotkey
Configure TCP tcp { recvbuf-size recvsize | Optional
parameters sendbuf-size sendsize |
By default, receive buffer size is
nodelay | keepalive time
2,048 bytes, send buffer size is
count }
2,048 bytes, delay is enabled,
keepalive interval is 50 seconds, and
the number of times for sending a
keepalive is 3.
Configure a vty vty-number description Optional
description for a VTY string
Configure a screen vty vty-number screencode Optional
code for a VTY screen string
Update the update changed-config Optional
configuration
n ■ If both the global source IP address and the source IP address of a VTY are
configured, the one of the VTY is used.
■ The parameters for TCP connections must be configured before the TCP
connections are established. If you configure the parameters after a TCP
connection is established, the TCP connection must be reestablished for the
parameters to take effect. Pressing the reset hotkey on the terminal can
reestablish the TCP connection.
■ The receive buffer size must be configured before the terminal template is
applied. If you configure the receive buffer size after a terminal template is
applied, you need to remove the application of the terminal template and
apply the terminal template again for the receive buffer size to take effect.

Configuring Telnet Receiver
The receiver of Telnet terminal access is an FEP. An FEP only needs to run the Telnet
server program and the corresponding application program; there is no need to
modify or compile the Unix kernel.

for Telnet Terminal Consider two Unix FEPs whose IP addresses are 10.110.96.53 and 10.110.96.54
Access respectively and whose port numbers are 23. A Star terminal is used at the outlet.
On the terminal, the first VTY corresponds to FEP 1, with the VTY switching hotkey
of < Alt+A >; the second VTY corresponds to FEP 2, with the VTY switching
hotkey of <Alt+B> and the menu hotkey of <Alt+C>.
Network diagram
Figure 225 Network diagram for Telnet terminal access configuration
■ Configure the initiator.
# Create a terminal access template and enter its view.
[Sysname] rta template temp2
# Configure VTY 0.
[Sysname-rta-template-temp2] vty 0 telnet remote 10.110.96.53

[Sysname-rta-template-temp2] vty 0 description chuxu_zhu
# Configure the screen saving code for the VTY 0.

[Sysname-rta-template-temp2] vty 0 screencode E!8Q
# Configure the hotkey for VTY 0 as <Alt+A>.
[Sysname-rta-template-temp2] vty 0 hotkey 1 96 13
# Configure VTY 1.
[Sysname-rta-template-temp2] vty 1 telnet remote 10.110.96.54

[Sysname-rta-template-temp2] vty 1 description chuxu_bei
# Configure the screen saving code for VTY 1.
[Sysname-rta-template-temp2] vty 1 screencode E!9Q
# Configure the hotkey for VTY 1 as <Alt+B>.
[Sysname-rta-template-temp2] vty 1 hotkey 1 97 13
# Configure the menu hotkey as <Alt+C>.
[Sysname-rta-template-temp2] menu hotkey 1 98 13

[Sysname-rta-template-temp2] quit
# Apply the template to the asynchronous serial interface.

[Sysname-Async1/0] quit
# Configure software flow control.
[Sysname] user-interface tty 17

[Sysname-ui-tty17] flow-control software
After the above-mentioned configurations, you can see the following menu on
the terminal (You can enter an option on the display or exit by pressing <Esc>.):
TTY ACCESS SYSTEM

VERSION 3.0
1. SELECT VTY(0): chuxu_zhu

2. SELECT VTY(1): chuxu_bei
0. QUIT
INPUT YOUR CHOICE:

■ Configure the receiver.
The receivers of Telnet terminal access are FEPs. An FEP only needs to run the
Telnet server program and the corresponding application program; there is no
need to modify or compile the Unix kernel.
RTC Terminal Access Configuring the RTC Initiator (RTC Client)

Configuration

The initiator of asynchronous RTC terminal access is an RTC client connected to

the monitoring device. The receiver of asynchronous RTC terminal access is the
RTC server connected to the monitored device. An RTC client can initiate a
connection request to the RTC server at any time to access the data.
Follow these steps to perform basic RTC initiator (RTC client) configuration:

Enable terminal access on rta server enable Required
the router
Disabled by default
Create a terminal template rta template template-name Required
and enter terminal
template view
Create a RTC client VTY vty vty-number rtc-client Required
remote ip-address
port-number [ source
template cannot be configured
source-ip ]
with any TTY, Telnet, or RTC
server VTYs.
interface-number
asynchronous serial
interface to operate in the
flow mode
Apply the template to the rta terminal template-name Required
interface terminal-number
Enter TTY user interface user-interface { first-num1 -
view [ last-num1 ] | tty first-num2
[ last-num2 ] }
control of data on the
Follow these steps to perform advanced RTC initiator (RTC Client) configuration


source IP address for
TCP connections
Enter terminal rta template -
template view template-name
automatic link
teardown time
automatic link teardown is performed.
Configure the auto-link time Optional
automatic link
establishment time
performed.
Bind a VPN instance to bind vpn-instance Optional
the template vpn-name
read blocking
Disabled by default
Configure the data data send delay Optional
send delay milliseconds
0 milliseconds by default; that is, there
is no send delay.
not to clear the
terminal buffer after a
TCP connection is
established
Configure the terminal driverbuf size size Optional
receive buffer size
connection idle
timeout time
terminal connection
information on the
information is printed on the terminal.
terminal
Use the print information command
before using this command
print information on
the terminal
Configure the print language { chinese | Optional
language of the print english }
Chinese by default
information
Set the terminal reset resetkey ascii-code&<1-3> Optional
hotkey
sent by the terminal
send buffer at one
time


By default, receive buffer size is 2,048
bytes, send buffer size is 2,048 bytes,
count }
delay is enabled, keepalive interval is
50 seconds, and the number of times
for sending a keepalive is 3.
Configure the vty vty-number password Optional
password for VTY { simple | cipher } string
authentication
Configure a screen vty vty-number screencode Required
code for the VTY string
screen
Configure the VTY vty-switch threshold times Optional
switching threshold
Not configured by default; that is, no
switching will be performed.
configuration
n ■ To implement terminal access authentication, terminal access authentication

must be configured on both the RTC server and the RTC client, and the
authentication passwords must be the same for the authentication to succeed.
■ The bind vpn-instance command is used when the RTC client also acts as an
MPLS PE router at the same time. When you apply a terminal template
configured with the bind vpn-instance command to an asynchronous serial
interface, the terminal connected to the asynchronous serial interface is bound
with the VPN instance. Thus, the RTC client can receive terminal access packets
from multiple VPNs and initiate connection requests through multiple
asynchronous serial interfaces.
■ If both the global source IP address and the source IP address for a VTY are
configured, the VTY uses the latter one.
■ The TCP parameters must be configured before a TCP connection is
connection.
■ The receive buffer size must be configured before the terminal template is

Configuring the RTC Receiver (RTC Server)
Follow these steps to perform basic RTC receiver (RTC server) configuration:

Enable terminal access rta server enable Required
Configure the listening rta rtc-server listen-port Required
port port-number
Create a terminal rta template template-name Required
template and enter
terminal template view
Create a RTC server vty vty-number rtc-server remote Required
VTY ip-address terminal-number
template cannot be configured
with any TTY, Telnet, or RTC
client VTYs.
Exit terminal template quit -
view
interface-number
asynchronous serial
interface to operate in
the flow mode
Apply the template to rta terminal template-name Required
an interface terminal-number
Exit interface view. quit -
Enter TTY user user-interface { first-num1 -
interface view [ last-num1 ] | tty first-num2
[ last-num2 ] }
control of the data on
the current user
interface
Perform these steps to perform advanced RTC receiver (RTC server) configuration:


source IP address for
TCP connections
Enter terminal template rta template -
view template-name
automatic link
teardown time
automatic link teardown is performed.
Bind a VPN instance to bind vpn-instance Optional
the template vpn-name
read blocking
Disabled by default
Configure the terminal data send delay Optional
data send delay milliseconds
0 milliseconds by default; that is, there
is no send delay.
not to clear the terminal
buffer after a TCP
connection is
established
Configure the terminal driverbuf size number Optional
buffer size
8 KB by default
connection idle timeout
time
terminal connection
information on the
information is printed on the terminal.
terminal
Use the print menu command before
using this command
print information on the
terminal
Configure the language print language { chinese | Optional
of the print information english }
Chinese by default
to be sent to a terminal
at one time
By default, receive buffer size is 2,048
bytes, send buffer size is 2,048 bytes,
count }
delay is enabled, keepalive interval is
50 seconds, and the number of times
for sending a keepalive is 3.


Configure the password vty vty-number password Optional
for the VTY { simple | cipher } string
authentication
Configure the RTC vty-switch priority Optional
server to perform VTY
By default, the VTY switching is
switching by priority
performed not by priority.
(the lower the VTY
number, the higher the
priority)
configuration
n ■ The port number specified for the VTY application on the RTC client must be
the same as the listening port number specified on the RTC server.
■ The terminal-number argument of the command vty rtc-server remote
configured on the RTC server must be the same as the terminal-number
argument of the command rta terminal configured on the RTC client;
otherwise, no TCP connection can be established
■ Each terminal of the RTC server corresponds to a different RTC client.
■ If not configured with the bind vpn-instance command, the RTC server can
accept connection requests from any VPNs.
■ The TCP parameters must be configured before a TCP connection is
connection.
■ The receive buffer size must be configured before a terminal template is
Asynchronous RTC Network requirements

Terminal Access Two routers, one serving as the RTC client and the other the RTC server, are
Configuration Example connected to the central terminal device and the remote terminal device
respectively.
■ The RTC listening port of the RTC server is 9000.
■ The central terminal device is connected to the asynchronous serial interface
Async1/0 on the RTC client. The remote terminal device is connected to the
asynchronous serial interface Async1/0 on the RTC server.
■ The RTC client and the RTC server have the same terminal number of 1.

Network diagram
Figure 226 Network diagram for asynchronous RTC terminal access configuration
1 Configure the RTC server.
# Set the listening port of the server.
[Sysname] rta rtc-server listen-port 9000
[Sysname] rta template rtcserver
# Configure the VTY.
[Sysname-rta-template-rtcserver] vty 0 rtc-server remote 10.111.0.12

1
[Sysname-rta-template-rtcserver] vty 0 password simple 123
# Apply the template to the interface.
[Sysname-rta-template-rtcserver] quit
[Sysname-Async1/0] rta terminal rtcserver 1
2 Configure the RTC client.
[Sysname] rta template rtcclient
# Configure the VTY.

[Sysname-rta-template-rtcclient] vty 0 rtc-client remote 10.111.95.1

0 9000
[Sysname-rta-template-rtcclient] vty 0 password simple 123
# Apply the template to the interface.

[Sysname-Async1/0] rta terminal rtcclient 1
Asynchronous RTC Network Requirements

Multi-instance Terminal CE A in the monitoring center and remote terminal CE B are in MPLS
Configuration Example VPNA and respectively connected to the interface Async1/0 on PE A and PE B. It is
required to monitor CE B in real time through CE A.
■ The terminal numbers of PE A and PE B are 2.
■ The listening port of the RTC server is 9000.
Network diagram
Figure 227 Network diagram for asynchronous RTC multi-instance configuration
1 Configure the RTC server.
# Configure MPLS L3VPN. For details, see “MPLS L3VPN Configuration” on page
1459.
# Bind Loopback1 to VPNA.
[PEB] interface loopback 1

[PEB-LoopBack1] ip binding vpn-instance vpna
[PEB-LoopBack1] ip address 169.254.3.1 32
[PEB-LoopBack1] quit
[PEB] rta server enable
# Configure the listening port number of the RTC server.

[PEB] rta rtc-server listen-port 9000
# Configure the terminal access template.
[PEB] rta template rtcs
# Configure VTY 0 on the RTC server.
[PEB-rta-template-rtcs] vty 0 rtc-server remote 169.254.2.1 2
# Bind the VPN instance to the template.
[PEB-rta-template-rtcs] bind vpn-instance vpna

[PEB-rta-template-rtcs] quit
# Configure interface async1/0.
[PEB] interface async 1/0

[PEB-Async1/0] async mode flow
[PEB-Async1/0] rta terminal rtcs 2
2 Configure the RTC client.
# Configure MPLS L3VPN. For details, see “MPLS L3VPN Configuration” on page
1459.
# Bind Loopback1 to VPNA.
[PEA] interface loopback 1

[PEA-LoopBack1] ip address 169.254.2.1 32
[PEA-LoopBack1] ip binding vpn-instance vpna
[PEA-LoopBack1] quit
[PEA] rta server enable
# Configure a terminal access template.
[PEA] rta template rtcc
# Configure VTY 0 on the RTC client.
[PEA-rta-template-rtcc] vty 0 rtc-client remote 169.254.3.1 9000
# Bind VPNA to the template.
[PEA-rta-template-rtcc] bind vpn-instance vpna

[PEA-rta-template-rtcc] quit
# Configure interface async1/0.
[PEA] interface async 1/0

[PEB-Async1/0] async mode flow
[PEB-Async1/0] rta terminal rtcc 2
[PEA-Async1/0] quit

Displaying and Maintaining Terminal Access Configuration 769
Displaying and
Maintaining Terminal To do... Use the command... Remarks
Access Configuration Display specified terminal display rta { all | statistics | Available in any view
access information terminal-number { brief | detail
| statistics | vty-number } }
Clear the statistics of a reset rta statistics Available in user view
terminal terminal-number


FEP INSTALLATION AND
52 CONFIGURATION
To implement terminal access with an FEP as the receiver, the router-side program
serving as the initiator must work together with the FEP-side programs serving as
the server that receives connection requests from the initiator. This chapter covers
the installation, configuration, operation, and management of FEP-side programs.
Normally, an FEP runs the following two programs:
■ ttyd (ttyd executable) program, which is the main program running at the FEP
side in terminal access. It exchanges data with the router-side program.
■ ttyadm terminal administration program, consisting of two executables:
ttyadmcmd and ttyadm. This program manages the ttyd program.
A Unix FEP supports up to 250 terminals. A Linux FEP supports up to 150

terminals.
Installing and
Configuring SCO
OpenServer Server
Installing Device Drivers Using a floppy disk

The following describes the installation procedure using a floppy disk.
1 Switch to a console terminal.
To install the ttyd program, you need at least one console terminal. In SCO
OpenServer Unix, use a hotkey from <Alt+F1> to <Alt+F12> to switch between
console terminals.
2 Log in as a super user such as root.
To install and configure this program, you must log in as a super user as follows:
Step1: Press a hotkey to switch to a console, <Alt+F4> for example. The following
interface appears:
SCO OpenServer(TM) Release 5 (scosysv) (tty04)

login:
Step 2: At the prompt of “login:”, enter root. Then, at the prompt of

“Password:”, enter the password root. Then, you can log in to the Unix server as
root.
3 Install the drivers

772 CHAPTER 52: FEP INSTALLATION AND CONFIGURATION
Insert the floppy disk into the floppy drive of the Unix server and then run the
mount command to mount the floppy drive.
# mount /dev/fd0 /mnt
Copy the executable files to the Unix server.
# cp /mnt/ttyd /etc/ttyd
# cp /mnt/TTYADMCMD /etc/ttyadmcmd
# cp /mnt/TTYADM /etc/ttyadm
Change the file mode of the files to the executable mode.
# chmod 744 /etc/ttyd /etc/ttyadm /etc/ttyadmcmd
n File names are case-sensitive in Unix. Use the ls /mnt command to view the names
of the files before copying them.
Thus, the ttyd, ttyadmcmd, and ttyadm programs are installed.
n After completing the above-mentioned tasks, make sure you use the umount
command to unmount the floppy drive as follows:
# cd /
# umount /mnt
Using FTP
You can also use FTP to install the ttyd programs. The following describes the
installation procedure using FTP on a Windows system.
1 Place the ttyd programs in a directory
You must place the ttyd programs under a directory of the Windows system, for
example, c:tyd.
2 Open the DOS window and run the ftp command.
Open the DOS window. Run the ftp command under the directory c:tyd to
connect to the Unix server and log in as root. The following configuration example
assumes that the IP address of the FEP is 10.110.96.53:
C: tyd>ftp 10.110.96.53
Connected to 10.110.96.53.
220-
220 sco2 FTP server (Version 2.1WU(1)) ready.
User (10.110.96.53:(none)):User (10.110.96.53:(none)): root
331 Password required for root.
Password:
230 User root logged in.
ftp>
3 Enter the directory /etc of the Unix server, and transfer the programs ttyd and
ttyadmcmd to the Unix server in binary format (ttyd and ttyadmcmd are binary
executables).
ftp> cd /etc
ftp> bin

ftp> put ttyd

ftp> put ttyadmcmd
Transfer the program ttyadm to the Unix server in text format. Then, exit FTP.
ftp> ascii
ftp> put ttyadm
ftp> bye
4 On the Unix server, change the file modes of the programs to the executable
mode.
# chmod u+x /etc/ttyd /etc/ttyadm /etc/ttyadmcmd
Now, the ttyd, ttyadmcmd, and ttyadm programs are installed.
Using the installer

For the SCO OpenServer Unix system, make sure you have a standard program
installation CD supporting this system. You can use the installation program
named VOL.000.000 on the disk to install the ttyd, ttyadmcmd, and ttyadm
programs to your SCO OpenServer Unix server. The installation procedure is as
follows:
1 Copy the installation file VOL.000.000 to a directory on the SCO OpenServer Unix
server. The following example assumes that the installation file is copied to the
directory /build. Type scoadmin to open the SCO manager.
2 From [FileSoftware Manager], select [SoftwareInstall New...] to enter software
installation interface, and then select local installation.
3 Select [Media Images] for Media Device.
4 In [Image Directory], enter the directory holding the installation file (this example
assumes VOL.000.000 is placed in the directory /build). Press <Enter>, and
information about the programs under the directory that can be installed will be
listed, such as “ttyd for sco openserver 5.05”.
5 Select [Install] to start the installation. After the programs are installed, a message
of “OK” is displayed.
Now, the ttyd, ttyadmcmd, and ttyadm programs are all installed.
Configuration Before configuration, you must determine the mappings between pseudo
Prerequisites terminals on the Unix server and ports on the router.
If the Unix system is connected with many terminals, the required resources may
exceed the default of the Unix system. In this case, you must modify the kernel
parameters of the Unix system.
The method for modifying the kernel of the SCO OpenServer Unix system is as
follows:
Adding pseudo terminals

By default, SCO OpenServer Unix supports up to 64 pseudo terminals. To connect
to more terminals, you must add pseudo terminals on the Unix system.
Before adding pseudo terminals, you must check whether the pseudo terminals
exist. For example, you can use the following command to check whether

ttyp50/ptyp50 devices exist. Generally, ttyp and ptyp devices are present in pairs
and each pair shares the same device number.
# ls -l /dev/ttyp50 /dev/ptyp50
If pseudo terminals exist, the console displays the following information:
crw-rw-rw- 1 root sys 59, 50 Aug 6 18:44 /dev/ptyp50

crw------- 1 bin terminal 58, 50 Aug 15 16:24 /dev/ttyp50
If not, you must create pseudo terminals. To do so, use the scoadmin program as
follows.
1 Launch scoadmin.
# scoadmin
2 Select [Hardware/Kernel Manager].
3 Select [Tune Parameters...].
4 Enter 9 to select [TTY and console configuration].
5 Change the value of “NSPTTYS: number of pseudo-ttys on system.” to 256.
6 Compile the kernel and restart the server. Then, the maximum number of devices
becomes 256.
c CAUTION: When the kernel is compiled, /etc/inittab is overwritten by

/etc/conf/cf.d/init.base. Therefore, back up /etc/inittab before creating a new
kernel.
Modifying the maximum number of files a process can open

By default, each SCO OpenServer Unix process can open up to 110 files. If a Unix
server is to be connected with more than 50 terminals, you are recommended to
change the number to 600. To do so, execute the following command:
# /etc/conf/cf.d/configure
Select 7 (User and group configuration), and then change the [maximum number
of open files per process] field to 600.
Modifying the maximum number of processes a user can open

By default, a SCO OpenServer Unix user can open up to 100 processes. If a Unix
server is to be connected with a number of terminals (usually more than 50), you
are recommended to change the number to 600. To do so, execute the following
command:
# /etc/conf/cf.d/configure
Select 7 (User and group configuration), and then change the [maximum number
of processes available to user] field to 600.
Validating the new configuration

After modifying system kernel parameters, you must follow the system prompts to
run ./link_unix to link to the system kernel again and then restart the system to
bring the changes into effect.

Modifying System Check whether the pseudo terminals are configured in file inittab. Taking ttyp50
Configuration File as example, edit file /etc/inittab and check whether the following line is present:
inittab C50:234:respawn:/etc/getty ttyp50 m
If the line is absent, add it. In the sample line, C50 is the identifier of the line. Each
line in file inittab must have a unique identifier consisting of no more than four
characters. According to banking applications, pseudo terminals fall into two
categories: active terminal and dumb terminal. When an active terminal user logs
into the Unix server, the Unix server pushes the login interface to the terminal.
When a dumb terminal user logs into the Unix server, the Unix server does not
push the login interface to the terminal. In system configuration file inittab, the
third column of a line is “respawn” for an active terminal and “off” for a dumb
terminal.
After adding the line, execute the init q command to bring the configuration into
effect.
# init q
In addition, you can use the enable command to configure a pseudo terminal as
an active terminal, or use the disable command to configure a pseudo terminal as
a dumb terminal.
# enable ttyp50
Editing the ttyd The default ttyd configuration file is /etc/ttyd.conf. In a ttyd configuration file, you
Configuration File can define the listening port number and map the terminal numbers on the router
to the pseudo terminals on the Unix server. The following shows the format of ttyd
configuration file:
# The router terminal access configuration file on the Unix server
serverport 9010
mode 1
nodelay 1
screen 0
lang 1
logsep 1
debugpath /var/ttydlist
sendsize 512
readsize 300
noblock 1
ttyp30 10.110.96.44 1 accesstime 1 8:00-18:00
exit 1
compat 1
The following explains the file format:
In the configuration file, the lines starting with a “#” are comment lines.
serverport 9010
TCP listening port for the ttyd process. By default, it is 9010. A Unix server can run
multiple ttyd processes, each of which must use a unique configuration file and a
unique listening port.

mode 1
Operating mode of the ttyd process. It can be 0 for many-to-one mode or 1 for
one-to-one mode. Currently, it must be set to 1.
nodelay 1
Specifies the ttyd process to support (with a value of 1) or not to support (with a
value of 0) the nodelay attribute. The default is 1, meaning that ttyd responds
instantly upon receiving data from the peer. On low speed lines, this can improve
the echoing speed.
screen 0
Specifies the ttyd process to support (with a value of 1) or not to support (with a
value of 0) the screen saving function. The default is 0.
lang 1
Specifies the language for prompting ttyd authentication failure. It can be 0 for
Chinese or 1 for English. The default is 0.
logsep 1
Specifies whether to save ttyd logs separately. It can be 1, meaning that a log file is
used for each terminal, or 0, meaning a log file is used for all the terminals. The
default is 1.
debugpath /var/ttydlist
Destination directory of the ttyd debugging file(s). It is /var/ttydlist by default.
autogetty 0
Specifies whether the ttyd program automatically calls the getty program. It can
be 0, meaning that, it is configured in the inittab system configuration file that the
system is responsible for calling the getty program, or 1, meaning the ttyd
program will call the getty program. In SCO UnixWare, this value must be set to 1.
Once you set a value of 1, you can no longer configure it in the /etc/inittab file;
otherwise, the program cannot operate normally.
This parameter functions in one-to-one mode only.
sendsize 512
Maximum size of data that the ttyd program can put onto the network in one
operation (in bytes). The default is 512 bytes, and the recommended value is from
384 to 1,024 bytes. You can adjust this value based on the WAN link status.
readsize 300
Size of data that the ttyd program can read from a pseudo terminal in one
operation (in bytes). The default is 256 bytes, and the recommended value is from
200 to 384 bytes. You can adjust this value based on the WAN link status.
Note that the value of readsize must be less than that of sendsize.
ttyp30 10.110.96.44 1 accesstime 2 8:00-12:00 13:00-18:00

The triple of the pseudo terminal number, router IP address, and the terminal
number configured on the asynchronous serial interface of the router uniquely

determines which router and which terminal on the router a pseudo terminal
corresponds to. This guarantees terminal number fixing. For example, the above
sample entry shows that pseudo terminal ttyp30 on the Unix server corresponds to
the terminal connected to the asynchronous interface with a terminal number of 1
on router 10.110.96.44. The name of a pseudo terminal must be present in the
/dev directory and must start with tty. To configure pseudo terminal names not to
start with “tty”, you must use a full path name starting with “/dev/”.
accesstime 2 8:00-12:00 13:00-18:00" in the sample entry specifies that the

terminal can be connected to the Unix server during two periods only: 8:00 to
12:00 and 13:00 to 18:00. Up to four access periods can be defined for a
terminal. By default, no time restriction is imposed. Note that access periods are
synchronized with the system clock of the FEP. This parameter functions in
one-to-one mode only.
ttyp30 10.110.96.44 1 mac 02-f3-22-3e-2e-01

This sample entry specifies that the router with the IP address of 10.110.96.44 has
a MAC address of 02-f3-22-3e-2e-01, and that the router must send its MAC
address for authentication before it can perform normal operations. After this
command is used, MAC address binding must also be configured on the router.
To configure authentication and access periods at the same time, you need to
configure them in the same line and make sure the access period is configured
before the authentication. See the following example:
ttyp30 10.110.96.44 1 accesstime 1 8:00-18:00 mac 02-f3-22-3e-2e-01
ttyp30 10.110.96.44 1 <str> beijing-01 </str>

<str> beijing-01 </str>" indicates the character string that the router with the IP
address of 10.110.96.44 sends for authentication. The router needs to send its
authentication character string. If the authentication character string is consistent
with that in the configuration file, the authentication succeeds; otherwise, the
authentication fails. After this command is used, character string binding must
also be configured on the router.
To configure authentication and access periods at the same time, you need to
configure them in the same line and make sure the access period is configured
before the authentication. See the following example:
ttyp30 10.110.96.44 1 accesstime 1 8:00-18:00 <str> beijing-01 </str>
exit 1
If “exit 1” is configured in the configuration file, terminating the connection using
the hotkey or the reset rta connection command will terminate the ttyd
program. When you re-log into the FEP, the login interface displays on the
terminal. If authentication is configured on the FEP, you need to enter the
password before performing any operation on the FEP. If neither exit 1 nor exit 0 is
configured, terminating the connection using the hotkey or the reset rta
connection command will not terminate the ttyd program. In this case, when you
re-log into the FEP, the login interface does not display on the terminal, and you
don’t need to pass the authentication for further operations on the FEP.

compat 1
Specifies to be compatible with the previous router versions, but some terminal
access features will not be available. The default is 0, indicating incompatibility
with the previous router versions.
The ttyd configuration file supports dynamic adding. That is, after ttyd is started,
the corresponding terminal configuration items can be added. The addition takes
effect after connection requests are initiated from the terminals connected to the
router or after the configuration file is refreshed with the ttyadm program,
without the need of restarting the ttyd program.
Addition takes effect automatically. For modification and deletion to take effect,
however, the configuration file must be refreshed.
Normally, you need to configure items 1, 2, 4, 9, 11, 12, and 13 as required and
use defaults for other items.
n When too many terminals are configured in a configuration file, the file is liable to
be modified improperly. Therefore, you are recommended to configure multiple
configuration files on a Unix server with many pseudo terminals, so that a
configuration error does not affect too many applications.
Modifying Route In terminal access, the router is usually connected to the Unix server through
Configuration File WANs and therefore located on an IP subnet different from that of the Unix server,
in which case you must configure a route on the Unix server. The following
example shows how to do so:
# route add 10.110.96.0 -netmask 255.255.255.0 63.1.1.250
In the example above, 10.110.96.0 is the destination subnet, with the subnet
mask of 255.255.255.0 and the next hop IP address of 63.1.1.250.
Running and Running ttyd

Terminating ttyd on You can run the ttyd program after the installation and configuration After
Unix Server installing the device drivers and configuring the configuration files, you can run
the ttyd program as long as you can ping through the router from the Unix server.
Execute the following command to run the ttyd program.
# /etc/ttyd
If you do not specify any parameters for the command, the default configuration
file /etc/ttyd.conf is used. To specify another configuration file, you must enter file
in the following format:
# /etc/ttyd /etc/ttyd9020.conf
A Unix server can run multiple ttyd programs, each of which must use a unique
configuration file and a unique listening port.
You can enter the following command to view the version of ttyd.
# /etc/ttyd -h

Terminating ttyd
The ttyd program operates in multi-process mode. After you launch the program,
you may find multiple ttyd processes. You can enter this command to view
information about processes:
# ps -ef | grep ttyd
In one-to-one access mode, ttyd processes are in a two-tier process architecture,

where the main process is parent process 1 and the others are child processes.
When you launch a ttyd program, a ttyd main process is started. Whenever a TCP
connection is established between the Unix server and a terminal, a child ttyd
process is started.
# ps -ef | grep ttyd

root 8312 8309 0 17:06:14 ? 00:00:00 /etc/ttyd ttyp40 10.110.96
.44 6 /etc/ttyd9010.conf 1026
root 8313 8309 0 17:06:15 ? 00:00:00 /etc/ttyd ttyp41 10.110.96
.44 7 /etc/ttyd9010.conf 1028
root 8309 1 0 17:06:11 ? 00:00:00 /etc/ttyd
The output reveals the relations between the processes:
■ Process 8309 is the first ttyd process launched, for its parent process is 1.
■ Processes 8312 and 8313 correspond to asynchronous interfaces with the
terminal numbers of 6 and 7 on router 10.110.96.44 respectively, and their
parent process is process 8309.
■ All processes use the default configuration file /etc/ttyd.conf.
■ You can use the kill 8309 command to kill the ttyd process 8309 and all its
child processes, that is, all the processes mentioned above.
■ You can use the kill 8312 command to kill the ttyd child processes
corresponding to the pseudo terminal ttyp40.
You are recommended to use the kill command, rather than the kill -9 command,
to kill ttyd processes.
c CAUTION: With automatic link establishment function configured on the router,

after you kill a child process and then use ps-ef, you may still find a process
corresponding to the same pseudo terminal, which is actually a new process.
Enabling ttyd autorun at system startup

1 Open the file /etc/init.d/ttyd.
# vi /etc/init.d/ttyd
2 Add the following to the file:
case "$1" in
’start’)
echo "Start ttyd ..."
# To launch multiple configuration files, list each of them in a line.
/etc/ttyd /etc/ttyd.conf
;;
’stop’)

echo "Stop ttyd ..."

pid=‘ps -ef | grep ttyd | awk ’{if ($3 == 1) print $0}’ | aw
k ’{print $2}’‘
if [ ! "$pid" = "" ]
then
kill $pid
fi
;;
esac
3 Save your configuration and exit.
4 Link the file to the startup directory.
# chmod u+x /etc/init.d/ttyd
# ln -s /etc/init.d/ttyd /etc/rc2.d/S99ttyd
# ln -s /etc/init.d/ttyd /etc/rc0.d/K00ttyd
Installing and Using ttyd A terminal administration program named ttyadm is provided for managing ttyd
Administration Program easily on a Unix server. It consists of two executable files: ttyadmcmd and ttyadm.
ttyadm ttyadm is a shell program and can be modified as needed and run without
compilation, greatly facilitating maintenance. You can use this tool to manage ttyd
processes, without the need of entering complex commands manually. You can
also add your own shell commands into the ttyadm program as desired.
c CAUTION: The programs ttyadm, ttyd, and ttyadmcmd must be placed under the
same directory.
After logging into the Unix server as root, enter /etc/ttyadm at the prompt to
launch ttyd administration program. The following main interface appears:
******************************
ttyd Administration Program
******************************
Main menu
1 - Process management
2 - View TCP connections.
3 - View system resources.
4 - View router status.
5 - View statistics.
6 - Edit ttyd configuration file.
0 - Exit
Enter:
You can select a function by entering the corresponding number displayed on the
screen. The following describe each of the functions.
Process management
In the main interface, select option 1 to enter the process management submenu.
Then, you can manage ttyd processes by selecting the corresponding options.
******************************
******************************
Process management
1 - Start ttyd.
2 - Display ttyd processes.

3 - Terminate a ttyd process.

4 - Terminate all the ttyd processes corresponding
to a specified router IP address.
5 - Terminate the ttyd process corresponding to a
specified terminal.
6 - Set the log output level.
7 - Update the ttyd configuration file.
0 - Return to the main menu.
1 Start ttyd
From the process management submenu, select option 1 and you will be
prompted to enter the directory of the configuration file. The screen displays the
following information:
Please enter the ttyd configuration file directory (the default is

/etc/ttyd.conf):
Here, you can enter the configuration file directory of the ttyd program to be
started. The default is /etc/ttyd.conf. If you press <Enter> directly, the ttyd program
will be started directly. The operation is the same as entering /etc/ttyd
/etc/ttyd.conf at the prompt. If you press <Enter> after entering the configuration
file name, this operation is the same as entering "/etc/ttyd configuration file
name" at the prompt.
2 Display ttyd processes
From the process management submenu, select option 2 to display the ttyd
processes running in the system. The screen displays the following information:
Main process:
Process No. Port No. Debugging level Number of bytes received from socket
Number of bytes received from tty
12674 9998 0 2 57
6108 9022 3 8 69
Child process:
Process NO. Parent process No. tty device name Router IP Port No.
Terminal No. Debugging level
12676 12674 ttyp55 10.110.96.44 1219 6 0
3 Terminate a ttyd process.
From the process management submenu, select option 3 to display all the ttyd
processes running in the system. Then, you can terminate a ttyd process by
entering its process number. If you enter the process number of a ttyd main
process, all the ttyd child processes of that main process will be terminated as well.
Here is an example:
Main process:
Process No. Port No. Debugging level Number of bytes received from socket
Number of bytes received from tty
12674 9998 0 2 57
6108 9022 3 8 69
Child process:
Process NO. Main process No. tty device name Router IP Port No. T
erminal No. Debugging level
12676 12674 ttyp55 10.110.96.44 1219 6 0
Enter process NO.: 6108

Press <Enter> to return.
4 Terminate all the ttyd processes corresponding to a specified router IP address.
From the process management submenu, select option 4 to display the following
information:
Enter router IP address:
Here, you can terminate all the ttyd processes associated with a router by entering
the corresponding router IP address. This makes operation more convenient
because you can terminate multiple processes at one time.
5 Terminate the ttyd process corresponding to a specified terminal.
information:
Terminal in use: ttyp55

Enter the terminal name to terminate (ttypxx):
Here, you can terminate the ttyd process associated with a terminal by entering
the corresponding terminal name. This makes operation more convenient because
you do not need to query the number of the process before terminating it.
6 Set the log output levels.
When a system fault occurs, you may need to determine the cause by viewing the
system logs. The system creates a log file for each main ttyd process and child
process. The output directory of the ttyd debugging file(s) is /var/ttydlist by default.
The debugging file of the main ttyd process is named in the format of
ttydxxxx.log, where xxxx is the number for the listening port of the main process.
The debugging file of a child process is named in the format of ttypxx.log, where
ttypxx is the name of the ttyp device corresponding to the child process.
There are four log output levels:
■ Level 0. At this level, only error information is output.

■ Level 1. At this level, alarm information is output besides error information.
■ Level 2. At this level, prompt information is output besides error and alarm
information.
■ Level 3. At this level, besides error, alarm, and prompt information, all the data
read from and written to sockets and pseudo-terminals (PTYs) are output in the
character format and in the hexadecimal format respectively.
The default log output level is level 0; that is, only error information will be output.
To view more detailed log information, you need to adjust the log output levels.
After the log output level is set to a higher one, the debugging information that is
displayed at all the lower levels will also be output.
information:
Enter the terminal name corresponding to the process or child process.

Here, after you enter the process number or terminal name and press <Enter>, the
system will prompt you to enter the new log output level by displaying the
following information:
Enter the new log output level:
Here, the log output level for the corresponding ttyd process will be updated after
you enter the new log output level and press <Enter>.
c CAUTION:
■ When you change the log output level for a process, you can specify a main
process by providing the process number only, but you can specify a child
process either by providing the child process number or the pseudo terminal
device name corresponding to the child process.
■ If the size of a log file exceeds 1 MB, when its corresponding ttyd process starts
the next time, it will be cleared by the ttyd program and the logging will start
all over again. Therefore, save debugging logs in time.
7 Refresh the ttyd configuration file.
information:
Enter the port No. in the configuration file.
Here, when you enter the corresponding listening port number, the configuration
of the ttyd process corresponding to the configuration file is automatically
refreshed.
8 Return to the main menu.
From the process management submenu, selection option 8 to return to the main
menu.
Displaying TCP connections

In the main interface, selection option 2 to display the TCP connections in the
system. This operation is same as executing the netstat -p tcp command. The
screen displays:
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 sco2.9040 10.110.96.64.listen ESTABLISHED
tcp 0 0 sco2.ftp 10.110.96.69.1079 ESTABLISHED
tcp 0 0 sco2.9998 10.110.96.44.1219 ESTABLISHED
tcp 0 0 sco2.telnet 10.110.96.54.1235 ESTABLISHED
tcp 0 0 sco2.9021 10.110.96.48.listen ESTABLISHED

Displaying system resource information

In the main interface, select option 3 to enter the system resource submenu. Then,
you can display system resource information by selecting an option in the
following. The screen displays:
*****************************
******************************
Display system resources
1 - Display CPU resources.
2 - Display memory resources.
3 - Display stream resources.
Enter:
1 Display CPU resources.
From the system resource submenu, select option 1 to display the CPU resources in
the system. This operation is the same as executing the sar -u 1 5 command. The
following displays:
SCO_SV sco2 3.2v5.0.5 i80386 07/15/2002
14:33:16 %usr %sys %wio %idle (-u)

14:33:17 0 0 0 100
14:33:18 0 0 0 100
14:33:19 0 0 0 100
14:33:20 0 0 0 100
14:33:21 0 0 0 100
Average 0 0 0 100
2 Display memory resources.
From the system resource submenu, select option 2 to display the memory
resources in the system. This operation is the same as executing the sar -r 1 5
command. The following displays:
SCO_SV sco2 3.2v5.0.5 i80386 07/15/2002
15:03:24 freemem freeswp availrmem availsmem (-r)

15:03:25 23683 390000 28329 71244
15:03:26 23683 390000 28329 71244
15:03:27 23683 390000 28329 71244
15:03:28 23683 390000 28329 71244
15:03:29 23683 390000 28329 71244
Average 23683 390000 28329 71244
3 Display stream resources.
From the system resource submenu, select 3 to display the stream resources in the
system. The following displays:

streams allocation:
config alloc free total max fail
stream 4096 134 3962 10692 135 0
queues 566 271 295 21387 273 0
mblks 2319 445 1874 761868 2149 1
buffer headers 2746 1279 1467 52307 2654 0
class 1, 64 bytes 192 9 183 240804 172 0
class 2, 128 bytes 192 0 192 234865 168 0
class 3, 256 bytes 304 9 295 96179 292 0
class 4, 512 bytes 32 0 32 26368 32 0
class 5, 1024 bytes 32 0 32 2734 29 0
class 6, 2048 bytes 274 182 92 6460 273 0
class 7, 4096 bytes 171 170 1 185 171 0
class 8, 8192 bytes 5 0 5 70 5 0
class 9, 16384 bytes 2 0 2 3 2 0
class 10, 32768 bytes 0 0 0 0 0 0
class 11, 65536 bytes 0 0 0 0 0 0
class 12, 131072 bytes 0 0 0 0 0 0
class 13, 262144 bytes 0 0 0 0 0 0
class 14, 524288 bytes 0 0 0 0 0 0
total configured streams memory: 8000.00KB
streams memory in use: 1103.09KB
maximum streams memory used: 1569.64KB
From the system resource submenu, selection option 0 to return to the main
menu.
Displaying router status

On the main interface, select option 0 and the system prompts you for the router
IP address. After you enter the router IP address, the router status submenu
displays:
******************************
******************************
Display router status - 10.110.96.44
1 - Display brief tty information.
2 - Display detailed tty information.
3 - Display brief tty-server information.
4 - Display detailed tty-server information.
Enter:
1 Display brief tty information.
From the router status submenu, select option 1 to display the brief information of
TTYs on the corresponding router. The following displays:
INTERFACE TTY_ID VTY_ID APP_ID TTY_STATE FLOW_C BUF_SIZE RATE

Async6 6 0 6 Ok Stop 4096 0%
Async7 7 0 1 Ok Stop 4096 0%
Async7 7 1 3 Ok Stop 4096 0%
stdin: END
2 Display detailed tty information.

From the router status submenu, select option 2 to display detailed information of
TTYs on the corresponding router. Following is part of the screen display:
Tty6 Detail Statistic

Interface Used : Async6
Current State : Ok
Flow Control : Stop
Current VTY : 0
Current APP : 6
TTY Recv : 2219 Bytes
TTY Send : 2336030 Bytes
Last Recv Time : 21:59:11
Last Send Time : 21:59:11
---------------------
Current VTY Recv : 2219 Bytes
Current VTY Send : 2336030 Bytes
Current APP Recv : 2327134 Bytes
Current APP Send : 2490 Bytes
3 Display brief tty-server information.
From the router status submenu, select option 3 to display the APP summary on
the corresponding router. The following displays:
APP_ID HOST_IP PORT STATE APP_TYPE APP_NAME

1 10.110.96.53 9998 Kept Special sco1
2 10.110.96.53 9997 Kept Normal sco2
3 10.110.96.53 9900 Kept Special sco3
6 10.110.96.53 9998 Linked Special sco4
4 Display detailed tty-server information.
From the router status submenu, select option 4 to display detailed APP
information on the corresponding router. Following is part of the screen display:
App1 Detail Statistic

Server IP Address : 10.110.96.53
Server Port : 9998
Source IP Address : 0.0.0.0
Local Port : 0
Server State : Kept
Server Mode : Special
Socket RecvBuf Size : 2048 Bytes
Socket SendBufSize : 1024 Bytes
-----------------------
Socket Recv : 27371 Bytes
Socket Send : 1217 Bytes
Last Recv Time : 04:42:15
Last Send Time : 04:42:15
From the router status submenu, selection option 0 to return to the main menu.
Displaying statistics
On the main interface, select option 5 to display the following:
Terminals in use: ttyp55
Enter terminal name:

Installing and Configuring SCO UnixWare Server 787
Enter a terminal name to display all the statistics about the terminal. The following
displays:
Process ID. Parent process No. tty device name Router IP Port No.
Terminal No. Debugging level
12676 12674 ttyp55 10.110.96.44 1219 6 0
Statistics:
Total number of packets read from socket: 3
Total number of bytes read from socket: 4
Number of bytes last read from socket: 1
Time when socket was last read?2002-07-15 13:59:43
Total number of packets written to socket: 2
Total number of bytes written to socket: 116
Number of bytes last written to socket: 58
Time when socket was last written to? 2002-07-15 13:59:44
Total number of packets read from pty: 2
Total number of bytes read from pty: 116
Number of bytes last read from pty: 58
Time when pty was last read?2002-07-15 13:59:44
Total number of packets written to pty: 2
Total number of bytes written to pty: 2
Number of bytes last written to pty: 1
Time when pty was last written to? 2002-07-15 13:59:43
Editing ttyd configuration file

On the main interface, select option 6 and the system prompts you for the
configuration file name. If the entered configuration file exists, the file is opened.
If the a new configuration file name is entered, a configuration file template is
opened to facilitate the configuration file editing.
Installing and
Configuring SCO
UnixWare Server
Installing Device Drivers Using the floppy disk

Refer to “Using a floppy disk” on page 771.
Using FTP
Refer to “Using FTP” on page 772.
Configuration Adding pseudo terminals

Prerequisites ■ When the number of pseudo terminals on the SCO UnixWare server is not
enough, you can use the scoadmin configuration program to add pseudo
terminals as follows:
1 Launch scoadmin.
2 Select [Networking].
3 Select [Network Configuration Manager].
4 Select [TCP/IP].
5 Select [Protocol].
6 Select [Modify protocol configuration...].

7 Select [Advanced options].

8 Select [Pseudo ttys]. The default value is 32. Change the value to 256.
9 Compile the kernel.
# /etc/conf/bin/idbuild -B
10 Reboot the FEP.
# init 6
Then, the system can support up to 256 pseudo terminals.
■ You can also increase the number of pseudo terminals by installing programs
acp and update as follows:
1 Change the value of kernel parameter NUMSCOPT to 256.
# /etc/conf/bin/idtune NUMSCOPT 256
2 Install the acp package, which is in the first disk for SCO UnixWare. Select a
terminal number of 256 during installation.
# pkgadd -d cdrom1 acp
3 Install the update package, which is in the second disk for SCO UnixWare.
# pkgadd -d cdrom1 update711
After installation, the system rebuilds the kernel and reboots automatically.

By default, each SCO UnixWare process can open up to 64 files. If a Unix server is
to be connected with a large number of terminals (usually more than 50), you are
recommended to change the value to 400. To do so, use the following commands:
# idtune SFNOLIM 400
# idbuild -B

By default, each SCO UnixWare user can open up to 80 processes. If a Unix server
is to be connected with many terminals (usually more than 50), you are
recommended to change the value to 500. To do so, use the following commands:
# idtune MAXUP 500
# idtune NPROC 1000
# idbuild -B
Modifying System Locate the line starting with “9600:” in file /etc/ttydefs. If the echoctl option is
Configuration File present, set it to -echoctl. If Chinese cannot be used normally, add the -istrip
ttydefs option to the line. For example:
9600: 9600 sane imaxbel iexten -echoctl echoke -istrip -tabs ::: 4800
n To run ttyd on the SCO UnixWare system, you do not need to configure pseudo
terminal related parameters in file /etc/inittab.
Editing ttyd Refer to “Editing the ttyd Configuration File” on page 775.
Configuration File

Installing and Configuring SUN OS Server 789
Modifying Route The terminal access router is usually connected to the Unix server through WANs
Configuration File and therefore located on an IP segment different from that of the Unix server, in
which case you must configure a route on the Unix server.
The following example shows how to do so:
# route add -netmask 255.255.255.0 -net 10.110.96.0 63.1.1.250
mask of 255.255.255.0 and the nexthop IP address of 63.1.1.250.

Terminating ttyd on Refer to “Running ttyd” on page 778.
Unix Server
Terminating ttyd
Refer to “Terminating ttyd” on page 779.

Refer to “Enabling ttyd autorun at system startup” on page 779.
Installing and Using ttyd Refer to “Installing and Using ttyd Administration Program ttyadm” on page 780
Administration Program
ttyadm
Installing and
Configuring SUN OS
Server

n In the SUN OS system, a floppy disk is mounted automatically and no mount

operation is needed.
Using FTP

Prerequisites If there are not enough pseudo terminals on the SUN OS system, you can add new
pseudo terminals by modifying the system file as follows:
1 Open the system file.
# vi /etc/system
Add set npty=176 into the file:

3 Create the file “reconfigure”.
# touch /reconfigure

4 Reboot the system.

# reboot
The number of supported pseudo terminals is now 176.

By default, each SUN OS process can open up to 64 files. If a Unix server is to be
connected with a number of terminals (usually more than 50), change the value to
400. To do so, edit file /etc/system to add the following line:
set rlim_fd_cur = 400
After modification, you must reboot the server to bring your configuration into
effect. You do not need to change other system kernel parameters.
Modifying System Follow these steps to modify the system configuration file inittab:
Configuration File
inittab
1 Check whether a pseudo terminal has been configured in the inittab configuration
file.
Take the device ttyp50 as an example. Edit the file /etc/inittab and check whether
this file contains the following line:
T1:234:respawn:/etc/getty ttyp50
If the line is absent, add it. In the sample line, T1 is the identifier of the line. Each
line in the file inittab must have a unique identifier consisting of no more than two
characters. In system configuration file inittab, the third column of a line is
“respawn” for an active terminal and off for a dumb terminal.
2 Bring the configuration into effect after the addition.

# init q
Editing the ttyd Refer to “Editing the ttyd Configuration File” on page 775.
Configuration File
# route add -net 10.110.96.0 63.1.1.250

Terminating ttyd on the Refer to “Running ttyd” on page 778
Unix Server
Terminating ttyd

Installing and Configuring IBM AIX Server 791

Refer to “Enabling ttyd autorun at system startup” on page 779.
Installing and Using ttyd Refer to “Installing and Using ttyd Administration Program ttyadm” on page 780.
ttyadm
Installing and
Configuring IBM AIX
Server

Using FTP

Prerequisites When the number of pseudo terminals on the IBM AIX server is not enough, you
can use the smit configuration program to add pseudo terminals as follows:
1 Launch smit.
# smit
2 Select [Devices].
3 Select [PTY].
4 Select [Maximum number of BSD Pseudo-Terminals] and set it to 256. Now, the
number of supported pseudo terminals is 256.
n Adding pseudo terminals on the IBM AIX server does not require reboot.

By default, each IBM AIX user can open up to 128 processes. If a Unix server is to
be connected with many terminals (usually more than 50), change the value to
500. To do so, use the following commands:
# smit
After entering the menu interface, select the [system management] to open the
submenu.
From the submenu, select [change/show characteristics of operating system] and

change the value of [maximum number processes allowed per user] to 500.

Modifying System
Configuration File
inittab
1 Check whether the pseudo terminal has been configured in the inittab
configuration file.
Take the device ttyA6 as an example. Edit the file /etc/inittab and check whether
ttyA6:234:respawn:/usr/sbin/getty /dev/ttyA6
If the line is absent, add it. In the sample line, ttyA6 is the identifier of the line.
Each line in file inittab must have a unique identifier consisting of no more than
four characters. In system configuration file inittab, the third column of a line is
“respawn” for an active terminal and “off” for a dumb terminal.

# init q
Configuration File
# route add -net 10.110.96.0 63.1.1.250

Terminating ttyd on the Refer to “Running and Terminating ttyd on Unix Server” on page 778.
Unix Server
Terminating ttyd

Add the command for starting ttyd at the end of the file /etc/inittab.
# vi /etc/inittab
Append the following line
ttyd:23:wait:/etc/ttyd /etc/ttyd.conf
ttyadm

Installing and Configuring HP-UX Server 793
Installing and
Configuring HP-UX
Server

Using FTP
Configuration Adding VTYs

Prerequisites If there are not enough pseudo terminals on the HP-UX server, you can add new
pseudo terminals by modifying the system file as follows:
1 Launch sam.
# sam
2 Select [Kernel Configuration].
3 Select [Configurable Parameters].
Change the value of the npty parameter to 256.
4 Compile the kernel.

5 Reboot the device.
Now, the number of pseudo terminals is 256 in the directories /dev/pty and
/dev/ptym.
Link the added devices to /dev as follows:
# ln /dev/pty/ttyy0 /dev/ttyy0
# ln /dev/ptym/ptyy0 /dev/ptyy0
Modifying the maximum number of processes supported by the system

By default, the HP-UX server supports up to 664 processes. If a Unix server is to be
connected with many terminals (usually more than 50), change the value to 2000.
# sam
After entering the menu interface, select [kernel configuration] to enter the
submenu, and then select [configurable parameters] and change the value of
[nproc] to 2000.

Modifying System
Configuration File
inittab
configuration file.
Take the device ttypa as an example. Edit the file /etc/inittab and check whether
pa:3456:respawn:/usr/sbin/getty ttypa 9600
If the line is absent, add it. In the sample line, pa is the identifier of the line. Each

# init q
Editing ttyd Refer to “Editing the ttyd Configuration File” on page 775.
Configuration File
# route add net 10.110.96.0 netmask 255.255.255.0 63.1.1.250

Terminating ttyd on Refer to “Running and Terminating ttyd on Unix Server” on page 778.
Unix Server
Terminating ttyd

1 Create the file /sbin/init.d/ttyd.
# vi /sbin/init.d/ttyd
2 Add the following contents:
case "$1" in
’start_msg’)
echo "Start ttyd"
;;
’start’)
# To launch multiple configuration files, list each of them in a line.
/etc/ttyd /etc/ttyd.conf
;;
’stop_msg’)

echo "Stop ttyd"

;;
’stop’)
pid=‘ps -ef | grep ttyd | awk ’{if ($3 == 1) print $0}’ | aw
k ’{print $2}’‘
if [ ! "$pid" = "" ]
then
kill $pid
fi
;;
esac
4 Link the file to the startup directory.
# chmod u+x /sbin/init.d/ttyd
# ln -s /sbin/init.d/ttyd /sbin/rc2.d/S99ttyd
# ln -s /sbin/init.d/ttyd /sbin/rc2.d/K00ttyd
ttyadm
Installing and
Configuring Red Hat
Linux Server

Using FTP
Configuration Setting the maximum number of open files

Prerequisites By default, Red Hat Linux supports up to 1,024 open files. To change the
maximum number of open files supported, use the following command:
# ulimit -n 4096
Changing the maximum number of user processes

By default, the Red Hat Linux server supports up to 4,096 user processes.
Normally, you do not need to change this value. To change it, use the following
command:
# ulimit -u 4096
Displaying system parameters

Display system parameters by using the following command:
# ulimit -a
The following contents are displayed:

[root@redhat root]# ulimit -a

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 2048
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
Modifying System
Configuration File
inittab
configuration file.
Take the device ttypa as an example. Edit the file /etc/inittab and check whether
pa:3456:respawn:/usr/sbin/getty ttypa 9600
If the line is absent, add it. In the sample line, pa is the identifier of the line. Each
The available pseudo terminals include ttyxy, where the value of “x” ranges from a
to e and p to z and that of “y” ranges from hexadecimal 0 to f. Examples are
ttyp6, ttypa, ttyz1, and ttyz9.

# init q
3 Start ttyd before the system starts the file /etc/inittab.
To start ttyd before the system starts the file /etc/inittab, you must edit the file
/etc/rc.d/rc.sysinit; otherwise, the system will prompt a message similar to "" INIT:"
Id "v0" respawning too fast, disabled for 5 minutes" and it may take a while
before the login window appears. No such problems will occur if all these devices
present in the file inittab have been opened by ttyd. Append the following
contents to line 30 in the file /etc/rc.d/rc.sysinit:
......
# Start the graphical boot, if necessary
if [ "$BOOTUP" = "graphical" ]; then
if [ -x /usr/bin/rhgb ]; then
/usr/bin/rhgb
else
export BOOTUP=color
fi
fi
#start ttyd

/root/ttydp/ttyd /root/ttydp/tty9000.conf
/root/ttydp/ttyd /root/ttydp/tty9001.conf
sleep 10
last=0
for i in ‘LC_ALL=C grep ’^[0-9]*.*respawn:/sbin/mingetty’ /etc/initt
ab | sed ’s/
^.* tty([0-9][0-9]*).*/1/g’‘; do
......
Configuration File
# route add net 10.110.96.0 netmask 255.255.255.0 63.1.1.250
mask of 255.255.255.0 and the gateway (a router) IP address of 63.1.1.250.

Terminating ttyd on Refer to “Running ttyd” on page 778.
Unix Server
Terminating ttyd
ttyadm


TERMINAL ACCESS TROUBLESHOOTING
53
Prompts on Terminals
No. Prompt Description
1 (TTY tty-number: vty-number Creating a socket failed because, for example, no
starting connect to server fail!) WAN IP address is configured on the router.
2 (TTY tty-number: vty-number The router failed to establish a TCP connection to
fail to connect server-name!) the Unix server because, for example, the Unix
server is turned on but ttyd is not running.
3 (TTY tty-number: vty-number The corresponding entries in the ttyd configuration
authentication failed or file of the Unix server may be wrong, or the ttyd
server-name no response) listening port on the Unix server and the application
port on the router are different.
4 (TTY tty-number: vty-number The TCP connection established between the Unix
peer socket close, fail to server and the router is down. This may occur when
connect server-name!) you close ttyd on the Unix server or turn off the
Unix server.
5 (TTY tty-number: vty-number Normally, the router should be able to establish a
connecting with TCP connection to the Unix server quickly. If the
server-name...) system prompts that the connection is still not
established after a long time, the Unix server may
be off or some other problems may have occurred.
Press a key on the terminal to initiate a new
connection.
6 (TTY tty-number: vty-number A TCP connection is established between the router
success to connect with and the Unix server.
server-name)
7 (TTY tty-number: vty-number The status of the socket on the router changes
link error with server-name when the router is establishing a TCP connection or
while sending) sending data to the Unix server.
9 (TTY tty-number:%d break The router just tore down a TCP connection and is
and reconnect with reestablishing another TCP connection to the Unix
server-name) server. This message appears when a terminal user
presses the terminal reset hotkey.
10 (Out of time range, access When terminal access periods are configured in the
forbidden!) ttyd configuration file on the Unix server, this
message appears if a terminal tries to access the
Unix server during forbidden periods.
11 (authentication failed, fail to Authentication of a terminal failed. The
open pty device!) corresponding pseudo terminal on the Unix server
cannot be opened.
12 (authentication failed, too Authentication of a terminal failed. The TCP
many tcp links!) connection number established by the ttyd program
on the Unix server has reached the upper limit.
13 (authentication failed, invalid The source IP address of the TCP connection
IP address!) corresponding to the terminal is not consistent with
the IP address configured in the ttyd configuration
file on the Unix server.

800 CHAPTER 53: TERMINAL ACCESS TROUBLESHOOTING
No. Prompt Description

14 (authentication failed, invalid Authentication of a terminal failed. The terminal
TTY No.!) number is not identical to that configured in the
ttyd configuration file on the Unix server.
15 (authentication failed, Authentication of a terminal failed. An unknown
unknown error!) error occurred.
Terminal Access Check if there is any prompt displayed on the terminal

Troubleshooting
1 If there is a prompt displayed on the terminal
Refer to “Prompts on Terminals” on page 799 or “Check whether the router and
Unix server can ping each other” on page 802 for detailed information.
2 If there is no prompt displayed on the terminal
Refer to “Check whether the cable connecting the terminal to the router is OK”
on page 800.
3 Verify terminal connectivity by using the terminal connectivity test hotkey
In router terminal access, a command is provided for testing terminal connectivity.

This command can be used to test the physical connectivity between a terminal
and a router and the TCP connectivity between the terminal and the Unix server.
Once the terminal connectivity test hotkey is configured in interface view, the
terminal connectivity test function is enabled.
Now, you can enter the test hotkey on the terminal. If the physical connectivity
between the terminal and router is correct, the terminal screen will display
“Terminal to Router test OK!” if you have set the language type to English on the
Unix server. This means the connectivity between the terminal and the
asynchronous serial interface of the router is correct and they can exchange data
with each other normally. Refer to “Check whether the router and Unix server can
ping each other” on page 802. If the TCP connection between the terminal and
the Unix server is correct, the terminal screen displays “Terminal to Unix test OK!”.
This means a TCP connection has been established between the application used
by the terminal and the ttyd program on the UNIX server, and the terminal can
communicate with the server normally. Refer to “For an active terminal, verify the
configuration of system file inittab” on page 804.
Check whether the cable connecting the terminal to the router is OK

1 Pin assignment of the asynchronous serial interface and terminal access converter
If the terminal displays nothing on its screen, verify that the cable connection is
correct. Different models of terminals have different pin assignments with their
primary serial interfaces, so a certain type of converter may be required.
In terminal access, 8ASE and 16ASE modules and their cables are used the most
frequently. The connection cables for the 8ASE/16ASE modules have 8/16
asynchronous serial interfaces, namely 8AS/16AS cables, which fall into three
types: 8AS/16AS cable (DB-25/DB-9), 8AS/16AS cable (RJ-45 for telecom), and
8AS/16AS cable (RJ-45 for banks). “Telecom” means that the 8AS/16AS (RJ-45)

cables, which are blue, are for telecom carriers. “Bank” means that the 8AS/16AS
(RJ-45) cables which are white and labeled with “Dumb Terminal” are used for
terminal access in banks.
The following table describes the pins of 8AS/16AS cables.
Serial
interfa RJ-45 (for Signal Signal
ce DB-25 DB-9 telecom/banks) Signal direction description
Asynchr 5 8 8/7 CTS Ð† Clear to send
onous
6 6 7/3 DSR Ð† Data set ready
serial
interfac 3 2 6/5 RxD Ð† Receive data
e
7 5 5/4 GND - Logical ground
8 1 4/1 DCD Ð† Data carrier detect
2 3 3/6 TxD Ðü Transmit data
20 4 2/2 DTR Ðü Data terminal
ready
4 7 1/8 RTS Ðü Request to send
Terminal access converters are exclusively used for 8AS cables (RJ-45 for banks)
and 16AS cables (RJ-45 for banks) to connect to terminals. One end of the cable is
an RJ-45 receptacle for connecting to a standard network cable, and the other end
is a DB-25 receptacle for connecting to a terminal. The following table describes
the pins of the terminal access converter.
RJ-45 (female) DB-25 (female) Signal

1 8 DCD
2 6 DSR
3 20 DTR
4 7 GND
5 2 TxD
6 3 RxD
7 4 RTS
8 5 CTS
The common terminal access connection in banking systems is shown in the

following figure.

Figure 228 Terminal access joint detail
For detailed cable descriptions, refer to the related manuals.
2 3-wire, 5-wire, and 8-wire asynchronous serial interface cables
When a 3-wire asynchronous serial interface cable is used, since dsr/dtr and flow
control signal lines are absent, you must use the undo detect dsr-dtr and
flow-control none (or flow-control software inbound) commands on the
asynchronous serial interface, to not detect the dsr/dtr signals so that the
asynchronous interface automatically enters the up state, and to not detect
hardware flow control signals by adopting software flow control or no flow
control.
When a 5-wire asynchronous serial interface cable is used, since flow control
signal lines are absent, you must use the flow-control none or flow-control
software inbound command on the asynchronous interface, to not detect
hardware flow control signals by adopting software flow control or no flow
control instead.
When a 8-wire asynchronous serial interface cable is used, all the required signal
lines are available; therefore, you do not need to configure the above-mentioned
commands on the asynchronous interface.
Check whether the router and Unix server can ping each other
1 If yes
The WAN line between the router and the Unix server functions well, and the
criterion is satisfied for the router to establish a TCP connection to the server. Refer
to “Check whether the main ttyd process and its child processes are present” on
page 803.
2 If not
Check the configuration of the WAN interface of the router, the WAN line
provided by the ISP, and the router related parameters on the router and server.

Check whether the main ttyd process and its child processes are present
Use the process management function provided by the ttyd administration
program or the ps -ef | grep ttyd command to check whether the main ttyd
process and its child processes are present.
1 The ttyd main process does not exist.
The ttyd program is not running. Run the program as follows:
# /etc/ttyd
If you do not specify any parameters for the command, the default configuration
file /etc/ttyd.conf is used. To specify another configuration file, you must enter a
file name in the following format:
# /etc/ttyd /etc/ttyd9020.conf
2 The main ttyd process exits but none of its child processes does.
3 The ttyd program has been started, but no TCP connection has been established
between the router and the Unix server. First, verify that the connection modes set
on the router and the FEP are the same, for example, both in the one-to-one
mode. Then, check whether it is because the terminal authentication failed or
opening the pseudo terminal failed. Refer to the “Verify the configuration of the
router and the ttyd configuration of the server are correct and consistent.” on
page 803 or “Prompts on Terminals” on page 799. The main ttyd process and its
child processes exist.
The ttyd program has been started, and a TCP connection has been established
between the router and the Unix server. Refer to “Check whether the router has
established a TCP connection with the Unix server” on page 803.
Verify the configuration of the router and the ttyd configuration of the
server are correct and consistent.
■ Verify router configuration is correct.
■ Verify the configuration file ttyd.conf on the Unix server is correct.
■ Verify either the one-to-one or many-to-one mode is configured on both sides.
■ Verify the port numbers configured on both sides are consistent.
■ Verify the IP address and terminal number configured in ttyd.conf and those on
the router are consistent.
■ If source IP address binding is configured on the router, verify the source IP
address can be pinged through from the Unix server
Check whether the router has established a TCP connection with the Unix
server
1 Verify TCP connectivity using the terminal connectivity test hotkey
In terminal access, a command is provided for testing terminal connectivity. This

command can be used to verify the TCP connectivity between a terminal and a
Unix server. Once the terminal connectivity test hotkey is configured on the
interface, the terminal connectivity test function is enabled.

Now, you can press the test hotkey on the terminal. If the TCP connection
between the terminal and the Unix server is correct, the terminal screen displays
“Terminal to Unix test OK!”. This means a TCP connection has been established
between the application used by the terminal and the ttyd program on the UNIX
server, and the terminal can communicate with the server normally. Refer to “For
an active terminal, verify the configuration of system file inittab” on page 804 for
detailed information.
If the terminal does not display “Terminal to Unix test OK!”, no TCP connection
has been established between the application used by the terminal and the ttyd
program on the Unix server, or the corresponding pseudo terminal on the Unix
server is not operating normally. Refer to “View the debugging information of the
router and ttyd program of the server” on page 805 for detailed information.
2 Verify terminal TCP connectivity with the echo command
First, confirm the pseudo terminal ttypxx on the Unix server corresponding to the
terminal by using the configuration file ttyd.conf. Then, execute the following
command on the Unix server:
# echo "123456789" > /dev/ttypxx
This command sends the string 123456789 to the terminal ttypxx (xx indicates the
terminal index).
If the string appears on the terminal, a TCP connection has been established
between the application used by the terminal and the ttyd program on the Unix
server, and the terminal can communicate with the server normally. Refer to “For
an active terminal, verify the configuration of system file inittab” on page 804 for
detailed information.
If the string does not appear on the terminal, no TCP connection has been
established between the application used by the terminal and the ttyd program on
the Unix server, or the corresponding pseudo terminal on the Unix server is not
operating normally. Refer to the “View the debugging information of the router
and ttyd program of the server” on page 805 for detailed information.
For an active terminal, verify the configuration of system file inittab

An active terminal is a pseudo terminal that pushes the login interface.
1 The inittab system file configuration is not correct.
First, find in the configuration file ttyd.conf on the Unix server the pseudo terminal
that corresponds to the terminal, ttyp50 for example. Then, edit the file
/etc/inittab and check whether the file contains the following line:
If the line is absent, add it.
Execute the init q command to bring the configuration into effect.
# init q

You can also use the enable command to configure a pseudo terminal as an
active terminal, or use the disable command to configure a pseudo terminal as a
dumb terminal.
# enable ttyp50
2 The inittab system file configuration is correct.
X. Refer to the “View the debugging information of the router and ttyd program
of the server” on page 805.
For a dumb terminal, check whether the pseudo terminal is activated

A dumb terminal is a pseudo terminal that does not push the login interface.
Check whether the banking service process has activated the pseudo terminal. If
not, activate it. If yes, refer to the “View the debugging information of the router
and ttyd program of the server” on page 805.
View the debugging information of the router and ttyd program of the
server
A debugging file is created for each main ttyd process and child process. By
default, the destination directory of the ttyd debugging file(s) is /var/ttydlist. You
can change this directory in the configuration file ttyd.conf. The debugging file of
the main ttyd process is named in the format of ttydxxxx.log, where xxxx is the
number of the listening port of the main process. The debugging file of a child
process is named in the format of ttypxx.log, where ttypxx is the name of the ttyp
device for the child process.
The following analyses the common ttyd debugging information and provides
some solutions.
1 authentication 1.1.92.52 failed.
Cause: The ttyd configuration file contains no configuration for the router.
Solution: Configure the IP address of the router in the ttyd configuration file, and
then press <Enter> on the terminal.
2 Fail: Too many tcp links
Cause: Too many TCP connections have been established on the Unix server so
that new TCP connection requests cannot be accepted.
3 Fail: authenticate <10.110.96.44 6> fail, no such termNo in config file
Cause: The TTY number is not configured in the configuration file.
4 Fail: authenticate <10.110.96.44 6> fail, no such ip in config file
Cause: The IP address of the router, 10.110.96.44, is not configured in the

configuration file.
5 Fail: connection closed by peer
Cause: The TCP connection has been closed by the router.

6 Fail: the swap is not enough to store the data, so some data is discarded
Cause: Data from the router is not written into the PTY device (pseudo terminal),
making the buffer full and subsequent data discarded. Typically, this is because the
PTY device is not operating normally.
7 Fail:fail to write data into screen
Cause: Data on the screen cannot be saved.
8 Fail:fail to recv data from socket
Cause: Failed to read user data from the socket.
9 Fail:fail to write data into pty
Cause: Failed to write data to the PTY device.
10 Fail:fail to read pty
Cause: Failed to read data from the PTY device.
11 Fail:fail to write data into socket
Cause: Failed to write data to the socket.
12 Fail:child process exit for out of time range
Cause: The user was accessing the Unix server out of the defined periods.
13 Fail:Failed in opening pty5, out of devices
Cause: Failed to find the device.
14 Fail:Failed in opening pty5, errno=5
Cause: Failed to open device pty5. The value of the errno parameter tells the
cause.
15 Fail:It failed in binding server, so it exited
Cause: Another process is using the listening port number specified in the ttyd
configuration file.
16 Fail:It failed in opening ttyd config file
Cause: Failed to open the file with the specified path.
17 Fail:Too many main process, so can’t add the new one
Cause: Too many main ttyd processes are started up on the Unix server.
18 Fail:It failed in creating or get device xxx, so exit
Cause: Failed to create a device used by the ttyd process. This is usually resulted
from Unix system resource problems.

If you cannot locate the problem, save the debugging information of both the
router and the Unix server and send it to a customer service engineer to locate it.
Change the corresponding pseudo terminal on the Unix server

If the above-mentioned procedure cannot solve the problem, try to use another
pseudo terminal on the Unix server corresponding to the terminal by following
these steps:
1 If the pseudo terminal is an active terminal, sign off; if it is a dumb terminal,
terminate it from the banking service process and delete its configuration in the
configuration file of the banking service.
2 Modify configuration file ttyd.conf on the Unix server to change the original
pseudo terminal to a new pseudo terminal.
If the new pseudo terminal is an active terminal, make sure that you have enabled
it. If it is a dumb terminal, configure the terminal in the configuration file of the
banking service.
3 Use the process management function of the ttyd administration program or the
kill command to kill the ttyd child process corresponding to the original terminal,
or run the ttyd administration program and use the menu for refreshing
configuration file to refresh ttyd program configuration.
If the new pseudo terminal is a dumb terminal, activate this terminal in the
banking service process.


TERMINAL ACCESS FAQ
54
If there are insufficient stream resources on the Unix server, modify kernel
parameters.
If an FEP is connected to too many terminals, you need to modify the Unix kernel
of the FEP to increase stream resources to avoid insufficient stream resources in
operation.
You can view system resources utilization by using the ttyd administration program
or the following command:
# netstat -m
streams allocation:
config alloc free total max fail
stream 4096 134 3962 10692 135 0
queues 566 271 295 21387 273 0
mblks 2319 445 1874 761868 2149 1
buffer headers 2746 1279 1467 52307 2654 0
class 1, 64 bytes 192 9 183 240804 172 0
class 2, 128 bytes 192 0 192 234865 168 0
class 3, 256 bytes 304 9 295 96179 292 0
class 4, 512 bytes 32 0 32 26368 32 0
class 5, 1024 bytes 32 0 32 2734 29 0
class 6, 2048 bytes 274 182 92 6460 273 0
class 7, 4096 bytes 171 170 1 185 171 0
class 8, 8192 bytes 5 0 5 70 5 0
class 9, 16384 bytes 2 0 2 3 2 0
class 10, 32768 bytes 0 0 0 0 0 0
class 11, 65536 bytes 0 0 0 0 0 0
class 12, 131072 bytes 0 0 0 0 0 0
class 13, 262144 bytes 0 0 0 0 0 0
class 14, 524288 bytes 0 0 0 0 0 0
total configured streams memory: 8000.00KB
streams memory in use: 1103.09KB
maximum streams memory used: 1569.64KB
A value of 1 for the fail column means the system stream resources are insufficient
and you need to increase stream resources by modifying the Unix server kernel.
You can follow these steps to modify system stream resources (taking SCO
OpenServer Unix 5.0x as an example):
1 Log in to the Unix server as a superuser.

2 Enter scoadmin to run SCO OpenServer Unix administration program.
3 Select [Hardware/Kernel Manager] from the main interface to enter the level 2
interface.
4 Select [Tune Parameters...] to enter the level 3 interface.

810 CHAPTER 54: TERMINAL ACCESS FAQ
5 Under the [Configuration tunables] title, Select [12 Streams] to enter the level 4
interface.
6 Set the [NSTRPAGES] field to 2000 (the default is 500).
7 Exit to the level 2 interface and select [Relink Kernel] to recompile the kernel.
8 Exit scoadmin and reboot the Unix server.
After reboot, the change takes effect. You can use the netstat -m command to
view current system stream resources. The last but three line of command output
will show that the total configured streams memory is changed from 2,048 KB to
8,000 KB.
Some banking services cannot use pseudo terminal names containing

more than six characters
By default, the name of a pseudo terminal consists of six characters, for example,
ttyp50. But some banking services do not support pseudo terminal names
containing six or more characters. Therefore, you must modify the names to
5-character long names. The following example shows the steps:
1 Kill all the current main and child ttyd processes.
2 Modify pseudo terminal names in configuration file ttyd.conf, for example:
Original: ttyp30 10.110.96.11 0
Modified: ttya0 10.110.96.11 0
3 Modify 6-character pseudo terminal names to 5-character ones with the following
commands:
# mv /dev/ttyp30 /dev/ttya0
# mv /dev/ptyp30 /dev/ptya0
4 Modify attributes of the pseudo terminals with the following commands:
# chmod 666 /dev/ttya0
# chmod 666 /dev/ptya0
5 Synchronize with the following command:
# sync
6 For active terminals, add corresponding pseudo terminal configuration in system
file inittab by using the following command:
a0:234:respawn:/etc/getty ttya0 m
7 Add configuration entry for pseudo terminal ttya0 in the banking service
configuration file.
8 Restart the ttyd program.
Thus, 6-character VTY names are changed to 5-character ones.
A terminal does not display the login interface

A terminal does not display the login interface in the following cases:
■ Sometimes, when you kill the main ttyd process, some banking service process
may remain. In this case, when you restart ttyd, the terminal cannot be
opened.

■ The terminal has baud rates different from those of the asynchronous interface.
■ The corresponding device is not configured in file inittab.
■ The router and the Unix server use different application modes, for example,
the Unix server may use the many-to-one mode and the router may use the
one-to-one mode. Note that the router only supports the one-to-one mode
currently.
Solution:
■ For the first case, you may check the UNIX server log for a message similar to
"open ptyp10 failed: I/O error. In such a case, execute the following command
on the Unix server:
# ps -ef | grep ttyp10
Then, kill all the displayed processes associated with ttyp10.
■ For the second case, you must reconfigure the baud rates to be consistent.
■ For the third case, you must configure the corresponding device in file inittab.
■ For the fourth case, you must configure the router and the Unix server to use
the same application mode.
Terminal echoing speed is low

Use the ttyd administration program to check the system resource occupation rate
of the Unix server. If the rate is relatively high, locate which service process is
abnormal and, if necessary, kill the process.
If the rate is not high, open the ttyd configuration file to examine whether the
sendsize and readsize options are properly configured. For low speed WAN links
(at 9,600 bps for example), the two options must be modified accordingly.
In addition, for higher terminal echoing speed, one-to-one mode is recommended.
The terminal displays abnormally for some banking services

Some banking services require certain types of terminal emulation. Terminal
emulation type is configured for each pseudo terminal in system file /etc/ttytype
on the Unix server. When upgrading network devices, if you modify pseudo
terminal numbers, you must edit the system file to add terminal emulation types
for the new pseudo terminals. Taking ttyp50 as an example, you must add the
following line to the file /etc/ttytype:
vt100 ttyp50
If a pseudo terminal is configured with no terminal emulation type in file

/etc/ttytype on the Unix server, the pseudo terminal uses the default emulation
type unknown, and the prompt message at login “TERM = (unknown)” displays.
Some pseudo terminals cannot be opened

After ttyd is started, if the log does not prompt that a terminal is open, the
terminal is not open. Check the configuration file to see whether the terminal is
given a valid name.

If other configurations are all correct but the log shows that some pseudo
terminals cannot be opened, check whether the terminals are under directory /dev.
If not, try to use another existent pseudo terminal or create the pseudo terminal. If
yes, check whether a process is using the pseudo terminal.
The status of a terminal is not OK but UP on the router

If a terminal is correctly connected to the router, its status should be OK when you
use the display rta command. If its status is UP, terminal access is not started, and
you must use the rta server enable command in system view on the router to
enable terminal access.
The TCP connection is intermittently up/establishing and down

■ Verify that the same application mode (many-to-one or one-to-one) is
configured on both the router and the Unix server.
■ Verify that the router and Unix server are configured consistently and that the
configurations comply with the parameter configuration conventions. Most
mistakes result from inconsistent configurations.
■ Check whether source address binding is configured. With source address
binding configured, the router IP address configured on the Unix server must
be the bound IP address.
■ Verify that correct routes are configured on both the router and Unix server.
Illegible characters are displayed when a terminal handles a service

Check whether test, redrawing, switching hotkeys and the like are configured.
Hotkey values may conflict with data. You can change the hotkey values.
Check whether the application mode is many-to-one, which may cause data for
terminals to fall into confusion. Upgrade to a router version supporting
one-to-one mode and switch to one-to-one application mode.
Pressing menu switching hotkey cannot bring up the menu

When a terminal is listing directories or outputting data, pressing the menu
switching hotkey cannot bring up the menu. Perform VTY switching when the
terminal is idle.
With terminal access enabled, a powered terminal is still down

■ Check whether the asynchronous interface is configured with the undo
modem command.
■ Verify that the terminal cable is OK.
■ Verify that the converter connecting the terminal and the router is wired
correctly.
Only the first configuration file has a corresponding process when

multiple configuration files are configured
Check whether the listening ports configured in the configuration files are in
conflict.

The terminal cannot display the login interface after configuration and no
error message is logged on the Unix server
Check the configuration file to see whether the same application mode is
configured on the router and the Unix server. This problem occurs if the Unix
server uses the many-to-one mode and the router uses one-to-one mode.
The terminal connected to a credit card (IC card) swipe reader does not
work
Check the hardware versions of the interface modules using the display version
command.
First, check the hardware versions of the interface modules. 8AS modules have
two hardware versions: 1.x and 2.x. 8AS modules with a hardware version of 1.x
do not support card swiping and those with a hardware version of 2.x do. No such
problems happen to any other interface modules.


IP ROUTING OVERVIEW
55
Go to these sections for information you are interested in:
■ “IP Routing and Routing Table” on page 815
■ “Routing Protocol Overview” on page 817
■ “Displaying and Maintaining a Routing Table” on page 821
IP Routing and
Routing Table
Routing Routing in the Internet is achieved through routers. Upon receiving a packet, a
router finds an optimal route based on the destination address and forwards the
packet to the next router in the path until the packet reaches the last router, which
forwards the packet to the intended destination host.
Routing Table Routing table

Routing tables play a key role in routing. Each router maintains a routing table,
and each entry in the table specifies which physical interface a packet destined for
a certain destination should go out to reach the next hop (the next router) or the
directly connected destination.
Routes in a routing table can be divided into three categories by origin:
■ Direct routes: Routes discovered by data link protocols, also known as interface
routes.
■ Static routes: Routes that are manually configured.
■ Dynamic routes: Routes that are discovered dynamically by routing protocols.
Contents of a routing table

A routing table includes the following key items:
■ Destination address: Destination IP address or destination network.
■ Network mask: Specifies, in company with the destination address, the address
of the destination network. A logical AND operation between the destination
address and the network mask yields the address of the destination network.
For example, if the destination address is 129.102.8.10 and the mask
255.255.0.0, the address of the destination network is 129.102.0.0. A
network mask is made of a certain number of consecutive 1s. It can be
expressed in dotted decimal format or by the number of the 1s.
■ Outbound interface: Specifies the interface through which the IP packets are to
be forwarded.

816 CHAPTER 55: IP ROUTING OVERVIEW
■ IP address of the next hop: Specifies the address of the next router on the path.
If only the outbound interface is configured, its address will be the IP address of
the next hop.
■ Priority for the route. Routes to the same destination but having different
nexthops may have different priorities and be found by various routing
protocols or manually configured. The optimal route is the one with the highest
priority (with the smallest metric).
Routes can be divided into two categories by destination:
■ Subnet routes: The destination is a subnet.

■ Host routes: The destination is a host.
Based on whether the destination is directly connected to a given router, routes

can be divided into:
■ Direct routes: The destination is directly connected to the router.

■ Indirect routes: The destination is not directly connected to the router.
To prevent the routing table from getting too large, you can configure a default
route. All packets without matching entry in the routing table will be forwarded
through the default route.
In Figure 229, the IP address on each cloud represents the address of the network.
Router G resides in three networks and therefore has three IP addresses for its
three physical interfaces. Its routing table is shown on the right of the network
topology.

Figure 229 A sample routing table
Router A Router F
17.0.0.1 17.0.0.0 17.0.0.3
16.0.0.2 11.0.0.2
17.0.0.2
Router D
16.0.0.0 11.0.0.0
14.0.0.3
16.0.0.1 11.0.0.1
14.0.0.2 14.0.0.4
Router B 14.0.0.0 Router G
15.0.0.2 12.0.0.1
Router E 14.0.0.1
15.0.0.0 12.0.0.0
13.0.0.2
15.0.0.1 12.0.0.2
13.0.0.3 13.0.0.1
13.0.0.0
Router C Router H
Destination Network Nexthop Interface
11.0.0.0 11.0.0.1 2
12.0.0.0 12.0.0.1 1
13.0.0.0 12.0.0.2 1
14.0.0.0 14.0.0.4 3
15.0.0.0 14.0.0.2 3
16.0.0.0 14.0.0.2 3
17.0.0.0 11.0.0.2 2
Routing Protocol
Overview
Static Routing and Static routing is easy to configure and requires less system resources. It works well
Dynamic Routing in small, stable networks with simple topologies. Its major drawback is that you
must perform routing configuration again whenever the network topology
changes; it cannot adjust to network changes by itself.
Dynamic routing is based on dynamic routing protocols, which can detect network
topology changes and recalculate the routes accordingly. Therefore, dynamic
routing is suitable for large networks. Its disadvantages are that it is complicated
to configure, and that it not only imposes higher requirements on the system, but
also eats away a certain amount of network resources.
Classification of Dynamic routing protocols can be classified based on the following standards:
Dynamic Routing
Protocols

Operational scope
■ Interior gateway protocols (IGPs): Work within an autonomous system, typically
includes RIP, OSPF, and IS-IS.
■ Exterior gateway protocols (EGPs): Work between autonomous systems. The
most popular one is BGP.
n An autonomous system refers to a group of routers that share the same routing
policy and work under the same administration.
Routing algorithm
■ Distance-vector protocols: Includes mainly RIP and BGP. BGP is also considered
a path-vector protocol.
■ Link-state protocols: Includes mainly OSPF and IS-IS.
The main differences between the above two types of routing algorithms lie in the
way routes are discovered and calculated.
Type of the destination address

■ Unicast routing protocols: Includes RIP, OSPF, BGP, and IS-IS.
■ Multicast routing protocols: Includes PIM-SM and PIM-DM.
This chapter focuses on unicast routing protocols. For information on multicast

routing protocols, refer to “Multicast Overview” on page 1085.
Version of IP protocol
IPv4 routing protocols: RIP, OSPF, BGP and IS-IS.
IPv6 routing protocols: RIPng, OSPFv3, BGP4+, IPv6 IS-IS.
Routing Protocols and Different routing protocols may find different routes to the same destination.
Routing Priority However, not all of those routes are optimal. In fact, at a particular moment, only
one protocol can uniquely determine the current optimal routing to the
destination. For the purpose of route selection, each routing protocol (including
static routes) is assigned a priority. The route found by the routing protocol with
the highest priority is preferred.
The following table lists some routing protocols and the default priorities for
routes found by them.
Routing approach Priority

DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 255

Routing approach Priority

EBGP 255
UNKNOWN 256
n ■
■
The smaller the priority value, the higher the priority.
The priority for a direct route is always 0, which you cannot change. Any other
type of routes can have their priorities manually configured. 256 represents a
route from an untrustworthy source.
■ Each static route can be configured with a different priority.
■ IPv4 and IPv6 routes have their own respective routing tables.
Load Balancing and Load Balancing

Route Backup In multi-route mode, a routing protocol can be configured with multiple
equal-cost routes to the same destination. These routes have the same priority and
will all be used to accomplish load balancing if there is no route with a higher
priority available.
A given routing protocol may find several routes with the same metric to the same
destination, and if this protocol has the highest priority among all the active
protocols, these routes will be considered valid routes for load balancing.
In current implementations, routing protocols supporting load balancing are static

routing, RIP, OSPF, BGP and IS-IS.
n In current implementations, routing protocols supporting load balancing are static

routing, RIP, OSPF, BGP, and IS-IS.
Route backup
Route backup can help improve network reliability. With route backup, you can
configure multiple routes to the same destination, expecting the one with the
highest priority to be the main route and all the rest backup routes.
Under normal circumstances, packets are forwarded through the main route.
When the main route goes down, the route with the highest priority among the
backup routes is selected to forward packets. When the main route recovers, the
route selection process is performed again and the main route is selected again to
forward packets.
Route Recursion The nexthops of some BGP routes (except EBGP routes), static routes configured
with nexthops, and multi-hop RIP routes may not be directly connected. To
forward the packets, the outgoing interface to reach the nexthop must be
available. Route recursion is used to find the directly connected outgoing interface
based on the nexthop information of the route. Link-state routing protocols, such
as OSPF and IS-IS, do not need route recursion because they obtain nexthop
information through route calculation.
Sharing of Routing As different routing protocols use different algorithms to calculate routes, they
Information may find different routes. In a large network with multiple routing protocols, it is
required for routing protocols to share their routing information. Each routing

protocol has its own route redistribution mechanism. For detailed information,
refer to “Routing Policy Configuration” on page 991.
Configuring Load Load sharing is implemented in the following ways:

Sharing ■ Flow-based load sharing: After enabled with fast forwarding, a device can only
perform flow-based load sharing. For example, assume there are two
equal-cost routes on the device. If one data flow is to pass through the device,
it will be forwarded through either route; if two data flows are to pass through,
they will be forwarded through the two routes separately.
■ Packet-based load sharing: With fast forwarding disabled, the device can
evenly forward packets over the two equal-cost routes.
■ Bandwidth-based non-balanced load sharing: With fast forwarding disabled,
the device can forward packets based on the configurable bandwidths of the
interfaces. The greater bandwidth an interface has, the more packets it
forwards.
Configuring Follow these steps to enable bandwidth-based non-balanced load sharing

Bandwidth-based
Non-Balanced Load To do... Use the command... Remarks
Sharing Enter system view system-view -
Enable bandwidth-based band-based-sharing Optional
non-balanced load sharing
Disabled by default
n Bandwidth-based non-balanced load sharing does not support the load sharing of
flows. Therefore, you have to disable fast forwarding on the corresponding
outbound and inbound interfaces.
Configuring the Load Follow these steps to configure interface load sharing bandwidth:
Sharing Bandwidth for
an Interface To do... Use the command... Remarks
interface-number
Configure the load sharing loadbandwidth bandwidth Optional
bandwidth for the interface
The default is the physical
bandwidth of the interface.
n ■ The load sharing bandwidth of an interface defaults to the physical bandwidth

of the interface.
■ If you specify a value of 0 for the bandwidth argument, routing is disabled on
the interface and the interface will not be used for load sharing. But this does
not affect other states of the physical interface.

Displaying and Maintaining a Routing Table 821
Displaying and
Maintaining a Routing To do... Use the command... Remarks
Table Display brief information display ip routing-table Available in any view
about the active routes in the [ vpn-instance vpn-instance-name ]
routing table [ verbose | | { begin | exclude |
include } regular-expression ]
Display information about display ip routing-table ip-address Available in any view
routes to the specified [ mask-length | mask ]
destination [ longer-match ] [ verbose ]
Display information about display ip routing-table ip-address1 Available in any view
routes with destination { mask-length | mask } ip-address2
addresses in the specified { mask-length | mask } [ verbose ]
range
Display information about display ip routing-table acl Available in any view
routes permitted by an IPv4 acl-number [ verbose ]
basic ACL
Display routing information display ip routing-table ip-prefix Available in any view
permitted by an IPv4 prefix list ip-prefix-name [ verbose ]
Display routes of a routing display ip routing-table protocol Available in any view
protocol protocol [ inactive | verbose ]
Display statistics about the display ip routing-table Available in any view
routing table or a VPN routing [ vpn-instance vpn-instance-name ]
table statistics
Display statistics about display loadsharing ip address Available in any view
bandwidth-based load ip-address mask
sharing
Clear statistics for the routing reset ip routing-table statistics Available in user view
table or a VPN routing table protocol [ vpn-instance
vpn-instance-name ] { all | protocol }
Display brief IPv6 routing display ipv6 routing-table Available in any view
table information
Display verbose IPv6 routing display ipv6 routing-table verbose Available in any view
table information
Display routing information display ipv6 routing-table Available in any view
for a specified destination ipv6-address prefix-length
IPv6 address [ longer-match ] [ verbose ]
Display routing information display ipv6 routing-table acl Available in any view
permitted by an IPv6 ACL acl6-number [ verbose ]
Display routing information display ipv6 routing-table Available in any view
permitted by an IPv6 prefix list ipv6-prefix ipv6-prefix-name
[ verbose ]
Display IPv6 routing display ipv6 routing-table protocol Available in any view
information of a routing protocol [ inactive | verbose ]
protocol
Display IPv6 routing statistics display ipv6 routing-table statistics Available in any view
Display IPv6 routing display ipv6 routing-table Available in any view
information for an IPv6 ipv6-address1 prefix-length1
address range ipv6-address2 prefix-length2
[ verbose ]
Clear specified IPv6 routing reset ipv6 routing-table statistics Available in user view
table statistics protocol { all | protocol }

Configuration
Example
Bandwidth-based Load Network requirements

Sharing Configuration On Router A, there are three equal-cost routes to the destination network
Example 10.2.1.0 /24, as shown below:
<Sysname> display fib
Destination/Mask Nexthop Flag TimeStamp Interface
10.2.1.0/24 10.1.1.2 GSU t[0] Ethernet0/0
10.2.1.0/24 10.1.2.2 GSU t[0] Atm1/0
10.2.1.0/24 10.1.3.2 GSU t[0] Serial2/0
Use the display loadsharing ip address command to display bandwidths on

interfaces.
<Sysname> display load-sharing ip address 10.2.1.0 24

There are/is totally 3 route entry(s) to the same destination network.
Nexthop Packet(s) Bandwidth[KB] Flow(s) Interface
10.1.1.2 763851 100000 0 Ethernet0/0
10.1.2.2 1193501 155000 0 Atm1/0
10.1.3.2 15914 2048 0 Serial2/0
# The display shows that packets are load-shared according to their default
bandwidths.
Specify bandwidths fpr the three interfaces on Router A and observe the load
sharing.
Network diagram
Figure 230 Network diagram for bandwidth-based non-balanced load sharing
Router A Eth1 /0
Router B
ATM 1/0
IP network
Serial 2 /0
Serial 2/0
# Configure load sharing bandwidths for the three interfaces.
[Sysname-Ethernet0/0] loadbandwidth 200
[Sysname] interface Atm 1/0
[Sysname-Atm 1/0] loadbandwidth 100
[Sysname-Atm 1/0] quit
[Sysname] interface serial 2/0
[Sysname-serial 2/0] loadbandwidth 300
[Sysname-serial 2/0] quit

# Display bandwidths of the three interfaces.
[Sysname] display load-sharing ip address 10.2.1.0 24

There are/is totally 3 route entry(s) to the same destination network.
Nexthop Packet(s) Bandwidth[KB] Flow(s) Interface
10.1.2.2 142824 100 0 Atm1/0
10.1.1.2 285648 200 0 Ethernet0/0
10.1.3.2 428472 300 0 Serial2/0
# The display shows that packets are load-shared according to the specified
interface bandwidths.


BGP CONFIGURATION
56
Border Gateway Protocol (BGP) is a dynamic inter-AS route discovery protocol.
When configuring BGP, go to these sections for information you are interested in:
■ “BGP Overview” on page 825

■ “BGP Configuration Task List” on page 840
■ “Configuring BGP Basic Functions” on page 841
■ “Controlling Route Distribution and Reception” on page 843
■ “Configuring BGP Routing Attributes” on page 846
■ “Tuning and Optimizing BGP Networks” on page 849
■ “Configuring a Large Scale BGP Network” on page 851
■ “Configuring BGP Graceful Restart” on page 853
■ “Displaying and Maintaining BGP Configuration” on page 855
■ “BGP Typical Configuration Examples” on page 856
■ “Troubleshooting BGP Configuration” on page 874
BGP Overview Three early versions of BGP are BGP-1 (RFC1105), BGP-2 (RFC1163) and BGP-3
(RFC1267). The current version in use is BGP-4 (RFC1771). BGP-4 is rapidly
becoming the defacto Internet exterior routing protocol standard and is commonly
used between ISPs.
The characteristics of BGP are as follows:
■ Focusing on the control of route propagation and the selection of optimal

routes rather than the discovery and calculation of routes, which makes BGP,
an external routing protocol different from internal routing protocols such as
OSPF and RIP
■ Using TCP as its transport layer protocol to enhance reliability
■ Supporting CIDR
■ Substantially reducing bandwidth occupation by advertising update routes only
and applicable to advertising a great amount of routing information on the
Internet
■ Eliminating routing loops completely by adding AS path information to BGP
routes
■ Providing abundant routing policies, allowing implementing flexible route
filtering and selection
■ Easy to extend, satisfying new network developments

826 CHAPTER 56: BGP CONFIGURATION
A router advertising BGP messages is called a BGP speaker, which exchanges new
routing information with other BGP speakers. When a BGP speaker receives a new
route or a route better than the current one from another AS, it will advertise the
route to all the other BGP speakers in the local AS.
BGP speakers call each other peers, and several associated peers form a peer
group.
BGP runs on a router in one of the following two modes:
■ IBGP (Interior BGP)

■ EBGP (External BGP)
BGP is called IBGP when it runs within an AS and is called EBGP when it runs
between ASs.
Formats of BGP Header

Messages BGP message involves five types:
■ Open message
■ Update message
■ Notification message
■ Keep-alive message
■ Route-refresh message
They have the same header, as shown below:
Figure 231 BGP message header
16 bytes
Marker
Length Type
2 bytes 1 bytes
■ Marker: The 16-octet field is used for BGP authentication calculation. If no
authentication information is available, then the Marker must be all ones.
■ Length: The 2-octet unsigned integer indicates the total length of the message.
■ Type: This 1-octet unsigned integer indicates the type code of the message. The
following type codes are defined: 1-Open 2-Update 3-Notification 4-Keepalive
5-Route-refresh. The former four are defined in RFC1771, the latter one
defined in RFC2918.

BGP Overview 827
Open
After a TCP connection is established, the first message sent by each side is an
Open message for peer relationship establishment. The Open message contains
the following fields:
Figure 232 BGP open message format
0 7 15 31
Version
My Autonomous System
Hold Time
BGP Identifier
Opt Parm Len
Optional Parameters
■ Version: This 1-octet unsigned integer indicates the protocol version number of
the message. The current BGP version number is 4.
■ My Autonomous System: This 2-octet unsigned integer indicates the
Autonomous System number of the sender.
■ Hold Time: When establishing peer relationship, two parties negotiate an
identical Hold time. If no Keepalive or Update is received from a peer after the
Hold time elapses, the BGP connection is considered down.
■ BGP Identifier: In IP address format, identifying the BGP router
■ Opt Parm Len (Optional Parameters Length): Length of optional parameters, set
to 0 if no optional parameter is available
Update
Update message is used to exchange routing information between peers. It can
advertise a feasible route or remove multiple unfeasible routes. Its format is shown
below:
Figure 233 BGP Update message format
0 15 31
Unfeasible Routes Length
Withdrawn Routes(Variable)
Total Path Attribute Length
Path Attributes(Variable)
NLRI(Variable)
Each Update message can advertise a group of feasible routes with similar
attributes, which are contained in the Network Layer Reachable Information field.
The Path Attributes field carries attributes of these routes that are used by BGP for
routing. Each message can also carry multiple withdrawn routes in the Withdrawn
Routes field.

■ Unfeasible Routes Length: The total length of the Withdrawn Routes field in
octets. A value of 0 indicates neither route is being withdrawn from service,
nor Withdrawn Routes field is present in this Update message.
■ Withdrawn Routes: This is a variable length field that contains a list of IP
prefixes of routes that are being withdrawn from service.
■ Total Path Attribute Length: Total length of the Path Attributes field in octets. A
value of 0 indicates that no Network Layer Reachability Information field is
present in this Update message.
■ Path Attributes: List of path attributes related to NLRI. Each path attribute is a
triple <attribute type, attribute length, attribute value> of variable length. BGP
uses these attributes to avoid routing loops, perform routing and protocol
extension.
■ NLRI (Network Layer Reachability Information): Reachability information is
encoded as one or more 2-tuples of the form <length, prefix>.
Notification
A Notification message is sent when an error is detected. The BGP connection is
closed immediately after sending it. Notification message format is shown below:
Figure 234 BGP Notification message format
0 7 15 31
Error Code Error SubCode
Data
■ Error Code: Type of Notification.

■ Error Subcode: Specific information about the nature of the reported error.
■ Data: Used to diagnose the reason for the Notification. The contents of the
Data field depend upon the Error Code and Error Subcode. Erroneous part of
data is recorded. The Data field length is variable.
Keepalive
Keepalive messages are sent between peers to maintain connectivity. Its format
contains only the message header.
Route-refresh
A route-refresh message is sent to a peer to request the resending of the specified
address family routing information. Its format is shown below:
Figure 235 BGP Route-refresh message format
0 15 23 31
AFI Res. SAFI
AFI: Address Family Identifier.
Res: Reserved. Set to 0.
SAFI: Subsequent Address Family Identifier.

BGP Overview 829
BGP Path Attributes Classification of path attributes

Path attributes fall into four categories:
■ Well-known mandatory: Must be recognized by all BGP routers and must be
included in every update message. Routing information error occurs without
this attribute.
■ Well-known discretionary: Can be recognized by all BGP routers and optional
to be included in every update message as needed.
■ Optional transitive: Transitive attribute between ASs. A BGP router not
supporting this attribute can still receive routes with this attribute and advertise
them to other peers.
■ Optional non-transitive: If a BGP router does not support this attribute, it will
not advertise routes with this attribute.
The usage of each BGP path attributes is described in the following table.
Table 40 Usage of BGP path attributes
Name Category
ORIGIN Well-known mandatory
AS_PATH Well-known mandatory
NEXT_HOP Well-known mandatory
LOCAL_PREF Well-known discretionary
ATOMIC_AGGREGATE Well-known discretionary
AGGREGATOR Optional transitive
COMMUNITY Optional transitive
MULTI_EXIT_DISC (MED) Optional non-transitive
ORIGINATOR_ID Optional non-transitive
CLUSTER_LIST Optional non-transitive
Usage of BGP path attributes

1 ORIGIN
ORIGIN is a well-known mandatory attribute and defines the origin of routing

information and how a route becomes a BGP route. It involves three types:
■ IGP: Has the highest priority. Routes added to the BGP routing table using the
network command have the IGP attribute.
■ EGP: Has the second highest priority. Routes obtained via EGP have the EGP
attribute.
■ incomplete: Has the lowest priority. The source of routes with this attribute is
unknown, which does not mean such routes are unavailable. The routes
redistributed from other routing protocols have the incomplete attribute.
2 AS_PATH
AS_PATH is a well-known mandatory attribute. This attribute identifies the

autonomous systems through which routing information carried in this Update
message has passed. When a route is advertised from the local AS to another AS,
each passed AS number is added into the AS_PATH attribute, thus the receiver can

determine ASs to route massages back. The number of the AS closest with the
receiver’s AS is leftmost, as shown below:
Figure 236 AS_PATH attribute
8.0.0.0
AS 10
D=8.0.0.0 D=8.0.0.0
(10) (10)
AS 20 AS 40
D=8.0.0.0 D=8.0.0.0
(20,10) (40,10)
D=8.0.0.0
(30,20,10)
AS 30 AS 50
In general, a BGP router does not receive routes containing the local AS number to
avoid routing loops.
n The current implementation supports using the peer allow-as-loop command to

receive routes containing the local AS number to meet special requirements.
AS_PATH attribute can be used for route selection and filtering. BGP gives priority
to the route with the shortest AS_PATH length if other factors are the same. As
shown in the above figure, the BGP router in AS 50 gives priority to the route
passing AS 40 for sending information to the destination 8.0.0.0.
In some applications, you can apply a routing policy to control BGP route selection
by modifying the AS path length.
By configuring an AS path filtering list, you can filter routes based on AS numbers
contained in the AS_PATH attribute.
3 NEXT_HOP
Different from IGP, the NEXT_HOP attribute of BGP may not be the IP address of a
neighboring router. It involves three types of values, as shown in Figure 237.
■ When advertising a self-originated route to an EBGP peer, a BGP speaker sets

the NEXT_HOP for the route to the address of its sending interface.
■ When sending a received route to an EBGP peer, a BGP speaker sets the
NEXT_HOP for the route to the address of the sending interface.
■ When sending a route received from an EBGP peer to an IBGP peer, a BGP
speaker does not modify the NEXT_HOP attribute. If load-balancing is

BGP Overview 831
configured, the NEXT_HOP attribute will be modified. For load-balancing

information, refer to “BGP Route Selection” on page 832.
Figure 237 NEXT_HOP attribute
D=8.0.0.0
NEXT_HOP=1.1.1.1
AS 200 AS 100
1.1.1.1/24
1.1.2.1/24 EBGP
8.0.0.0
EBGP
D=8.0.0.0
NEXT_HOP=1.1.2.1
AS 300
IBGP
D=8.0.0.0
NEXT_HOP=1.1.2.1
4 MED (MULTI_EXIT_DISC)
The MED attribute is exchanged between two neighboring ASs, each of which will
not advertise the attribute to any other AS.
Similar with metrics used by IGP, MED is used to determine the best route for
traffic going into an AS. When a BGP router obtains multiple routes to the same
destination but with different next hops, it considers the route with the smallest
MED value the best route if other conditions are the same. As shown below, traffic
from AS 10 to AS 20 travels through Router B that is selected according to MED.
Figure 238 MED attribute
MED=0
Router B
2.1.1.1
D=9.0.0.0
NEXT_HOP=2.1.1.1 IBGP
MED=0 9.0.0.0
EBGP
Router A IBGP Router D
EBGP
D=9.0.0.0
NEXT_HOP=3.1.1.1 IBGP
MED=100 3.1.1.1
AS 10 Router C
MED=100 AS 20
In general, BGP compares MEDs of routes to the same AS only.
n The current implementation supports using the compare-different-as-med

command to force BGP to compare MED values of routes to different ASs.
5 LOCAL_PREF

This attribute is exchanged between IBGP peers only, thus not advertised to any
other AS. It indicates the priority of a BGP router.
LOCAL_PREF is used to determine the best route for traffic leaving the local AS.
When a BGP router obtains from several IBGP peers multiple routes to the same
destination but with different next hops, it considers the route with the highest
LOCAL_PREF value as the best route. As shown below, traffic from AS 20 to AS 10
travels through Router C that is selected according to LOCAL_PREF.
Figure 239 LOCAL_PREF attribute
LOCAL_PREF=100
Router B
2.1.1.1
EBGP IBGP
8.0.0.0 NEXT_HOP=2.1.1.1
LOCAL_PREF=100
Router A IBGP Router D
EBGP
D=8.0.0.0
NEXT_HOP=3.1.1.1
IBGP LOCAL_PREF=200
AS 10
3.1.1.1
Router C AS 20
LOCAL_PREF=200
6 COMMUNITY
The COMMUNITY attribute is used to simplify routing policy usage and ease
management and maintenance. It is a collection of destination addresses having
identical attributes, without physical boundaries in between, having nothing to do
with local AS. Well known community attributes include:
■ Internet: By default, all routes belong to the Internet community. Routes with
this attribute can be advertised to all BGP peers.
■ No_Export: After received, routes with this attribute cannot be advertised out
the local AS or out the local confederation but can be advertised to other sub
ASs in the confederation (for confederation information, refer to “Settlements
for Problems Caused by Large Scale BGP Networks” on page 835).
■ No_Advertise: After received, routes with this attribute cannot be advertised to
other BGP peers.
■ No_Export_Subconfed: After received, routes with this attribute cannot be
advertised out the local AS or other ASs in the local confederation.
BGP Route Selection Route selection rule

The current BGP implementation supports the following route selection rule:
■ Discard routes with unreachable NEXT_HOP first
■ Select the route with the highest Preferred_value
■ Select the route with the highest LOCAL_PREF
■ Select the route originated by the local router

BGP Overview 833
■ Select the route with the shortest AS-PATH

■ Select ORIGIN IGP, EGP, Incomplete routes in turn
■ Select the route with the lowest MED value
■ Select routes learned from EBGP, confederation, IBGP in turn
■ Select the route with the smallest next hop cost
■ Select the route with the shortest CLUSTER_LIST
■ Select the route with the smallest ORIGINATOR_ID
■ Select the route advertised by the router with the smallest Router ID
n ■ CLUSTER_IDs of route reflectors form a CLUSTER_LIST. If a route reflector

receives a route that contains its own CLUSTER ID in the CLUSTER_LIST, the
router discards the route to avoid routing loop.
■ If load balancing is configured, the system selects available routes to
implement load balancing.
Route selection with BGP load balancing

The next hop of a BGP route may not be a directly connected neighbor. One of the
reasons is next hops in routing information exchanged between IBGPs are not
modified. In this case, the router finds the direct route via IGP route entries to
reach the next hop. The direct route is called reliable route. The process of finding
a reliable route to reach a next hop is route recursion.
Currently, the system supports BGP load balancing based on route recursion,
namely if reliable routes are load balanced (suppose three next hop addresses),
BGP generates the same number of next hops to forward packets. Note that BGP
load balancing based on route recursion is always enabled by the system rather
than configured using command.
BGP differs from IGP in the implementation of load balancing in the following:
■ IGP routing protocols such as RIP, OSPF compute metrics of routes, and then
implement load balancing on routes with the same metric and to the same
destination. The route selection criterion is metric.
■ BGP has no route computation algorithm, so it cannot implement load
balancing according to metrics of routes. However, BGP has abundant route
selection rules, through which, it selects available routes for load balancing and
adds load balancing to route selection rules.
n ■ BGP implements load balancing only on routes that have the same AS_PATH
attribute, ORIGIN attribute, LOCAL_PREF and MED.
■ BGP load balancing is applicable between EBGPs, IBGPs and between
confederations.
■ If multiple routes to the same destination are available, BGP selects routes for
load balancing according to the configured maximum number of load
balanced routes.

Figure 240 Network diagram for BGP load balancing
AS 100
Router A Router B
Router C
Router E Router D
AS 200
In the above figure, Router D and Router E are IBGP peers of Router C. Router A
and Router B both advertise a route destined for the same destination to Router C.
If load balancing is configured and the two routes have the same AS_PATH
attribute, ORIGIN attribute, LOCAL_PREF and MED, Router C adds both the two
routes to its route table for load balancing. After that, Router C forwards routes to
Router D and Router E only once, with AS_PATH unchanged, NEXT_HOP changed
to Router C’s address. Other BGP transitive attributes apply according to route
selection rules.
BGP route advertisement rule

The current BGP implementation supports the following route advertisement rules:
■ When multiple available routes exist, a BGP speaker advertises only the best
route to its peers.
■ A BGP speaker advertises only routes used by itself.
■ A BGP speaker advertises routes learned from EBGPs to all BGP peers, including
both EBGP and IBGP peers.
■ A BGP speaker does not advertise routes learned from IBGPs to IBGP peers.
■ A BGP speaker advertises routes learned from IBGPs to EBGP peers. Note that if
information synchronization is disabled between BGP and IGP, IBGP routes are
advertised to EBGP peers. If enabled, only IGP advertises the IBGP routes can
these routes be advertised to EBGP peers.
■ A BGP speaker advertises all routes to a newly connected peer.
IBGP and IGP The routing Information synchronization between IBGP and IGP is for avoidance of
Information giving wrong directions to routers outside of the local AS.
Synchronization
If a non-BGP router works in an AS, a packet forwarded via the router may be
discarded due to unreachable destination. As shown in Figure 241, Router E
learned a route 8.0.0.0/8 from Router D via BGP. Then Router E sends a packet to
Router A through Router D, which finds from its routing table that Router B is the
next hop (configured using the peer next-hop-local command). Since Router D
learned the route to Router B via IGP, it forwards the packet to Router C using

BGP Overview 835
route recursion. Router C has no idea about the route 8.0.0.0/8, so it discards the
packet.
Figure 241 IBGP and IGP synchronization
AS 10 AS 30
Router A EBGP Router E

Router C
EBGP IGP IGP
IBGP
Router B Router D
AS 20
If synchronization is configured in this example, the IBGP router (Router D) checks

the learned IBGP route from its IGP routing table first. Only the route is available in
the IGP routing table can the IBGP router add the route into its BGP routing table
and advertise the route to the EBGP peer.
You can disable the synchronization feature in the following cases:
■ The local AS is not a transitive AS (AS 20 is a transitive AS in the above figure).

■ IBGP routers in the local AS are fully meshed.
Settlements for Route summarization

Problems Caused by The size of BGP routing tables on a large network is very large. Using route
Large Scale BGP summarization can reduce the routing table size.
Networks
By summarizing multiple routes with one route, a BGP router advertises only the
summary route rather than all routes.
Currently, the system supports both manual and automatic summarization. The
latter provides for controlling the attribute of a summary route and deciding
whether to advertise the route.
Route dampening
BGP route dampening is used to solve the issue of route instability such as route
flaps, that is, a route comes up and disappears in the routing table frequently.
When a route flap occurs, the routing protocol sends an update to its neighbor,
and then the neighbor needs to recalculate routes and modify the routing table.
Therefore, frequent route flaps consume large bandwidth and CPU resources even
affect normal operation of the network.
In most cases, BGP is used in complex networks, where route changes are very
frequent. To solve the problem caused by route flaps, BGP uses route dampening
to suppress unstable routes.

BGP route dampening uses a penalty value to judge the stability of a route. The
bigger the value, the less stable the route. Each time a route flap occurs (the state
change of a route from active to inactive is a route flap), BGP adds a penalty value
(1000, which is a fixed number and cannot be changed) to the route. When the
penalty value of the route exceeds the suppress value, the route is suppressed,
that is, it is neither added into the routing table, nor advertised to other BGP
peers.
The penalty value of the suppressed route will reduce to half of the suppress value
after a period of time. This period is called Half-life. When the value decreases to
the reusable threshold value, the route is added into the routing table and
advertised to other BGP peers in update packets.
Figure 242 BGP route dampening
Penalty
Value
Suppress
Threshold
Reusable
Threshold
Suppress Time
Time
Half-life
Peer group
A peer group is a collection of peers with the same attributes. When a peer joins
the peer group, the peer obtains the same configuration as the peer group. If
configuration of the peer group is changed, configuration of group members is
also changed.
There are many peers in a large BGP network. Some of these peers may be
configured with identical commands. The peer group feature simplifies
configuration of this kind.
When a peer is added into a peer group, the peer enjoys the same route update
policy as the peer group, improving route distribution efficiency.
c CAUTION: If an option is configured both for a peer and for the peer group, the
latest configuration takes effect.
Community
A peer group makes peers in it enjoy the same policy, while a community makes a
group of BGP routers in several ASs enjoy the same policy. Community is a path
attribute and advertised between BGP peers, without being limited by AS.
A BGP router can modify the community attribute for a route before sending it to
other peers.

BGP Overview 837
Besides using the well-known community attribute, you can define the extended
community attribute using a community list to help define a routing policy.
Route reflector
IBGP peers should be fully meshed to maintain connectivity. Suppose there are n
routers in an AS, the number of IBGP connections is n(n-1)/2. If there are many
IBGP peers, most network and CPU resources will be consumed.
Using route reflectors can solve the issue. In an AS, a router acts as a route
reflector, and other routers act as clients connecting to the route reflector. The
route reflector forwards (reflects) routing information between clients. BGP
connections between clients need not be established.
The router neither a route reflector nor a client is a non-client, which has to
establish connections to the route reflector and all non-clients, as shown below.
Figure 243 Network diagram for route reflector
Route
Reflector Non-Client
IBGP IBGP
Client
Cluster IBGP IBGP

IBGP IBGP
Client Client Non-Client AS 65000
The route reflector and clients form a cluster. In some cases, you can configure
more than one route reflector in a cluster to improve network reliability and
prevent single point failure, as shown in the following figure. The configured route
reflectors must have the same Cluster_ID to avoid routing loops.
Figure 244 Network diagram for route reflectors
Route Route
Reflector1 Reflector2
IBGP
Cluster
IBGP IBGP IBGP
Client Client Client

AS 65000

When clients of a route reflector are fully meshed, route reflection is unnecessary
because it consumes more bandwidth resources. The system supports using
related commands to disable route reflection in this case.
n After route reflection is disabled between clients, routes between clients and
non-clients can still be reflected.
Confederation
Confederation is another method to deal with growing IBGP connections in ASs. It
splits an AS into multiple sub ASs. In each sub AS, IBGP peers are fully meshed,
and EBGP connections are established between sub ASs, as shown below:
Figure 245 Confederation network diagram
AS 65002 AS 65003
EBGP EBGP
EBGP
IBGP
AS 100 IBGP IBGP
AS 65004
AS 200
From the perspective of a non-confederation speaker, it needs not know sub ASs
in the confederation. The ID of the confederation is the number of the AS, in the
above figure, AS 200 is the confederation ID.
The deficiency of confederation is: when changing an AS into a confederation,

you need to reconfigure your routers, and the topology will be changed.
In large-scale BGP networks, both route reflector and confederation can be used.
BGP GR
n For GR (Graceful Restart) information, refer to “GR Overview” on page 1957.
1 To establish a BGP session with a peer, a BGP GR Restarter sends an OPEN message
with GR capability to the peer.
2 Upon receipt of this message, the peer is aware that the sending router is capable
of Graceful Restart, and sends an OPEN message with GR Capability to the GR
Restarter to establish a GR session. If neither party has the GR capability, the
session established between them will not be GR capable.

BGP Overview 839
3 The GR session between the GR Restarter and its peer goes down when the GR
Restarter restarts BGP. The GR capable peer will mark all routes associated with the
GR Restarter as stale. However, during the configured GR Time, it still uses these
routes for packet forwarding, ensuring that no packet will be lost when routing
information from its peer is recollected.
4 After the restart, the GR Restarter will reestablish a GR session with its peer and
send a new GR message notifying the completion of restart. Routing information
is exchanged between them for the GR Restarter to create a new routing table
and forwarding table with stale routing information removed. Thus the BGP
routing convergence is complete.
MP-BGP Overview
The legacy BGP-4 supports IPv4, but does not support some other network layer
protocols like IPv6.
To support more network layer protocols, IETF extended BGP-4 by introducing

Multiprotocol Extensions for BGP-4 (MP-BGP), which is defined in RFC2858.
Routers supporting MP-BGP can communicate with routers not supporting

MP-BGP.
MP-BGP extended attributes

In BGP-4, the three types of attributes for IPv4, namely NLRI, NEXT_HOP and
AGGREGATOR (contains the IP address of the speaker generating the summary
route) are all carried in updates.
To support multiple network layer protocols, BGP-4 puts information about

network layer into NLRI and NEXT_HOP. MP-BGP introduced two path attributes:
■ MP_REACH_NLRI: Multiprotocol Reachable NLRI, for advertising available

routes and next hops
■ MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI, for withdrawing
unfeasible routes
The above two attributes are both Optional non-transitive, so BGP speakers not
supporting multi-protocol ignore the two attributes, not forwarding them to
peers.
Address family
MP-BGP employs address family to differentiate network layer protocols. For
address family values, refer to RFC 1700 (Assigned Numbers). Currently, the
system supports multiple MP-BGP extensions, including VPN extension, IPv6
extension. Different extensions are configured in respective address family view.
n ■ For information about the VPN extension application, refer to “MPLS L3VPN
■ For information about the IPv6 extension application, refer to “IPv6 BGP
■ This chapter gives no detailed commands related to any specific extension
application in MP-BGP address family view.

Protocols and Standards ■ RFC1771: A Border Gateway Protocol 4 (BGP-4)

■ RFC2858: Multiprotocol Extensions for BGP-4
■ RFC3392: Capabilities Advertisement with BGP-4
■ RFC2918: Route Refresh Capability for BGP-4
■ RFC2439: BGP Route Flap Damping
■ RFC1997: BGP Communities Attribute
■ RFC2796: BGP Route Reflection
■ RFC3065: Autonomous System Confederations for BGP
■ draft-ietf-idr-restart-08: Graceful Restart Mechanism for BGP
BGP Configuration To configure BGP, perform the tasks described in the following sections:
Task List
Task Description
“Configuring BGP Basic Functions” on page 841 Required
“Controlling Route Distribution and “Configuring BGP Route Optional
Reception” on page 843 Redistribution” on page
843
“Configuring BGP Route Optional
Summarization” on page
843
“Advertising a Default Optional
Route to a Peer or Peer
Group” on page 844
Distribution Policy” on
page 844
Reception Policy” on page
845
“Enabling BGP and IGP Optional
Route Synchronization”
on page 846
Dampening” on page
846
“Configuring BGP Routing Attributes” on page 846 Required
“Tuning and Optimizing BGP Networks” on page 849 Required
“Configuring a Large Scale BGP “Configuring BGP Peer Optional
Network” on page 851 Groups” on page 851
“Configuring BGP Optional
Community” on page
852
“Configuring a BGP Optional
Route Reflector” on page
853
“Configuring a BGP Optional
Confederation” on page
853
“Configuring BGP Graceful Restart” on page 853 Optional

Configuring BGP Basic Functions 841
Configuring BGP Basic The section describes BGP basic configuration.

Functions
n ■
■
This section does not differentiate between BGP and MP-BGP.
Since BGP employs TCP, you need to specify IP addresses of peers, which may
not be neighboring routers.
■ Using logical links can also establish BGP peer relationships.
■ In general, IP addresses of loopback interfaces are used to improve stability of
BGP connections.
Prerequisites The neighboring nodes are accessible to each other at the network layer.
Configuration Procedure To configure BGP basic functions, use the following commands:

Enable BGP and enter BGP bgp as-number Required
view
Specify a Router ID Router-id ip-address Optional
If no IP addresses are
configured for loopback
interface and other interfaces,
the task becomes required
Specify the AS number for a peer { group-name | Required
peer or a peer group ip-address } as-number
as-number
Configure a description for a peer { group-name | Optional
peer or a peer group ip-address } description
description-text
Enable IPv4 unicast address default ipv4-unicast Optional
family for all peers
Enabled by default
Enable a peer peer ip-address enable Optional
Enabled by default
Disable session with a peer or peer { group-name | Optional
peer group ip-address } ignore
Not disabled by default
Enable the Enable BGP log-peer-change Optional
logging on logging
Enabled by default
peer state globally
changes
Enable peer { group-name | Optional
logging for a ip-address } log-change
Enabled by default
peer or peer
group
Specify a preferred value for peer { group-name | Optional
routes from a peer or peer ip-address }
The preferred value defaults to
group preferred-value value
0


Specify the source interface peer { group-name | Optional
for establishing TCP ip-address }
By default, BGP uses the
connections to a peer or peer connect-interface
outbound interface of the best
group interface-type
route to the BGP peer as the
interface-number
source interface for establishing
a TCP connection.
Allow the establishment of peer { group-name | Optional
EBGP connection to a non ip-address } ebgp-max-hop
Not allowed by default. By
directly connected peer/peer [ hop-count ]
specifying hop-count, you can
group
specify the max hops for the
EBGP connection
c CAUTION:
■ It is required to specify for a BGP router a router ID, a 32-bit unsigned integer
and the unique identifier of the router in the AS.
■ You can specify a router ID manually. If not, the system selects an IP address as
the router ID. The selection sequence is the highest IP address among loopback
interface addresses; if not available, then the highest IP address of interfaces. It
is recommended to specify a loopback interface address as the router ID to
enhance network reliability. Only when the interface with the selected Router
ID or the manual Router ID is deleted will the system select another ID for the
router.
■ You need to create a peer group before configuring it. Refer to “Configuring
BGP Peer Groups” on page 851 for creating a peer group.
■ To establish multiple BGP connections between two devices, you need to
specify on the local router the respective source interfaces for establishing TCP
connections to the peers on the peering BGP router; otherwise, the local BGP
router may fail to establish TCP connections to the peers when using the
outbound interfaces of the best routes as the source interfaces.
■ In general, direct physical links should be available between EBGP peers. If not,
you can use the peer ebgp-max-hop command to establish a TCP connection
over multiple hops between two peers. You need not use this command for
directly connected EBGP peers, which employ loopback interfaces for peer
relationship establishment.
■ If you both reference a routing policy and use the peer { group-name |
ip-address } preferred-value value command to set a preferred value for
routes from a peer, the routing policy sets a non-zero preferred value for routes
matching it. Other routes not matching the routing policy uses the value set
with the command. If the preferred value in the routing policy is zero, the
routes matching it will also use the value set with the command. For
information about using a routing policy to set a preferred value, refer to the
command peer { group-name | ip-address } route-policy route-policy-name
{ export | import } in this document, and the command apply
preferred-value preferred-value in “Routing Policy Configuration” on page
991.

Controlling Route
Distribution and
Reception
Prerequisites Before configuring this task, you have completed BGP basic configuration.
Configuring BGP Route BGP can advertise the routing information of the local AS to peering ASs, but it
Redistribution redistributes routing information from IGP into BGP routing table rather than
self-finding. During route redistribution, BGP can filter routing information
according to different routing protocols.
To configure BGP route redistribution, use the following commands:

Enter BGP view bgp as-number -
Enable BGP to redistribute default-route imported Optional
default route into the BGP
routing table
Redistribute routes from import-route protocol Required
another routing protocol for [ process-id [ med med-value |
Not redistributed by default
advertisement route-policy
route-policy-name ] * ]
Advertise a network to the network ip-address [ mask | Optional
BGP routing table mask-length ] [ short-cut |
Not advertised by default
route-policy
route-policy-name ]
n ■ The ORIGIN attribute of routes redistributed using the import-route

command is Incomplete.
■ The ORIGIN attribute of networks advertised into the BGP routing table with
the network command is IGP. These networks must exist in the local IP routing
table, and using a routing policy makes routes control more flexible.
Configuring BGP Route To reduce the routing table size on medium and large BGP networks, you need to
Summarization configure route summarization on peers. BGP supports two summarization types:
automatic and manual.
■ Automatic summarization: Summarizes redistributed IGP subnets. With the
feature configured, BGP advertises only summary natural networks rather than
subnets. The default route and routes imported using the network command
can not be summarized.
■ Manual summarization: Summarizes BGP local routes. The manual summary
routes have higher priority than automatic ones.
To configure BGP route summarization, use the following commands:



Configure BGP Configure automatic summary automatic Required
route route summarization
No route summarization
summarization
Configure manual aggregate ip-address is configured by default
route summarization { mask | mask-length }
Choose either as needed;
[ as-set |
if both are configured,
attribute-policy
the manual route
route-policy-name |
summarization takes
detail-suppressed |
effect.
origin-policy
route-policy-name |
suppress-policy
route-policy-name ]*
Advertising a Default To advertise a default route to a peer or peer group, use the following commands:
Route to a Peer or Peer
Advertise a default route to a peer { group-name | Required
peer or peer group ip-address }
default-route-advertise
[ route-policy
route-policy-name ]
n With the peer default-route-advertise command executed, the router sends a

default route with the next hop being itself to the specified peer/peer group,
regardless of whether the default route is available in the routing table.
Configuring BGP Route To configure BGP route distribution policy, use the following commands:
Distribution Policy


Filter redistributed routes filter-policy { acl-number | Required to choose any;
when advertising them ip-prefix ip-prefix-name }
The filtering is not configured
export [ direct | isis
by default;
process-id | ospf process-id |
rip process-id | | static ] You can configure a filtering
policy as needed;
Reference a routing policy to peer { group-name |
filter routes to a peer/peer ip-address } route-policy If several filtering policies are
group route-policy-name export configured, they are applied
in the following sequence:
Reference an ACL to filer peer { group-name |
routing information to a ip-address } filter-policy ■ filter-policy export
peer/peer group acl-number export
■ peer filter-policy export
Reference an AS path ACL to peer { group-name |
■ peer as-path-acl export
filer routing information to a ip-address } as-path-acl
peer/peer group as-path-acl-number export ■ peer ip-prefix export
Reference an IP prefix list to peer { group-name | ■ peer route-policy export
filer routing information to a ip-address } ip-prefix
Only routes passing the first
peer/peer group ip-prefix-name export
policy, can they go through
the next; and only routes
passing all the configured
policies, can they be
advertised.
c CAUTION: Only routes passing the specified filter can be advertised.
Configuring BGP Route To configure BGP routing reception policy, use the following commands:
Reception Policy
Filter incoming routes filter-policy { acl-number | Required to choose any;
ip-prefix ip-prefix-name }
No inbound filtering is
import
configured by default;
Reference a routing policy to peer { group-name |
You can configure a filtering
filter routes from a peer/peer ip-address } route-policy
policy as needed;
group policy-name import
If several filtering policies are
Reference an ACL to filter peer { group-name |
configured, they are applied
routing information from a ip-address } filter-policy
in the following sequence:
peer/peer group acl-number import
■ filter-policy import
Reference an AS path ACL to peer { group-name |
filter routing information from ip-address } as-path-acl ■ peer filter-policy import
a peer/peer group as-path-acl-number import
■ peer as-path-acl import
Reference an IP prefix list to peer { group-name |
■ peer ip-prefix import
filter routing information from ip-address } ip-prefix
a peer/peer group ip-prefix-name import ■ peer route-policy import
Only routes passing the first
policy, can they go through
the next; and only routes
passing all the configured
policies, can they be received.
Specify the maximum number peer { group-name | The number is unlimited by
of routes that can be received ip-address } route-limit limit default.
from a peer/peer group [ percentage ]

c CAUTION:
■ Only routes permitted by the specified filter policy can be added into the local
BGP routing table.
■ Members of a peer group can have different inbound route filter policies from
the peer group.
Enabling BGP and IGP By default, when a BGP router receives an IBGP route, it only checks the
Route Synchronization reachability of the route’s next hop before advertisement. With BGP and IGP
synchronization configured, the BGP router cannot advertise the route to EBGP
peers unless the route is also available in the IGP routing table.
To configure BGP and IGP synchronization, use the following commands:

Enable synchronization synchronization Required
between BGP and IGP
Configuring BGP Route Through configuring BGP route dampening, you can suppress unstable routes to
Dampening neither add them to the local routing table nor advertise them to BGP peers.
To configure BGP route dampening, use the following commands:

Configure BGP route dampening [ half-life-reachable Optional
dampening half-life-unreachable reuse suppress
Not configured by
ceiling | route-policy
default
route-policy-name ] *
n Using this command dampens only routes from EBGP peers rather than IBGP
peers.
Configuring BGP
Routing Attributes
Prerequisites Before configuring this task, you have configured BGP basic functions.
Configuration Procedure You can use BGP route attributes to adjust BGP route selection policy.
To configure BGP route attributes, use the following commands:


Configuring BGP Routing Attributes 847

Configure preferences for external, internal, preference Optional
local routes { external-preference
The default
internal-preference
preferences of
local-preference |
external, internal
route-policy
and local routes are
route-policy-name }
255, 255, 130
respectively.
Configure the default value of local preference default Optional
local-preference value
The value defaults
to 100
Configure Configure the default MED value default med med-value Optional
the MED
The value defaults
attribute
to 0
Enable to compare MED values of compare-different-as- Optional
routes from different ASs med
Not enabled by
default
Enable to compare MED values of bestroute Optional
routes from each AS compare-med
Not enabled by
default
Enable to compare MED values of bestroute Optional
routes from confederation peers med-confederation
Not enabled by
default
Specify the router as the next hop of routes to peer { group-name | Optional
a peer/peer group ip-address }
By default, routes
next-hop-local
to an EBGP
peer/peer group
take the router as
the next hop, while
routes to an IBGP
peer/peer group do
not take the local
router as the next
hop.


Configure the AS_PATH Configure peer { group-name | Optional
attribute repeating times ip-address }
The local AS
of local AS allow-as-loop
number can not be
number in routes [ number ]
repeated in routes
from a peer/peer
from the peer/peer
group
group.
Disable the bestroute Optional
router from as-path-neglect
By default, the
taking AS_PATH
router takes
as a factor for
AS_PATH as a
best route
factor for best
selection
route selection
Specify a fake AS peer { group-name | Optional
number for a ip-address } fake-as
Not specified by
peer/peer group as-number
default
This command is
only applicable to
an EBGP peer or
peer group.
Substitute local peer { group-name | Optional
AS number for ip-address }
The substitution is
the AS number substitute-as
not configured by
of a peer/peer
default.
group in the
AS_PATH
attribute
Configure to not peer { group-name | Optional
keep private AS ip-address }
By default, BGP
number in public-as-only
updates carry
AS_PATH of
private AS number.
updates to a
peer/peer group
c CAUTION:
■ Using a routing policy can set a preference for routes meeting its filtering
conditions. Routes not meeting the conditions use the default preference.
■ If other conditions are identical, the route with the smallest MED value is
selected as the best external route of the AS.
■ Using the peer next-hop-local command can specify the router as the next
hop for a peer/peer group. If BGP load balancing is configured, the router
specify itself as the next hop for routes to a peer/peer group regardless of
whether the peer next-hop-local command is configured.
■ In a “third party next hop” network, that is, the two EBGP peers reside in a
common broadcast subnet, the BGP router does not specify itself as the next
hop for routes to the EBGP peer, unless the peer next-hop-local command is
configured.
■ In general, BGP checks whether the AS_PATH attribute of a route from a peer
contains the local AS number. If so, it discards the route to avoid routing loops.
■ You can specify a fake AS number to hide the real one as needed. The fake AS
number applies to EBGP peers only, that is, EBGP peers in other ASs can only
find the fake AS number.

Tuning and Optimizing BGP Networks 849
■ The peer substitute-as command is used only in specific networking

environments. Inappropriate use of the command may cause routing loops.
Tuning and This task involves the following parts:

Optimizing BGP
Networks
1 Configure BGP timers
After establishing a BGP connection, two routers send keepalive messages

periodically to each other to keep the connection. If a router receives no keepalive
message from the peer after the holdtime elapses, it tears down the connection.
When establishing a BGP connection, the two parties compare their holdtime
values, taking the shorter one as the common holdtime.
2 Reset BGP connections
After modifying a route selection policy, you have to reset BGP connections to
make the new one take effect, causing a short time disconnection. The current
BGP implementation supports the route-refresh capability. With this capability
enabled on all BGP routers in a network, when a policy is modified on a router, the
router advertises a route-refresh message to its peers, which then resend their
routing information to the router. Therefore, the local router can perform dynamic
route update and apply the new policy without tearing down BGP connections.
If a router not supporting route-refresh exists in the network, you need to

configure the peer keep-all-routes command to save all route updates, and then
use the refresh bgp command to soft reset BGP connections, which can refresh
the BGP routing table and apply the new policy without tearing down BGP
connections.
3 Configure BGP authentication
BGP employs TCP as the transport protocol. To enhance security, you can
configure BGP to perform MD5 authentication when establishing a TCP
connection. BGP MD5 authentication is not for BGP packets. It is used to set
passwords for TCP connections. If the authentication fails, the TCP connection can
not be established.
Prerequisites Before configuring this task, you have configured BGP basic functions
Configuration Procedure To tune and optimize BGP networks, use the following commands:



Configure BGP Configure timer keepalive Optional
timers keepalive keepalive hold holdtime
The keepalive interval defaults
interval and
to 60 seconds, holdtime
holdtime
defaults to 180 seconds.
Configure peer { group-name |
keepalive ip-address } timer
interval and keepalive keepalive
holdtime for a hold holdtime
peer/peer group
Configure the interval for sending peer { group-name | Optional
the same update to a peer/peer ip-address }
The intervals for sending the
group route-update-interval
same update to an IBGP peer
seconds
and an EBGP peer default to
15 seconds and 30 seconds
respectively.
Configure BGP Disable BGP peer { group-name | Optional
soft reset route-refresh ip-address }
Enabled by default
and capability-advertise
multi-protocol conventional
extensions for a
peer/peer group
Enable BGP peer { group-name | Optional
route refresh for ip-address }
Enabled by default
a peer/peer capability-advertise
group route-refresh
Keep all original peer { group-name | Optional
routes imported ip-address }
Not kept by default
from a keep-all-routes
peer/peer group
regardless of
whether they
pass the
inbound
filtering policy
Return to user return -
view
Perform manual refresh bgp { all | Required
soft reset on ip-address | group
BGP group-name | external |
connections internal } { export |
import }
Enter system system-view -
view
Clear the direct EBGP session on ebgp-interface-sensiti Optional
any interface that becomes down ve
The function is enabled by
default
Perform MD5 authentication peer { group-name | Optional
when establishing a TCP ip-address } password
Not performed by default
connection { cipher | simple }
password
Configure the number of BGP load balance number Optional
balanced routes
Load balancing is not enabled
by default.

Configuring a Large Scale BGP Network 851
c CAUTION:
■ The maximum keepalive interval should be 1/3 of the holdtime and no less
than 1 second. The holdtime is no less than 3 seconds unless it is set to 0.
■ The intervals set with the peer timer command are preferred to those set with
the timer command.
■ Use of the peer keep-all-routes command saves all routing updates from the
peer regardless of whether the filtering policy is configured. The system uses
these updates to rebuild the routing table after a soft reset is triggered.
■ Performing BGP soft reset can refresh the routing table and apply the new
policy without tearing down BGP sessions.
■ BGP soft reset requires all routers in the network have the route-refresh
capability. If not, you need use the peer keep-all-routes command to keep all
routing information from a BGP peer to perform soft reset.
■ Configured in BGP view, MD5 authentication also applies to the MP-BGP
VPNv4 extension, because the same TCP connection is used.
Configuring a Large In a large-scale BGP network, configuration and maintenance become difficult due
Scale BGP Network to so many peers. In this case, configuring peer groups makes management easier
and improves route distribution efficiency. Peer group includes IBGP peer group,
where peers belong to the same AS, and EBGP peer group, where peers belong to
different ASs. If peers in an EBGP group belong to the same external AS, the EBGP
peer group is a pure EBGP peer group, and if not, a mixed EBGP peer group.
Configuring a BGP community can also help simplify routing policy management,
and a community has much larger management range than a peer group by
controlling routing policies of multiple BGP routers.
To guarantee connectivity between IBGP peers, you need to make them fully
meshed, but it becomes unpractical when there are too many IBGP peers. Using a
route reflector or confederation can solve it. In a large-scale AS, both of them can
be used.
Configuration Before configuring this task, you have made network layer accessible on peering
Prerequisites nodes.
Configuring BGP Peer To do so, use the following commands:

Groups
Configure Create an IBGP peer group group-name Optional
an IBGP group [ internal ]
You can add multiple peers into
peer
Add a peer into the peer ip-address group the group. The system will
group
IBGP peer group group-name create these peers automatically
[ as-number and specify the local AS number
as-number ] as their AS in BGP view.


Configure Create an EBGP peer group group-name Optional
a pure group external
EBGP peer
Specify the AS number peer group-name the group. The system will
group
for the group as-number as-number create these peers automatically
and specify the local AS number
Add a peer into the peer ip-address group
as their AS in BGP view.
group group-name
[ as-number
as-number ]
Configure Create an EBGP peer group group-name Optional
a mixed group external
EBGP peer
Specify a peer and the peer ip-address the group.
group
AS number for the as-number as-number
peer respectively
Add a peer into the peer ip-address group
group group-name
[ as-number
as-number ]
c CAUTION:
■ You need not specify the AS number when creating an IBGP peer group.
■ If there are peers in a peer group, you can neither change the AS number of
the group nor use the undo command to remove the AS number
■ You need specify the AS number for each peer in a mixed EBGP peer group
respectively.
Configuring BGP To configure BGP community, use the following commands:

Community
Advertise the Advertise the peer { group-name | Required
community community attribute to ip-address }
Not configured by
attribute to a a peer/peer group advertise-communit
default
peer/peer group y
Advertise the extended peer { group-name |
community attribute to ip-address }
a peer/peer group advertise-ext-comm
unity
Apply a routing policy to routes advertised peer { group-name | Required
to a peer/peer group ip-address }
Not configured by
route-policy
default
route-policy-name
export
c CAUTION:
■ When configuring BGP community, you need to configure a routing policy to
define the community attribute, and apply the routing policy to route
advertisement.
■ For routing policy configuration, refer to “Routing Policy Configuration” on
page 991.

Configuring BGP Graceful Restart 853
Configuring a BGP Route To configure a BGP route reflector, use the following commands:
Reflector
Configure the router as a route peer { group-name | Required
reflector and specify a peer/peer ip-address } reflect-client
group as its client
Enable route reflection between reflect between-clients Optional
clients
Enabled by default
Configure the cluster ID of the reflector cluster-id Optional
route reflector cluster-id
By default, a route reflector
uses its router ID as the
cluster ID
c CAUTION:
■ In general, it is not required to make clients of a route reflector fully meshed.
The route reflector forwards routing information between clients. If clients are
fully meshed, you can disable route reflection between clients to reduce
routing costs.
■ In general, a cluster has only one route reflector, and the router ID is used to
identify the cluster. You can configure multiple route reflectors to improve
network stability. In this case, you need to specify the same cluster ID for these
route reflectors to avoid routing loops.
Configuring a BGP To configure a BGP confederation, use the following commands:

Confederation
Configure a BGP Configure a confederation id Required
confederation confederation ID as-number
Specify sub ASs confederation peer-as
contained in the as-number-list
confederation
Enable compatibility with AS confederation Optional
confederation not compliant with RFC nonstandard
By default, a confederation
3065
complies with RFC 3065.
c CAUTION:
■ A confederation contains 32 sub ASs at most. The as-number of a sub AS takes
effect in the confederation only.
■ If routers not compliant with RFC 3065 exist in the confederation, you can use
the confederation nonstandard command to make the local router
compatible with these routers.
Configuring BGP Follow these steps to configure GR on the GR Restarter and the GR Helper:
Graceful Restart

n One device can act as both the GR Restarter and GR Helper at the same time.

Enable BGP, and enter its view bgp as-number Required
Disabled by default
Enable Graceful Restart Capability graceful-restart Required
for BGP
Disabled by default
Configure the maximum time graceful-restart timer Optional
allowed for the peer to reestablish restart timer
a BGP session
Configure the maximum time to graceful-restart timer Optional
wait for the End-of-RIB (End of wait-for-rib timer
Router-Information-Base) marker
n ■ In general, the maximum time allowed for the peer to reestablish a BGP session
should be less than the Holdtime carried in the OPEN message.
■ The End-of-RIB marker can be used to indicate that the updated routing
information has been sent.

Displaying and Maintaining BGP Configuration 855
Displaying and
Maintaining BGP
Configuration
Displaying BGP
Configuration To do... Use the command... Remarks
Display peer group display bgp group [ group-name ] Available in
information any view
Display advertised BGP display bgp network
routing information
Display AS path information display bgp paths [ as-regular-expression ]
Display BGP peer/peer group display bgp peer [ ip-address { log-info |
information verbose } | group-name log-info | verbose ]
Display BGP routing display bgp routing-table [ ip-address [ { mask
information | mask-length } [ longer-prefixes ] ] ]
Display routing information display bgp routing-table as-path-acl
matching the AS path ACL as-path-acl-number
Display BGP CIDR routing display bgp routing-table cidr
information
Display BGP routing display bgp routing-table community
information matching the [ aa:nn&<1-13> ] [ no-advertise | no-export |
specified BGP community no-export-subconfed ]* [ whole-match ]
Display routing information display bgp routing-table community-list
matching a BGP community { basic-community-list-number [ whole-match ]
list | adv-community-list-number }&<1-16>
Display BGP dampened display bgp routing-table dampened
routing information
Display BGP dampening display bgp routing-table dampening
parameter information parameter
Display BGP routing display bgp routing-table
information originating from different-origin-as
different ASs
Display BGP routing flap display bgp routing-table flap-info
statistics [ regular-expression as-regular-expression |
as-path-acl as-path-acl-number | ip-address
[ { mask | mask-length } [ longer-match ] ] ]
Display routing information to display bgp routing-table peer ip-address
or from a peer { advertised-routes | received-routes }
[ network-address [ mask | mask-length ] |
statistic ]
Display routing information display bgp routing-table
matching a regular expression regular-expression as-regular-expression
Display BGP routing statistics display bgp routing-table statistic

Resetting BGP
Connections To do... Use the command... Remarks
Reset all BGP connections reset bgp all Available in
user view
Reset the BGP connections to an AS reset bgp as-number
Reset the BGP connection to a peer reset bgp ip-address
[ flap-info ]
Reset all EBGP connections reset bgp external
Reset the BGP connections to a peer reset bgp group group-name
group
Reset all IBGP connections reset bgp internal
Reset all IPv4 unicast BGP connections reset bgp ipv4 all
Clearing BGP
Information To do... Use the command... Remarks
Clear dampening routing reset bgp dampening [ ip-address [ mask Available in user
information and release | mask-length ] ] view
suppressed routes
Clear route flap information reset bgp flap-info [ regexp
as-path-regexp | as-path-acl
as-path-acl-number | ip-address [ mask |
mask-length ] ]
BGP Typical
Configuration
Examples
BGP Basic Configuration Network requirements

In Figure 246 are all BGP routers. Between Router A and Router B is an EBGP
connection. Router B, Router C and Router D are IBGP fully meshed.
Network diagram
Figure 246 Network diagram for BGP basic configuration
AS 65008 AS 65009 S2/2 S2/1

9.1 .3.2/24 9.1.2 .1/24
Router C
S 2/2 S2 /1
Eth1/0 9.1.3.1 /24 9.1.2.2/24
8.1.1 .1/8
S 2/1 S 2/1 S2 /0 S2/0

200 .1.1 .2/24 200.1.1.1 /24 9.1.1.1/24 9 .1.1.2/24
Router A Router B Router D
1 Configure IP addresses for interfaces (omitted)
2 Configure IBGP connections
# Configure Router B.

[RouterB] bgp 65009
[RouterB-bgp] router-id 2.2.2.2
[RouterB-bgp] peer 9.1.1.2 as-number 65009
[RouterB-bgp] quit
# Configure Router C.
[RouterC] bgp 65009
[RouterC-bgp] router-id 3.3.3.3
[RouterC-bgp] peer 9.1.3.1 as-number 65009
[RouterC-bgp] quit
# Configure Router D.
[RouterD] bgp 65009
[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] peer 9.1.1.1 as-number 65009
[RouterD-bgp] quit
3 Configure the EBGP connection
# Configure Router A.
[RouterA] bgp 65008
[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.1.1 as-number 65009
# Advertise network 8.0.0.0/8 to the BGP routing table.
[RouterA-bgp] network 8.0.0.0

[RouterA-bgp] quit
[RouterB] bgp 65009

[RouterB-bgp] quit
# Display BGP peer information on Router B.
[RouterB] display bgp peer
BGP local router ID : 2.2.2.2

Local AS number : 65009
Total number of peers : 3 Peers in established state : 3
Peer V AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
9.1.1.2 4 65009 56 56 0 0 00:40:54 Established

9.1.3.2 4 65009 49 62 0 0 00:44:58 Established
200.1.1.2 4 65008 49 65 0 1 00:44:03 Established

You can find Router B has established BGP connections to other routers.
# Display routing table information on Router A.
[RouterA] display bgp routing-table
Total Number of Routes: 1
BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 8.0.0.0 0.0.0.0 0 0 i
# Display routing table information on Router B.
[RouterB] display bgp routing-table

*> 8.0.0.0 200.1.1.2 0 0 65008i
# Display routing table information on Router C.
[RouterC] display bgp routing-table

i 8.0.0.0 200.1.1.2 0 100 0 65008i
n From above outputs, you can find Router A learned no route to AS65009, and
Router C learned network 8.0.0.0 but the next hop 200.1.1.2 is unreachable, thus
the route is invalid.
4 Redistribute direct routes
[RouterB] bgp 65009

[RouterB-bgp] import-route direct
# Display BGP routing table information on Router A.



*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009?
*> 9.1.3.0/24 200.1.1.1 0 0 65009?
* 200.1.1.0 200.1.1.1 0 0 65009?
# Display BGP routing table information on Router C.

*>i 8.0.0.0 200.1.1.2 0 100 0 65008i

*>i 9.1.1.0/24 9.1.3.1 0 100 0 ?
* i 9.1.3.0/24 9.1.3.1 0 100 0 ?
*>i 200.1.1.0 9.1.3.1 0 100 0 ?
You can find the route 8.0.0.0 becomes valid with the next hop as Router A.
# Ping 8.1.1.1 on Router C.
[RouterC] ping 8.1.1.1


0.00% packet loss
BGP and IGP Interaction Network requirements

Configuration As shown below, OSPF is used as the IGP protocol in AS 65009, where Router C is
a non-BGP router. Between Router A and Router B is an EBGP connection.

Network diagram
Figure 247 Network diagram for BGP and IGP interaction configuration
Eth1/0
8.1.1.1/24
AS 65009
S2/1
3.1.1.2 /24
Router A
S2 /1 Eth1/0
S 2/0 S2 /0 9.1.2.1/24
3.1.1 .1/24 9.1.1.1/24 9.1.1 .2/24
AS 65008
Router B Router C
2 Configure OSPF (omitted)
[RouterA] bgp 65008
# Advertise network 8.1.1.0/24 to the BGP routing table.
[RouterA-bgp] network 8.1.1.0 24

[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp] quit
4 Configure BGP and IGP interaction
# Configure BGP to redistribute routes from OSPF on Router B.
[RouterB] bgp 65009

[RouterB-bgp] import-route ospf 1
[RouterB-bgp] quit
# Display routing table information on Router A.



*> 8.1.1.0/24 0.0.0.0 0 0 i

*> 9.1.1.0/24 3.1.1.1 0 0 65009?
*> 9.1.2.0/24 3.1.1.1 1563 0 65009?
# Configure OSPF to redistribute routes from BGP on router B.
[RouterB] ospf
[RouterB-ospf-1] import-route bgp
[RouterB-ospf-1] quit
# Display routing table information on Router C.
<RouterC> display ip routing-table

Routing Tables: Public
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost NextHop Interface

8.1.1.0/24 O_ASE 150 1 9.1.1.1 S2/0
9.1.1.0/24 Direct 0 0 9.1.1.2 S2/0
9.1.1.1/32 Direct 0 0 9.1.1.1 S2/0
9.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
9.1.2.0/24 Direct 0 0 9.1.2.1 Eth1/0
9.1.2.1/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
5 Configure route automatic summarization
# Configure route automatic summarization on Router B.
[RouterB] bgp 65009

[RouterB-bgp] summary automatic


*> 8.1.1.0/24 0.0.0.0 0 0 i

*> 9.0.0.0 3.1.1.1 0 65009?
# Use ping for verification.
[RouterA] ping -a 8.1.1.1 9.1.2.1


0.00% packet loss
BGP Load Balancing and Network requirements

MED Attribute This example describes how to configure BGP load balancing, and how to use the
Configuration MED attribute to affect BGP route election.
As shown in the figure below, all routers run BGP, and Router A resides in AS
65008, Router B and Router C in AS 65009. Between Router A and Router B,
Router A and Router C are EBGP connections, and between Router B and Router C
is an IBGP connection.
Network diagram
Figure 248 Network diagram for BGP path selection
Router B AS 65009
AS 65008 S 2/0
200.1.1.1 /24 Eth1 /0
S2/0 9 .1.1.1/24
Eth1/0 200.1.1.2 /24 EBGP
8 .1.1.1/8 IBGP
Eth1 /0
S2/1 EBGP
9 .1.1.2/24
200.1.2 .2/24
Router A S 2/1
200.1.2.1 /24
Router C
2 Configure BGP connections
[RouterA] bgp 65008
[RouterA-bgp] network 8.0.0.0 255.0.0.0
[RouterA-bgp] quit
[RouterB] bgp 65009
[RouterB-bgp] network 9.1.1.0 255.255.255.0
[RouterB-bgp] quit

[RouterC] bgp 65009
[RouterC-bgp] network 9.1.1.0 255.255.255.0
[RouterC-bgp] quit

*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009i
* 200.1.2.1 0 0 65009i
From the above output, you can find two routes to the destination 9.1.1.0/24 are
available, and the route with the next hop 200.1.1.1 is the best route because
Router B has a smaller router ID than Router C.
3 Configure load balancing.
[RouterA] bgp 65008

[RouterA-bgp] balance 2
[RouterA-bgp] quit

*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.1.1 0 0 65009i
*> 200.1.2.1 0 0 65009i
From the above output, you can find two routes to the destination 9.1.1.0/24 are
available, and both of them are best routes.
4 Configure the MED attribute.
# Configure the default MED value for Router B.

[RouterB] bgp 65009

[RouterB-bgp] default med 100

*> 8.0.0.0 0.0.0.0 0 0 i

*> 9.1.1.0/24 200.1.2.1 0 0 65009i
* 200.1.1.1 100 0 65009i
From the above information, you can find the route with the next hop 200.1.2.1 is
the best route, because its MED (0) is smaller than the MED (100) of the other
route with the next hop 200.1.1.1 (Router B).
BGP Community Network requirements

Configuration Router B establishes EBGP connections with Router A and Router C. Configure
No_Export community attribute on Router A to make routes from AS 10 not
advertised by AS 20 to any other AS.
Network diagram
Figure 249 Network diagram for BGP community configuration
Eth1/0
9.1.1.1 /24
S2 /1
AS 10
200 .1.2 .1/24
Router A
EBGP
S2/1
200.1.2.2/24
S2/2
200.1.3.1/24 EBGP
AS 20 AS 30
S2/2
200.1.3.2/24
Router B Router C
2 Configure EBGP connections.
[RouterA] bgp 10
[RouterA-bgp] network 9.1.1.0 255.255.255.0
[RouterA-bgp] quit

[RouterB] bgp 20
[RouterB-bgp] quit
[RouterC] bgp 30
[RouterC-bgp] quit
# Display BGP routing table information on Router B.
[RouterB] display bgp routing-table 9.1.1.0

Paths: 1 available, 1 best
BGP routing table entry information of 9.1.1.0/24:

From : 200.1.2.1 (1.1.1.1)
Original nexthop: 200.1.2.1
AS-path : 10
Origin : igp
Attribute value : MED 0, pref-val 0, pre 255
State : valid, external, best,
Advertised to such 1 peers:
200.1.3.2
Router B advertised received routes to Router C in AS 30.
# Display BGP routing table information on Router C.


*> 9.1.1.0/24 200.1.3.1 0 20 10i
Router C learned the route to the destination 9.1.1.0/24 from Router B.
3 Configure BGP community attribute.
# Configure a routing policy.
[RouterA] route-policy comm_policy permit node 0

[RouterA-route-policy] apply community no-export
[RouterA-route-policy] quit

# Apply the routing policy.
[RouterA] bgp 10
[RouterA-bgp] peer 200.1.2.2 route-policy comm_policy export
[RouterA-bgp] peer 200.1.2.2 advertise-community


From : 200.1.2.1 (1.1.1.1)
Community : No-Export
AS-path : 10
Origin : igp
Attribute value : MED 0, pref-val 0, pre 255
State : valid, external, best,
Not advertised to any peers yet
You can find the configured community attribute in the above output. At this
time, the route to the destination 9.1.1.0/24 is not available in the routing table of
Router C.
BGP Route Reflector Network requirements

Configuration In the following figure, all routers run BGP.
■ Between Router A and Router B is an EBGP connection, between Router C and
Router B, Router C and Router D are IBGP connections.
■ Router C is a route reflector with clients Router B and D.
■ Router D can learn route 1.0.0.0/8 from Router C.
Network diagram
Figure 250 Network diagram for BGP route reflector configuration
Route
Reflector
Eth1/0
S2/1 S 2/0
1.1.1.1/8
193 .1 .1.1/24 194 .1.1 .1/24
S2/0 Router C
192.1.1.1 /24
Router A
S2/0 S2 /1 S2/0
192 .1 .1.2/24 193 .1 .1.2/24 194 .1.1.2/24
AS 100
AS 200 Router D
Router B
2 Configure BGP connections (omitted)

# Configure Router A
[RouterA] bgp 100
# Advertise network 1.0.0.0/8 to the BGP routing table
[RouterA-bgp] network 1.0.0.0

[RouterA-bgp] quit
# Configure Router B
[RouterB] bgp 200
[RouterB-bgp] peer 193.1.1.1 next-hop-local
[RouterB-bgp] quit
# Configure Router C
[RouterC] bgp 200
[RouterC-bgp] quit
# Configure Router D
[RouterD] bgp 200
[RouterD-bgp] quit
3 Configure route reflector
[RouterC] bgp 200

[RouterC-bgp] peer 193.1.1.2 reflect-client
[RouterC-bgp] peer 194.1.1.2 reflect-client
[RouterC-bgp] quit
# Display the BGP routing table on Router B

*> 1.0.0.0 192.1.1.1 0 0 100i

# Display the BGP routing table on Router D
[RouterD] display bgp routing-table

i 1.0.0.0 193.1.1.2 0 100 0 100i
Router D learned the route 1.0.0.0/8 from Router C.
BGP Confederation Network requirements

Configuration To reduce IBGP connections in AS 200, split it into three sub ASs, AS 65001, AS
65002 and AS 65003. Routers in AS 65001 are fully meshed.
Network diagram
Figure 251 Network diagram for BGP confederation configuration
Router B Router C
Eth1/0
Eth1/0
Eth1/0 AS 65002
S2/0 AS 65003
Router F
Eth1/0
AS 100 Eth1/1
S2/1
Eth1/0
Router A Eth1/2
Eth1/3 Eth1/1 Router D
AS 65001
Eth1/0 Eth1 /1
Router E
AS 200
Device Interface IP address Device Interface IP address
Router A S2/1 200.1.1.1/24 Router D Eth1/0 10.1.3.2/24
Eth1/0 10.1.1.1/24 Eth1/1 10.1.5.1/24
Eth1/1 10.1.2.1/24 Router E Eth1/0 10.1.4.2/24
Eth1/2 10.1.3.1/24 Eth1/1 10.1.5.2/24
Eth1/3 10.1.4.1/24 Router F Eth1/0 9.1.1.1/24
Router B Eth1/0 10.1.1.2/24 S2/0 200.1.1.2/24
Router C Eth1/0 10.1.2.2/24
2 Configure BGP confederation

[RouterA] bgp 65001
[RouterA-bgp] confederation id 200
[RouterA-bgp] confederation peer-as 65002 65003
[RouterA-bgp] peer 10.1.1.2 next-hop-local
[RouterA-bgp] quit
[RouterB] bgp 65002
[RouterB-bgp] confederation id 200
[RouterB-bgp] confederation peer-as 65001 65003
[RouterB-bgp] quit
[RouterC] bgp 65003
[RouterC-bgp] confederation id 200
[RouterC-bgp] confederation peer-as 65001 65002
[RouterC-bgp] quit
3 Configure IBGP connections in AS 65001.
[RouterA] bgp 65001

[RouterA-bgp] quit
[RouterD] bgp 65001
[RouterD-bgp] confederation id 200
[RouterD-bgp] confederation 200
[RouterD-bgp] quit
# Configure Router E.
<RouterE> system-view
[RouterE] bgp 65001
[RouterE-bgp] router-id 5.5.5.5

[RouterE-bgp] confederation id 200

[RouterE-bgp] confederation 200
[RouterE-bgp] peer 10.1.4.1 as-number 65001
[RouterE-bgp] peer 10.1.5.1 as-number 65001
[RouterE-bgp] quit
4 Configure the EBGP connection between AS 100 and AS 200.
[RouterA] bgp 65001

[RouterA-bgp] quit
# Configure Router F.
<RouterF> system-view
[RouterF] bgp 100
[RouterF-bgp] router-id 6.6.6.6
[RouterF-bgp] peer 200.1.1.1 as-number 200
[RouterF-bgp] network 9.1.1.0 255.255.255.0
[RouterF-bgp] quit
5 Verify the configuration.

*>i 9.1.1.0/24 10.1.1.1 0 100 0 (65001) 100i



From : 10.1.1.1 (1.1.1.1)
Relay Nexthop : 0.0.0.0
AS-path : (65001) 100
Origin : igp
Attribute value : MED 0, localpref 100, pref-val 0, pre 255
State : valid, external-confed, best,
# Display BGP routing table information on Router D.


*>i 9.1.1.0/24 10.1.3.1 0 100 0 100i

[RouterD] display bgp routing-table 9.1.1.0


From : 10.1.3.1 (1.1.1.1)
Relay Nexthop : 0.0.0.0
AS-path : 100
Origin : igp
Attribute value : MED 0, localpref 100, pref-val 0, pre 255
State : valid, internal, best,
BGP Path Selection Network requirements

Configuration ■ In the figure below, all routers run BGP. Between Router A and Router B,
Router A and Router C are EBGP connections. Between Router B and Router D,
Router D and Router C are IBGP connections.
■ OSPF is the IGP protocol in AS 200.
■ Configure routing policies to make Router D give priority to the route 1.0.0.0/8
learned from Router C.
Network diagram
Figure 252 Network diagram for BGP path selection configuration
AS 200
AS 100 S2/0 S 2/1
Eth1/0 Router B
S2/1
S2/0
S2/0
S2/1
Router D
S2/1 S2/0
Router A
Router C
Router A Eth1/0 1.0.0.0/8 Router D S2/0 195.1.1.1/24
S2/0 192.1.1.1/24 S2/1 194.1.1.1/24
S2/1 193.1.1.1/24 Router C S2/0 195.1.1.2/24
Router B S2/0 192.1.1.2/24 S2/1 193.1.1.2/24
S2/1 194.1.1.2/24
2 Configure OSPF on routers B, C and D

[RouterB] ospf
[RouterB-ospf] area 0
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterC] ospf
[RouterC-ospf] area 0
[RouterC-ospf-1-area-0.0.0.0] network 193.1.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.0] quit
[RouterC-ospf-1] quit
[RouterD] ospf
[RouterD-ospf] area 0
[RouterD-ospf-1-area-0.0.0.0] network 194.1.1.0 0.0.0.255
[RouterD-ospf-1-area-0.0.0.0] quit
[RouterD-ospf-1] quit
3 Configure BGP connections
[RouterA] bgp 100
# Advertise network 1.0.0.0/8 into the BGP routing table of Router A
[RouterA-bgp] network 1.0.0.0 8

[RouterA-bgp] quit
[RouterB] bgp 200

[RouterB-bgp] quit
[RouterC] bgp 200

[RouterC-bgp] quit

[RouterD] bgp 200

[RouterD-bgp] quit
4 Configure different attribute values for the route 1.0.0.0/8 to make Router D give
priority to the route learned from Router C.
■ Specify a higher MED value for the route 1.0.0.0/8 advertised to 192.1.1.2 to
make Router D give priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8

[RouterA-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterA-acl-basic-2000] quit
# Define routing policy apply_med_50 that sets the MED value of route 1.0.0.0/8
to 50, and routing policy apply_med_100 that sets the MED value of route
1.0.0.0/8 to 100.
[RouterA] route-policy apply_med_50 permit node 10

[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 50
[RouterA] route-policy apply_med_100 permit node 10
[RouterA-route-policy] if-match acl 2000
[RouterA-route-policy] apply cost 100
# Apply routing policy apply_med_50 to the route advertised to 193.1.1.2 (Router

C), and apply routing policy apply_med_100 to the route advertised to 192.1.1.2
(Router B).
[RouterA] bgp 100

[RouterA-bgp] peer 193.1.1.2 route-policy apply_med_50 export
[RouterA-bgp] peer 192.1.1.2 route-policy apply_med_100 export
[RouterA-bgp] quit
# Display the BGP routing table on Router D.

*>i 1.0.0.0 193.1.1.1 50 100 0 100i

* i 192.1.1.1 100 100 0 100i
The route 1.0.0.0/8 learned from Router C is the optimal.
■ Specify different local priorities for route 1.0.0.0/8 on Router B and C to make
Router D give priority to the route learned from Router C.
# Define ACL 2000 to permit the route 1.0.0.0/8 on Router C.

[RouterC] acl number 2000

[RouterC-acl-basic-2000] rule permit source 1.0.0.0 0.255.255.255
[RouterC-acl-basic-2000] quit
# Define routing policy localpref on Router C to set the local priority of route
1.0.0.0/8 to 200 (the default is 100).
[RouterC] route-policy localpref permit node 10

[RouterC-route-policy] if-match acl 2000
[RouterC-route-policy] apply local-preference 200
[RouterC-route-policy] quit
# Apply the routing policy localpref to the route from the peer at 193.1.1.1 on
Router C.
[RouterC] bgp 200

[RouterC-bgp] peer 193.1.1.1 route-policy localpref import
[RouterC-bgp] quit
# Display the BGP routing table on Router D.

*>i 1.0.0.0 193.1.1.1 0 200 0 100i

* i 192.1.1.1 0 100 0 100i
The route 1.0.0.0/8 learned from Router C is the optimal.
Troubleshooting BGP
Configuration
No BGP Peer Symptom

Relationship Established Display BGP peer information using the display bgp peer command. The state of
the connection to the peer cannot become established.
Analysis
To become BGP peers, any two routers need to establish a TCP session using port
179 and exchange open messages successfully.
Processing steps
1 Use the display current-configuration command to verify the peer’s AS number.
2 Use the display bgp peer command to verify the peer’s IP address.
3 If the loopback interface is used, check whether the peer connect-interface
command is configured.
4 If the peer is a non-direct EBGP peer, check whether the peer ebgp-max-hop

Troubleshooting BGP Configuration 875
5 Check whether a route to the peer is available in the routing table.

6 Use the ping command to check connectivity.
7 Use the display tcp status command to check the TCP connection.
8 Check whether an ACL disabling TCP port 179 is configured.


IS-IS CONFIGURATION
57
When configuring IS-IS, go to these sections for information you are interested in:
■ “IS-IS Overview” on page 877
■ “IS-IS Configuration Task List” on page 892
■ “Configuring IS-IS Basic Functions” on page 893
■ “Configuring IS-IS Routing Information Control” on page 894
■ “Tuning and Optimizing IS-IS Network” on page 898
■ “Configuring IS-IS GR” on page 904
■ “Displaying and Maintaining IS-IS Configuration” on page 905
■ “IS-IS Configuration Example” on page 906
IS-IS Overview Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol

designed by the International Organization for Standardization (ISO) to operate on
the connectionless network protocol (CLNP).
The IS-IS routing protocol has been modified and extended in RFC 1195 by the
International Engineer Task Force (IETF) for application in both TCP/IP and OSI
reference models, and the new one is called Integrated IS-IS or Dual IS-IS.
IS-IS is an interior gateway protocol (IGP) used within an Autonomous System. It

adopts the Shortest Path First (SPF) algorithm for route calculation.
Basic Concepts IS-IS terminology

■ Intermediate system (IS). An IS, similar to a router in TCP/IP, is the basic unit in
IS-IS protocol to generate and propagate routing information. In the following
text, an IS is a router.
■ End system (ES). An ES refers to a host system in TCP/IP. ISO defines the ES-IS
protocol for communication between an ES and an IS, therefore an ES does not
participate in the IS-IS process.
■ Routing domain (RD). A group of ISs exchange routing information with the
same routing protocol in a routing domain.
■ Area. An area is a division unit in a routing domain. The IS-IS protocol allows a
routing domain to be divided into multiple areas.
■ Link State Database (LSDB). All link states in the network forms the LSDB. There
is at least one LSDB in each IS. The IS uses SPF algorithm and LSDB to generate
its own routes.

878 CHAPTER 57: IS-IS CONFIGURATION
■ Link State Protocol Data Unit (LSP). Each IS can generate an LSP which contains
all the link state information of the IS. Each IS collects all the LSPs in the local
area to generate its own LSDB.
■ Network Protocol Data Unit (NPDU). An NPDU is a network layer protocol
packet in ISO, which is equivalent to an IP packet in TCP/IP.
■ Designated IS. On a broadcast network, the designated intermediate system is
also known as the designated IS or a pseudonode.
■ Network service access point (NSAP). The NSAP is the ISO network layer
address. It identifies an abstract network service access point and describes the
network address in the ISO reference model.
IS-IS address structure

1 NSAP
As shown in Figure 253, the NSAP address consists of the Initial Domain Part (IDP)
and the Domain Specific Part (DSP). The IDP is equal to the network ID of the IP
address, and the DSP is equal to the subnet and host IDs.
The IDP, defined by ISO, includes the Authority and Format Identifier (AFI) and the
Initial Domain Identifier (IDI).
The DSP includes the High Order DSP (HODSP), the System ID and SEL, where the
HODSP identifies the area, the System ID identifies the host, and the SEL indicates
the type of service.
The length of IDP and DSP is variable. The length of the NSAP address varies from
8 bytes to 20 bytes.
Figure 253 NSAP address structure
IDP DSP
AFI IDI High order DSP System ID (6 octet) SEL (1 octet)
Area address
2 Area address
The area address is composed of the IDP and the HODSP of the DSP, which identify
the area and the routing domain. Different routing domains cannot have the same
area address.
Generally, a router only needs one area address, and all nodes in the same routing
domain must share the same area address. However, a router can have three area
addresses at most to support smooth area merging, partitioning and switching.
3 System ID
The system ID identifies the host or router uniquely. It has a fixed length of 48 bits
(6 bytes).
The system ID is used in cooperation with the Router ID in practical. For example, a
router uses the IP address 168.10.1.1 of the Loopback 0 as the Router ID, the
system ID in IS-IS can be obtained in the following way:

IS-IS Overview 879
■ Extend each decimal number of the IP address to 3 digits by adding 0s from the
left, like 168.010.001.001;
■ Divide the extended IP address into 3 sections with 4 digits in each section to
get the System ID 1680.1000.1001.
There are other methods to define a system ID. Just make sure it can uniquely
identify a host or router.
4 SEL
The NSAP Selector (SEL), sometimes present in N-SEL, is similar with the protocol
identifier in IP. Different transport layer protocols use different SELs. All SELs in IP
are 00.
5 Routing method
Since the area is explicitly defined in the address structure, the Level-1 router can
easily recognize the packets sent out of the area. These packets are forwarded to
the Level-2 router.
The Level-1 router makes routing decisions based on the system ID. If the
destination is not in the area, the packet is forwarded to the nearest Level-1-2
router.
The Level-2 router routes packets across areas according to the area address.
NET
The Network Entity Title (NET) is an NSAP with SEL of 0. It indicates the network
layer information of the IS itself, where SEL=0 means no transport layer
information. Therefore, the length of NET is equal to NSAP, in the range 8 bytes to
20 bytes.
Generally, a router only needs one NET, but it can have three NETs at most for
smooth area merging and partitioning. When you configure multiple NETs, make
sure their system IDs are the same.
For example, a NET is ab.cdef.1234.5678.9abc.00, where,
Area = ab.cdef, System ID = 1234.5678.9abc, and SEL = 00.
IS-IS Area Two-level hierarchy

IS-IS uses two-level hierarchy in the routing domain to support large scale routing
networks. A large routing domain is divided into multiple Areas. The Level-1 router
is in charge of forwarding routes within an area, and the Level-2 router is in
charge of forwarding routes between areas.
Level-1 and Level-2

1 Level-1 router
The Level-1 router only establishes the neighbor relationship with Level-1 and
Level-1-2 routers in the same area. The LSDB maintained by the Level-1 router
contains the local area routing information. It directs the packets out of the area to
the nearest Level-1-2 router.

2 Level-2 router
The Level-2 router establishes the neighbor relationships with the Level-2 and
Level-1-2 routers in the same or in different areas. It maintains a Level-2 LSDB
which contains inter area routing information. All the Level-2 and Level-1-2
routers form the backbone in a routing domain. The backbone must be physically
contiguous. Only Level-2 routers can directly communicate with routers outside
the routing domain.
3 Level-1-2 router
A router with both Level-1 and Level-2 router functions is called a Level-1-2 router.
It can establish the Level-1 neighbor relationship with the Level-1 and Level-1-2
routers in the same area, or establish Level-2 neighbor relationship with the
Level-2 and Level-1-2 routers in different areas. A Level-1 router must be
connected to other areas via a Level-1-2 router. The Level-1-2 router maintains
two LSDBs, where the Level-1 LSDB is for routing within the area, and the Level-2
LSDB is for routing between areas.
n ■ The Level-1 routers in different areas can not establish the neighbor
relationship.
■ The neighbor relationship establishment of Level-2 routers has nothing to do
with area.
Figure 254 shows a network topology running the IS-IS protocol. Area 1 is a set of
Level-2 routers, called backbone network. The other four areas are non-backbone
networks connected to the backbone through Level-1-2 routers.
Figure 254 IS-IS topology
Area 3
Area 2
L1/L2 L1/L2
L1 L2 L2
Area 1
L2 L2
Area 5
L1/L2 L1/L2 L1
Area 4
L1 L1 L1 L1
Figure 255 shows another network topology running the IS-IS protocol. The
Level-1-2 routers connect the Level-1 and Level-2 routers, and also form the IS-IS

IS-IS Overview 881
backbone together with the Level-2 routers. There is no area defined as the
backbone in this topology. The backbone is composed of all contiguous Level-2
and Level-1-2 routers which can reside in different areas.
Figure 255 IS-IS topology
Area 1
L2
L1
Area 4
Area 2
L1/L2
L1 L1/L2 L1
Area 3
L2
n The IS-IS backbone does not need to be a specific Area.
Both the IS-IS Level-1 and Level-2 routers use the SPF algorithm to generate the
Shortest Path Tree (SPT).
Interface routing hierarchy type

You can configure the routing type for each interface. For a Level-1-2 router, one
interface may establish Level-1 adjacency with a router, and another one may
establish Level-2 adjacency with another router. You can limit the adjacency type
by configuring the routing hierarchy on the interface. For example, the level-1
interface can only establish Level-1 adjacency, while the level-2 interface can only
establish Level-2 adjacency.
By having this function, you can prevent the Level-1 hello packets from
propagating to the Level-2 backbone through the Lever-1-2 router. This can result
in bandwidth saving.
Route leaking
An IS-IS routing domain is comprised of only one Level-2 area and multiple Level-1
areas. A Level-1 area is connected with the Level-2 area rather than other Level-1
areas.
The routing information of the Level-1 area is sent to the Level-2 area through the
Level-1-2 router. Therefore, the Level-2 router knows the routing information of
the entire IS-IS routing domain but does not share the information with the
Level-1 area by default.
Since the Level-1 router simply sends the routing information for destinations
outside the area to the nearest Level-1-2 router, this may cause a problem that the
best path cannot be selected.
To solve this problem, route leaking was introduced. The Level-2 router can
advertise the Level-2 routing information to a specified Level-1 area. By having the

routing information of other areas, the Level-1 router can make a better routing
choice for the packets destined outside the area.
IS-IS Network Type Network type

IS-IS supports two network types:
■ Broadcast network, such as Ethernet, Token-Ring.
■ Point-to-point network, such as PPP, HDLC.
n For the Non-Broadcast Multi-Access (NBMA) network, such as ATM, you need to
configure point-to-point or broadcast network on its configured subinterfaces.
IS-IS does not run on Point to Multipoint (P2MP) links.
DIS and pseudonodes

On an IS-IS broadcast network, a router has to be selected as the Designated
Intermediate System (DIS).
The Level-1 and Level-2 DISs are selected respectively. You can assign different
priorities for different level DIS selections. The higher a router’s priority is, the more
likelihood the router becomes the DIS. If there are multiple routers with the same
highest DIS priority, the one with the highest SNPA (Subnetwork Point of
Attachment) address (which is the MAC address on a broadcast network) will be
selected. A router can be the DIS for different levels.
As shown in Figure 256, the same level routers and non-DIS routers on the same
network segment can establish adjacencies. This is different from OSPF.
Figure 256 DIS in the IS-IS broadcast network
L1/L2 L1/L2
L2 adjacencies
L1 L2
L1 adjacencies DIS DIS
The DIS creates and updates pseudonodes as well as their LSP to describe all
routers on the network.
The pseudonode emulates a virtual node on the broadcast network. It is not a real
router. In IS-IS, it is identified by the system ID and one byte Circuit ID (a non zero
value) of the DIS.
Using pseudonodes can reduce LSPs, the resources used by SPF and simplify the
network topology.
n On IS-IS broadcast networks, all routers are adjacent with each other. The DIS is
responsible for the synchronization of their LSDBs.

IS-IS Overview 883
IS-IS PDU Format PDU header format

The IS-IS packets are encapsulated into link layer frames. The Protocol Data Unit
(PDU) consists of two parts, the headers and the variable length field, where the
headers can be further divided into the common header and the specific header.
The common headers are the same for all PDUs, while the specific headers vary by
PDU type. The following figure shows the PDU format.
Figure 257 PDU format
PDU common header PDU specific header Variable length fields (CLV)
Common header format

Figure 258 shows the common header format.
Figure 258 PDU common header format
No. of Octets
Intradomain routing protocol discriminator 1
Length indicator 1
Version/Protocol ID extension 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1
Maximum area address 1
■ Intra-domain Routing Protocol Discriminator: Set to 0x83.

■ Length Indicator: The length of the PDU header, including both common and
specific headers, present in bytes.
■ Version/Protocol ID Extension: Set to 1(0x01).
■ ID Length: The length of the NSAP address and NET ID.
■ R(Reserved): Set to 0.
■ PDU Type: For detail information, refer to Table 41.
■ Version: Set to 1(0x01).
■ Maximum Area Address: Maximum number of area addresses supported.
Table 41 PDU type
Type PDU Type Acronym

15 Level-1 LAN IS-IS hello PDU L1 LAN IIH
16 Level-2 LAN IS-IS hello PDU L2 LAN IIH
17 Point-to-Point IS-IS hello PDU P2P IIH
18 Level-1 Link State PDU L1 LSP
20 Level-2 Link State PDU L2 LSP
24 Level-1 Complete Sequence Numbers PDU L1 CSNP
25 Level-2 Complete Sequence Numbers PDU L2 CSNP
26 Level-1 Partial Sequence Numbers PDU L1 PSNP

Table 41 PDU type
Type PDU Type Acronym

27 Level-2 Partial Sequence Numbers PDU L2 PSNP
Hello
The hello packet is used by routers to establish and maintain the neighbor
relationship. It is also called IS-to-IS hello PDU (IIH). For broadcast network, the
Level-1 router uses the Level-1 LAN IIH; and the Level-2 router uses the Level-2
LAN IIH. The P2P IIH is used on point-to-point network.
Figure 259 illustrates the hello packet format in broadcast networks, where the
blue fields are the common header.
Figure 259 L1/L2 LAN IIH format
No. of Octets
Length indicator 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1
Reserved/Circuit type 1
Source ID ID length
Holding time 2
PDU length 2
R Priority 1
LAN ID ID length+1
Variable length fields
■ Reserved/Circuit Type: The first 6 bits are reserved with value 0. The last 2 bits
indicates router types: 00 means reserved, 01 indicates L1, 10 indicates L2, and
11 indicates L1/2.
■ Source ID: The system ID of the router advertising the hello packet.
■ Holding Time: If no hello packets are received from a neighbor within the
holding time, the neighbor is considered dead.
■ PDU Length: The total length of the PDU in bytes.
■ Priority: DIS priority.
■ LAN ID: Includes the system ID and one byte pseudonode ID.
Figure 260 shows the hello packet format on the point-to-point network.

IS-IS Overview 885
Figure 260 P2P IIH format
No. of Octets
Length indicator 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1

Reserved/Circuit type 1
Source ID ID length
Holding time 2
PDU length 2
Local Circuit ID 1
Instead of the priority and LAN ID fields in the LAN IIH, the P2P IIH has a Local
Circuit ID field.
LSP packet format

The Link State PDUs (LSP) carries link state information. There are two types:
Level-1 LSP and Level-2 LSP. The Level-2 LSP is sent by the Level-2 router, and the
Level-1 LSP is sent by the Level-1 router. The level-1-2 router can sent both types
of the LSPs.
Two types of LSPs have the same format, as shown in Figure 261.

Figure 261 L1/L2 LSP format
No. of Octets
Length indicator 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1

PDU length 2
Remaining lifetime 2
LSP ID ID length+2
Sequence number 4
Checksum 2
P ATT OL IS type 1
■ PDU Length: Total length of the PDU in bytes.

■ Remaining Lifetime: LSP remaining lifetime in seconds.
■ LSP ID: Consists of the system ID, the pseudonode ID (one byte) and the LSP
fragment number (one byte).
■ Sequence Number: LSP sequence number.
■ Checksum: LSP checksum.
■ P (Partition Repair): Only related with L2 LSP, indicates whether the router
supports partition repair.
■ ATT (Attachment): Generated by the L1/L1 router, only related with L1 LSP,
indicates that the router generating the LSP is connected with multiple areas.
■ OL (LSDB Overload): Indicates that the LSDB is not complete because the router
is running out of system resources. In this condition, other routers will not send
packets to the overloaded router, except packets destined to the networks
directly connected to the router. For example, in Figure 262, Router A uses
Router B to forward its packets to Router C in normal condition. Once other
routers know the OL field on Router B is set to 1, Router A will send packets to
Router C via Router D and Router E, but still send to Router B packets destined
to the network directly connected to Router B.

IS-IS Overview 887
Figure 262 LSDB overload
Router D Router E
Router A Overload Router C
Router B
■ IS Type: Type of the router generating the LSP.
SNP format
The Sequence Number PDU (SNP) confirms the latest received LSPs. It is similar to
the Acknowledge packet, but more efficient.
SNP contains Complete SNP (CSNP) and Partial SNP (PSNP), which are further
divided into Level-1 CSNP, Level-2 CSNP, Level-1 PSNP and Level-2 PSNP.
CSNP covers the summary of all LSPs in the LSDB to synchronize the LSDB between
neighboring routers. On broadcast networks, CSNP is sent by the DIS periodically
(10s by default). On point-to-point networks, CSNP is only sent during the first
adjacency establishment.
The CSNP packet format is shown in Figure 263.
Figure 263 L1/L2 CSNP format
No. of Octets
Length indicator 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1

PDU length 2
Source ID ID length+1
Start LSP ID ID length+2
End LSP ID ID length+2
PSNP only contains the sequence numbers of one or multiple latest received LSPs.
It can acknowledge multiple LSPs at one time. When LSDBs are not synchronized,
a PSNP is used to request new LSPs from neighbors.

Figure 264 shows the PSNP packet format.
Figure 264 L1/L2 PSNP format
No. of Octets
Length indicator 1
ID length 1
R R R PDU type 1
Version 1
Reserved 1

PDU length 2
Source ID ID length+1
CLV
The variable fields of PDU are composed of multiple Code-Length-Value (CLV)
triplets. Figure 265 shows the CLV format.
Figure 265 CLV format
No. of Octets
Code 1
Length 1
Value Length
Table 42 shows different PDUs contain different CLVs.
Table 42 CLV name and the corresponding PDU type
CLV Code Name PDU Type

1 Area Addresses IIH, LSP
2 IS Neighbors (LSP) LSP
4 Partition Designated Level-2 IS L2 LSP
6 IS Neighbors (MAC Address) LAN IIH
7 IS Neighbors (SNPA Address) LAN IIH
8 Padding IIH
9 LSP Entries SNP
10 Authentication Information IIH, LSP, SNP
128 IP Internal Reachability Information LSP
129 Protocols Supported IIH, LSP
130 IP External Reachability Information L2 LSP
131 Inter-Domain Routing Protocol Information L2 LSP
132 IP Interface Address IIH, LSP

IS-IS Overview 889
Code 1 to 10 of CLV are defined in ISO 10589 (code 3 and 5 are not shown in the
table), and others are defined in RFC 1195.
IS-IS Features Supported Multiple instances and processes

IS-IS supports multiple instances and processes. Multiple processes allow a
designated IS-IS process to work in concert with a group of interfaces. This means
that a router can run multiple IS-IS processes, and each process corresponds to a
unique group of interfaces.
For routers supporting VPN, each IS-IS process is associated with a designated VPN
instance. Thus, the VPN instance is also associated with interfaces corresponding
to the process.
IS-IS Graceful Restart
n For detailed GR information, refer to “GR Overview” on page 1957.
After an IS-IS GR Restarter restarts IS-IS, it needs to complete the following two
tasks to synchronize the LSDB with its neighbors.
■ To obtain effective IS-IS neighbor information without changing adjacencies.

■ To obtain the LSDB contents.
After the restart, the GR Restarter will send an OSPF GR signal to its neighbors to
keep the adjacencies. After receiving the responses from neighbors, the GR
Restarter can restore the neighbor table.
After reestablishing neighborships, the GR Restarter will synchronize the LSDB and
exchange routing information with all adjacent GR capable neighbors. After that,
the GR Restarter will update its own routing table and forwarding table based on
the new routing information and remove the stale routes. In this way, the IS-IS
IS-IS TE
IS-IS Traffic Engineering (TE) creates and maintains the Label Switched Path (LSP).
When creating the Constraint-based Routed LSP (CR LSP), MPLS needs to get the
traffic attribute information of all links in the local area. The Traffic Engineering
information of links is obtained from IS-IS.
n For detailed configuration of the IS-IS TE, refer to “MPLS TE Configuration” on

page 1345.
Management tag
Management tag carries the management information of the IP address prefixes
and BGP community attribute. It controls the redistribution from other routing
protocols.
LSP fragment extension

IS-IS advertises link state information by flooding LSPs. One LSP carries limited
amount of link state information; therefore, IS-IS fragments LSPs. Each LSP
fragment is uniquely identified by a combination of the System ID, Pseudonode ID

(0 for a common LSP or non-zero for a Pseudonode LSP), and LSP Number (LSP
fragment number) of the node or pseudo node that generated the LSP. The 1-byte
LSP Number field, allowing a maximum of only 256 fragments to be generated by
an IS-IS router, limits the amount of link information that the IS-IS router can
advertise.
The LSP fragment extension feature allows an IS-IS router to generate more LSP
fragments. Up to 50 additional virtual systems can be configured on the router,
with each virtual system capable of generating 256 LSP fragments, to enable the
IS-IS router to generate up to 13056 LSP fragments.
1 Terms
■ Originating System
It is the router actually running IS-IS. After LSP fragment extension is enabled,
additional virtual systems can be configured for the router. Originating system is
the actual IS-IS process that originally runs.
■ System-ID
The system ID of the Originating System.
■ Additional System-ID
It is the additional virtual system ID configured for the IS-IS router after LSP
fragment extension is enabled. Each additional system ID can generate 256 LSP
fragments. Both the additional system ID and the system ID must be unique in the
entire routing domain.
■ Virtual System
Virtual System is identified by the additional system ID and generates extended LSP
fragments
■ Original LSP
It is the LSP generated by the originating system. The system ID in its LSP ID field is
the system ID of the originating system.
■ Extended LSP
It is the LSP generated by a virtual system. The system ID in its LSP ID field is the
virtual system ID.
After additional system IDs are configured, an IS-IS router can advertise more link
state information in extended LSP fragments. Each virtual system can be
considered as a virtual router. An extended LSP fragment is advertised by a virtual
system identified by additional system ID.
2 Operation modes
The LSP fragment extension feature operates in two modes on an IS-IS router:

IS-IS Overview 891
■ Mode-1: It applies to a network where some routers do not support LSP

fragment extension. In this mode, an adjacency is formed between the
originating system and each virtual system, with the link cost from the
originating system to each virtual system as 0. Thus, each virtual system acts as
a router connected to the originating system in the network, but the virtual
system is reachable through the originating system only. Therefore, the IS-IS
routers not supporting LSP fragment extension can operate normally without
modifying the extended LSP fragments received, but some limitation is
imposed on the link state information in the extended LSP fragments
advertised by the virtual systems.
■ Mode-2: This mode is recommended in a network where all the routers
support LSP fragment extension. In this mode, all the IS-IS routers in the
network know which originating system the LSPs generated by the virtual
systems belong to; therefore, no limitation is imposed on the link state
information of the extended LSP fragments advertised by the virtual systems.
The operation mode of LSP fragment extension is configured based on area and
routing level. Mode-1 is backward-compatible and allows the routers supporting
LSP fragment extension and those not supporting this feature to interoperate with
each other, but it restricts the link state information in the extended fragments.
Mode-2 does not restrict the link state information in the extended fragments.
Mode-2 is recommended in a network where all the routers that are in the same
area and at the same routing level support LSP fragment extension.
Dynamic host name mapping mechanism

The dynamic host name mapping mechanism provides the mapping between the
host names and the system IDs for the IS-IS routers. The dynamic host name
information is announced in the dynamic host name CLV of an LSP.
This mechanism also provides the mapping between a host name and the DIS of a
broadcast network, which is announced in a dynamic host name TLV of a
pseudonode LSP.
A host name is intuitively easier to remember than a system ID. After enabling this
feature on the router, you can see the host names instead of system IDs after using
the display command.
Protocols and Standards ■ ISO 10589 ISO IS-IS Routing Protocol

■ ISO 9542 ES-IS Routing Protocol
■ ISO 8348/Ad2 Network Services Access Points
■ RFC 1195 - Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
■ RFC 2763 - Dynamic Hostname Exchange Mechanism for IS-IS
■ RFC 2966 - Domain-wide Prefix Distribution with Two-Level IS-IS
■ RFC 2973 - IS-IS Mesh Groups
■ RFC 3277 - IS-IS Transient Blackhole Avoidance
■ RFC 3358 - Optional Checksums in ISIS
■ RFC 3373 - Three-Way Handshake for IS-IS Point-to-Point Adjacencies

■ RFC 3567 - Intermediate System to Intermediate System (IS-IS) Cryptographic

Authentication
■ RFC 3719 - Recommendations for Interoperable Networks using IS-IS
■ RFC 3786 - Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit
■ RFC 3787 - Recommendations for Interoperable IP Networks using IS-IS
■ RFC 3784 - IS-IS extensions for Traffic Engineering
■ RFC 3847 - Restart signaling for IS-IS
IS-IS Configuration The following table describes the IS-IS configuration tasks.
Task List
Configuration Task Remarks
“Configuring IS-IS Basic Functions” on page 893 Required
“Configuring IS-IS Routing “Specifying a Priority for IS-IS” Optional
Information Control” on on page 894
page 894
“Configuring IS-IS Link Cost” Required
on page 895
Number of Load Balanced
Routes” on page 896
“Configuring IS-IS Route Optional
Summarization” on page 896
“Advertising a Default Route” Optional
on page 897
“Configuring Inbound Route Optional
Filtering” on page 897
“Configuring Route Optional
Redistribution” on page 897
“Configuring IS-IS Route Optional
Leaking” on page 898

Configuring IS-IS Basic Functions 893
Configuration Task Remarks

“Tuning and Optimizing “Configuring a DIS Priority for Optional
IS-IS Network” on page 898 an Interface” on page 898
“Configuring IS-IS Timers” on Optional
page 899
“Disabling an Interface from Optional
Sending/Receiving IS-IS Hello
“Configuring LSP Parameters” Optional
on page 900
“Configuring SPF Parameters” Optional
on page 901
“Configuring Dynamic Host Optional
Name Mapping” on page 902
“Configuring IS-IS Optional
Authentication” on page 902
“Configuring LSDB Overload Optional
Tag” on page 903
“Logging the Adjacency Optional
Changes” on page 904
“Enabling an Interface to Send Optional
Small Hello Packets” on page
904
“Enabling IS-IS Trap” on page Optional
904
“Configuring IS-IS GR” on page 904 Optional
Configuring IS-IS Basic

Functions
Configuration Before the configuration, accomplish the following tasks first:

Prerequisites ■ Configure the link layer protocol.
■ Configure an IP address for each interface, and make sure all nodes are
reachable.
Configuration Procedure Follow these steps to configure IS-IS basic functions:

Enable IS-IS routing process isis [ process-id ] Required
and enter its view [ vpn-instance
vpn-instance-name ]
Assign a network entity title network-entity net Required
(NET)
Specify a router type is-level { level-1 | level-1-2 | Optional
level-2 }
The default type is level-1-2.
Return to system view quit --
interface-number


Enable an IS-IS process on the isis enable [ process-id ] Required
interface
Disabled by default
Specify network type for the isis circuit-type p2p Optional
interface as P2P
By default, the network type
of an interface depends on
the physical media. The
network type of a VLAN
interface is broadcast.
Specify the adjacency type for isis circuit-level [ level-1 | Optional
the interface level-1-2 | level-2 ]
The default type is level-1-2.
Disable peer IP address check isis peer-ip-ignore Optional
on the PPP interface
The command only applies to
the PPP interface.
Enabled by default, meaning
two peers must be in the
same network.
n If a router’s type is configured as Level-1 or Level-2, the type of interfaces must be

the same, which cannot be changed using the isis circuit-level command.
However, an interface’s type can be changed with this command when the
router’s type is Level-1-2 for the establishment of a specific level adjacency.
Configuring IS-IS
Routing Information
Control

Prerequisites ■ Configure an IP address on each interface, and make sure all nodes are
reachable.
■ Configure basic IS-IS functions
Specifying a Priority for A router can run multiple routing protocols. When a route to the same destination
IS-IS is learned by multiple routing protocols, the one with the highest protocol priority
wins. You can reference a routing policy to specify a priority for specific routes. For
information about routing policy, refer to “Routing Policy Configuration” on page
991.
Follow these steps to configure the IS-IS protocol priority.

Enter IS-IS view isis [ process-id ] [ vpn-instance --
vpn-instance-name ]
Specify a priority for IS-IS preference { route-policy Optional
route-policy-name | preference } *
15 by default

Configuring IS-IS Link There are three ways to configure the interface link cost, in descending order of
Cost interface costs:
■ Interface cost: Assign a link cost for a single interface.
■ Global cost: Assign a link cost for all interfaces.
■ Automatically calculated cost: Calculate the link cost based on the bandwidth
of an interface.
Interface cost defaults to 10.
Configure an IS-IS cost for an interface

Follow these steps to configure an interface’s cost:

Enter IS-IS view isis [ process-id ] --
[ vpn-instance
vpn-instance-name ]
Specify a cost style cost-style { narrow | wide | Optional
wide-compatible |
narrow by default
{ compatible |
narrow-compatible }
[ relax-spf-limit ] }
interface-number
Specify a cost for the interface isis cost value [ level-1 | Optional
level-2 ]
Configure a global IS-IS cost

Follow these steps to configure global IS-IS cost:

Enter IS-IS view isis [ process-id ] [ vpn-instance -
vpn-instance-name ]
Specify an IS-IS cost cost-style { narrow | wide | Optional
style wide-compatible | { compatible |
Defaulted as narrow.
narrow-compatible }
Specify a global IS-IS circuit-cost value [ level-1 | Required
cost level-2 ]
Not specified by default.
Enable automatic IS-IS cost calculation

Follow these steps to enable automatic IS-IS cost calculation:

Enter IS-IS view isis [ process-id ] [ vpn-instance -
vpn-instance-name ]


Specify an IS-IS cost style cost-style { narrow | wide | Optional
wide-compatible | { compatible
narrow by default
| narrow-compatible }
Configure a bandwidth bandwidth-reference value Optional
reference value for automatic
100 Mbps by default
IS-IS cost calculation
Enable automatic IS-IS cost auto-cost enable Required
calculation
n In the case no interface cost is specified in interface view or system view and
automatic cost calculation is enabled
■ When the cost style is wide or wide-compatible, IS-IS automatically
calculates the interface cost based on the interface bandwidth, using the
formula: interface cost = bandwidth reference value/interface bandwidth, and
the maximum calculated cost is 16777214.
■ When the cost style is narrow, narrow-compatible, or compatible, if the
interface is a loopback interface, the cost value is 0; otherwise, the cost value is
automatically calculated as follows: if the interface bandwidth is in the range of
1 M to 10 M, the interface cost is 60; if the interface bandwidth is in the range
of 11 M to 100 M, the interface cost is 50; if the interface bandwidth is in the
range of 101 M to 155 M, the interface cost is 40; if the interface bandwidth is
in the range of 156 M to 622 M, the interface cost is 30; if the interface
bandwidth is in the range of 623 M to 2500 M, the interface cost is 20, and
the default interface cost of 10 is used for any other bandwidths.
Configuring the If there are more than one equal cost routes to the same destination, the traffic
Maximum Number of can be load balanced to enhance path efficiency.
Load Balanced Routes
Follow these steps to configure the maximum number of load balanced routes:

[ vpn-instance
vpn-instance-name ]
Specify the maximum number maximum load-balancing Optional
of load balanced routes number
The number range and
default vary by device.
Configuring IS-IS Route This task is to configure a summary route, so routes falling into the network range
Summarization of the summary route are summarized with one route for advertisement. Doing so
can reduce the size of routing tables, as well as the LSP and LSDB generated by the
router itself. Both IS-IS and redistributed routes can be summarized.
Follow these steps to configure route summarization:


vpn-instance-name ]
Configure IS-IS route summary ip-address { mask | Required
summarization mask-length } [ avoid-feedback |
Not configured by
generate_null0_route | tag tag |
default
[ level-1 | level-1-2 | level-2 ] ] *
n The cost of the summary route is the lowest cost among those summarized routes.
Advertising a Default Follow these steps to advertise a default route:

Route
Enter IS-IS view isis [ process-id ] -
[ vpn-instance
vpn-instance-name ]
Advertise a default route default-route-advertise Optional
[ route-policy
Level-2 router generates a
route-policy-name ] [ level-1 |
default route by default.
level-2 | level-1-2 ]
n The default route is only advertised to routers at the same level. You can use a
routing policy to generate the default route only when a local routing entry is
matched by the policy.
Configuring Inbound Follow these steps to configure inbound route filtering:

Route Filtering
vpn-instance-name ]
Configure inbound filter-policy { acl-number | Required
route filtering ip-prefix ip-prefix-name |
route-policy route-policy-name }
import
Configuring Route Follow these steps to configure IS-IS route redistribution from other routing
Redistribution protocols:

vpn-instance-name ]


Redistribute routes from import-route { isis [ process-id ] | Required
another routing protocol ospf [ process-id ] | rip
No route is redistributed
[ process-id ] | bgp [ allow-ibgp ] |
by default.
direct | static } [ cost cost |
cost-type { external | internal } | If no level is specified,
[ level-1 | level-1-2 | level-2 ] | routes are redistributed
route-policy route-policy-name | into the Level-2 routing
tag tag ] * table by default.
Configure a filtering policy to filter-policy { acl-number | Optional
filter redistributed routes ip-prefix ip-prefix-name |
Not configured by
route-policy route-policy-name }
default
export [ isis process-id | ospf
process-id | rip process-id | bgp |
direct | static]
Configuring IS-IS Route With this feature enabled, the Level-1-2 router can advertise both Level-1 and
Leaking Level-2 area routing information to the Level-1 router.
Follow these steps to configure IS-IS route leaking:

vpn-instance-name ]
Enable IS-IS route import-route isis level-2 into Required
leaking level-1 [ filter-policy { acl-number |
Disabled by default
ip-prefix ip-prefix-name |
route-policy route-policy-name } |
tag tag ] *
n ■ If a filter policy is specified, only routes passing it can be advertised into Level-1
area.
■ You can specify a routing policy in the import-route isis level-2 into level-1
command to filter routes from Level-2 to Level-1. Other routing policies
specified for route reception and redistribution does not affect the route
leaking.
Tuning and
Optimizing IS-IS
Network

Prerequisites ■ Configure an IP address on each interface, and make sure all nodes are
reachable.
■ Configure basic IS-IS functions
Configuring a DIS On an IS-IS broadcast network, a router should be selected as the DIS at a specific
Priority for an Interface level, Level-1 or Level-2. You can specify a DIS priority at a level for an interface.
The bigger the interface’s priority value, the more likelihood it becomes the DIS.

Follow these steps to configure a DIS priority for an interface:

interface-number
Specify a DIS priority for the isis dis-priority value Optional
interface [ level-1 | level-2 ]
64 by default
n If multiple routers in the broadcast network have the same highest DIS priority, the
router with the highest MAC address becomes the DIS. This rule applies even all
routers’ DIS priority is 0.
Configuring IS-IS Timers Follow these steps to configure the IS-IS timers:

interface-number
Specify the interval between isis timer hello seconds Optional
hello packets [ level-1 | level-2 ]
Specify the number of hello isis timer Optional
packets; within the time for holding-multiplier value
3 by default
receiving the specified hello [ level-1 | level-2 ]
packets, if no hello packets
are received on the interface,
the neighbor is considered
dead.
Specify the interval for isis timer csnp seconds Optional
sending CSNP packets [ level-1 | level-2 ]
Specify the interval for isis timer lsp time [ count Optional
sending LSP packets count ]
33 milliseconds by default
Specify the LSP retransmission isis timer retransmit Optional
interval on the point-to-point seconds
link
n ■ On the broadcast link, you can specify different intervals for Level-1 and Level-2
hello packets; if no level is specified, the interval applies to both Level-1 and
Level-2 hello packets, but only takes effect on the level of the current process;
if a level is specified, it applies to hello packets at this level. The point-to-point
link does not distinguish between Level-1 and Level-2 hello packets, so you
need not specify a level.
■ Hello packets are used to establish and maintain neighbor relationships. If no
hello packets are received from a neighbor within the time for receiving the
specified hello packets, the neighbor is considered dead.
■ CSNPs are sent by the DIS on a broadcast network for LSDB synchronization. If
no level is included, the specified CSNP interval applies to both Level-1 and
Level-2 of the current IS-IS process. If a level is specified, it applies to the level.

■ On a point-to-point link, if there is no response to an LSP sent by the local

router within the specified retransmission interval, the LSP is considered lost,
and the same LSP will be retransmitted. On broadcast links, responses to the
sent LSPs are not required.
■ The interval between hello packets sent by the DIS is 1/3 the hello interval set
by the isis timer hello command.
Disabling an Interface Follow these steps to disable an interface from sending hello packets:
from Sending/Receiving
IS-IS Hello Packets To do... Use the command... Remarks
interface-number
Disable the interface from isis silent Required
sending and receiving hello
packets
Configuring LSP An IS-IS router periodically advertises all the local LSPs to maintain the LSP
Parameters synchronization in the entire area.
An LSP is given an aging time when generated by the router. When the LSP is
received by another router, its aging time begins to decrease. If the receiving
router does not get the update for the LSP within the aging time, the LSP will be
deleted from the LSDB.
The router will discard an LSP with incorrect checksum. You can configure the
router to ignore the incorrect checksum, which means an LSP will be processed
even with an incorrect LSP checksum.
On the NBMA network, the router will flood a new LSP received from an interface
to other interfaces. This can cause the LSP reflooding on the high connectivity
networks. To avoid this problem, you can make a mesh group of interfaces. The
interface in this group will only flood the new LSP to interfaces outside the mesh
group.
Follow these steps to configure the LSP parameters:

[ vpn-instance
vpn-instance-name ]
Specify an LSP refresh interval timer lsp-refresh seconds Optional
Specify the maximum LSP timer lsp-max-age seconds Optional
aging time
Specify LSP generation timer lsp-generation Optional
interval maximum-interval
[ initial-interval
[ incremental-interval ] ]
[ level-1 | level-2 ]


Enable the LSP flash flooding flash-flood [ flood-count Optional
function flooding-count |
max-timer-interval
flooding-interval | [ level-1 |
level-2 ] ] *
Specify the maximum size of lsp-length originate size Optional
the originated Level-1 or [ level-1 | level-2 ]
Both are 1497 bytes by
Level-2 LSP
default
Specify the maximum size of lsp-length receive size Optional
the received Level-1 or Level-2
Both are 1497 bytes by
LSP
default
Enable LSP fragment lsp-fragments-extend Optional
extension [ level-1 | level-2 | level-1-2 ]
Disabled by default
[ mode-1 | mode-2 ]
Create a virtual system virtual-system Optional
virtual-system-id
interface-number
Add the interface to a mesh isis mesh-group Optional
group [ mesh-group-number |
Not added by default
mesh-blocked ]
If the mesh-blocked keyword
is included, the interface is
blocked from flooding LSPs. It
can send an LSP only after
receiving a request.
n Note the following when enabling LSP fragment extension

■ After LSP fragment extension is enabled in an IS-IS process, the MTUs of all the
interfaces with this IS-IS process enabled must not be less than 512; otherwise,
LSP fragment extension will not take effect.
■ At least one virtual system needs to be created to generate extended LSP
fragments. An IS-IS process allows 50 virtual systems at most.
Configuring SPF When the LSDB changes in an IS-IS network, a routing calculation starts. If the
Parameters changes happen frequently, it will take a lot of system resources. You can set the
interval for SPF calculation for efficiency consideration.
The SPF calculation may occupy the CPU for a long time when the routing entries
are too many (more than 150 thousand). You can split the SPF calculation time
into multiple durations with a default interval of 10s in between.
Follow these steps to configure the SPF parameters:

[ vpn-instance
vpn-instance-name ]


Configure the SPF calculation timer spf maximum-interval Optional
intervals [ minimum-interval
The default SPF calculation
interval is 10 seconds.
Specify the SPF calculation spf-slice-size duration-time Optional
duration
10 milliseconds by default
Configuring Dynamic Follow these steps to configure the dynamic host name mapping:
Host Name Mapping
[ vpn-instance
vpn-instance-name ]
Assign a local host name is-name sys-name Required
No name is assigned by
default.
This command also enables
the mapping between the
local system ID and host name
Assign a remote host name is-name map sys-id Optional
and create a mapping map-sys-name
One system ID only maps to
between the host name and a
one name.
system ID
No name is assigned by
default
interface-number
Assign a DIS name for the isis dis-name symbolic-name Optional
local network
This command is only
applicable on the router with
dynamic host name mapping
enabled.
It is invalid on point-to-point
links.
n The local host name on the local IS overwrites the remote host name on the
remote IS.
Configuring IS-IS For area authentication, the area authentication password is encapsulated into the
Authentication Level-1 LSP, CSNP, and PSNP packets. On area authentication enabled routers in
the same area, the authentication mode and password must be same.
For routing domain authentication, the domain authentication password is

encapsulated into the Level-2 LSP, CSNP, and PSNP packets. The domain
authentication enabled Level-2 routers in the backbone must adopt the same
authentication mode and share the same password.

The authentication configured on an interface applies to the hello packet in order

to authenticate neighbors. All interfaces within a network must share the same
authentication password at the same level.
Follow these steps to configure the authentication function:

[ vpn-instance
vpn-instance-name ]
Specify the area area-authentication-mode Required
authentication mode { simple | md5 } password
No authentication is enabled
[ ip | osi ]
for Level-1 routing
information, and no password
is specified by default.
Specify the routing domain domain-authentication-mo Required
authentication mode de { simple | md5 } password
No authentication is enabled
[ ip | osi ]
for Level-2 routing
information, and no password
is specified by default.
interface-number
Specify the authentication isis authentication-mode Optional
mode and password { simple | md5 } password
No authentication and
[ level-1 | level-2 ] [ ip | osi ]
password are available by
default.
n The level-1 and level-2 keywords in the isis authentication-mode command

are only supported on the Ethernet or GigabitEthernet interface of a router and
the interface must be configured with the isis enable command first.
Configuring LSDB When the overload tag is set on a router, other routers will not send packets to the
Overload Tag router except for the packets destined to the network directly connected to the
router.
The overload tag can be used for troubleshooting as well. You can temporarily
isolate a router from the IS-IS network by setting the overload tag.
Follow these steps to configure the LSDB overload tag:

vpn-instance-name ]
Configure the overload set-overload [ on-startup Required
tag start-from-nbr system-id [ timeout
Not configured by
[ nbr-timeout ] ] ] [ allow { interlevel |
default
external } * ]

Logging the Adjacency Follow these steps to configure this task:

Changes
[ vpn-instance
vpn-instance-name ]
Enable to log the adjacency log-peer-change Required
changes
Enabled by default
n With this feature enabled, the state information of the adjacency is displayed on
the configuration terminal.
Enabling an Interface to Follow these steps to enable an interface to send small hello packets (without the
Send Small Hello Packets padding field):

interface-number
Enable the interface to send isis small-hello Required
small hello packets that have
Standard hello packets are
no padding field
sent by default.
Enabling IS-IS Trap Follow these steps to enable IS-IS trap:

[ vpn-instance
vpn-instance-name ]
Enable IS-IS Trap is-snmp-traps enable Required
Enabled by default
Configuring IS-IS GR An ISIS restart may cause the termination of the adjacencies between a restarting
router and its neighbors, resulting in a transient network disconnection.
IS-IS Graceful Restart can help to solve this problem by notifying its neighbors its
restarting state to allow them to reestablish the adjacency without removing it.
The IS-IS Graceful Restart provides the following features:
■ When restarting ISIS, a Graceful Restart capable device will resend connection
requests to its neighbors instead of terminating their adjacencies.
■ Graceful Restart minimizes network disruption caused by LSDB synchronization
before LSP packets generation.
■ When a router starts for the first time, it sets the overload bit in LSP packets
before LSDB synchronization is complete, which ensures no routing loop is
created.

Displaying and Maintaining IS-IS Configuration 905
The Graceful Restart interval on a router is used as the holdtime in the IS-IS Hello
PDUs so that its neighbors can maintain the adjacencies within the interval after
the router restarts.
By setting the SA (Suppress-Advertisement) bit in the hello PDUs sent by the GR

Restarter, its neighbors will not advertise adjacencies within the specified period
until the completion of LSDB synchronization between the GR Restarter and its
neighbors. This feature helps to effectively avoid blackhole routes due to the
sending or receiving of LSPs across the restart.
n A device can act as both a GR Restarter and GR Helper at the same time.
Follow these steps to configure GR on the GR Restarter and GR Helper

respectively:

Enable IS-IS, and enter IS-IS isis [ process-id ] Required
view [ vpn-instance
Disabled by default
vpn-instance-name ]
Enable the GR capability for graceful-restart Required
IS-IS
Disabled by default
Set the Graceful Restart graceful-restart interval Required
interval timer
Configure to set the SA bit graceful-restart Optional
during restart suppress-sa
By default, the SA bit is not
set.
Displaying and
Maintaining IS-IS To do... Use the command... Remarks
Configuration Display brief IS-IS information display isis brief [ process-id | Available in any view
vpn-instance vpn-instance-name ]
Display the status of the display isis debug-switches Available in any view
debug switch { process-id | vpn-instance
vpn-instance-name }
Display information about display isis interface [ [ traffic-eng | Available in any view
IS-IS enabled interfaces verbose ] * | tunnel ] [ process-id |
Display IS-IS license display isis license Available in any view
information
Display IS-IS LSDB information display isis lsdb [ [ l1 | l2 | level-1 | Available in any view
level-2 ] | [ lsp-id LSPID | lsp-name
lspname ] | local | verbose ] *
[ process-id | vpn-instance
vpn-instance-name ]
Display IS-IS mesh group display isis mesh-group [ process-id Available in any view
information | vpn-instance vpn-instance-name ]
Display the display isis name-table [ process-id | Available in any view
host-name-to-system-ID vpn-instance vpn-instance-name ]
mapping table


Display IS-IS neighbor display isis peer [ verbose ] Available in any view
information [ process-id | vpn-instance
vpn-instance-name ]
Display IS-IS routing display isis route [ ipv4 | ipv6 ] Available in any view
information [ [ level-1 | level-2 ] | verbose ] *
vpn-instance-name ]
Display SPF calculation log display isis spf-log [ process-id | Available in any view
information vpn-instance vpn-instance-name ]
Display statistic about an IS-IS display isis statistics [ level-1 | Available in any view
process level-2 | level-1-2 ] [ process-id |
Display the IS-IS Graceful display isis graceful-restart status Available in any view
Restart state [ level-1 | level-2 ] [ process-id |
Clear the data structure reset isis all [ process-id | Available in user view
information of an IS-IS vpn-instance vpn-instance-name ]
process
Clear the data structure reset isis peer system-id [ process-id | Available in user view
information of an IS-IS vpn vpn-instance-name ]
neighbor
IS-IS Configuration
Example
IS-IS Basic Configuration Network requirements

As shown in Figure 266, Router A, B, C and Router D are in an IS-IS autonomous
system.
Router A and Router B are Level-1 routers, Router D is a Level-2 router, and Router
C is a Level-1-2 router connecting two areas. Router A, Router B, and Router C are
in area 10, while Router D is in area 20.
Network diagram
Figure 266 Network diagram for IS-IS basic configuration
Router A
L1
S2/0
10.1 .1.2/24
S2/1
S2/2 Eth1/0
10.1 .1.1/24
192.168.0.1/24 172 .16 .1.1/16
S2/0 S2/0
10 .1.2.1/24 1 92.168.0.2/24
Router C Router D
L1/L2 L2
S 2/0
1 0.1 .2.2/24 Area 20
Router B Area 10
L1

2 Configure IS-IS
[RouterA] isis 1
[RouterA-isis-1] is-level level-1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA-Serial2/0] isis enable 1
[RouterB] isis 1
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB-Serial2/0] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC-Serial2/0] isis enable 1
[RouterD] isis 1
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] network-entity 20.0000.0000.0004.00
[RouterD-isis-1] quit
[RouterD-Ethernet1/0] isis enable 1
[RouterD-Serial2/0] isis enable 1

# Display the IS-IS LSDB information of each router to check the integrity of the
LSP.
[RouterA] display isis lsdb

Database information for ISIS(1)
--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length ATT/P/OL

--------------------------------------------------------------------------
0000.0000.0001.00-00* 0x0000000d 0xb184 879 68 0/0/0
0000.0000.0002.00-00 0x0000000c 0xcf65 493 68 0/0/0
0000.0000.0003.00-00 0x00000013 0x2f38 594 111 1/0/0
*-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload
[RouterB] display isis lsdb

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

--------------------------------------------------------------------------
0000.0000.0001.00-00 0x0000000d 0xb184 707 68 0/0/0
0000.0000.0002.00-00* 0x0000000d 0xcd66 1167 68 0/0/0
0000.0000.0003.00-00 0x00000014 0x2d39 1136 111 1/0/0
[RouterC] display isis lsdb

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

------------------------------------------------------------------------
0000.0000.0001.00-00 0x00000003 0xc57a 991 68 0/0/0
0000.0000.0002.00-00 0x00000003 0xef4d 1025 68 0/0/0
0000.0000.0003.00-00* 0x0000000a 0x93dd 1026 111 1/0/0

------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000007 0xbb56 1026 100 0/0/0
0000.0000.0004.00-00 0x00000005 0xd086 904 84 0/0/0
[RouterD] display isis lsdb

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

------------------------------------------------------------------------
0000.0000.0003.00-00 0x00000007 0xbb56 910 100 0/0/0
0000.0000.0004.00-00* 0x00000005 0xd086 791 84 0/0/0
# Display the IS-IS routing information of each router. The routing table of Level-1
routers must contain a default route with the next hop being the Level-1-2 router.
The routing table of Level-2 router must contain all routes of Level-1 and Level-2.
[RouterA] display isis route
Route information for ISIS(1)

-----------------------------
ISIS(1) IPv4 Level-1 Forwarding Table

-------------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/0 Direct R/L/-
10.1.2.0/24 20 NULL S2/0 10.1.1.1 R/-/-
192.168.0.0/24 20 NULL S2/0 10.1.1.1 R/-/-
0.0.0.0/0 10 NULL S2/0 10.1.1.1 R/-/-
Flags: D-Direct, R-Added to RM, L-Advertised in LSPs, U-Up/Down Bit Set
[RouterC] display isis route

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

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct R/L/-
10.1.2.0/24 10 NULL S2/0 Direct R/L/-
192.168.0.0/24 10 NULL S2/2 Direct R/L/-

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

--------------------------------------------------------------------------
10.1.1.0/24 10 NULL S2/1 Direct R/L/-
10.1.2.0/24 10 NULL S2/0 Direct R/L/-
192.168.0.0/24 10 NULL S2/2 Direct R/L/-
172.16.0.0/16 20 NULL S2/2 192.168.0.2 R/-/-

[RouterD] display isis route

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

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

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

192.168.0.0/24 10 NULL S2/0 Direct R/L/-

10.1.1.0/24 20 NULL S2/0 192.168.0.1 R/-/-
10.1.2.0/24 20 NULL S2/0 192.168.0.1 R/-/-
172.16.0.0/16 10 NULL Eth1/0 Direct R/L/-
DIS Selection Network requirements

Configuration As shown in Figure 267, on a broadcast network (Ethernet), Router A, Router B,
Router C and Router D reside in IS-IS area 10. Router A and Router B are Level-1-2
routers, Router C is a Level-1 router, and Router D is a Level-2 router.
Change the DIS priority of Router A to make it selected as the Level-1-2 DIS router.
Network diagram
Figure 267 Network diagram for DIS selection configuration
Router A Router B
L1/L2 L1/L2
Eth1/0 Eth1/0
10 .1.1.1/24 10.1.1.2/24
Eth1/0 Eth1/0
10.1.1.3/24 10 .1.1.4/24
Router C Router D
L1 L2
1 Configure an IP address for each interface (omitted)
2 Enable IS-IS
[RouterA] isis 1
[RouterA-Ethernet1/0] isis enable 1
[RouterB] isis 1


[RouterB-Ethernet1/0] isis enable 1
[RouterC] isis 1
[RouterC-isis-1] is-level level-1
[RouterC-Ethernet1/0] isis enable 1
[RouterD] isis 1
[RouterD-Ethernet1/0] isis enable 1
# Display information about IS-IS neighbors of Router A.
Peer information for ISIS(1)

----------------------------
System Id: 0000.0000.0002

Interface: Ethernet1/0 Circuit Id: 0000.0000.0003.01
State: Up HoldTime: 21s Type: L1(L1L2) PRI: 64
System Id: 0000.0000.0003

State: Up HoldTime: 6s Type: L1 PRI: 64
System Id: 0000.0000.0002

System Id: 0000.0000.0004

# Display information about IS-IS interfaces of Router A.
[RouterA] display isis interface
Interface information for ISIS(1)

---------------------------------
Interface: Ethernet1/0
Id IPV4.State IPV6.State MTU Type DIS
001 Up Down 1497 L1/L2 No/No
# Display IS-IS interfaces of Router C.

[RouterC] display isis interface

---------------------------------
001 Up Down 1497 L1/L2 Yes/No
# Display information about IS-IS interfaces of Router D.
[RouterD] display isis interface

---------------------------------
001 Up Down 1497 L1/L2 No/Yes
n By using the default DIS priority, Router C is the Level-1 DIS, and Router D is the
Level-2 DIS. The pseudonodes of Level-1 and Level-2 are 0000.0000.0003.01 and
0000.0000.0004.01 respectively.
3 Configure the DIS priority of Router A.
[RouterA-Ethernet1/0] isis dis-priority 100
# Display information about IS-IS neighbors of Router A.
[RouterA] display isis peer

----------------------------
System Id: 0000.0000.0002

System Id: 0000.0000.0003

System Id: 0000.0000.0002

System Id: 0000.0000.0004

# Display information about IS-IS interfaces of Router A.
[RouterA] display isis interface

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


001 Up Down 1497 L1/L2 Yes/Yes
n After the DIS priority configuration, you can see Router A is the DIS for Level-1-2,
and the pseudonode is 0000.0000.0001.01.
# Display information about IS-IS neighbors and interfaces of Router C.
[RouterC] display isis peer

----------------------------
System Id: 0000.0000.0001

System Id: 0000.0000.0002

[RouterC] display isis interface

---------------------------------
# Display information about IS-IS neighbors and interfaces of Router D.
[RouterD] display isis peer

----------------------------
System Id: 0000.0000.0001

System Id: 0000.0000.0002

[RouterD] display isis interface

---------------------------------
IS-IS GR Configuration Network requirements

Example Router A, Router B, and Router C belong to the same IS-IS routing domain, as
illustrated in Figure 268.

Network diagram
Figure 268 Network diagram for IS-IS-based GR configuration
GR restarter
Router A
Eth1/0
10 .0.0.1/24
Eth1/0 Eth1/0
10.0.0 .2/24 10 .0.0.3/24
Router B Router C
GR helper GR helper
Configuration Procedure
1 Configure IP addresses of the interfaces on each router and configure IS-IS.
Follow Figure 268 to configure the IP address and subnet mask of each interface
on the router. The configuration procedure is omitted.
Configure IS-IS on the routers, ensuring that Router A, Router B and Router C can
communicate with each other at layer 3 and dynamic route update can be
implemented among them with IS-IS. The configuration procedure is omitted here.
2 Configure IS-IS Graceful Restart.
# Enable IS-IS Graceful Restart on Router A and configure the Graceful Restart
interval.
[RouterA] isis 1
[RouterA-isis-1] graceful-restart
[RouterA-isis-1] graceful-restart interval 150
[RouterA-isis-1] return
The configurations for Router B and Router C are similar and therefore are omitted
here.
After Router A establishes adjacencies with Router B and Router C, they begin to
exchange routing information. Restart IS-IS on Router A, which enters into the
restart state and sends connection requests to its neighbors through the Graceful
Restart mechanism to synchronize the LSDB. Using the display isis
graceful-restart status command can display the IS-IS GR status on Router A.
# Restart Router A.
<RouterA> reset isis all 1

Warning : Reset ISIS process? [Y/N]:y
# Check the IS-IS Graceful Restart state on Router A.
<RouterA> display isis graceful-restart status

Restart information for IS-IS(1)

--------------------------------------------------------------------
IS-IS(1) Level-1 Restart Status
Restart Interval: 150
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTARTING
Number of LSPs Awaited: 3
T3 Timer Status:
Remaining Time: 239
T2 Timer Status:
Remaining Time: 59
IS-IS(1) Level-2 Restart Status

Restart Interval: 150
SA Bit Supported
Total Number of Interfaces = 1
Restart Status: RESTARTING
Number of LSPs Awaited: 3
T3 Timer Status:
Remaining Time: 239
T2 Timer Status:
Remaining Time: 59


OSPF CONFIGURATION
58
Open Shortest Path First (OSPF) is a link state based interior gateway protocol
developed by the OSPF working group of the Internet Engineering Task Force
(IETF). At present, OSPF version 2 (RFC2328) is used.
When configuring OSPF, go to these sections for information you are interested in:
■ “Introduction to OSPF” on page 917

■ “OSPF Configuration Task List” on page 937
■ “Configuring OSPF Basic Functions” on page 939
■ “Configuring OSPF Area Parameters” on page 940
■ “Configuring OSPF Network Types” on page 941
■ “Configuring OSPF Routing Information Control” on page 942
■ “Configuring OSPF Network Optimization” on page 946
■ “Displaying and Maintaining OSPF Configuration” on page 954
■ “OSPF Configuration Examples” on page 955
■ “Troubleshooting OSPF Configuration” on page 968
Introduction to OSPF
n Unless otherwise noted, OSPF refers to OSPFv2 throughout this document.
OSPF has the following features:
■ Scope: Supports networks of various sizes and can support several hundred
routers.
■ Fast convergence: Transmits update packets instantly after network topology
changes for routing information synchronization in the AS.
■ Loop-free: Computes routes with the Shortest Path Tree algorithm according to
the collected link states, so no loop routes are generated.
■ Area partition: Allows an AS to be split into different areas for ease of
management and the routing information transmitted between areas is
summarized to reduce network bandwidth consumption.
■ Equal-cost multi-route: Supports multiple equal-cost routes to a destination.
■ Routing hierarchy: Supports a four-level routing hierarchy that prioritizes the
routes into intra-area, inter-area, external type-1, and external type-2 routes.
■ Authentication: Supports interface-based packet authentication to guarantee
the security of packet exchange.

918 CHAPTER 58: OSPF CONFIGURATION
■ Multicast: Supports packet multicasting on some types of links.
Basic Concepts Autonomous System

A set of routers using the same routing protocol to exchange routing information
constitute an Autonomous System (AS).
OSPF route computation

OSPF route computation is described as follows:
■ Based on the network topology around itself, each router generates Link State
Advertisements (LSA) and sends them to other routers in update packets.
■ Each OSPF router collects LSAs from other routers to compose a LSDB (Link
State Database). An LSA describes the network topology around a router, so
the LSDB describes the entire network topology of the AS.
■ Each router transforms the LSDB to a weighted directed graph, which actually
reflects the topology architecture of the entire network. All the routers have
the same graph.
■ Each router uses the SPF algorithm to compute a Shortest Path Tree that shows
the routes to the nodes in the autonomous system. The router itself is the root
of the tree.
Router ID
To run OSPF, a router must have a Router ID, which is a 32-bit unsigned integer,
the unique identifier of the router in the AS.
You may assign a Router ID to an OSPF router manually. If no Router ID is

specified, the system automatically selects one for the router as follows:
■ If the loopback interfaces are configured, select the highest IP address among
them.
■ If no loopback interface is configured, select the highest IP address among
addresses of active interfaces on the router.
OSPF packets
OSPF uses five types of packets:
■ Hello Packet: Periodically sent to find and maintain neighbors, containing the
values of some timers, information about DR, BDR and known neighbors.
■ DD packet (Database Description Packet): Describes the digest of each LSA in
the LSDB, exchanged between two routers for data synchronization.
■ LSR (Link State Request) Packet: Requests needed LSAs from the peer. After
exchanging the DD packets, the two routers know which LSAs of the neighbor
routers are missing from the local LSDBs. In this case, they send LSR packets,
requesting the missing LSAs. The packets contain the digests of the missing
LSAs.
■ LSU (Link State Update) Packet: Transmits the needed LSAs to the peer router.
■ LSAck (Link State Acknowledgment) Packet: Acknowledges received LSU
packets. It contains the Headers of LSAs requiring acknowledgement (a packet
can acknowledge multiple LSAs).

LSA types
OSPF sends routing information in LSAs, which, as defined in RFC 2328, have the
following types:
■ Router LSA: Type-1 LSA, originated by all routers, flooded throughout a single
area only. This LSA describes the collected states of the router’s interfaces to an
area.
■ Network LSA: Type-2 LSA, originated for broadcast and NBMA networks by the
Designated Router, flooded throughout a single area only. This LSA contains
the list of routers connected to the network.
■ Network Summary LSA: Type-3 LSA, originated by ABRs (Area Border Routers),
and flooded throughout the LSA’s associated area. Each summary-LSA
describes a route to a destination outside the area, yet still inside the AS (an
inter-area route).
■ ASBR Summary LSA: Type-4 LSA, originated by ABRs and flooded throughout
the LSA’s associated area. Type 4 summary-LSAs describe routes to ASBR
(Autonomous System Boundary Router).
■ AS External LSA: Type-5 LSA, originated by ASBRs, and flooded throughout the
AS (except Stub and NSSA areas). Each AS-external-LSA describes a route to
another Autonomous System.
■ NSSA LSA: Type-7 LSA, as defined in RFC 1587, originated by ASBRs in NSSAs
(Not-So-Stubby Areas) and flooded throughout a single NSSA. NSSA LSAs
describe routes to other ASs.
■ Opaque LSA: A proposed type of LSA, the format of which consists of a
standard LSA header and application specific information. Opaque LSAs are
used by the OSPF protocol or by some application to distribute information into
the OSPF routing domain. The opaque LSA includes three types, Type 9, Type
10 and Type 11, which are used to flood into different areas. The Type 9
opaque LSA is flooded into the local subnet, the Type 10 is flooded into the
local area, and the Type 11 is flooded throughout the whole AS.
Neighbor and Adjacency

In OSPF, the “Neighbor” and “Adjacency” are two different concepts.
Neighbor: Two routers that have interfaces to a common network. Neighbor

relationships are maintained by, and usually dynamically discovered by, OSPF’s
hello packets. When a router starts, it sends a hello packet via the OSPF interface,
and the router that receives the hello packet checks parameters carried in the
packet. If parameters of the two routers match, they become neighbors.
Adjacency: A relationship formed between selected neighboring routers for the

purpose of exchanging routing information. Not every pair of neighboring routers
become adjacent, which depends on network types. Only by synchronizing the
LSDB via exchanging DD packets and LSAs can two routers become adjacent.
OSPF Area Partition and Area partition

Route Summarization When a large number of OSPF routers are present on a network, LSDBs may
become so large that a great amount of storage space is occupied and CPU
resources are exhausted performing SPF computation.

In addition, as the topology of a large network is prone to changes, enormous

OSPF packets may be created, reducing bandwidth utilization. Each topology
change makes all routers perform route calculation.
To solve this problem, OSPF splits an AS into multiple areas, which are identified by
area ID. The boundaries between areas are routers rather than links. A network
segment (or a link) can only reside in one area, in other words, an OSPF interface
must be specified to belong to its attached area, as shown in the figure below.
Figure 269 OSPF area partition
Area 4
Area 1
Area 0
Area 2
Area 3
After area partition, area border routers perform route summarization to reduce
the number of LSAs advertised to other areas and minimize the effect of topology
changes.
Classification of Routers
The OSPF router falls into four types according to the position in the AS:
1 Internal Router
All interfaces on an internal router belong to one OSPF area.
2 Area Border Router (ABR)
An area border router belongs to more than two areas, one of which must be the
backbone area. It connects the backbone area to a non-backbone area. The
connection between an area border router and the backbone area can be physical
or logical.
3 Backbone Router
At least one interface of a backbone router must be attached to the backbone

area. Therefore, all ABRs and internal routers in area 0 are backbone routers.

4 Autonomous System Border Router (ASBR)
The router exchanging routing information with another AS is an ASBR, which

may not reside on the boundary of the AS. It can be an internal router or area
border router.
Figure 270 OSPF router types
RIP
IS-IS
ASBR
Area 1
Area 4
Backbone Router
Internal
Router
ABR
Area 3
Area 2
Backbone area and virtual links

An AS has a unique area called backbone area, which is responsible for
distributing routing information between none-backbone areas. Routing
information between non-backbone areas must be forwarded by the backbone
area. Therefore, OSPF requires:
■ All non-backbone areas must maintain connectivity to the backbone area.
■ The backbone area itself must maintain connectivity.
In practice, due to physical limitations, the requirements may not be satisfied. In

this case, configuring OSPF virtual links is a solution.
A virtual link is established between two area border routers via a non-backbone
area and is configured on both ABRs to take effect. The area that provides the
non-backbone area internal route for the virtual link is a “transit area”.
In the following figure, Area 2 has no direct physical link to the backbone area 0.
Configuring a virtual link between ABRs can connect Area 2 to the backbone area.

Figure 271 Virtual link application 1
Transit Area
Virtual Link
Area 0 ABR ABR Area 2
Area 1
Another application of virtual links is to provide redundant links. If the backbone

area cannot maintain internal connectivity due to a physical link failure,
configuring a virtual link can guarantee logical connectivity in the backbone area,
as shown below.
Figure 272 Virtual link application 2
Area 1
Virtual Link
R1 R2
Area 0
The virtual link between the two ABRs acts as a point-to-point connection.
Therefore, you can configure interface parameters such as hello packet interval on
the virtual link as they are configured on physical interfaces.
The two ABRs on the virtual link exchange OSPF packets with each other directly,
the OSPF routers in between simply convey these OSPF packets as normal IP
packets.
(Totally) Stub area

The ABR in a stub area does not distribute Type5 LSAs into the area, so the routing
table scale and amount of routing information in this area are reduced
significantly.
You can also configure the stub area as a Totally Stub area, where the ABR
advertises neither the routes of other areas nor the external routes.
Stub area configuration is optional, and not every area is qualified to be a stub
area. In general, a stub area resides on the border of the AS.
The ABR in a stub area generates a default route into the area.
Note the following when configuring a (totally) stub area:
■ The backbone area cannot be a (totally) stub area

■ The stub command must be configured on routers in a (totally) stub area

■ A (totally) stub area cannot have an ASBR because AS external routes cannot
be distributed into the stub area.
■ Virtual links cannot transit (totally) stub areas.
NSSA area
Similar to a stub area, an NSSA area imports no AS external LSA (type5 LSA) but
can import type7 LSAs that are generated by the ASBR and distributed throughout
the NSSA area. When traveling to the NSSA ABR, type7 LSAs are translated into
type5 LSAs by the ABR for advertisement to other areas.
In the following figure, the OSPF AS contains three areas: Area 1, Area 2 and Area
0. The other two ASs employ the RIP protocol. Area 1 is an NSSA area, and the
ASBR in it translates RIP routes into type7 LSAs and advertises them throughout
Area 1. When these LSAs travel to the NSSA ABR, the ABR translates type7 LSAs to
type5 LSAs for advertisement to Area 0 and Area 2.
On the left of the figure, RIP routes are translated into type5 LSAs by the ASBR of
Area 2 and distributed into the OSPF AS. However, Area 1 is an NSSA area, so
these type5 LSAs cannot travel to Area 1.
Similar to stub areas, virtual links cannot transit NSSA areas.
Figure 273 NSSA area
RIP RIP
NSSA
Type 5 Type 5
Type 5 Type 5 Type 7

ASBR Area 2 ABR Area 0 NSSA Area 1 NSSA
ABR ASBR
Route summarization
Route summarization: An ABR or ASBR summarizes routes with the same prefix
with a single route and distribute it to other areas.
Via route summarization, routing information across areas and the size of routing
tables on routers will be reduced, improving calculation speed of routers.
For example, as shown in the following figure, in Area 1 are three internal routes
19.1.1.0/24, 19.1.2.0/24, and 19.1.3.0/24. By configuring route summarization
on Router A, the three routes are summarized with the route 19.1.0.0/16 that is
advertised into Area 0.
Figure 274 Route summarization
Router A
19.1.0.0/16
19.1.1.0/24
19.1.2.0/24
Area 0 ABR Router B 19.1.3.0/24
ABR
ĂĂ
Area 1

OSPF has two types of route summarization:
1 ABR route summarization
To distribute routing information to other areas, an ABR generates type3 LSAs on a

per network segment basis for an attached non-backbone area. If contiguous
network segments are available in the area, you can summarize them with a single
network segment. The ABR in the area distributes only the summary LSA to reduce
the scale of LSDBs on routers in other areas.
2 ASBR route summarization
If summarization for redistributed routes is configured on an ASBR, it will

summarize redistributed type5 LSAs that fall into the specified address range. If in
an NSSA area, it also summarizes type7 LSAs that fall into the specified address
range.
If this feature is configured an on ABR, the ABR will summarize type5 LSAs
translated from type7 LSAs.
Route types
OSPF prioritize routes into four levels:
■ Intra-area route
■ Inter-area route
■ type1 external route
■ type2 external route
The intra-area and inter-area routes describe the network topology of the AS,
while external routes describe routes to destinations outside the AS. OSPF
classifies external routes into two types: type1 and type2.
A type1 external route is an IGP route, such as a RIP or static route, which has high
credibility and whose cost is comparable with the cost of an OSPF internal route.
The cost from a router to the destination of the type1 external route= the cost
from the router to the corresponding ASBR+ the cost from the ASBR to the
destination of the external route.
A type2 external route is an EGP route, which has low credibility, so OSPF
considers the cost from the ASBR to the destination of the type2 external route is
much bigger than the cost from the ASBR to an OSPF internal router. Therefore,
the cost from the internal router to the destination of the type2 external route=
the cost from the ASBR to the destination of the type2 external route. If two
routes to the same destination have the same cost, then take the cost from the
router to the ASBR into consideration.
Classification of OSPF OSPF network types

Networks OSPF classifies networks into four types upon the link layer protocol:
■ Broadcast: when the link layer protocol is Ethernet or FDDI, OSPF considers the
network type broadcast by default. On Broadcast networks, packets are sent to
multicast addresses (such as 224.0.0.5 and 224.0.0.6).

■ NBMA (Non-Broadcast Multi-Access): when the link layer protocol is Frame

Relay, ATM or X.25, OSPF considers the network type as NBMA by default.
Packets on these networks are sent to unicast addresses.
■ P2MP (point-to-multipoint): by default, OSPF considers no link layer protocol as
P2MP, which is a conversion from other network types such as NBMA in
general. On P2MP networks, packets are sent to multicast addresses
(224.0.0.5).
■ P2P (point-to-point): when the link layer protocol is PPP or HDLC, OSPF
considers the network type as P2P. On P2P networks, packets are sent to
multicast addresses (224.0.0.5).
NBMA network configuration principle

Typical NBMA networks are ATM and Frame Relay networks.
You need to perform some special configuration on NBMA interfaces. Since these
interfaces cannot broadcast hello packets for neighbor location, you need to
specify neighbors manually and configure whether the neighbors have the DR
election right.
An NBMA network is fully meshed, which means any two routers in the NBMA
network have a direct virtual link for communication. If direct connections are not
available between some routers, the type of interfaces associated should be
configured as P2MP, or as P2P for interfaces with only one neighbor.
Differences between NBMA and P2MP networks:
■ NBMA networks are fully meshed, non-broadcast and multi access. P2MP
networks are not required to be fully meshed.
■ It is required to elect the DR and BDR on NBMA networks, while DR and BDR
are not available on P2MP networks.
■ NBMA is the default network type, while P2MP is a conversion from other
network types such as NBMA in general.
■ On NBMA networks, packets are unicast, and neighbors are configured
manually on routers. On P2MP networks, packets are multicast.
DR and BDR DR/BDR introduction

On broadcast or NBMA networks, any two routers exchange routing information
with each other. If n routers are present on a network, n(n-1)/2 adjacencies are
required. Any change on a router in the network generates traffic for routing
information synchronization, consuming network resources. The Designated
Router is defined to solve the problem. All other routers on the network send
routing information to the DR, which is responsible for advertising link state
information.
If the DR fails to work, routers on the network have to elect another DR and
synchronize information with the new DR. It is time-consuming and prone to
routing calculation errors. The Backup Designated Router (BDR) was introduced to
reduce the synchronization period.
The BDR is elected along with the DR and establishes adjacencies for routing
information exchange with all other routers. When the DR fails, the BDR will

become the new DR in a very short period by avoiding adjacency establishment

and DR reelection. Meanwhile, other routers elect another BDR, which requires a
relatively long period but has no influence on routing calculation.
Other routers, also known as DRothers establish no adjacency with each other and
exchange no routing information, thus, reducing the number of adjacencies on
broadcast and NBMA networks.
In the following figure, real lines are Ethernet physical links, and dashed lines
represent adjacencies. With the DR and BDR in the network, only seven
adjacencies are enough.
Figure 275 DR and BDR in a network
DR BDR
DRother DRother DRother
DR/BDR election
The DR and BDR in a network are elected by all routers rather than configured
manually. The DR priority of an interface determines its qualification for DR/BDR
election. Interfaces attached to the network and having priorities higher than ‘0"
are election candidates.
The election votes are hello packets. Each router sends the DR elected by itself in a
hello packet to all the other routers. If two routers on the network declare
themselves as the DR, the router with the higher DR priority wins. If DR priorities
are the same, the router with the higher Router ID wins. In addition, a router with
the priority 0 cannot become the DR/BDR.
Note that:
■ The DR election is available on broadcast, NBMA interfaces rather than P2P, or

P2MP interfaces.
■ A DR is an interface of a router and belongs to a single network segment. The
router’s other interfaces may be a BDR or DRother.
■ After DR/BDR election and then a new router joins, it cannot become the DR
immediately even if it has the highest priority on the network.
■ The DR may not be the router with the highest priority in a network, and the
BDR may not be the router with the second highest priority.
OSPF Packet Formats OSPF packets are directly encapsulated into IP packets. OSPF has the IP protocol
number 89. The OSPF packet format, taking a LSU packet as an example, is shown
below.

Figure 276 OSPF packet format
IP header OSPF packet header Number of LSAs LSA header LSA Data
OSPF packet header

OSPF packets are classified into five types that have the same packet header, as
shown below.
Figure 277 OSPF packet header
0 7 15 31
Version Type Packet length
Router ID
Area ID
Checksum AuType
Authentication
Authentication
■ Version: OSPF version number, which is 2 for OSPFv2.

■ Type: OSPF packet type from 1 to 5, corresponding with hello, DD, LSR, LSU
and LSAck respectively.
■ Packet length: Total length of the OSPF packet in bytes, including the header
■ Router ID: ID of the advertising router
■ Area ID: ID of the area where the advertising router resides
■ Checksum: Checksum of the message
■ Autype: Authentication type from 0 to 2, corresponding with
non-authentication, simple (plaintext) authentication and MD5 authentication
respectively.
■ Authentication: Information determined by authentication type, which is not
defined for authentication type 0, password information for authentication
type 1, information about Key ID, MD5 authentication data length and
sequence number for authentication type 2.
n MD5 authentication data is added following an OSPF packet rather than

contained in the Authentication field.
Hello packet
A router sends hello packets periodically to neighbors to find and maintain
neighbor relationships and to elect DR/BDR, including information about values of
timers, DR, BDR and neighbors already known. The format is shown below:

Figure 278 Hello packet format
0 7 15 31
Version 1 Packet length
Router ID
Area ID
Checksum AuType
Authentication
Authentication
Network Mask
HelloInterval Options Rtr Pri
RouterDeadInterval
Designatedrouter
Backup designated router
Neighbor
...
Neighbor
Major fields:
■ Network Mask: The network mask associated with the router’s sending
interface. If two routers have different network masks, they cannot become
neighbors.
■ HelloInterval: The interval between the router’s hello packets. If two routers
have different intervals, they cannot become neighbors.
■ Rtr Pri: Router priority. A value of 0 means the router cannot become the
DR/BDR.
■ RouterDeadInterval: The time value before declaring a silent router down. If
two routers have different time values of this kind, they cannot become
neighbors.
■ Designated Router: IP address of the DR interface.
■ Backup Designated Router: IP address of the BDR interface
■ Neighbor: Router ID of the neighbor router.
DD packet
Two routers exchange Database Description (DD) packets describing their LSDBs
for database synchronization, contents in DD packets including the header of each
LSA (uniquely representing a LSA). The LSA header occupies small part of an LSA,
so reducing traffic between routers. The recipient checks whether the LSA is
available using the LSA header.
The DD packet format:

Figure 279 DD packet format
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
Authentication
M
Interface MTU Options 0 0 0 0 0 I M
S
DD sequence number
LSA header
...
LSA header
Major fields:
■ Interface MTU: The size in bytes of the largest IP datagram that can be sent out
the associated interface, without fragmentation.
■ I (Initial) The Init bit, which is set to 1 if the packet is the first packet in the
sequence of Database Description Packets, and set to 0 if not.
■ M (More): The More bit, which is set to 0 if the packet is the last packet in the
sequence of DD packets, and set to 1 if more DD Packets are to follow.
■ MS (Master/Slave): The Master/Slave bit. When set to 1, it indicates that the
router is the master during the Database Exchange process. Otherwise, the
router is the slave.
■ DD Sequence Number: Used to sequence the collection of Database
Description Packets for ensuring reliability and intactness of DD packets
between the master and slave. The initial value is set by the master. The DD
sequence number then increments until the complete database description has
been sent.
LSR packet
After exchanging DD packets, any two routers know which LSAs of the peer
routers are missing from the local LSDBs. In this case, they send LSR (Link State
Request) packets, requesting the missing LSAs. The packets contain the digests of
the missing LSAs. Figure 280 shows the LSR packet format.

Figure 280 LSR packet format
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
Authentication
LS type
Link state ID
Advertising router
...
Major fields:
■ LS type: The type number of the LSA to be requested, type 1 for example
indicates the Router LSA
■ Link State ID: Determined by LSA type
■ Advertising Router: The ID of the router that sent the LSA
LSU packet
LSU (Link State Update) packets are used to send the requested LSAs to peers, and
each packet carries a collection of LSAs. The LSU packet format is shown below.
Figure 281 LSU packet format
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
Authentication
Number of LSAs
LSA
...
LSA
LSAck packet
LSAack (Link State Acknowledgment) packets are used to acknowledge received
LSU packets, contents including LSA headers to describe the corresponding LSAs.
Multiple LSAs can be acknowledged in a single Link State Acknowledgment
packet. The following figure gives its format.

Figure 282 LSAck packet format
0 7 15 31
Router ID
Area ID
Checksum AuType
Authentication
Authentication
LSA header
...
LSA header
LSA header format

All LSAs have the same header, as shown in the following figure.
Figure 283 LSA header format
0 7 15 31
LS age Options LS type
Linke state ID
Advertising Router
LS sequence number
LS checksum Length
Major fields:
■ LS age: The time in seconds elapsed since the LSA was originated. A LSA ages
in the LSDB (added 1 per second), but does not in transmission.
■ LS type: The type of the LSA
■ Link State ID: The contents of this field depend on the LSA’s type
■ LS sequence number: Used by other routers to judge new and old LSAs.
■ LS checksum: Checksum of the LSA except the LS age field
■ Length: The length in bytes of the LSA, including the LSA header

Formats of LSAs
1 Router LSA
Figure 284 Router LSA format
0 7 15 31
LS age Options 1
Linke state ID
Advertising Router
LS sequence number
LS checksum Length
0 V E B 0 # links
Link ID
Link data
Type #TOS metric
...
TOS 0 TOS metric
Link ID
Link data
...
Major fields:
■ Link State ID: The ID of the router that originated the LSA.
■ V (Virtual Link): Set to 1 if the router that originated the LSA is a virtual link
endpoint.
■ E (External): Set to 1 if the router that originated the LSA is an ASBR.
■ B (Border): Set to 1 if the router that originated the LSA is an ABR.
■ # links: The number of router links (interfaces) to the area, described in the
LSA.
■ Link ID: Determined by Link type.
■ Link Data: Determined by Link type.
■ Type: Link type. A value of 1 indicates a point-to-point link to a remote router;
a value of 2 indicates a link to a transit network; a value of 3 indicates a link to
a stub network; a value of 4 indicates a virtual link.
■ #TOS: The number of different TOS metrics given for this link.
■ metric: The cost of using this router link.
■ TOS: IP Type of Service that this metric refers to.
■ TOS metric: TOS-specific metric information.
2 Network LSA
A Network LSA is originated by the DR on a broadcast or NBMA network. The LSA

describes all routers attached to the network.

Figure 285 Network LSA format
0 7 15 31
LS age Options 2
Linke state ID
Advertising Router
LS sequence number
LS checksum Length
Network mask
Attached router
...
Major fields:
■ Link State ID: The interface address of the DR

■ Network Mask: The mask of the network (a broadcast or NBMA network)
■ Attached Router: The IDs of the routers, which are adjacent to the DR,
including the DR itself
3 Summary LSA
Network summary LSAs (type3 LSAs) and ASBR summary LSAs (type4 LSAs) are
originated by ABRs. Other than the difference in the Link State ID field, the format
of type 3 and 4 summary-LSAs is identical.
Figure 286 Summary LSA format
0 7 15 31
LS age Options 3or4
Linke state ID
Advertising Router
LS sequence number
LS checksum Length
Network mask
0 metric
TOS TOS metric
...
Major fields:
■ Link State ID: For a type3 LSA, it is an IP address outside the area; for a type 4
LSA, it is the router ID of an ASBR outside the area.
■ Network Mask: The network mask for the type 3 LSA; set to 0.0.0.0 for the
type4 LSA
■ metric: The metric to the destination

n A type3 LSA can be used to advertise a default route, having the Link State ID and
Network Mask set to 0.0.0.0.
4 AS external LSA
An AS external LSA originates from an ASBR, describing routing information to a

destination outside the AS.
Figure 287 AS external LSA format
0 7 15 31
LS age Options 5
Linke state ID
Advertising Router
LS sequence number
LS checksum Length
Network mask
E 0 Metric
Forwarding address
External route tag
E TOS TOS metric

Forwarding address
External route tag
...
Major fields:
■ Link State ID: The IP address of another AS to be advertised. When describing a

default route, the Link State ID is always set to Default Destination (0.0.0.0)
and the Network Mask is set to 0.0.0.0
■ Network Mask: The IP address mask for the advertised destination
■ E (External Metric): The type of the external metric value, which is set to 1 for
type 2 external routes, and set to 0 for type 1 external routes. Refer to “Route
types” on page 924 for description about external route types
■ metric: The metric to the destination
■ Forwarding Address: Data traffic for the advertised destination will be
forwarded to this address
■ External Route Tag: A tag attached to each external route. This is not used by
the OSPF protocol itself. It may be used to manage external routes.
5 NSSA external LSA
An NSSA external LSA originates from the ASBR in a NSSA and is flooded in the
NSSA area only. It has the same format as the AS external LSA.

Figure 288 NSSA external LSA format
0 7 15 31
LS age Options 7
Linke state ID
Advertising Router
LS sequence number
LS checksum Length
Network mask
E TOS Metric
Forwarding address
External route tag
...
OSPF Features Multi-process

Supported With multi-process support, multiple OSPF processes can run on a router
simultaneously and independently. Routing information interactions between
different processes seem like interactions between different routing protocols.
Multiple OSPF processes can use the same RID.
An interface of a router can only belong to a single OSPF process.
Authentication
OSPF supports authentication on packets. Only packets that pass the
authentication are received. If hello packets cannot pass authentication, no
neighbor relationship can be established.
The authentication type for interfaces attached to a single area must be identical.
Authentication types include non-authentication, plaintext authentication and
MD5 ciphertext authentication. The authentication password for interfaces
attached to a network segment must be identical.
OSPF Graceful Restart
n For GR information, refer to “GR Overview” on page 1957.
After an OSPF GR Restarter restarts OSPF, it needs to perform the following two
tasks in order to re-synchronize its LSDB with its neighbors.
■ To obtain once again effective OSPF neighbor information, assuming the

adjacencies are not changed.
■ To obtain once again LSDB contents.
Before the restart, the GR Restarter originates Grace-LSAs to negotiate the GR

capability. During the restart, the GR Helpers continue to advertise their
adjacencies with the GR Restarter.

After the restart, the GR Restarter will send an OSPF GR signal to its neighbors that
will not reset their adjacencies with it. In this way, the GR Restarter can restore the
neighbor table upon receiving the responses from neighbors.
After reestablishing neighborships, the GR Restarter will synchronize the LSDB and
exchange routing information with all adjacent GR-capable neighbors. After that,
the GR Restarter will update its own routing table and forwarding table based on
the new routing information and remove the stale routes. In this way, the OSPF
TE and DS-TETE
OSPF Traffic Engineering (TE) provides for the establishment and maintenance of
Label Switch Paths (LSPs) of TE.
When establishing Constraint-based Routed LSPs (CR LSPs), MPLS obtains the TE
information of links in the area via OSPF.
OSPF has a new LSA, Opaque LSA, which can be used for carrying TE information.
DiffServ Aware TE (DS-TE) provides for network resource optimization and

allocation, flow classification, and indication of network bandwidth consumption
of each flow in a link. TE is implemented on the classified type (thin granularity
summarization type) rather than the summarized type (thick granularity
summarization type) to improve performance and bandwidth utilization.
To support DS-TE application in MPLS, OSPF supports Local Overbooking Multiplier

TLV and Bandwidth Constraint (BC) TLV.
n For OSPF TE configuration, refer to “MPLS TE Configuration” on page 1345.
IGP Shortcut and Forwarding Adjacency

IGP Shortcut and Forwarding Adjacency enable OSPF to use a LSP as the outbound
interface for a destination. Without them, OSPF cannot use the LSP as the
outbound interface.
Differences between IGP Shortcut and Forwarding Adjacency:
■ If Forwarding Adjacency is enabled only, OSPF can also use an LSP as the
outbound interface for a destination
■ If LGP Shortcut is enabled only, only the router enabled with it can use LSPs for
routing.
n For configuration of this feature, refer to “MPLS TE Configuration” on page 1345.
VPN
OSPF supports multi-instance, which can run on PEs in VPN networks.
In BGP MPLS VPN networks, multiple sites in the same VPN can use OSPF as the
internal routing protocol, but they are treated as different ASs. An OSPF route
learned by a site will be forwarded to another site as an external route, which
leads to heavy OSPF routing traffic and management issues.

OSPF Configuration Task List 937
Configuring area IDs on PEs can differentiate VPNs. Sites in the same VPN are
considered as directly connected. PE routers then exchange OSPF routing
information like on a dedicated line, thus network management and OSPF
operation efficiency are improved.
n For configuration of this feature, refer to “BGP Configuration” on page 825 and
“MPLS Basics Configuration” on page 1311.
OSPF sham link

An OSPF sham link is a point-to-point link between two PE routers on the MPLS
VPN backbone.
In general, BGP peers exchange routing information on the MPLS VPN backbone
using the BGP extended community attribute. OSPF running on a PE at the other
end utilizes this information to originate a type3 summary LSA as an inter-area
route between the PE and CE.
If a router connects to a PE router in the same area and establishes an internal

route (backdoor route) for a special destination, in this case, since an OSPF
intra-area route has a higher priority than a backbone route, VPN traffic will
always travel on the backdoor route rather than the backbone route. To avoid this,
an unnumbered sham link can be configured between PE routers, connecting the
router to another PE router via an intra-area route with low cost.
n For sham link configuration, refer to “BGP Configuration” on page 825 and “MPLS
Basics Configuration” on page 1311.
Related RFCs ■ RFC 1765:OSPF Database Overflow

■ RFC 2328: OSPF Version 2
■ RFC 3101: OSPF Not-So-Stubby Area (NSSA) Option
■ RFC 3137: OSPF Stub Router Advertisement
■ RFC 3630: Traffic Engineering Extensions to OSPF Version 2
OSPF Configuration Complete the following tasks to configure OSPF:

Task List
Task Description
“Configuring OSPF Basic Functions” on page 939 Required
“Configuring OSPF Area Parameters” on page 940 Optional
“Configuring OSPF Network “Configuring the OSPF Optional
Types” on page 941 Network Type for an
Interface” on page 941
“Configuring an NBMA Optional
Neighbor” on page 942
“Configuring a Router Priority Optional
for an OSPF Interface” on
page 942

Task Description
“Configuring OSPF Routing “Configuring OSPF Route Optional
Information Control” on Summarization” on page 943
page 942
“Configuring OSPF Inbound Optional
Route Filtering” on page 943
“Configuring ABR Type3 LSA Optional
Filtering” on page 943
“Configuring OSPF Link Cost” Optional
on page 944
Number of OSPF Routes” on
page 944
Number of Load-balanced
“Configuring OSPF Priority” Optional
on page 945
“Configuring OSPF Route Optional
Redistribution” on page 945
“Configuring OSPF Network “Configuring OSPF Packet Optional
Optimization” on page 946 Timers” on page 946
“Configuring LSA Optional
Transmission Delay Time” on
page 947
“Configuring SPF Calculation Optional
Interval” on page 948
“Configuring LSA Minimum Optional
Repeat Arrival Interval” on
page 948
“Configuring LSA Generation Optional
Interval” on page 948
“Disabling Interfaces from Optional
Sending OSPF Packets” on
page 949
“Configuring Stub Routers” Optional
on page 949
“Configuring OSPF Optional
Authentication” on page 950
“Adding Interface MTU into Optional
DD Packets” on page 950
Number of External LSAs in
LSDB” on page 951
“Making External Route Optional
Selection Rules Defined in
RFC1583 Compatible” on
page 951
“Logging Neighbor State Optional
“Enabling the Advertisement Optional
and Reception of Opaque
LSAs” on page 952

Task Description
“Configuring OSPF Graceful “Configuring the OSPF GR Optional
Restart” on page 952 Restarter” on page 952
“Configuring the OSPF GR Optional
Helper” on page 953
“Triggering OSPF Graceful Optional
Restart” on page 953
Configuring OSPF You need to enable OSPF, specify an interface and area ID first before performing
Basic Functions other tasks.
Prerequisites Before configuring OSPF, you have configured the link layer protocol, and IP
addresses for interfaces, making neighboring nodes accessible with each other at
the network layer.
Configuration Procedure To ensure OSPF stability, you need to decide on router IDs and configure them
manually. Any two routers in an AS must have different IDs. In practice, the ID of a
router is the IP address of one of its interfaces.
The system supports OSPF multi-process. When a router runs multiple OSPF
processes, you need to specify an ID for each process, which takes effect locally
and has no interference on packet exchange between routers. Therefore, two
routers having different process IDs can exchange packets.
The system supports OSPF multi-instance. You can configure an OSPF process to
run in a specified VPN instance to configure an association between the two.
The configurations for routers in an area are performed on the area basis. Wrong
configurations may cause communication failures, even routing information block
or routing loops between neighboring routers.
Follow these steps to configure OSPF basic functions:

Enable OSPF and enter its ospf [ process-id | router-id Required
view router-id | vpn-instance
instance-name ] *
Configure a description for description description Optional
the OSPF process
Configure an OSPF area and area area-id Required
enter OSPF area view
Configure a description for description description Optional
the area
Specify a network for the area network ip-address Required
to enable OSPF on the wildcard-mask
interface attached to the
network

n ■ An OSPF process ID is unique, including the process ID for OSPF multi-instance,

which cannot be the same as any previously configured ID.
■ A network segment can only belong to one area.
■ It is recommended to configure a description for each OSPF process to help
identify purposes of processes and for ease of management and memorization.
■ It is recommended to configure a description for each area to help identify
purposes of areas and for ease of management and memorization.
Configuring OSPF Splitting an OSPF AS into multiple areas reduces the number of LSAs on networks
Area Parameters and extends OSPF application. For those non-backbone areas residing on the AS
boundary, you can configure them as Stub areas to further reduce the size of
routing tables on routers in these areas and the number of LSAs.
A stub area cannot redistribute routes, thus introducing the concept of NSSA,
where type 7 LSAs (NSSA External LSAs) are advertised. Type 7 LSAs originate from
the ASBR in a NSSA area. When arriving at the ABR in the NSSA area, these LSAs
will be translated into type 5 LSAs for advertisement to other areas.
Non-backbone areas exchange routing information via the backbone area.

Therefore, the backbone and non-backbone areas, including the backbone itself
must maintain connectivity.
If necessary physical links are not available for this connectivity maintenance, you
can configure virtual links to solve it.
Prerequisites Before configuring an OSPF area, you have configured:

■ IP addresses for interfaces, making neighboring nodes accessible with each
other at network layer.
■ OSPF basic functions
Configuration Procedure Follow these steps to configure OSPF area parameters:

Enter OSPF view ospf [ process-id | router-id -
router-id | vpn-instance
instance-name ] *
Enter area view area area-id Required
Configure the area as a stub stub [ no-summary ] Optional
area
Configure the area as an nssa Optional
NSSA area [ default-route-advertise |
no-import-route |
no-summary ] *
Specify a cost for the default default-cost cost Optional
route advertised to the stub or
Defaults to 1
NSSA area

Configuring OSPF Network Types 941

Create and configure a virtual vlink-peer router-id [ hello Optional
link seconds | retransmit seconds
Configured on both ends of a
| trans-delay seconds | dead
virtual link
seconds | simple [ plain |
cipher ] password | { md5 | Note that hello and dead
hmac-md5 } key-id [ plain | parameters must be identical
cipher ] password ] * on both ends of the link
Configure and advertise a host-advertise ip-address Optional
host route cost
n ■
■
It is required to use the stub command on routers attached to a stub area.
It is required to use the nssa command on routers attached to an NSSA area.
■ Using the default-cost command only takes effect on the ABR of a stub area
or the ABR/ASBR of an NSSA area.
Configuring OSPF OSPF classifies networks into four types upon link layer protocols. Since an NBMA
Network Types network must be fully meshed, namely, any two routers in the network must have
a virtual link in between. In most cases, however, the requirement cannot be
satisfied, so you need to change the network type using commands.
For routers having no direct link in between, you can configure related interfaces
as the P2MP mode. If a router in the NBMA network has only a single peer, you
can also configure associated interfaces as the P2P mode.
In addition, when configuring broadcast and NBMA networks, you can specify for
interfaces router priorities for DR/BDR election. In practice, routers having higher
reliability should become the DR/BDR.
Prerequisites Before configuring OSPF network types, you have configured:

■ IP addresses for interfaces, making neighboring nodes accessible with each
other at network layer.
Configuring the OSPF Follow these steps to configure the OSPF network type for an interface:
Network Type for an
interface-number
Configure the network ospf network-type Optional
type { broadcast | nbma | p2mp |
p2p }
The network type of an interface
depends on the media type of
the interface
n ■ Configuring a new network type for an interface overwrites the previous

network one (if any).

■ If the two interfaces on a link are both configured as the broadcast, NBMA or
P2MP type, they cannot establish neighbor relationship unless they are on the
same network segment.
Configuring an NBMA For NBMA interfaces that cannot broadcast hello packets to find neighbors, you
Neighbor need to specify IP addresses and DR priorities of neighbors manually.
Follow these steps to configure a neighbor and its DR priority:

Enter OSPF view ospf [ process-id | router-id router-id | -
vpn-instance instance-name ]*
Specify an NBMA neighbor peer ip-address [ dr-priority dr-priority ] Required
and its DR priority
Configuring a Router For broadcast or NBMA interfaces, you can configure router priorities for DR/BDR
Priority for an OSPF election.
Interface
Follow these steps to configure a router priority for an OSPF interface:

interface-number
Configure a router priority for ospf dr-priority priority Optional
the interface
The default router priority is 1
n The DR priority configured with the ospf dr-priority command and the one with
the peer command have the following differences
■ The former is for actual DR election.
■ The latter is to indicate whether a neighbor has election right or not. If you
configure the DR priority for a neighbor as 0, the local router will consider the
neighbor has no election right, thus no hello packet is sent to this neighbor,
reducing the number of hello packets for DR/BDR election on networks.
However, if the local router is the DR or BDR, it will send a hello packet to the
neighbor with priority 0 for adjacency relationship establishment.
Configuring OSPF This section is to configure management for OSPF routing information
Routing Information advertisement and reception, and route redistribution from other protocols.
Control
Prerequisites To configure this task, you have configured:

■ IP addresses for interfaces
■ Corresponding filters if routing information filtering is needed.

Configuring OSPF Route OSPF route summarization includes:

Summarization ■ Configure route summarization between OSPF areas on an ABR
■ Configure route summarization when redistributing routes into OSPF on an
ASBR
Follow these steps to configure route summarization between OSPF areas on an

ABR:

instance-name ] *
Enter OSPF area view area area-id Required
Configure ABR route abr-summary ip-address { mask | Required
summarization mask-length } [ advertise |
Available on an ABR only
not-advertise ] [ cost cost ]
Follow these steps to configure route summarization when redistributing routes

into OSPF on an ASBR:

instance-name ]*
Configure ASBR route asbr-summary ip-address { mask | Required
summarization mask-length } [ tag tag |
Not configured by
not-advertise | tag tag-value |
default
cost cost ] *
Configuring OSPF Follow these steps to configure OSPF to filter received routes:
Inbound Route Filtering
instance-name ]*
Configure to filter filter-policy { acl-number | Required
received routes ip-prefix ip-prefix-name | gateway
ip-prefix-name } import
n Since OSPF is a link state-based internal gateway protocol, routing information is

contained in LSAs. However, OSPF cannot filter LSAs. Using the filter-policy
import command is to filter routes computed by OSPF, and only routes not
filtered are added into the routing table.
Configuring ABR Type3 Follow these steps to configure type 3 LSA filtering on an ABR:
LSA Filtering


Enter system view System-view -
instance-name ] *
Enter area view area area-id -
Configure ABR type3 LSA filter { acl-number | ip-prefix Required
filtering ip-prefix-name } { import |
export }
Configuring OSPF Link Follow these steps to configure the link cost for an interface:
Cost
interface-number
Configure the cost value of ospf cost value Optional
the interface
By default, an interface
computes its cost according to
the baud rate.
Follow these steps to configure a bandwidth reference value:

instance-name ]*
Configure a bandwidth bandwidth-reference value Optional
reference value
The value defaults to 100
Mbps
n If the cost value is not configured for an interface, OSPF computes the interface
cost value automatically: Interface value= Bandwidth reference value/Interface
bandwidth. If the calculated cost value is greater than 65535, the maximum cost
will be 65535.
Configuring the Follow these steps to configure the maximum number of routes:
Maximum Number of
OSPF Routes To do... Use the command... Remarks
vpn-instance instance-name ] *
Configure the maximum maximum-routes { external | inter | Optional
number of OSPF routes intra } number
Configuring the If several routes with the same cost to the same destination are available,
Maximum Number of configuring them as load-balanced routes can improve link utilization.
Load-balanced Routes

Follow these steps to configure the maximum number of load-balanced routes:

Configure the maximum maximum load-balancing maximum Optional
number of equivalent
load-balanced routes
Configuring OSPF A router may run multiple routing protocols. The router sets a priority for each
Priority protocol, when a route found by several routing protocols, the route found by the
protocol with the highest priority will be selected.
Follow these steps to configure the priority for OSPF:

instance-name ] *
Configure OSPF preference [ ase ] Optional
route priority [ route-policy
The priority of OSPF internal routes
route-policy-name ] value
defaults to 10
The priority of OSPF external routes
defaults to 150
Configuring OSPF Route Follow these steps to configure OSPF route redistribution:
Redistribution
Enter OSPF view ospf [ process-id | router-id router-id -
| vpn-instance instance-name ] *
Configure OSPF to import-route protocol [ process-id | Required
redistribute routes from other allow-ibgp ] [ cost cost | type type |
Not configured by
protocols tag tag | route-policy
default
Configure OSPF to filter filter-policy { acl-number | ip-prefix Optional
redistributed routes before ip-prefix-name } export [ protocol
Not configured by
advertisement [ process-id ] ]
default
Redistribute a default route default-route-advertise [ always | Optional
cost cost | type type | route-policy
Not redistributed by
default
default-route-advertise summary
cost cost


Configure the default values default { cost cost | limit limit | tag Optional
of parameters for tag | type type } *
By default, the default
redistributed routes (cost,
cost is 1, default
route number, tag and type)
upper limit of routes
redistributed per time
is 1000, default tag is
1 and default type of
redistributed routes is
type2.
n ■ Using the import-route command cannot redistribute a default external

route. To do so, you need to use the default-route-advertise command.
■ The default-route-advertise summary cost command is applicable only to
VPN, and the default route is redistributed in a Type-3 LSA. The PE router will
advertise the default route to the CE router.
■ By filtering redistributed routes, OSPF translates only routes, which are not
filtered out, into type5 LSAs or type7 LSAs for advertisement.
■ You can configure default values of parameters for redistributed routes, such
as the cost, upper limit, tag and type of external routes. The tag is used to
indicate information related to protocol, for example, when redistributing BGP
routes, OSPF uses the tag to differentiate AS IDs.
Configuring OSPF You can optimize your OSPF network in the following ways:
Network Optimization ■ Change values of OSPF packet timers to adjust the OSPF network convergence
speed and network load. On low speed links, you need to consider the delay
time for sending LSAs on interfaces.
■ Change the interval for SPF calculation to reduce resource consumption caused
by frequent network changes.
■ Configure OSPF authentication to meet high security requirements of some
mission-critical networks.
■ Configure OSPF network management functions, such as binding OSPF MIB
with a process, sending trap information and collecting log information.
Prerequisites Before configuring OSPF network optimization, you have configured:

■ IP addresses for interfaces
Configuring OSPF Packet You can configure the following timers on OSPF interfaces as needed:
Timers ■ Hello timer: Interval for sending hello packets, must be identical on OSPF
neighbors. The longer the interval, the lower convergence speed and smaller
network load.
■ Poll timer: Interval for sending hello packets to the neighbor that is down on
the NBMA network.
■ Dead timer: Interval within which if the interface receives no hello packet from
the neighbor, it declares the neighbor is down.

■ LSA retransmit timer: Interval within which if the interface receives no

acknowledgement packets after sending a LSA to the neighbor, it will
retransmit the LSA.
Follow these steps to configure timers for OSPF packets:

interface-number
Specify the hello interval ospf timer hello seconds Optional
The hello interval on P2P, Broadcast
interfaces defaults to 10 seconds
and defaults to 30 seconds on
P2MP and NBMA interfaces.
Specify the poll interval ospf timer poll seconds Optional
The poll interval defaults to 120
seconds.
Specify the dead ospf timer dead seconds Optional
interval
The dead interval defaults to 40
seconds on P2P, Broadcast
interfaces and 120 seconds on
P2MP and NBMA interfaces.
Specify the ospf timer retransmit Optional
retransmission interval interval
The retransmission interval defaults
to 5 seconds.
n ■ The hello and dead intervals restore to default values after you change the
network type for an interface.
■ The dead interval should be at least four times the hello interval on an
interface.
■ The poll interval is at least four times the hello interval.
■ The retransmission interval should not be so small for avoidance of unnecessary
LSA retransmissions. In general, this value is bigger than the round-trip time of
a packet between two adjacencies.
Configuring LSA Since OSPF packets need time for traveling on links, extending LSA age time with
Transmission Delay Time some delay time is necessary, especially for low speed links.
Follow these steps to configure the LSA transmission delay time on an interface:

interface-number
Set the LSA transmission delay ospf trans-delay seconds Optional
time
Set to 1 second by default

Configuring SPF Link State Database changes lead to SPF calculations. When an OSPF network
Calculation Interval changes frequently, a large amount of network resources will be occupied,
reducing working efficiency of routers. You can adjust the SPF calculation interval
for the network to reduce negative influence.
Follow these steps to adjust the SPF calculation interval:

instance-name ] *
Set the SPF calculation interval spf-schedule-interval Optional
maximum-interval
By default, the interval is 5
[ minimum-interval
seconds
n With this command configured, when network changes are not frequent, SPF
calculation applies at the minimum-interval. If network changes become frequent,
SPF calculation interval is incremented by incremental-interval•2n-2 (n is the
number of calculation times) each time a calculation occurs, up to the
maximum-interval.
Configuring LSA When an interface receives an LSA that is the same with the previously received
Minimum Repeat Arrival LSA within a specified interval, the LSA minimum repeat arrival interval, the
Interval interface will discard the LSA.
Follow these steps to configure the LSA minimum repeat arrival interval:

instance-name ] *
Configure the LSA minimum lsa-arrival-interval interval Optional
repeat arrival interval
Defaults to 1000 milliseconds
n The interval set by the lsa-arrival-interval command should be smaller or equal

to the interval set by the lsa-generation-interval command.
Configuring LSA With this feature configured, you can protect network resources and routers from
Generation Interval being over consumed due to frequent network changes.
Follow these steps to configure LSA generation interval:

Enter OSPF view ospf [ process-id | router-id Required
instance-name ] *


Configure the LSA lsa-generation-interval Optional
generation interval maximum-interval [ initial-interval
By default, the maximum
incremental-interval ] ]
interval is 5 seconds, the
minimum interval is 0
millisecond and the
incremental interval is 5000
milliseconds.
n With this command configured, when network changes are not frequent, LSAs
are generated at the minimum-interval. If network changes become frequent, LSA
generation interval is incremented by incremental-interval•2n-2 (n is the number of
generation times) each time a generation occurs, up to the maximum-interval.
Disabling Interfaces Follow these steps to disable an interface from sending routing information to
from Sending OSPF other routers:
Packets
instance-name ] *
Disable interfaces from silent-interface { all | Optional
sending OSPF packets interface-type interface-number }
n ■ Different OSPF processes can disable the same interface from sending OSPF
packets. Use of the silent-interface command disables only the interfaces
associated with the current process rather than interfaces associated with other
processes.
■ After an OSPF interface is set to silent, other interfaces on the router can still
advertise direct routes of the interface in router LSAs, but no OSPF packet can
be advertised for the interface to find a neighbor. This configuration can
enhance adaptability of OSPF networking and reduce resource consumption.
Configuring Stub A stub router is used for traffic control. It informs other OSPF routers not to use it
Routers to forward data, but they can have a route to the stub router.
The router LSAs from the stub router may contain different link type values. A
value of 3 means a link to the stub network, so the cost of the link remains
unchanged. A value of 1, 2 or 4 means a point-to-point link, a link to a transit
network or a virtual link, in such cases, a maximum cost value of 65535 is used.
Thus, other neighbors find the links to the stub router have such big costs, they
will not send packets to the stub router for forwarding as long as there is a route
with a smaller cost.
Follow these steps to configure a router as a stub router:



instance-name ] *
Configure the router as a stub stub-router Required
router
n A stub router has nothing to do with a stub area.
Configuring OSPF By supporting packet authentication, OSPF receives packets that pass the
Authentication authentication only, so failed packets cannot establish neighboring relationship.
Follow these steps to configure OSPF authentication:

instance-name ] *
Enter area view area area-id -
Configure the authentication authentication-mode { simple Required
mode | md5 }
Exit to OSPF view quit -
interface-number
Configure the authentication ospf authentication-mode Optional
mode (simple authentication) simple [ plain | cipher ]
for the interface password
Configure the authentication ospf authentication-mode
mode (MD5 authentication) { md5 | hmac-md5 } key-id
for the interface [ plain | cipher ] password
n The authentication mode and password for all interfaces attached to the same
area must be identical.
Adding Interface MTU Generally, when an interface sends a DD packet, it adds 0 into the Interface MTU
into DD Packets field of the DD packet rather than the interface MTU.
Follow these steps to add the interface MTU into DD packets:

interface-number


Enable OSPF to add interface ospf mtu-enable Optional
MTU into DD packets
Not enabled by default, that
is, the interface fills in a value
of 0
Configuring the Follow these steps to configure the maximum number of external LSAs in the Link
Maximum Number of State Database:
External LSAs in LSDB
instance-name ] *
Specify the maximum number lsdb-overflow-limit number Optional
of external LSAs in the LSDB
No limitation by default
Making External Route The selection of an external route from multiple LSAs defined in RFC2328 is
Selection Rules Defined different from the one defined in RFC1583.
in RFC1583 Compatible
Follow these steps to make external route selection rules defined in RFC1583
compatible:

Enter OSPF view ospf [ process-id | router-id Required
instance-name ] *
Make RFC1583 compatible rfc1583 compatible Optional
Compatible by default
Logging Neighbor State Follow these steps to log neighbor state changes
Changes
Enable the logging of log-peer-change Optional
neighbor state
Enabled by default
changes
Configuring OSPF Follow these steps to configure OSPF network management:

Network Management
Bind OSPF MIB to an ospf mib-binding process-id Optional
OSPF process
The first OSPF process
bound with OSPF MIB by
default


Enable OSPF trap snmp-agent trap enable ospf Optional
[ process-id ] [ ifauthfail | ifcfgerror |
Enabled by default
ifrxbadpkt | ifstatechange |
iftxretransmit |
lsdbapproachoverflow |
lsdboverflow | maxagelsa |
nbrstatechange | originatelsa |
vifcfgerror | virifauthfail |
virifrxbadpkt | virifstatechange |
viriftxretransmit |
virnbrstatechange ] *
vpn-instance instance-name ]*
Enable messages enable log [ config | error | state ] Optional
logging
Enabling the With this feature enabled, the OSPF router can receive and advertise the Type 9,
Advertisement and Type 10 and Type 11 opaque LSAs.
Reception of Opaque
LSAs Follow these steps to enable the advertisement and reception of opaque LSAs:

instance-name ] *
Enable the advertisement and opaque-capability enable Optional
reception of opaque LSAs
Disabled by default
Configuring OSPF
Graceful Restart
n One device can act as both a GR Restarter and a GR Helper at the same time.
Configuring the OSPF GR You can configure the IETF standard or non IETF standard OSPF Graceful Restart
Restarter capability on a GR Restarter.
Configuring the IETF standard OSPF GR Restarter

Follow these steps to configure the standard IETF OSPF GR Restarter:

Enable OSPF and ospf [ process-id | router-id router-id | Required
enter its view vpn-instance instance-name ] *
Disabled by default
Enable opaque LSA opaque-capability enable Required
advertisement
Disabled by default
capability


Enable the IETF graceful-restart ietf Required
standard Graceful
Disabled by default
Restart capability for
OSPF
Configure the graceful-restart interval timer Optional
Graceful Restart
interval for OSPF
Configuring the non-IETF standard OSPF GR Restarter

Follow these steps to configure non-IETF standard OSPF GR Restarter:

Enable OSPF and ospf [ process-id | router-id Required
enter its view router-id | vpn-instance
Disabled by default
instance-name ] *
Enable the use of enable link-local-signaling Required
link-local signaling
Disabled by default
Enable out-of-band enable Required
re-synchronization out-of-band-resynchronization
Disabled by default
Enable non IETF graceful-restart [ nonstandard ] Required
standard Graceful
Disabled by default
Restart capability for
OSPF
Configure the graceful-restart interval timer Optional
Graceful Restart
interval for OSPF
Configuring the OSPF GR Follow these steps to configure the OSPF GR Helper:
Helper
Enable OSPF and enter its ospf [ process-id | router-id Required
view router-id | vpn-instance
Disabled by default
instance-name ] *
Configure for which OSPF graceful-restart help Optional
neighbors the current { acl-number | prefix prefix-list }
The router can server as a
router can serve as a GR
GR Helper for any OSPF
Helper
neighbor by default.
Triggering OSPF Graceful Performing main/backup switchover on a distributed device with two PDUs, or
Restart performing the following configuration on an OSPF router will trigger OSPF
Graceful Restart. Ensure that these routers are enabled with the following
capabilities first:
■ LLS (link local signaling)
■ OOB (out of band re-synchronization)
■ Opaque LSA advertisement
■ IETF GR capability

Follow these steps to trigger OSPF Graceful Restart:

Trigger OSPF Graceful reset ospf [ process-id ] process Required
Restart graceful-restart
Displaying and
Maintaining OSPF To do... Use the command... Remarks
Configuration Display OSPF brief display ospf [ process-id ] brief Available in
Display OSPF statistics display ospf [ process-id ] cumulative
Display Link State display ospf [ process-id ] lsdb [ brief | [ { ase |
Database information router | network | summary | asbr | nssa |
opaque-link | opaque-area | opaque-as }
[ link-state-id ] ] [ originate-router
advertising-router-id | self-originate ] ]
Display OSPF neighbor display ospf [ process-id ] peer [ verbose |
information [ interface-type interface-number ]
[ neighbor-id ] ]
Display neighbor statistics display ospf [ process-id ] peer statistics
of OSPF areas
Display next hop display ospf [ process-id ] nexthop
information
Display routing table display ospf [ process-id ] routing [ interface
information interface-type interface-number ] [ nexthop
nexthop-address ]
Display virtual link display ospf [ process-id ] vlink
information
Display OSPF request display ospf [ process-id ] request-queue
queue information [ interface-type interface-number ] [ neighbor-id ]
Display OSPF display ospf [ process-id ] retrans-queue
retransmission queue [ interface-type interface-number ] [ neighbor-id ]
information
Display OSPF ABR and display ospf [ process-id ] abr-asbr
ASBR information
Display OSPF interface display ospf [ process-id ] interface [ all |
information interface-type interface-number ]
Display OSPF error display ospf [ process-id ] error
information
Display OSPF ASBR display ospf [ process-id ] asbr-summary
summarization information [ ip-address { mask | mask-length } ]
Reset OSPF counters reset ospf [ process-id ] counters [ neighbor Available in
[ interface-type interface-number ] [ router-id ] ] user view
Reset an OSPF process reset ospf [ process-id ] process
[ graceful-restart ]
Remove redistributed reset ospf [ process-id ] redistribution
routes

OSPF Configuration
Examples
c CAUTION: In these examples, only commands related to OSPF configuration are

described.
Configuring OSPF Basic Network requirements

Functions As shown in the following figure, all routers run OSPF. The AS is split into three
areas, in which, RouterA and RouterB act as ABRs.
After configuration, all routers can learn routes to every network segment in the
AS.
Network diagram
Figure 289 Network diagram for OSPF basic configuration
Router A Area 0 Router B

Eth1/0
10.1.1.1 /24
Eth1/0
Eth1/1 10 .1 .1.2/24 Eth1/1
10.2.1.1/24 10.3.1.1 /24
Eth1/0
Area 1 Eth1/0 Area 2
10.2.1.2/24 10.3.1.2/24
Eth1/1 Eth1/0
Router C 10.4.1.1/24 10 .5.1.1/24 Router D
2 Configure OSPF basic functions
# Configure RouterA
[RouterA] ospf
# Configure RouterB
[RouterB] ospf


# Configure RouterC
[RouterC] ospf
[RouterC-ospf-1] area 1
# Configure RouterD
[RouterD] ospf
[RouterD-ospf-1] area 2
3 Verify the above configuration
# Display OSPF neighbors information on Router A.[RouterA] display ospf peer
verbose
OSPF Process 1 with Router ID 10.2.1.1
Neighbors
Area 0.0.0.0 interface 10.1.1.1(Ethernet1/0)’s neighbors

Router ID: 10.3.1.1 Address: 10.1.1.2 GR State: Normal
State: Full Mode: Nbr is Master Priority: 1
DR: 10.1.1.1 BDR: 10.1.1.2 MTU: 0
Dead timer due in 37 sec
Neighbor is up for 06:03:59
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
Neighbors

DR: 10.2.1.1 BDR: 10.2.1.2 MTU: 0
Neighbor state change count: 5
# Display OSPF routing information on RouterA[RouterA] display ospf routing

Routing Tables
Routing for Network

Destination Cost Type NextHop AdvRouter Area
10.2.1.0/24 10 Transit 10.2.1.1 10.2.1.1 0.0.0.1
10.3.1.0/24 4 Inter 10.1.1.2 10.3.1.1 0.0.0.0
10.4.1.0/24 13 Stub 10.2.1.2 10.4.1.1 0.0.0.1
10.5.1.0/24 14 Inter 10.1.1.2 10.3.1.1 0.0.0.0
10.1.1.0/24 2 Transit 10.1.1.1 10.2.1.1 0.0.0.0

Total Nets: 5
Intra Area: 3 Inter Area: 2 ASE: 0 NSSA: 0
# Display the Link State Database on RouterA
[RouterA] display ospf lsdb

Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.2.1.1 10.2.1.1 1069 36 80000012 0
Router 10.3.1.1 10.3.1.1 780 36 80000011 0
Network 10.1.1.1 10.2.1.1 1069 32 80000010 0
Sum-Net 10.5.1.0 10.3.1.1 780 28 80000003 12
Sum-Net 10.2.1.0 10.2.1.1 1069 28 8000000F 10
Sum-Net 10.3.1.0 10.3.1.1 780 28 80000014 2
Sum-Net 10.4.1.0 10.2.1.1 769 28 8000000F 13
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.2.1.1 10.2.1.1 769 36 80000012 0
Router 10.4.1.1 10.4.1.1 1663 48 80000012 0
Network 10.2.1.1 10.2.1.1 769 32 80000010 0
Sum-Net 10.5.1.0 10.2.1.1 769 28 80000003 14
Sum-Net 10.3.1.0 10.2.1.1 1069 28 8000000F 4
Sum-Net 10.1.1.0 10.2.1.1 1069 28 8000000F 2
Sum-Asbr 10.3.1.1 10.2.1.1 1069 28 8000000F 2
# Display routing table information on Router D.
[RouterD] display ospf routing

Routing Tables
Routing for Network

10.2.1.0/24 22 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.3.1.0/24 10 Transit 10.3.1.2 10.3.1.1 0.0.0.2
10.4.1.0/24 25 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.5.1.0/24 10 Stub 10.5.1.1 10.5.1.1 0.0.0.2
10.1.1.0/24 12 Inter 10.3.1.1 10.3.1.1 0.0.0.2
Total Nets: 5
# Ping 10.4.1.1 to check connectivity.
[RouterD] ping 10.4.1.1

Request time out

20.00% packet loss

Configuring an OSPF Network requirements

Stub Area Figure 290 shows an AS is split into three areas, where all routers run OSPF.
RouterA and RouterB act as ABRs to forward routing information between areas.
RouterD acts as the ASBR, redistributing routes (static routes).
It is required to configure Area1 as a Stub area, reducing LSAs to this area without
route reachability interference.
Network diagram
Figure 290 OSPF Stub area configuration

Eth1/0
10.1.1.1 /24
Eth1/0
S2 /1 10 .1 .1.2/24 Eth1/1
10 .2.1.1/24 10.3.1.1 /24
Eth1/0 Eth1/0
Area 1 Area 2 10.3.1.2/24
10.2.1.2 /24
Stub
ASBR
Eth1/1 Eth1/0
10.4.1.1/24 10 .5.1.1/24
Router C Router D
2 Configure OSPF basic functions (in the previous example)
3 Configure RouterD to redistribute static routes
[RouterD] ip route-static 3.1.3.1 24 Ethernet 1/2 9.1.1.1
[RouterD] ospf
[RouterD-ospf-1] import-route static
# Display ABR/ASBR information on RouterC
[RouterC] display ospf abr-asbr

Routing Table to ABR and ASBR
Type Destination Area Cost Nexthop RtType

Intra 10.2.1.1 0.0.0.1 3 10.2.1.1 ABR
Inter 10.3.1.1 0.0.0.1 5 10.2.1.1 ASBR
Inter 10.5.1.1 0.0.0.1 7 10.2.1.1 ASBR
# Display OSPF routing table information on RouterC
[RouterC] display ospf routing

Routing Tables
Routing for Network

10.2.1.0/24 3 Transit 10.2.1.2 10.2.1.1 0.0.0.1
10.3.1.0/24 7 Inter 10.2.1.1 10.2.1.1 0.0.0.1

10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1

10.5.1.0/24 17 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.1.1.0/24 5 Inter 10.2.1.1 10.2.1.1 0.0.0.1
Routing for ASEs

Destination Cost Type Tag NextHop AdvRouter
3.1.3.0/24 1 Type2 1 10.2.1.1 10.5.1.1
Total Nets: 6
n In the above output, since RouterC resides in a normal OSPF area, its routing table
contains an external route.
4 Configure Area1 as a Stub area
# Configure RouterA
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub
# Configure RouterC
[RouterC] ospf
[RouterC-ospf-1] stub-router
[RouterC-ospf-1-area-0.0.0.1] stub
# Display routing table information on RouterC

Routing Tables
Routing for Network

0.0.0.0/0 65536 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.2.1.0/24 65535 Transit 10.2.1.2 10.2.1.1 0.0.0.1
10.3.1.0/24 65539 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1
10.5.1.0/24 65549 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.1.1.0/24 65537 Inter 10.2.1.1 10.2.1.1 0.0.0.1
Total Nets: 6
n After the area where RouterC resides is configured as a Stub area, a default route
takes the place of the external route.
# Configure to filter type3 LSAs for the Stub area
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub no-summary

# Display OSPF routing table information on RouterC

Routing Tables
Routing for Network

0.0.0.0/0 65536 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.2.1.0/24 65535 Transit 10.2.1.2 10.4.1.1 0.0.0.1
10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1
Total Nets: 3
n After this configuration, routing table entries on the stub router are further
reduced, containing only one default external route.
Configuring an OSPF Network requirements

NSSA Area Figure 291 shows an AS is split into three areas, where all routers run OSPF.
RouterA and RouterB act as ABRs to forward routing information between areas.
It is required to configure Area1 as an NSSA area, RouterC as an ASBR to

redistribute static routes into the AS.
Network diagram
Figure 291 OSPF NSSA area configuration network diagram

Eth1/0
10.1.1.1 /24
Eth1/0
10 .1 .1.2/24 Eth1/1
Eth1/1
10.2.1 .1/24 10.3.1.1 /24
Area 1 Eth1 /0 Eth1/0

NSSA Area 2 10.3.1.2/24
10 .2 .1.2/24
ASBR ASBR
Eth1/0
Eth1/1
Router C 10 .4.1.1/24 10 .5.1.1/24 Router D
1 Configure IP addresses for interfaces (omitted).
2 Configuring OSPF basic functions (refer to “Configuring OSPF Basic Functions” on
page 939).
3 Configure Area1 as NSSA area.
# Configure RouterA
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary

# Configure RouterC
[RouterC] ospf
[RouterC-ospf-1-area-0.0.0.1] nssa
n It is recommended to configure the nssa command with the keyword

default-route-advertise no-summary on Router A (an ABR) to reduce the
routing table size on NSSA routers. On other NSSA routers, using the nssa
command is ok.
# Display routing information on RouterC

Routing Tables
Routing for Network

0.0.0.0/0 4 Inter 10.2.1.1 10.2.1.1 0.0.0.1
10.2.1.0/24 3 Transit 10.2.1.2 10.2.1.1 0.0.0.1
10.4.1.0/24 3 Stub 10.4.1.1 10.4.1.1 0.0.0.1
Total Nets: 3
4 Configure RouterC to redistribute static routes

[RouterC] ip route-static 3.1.3.1 24 Ethernet 1/2 11.1.1.1
[RouterC] ospf
[RouterC-ospf-1] import-route static
# Display routing table information on RouterD
[RouterD] display ospf routing

Routing Tables
Routing for Network

10.2.1.0/24 22 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.3.1.0/24 10 Transit 10.3.1.2 10.3.1.1 0.0.0.2
10.4.1.0/24 25 Inter 10.3.1.1 10.3.1.1 0.0.0.2
10.5.1.0/24 10 Stub 10.5.1.1 10.5.1.1 0.0.0.2
10.1.1.0/24 12 Inter 10.3.1.1 10.3.1.1 0.0.0.2
Routing for ASEs

3.1.3.0/24 1 Type2 1 10.3.1.1 10.2.1.1
Total Nets: 6
n You can see on RouterD an external route imported from the NSSA area.

Configuring OSPF DR Network requirements

Election In Figure 292:
■ Router A, B, C and D are on the same network, running OSPF.
■ Configure Router A as the DR, C as the BDR.
Network diagram
Figure 292 OSPF DR election configuration network diagram
Router A Router B
Eth1/0 Eth1/0
192.168 .1.1/24 192.168.1.2/24
Eth1/0 Eth1/0
192 .1 68.1.3 /24 192 .1 68.1.4 /24
Router C Router D
# Configure RouterA
[RouterA] router id 1.1.1.1
[RouterA] ospf
# Configure RouterB
[RouterB] router id 2.2.2.2
[RouterB] ospf
# Configure RouterC
[RouterC] router id 3.3.3.3
[RouterC] ospf

# Configure RouterD
[RouterD] router id 4.4.4.4
[RouterD] ospf
[RouterD-ospf-1] area 0
# Display neighbor information on RouterA
[RouterA] display ospf peer

Neighbors

State: 2-Way Mode: None Priority: 1
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
RouterD becomes the DR, and RouterC becomes the BDR.
3 Configure router priorities on interfaces
# Configure RouterA

[RouterA-Ethernet1/0] ospf dr-priority 100
# Configure RouterB

[RouterB-Ethernet1/0] ospf dr-priority 0
# Configure RouterC

[RouterC-Ethernet1/0] ospf dr-priority 2

# Display information about neighbors on RouterD.
[RouterD] display ospf peer

Neighbors

State: Full Mode:Nbr is Slave Priority: 100
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
The DR and BDR have no change.
n In the above output, you can find the priority configuration does not take effect
immediately.
4 Restart the OSPF process (omitted)
# Display neighbor information on RouterD
[RouterD] display ospf peer

Neighbors
Area 0.0.0.0 interface 192.168.1.4(Ethernet0/1/0)’s neighbors

State: Full Mode: Nbr is Slave Priority: 100
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
State: 2-Way Mode: None Priority: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

State: Full Mode: Nbr is Slave Priority: 2
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0


RouterA becomes the DR, Router C the BDR.
n The full neighbor state means Router D has established the adjacency with the
router. The 2-way neighbor state means the two routers are neither the DR nor
the BDR, and they do not exchange LSAs.
# Display interface information
[RouterA] display ospf interface

Interfaces
Area: 0.0.0.0
IP Address type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 100 192.168.1.1 192.168.1.3
[RouterB] display ospf interface

Interfaces
Area: 0.0.0.0
IP Address type State Cost Pri DR BDR
192.168.1.2 Broadcast DROther 1 0 192.168.1.1 192.168.1.3
n The interface state DROther means the interface is not the DR/BDR.
Configuring OSPF Network requirements

Virtual links In Figure 293, Area 2 has no direct connection to Area 0, the backbone, and Area
1 acts as the Transit Area to connect Area 2 to Area 0 via a virtual link between
RouterA and RouterB.
After configuration, RouterA can learn routes to Area 2.
Network diagram
Figure 293 Network diagram for OSPF virtual link configuration

S2/0 S2 /0
192.168 .1.1/24 192 .168 .1 .2/24
Virtual Link Eth1/0

Eth1/0
10 .1.1.1/8 172.16.1.1/16
Area 0 Area 2
# Configure RouterA

[RouterA] ospf 1 router-id 1.1.1.1
# Configure RouterB
[RouterB] ospf 1 router-id 2.2.2.2
# Display OSPF routing information on RouterA.
[RouterA] display ospf routing

Routing Tables
Routing for Network

Destination Cost type NextHop AdvRouter Area
10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1562 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 2
n Since Area 2 has no direct connection to Area 0, the OSPF routing table of Router
A has no route to Area 2.
3 Configure a virtual link
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[RouterB] ospf 1
[RouterB-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1
# Display OSPF routing information on Router A

Routing Tables

Routing for Network

Destination Cost type NextHop AdvRouter Area
172.16.1.1/16 1563 Inter 192.168.1.2 2.2.2.2 0.0.0.0
10.0.0.0/8 1 Stub 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1562 Stub 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 3
Router A has learned the destination 172.16.1.1/16 in Area 2.
Configuring OSPF Network requirements

Graceful Restart ■ Router A, Router B and Router C that belong to the same autonomous system
and the same OSPF routing domain are GR capable.
■ Router A acts as the non IETF standard GR Restarter, and Router B and Router
C are the GR Helpers and remain OOB synchronized with Router A through the
GR mechanism.
Network diagram
Figure 294 Network diagram for OSPF-based GR configuration (on routers)
Router ID: 1.1.1.1

GR restarter
Router A
Eth1/0
192 .1 .1.1/24
Eth1/0 Eth1/0
192.1.1.2 /24 192 .1.1.3/24
Router B Router C
GR helper GR helper
Router ID: 2.2.2.2 Router ID: 3.3.3.3
Configuration Procedure
[RouterA] router id 1.1.1.1
[RouterA] ospf 100
[RouterA-ospf-100] enable link-local-signaling
[RouterA-ospf-100] enable out-of-band-resynchronization
[RouterA-ospf-100] graceful-restart
[RouterA-ospf-100-area-0.0.0.0] return
[RouterB-acl-basic-2000] rule 10 permit source 192.1.1.1 0.0.0.0
[RouterB-acl-basic-2000] quit


[RouterB-Ethernet1/0] ospf dr-priority 0
[RouterB] router id 2.2.2.2
[RouterB] ospf 100
[RouterB-ospf-100] graceful-restart help 2000
[RouterC] acl number 2000
[RouterC-acl-basic-2000] rule 10 permit source 192.1.1.1 0.0.0.0
[RouterC-acl-basic-2000] quit
[RouterC-Ethernet1/0] ospf dr-priority 2
[RouterC] router id 3.3.3.3
[RouterC] ospf 100
[RouterC-ospf-100] graceful-restart help 2000
4 Verify the configuration.
# Perform OSPF Graceful Restart on Router A if all routers function properly after
the above configurations.
<RouterA> reset ospf 100 process graceful-restart
Troubleshooting OSPF
Configuration
No OSPF Neighbor Symptom

Relationship Established No OSPF neighbor relationship can be established.
Analysis
If the physical link and lower layer protocols work well, check OSPF parameters
configured on interfaces. Two neighbors must have the same parameters, such as
the area ID, network segment and mask (a P2P or virtual link may have different
network segments and masks), network type. If the network type is broadcast or
NBMA, at least one interface must have a router priority higher than 0.
Solution
1 Display OSPF neighbor information using the display ospf peer command.
2 Display OSPF interface information using the display ospf interface command.
3 Ping the neighbor router’s IP address to check connectivity.
4 Check OSPF timers. The dead interval on an interface must be at least four times
the hello interval.

Troubleshooting OSPF Configuration 969
5 On an NBMA network, using the peer ip-address command to specify the

neighbor manually is required.
6 On an NBMA or a broadcast network, at least one connected interface must have
a router priority higher than 0.
Incorrect Routing Symptom

Information OSPF cannot find routes to other areas.
Analysis
The backbone area must maintain connectivity to all other areas. If a router
connects to more than one area, at least one area must be connected to the
backbone. The backbone cannot be configured as a Stub area.
In a Stub area, all routers cannot receive external routes, and all interfaces
connected to the Stub area must be associated with the Stub area.
Solution
1 Use the display ospf peer command to display neighbors.
2 Use the display ospf interface command to display OSPF interface information.
3 Use the display ospf lsdb command to display the Link State Database to check
its integrity.
4 Display information about area configuration using the display
current-configuration configuration ospf command. If more than two areas
are configured, at least one area is connected to the backbone.
5 In a Stub area, all routers are configured with the stub command. In an NSSA
area, all interfaces are configured with the nssa command.
6 If a virtual link is configured, use the display ospf vlink command to check the
state of the virtual link.


RIP CONFIGURATION
59
When configuring RIP, go to these sections for information you are interested in:
■ “RIP Overview” on page 971
■ “Configuring RIP Basic Functions” on page 976
■ “Configuring RIP Advanced Functions” on page 978
■ “Optimizing the RIP Network” on page 981
■ “Displaying and Maintaining RIP Configuration” on page 986
■ “RIP Configuration Example” on page 986
■ “Troubleshooting RIP Configuration” on page 990
RIP Overview RIP is a simple Interior Gateway Protocol (IGP), mainly used in small-sized
networks, such as academic networks and simple structured LANs. RIP is not
applicable to complex networks.
RIP is still widely used in practical networking due to easier implementation,

configuration and maintenance than OSPF and IS-IS.
RIP Working Mechanism Basic concept of RIP

RIP is a Distance-Vector (D-V)-based routing protocol, using UDP packets for
exchanging information through port 520.
RIP uses a hop count to measure the distance to a destination. The hop count is
known as metric. The hop count from a router to its directly connected network is
0. The hop count of a network reachable through one router is 1. To limit
convergence time, the range of RIP metric value is from 0 to 15. A metric value of
16 (or bigger) is considered infinite, which means the destination network is
unreachable. That is why RIP is not suitable for large-scaled networks.
RIP prevents routing loops by implementing the split horizon and poison reverse
functions.
RIP routing table

Each RIP router has a routing table containing routing entries of all reachable
destinations, and each routing entry contains:
■ Destination address: IP address of a host or a network.
■ Next hop: IP address of the adjacent router’s interface to reach the destination.
■ Egress interface: Interface through which the router forwards the packets to
the destination.
■ Metric: Cost from the local router to the destination.

972 CHAPTER 59: RIP CONFIGURATION
■ Route time: Time elapsed since the routing entry was last updated. The time is
reset to 0 every time the routing entry is updated.
■ Route tag: Identifies a route, used in routing policy to flexibly control routes.
For information about routing policy, refer to “Routing Policy Configuration”
on page 991.
RIP timers
RIP employs four timers, Update, Timeout, Suppress, and Garbage-Collect.
■ The update timer defines the interval between routing updates.
■ The timeout timer defines the route aging time. If no update for a route is
received after the aging time elapses, the metric of the route is set to 16 in the
routing table.
■ The suppress timer defines how long a RIP route stays in the suppressed state.
When the metric of a route is 16, the route enters the suppressed state. In the
suppressed state, only routes which come from the same neighbor and whose
metric is less than 16 will be received by the router to replace unreachable
routes.
■ The garbage-collect timer defines the interval from when the metric of a route
becomes 16 to when it is deleted from the routing table. During the
Garbage-Collect timer length, RIP advertises the route with the routing metric
set to 16. If no update is announced for that route after the Garbage-Collect
timer expires, the route will be deleted from the routing table.
Routing loops prevention

RIP is a distance-vector (D-V) based routing protocol. Since a RIP router advertises
its own routing table to neighbors, routing loops may occur.
RIP uses the following mechanisms to prevent routing loops.
■ Counting to infinity. The metric value of 16 is defined as unreachable. When a

routing loop occurs, the metric value of the route will increment to 16.
■ Split horizon. A router does not send the routing information learned from a
neighbor to the neighbor to prevent routing loops and save the bandwidth.
■ Poison reverse. A router sets the metric of routes received from a neighbor to
16 and sends back these routes to the neighbor to help delete useless
information from the neighbor’s routing table.
■ Triggered updates. A router advertises updates once the metric of a route is
changed rather than after the update period expires to speed up the network
convergence.
Operation of RIP The following procedure describes how RIP works.

1 After RIP is enabled, the router sends Request messages to neighboring routers.
Neighboring routers return Response messages including information about their
routing tables.
2 After receiving such information, the router updates its local routing table, and
sends triggered update messages to its neighbors. All routers on the network do
the same to keep the latest routing information.
3 By default, a RIP router sends its routing table to neighbors every 30 seconds.

RIP Overview 973
4 RIP ages out routes by adopting an aging mechanism to keep only valid routes.
RIP Version RIP has two versions, RIP-1 and RIP-2.
RIP-1, a Classful Routing Protocol, supports message advertisement via broadcast

only. RIP-1 protocol messages do not carry mask information, which means it can
only recognize routing information of natural networks such as Class A, B, C. That
is why RIP-1 does not support discontiguous subnet.
RIP-2 is a Classless Routing Protocol. Compared with RIP-1, RIP-2 has the following
advantages.
■ Supporting route tags. The route tag is used in routing policies to flexibly
control routes.
■ Supporting masks, route summarization and classless inter-domain routing
(CIDR).
■ Supporting designated next hop to select the best next hop on broadcast
networks.
■ Supporting multicast routing update to reduce resource consumption.
■ Supporting Plain text authentication and MD5 authentication to enhance
security.
n ■ RIP-2 has two types of message transmission: broadcast and multicast.

Multicast is the default type using 224.0.0.9 as the multicast address. The
interface working in the RIP-2 broadcast mode can also receive RIP-1 messages.
■ On a ComwareV5 device, you can configure the RIP version in RIP view and in
interface view. On a ComwareV3 device, you can only perform such
configuration in interface view.
■ To enable a ComwareV5 device in the RIP-1 mode to interoperate with a
ComwareV3 device in the RIP-2 broadcast mode, you need to use the undo
version command in RIP view and the undo rip version in interface view to
remove related RIP version configuration from the ComwareV5 device.
■ For a ComwareV5 device, the case that no RIP version is configured is different
from the case that RIP-1 is configured. The former one uses the default RIP-1
version that is compatible with RIP-2, but the latter one is not compatible with
RIP-2.
RIP Message Format RIP-1 message format

A RIP message consists of the Header and up to 25 route entries.
Figure 295 shows the format of RIP-1 message.

Figure 295 RIP-1 Message Format
0 7 15 31
Header Command Version Must be zero
AFI Must be zero
IP address
Route
Entries Must be zero
Must be zero
Metric
■ Command: The type of message. 1 indicates Request, 2 indicates Response.

■ Version: The version of RIP, 0x01 for RIP-1.
■ AFI: Address Family Identifier, 2 for IP.
■ IP Address: Destination IP address of the route; can be a natural network,
subnet or a host address.
■ Metric: Cost of the route.
RIP-2 message format

The format of RIP-2 message is similar with RIP-1. Figure 296 shows it.
Figure 296 RIP-2 Message Format
0 7 15 31
Header Command Version Unused
AFI Route tag
IP address
Route
Entries Subnet mask
Next hop
Metric
The differences from RIP-1 are stated as following.
■ Version: Version of RIP. For RIP-2 the value is 0x02.

■ Route Tag: Route Tag.
■ IP Address: Destination IP address. It could be a natural network address,
subnet address or host address.
■ Subnet Mask: Mask of the destination address.
■ Next Hop: If set to 0.0.0.0, it indicates that the originator of the route is the
best next hop; Otherwise it indicates a next hop better that the originator of
the route.
RIP-2 authentication
RIP-2 sets the AFI field of the first route entry to 0xFFFF to identify authentication
information. See Figure 297.

RIP Overview 975
Figure 297 RIP-2 Authentication Message
0 7 15 31
Command Version Unused
0xFFFF Authentication type
Authentication (16 octets)
■ Authentication Type: 2 represents plain text authentication, while 3 represents

MD5.
■ Authentication: Authentication data, including password information when
plain text authentication is adopted or including key ID, MD5 authentication
data length and sequence number when MD5 authentication is adopted.
n ■ RFC 1723 only defines plain text authentication. For information about MD5
authentication, refer to RFC2082 “RIP-2 MD5 Authentication”.
■ With RIPv1, you can configure the authentication mode in interface view.
However, the configuration will not take effect because RIPv1 does not support
authentication.
TRIP Triggered RIP (TRIP), a RIP extension on WAN, is mainly used in dial-up network.
Working mechanism
Routing information is sent in triggered updates rather than periodic broadcasts to
reduce the routing management cost the WAN.
■ Only when data in the routing table changes or the next hop is unreachable, a
routing update message is sent.
■ Since the periodic update delivery is canceled, an acknowledgement and
retransmission mechanism is required to guarantee successful updates
transmission on WAN.
Message types
RIP use three new types of message which are identified by the value of the
Command filed.
■ Update Request (type value 9): Requests needed routes from the peer.
■ Update Response (type value 10): Contains the routes requested by the peer.
■ Update Acknowledge (type value 11): Acknowledges received Update
Response messages.
TRIP retransmission mechanism

■ If receiving no Update Responses after sending an Update Request, a router
sends the request again after a specified interval. If still receiving no Update
Response after the upper limit for sending requests is reached, the router
considers the neighbor unreachable.
■ If receiving no Update Acknowledge after sending an Update Response, a
router sends the Update Response again after a specified interval. If still

receiving no Update Acknowledge after the upper limit for sending Update
Responses is reached, the router considers the neighbor unreachable.
RIP Features Supported The current implementation supports the following RIP features.
■ RIP-1 and RIP-2
■ RIP Multi-instance. This means that RIP can serve as an internal VPN routing
protocol, running between CE and PE on the BGP/MPLS VPN network. For
related information, refer to “BGP Configuration” on page 825 and “MPLS
Basics Configuration” on page 1311.
■ TRIP
Protocols and Standards ■ RFC 1058: Routing Information Protocol

■ RFC 1723: RIP Version 2 - Carrying Additional Information
■ RFC 1721: RIP Version 2 Protocol Analysis
■ RFC 1722: RIP Version 2 Protocol Applicability Statement
■ RFC 1724: RIP Version 2 MIB Extension
■ RFC 2082: RIP-2 MD5 Authentication
■ RFC 2091: Triggered Extensions to RIP to Support Demand Circuits
Configuring RIP Basic

Functions
Configuration Before configuring RIP features, finish the following tasks.

Prerequisites ■ Configure the link layer protocol.
■ Configure IP address on each interface, and make sure all adjacent routers are
reachable with each other.
Configuration Procedure Enable RIP and specify networks to run RIP

Follow these steps to enable RIP and specify networks to run RIP

Enable a RIP process and enter rip [ process-id ] Required
RIP view [ vpn-instance
Disabled by default
vpn-instance-name ]
Enable RIP on the network of network network-address Required
an interface
Disabled by default
n ■ If you make some RIP configurations in interface view before enabling RIP,
those configurations will take effect after RIP is enabled.
■ RIP runs only on the interfaces residing on the specified networks. Therefore,
you need specify the network after enabling RIP to validate RIP on a specific
interface.
■ You can enable RIP on all interfaces using the command network 0.0.0.0.

Configuring RIP Basic Functions 977
Configure the interface behavior

Follow these steps to configure the interface behavior:

Enter RIP view rip [ process-id ] --
[ vpn-instance
vpn-instance-name ]
Disable an or all interfaces silent-interface { all | Optional
from sending routing updates interface-type
All interfaces can send routing
(the interfaces can still receive interface-number }
updates by default
updates)
interface-number
Enable the interface to receive rip input Optional
RIP messages
Enabled by default
Enable the interface to send rip output Optional
RIP messages
Enabled by default
Configure a RIP version

You can configure a RIP version in RIP or interface view.
■ If neither global nor interface RIP version is configured, the interface sends
RIP-1 broadcasts and can receive RIP-1 broadcast and unicast packets, RIP-2
broadcast, multicast, and unicast packets.
■ If an interface has no RIP version configured, it uses the global RIP version;
otherwise it uses the RIP version configured on it.
■ With RIP-1 configured, an interface sends RIP-1 broadcasts, and can receive
RIP-1 broadcasts and RIP-1 unicasts.
■ With RIP-2 configured, a multicast interface sends RIP-2 multicasts and can
receive RIP-2 unicasts, broadcasts and multicasts.
■ With RIP-2 configured, a broadcast interface sends RIP-2 broadcasts and can
receive RIP-1 unicasts, and broadcasts, RIP-2 broadcasts, multicasts and
unicasts.
Follow these steps to configure a RIP version:

[ vpn-instance
vpn-instance-name ]


Specify a global RIP version { 1 | 2 } Optional;
version
RIP-1 by default;
If an interface has a RIP version
specified, the version takes
precedence over the global one. If no
RIP version is specified for an interface,
the interface can send RIP-1
broadcasts, and receive RIP-1
broadcasts, unicasts, RIP-2 broadcasts,
multicasts and unicasts.
interface-number
Specify a RIP version rip version { 1 | 2 Optional
[ broadcast | multicast ] }
Configuring RIP In some complex network environments, you need to configure advanced RIP
Advanced Functions functions.
This section covers the following topics:
■ “Configuring an Additional Routing Metric” on page 978

■ “Configuring RIP-2 Route Summarization” on page 979
■ “Disabling Host Route Reception” on page 980
■ “Advertising a Default Route” on page 980
■ “Configuring Inbound/Outbound Route Filtering Policies” on page 980
■ “Configuring a Priority for RIP” on page 981
■ “Configuring RIP Route Redistribution” on page 981
Before configuring RIP routing feature, finish the following tasks:
■ Configure an IP address for each interface, and make sure all routers are
reachable.
■ Configure basic RIP functions
Configuring an An additional routing metric can be added to the metric of a RIP route, namely,
Additional Routing the inbound and outbound additional metric.
Metric
The outbound additional metric is added to the metric of a sent route, the route’s
metric in the routing table is not changed.
The inbound additional metric is added to the metric of a received route before
the route is added into the routing table, so the route’s metric is changed.
Follow these steps to configure additional routing metric:


Configuring RIP Advanced Functions 979

interface-number
Define an inbound additional rip metricin value Optional
routing metric
0 by default
Define an outbound additional rip metricout value Optional
routing metric
1 by default
Configuring RIP-2 Route The route summarization means that subnet routes in a natural network are
Summarization summarized with a natural network that is sent to other networks. This function
can reduce the size of routing tables.
Configure RIP-2 route automatic summarization

Disable RIP-2 route automatic summarization if you want to advertise all subnet
routes.
Follow these steps to configure route automatic summarization:

[ vpn-instance
vpn-instance-name ]
Enable RIP-2 automatic route summary Optional
summarization
Enabled by default
Advertise a summary route

You can configure RIP-2 to advertise a summary route on the specified interface.

Enter RIP view rip [ process-id ] [ vpn-instance --
vpn-instance-name ]
Disable RIP-2 automatic route undo summary Required
summarization
Enabled by default
interface-number
Configure to advertise a rip summary-address ip-address Required
summary route { mask | mask-length }
n You need disable RIP-2 route automatic summarization before advertising a

summary route on an interface.

Disabling Host Route Sometimes a router may receive many host routes from the same network, which
Reception are not helpful for routing and occupy a large amount of network resources. In
this case, you can disable RIP from receiving host routes to save network resources.
Follow these steps to disable RIP from receiving host routes:

Enter RIP view rip [ process-id ] -
[ vpn-instance
vpn-instance-name ]
Disable RIP from receiving undo host-route Required
host routes
Enabled by default
n RIPv2 can be disabled from receiving host routes, but RIPv1 cannot.
Advertising a Default You can configure RIP to advertise a default route with the specified metric to RIP
Route neighbors.
Follow these steps to configure RIP to advertise a default route:

[ vpn-instance
vpn-instance-name ]
Enable RIP to advertise a default-route originate Required
default route cost value
n The router enabled to advertise a default route does not receive default routes
from RIP neighbors.
Configuring Route filtering is supported by the router. You can filter routes by configuring the
Inbound/Outbound inbound and outbound route filtering policies via referencing an ACL and IP prefix
Route Filtering Policies list. You can also specify to receive only routes from a specified neighbor.
Follow these steps to configure a routing policy:

Define a filtering policy filter-policy { acl-number | gateway Required
for incoming routes ip-prefix-name | ip-prefix ip-prefix-name
By default, no inbound
[ gateway ip-prefix-name ] } import
filtering is configured by
[ interface-type interface-number ]
default.


Define a filtering policy filter-policy { acl-number | ip-prefix Required
for outgoing routes ip-prefix-name } export [ protocol
No outbound filtering is
[ process-id ] | interface-type
configured by default.
interface-number ]
n ■ Using the filter-policy import command filters incoming routes. Routes not
passing the filtering will be neither installed into the routing table nor
advertised to neighbors.
■ Using the filter-policy export command filters outgoing routes, including
routes redistributed with the import-route command.
Configuring a Priority Multiple IGP protocols may run in a router. If you want RIP routes to have a higher
for RIP priority than those learned from other routing protocols, you should assign RIP a
smaller priority value to influence optimal route selection.
Follow these steps to configure a priority for RIP:

vpn-instance-name ]
Configure a priority for RIP preference [ route-policy Optional
route-policy-name ] value
100 by default
Configuring RIP Route Follow these steps to configure RIP route redistribution:
Redistribution
[ vpn-instance
vpn-instance-name ]
Configure a default metric for default-cost value Optional
redistributed routes
The default metric of a
redistributed route is 0 by
default.
Redistribute routes from other import-route protocol Required
protocols or processes [ process-id ] [ allow-ibgp ]
By default, RIP does not
[ cost cost | route-policy
redistribute any other
route-policy-name | tag tag ]
protocol route.
*
Optimizing the RIP This section covers the following topics:

Network ■ “Configuring RIP Timers” on page 982
■ “Configuring the Split Horizon and Poison Reverse” on page 982
■ “Configuring the Maximum Number of Load Balanced Routes” on page 983
■ “Enabling CheckZero Field Check on RIPv1 Messages” on page 983
■ “Enabling Source IP Address Check on Incoming RIP Updates” on page 984

■ “Configuring RIP-2 Message Authentication” on page 984

■ “Configuring a RIP Neighbor” on page 984
■ “Configuring TRIP” on page 985
■ “Configuring RIP-to-MIB Binding” on page 986
Finish the following tasks before configuring the RIP network optimization.
■ Configure network addresses on interfaces, and make sure neighboring nodes

are reachable
■ Configure basic RIP functions.
Configuring RIP Timers Follow these steps to configure RIP timers:

vpn-instance-name ]
Configure values for RIP timers { garbage-collect Optional
timers garbage-collect-value | suppress
By default, 30s for update timer,
suppress-value | timeout
180s for timeout timer, 120s for
timeout-value | update
suppress timer, and 120s for
update-value }*
garbage-collect timer
n Based on the network performance, you should make RIP timers of RIP routers
identical to each other to avoid unnecessary traffic or route oscillation.
Configuring the Split

Horizon and Poison
Reverse
n If both the split horizon and poison reverse are configured, only the poison reverse
function takes effect.
Configure split horizon

The split horizon function disables an interface from sending routes received by
the interface itself, so as to prevent routing loops between adjacent routers.
Follow these steps to configure the split horizon function:

interface-number
Enable split horizon rip split-horizon Optional
Enabled by default
n ■ In Frame Relay, X.25 and other non-broadcast multi-access (NBMA) networks,

split horizon should be disabled if multiple VCs are configured on the primary
interface and secondary interfaces to ensure route advertisement. For detailed

information, refer to “Frame Relay Configuration” on page 235 and “X.25 and
LAPB Configuration” on page 283.
■ Disabling the split horizon function on a point-to-point link does not take
effect.
Configure the poison reverse

The poison reverse function allows an interface to advertise the routes received by
itself, but the metric of these routes is set to 16, making them unreachable.
Follow these steps to configure the poise reserve function:

interface-number
Enable the poison reverse rip poison-reverse Required
function
Disabled by default
Configuring the Follow these steps to configure the maximum number of load balanced routes:
Maximum Number of
Load Balanced Routes To do... Use the command... Remarks
vpn-instance-name ]
Configure the maximum number of maximum load-balancing number Optional
load balanced routes
Enabling CheckZero Some fields in the RIP-1 message must be zero. These fields are called zero fields.
Field Check on RIPv1 You can enable the zero field check on received RIP-1 messages. If any such field
Messages contains a non-zero value, the RIP-1 message will not be processed. If you are sure
that all messages are trusty, you can disable the zero field check to save the CPU
processing time.
In addition, you can enable the source IP address validation on received messages.
For the message received on an Ethernet interface, RIP compares the source IP
address of the message with the IP address of the interface. If they are not in the
same network segment, RIP discards the message. For a message received on a
serial interface, RIP checks whether the source address of the message is the IP
address of the peer interface. If not, RIP discards the message.
Follow these steps to enable zero field check on RIPv1 messages:

vpn-instance-name ]
Enable the zero field check on checkzero Optional
received RIP-1 messages
Enabled by default

Enabling Source IP You can enable source IP address check on incoming RIP updates.
Address Check on ■ For a message received on an Ethernet interface, RIP compares the source IP
Incoming RIP Updates address of the message with the IP address of the interface. If they are not in
the same network segment, RIP discards the message.
■ For a message received on a serial interface, RIP checks whether the source
address of the message is the IP address of the peer interface. If not, RIP
discards the message.
Follow these steps to enable source IP address check on incoming RIP updates:

[ vpn-instance
vpn-instance-name ]
Enable source IP address validate-source-address Optional
check on incoming RIP
Enabled by default
messages
n The source IP address check feature should be disabled if the RIP neighbor is not
directly connected.
Configuring RIP-2 RIP-2 supports two authentication modes: plain text and MD5.
Message Authentication
In plain text authentication, the authentication information is sent with the RIP
message, which cannot meet high security needs.
Follow these steps to configure RIP-2 message authentication:

interface-number
Configure RIP-2 rip authentication-mode { md5 Required
authentication mode { rfc2082 key-string key-id | rfc2453
key-string } | simple password }
Configuring a RIP Usually, RIP sends messages to broadcast or multicast addresses. On non broadcast
Neighbor or multicast links, you need to manually specify a RIP neighbor. If the specified
neighbor is not directly connected, you must disable the source address check on
update messages.
Follow these steps to configure a RIP neighbor:

vpn-instance-name ]
Specify a RIP neighbor peer ip-address Required


Disable source address check undo validate-source-address Required
on received RIP update
messages
n You need not use the peer ip-address command when the neighbor is directly
connected; otherwise the neighbor may receive both the unicast and multicast (or
broadcast) of the same routing information.
Configuring TRIP In a connection oriented network, a router may establish connections to multiple
remote devices. In a WAN, links are created and removed as needed. In such
applications, a link created between two nodes for data transmission is temporary
and infrequently.
TRIP should be enabled when it is necessary to exchange routing information via

on-demand links or triggered RIP.
Enable TRIP
Follow these steps to enable TRIP:

Enable RIP rip [ process-id ] Required
[ vpn-instance
vpn-instance-name ]
interface-number
Enable TRIP rip triggered Required
n If RIP is disabled, TRIP is also disabled.
Configure TRIP retransmission parameters

You can specify intervals and upper limits for Update Request and Response
retransmissions as needed.
For two routers on an analog dial-up link, the difference between retransmission
intervals on the two ends must be bigger than 50 seconds; otherwise, they can
not become TRIP neighbors.
Follow these steps to configure TRIP retransmission parameters:

Enable RIP and enter its view rip [ process-id ] Required
[ vpn-instance
vpn-instance-name ]
Configure the interval for trip retransmit timer Required
retransmitting an Update retransmit-time-value
Request or Update Response


Configure the upper limit for trip retransmit count Optional
retransmitting an Update retransmit-count-value
36 by default
Request or Update Response
The maximum retransmission time (upper limit × interval) for a packet cannot be
n too long lest when its neighbor is down, the router still resends the packet.
Configuring RIP-to-MIB Follow these steps to bind RIP to MIB:

Binding
Bind RIP to MIB rip mib-binding process-id Optional
By default, MIB is bound to the RIP
process with the smallest process ID
Displaying and
Maintaining RIP To do... Use the command... Remarks
Configuration Display RIP current status and display rip [ process-id | vpn-instance Available in any
configuration information vpn-instance-name ] view
Display all active routes in RIP display rip process-id database
database
Display RIP interface display rip process-id interface

information [ interface-type interface-number ]
Display routing information display rip process-id route [ statistics |

about a specified RIP process ip-address { mask | mask-length } | peer
ip-address ]
Clear the statistics of a RIP reset rip process-id statistics Available in user
process view
RIP Configuration
Example
RIP Version Network requirements

Configuration As shown in Figure 298, enable RIP-2 on all interfaces on Router A and Router B.
Network diagram
Figure 298 Network diagram for RIP version configuration
RIP 100 RIP 200

Eth1/1 Eth1/2
2.1.1.1/24 Eth1 /0 Eth1 /1 5.1.1.1 /24
1 .1.1.1/24 3 .1.1.1/24
Eth1/0 Eth1/0 Eth1/1
1.1 .1.2/24 3.1 .1.2/24 Router C 4.1.1 .1/24
Router A Router B

1 Configure an IP address for each interface (Omitted)
2 Configure basic RIP functions
[RouterA] rip
[RouterB] rip
# Display the RIP routing table on Router A.
Route Flags: R - RIP, T - TRIP

P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
--------------------------------------------------------------------------
Peer 1.1.1.2 on Ethernet1/0
Destination/Mask Nexthop Cost Tag Flags Sec
10.0.0.0/8 1.1.1.2 1 0 RA 9
From the routing table, you can see RIP-1 uses natural mask to advertise routing
information.
3 Configure RIP version
# Configure RIP-2 on Router A.
[RouterA] rip
[RouterA-rip-1] version 2
[RouterA-rip-1] undo summary
# Configure RIP-2 on Router B.
[RouterB] rip
[RouterB-rip-1] version 2
[RouterB-rip-1] undo summary
# Display the RIP routing table of Router A.
[RouterA] display rip 1 route

Route Flags: R - RIP, T - TRIP
P - Permanent, A - Aging, S - Suppressed, G - Garbage-collect
--------------------------------------------------------------------------
Peer 1.1.1.2 on Ethernet1/0
Destination/Mask Nexthop Cost Tag Flags Sec
10.0.0.0/8 1.1.1.2 1 0 RA 87
10.1.1.0/24 1.1.1.2 1 0 RA 19
10.2.1.0/24 1.1.1.2 1 0 RA 19
From the routing table, you can see RIP-2 uses classless subnet mask.

n Since RIP-1 routing information has a long aging time, it will still exist before being
aged out after RIP-2 is configured.
Configuring RIP Route Network requirements

Redistribution As shown in Figure 299, two RIP processes are running on Router B, which
communicates with Router A through RIP100 and with Router C through RIP 200.
Configure route redistribution on Router B, letting the two RIP processes

redistribute routes from each other. Set the cost of redistributed routes from RIP
200 to 3. Configure a filtering policy on Router B to filter out the route 4.1.1.1/24
from RIP200, making the route not advertised to Router A.
Network diagram
Figure 299 Network diagram for RIP route redistribution configuration
RIP 100 RIP 200
Eth1/1 Eth1/2
2.1.1.1/24 Eth1 /0 Eth1 /1 5.1.1.1 /24
1 .1.1.1/24 3 .1.1.1/24
1.1 .1.2/24 3.1 .1.2/24 Router C 4.1.1 .1/24
Router A Router B
1 Configure an IP address for each interface (omitted)
2 Configure RIP basic functions
# Enable RIP 100, and configure a RIP version of 2 on Router A.
[RouterA] rip 100
[RouterA-rip-100] version 2
[RouterA-rip-100] undo summary
# Enable RIP 100 and RIP 200, configure RIP version as 2 on Router B.
[RouterB] rip 100
[RouterB] rip 200
# Enable RIP 200 and configure RIP version as 2 on Router C.

[RouterC] rip 200
[RouterC-rip-200] version 2
[RouterC-rip-200] undo summary
# Display the routing table of Router A.
[RouterA] display ip routing-table

1.1.1.0/24 Direct 0 0 1.1.1.1 Eth1/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Eth1/1
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
3 Configure RIP route redistribution
# Configure RIP processes 100 and 200 to redistribute routes from each other on
Router B.
[RouterB] rip 100

[RouterB-rip-100] default cost 3
[RouterB-rip-100] import-route rip 200
[RouterB] rip 200
[RouterB-rip-200] import-route rip 100
# Display the routing table of Router A.

1.1.1.0/24 Direct 0 0 1.1.1.1 Eth1/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Eth1/1
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
4.1.1.0/24 RIP 100 4 1.1.1.2 Eth1/0
5.1.1.0/24 RIP 100 4 1.1.1.2 Eth1/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
4 Configure a filtering policy for redistributed routes
# On Router B, define ACL 2000 and reference it to a filtering policy to filter routes
redistributed from RIP 200.

[RouterB-acl-basic-2000] rule deny source 4.1.1.1 0.0.0.255
[RouterB-acl-basic-2000] rule permit

[RouterB] rip 100

[RouterB-rip-100] filter-policy 2000 export rip 200
# Display the routing table on Router A.

1.1.1.0/24 Direct 0 0 1.1.1.1 Eth1/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
2.1.1.0/24 Direct 0 0 2.1.1.1 Eth1/1
2.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
5.1.1.0/24 RIP 100 4 1.1.1.2 Eth1/0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Troubleshooting RIP
Configuration
No RIP Updates Received Symptom:
No RIP updates are received when the links work well.
Analysis:
After enabling RIP, you must use the network command to enable corresponding
interfaces. Make sure no interfaces are disabled from handling RIP messages.
If the peer is configured to send multicast messages, the same should be

configured on the local end.
Solution:
■ Use the display current-configuration command to check RIP configuration

■ Use the display rip command to check whether some interface is disabled
Route Oscillation Symptom:

Occurred
When all links work well, route oscillation occurs on the RIP network. After
displaying the routing table, you may find some routes appear and disappear in
the routing table intermittently.
Analysis:
In the RIP network, make sure all the same timers within the whole network are
identical and relationships between timers are reasonable. For example, the
timeout timer value should be larger than the update timer value.
Solution:
■ Use the display rip command to check the configuration of RIP timers
■ Use the timers command to adjust timers properly.

ROUTING POLICY CONFIGURATION
60
A routing policy is used on a router for route inspection, filtering, attributes
modifying when routes are received, advertised, or redistributed.
When configuring routing policy, go to these sections for information you are
interested in:
■ “Introduction to Routing Policy” on page 991

■ “Routing Policy Configuration Task List” on page 993
■ “Defining Filtering Lists” on page 993
■ “Configuring a Routing Policy” on page 996
■ “Displaying and Maintaining the Routing Policy” on page 1000
■ “Routing Policy Configuration Example” on page 1000
■ “Troubleshooting Routing Policy Configuration” on page 1005
n Routing policy described in this chapter contains both IPv4 routing policy and IPv6
routing policy. Configurations of the two are similar, and differences are described
in related sections.
Introduction to
Routing Policy
Routing Policy and A routing policy is used on the router for route inspection, filtering, attributes
Policy Routing modifying when routes are received, advertised, or redistributed.
Policy routing is a routing mechanism based on the user-defined policies.
This chapter describes only routing policy configuration and usage, refer to “IP
Unicast Policy Routing Configuration” on page 639 for policy routing information.
When distributing or receiving routing information, a router can apply some policy
to filter routing information. For example, a router handles only routing
information that matches some criteria, or a routing protocol redistributes from
other protocols only routes matching some criteria and modifies some attributes
of these routes to satisfy its needs.
To implement a routing policy, you need define a set of match criteria according to
attributes in routing information, such as destination address, advertising router’s
address and so on. The match criteria can be set beforehand and then apply them
to a routing policy for route distribution, reception and redistribution.

992 CHAPTER 60: ROUTING POLICY CONFIGURATION
Filters Routing protocols can use six filters: ACL, IP prefix list, AS path ACL, community
list, extended community list and routing policy.
ACL
ACL involves IPv4 ACL and IPv6 ACL. When defining an ACL, you can specify IP
addresses and subnets to match destinations or next hops of routing information.
For ACL configuration, refer to “Configuring ACLs” on page 1881.
IP prefix list
IP prefix list involves IPv4 and IPv6 prefix list.
IP prefix list plays a role similar to ACL, but it is more flexible than ACL and easier
to understand. When an IP prefix list is applied to filtering routing information, its
matching object is the destination address of routing information. Moreover, you
can specify the gateway option to indicate that only routing information
advertised by certain routers will be received. For gateway option information,
refer to “RIP Configuration” on page 971 and “OSPF Configuration” on page 917.
An IP prefix list is identified by name. Each IP prefix list can comprise multiple
items, and each item, which is identified by an index number, can specify a
matching range in network prefix format. The index number indicates the
matching sequence of items in the IP prefix list.
The filtering relation among items is logical OR. During matching, the router
compares the packet with the items in the ascending order. If one item is matched,
the IP prefix list filter is passed, and the packet will not go to the next item.
AS-path ACL
AS path ACL is only applicable to BGP. There is an AS-path field in the BGP packet.
An AS path ACL specifies matching conditions according to the AS-path field.
Community list
Community list only applies to BGP. The BGP packet contains a community
attribute field to identify a community. A community list specifies matching
conditions based on the community attribute.
Extended community list

Extended community list (extcommunity-list) applies to BGP only. It involves two
attributes: Route-Target extcommunity for VPN, Source of Origin extcommunity.
An extcommunity-list specifies matching conditions according to the two
attributes.
Routing policy
A routing policy is used to match against some attributes in given routing
information and modify the attributes of the information if match conditions are
satisfied. It can reference the above mentioned filters to define its own match
criteria.
A routing policy can comprise multiple nodes. Each node is a match unit, and the
system compares each node to a packet in ascending order of node sequence
numbers.

Routing Policy Configuration Task List 993
Each node comprises a list of if-match and apply clauses. The if-match clauses
define the match criteria. The matching objects are some attributes of routing
information. The different if-match clauses on a node is in logical AND
relationship. Only when the matching conditions specified by all the if-match
clauses on the node are satisfied, can routing information pass the node. The
apply clauses specify the actions performed after the node is passed, concerning
the attribute settings for routing information.
The filter relation among different route policy nodes is logical OR. Once a node is
matched, the routing policy is passed and the packet will not go through the next
node.
Routing Policy A routing policy is applied in two ways:

Application ■ When redistributing routes from other routing protocols, a routing protocol
accepts only routes passing the routing policy.
■ When receiving or advertising routing information, a routing protocol uses the
routing policy to filter routing information.
Routing Policy To configure a routing policy, perform the tasks described in the following
Configuration Task sections:
List
Task
“Defining Filtering Lists” on page “Defining an IP-prefix List” on page 993
993
“Defining an AS Path ACL” on page 995
“Defining a Community List” on page 995
“Defining an Extended Community List” on page 995
“Configuring a Routing Policy” on “Creating a Routing Policy” on page 996
page 996
“Defining if-match Clauses for the Routing Policy” on
page 996
“Defining apply Clauses for the Routing Policy” on page
998
Defining Filtering Lists
Prerequisites Before configuring this task, you need to decide on:

■ IP-prefix list name
■ Matching address range
■ Extcommunity list sequence number
Defining an IP-prefix List Define an IPv4 prefix list

Identified by name, each IPv4 prefix list can comprise multiple items. Each item
specifies a matching address range in the form of network prefix identified by
index number.
During matching, the system compares the route to each item identified by index
number in the ascending order. If one item matches, the route passes the IP-prefix
list, without needing to match against the next item.

To define an IPv4 prefix list, use the following commands:

Define an IPv4 prefix list ip ip-prefix ip-prefix-name [ index Required
index-number ] { permit | deny } ip-address
Not defined by
mask-length [ greater-equal
default
min-mask-length ] [ less-equal
max-mask-length ]
n If all items are set to the deny mode, no routes can pass the IPv4 prefix list.
Therefore, you need to define the permit 0.0.0.0 0 less-equal 32 item following
multiple deny mode items to allow other IPv4 routing information to pass.
For example, the following configuration filters routes 10.1.0.0/16, 10.2.0.0/16

and 10.3.0.0/16, but allows other routes to pass.
[Sysname] ip ipv6-prefix abc index 10 deny 10.1.0.0 16
[Sysname] ip ipv6-prefix abc index 40 permit 0.0.0.0 0 less-equal 32
Define an IPv6 prefix list

Identified by name, each IPv6 prefix list can comprise multiple items. Each item
specifies a matching address range in the form of network prefix, which is
identified by index number.
During matching, the system compares the route to each item in the ascending
order of index number. If one item is matched, the route passes the IP-prefix list,
without needing to match the next item.
To define an IPv6 prefix list, use the following commands:

Define an IPv6 prefix ip ipv6-prefix ipv6-prefix-name [ index Required
list index-number ] { deny | permit } ipv6-address
Not defined by
prefix-length [ greater-equal min-prefix-length ]
default
[ less-equal max-prefix-length ]
n If all items are set to the deny mode, no routes can pass the IPv6 prefix list.
Therefore, you need to define the permit :: 0 less-equal 128 item following
multiple deny mode items to allow other IPv6 routing information to pass.
For example, the following configuration filters routes 2000:1::/48, 2000:2::/48

and 2000:3::/48, but allows other routes to pass.
[Sysname] ip ip-prefix abc index 10 deny 2000:1:: 48
[Sysname] ip ip-prefix abc index 40 permit :: 0 less-equal 128

Defining Filtering Lists 995
Defining an AS Path ACL You can define multiple items for an AS path ACL that is identified by number.
During matching, the relation between items is logical OR, that is, if the route
matches one of these items, it passes the AS path ACL.
To define an AS path ACL, use the following commands:

Define an AS path ACL ip as-path as-path-number Required
{ deny | permit }
regular-expression
Defining a Community You can define multiple items for a community list that is identified by number.
List During matching, the relation between items is logic OR, that is, if routing
information matches one of these items, it passes the community list.
To define a community list, use the following commands:
Use the
Define a community Define a basic community ip community-list Required to define
list list basic-comm-list-num either;
{ deny | permit }
Not defined by
[ community-number
default
-list ] [ internet |
no-advertise |
no-export |
no-export-subconf
ed ] *
Define an advanced ip community-list
community list adv-comm-list-num
{ deny | permit }
regular-expression
Defining an Extended You can define multiple items for an extended community list that is identified by
Community List number. During matching, the relation between items is logic OR, that is, if
routing information matches one of these items, it passes the extended
community list.
To define an extended community list, use the following commands:

Define an extended ip extcommunity-list Required
community list ext-comm-list-number { deny
| permit } { rt
route-target }&<1-16>

Configuring a Routing A routing policy is used to filter routing information according to some attributes,
Policy and modify some attributes of the routing information that matches the routing
policy. Match criteria can be configured using filters above mentioned.
A routing policy can comprise multiple nodes, each node contains:
■ if-match clauses: Define the match criteria that routing information must
satisfy. The matching objects are some attributes of routing information.
■ apply clauses: Specify the actions performed after specified match criteria are
satisfied, concerning attribute settings for passed routing information.
Prerequisites Before configuring this task, you have completed:

■ Filtering list configuration
■ Routing protocol configuration
You also need to decide on:
■ Name of the routing policy, node sequence numbers

■ Match criteria
■ Attributes to be modified
Creating a Routing To create a routing policy, use the following commands:

Policy
Create a routing policy and route-policy route-policy-name { permit Required
enter its view | deny } node node-number
n ■ If a node has the permit keyword specified, routing information meeting the
node’s conditions will be handled using the apply clauses of this node, without
needing to match against the next node. If routing information does not meet
the node’s conditions, it will go to the next node for a match.
■ If a node has the deny keyword specified, routing information matching all the
if-match clauses of the node can neither pass the node nor go to the next
node. If route information cannot meet any if-match clause of the node, it will
go to the next node for a match.
■ When a routing policy is defined with more than one node, at least one node
should be configured with the permit keyword. If the routing policy is used to
filter routing information, routing information that does not meet any node’s
conditions cannot pass the routing policy. If all nodes of the routing policy are
set using the deny keyword, no routing information can pass it.
Defining if-match To define if-match clauses for a route-policy, use the following command:
Clauses for the Routing
Policy Use the

Use the
Enter routing policy view route-policy Required
route-policy-name
{ permit | deny }
node node-number
Define match criteria Match IPv4 routes having if-match acl Optional
for IPv4 routes destinations specified in acl-number
Not configured by
the ACL
default
Match IPv4 routes having if-match ip-prefix
destinations specified in ip-prefix-name
the IP prefix list
Match IPv4 routes having if-match ip Optional
next hops or sources { next-hop |
Not configured by
specified in the ACL or IP route-source } { acl
default
prefix list acl-number |
ip-prefix
ip-prefix-name }
Match IPv6 routes having the next hop or source if-match ipv6 Optional
specified in the ACL or IP prefix list { address |
Not configured by
next-hop |
default
route-source } { acl
acl-number |
prefix-list
ipv6-prefix-name }
Match routes having AS path attributes specified if-match as-path Optional
in the AS path ACL(s) as-path-acl-number&
Not configured by
<1-16>
default
Match routes having community attributes in the if-match Optional
specified community list(s) community
Not configured by
{ basic-community-lis
default
t-number
[ whole-match ] |
adv-community-list-n
umber }&<1-16>
Match routes having the specified cost if-match cost value Optional
Not configured by
default
Match BGP routes having extended attributes if-match Optional
contained in the extended community list(s) extcommunity
Not configured by
ext-comm-list-numb
default
er&<1-16>
Match routes having specified outbound if-match interface Optional
interface(s) { interface-type
Not configured by
interface-number }&
default
<1-16>
Match routes having MPLS label if-match mpls-label Optional
Not configured by
default

Use the
Match routes having the specified route type if-match Optional
route-type
Not configured by
{ internal |
default
external-type1 |
external-type2 |
external-type1or2 |
is-is-level-1 |
is-is-level-2 |
nssa-external-type
1|
nssa-external-type
2|
nssa-external-type
1or2 } *
Match RIP, OSPF, or IS-IS routes having the if-match tag value Optional
specified tag value
Not configured by
default
n ■ The if-match clauses of a route-policy are in logic AND relationship, namely,

routing information has to satisfy all if-match clauses before being executed
with apply clauses.
■ You can specify no or multiple if-match clauses for a routing policy. If no
if-match clause is specified, and the routing policy is in permit mode, all
routing information can pass the node; if in deny mode, no routing
information can pass.
■ A routing policy should use a non VPN ACL for filtering.
■ The differences between defining if-match clauses for IPv4 and IPv6 routing
policies are commands for matching the destination, next hop and source
address.
Defining apply Clauses To define apply clauses for a route-policy, use the following command:
for the Routing Policy
Create a routing policy and route-policy Required
enter its view route-policy-name { permit |
deny } node node-number
Set AS_Path attribute for BGP apply as-path Optional
routes as-number&<1-10>
Not set by default
[ replace ]
Delete community attributes of apply comm-list Optional
BGP routing information comm-list-number delete
according to the community list
Set community attribute for apply community { none | Optional
BGP routes additive |
Not set by default
{ community-number&<1-16
> | aa:nn&<1-16> | internet
| no-export-subconfed |
no-export | no-advertise }
* [ additive ] }
Set a cost for routes apply cost [ + | - ] value Optional
Not set by default


Set a cost type for routes apply cost-type [ external | Optional
internal | type-1 | type-2 ]
Not set by default
Set the extended community apply extcommunity { rt Optional
attribute for BGP routes { as-number:nn |
Not set by default
ip-address:nn } }&<1-16>
[ additive ]
Set a next hop for IPv4 routes apply ip-address next-hop Optional
ip-address
Not set by default
The next hop set using the
apply ip-address next-hop
command does not take
effect for route
redistribution.
for IPv6 routes apply ipv6 next-hop Optional
ipv6-address
Not set by default
The next hop set using the
apply ip-address next-hop
command does not take
effect for route
redistribution.
Redistribute routes to a apply isis { level-1 | Optional
specified ISIS level level-1-2 | level-2 }
Set a local preference for BGP apply local-preference Optional
routes preference
Not set by default
Set MPLS label apply mpls-label Optional
Not set by default
Set an origin attribute for BGP apply origin { igp | egp Optional
routes as-number | incomplete }
Not set by default
Set a preference for the apply preference Optional
matched routing protocol preference
Not set by default
Set a preferred value for BGP apply preferred-value Optional
routes preferred-value
Not set by default
Set a tag value for RIP, OSPF or apply tag value Optional
IS-IS routes
Not set by default
n ■ The difference between IPv4 and IPv6 apply clauses is the command of setting
the next hop for routing information.
■ The apply ip-address next-hop and apply ipv6 next-hop commands do
not apply to redistributed IPv4 and IPv6 routes respectively.

Displaying and
Maintaining the To do... Use the command... Remarks
Routing Policy Display BGP AS path ACL display ip as-path [ as-path-number ] Available in any
information view
Display BGP community list display ip community-list
information [ basic-community-list-number |
adv-community-list-number ]
Display BGP extended display ip extcommunity-list
community list information [ ext-comm-list-number ]
Display IPv4 prefix list display ip ip-prefix [ ip-prefix-name ]
statistics
Display IPv6 prefix list display ip ipv6-prefix
statistics [ ipv6-prefix-name ]
Display routing policy display route-policy
information [ route-policy-name ]
Clear IPv4 prefix list statistics reset ip ip-prefix [ ip-prefix-name ] Available in user
view
Clear IPv6 prefix statistics reset ip ipv6-prefix [ ipv6-prefix-name ]
Routing Policy
Configuration
Example
Applying Routing Policy Network Requirements

When Redistributing In Figure 300, Router B exchanges routing information with Router A using OSPF,
IPv4 Routes and with Router C using IS-IS.
Configure route redistribution on Router B to redistribute IS-IS routes into the

OSPF routing domain, and use a routing policy to set attributes for redistributed
routes. Set the cost of route 172.17.1.0/24 to 100, and the tag of route
172.17.2.0/24 to 20.
Network diagram
Figure 300 Network diagram for routing policy application to route redistribution
OSPF IS-IS
S2 /0 S2/1
192 .168 .1 .2/24 192 .168 .2 .2/24
Router B
Eth1/0
172 .17 .1 .1/24
S2 /1 S2/1
192 .168 .1.1 /24 192.168 .2.1/24 Eth1/1
172 .17 .2 .1/24
Router A Router C
Eth1/2
172 .17 .3 .1/24

2 Configure IS-IS
[RouterC] isis
[RouterC-isis-1] is-level level-2
[RouterC-Serial2/1] isis enable
[RouterC-Ethernet1/0] isis enable
[RouterB] isis
[RouterB-Serial2/1] isis enable
3 Configure OSPF and route redistribution.
# Configure Router A, enabling OSPF.
[RouterA] ospf
# Configure Router B, enabling OSPF and redistributing routes from IS-IS.
[RouterB] ospf
[RouterB-ospf-1] import-route isis 1
#Displaying OSPF routing table on Router A, you can find redistributed routes.


Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs

172.17.1.0/24 1 Type2 1 192.168.1.2 192.168.2.2
172.17.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.2.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
Total Nets: 5
4 Configure filtering lists on Router B
# Configure an ACL with the number 2002 to allow 172.17.2.0/24 to pass.

[RouterB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
# Configure an IP prefix list with the name prefix-a to allow 172.17.1.0/24 to pass.
[RouterB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24

5 Configure a routing policy on Router B
[RouterB] route-policy isis2ospf permit node 10
[RouterB-route-policy] if-match ip-prefix prefix-a
[RouterB-route-policy] apply cost 100
[RouterB-route-policy] quit
[RouterB-route-policy] if-match acl 2002
[RouterB-route-policy] apply tag 20
6 Apply the routing policy when redistributing routes on Router B.
# Configure Router B to apply the routing policy for route redistribution.
[RouterB] ospf
[RouterB-ospf-1] import-route isis 1 route-policy isis2ospf
# Displaying OSPF routing table information on Router A, you can find the route
cost to the destination 172.17.1.0/24 is 100, and the tag of the route
172.17.2.0/24 is 20, other external routes have no change.

Routing Tables
Routing for Network

192.168.1.0/24 1 Transit 192.168.1.1 192.168.1.1 0.0.0.0

Routing for ASEs

172.17.1.0/24 100 Type2 1 192.168.1.2 192.168.2.2
172.17.2.0/24 1 Type2 20 192.168.1.2 192.168.2.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.2.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.2.2
Total Nets: 5
Applying a Routing Network requirements

Policy When ■ In the following figure, Router A communicates with Router B, both using PPP
Redistributing IPv6 at link layer and RIPng for routing.
Routes
■ Enable RIPng and configure three static routes on Router A
■ Apply a routing policy when redistributing static routes, making routes in
20::/32 and 40::/32 pass, routes in 30::/32 filtered.
■ Display RIPng routing table information on Router B to verify the configuration.
Network diagram
Figure 301 Network diagram for routing policy application to route redistribution
20::/32
30::/32
40::/32
S 2/1
11::1 /32 S2/0 S 2/0
10::1/32 10::2 /32
Router A Router B
# Configure IPv6 addresses for interfaces Serial 2/0 and Serial 2/1 and enable PPP.
[RouterA] ipv6
# Enable RIPng for interface Serial 2/0.

# Configure three static routes on Router A.

[RouterA] ipv6 route-static 20:: 32 serial 2/1

# Configure a routing policy.
[RouterA] ip ipv6-prefix a index 10 permit 30:: 32

[RouterA] route-policy static2ripng deny node 0
[RouterA-route-policy] if-match ipv6 address prefix-list a
[RouterA] route-policy static2ripng permit node 10
# Enable RIPng and apply routing policy static3ripng to filter redistributed static
routes on Router A.
[RouterA] ripng
[RouterA-ripng-1] import-route static route-policy static2ripng
# Configure the IPv6 address for Serial 2/0 and enable PPP.
[RouterB] ipv6
# Enable RIPng for interface Serial 2/0.

# Enable RIPng.
[RouterB] ripng
# Display RIPng routing table information.
[RouterB-ripng-1] display ripng 1 route

Route Flags: A - Aging, S - Suppressed, G - Garbage-collect
----------------------------------------------------------------
Peer FE80::7D58:0:CA03:1 on Serial2/0

Dest 10::/32,
via FE80::7D58:0:CA03:1, cost 1, tag 0, A, 18 Sec
Dest 20::/32,
Dest 40::/32,

Troubleshooting Routing Policy Configuration 1005
Troubleshooting
Routing Policy
Configuration
IPv4 Routing Symptom

Information Filtering Filtering routing information failed, while routing protocol runs normally.
Failure
Analysis
At least one item of the IP prefix list should be configured as permit mode, and at
least one node in the Route-policy should be configured as permit mode.
Processing procedure
1 Use the display ip ip-prefix command to display IP prefix list information.
2 Use the display route-policy command to display routing policy information.
IPv6 Routing Symptom

Information Filtering Filtering routing information failed, while routing protocol runs normally.
Failure
Analysis
At least one item of the IPv6 prefix list should be configured as permit mode, and
at least one node of the Route-policy should be configured as permit mode.
Processing procedure
1 Use the display ip ipv6-prefix command to display IP prefix list information.
2 Use the display route-policy command to display routing policy information.


STATIC ROUTING CONFIGURATION
61
When configuring a static route, go to the following sections for information you
are interested in:
■ “Introduction” on page 1007
■ “Configuring a Static Route” on page 1008
■ “Detecting Reachability of the Static Route’s Nexthop” on page 1009
■ “Displaying and Maintaining Static Routes” on page 1010
■ “Configuration Example” on page 1010
Introduction
Static Route A static route is a special route that is manually configured by the network
administrator. If a network’s topology is simple, you only need to configure static
routes for network interconnection. The proper configuration and usage of static
routes can improve network performance and ensure bandwidth for important
network applications.
The disadvantage of using static routes is that they cannot adapt to network
topology changes. If a fault or a topological change occurs to the network, the
routes will be unavailable and the network breaks. In this case, the network
administrator has to modify the static routes manually.
Default Route A router selects the default route only when it cannot find any matching entry in
the routing table.
■ If the destination address of a packet fails to match any entry in the routing
table, the router selects the default route to forward the packet.
■ If there is no default route and the destination address of the packet fails to
match any entry in the routing table, the packet will be discarded and an ICMP
packet will be sent to the source to report that the destination or the network
is unreachable.
You can create the default route with both destination and mask being 0.0.0.0,
and some dynamic routing protocols, such as OSPF, RIP and IS-IS, can also
generate the default route.

1008 CHAPTER 61: STATIC ROUTING CONFIGURATION
Application Before configuring a static route, you need to know the following concepts:
Environment of Static
Routing
1 Destination address and mask
In the ip route-static command, an IPv4 address is in dotted decimal format and

a mask can be either in dotted decimal format or in the form of mask length (the
digits of consecutive 1s in the mask).
2 Output interface and next hop address
While configuring a static route, you can specify either the output interface or the
next hop address depending on the specific occasion. The next hop address can
not be a local interface IP address; otherwise, the route configuration will not take
effect.
In fact, all the route entries must have a next hop address. When forwarding a
packet, a router first searches the routing table for the route to the destination
address of the packet. The system can find the corresponding link layer address
and forward the packet only after the next hop address is specified.
When specifying the output interface, note that:
■ If the output interface is a NULL0 or loopback interface, there is no need to

configure the next hop address.
■ If the output interface is a point-to-point interface, there is no need to
configure the next hop address. You need not change the configuration even if
the peer’s address changes. For example, a PPP interface obtains the peer’s IP
address through PPP negotiation, so you need only specify the output
interface.
■ If the output interface is an NBMA or P2MP interface, which support
point-to-multipoint network, the IP address to link layer address mapping must
be established. Therefore, it is recommended to configure both the next hop IP
address and the output interface.
■ You are not recommended to specify a broadcast interface (such as an Ethernet
interface, virtual template, or VLAN interface) as the output interface, because
a broadcast interface may have multiple next hops. If you have to do so, you
must specify the corresponding next hop for the output interface.
3 Other attributes
You can configure different preferences for different static routes so that route
management policies can be applied more flexibly. For example, specifying the
same preference for different routes to the same destination enables load sharing,
while specifying different preferences for these routes enables route backup.
Configuring a Static
Route
Configuration Before configuring a static route, you need to finish the following tasks:
Prerequisites ■ Configure the physical parameters for related interfaces

Detecting Reachability of the Static Route’s Nexthop 1009
■ Configure the link-layer attributes for related interfaces

■ Configure the IP addresses for related interfaces
Configuration Procedure Follow these steps to configure a static route:

Configure a static ip route-static dest-address { mask | Required
route mask-length } { gateway-address |
By default,
preference for static
[ gateway-address ] | vpn-instance
routes is 60, tag is 0,
d-vpn-instance-name gateway-address }
and no description
[ preference preference-value ] [ tag
information is
tag-value ] [ description description-text ]
configured.
ip route-static vpn-instance
s-vpn-instance-name&<1-6> dest-address
{ mask | mask-length } { gateway-address
[ public ] | interface-type interface-number
[ gateway-address ] | vpn-instance
d-vpn-instance-name gateway-address }
[ preference preference-value ] [ tag
tag-value ] [ description description-text ]
Configure the ip route-static default-preference Optional

default preference default-preference-value
60 by default
for static routes
n ■ When configuring a static route, the static route does not take effect if you
specify the next hop address first and then configure it as the IP address of a
local interface, such as Ethernet interface and VLAN interface.
■ If you do not specify the preference when configuring a static route, the
default preference will be used. Reconfiguring the default preference applies
only to newly created static routes.
■ You can flexibly control static routes by configuring tag values and using the
tag values in the routing policy.
■ If the destination IP address and mask are both configured as 0.0.0.0 with the
ip route-static command, the route is the default route.
Detecting Reachability If a static route fails due to a topology change or a fault, the connection will be
of the Static Route’s interrupted. To improve network stability, the system needs to detect reachability
Nexthop of the static route’s next hop and switch to a backup route once the next hop is
unreachable. The following method is used to detect reachability of the static
route’s next hop.
Detecting Nexthop If you specify the nexthop but not outgoing interface when configuring a static
Reachability Through route, you can associate the static route with a track entry to check the static route
Track validity. When the track entry is positive, the static route’s nexthop is reachable
and the static route takes effect; when the track entry is negative, the static route’s
nexthop is unreachable and the static route is invalid. For details about track, refer
to “Track Configuration” on page 2207.

Network requirements
To detect the reachability of a static route’s nexthop through a Track entry, you
need to create a Track first. For detailed Track configuration procedure, refer to
“Track Configuration” on page 2207.
Follow these steps to detect the reachability of a static route’s nexthop through
Track:

Associate the static ip route-static dest-address { mask | Required
route with a track mask-length } { gateway-address |
Not configured by
entry vpn-instance d-vpn-instance-name
default
gateway-address } track track-entry-number
ip route-static vpn-instance
s-vpn-instance-name&<1-6> dest-address
{ mask | mask-length } { gateway-address
track track-entry-number [ public ] |
vpn-instance d-vpn-instance-name
gateway-address track track-entry-number }
n ■ To configure this feature for an existing static route, simply associate the static
route with a track entry. For a non-existent static route, configure it and
associate it with a Track entry.
■ If the track module uses NQA to detect the reachability of the private network
static route’s nexthop, the VPN instance number of the static route’s nexthop
must be identical to that configured in the NQA test group.
■ If a static route needs route recursion, the associated track entry must monitor
the nexthop of the recursive route instead of that of the static route;
otherwise, a valid route may be mistakenly considered invalid
Displaying and
Maintaining Static To do... Use the command... Remarks
Routes View the current display current-configuration Available in any
configuration information view
View the brief information of display ip routing-table
the IP routing table
View the detailed information display ip routing-table verbose
of the IP routing table
View information of static display ip routing-table protocol
routes static [ inactive | verbose ]
Delete all the static routes delete [ vpn-instance Available In system
vpn-instance-name ] static-routes all view
Configuration Network requirements

Example The routers’ interfaces and the hosts’ IP addresses and masks are shown in the
following figure. Static routes are required for interconnections between any two
hosts.

Network diagram
Figure 302 Network diagram for static route configuration
Host B
1.1.6.2/24
Eth1/2
1.1.6 .1/24
Eth1 /0 Eth1/1
1.1.4 .2/30 1.1.5 .5/30
Router B
Eth1/1 Eth1 /1
1.1.4.1/30 1 .1.5.6/30
Eth1/0 Eth1/0
1.1.2.3/24 1.1.3 .1/24
Host A Router A Router C Host C
1.1.2.2/24 1.1.3.2/24
1 Configuring IP addresses for interfaces (omitted)
2 Configuring static routes
# Enter system view
# Configure a default route on Router A.
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.4.2
# Configure two static routes on Router B.
[RouterB] ip route-static 1.1.2.0 255.255.255.0 1.1.4.1
[RouterB] ip route-static 1.1.3.0 255.255.255.0 1.1.5.6
# Configure a default route on Router C.
[RouterC] ip route-static 0.0.0.0 0.0.0.0 1.1.5.5
3 Configure the hosts
The default gateways for the three hosts Host A, Host B and Host C are 1.1.2.3,
1.1.6.1 and 1.1.3.1 respectively. The detailed configuration procedure is omitted.
4 Display the configuration result
# Display the IP routing table of Router A.


0.0.0.0/0 Static 60 0 1.1.4.2 Serial2/0

1.1.1.0/24 Direct 0 0 1.1.1.1 Ethernet1/0

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoopBack0
1.1.4.0/30 Direct 0 0 1.1.4.1 Serial2/0
1.1.4.2/32 Direct 0 0 1.1.4.2 Serial2/0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoopBack0Routin
g Tables: Public
0.0.0.0/0 Static 60 0 1.1.4.2 Eth1/1

1.1.2.0/24 Direct 0 0 1.1.2.3 Eth1/0
1.1.2.3/32 Direct 0 0 127.0.0.1 InLoop0
1.1.4.0/30 Direct 0 0 1.1.4.1 Eth1/1
1.1.4.1/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
# Display the IP routing table of Router B.
[RouterB] display ip routing-table

1.1.2.0/24 Static 60 0 1.1.4.1 Eth1/0

1.1.3.0/24 Static 60 0 1.1.5.6 Eth1/1
1.1.4.0/30 Direct 0 0 1.1.4.2 Eth1/0
1.1.4.2/32 Direct 0 0 127.0.0.1 InLoop0
1.1.5.4/30 Direct 0 0 1.1.5.5 Eth1/1
1.1.5.5/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
1.1.6.0/24 Direct 0 0 1.1.6.1 Eth1/2
1.1.6.1/32 Direct 0 0 127.0.0.1 InLoop0
# Use the ping command on Host B to check reachability to Host A, assuming

Windows XP runs on the two hosts.
C:Documents and SettingsAdministrator> ping 1.1.2.2

Pinging 1.1.2.2 with 32 bytes of data:
Reply from 1.1.2.2: bytes=32 time=1ms TTL=128
Ping statistics for 1.1.2.2:
# Use the tracert command on Host B to check reachability to Host A.
C:Documents and SettingsAdministrator>tracert 1.1.2.2
Tracing route to 1.1.2.2 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 1.1.6.1

2 <1 ms <1 ms <1 ms 1.1.4.1

3 1 ms <1 ms <1 ms 1.1.2.2

Trace complete.


IPV6 BGP CONFIGURATION
62
n This chapter describes only configuration for IPv6 BGP. For BGP related
information, refer to “BGP Configuration” on page 825.
When configuring IPv6 BGP, go to these sections for information you are
interested in:
■ “IPv6 BGP Overview” on page 1015

■ “IPv6 BGP Configuration Task List” on page 1016
■ “Configuring IPv6 BGP Basic Functions” on page 1017
■ “Controlling Route Distribution and Reception” on page 1020
■ “Configuring IPv6 BGP Route Attributes” on page 1023
■ “Adjusting and Optimizing IPv6 BGP Networks” on page 1024
■ “Configuring a Large Scale IPv6 BGP Network” on page 1027
■ “Configuring 6PE” on page 1029
■ “Displaying and Maintaining IPv6 BGP Configuration” on page 1033
■ “IPv6 BGP Configuration Examples” on page 1034
■ “Troubleshooting IPv6 BGP Configuration” on page 1041
IPv6 BGP Overview BGP-4 manages only IPv4 routing information, thus other network layer protocols
such as IPv6 are not supported.
To support multiple network layer protocols, IETF extended BGP-4 by introducing

IPv6 BGP that is defined in RFC 2858 (Multiprotocol Extensions for BGP-4).
To implement IPv6 support, IPv6 BGP puts IPv6 network layer information into the
attributes of Network Layer Reachable Information (NLRI) and NEXT_HOP.
NLRI attribute of IPv6 BGP involves:
■ MP_REACH_NLRI: Multiprotocol Reachable NLRI, for advertisement of next hop

information of reachable routes.
■ MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI, for withdrawal of
unreachable routes.
The NEXT_HOP attribute of IPv6 BGP is identified by an IPv6 unicast address or

IPv6 local link address.
IPv6 BGP utilizes BGP multiprotocol extensions for application in IPv6 networks.
The original messaging and routing mechanisms of BGP are not changed.

1016 CHAPTER 62: IPV6 BGP CONFIGURATION
IPv6 BGP Complete the following tasks to configure IPv6 BGP:

Configuration Task
List Task Remarks
“IPv6 BGP Configuration” “Configuring an IPv6 Peer” on Required
on page 1015 page 1017
“Advertising a Local IPv6 Optional
Route” on page 1017
“Configuring a Preferred Optional
Value for Routes from a
Peer/Peer Group” on page
1018
“Specifying a Local Update Optional
Source Interface to a Peer/Peer
“Configuring a Non Direct Optional
EBGP Connection to a
1019
“Configuring Description for a Optional
1019
“Establishing No Session to a Optional
1019
“Logging Session State and Optional
Event Information of a
1019
“IPv6 BGP Configuration” “Configuring IPv6 BGP Route Optional
on page 1015 Redistribution” on page 1020
“Advertising a Default Route Optional
to a Peer/Peer Group” on page
1020
Distribution Policy” on page
1021
“Configuring Route Reception Optional
Policy” on page 1021
“Configuring IPv6 BGP and Optional
IGP Route Synchronization” on
page 1022
Dampening” on page 1022
“IPv6 BGP Configuration” “Configuring IPv6 BGP Optional
on page 1015 Preference and Default
LOCAL_PREF and NEXT_HOP
Attributes” on page 1023
“Configuring the MED Optional
Attribute” on page 1024
“Configuring the AS_PATH Optional
Attribute” on page 1024

Task Remarks
“IPv6 BGP Configuration” “Configuring IPv6 BGP Optional
on page 1015 Timers” on page 1025
“Configuring IPv6 BGP Soft Optional
Reset” on page 1026
Number of Load-Balanced
“IPv6 BGP Configuration” “Configuring IPv6 BGP Peer Optional
on page 1015 Group” on page 1027
“Configuring IPv6 BGP Optional
Community” on page 1028
“Configuring an IPv6 BGP Optional
Route Reflector” on page
1029
“Configuring 6PE” on page “Configuring Basic 6PE Required
1029 Capabilities” on page 1030
“Configuring Optional 6PE Optional
Capabilities” on page 1031
Configuring IPv6 BGP

Basic Functions
Prerequisites Before configuring this task, you need to

■ Specify IP addresses for interfaces
■ Enable IPv6 function.
n You need create a peer group before configuring basic functions for it. For related
information, refer to “Configuring IPv6 BGP Peer Group” on page 1027.
Configuring an IPv6 Peer Follow these steps to configure an IPv6 peer:

Enter BGP view bgp as-number Required
Specify a router ID router-id router-id Optional
Required if no IP addresses
configured for Loopback
interface and other interfaces
Enter IPv6 address family view ipv6-family -
Specify an IPv6 peer and its peer ipv6-address Required
AS number as-number as-number
Advertising a Local IPv6 Follow these steps to advertise a local route into the routing table:
Route


Add a local route into IPv6 network ipv6-address Required
BGP routing table prefix-length [ short-cut |
route-policy
route-policy-name ]
Configuring a Preferred Follow these steps to configure a preferred value for routes received from a
Value for Routes from a peer/peer group:
Peer/Peer Group
Configure a preferred value for routes peer { ipv6-group-name | Optional
received from a peer/peer group ipv6-address }
By default, the
preferred-value value
preferred value is 0.
c CAUTION: If you both reference a routing policy and use the command peer
{ ipv6-group-name | ipv6-address } preferred-value value to set a preferred value
for routes from a peer, the routing policy sets a non-zero preferred value for
routes matching it. Other routes not matching the routing policy uses the value set
with the command. If the preferred value in the routing policy is zero, the routes
matching it will also use the value set with the command. For information about
using a routing policy to set a preferred value, refer to the command peer
{ group-name | ipv4-address | ipv6-address } route-policy route-policy-name
{ import | export } in this document, and the command apply preferred-value
preferred-value in “Routing Policy Configuration” on page 991.
Specifying a Local Follow these steps to specify a local update source interface connected to a peer:
Update Source Interface
to a Peer/Peer Group To do... Use the command... Remarks
Specify the source interface peer { ipv6-group-name | Required
for establishing TCP ipv6-address }
By default, IPv6 BGP uses the
connections to a BGP peer or connect-interface
outbound interface of the
peer group interface-type
best route to the BGP peer as
interface-number
the source interface for
establishing a TCP
connection.
n ■ To improve stability and reliability, you can specify the local interface of an IPv6
BGP connection as loopback interface. By doing so, a connection failure upon
redundancy availability will not affect IPv6 BGP connection.
■ To establish multiple BGP connections to an IPv6 BGP router, you need to
specify on the local router the respective source interfaces for establishing TCP
connections to the peers on the peering BGP router; otherwise, the local BGP

router may fail to establish TCP connections to the peers when using the
outbound interfaces of the best routes as the source interfaces.
Configuring a Non Direct Follow these steps to configure an EBGP connection to a peer not directly
EBGP Connection to a connected:
Peer/Peer Group
Configure a non direct EBGP peer { ipv6-group-name | Required
connection to a peer/peer ipv6-address } ebgp-max-hop
Not configured by
group [ hop-count ]
default
c CAUTION: In general, direct links should be available between EBGP peers. If not,
you can use the peer ebgp-max-hop command to establish a multi-hop TCP
connection in between. However, you need not use this command for direct EBGP
connection with loopback interfaces.
Configuring Description Follow these steps to configure description for a peer/peer group:
for a Peer/Peer Group
Configure description for a peer { ipv6-group-name | Optional
peer/peer group ipv6-address } description
description-text
n The peer group for which to configure description must have been created.
Establishing No Session Follow these steps to disable session establishment to a peer/peer group:
to a Peer/Peer Group
Disable session establishment peer { ipv6-group-name | Optional
to a peer/peer group ipv6-address } ignore
Logging Session State Follow these steps to log on the session and event information of a peer/peer
and Event Information group:
of a Peer/Peer Group


Enable global logging log-peer-change Optional
Enabled by default
Enable to log session and peer { ipv6-group-name | Optional
event information of a ipv6-address } log-change
Enabled by default
peer/peer group
n Refer to “BGP Configuration” on page 825 for information about the

log-peer-change command.
Controlling Route The task includes routing information filtering, routing policy application and route
Distribution and dampening.
Reception
Prerequisites Before configuring this task, you have:

■ Enabled the IPv6 function
■ Configured IPv6 BGP basic functions
You need to decide on:
■ ACL number
■ Routing policy names on both distribution and reception directions
■ Route dampening parameters: half-life, threshold values
Configuring IPv6 BGP Follow these steps to configure IPv6 BGP route redistribution and filtering:
Route Redistribution
Enable default route default-route imported Optional
redistribution into the IPv6
BGP routing table
Enable route redistribution import-route protocol Required
from another routing protocol [ process-id ] [ med
med-value | route-policy
n If the default-route imported command is not configured, using the

import-route command cannot redistribute any IGP default route.
Advertising a Default Follow these steps to advertise default route to a peer/peer group:
Route to a Peer/Peer


Advertise a default route to a peer { ipv6-group-name | ipv6-address } Required
peer/peer group default-route-advertise [ route-policy
Not advertised by
route-policy-name ]
default
n With the peer default-route-advertise command used, the local router

advertises a default route with itself as the next hop to the specified peer/peer
group, regardless of whether the default route is available in the routing table.
Configuring Route Follow these steps to configure policies for route distribution:
Distribution Policy
Configure outbound route filter-policy { acl6-number | Required
filtering ipv6-prefix ipv6-prefix-name }
Not configured by
export [ protocol process-id ]
default
Apply a routing policy to peer { ipv6-group-name | Required
routes advertised to a ipv6-address } route-policy
Not applied by default
peer/peer group route-policy-name export
Specify an IPv6 ACL to filer peer { ipv6-group-name | Required
routes advertised to a ipv6-address } filter-policy
peer/peer group acl6-number export
Specify an AS path ACL to filer peer { ipv6-group-name | Required
routes advertised to a ipv6-address } as-path-acl
peer/peer group as-path-acl-number export
Specify an IPv6 prefix list to peer { ipv6-group-name | Required
filer routes advertised to a ipv6-address } ipv6-prefix
peer/peer group ipv6-prefix-name export
n ■ Members of a peer group must have the same outbound route policy with the
peer group.
■ IPv6 BGP advertises routes passing the specified policy to peers. Using the
protocol argument can filter only the specified protocol routes. If no protocol
specified, IPv6 BGP filters all routes to be advertised, including redistributed
routes and routes imported using the network command.
Configuring Route Follow these steps to configure route reception policy:

Reception Policy
Configure inbound route filter-policy { acl6-number | Required
filtering ipv6-prefix ipv6-prefix-name }
import


routes from a peer/peer group ipv6-address } route-policy
route-policy-name import
Specify an ACL to filter routes peer { ipv6-group-name | Required
imported from a peer/peer ipv6-address } filter-policy
group acl6-number import
Specify an AS path ACL to peer { ipv6-group-name | Required
filter routing information ipv6-address } as-path-acl
imported from a peer/peer as-path-acl-number import
group
Specify an IPv6 prefix list to peer { ipv6-group-name | Required
filter routing information ipv6-address } ipv6-prefix
imported from a peer/peer ipv6-prefix-name import
group
Specify the upper limit of peer { ipv6-group-name | Optional
address prefixes imported ipv6-address } route-limit limit
By default, no limit on
from a peer/peer group [ percentage ]
prefixes
n ■ Only routes passing the specified policy can be added into the local IPv6 BGP
routing table.
■ Members of a peer group can have different inbound route policies.
Configuring IPv6 BGP With this feature enabled and when a non-BGP router is responsible for
and IGP Route forwarding packets in an AS, IPv6 BGP speakers in the AS cannot advertise routing
Synchronization information to outside ASs unless all routers in the AS know the latest routing
information.
By default, when a BGP router receives an IBGP route, it only checks the
reachability of the route’s next hop before advertisement. If the synchronization
feature is configured, only the IBGP route is advertised by IGP can the route be
advertised to EBGP peers.
Follow these steps to configure IPv6 BGP and IGP route synchronization:

Enable route synchronization synchronization Required
between IPv6 BGP and IGP
Configuring Route Follow these steps to configure BGP route dampening:

Dampening

Configuring IPv6 BGP Route Attributes 1023

Configure IPv6 BGP route dampening [ half-life-reachable Optional
dampening parameters half-life-unreachable reuse suppress
Not configured by
ceiling | route-policy
default
Configuring IPv6 BGP This section describes how to use IPv6 BGP route attributes to modify BGP routing
Route Attributes policy. These attributes are:
■ IPv6 BGP protocol preference
■ Default LOCAL_PREF attribute
■ MED attribute
■ NEXT_HOP attribute
■ AS_PATH attribute
Prerequisites Before configuring this task, you have:

■ Enabled IPv6 function
Configuring IPv6 BGP Follow these steps to configure IPv6 BGP preference and default LOCAL_PREF and
Preference and Default NEXT_HOP attributes:
LOCAL_PREF and
NEXT_HOP Attributes To do... Use the command... Remarks
Configure preference values preference Optional
for IPv6 BGP external, internal, { external-preference
The default preference values
local routes internal-preference
of external, internal and local
local-preference |
routes are 255, 255, 130
route-policy
respectively
route-policy-name }
Configure the default value default local-preference Optional
for local preference value
The value defaults to 100
Advertise routes to a peer { ipv6-group-name | Required
peer/peer group with the local ipv6-address }
By default, the feature is
router as the next hop next-hop-local
available for routes advertised
to the EBGP peer/peer group,
but not available to the IBGP
peer/peer group
n ■ To make sure an IBGP peer can find the correct next hop, you can configure
routes advertised to the peer to use the local router as the next hop. If BGP
load balancing is configured, the local router specifies itself as the next hop of
outbound routes to a peer/peer group regardless of whether the peer
next-hop-local command is configured.
■ In a “third party next hop” network, that is, the two EBGP peers reside in a
common broadcast subnet, the router does not specify itself as the next hop

for routes to the EBGP peer by default, unless the peer next-hop-local
Configuring the MED Follow these steps to configure the MED attribute:
Attribute
Configure a default MED default med med-value Optional
value
Defaults to 0
Enable to compare MED compare-different-as-med Optional
values of routes from different
EBGP peers
Prioritize MED values of routes bestroute compare-med Optional
from each AS
Prioritize MED values of routes bestroute Optional
from confederation peers med-confederation
Configuring the Follow these steps to configure the AS_PATH attribute:

AS_PATH Attribute
Allow the local AS number to peer { ipv6-group-name | Optional
appear in AS_PATH of routes ipv6-address } allow-as-loop
Not allowed by default
from a peer/peer group and [ number ]
specify the repeat times
Specify a fake AS number for peer { ipv6-group-name | Optional
a peer/peer group ipv6-address } fake-as
as-number
Neglect the AS_PATH bestroute as-path-neglect Optional
attribute for best route
Not neglected by default
selection
Configure to carry only the peer { ipv6-group-name | Optional
public AS number in updates ipv6-address } public-as-only
By default, BGP updates carry
sent to a peer/peer group
private AS number
Substitute local AS number peer { ipv6-group-name | Optional
for the AS number of a ipv6-address } substitute-as
Not substituted by default
peer/peer group indicated in
the AS_PATH attribute
Adjusting and This section describes configurations of IPv6 BGP timers, IPv6 BGP connection soft
Optimizing IPv6 BGP reset and the maximum number of load balanced routes.
Networks ■ IPv6 BGP timers

Adjusting and Optimizing IPv6 BGP Networks 1025
After establishing an IPv6 BGP connection, two routers send keepalive messages
periodically to each other to keep the connection. If a router receives no keepalive
message from the peer after the holdtime elapses, it tears down the connection.
When establishing an IPv6 BGP connection, the two parties compare their
holdtime values, taking the shorter one as the common holdtime. If the holdtime
is 0, neither keepalive massage is sent, nor holdtime is checked.
■ IPv6 BGP connection soft reset
After modifying a route selection policy, you have to reset IPv6 BGP connections to
make the new one take effect, causing a short time disconnection. The current
IPv6 BGP implementation supports the route-refresh feature that enables dynamic
IPv6 BGP routing table refresh without needing to disconnect IPv6 BGP links.
With this feature enabled on all IPv6 BGP routers in a network, when a routing
policy modified on a router, the router advertises a route-refresh message to its
peers, which then send their routing information back to the router. Therefore, the
local router can perform dynamic routing information update and apply the new
policy without tearing down connections.
If a router not supporting route-refresh exists in the network, you need to

configure the peer keep-all-routes command on the router to save all route
updates, and then use the refresh bgp ipv6 command to soft-reset IPv6 BGP
connections.
Prerequisites Before configuring IPv6 BGP timers, you have:

■ Enabled IPv6 function
Configuring IPv6 BGP Follow these steps to configure IPv6 BGP timers:
Timers
Configure IPv6 Specify timer keepalive keepalive Optional
BGP timers keepalive hold holdtime
The keepalive interval
interval and
defaults to 60 seconds,
holdtime
holdtime defaults to 180
Configure peer { ipv6-group-name | seconds.
keepalive ipv6-address } timer
interval and keepalive keepalive hold
holdtime for a holdtime
peer/peer group
Configure the interval for peer { ipv6-group-name | Optional

sending the same update to a ipv6-address }
The interval for sending the
peer/peer group route-update-interval
same update to an IBGP peer
seconds
or an EBGP peer defaults to
15 seconds or 30 seconds

n ■ Timers configured using the timer command have lower priority than timers
configured using the peer timer command.
■ The holdtime interval must be at least three times the keepalive interval.
Configuring IPv6 BGP Enable route refresh

Soft Reset Follow these steps to enable route refresh:

Enter IPv6 address family ipv6-family -
view
Enable route refresh peer { ipv6-group-name | ipv6-address } Optional
capability-advertise route-refresh
Enabled by default
Perform manual soft-reset

Follow these steps to perform manual soft reset:

Save all routes from a peer/peer peer { ipv6-group-name | Optional
group, not letting them go through ipv6-address } keep-all-routes
Not saved by
the inbound policy
default.
Return to user view return Required
Soft-reset BGP connections manually refresh bgp ipv6 { all |
ipv6-address | group
ipv6-group-name | external |
internal } { export | import }
n If the peer keep-all-routes command is used, all routes from the peer/peer
group will be saved regardless of whether filtering policy available. These routes
will be used to generate IPv6 BGP routes after soft-reset is performed.
Configuring the Follow these steps to configure the maximum number of load balanced routes:
Maximum Number of
Load-Balanced Routes To do... Use the command... Remarks
Configure the maximum balance number Required
number of load balanced
By default, no load balancing
routes
is enabled.

Configuring a Large Scale IPv6 BGP Network 1027
Configuring a Large In a large-scale IPv6 BGP network, configuration and maintenance become no
Scale IPv6 BGP convenient due to too many peers. In this case, configuring peer groups makes
Network management easier and improves route distribution efficiency. Peer group includes
IBGP peer group, where peers belong to the same AS, and EBGP peer group,
where peers belong to different ASs. If peers in an EBGP group belong to the same
external AS, the EBGP peer group is a pure EBGP peer group, and if not, a mixed
EBGP peer group.
In a peer group, all members enjoy a common policy. Using the community
attribute can make a set of IPv6 BGP routers in multiple ASs enjoy the same policy,
because sending of community between IPv6 BGP peers is not limited by AS.
To guarantee connectivity between IBGP peers, you need to make them fully
meshed, but it becomes unpractical when there are too many IBGP peers. Using
route reflectors or confederation can solve it. In a large-scale AS, both of them can
be used.
Confederation configuration of IPv6 BGP is identical to that of BGP 4, so it is not

mentioned here. The following describes:
■ Configuring IPv6 BGP peer group

■ Configuring IPv6 BGP community
■ Configuring IPv6 BGP route reflector
Prerequisites Before configuring IPv6 BGP peer group, you have:

■ Made peer nodes accessible at network layer
■ Enabled BGP and configured router ID.
Configuring IPv6 BGP Create an IBGP peer group

Peer Group Follow these steps to create an IBGP group:

Create an IBGP peer group group ipv6-group-name Required
[ internal ]
Add a peer into the group peer ipv6-address group Required
ipv6-group-name
[ as-number as-number ]
Create a pure EBGP peer group

Follow these steps to configure a pure EBGP group:



Create an EBGP peer group group ipv6-group-name Required
external
Configure the AS number for peer ipv6-group-name Required
the peer group as-number as-number
Add an IPv6 peer into the peer peer ipv6-address group Required
group ipv6-group-name
n ■ To create a pure EBGP peer group, you need to specify an AS number for the
peer group.
■ If a peer was added into an EBGP peer group, you cannot specify any AS
number for the peer group.
Create a mixed EBGP peer group

Follow these steps to create a mixed EBGP peer group:

Create an EBGP peer group group ipv6-group-name Required
external
Specify the AS number of an peer ipv6-address Required
IPv6 peer as-number as-number
Add the IPv6 peer into the peer ipv6-address group Required
peer group ipv6-group-name
n When creating a mixed EBGP peer group, you need to create a peer and specify its
AS number that can be different from AS numbers of other peers, but you cannot
specify AS number for the EBGP peer group.
Configuring IPv6 BGP Advertise community attribute to a peer/peer group

Community Follow these steps to advertise community attribute to a peer/peer group:

Advertise community peer { ipv6-group-name | Required
attribute to a peer/peer group ipv6-address }
advertise-community


Advertise extended peer { ipv6-group-name | Required
community attribute to a ipv6-address }
peer/peer group advertise-ext-community
Apply a routing policy to routes advertised to a peer/peer group

Follow these steps to apply a routing policy to routes advertised to a peer/peer
group:

routes advertised to a ipv6-address } route-policy
peer/peer group route-policy-name export
n ■ When configuring IPv6 BGP community, you need to configure a routing policy
to define the community attribute, and apply the routing policy to route
advertisement.
■ For routing policy configuration, refer to “Routing Policy Configuration” on
page 991.
Configuring an IPv6 BGP Follow these steps to configure an IPv6 BGP route reflector:
Route Reflector
Configure the router as a peer { ipv6-group-name | Required
route reflector and specify a ipv6-address } reflect-client
peer/peer group as a client
Enable route reflection reflect between-clients Optional
between clients
Enabled by default
Configure the cluster ID of reflector cluster-id cluster-id Optional
the route reflector
By default, a route reflector
uses its router ID as the cluster
ID
n ■ In general, since the route reflector forwards routing information between

clients, it is not required to make clients of a route reflector fully meshed. If
clients are fully meshed, it is recommended to disable route reflection between
clients to reduce routing costs.
■ If a cluster has multiple route reflectors, you need to specify the same cluster ID
for these route reflectors to avoid routing loops.
Configuring 6PE IPv6 Provider Edge (6PE) is a transition technology with which Internet service
providers (ISPs) can use existing IPv4 backbone networks to provide access

capability for sparsely populated IPv6 networks, allowing customer edge (CE)
routers in these isolated IPv6 networks to communicate with IPv4 PE routers.
Work mechanism of 6PE:
IPv6 routing information from users is converted into IPv6 routing information
with labels and then is flooded into IPv4 backbone networks of ISPs through
internal border gateway protocol (IBGP) sessions. When IPv6 packets are
forwarded, they will be labeled when entering tunnels of backbone networks. The
tunnels can be GRE tunnels or MPLS LSPs.
IGPs running on ISP networks can be OSPF or IS-IS. Static routing, IGP, or EBGP can
be used between CE and 6PE.
Figure 303 Network diagram for 6PE
CE IPv4/MPLS network CE
IBGP
IPv6 network 6PE 6PE IPv6 network
n The P (Provider) router in the above figure refers to a backbone router in the
network of a service provider. P is not directly connected with a CE and is required
to have the basic MPLS capability.
When an ISP wants to utilize the existing IPv4/MPLS network to provide IPv6 traffic
switching capability through MPLS, only the PE routers need to be upgraded.
Therefore, it is undoubtedly a high efficient solution that ISPs use the 6PE
technology as an IPv6 transition mechanism. Furthermore, the operation risk of
the 6PE technology is very low.
Configuration Before configuring 6PE, you need to:

Prerequisites ■ Configure the MPLS basic capability for the IPv4 MPLS backbone. For details,
refer to “MPLS Basics Configuration” on page 1311.
■ Configure the IPv6 BGP peer on the PE devices. For details, refer to
“Configuring IPv6 BGP Basic Functions” on page 1017.
■ If a peer group is to be specified, you need to create the peer group
beforehand in BGP view.
Configuring Basic 6PE Follow these steps to configure the 6PE basic capabilities:
Capabilities
view


Specify the AS number for the peer { group-name | Required
6PE peer or peer group ipv4-address } as-number
as-number
Enable the 6PE peer or peer peer { group-name | Required
group ipv4-address } enable
Enable exchange of labeled peer { group-name | Required
IPv4 routes with the 6PE peer ipv4-address }
or peer group label-route-capability
Configuring Optional Follow these steps to configure the 6PE optional capabilities:
6PE Capabilities
view
Specify the AS number for the peer { group-name | Required
6PE peer or peer group ipv4-address } as-number
as-number
Enable the 6PE peer or peer peer { group-name | Required
group ipv4-address } enable
Advertise community attribute peer { group-name | Optional
to the 6PE peer or peer group ipv4-address }
advertise-community
Advertise extended peer { group-name | Optional
community attribute to the ipv4-address }
6PE peer or peer group advertise-ext-community
Allow the local AS number to peer { group-name | Optional
appear in routes from the ipv4-address } allow-as-loop
Not allowed by default
peer or peer group and [ number ]
specify the repeat times
Specify an AS path ACL to peer { group-name | Optional
filter routes from or to the 6PE ipv4-address } as-path-acl
peer or peer group as-path-acl-number { import |
export }
Advertise a default route to peer { group-name | Optional
the 6PE peer or peer group ipv4-address }
default-route-advertise
[ route-policy
route-policy-name ]
Configure an inbound or peer { group-name | Optional
outbound IPv6 ACL based ipv4-address } filter-policy
filtering policy for the 6PE acl6-number { import |
peer or peer group export }
Add an 6PE peer to an peer ipv4-address group Optional
existing peer group group-name [ as-number
as-number ]
Configure an inbound or peer { group-name | Optional
outbound IPv6 prefix list ipv4-address } ipv6-prefix
based filtering policy for the ipv6-prefix-name { import |
6PE peer or peer group export }


Keep all routes from the 6PE peer { group-name | Optional
peer or peer group, including ipv4-address }
Not kept by default
routes not passing the keep-all-routes
inbound filtering policy
Configure the device as a peer { group-name | Optional
route reflector and the 6PE ipv4-address } reflect-client
peer or peer group as a client
Configure an upper limit of peer { group-name | No limitation on received
IPv6 address prefixes that can ipv4-address } route-limit prefixes by default
be received from the 6PE peer limit [ percentage ]
or peer group
Apply a routing policy to peer { group-name | Not applied by default
routes outgoing or incoming ipv4-address } route-policy
from the 6PE peer or peer route-policy-name { import |
group export }
Display information about the display bgp ipv6 peer Optional
6PE peer or peer group [ group-name log-info |
Available in any view
ipv4-address verbose ]
Display routes from or to the display bgp ipv6 Optional
6PE peer or peer group routing-table peer
ipv4-address
{ advertised-routes |
received-routes }
[ network-address
prefix-length | statistic ]
Perform soft reset on inbound refresh bgp ipv6 ip-address Optional
or outbound IPv6 BGP { export | import }
connections
Reset a BGP 6PE connection reset bgp ipv6 ip-address Optional

Displaying and Maintaining IPv6 BGP Configuration 1033
Displaying and
Maintaining IPv6 BGP
Configuration
Displaying BGP
Display peer group display bgp ipv6 group [ ipv6-group-name ] Available in
Display IPv6 BGP advertised display bgp ipv6 network
routing information
Display AS path information display bgp ipv6 paths
[ as-regular-expression ]
Display BGP peer/peer group display bgp ipv6 peer [ group-name log-info
information | ipv4-address verbose | ipv6-address { log-info
| verbose } ]
Display IPv6 BGP routing table display bgp ipv6 routing-table [ ipv6-address
information prefix-length ]
Display routing information display bgp ipv6 routing-table as-path-acl
matched by a AS path ACL as-path-acl-number
Display IPv6 BGP community display bgp ipv6 routing-table community
routing information [ aa:nn<1-13> ] [ no-advertise | no-export |
no-export-subconfed ]* [ whole-match ]
Display routing information display bgp ipv6 routing-table
matched by an IPv6 BGP community-list { basic-community-list-number
community list [ whole-match ] |
adv-community-list-number }&<1-16>
Display BGP dampened display bgp ipv6 routing-table dampened
routing information
Display BGP dampening display bgp ipv6 routing-table dampening
parameter information parameter
originated from different ASs different-origin-as
Display routing flap statistics display bgp ipv6 routing-table flap-info
[ regular-expression as-regular-expression |
as-path-acl as-path-acl-number |
network-address [ prefix-length
[ longer-match ] ] ]
Display IPv6 label routing display bgp ipv6 routing-table label
information
Display routing information to display bgp ipv6 routing-table peer
or from an IPv4 or IPv6 peer { ipv4-address | ipv6-address }
{ advertised-routes | received-routes }
[ network-address prefix-length | statistic ]
matched by a regular regular-expression as-regular-expression
expression
Display IPv6 BGP routing display bgp ipv6 routing-table statistic
statistics

Resetting IPv6 BGP

Connections To do... Use the command... Remarks
Perform soft reset on refresh bgp ipv6 { ipv4-address | ipv6-address | all | Available in
IPv6 BGP connections external | group ipv6-group-name | internal } user view
{ export | import }
Reset IPv6 BGP reset bgp ipv6 { as-number | ipv4-address |
connections ipv6-address [ flap-info ] | all | group group-name |
external | internal }
Clearing IPv6 BGP

Information To do... Use the command... Remarks
Clear dampening routing reset bgp ipv6 dampening [ ipv6-address Available in
information and release prefix-length ] user view
suppressed routes
Clear route flap information reset bgp ipv6 flap-info
[ ipv6-address/prefix-length | regexp
as-path-regexp | as-path-acl
as-path-acl-number ]
IPv6 BGP
Configuration
Examples
n Some IPv6 BGP configuration examples are similar to those of BGP, so refer to
“BGP Configuration” on page 825 for related information.
IPv6 BGP Basic Network requirements

Configuration In Figure 304 are all IPv6 BGP routers. Between Router A and Router B is an EBGP
connection. Router B, Router C and Router D are IBGP fully meshed.
Network diagram
Figure 304 Network diagram for IPv6 BGP basic configuration
AS 65009
S2/2 S2/1
9:3::2/64 9:2::1/64
Router C
S2/1
Router A 10::2/64 S2 /1
S2 /2 9:2::2 /64
S2 /1 9:3::1 /64
10::1/64
AS 65008 S2 /0 S2/0
9:1::1/64 9:1::2/64
Router B Router D
1 Configure IPv6 addresses for interfaces (omitted)
2 Configure IBGP connections

[RouterB] ipv6
[RouterB] bgp 65009
[RouterB-bgp] ipv6-family
[RouterB-bgp-af-ipv6] peer 9:1::2 as-number 65009
[RouterB-bgp-af-ipv6] peer 9:3::2 as-number 65009
[RouterB-bgp-af-ipv6] quit
[RouterB-bgp] quit
[RouterC] ipv6
[RouterC] bgp 65009
[RouterC-bgp] ipv6-family
[RouterC-bgp-af-ipv6] peer 9:3::1 as-number 65009
[RouterC-bgp-af-ipv6] peer 9:2::2 as-number 65009
[RouterC-bgp-af-ipv6] quit
[RouterC-bgp] quit
[RouterD] ipv6
[RouterD] bgp 65009
[RouterD-bgp] ipv6-family
[RouterD-bgp-af-ipv6] peer 9:1::1 as-number 65009
[RouterD-bgp-af-ipv6] peer 9:2::1 as-number 65009
[RouterD-bgp-af-ipv6] quit
[RouterD-bgp] quit
[RouterA] ipv6
[RouterA] bgp 65008
[RouterA-bgp] ipv6-family
[RouterA-bgp-af-ipv6] peer 10::1 as-number 65009
[RouterA-bgp-af-ipv6] quit
[RouterA-bgp] quit
[RouterB] bgp 65009

[RouterB-bgp-af-ipv6] peer 10::2 as-number 65009
[RouterB-bgp-af-ipv6] quit
[RouterB-bgp] quit
# Display IPv6 peer information on Router B.

[RouterB] display bgp ipv6 peer

10::2 4 65008 3 3 0 0 00:01:16 Established

9:3::2 4 65009 2 3 0 0 00:00:40 Established
9:1::2 4 65009 2 4 0 0 00:00:19 Established
# Display IPv6 peer information on Router C.
[RouterC] display bgp ipv6 peer

9:3::1 4 65009 4 4 0 0 00:02:18 Established

9:2::2 4 65009 4 5 0 0 00:01:52 Established
Router A and B established an EBGP connection; Router B, C and D established

IBGP connections with each other.
IPv6 BGP Route Reflector Network requirements

Configuration Router B receives an EBGP update and sends it to Router C, which is configured as
a route reflector with two clients: Router B and Router D.
Router B and Router D need not establish an IBGP connection because Router C
reflects updates between them.
Network diagram
Figure 305 Network diagram for IPv6 BGP route reflector configuration
Route AS 200
Reflector
S 2/2 S2/1
101::1 /96 102::1 /96
S 2/1
Router C
100 ::1/96
Router A IBGP IBGP
S 2/1 S2 /0 S 2/0
100::2 /96 101 ::2/96 102::2/96
AS 100
Router B Router D
2 Configure IPv6 BGP basic functions

[RouterA] ipv6
[RouterA] bgp 100
[RouterA-bgp] ipv6-family
[RouterA-bgp-af-ipv6] peer 100::2 as-number 200
[RouterA-bgp-af-ipv6] network 1:: 64
[RouterB] ipv6
[RouterB] bgp 200
[RouterB-bgp-af-ipv6] peer 101::1 next-hop-local
[RouterC] ipv6
[RouterC] bgp 200
[RouterC-bgp] ipv6-family
[RouterC-bgp-af-ipv6] peer 101::2 as-number 200
[RouterC-bgp-af-ipv6] peer 102::2 as-number 200
[RouterD] ipv6
[RouterD] bgp 200
[RouterD-bgp] ipv6-family
[RouterD-bgp-af-ipv6] peer 102::1 as-number 200
3 Configure route reflector
# Configure Router C as a route reflector, Router B and Router D as its clients.
[RouterC-bgp-af-ipv6] peer 101::2 reflect-client

[RouterC-bgp-af-ipv6] peer 102::2 reflect-client
Use the display bgp ipv6 routing-table command on Router B and Router D
respectively, you can find both of them have learned the network 1::/64.
6PE Configuration Network requirements

■ Routers PE 1 and PE 2 support 6PE;
■ Routers CE 1 and CE 2 support IPv6;
■ Between the PE routers is the IPv4/MPLS network of an ISP. The two PEs
establish an IPv4 IBGP connection in between, and the IGP used is OSPF.
■ The CEs reside in IPv6 networks. A CE and a PE use IPv6 link-local addresses to
exchange routing information via a static route;

■ Connect the two IPv6 networks through the IPv4/MPLS network with the 6PE
feature.
Network diagram
Figure 306 Network diagram for 6PE configuration
Loop 0 Loop 0
2.2.2.2/32 3.3.3.3/32
2::2 /128 3::3/128
S 2/1 S2/1
1 .1.1.1/16 1 .1.1.2/16
S2/0 IBGP S 2/0

PE 1 PE 2
Loop 0 Loop 0
1::1/128 IPv4/MPLS network 4::4 /128
S2 /0 S2 /0
CE 1 CE 2

1 Configure CE 1
# Enable IPv6 packet forwarding.
<CE1> system-view
[CE1] ipv6
# Specify IP addresses for interfaces.
[CE1] interface serial 2/0

[CE1-Serial2/0] ipv6 address auto link-local
[CE1-Serial2/0] quit
[CE1] interface loopback0
[CE1-LoopBack0] ipv6 address 1::1/128
[CE1-LoopBack0] quit
# Configure an IPv6 static route to PE 1.
[CE1] ipv6 route-static :: 0 serial2/0

2 Configure PE 1
# Enable IPv6 packet forwarding, MPLS and LDP.
<PE1> system-view
[PE1] ipv6
[PE1] mpls lsr-id 2.2.2.2
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit

# Configure an IPv6 link-local address for Serial2/0.
[PE1] interface serial 2/0

[PE1-Serial2/0] ipv6 address auto link-local
[PE1-Serial2/0] quit
# Configure an IP address for Serial2/1 and enable MPLS and LDP.

[PE1-Serial2/1] ip address 1.1.1.1 16
[PE1-Serial2/1] mpls
[PE1-Serial2/1] mpls ldp
# Configure IP addresses for Loopback0.
[PE1] interface loopback 0

[PE1-LoopBack0] ip address 2.2.2.2 32
[PE1-LoopBack0] ipv6 address 2::2/128
[PE1-LoopBack0] quit
# Configure IBGP, enable the peer’s 6PE capabilities, and redistribute IPv6 direct
and static routes.
[PE1] bgp 65100

[PE1-bgp] peer 3.3.3.3 as-number 65100
[PE1-bgp] peer 3.3.3.3 connect-interface loopback 0
[PE1-bgp] ipv6-family
[PE1-bgp-af-ipv6] import-route direct
[PE1-bgp-af-ipv6] import-route static
[PE1-bgp-af-ipv6] peer 3.3.3.3 enable
[PE1-bgp-af-ipv6] peer 3.3.3.3 label-route-capability
[PE1-bgp-af-ipv6] quit
[PE1-bgp] quit
# Configure the static route to CE 1.
[PE1] ipv6 route-static 1::1 128 serial2/0
# Configure OSPF for LSP establishment.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
[PE1]
3 Configure PE 2
<PE2> system-view
[PE2] ipv6
[PE2] mpls lsr-id 3.3.3.3
[PE2] mpls
[PE2-mpls] lsp-trigger all
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit


[PE2-Serial2/1] ip address 1.1.1.2 16
[PE2-Serial2/1] mpls
[PE2-Serial2/1] mpls ldp
[PE2-Serial2/0] ipv6 address auto link-local
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 3.3.3.3 32
[PE2-LoopBack0] ipv6 address 3::3/128
[PE2-LoopBack0] quit
# Configure IBGP, enable the peer’s 6PE capabilities, and redistribute IPv6 direct
and static routes.
[PE2] bgp 65100

[PE2-bgp] peer 2.2.2.2 as-number 65100
[PE2-bgp] peer 2.2.2.2 connect-interface loopback 0
[PE2-bgp] ipv6-family
[PE2-bgp-af-ipv6] import-route direct
[PE2-bgp-af-ipv6] import-route static
[PE2-bgp-af-ipv6] peer 2.2.2.2 enable
[PE2-bgp-af-ipv6] peer 2.2.2.2 label-route-capability
[PE2-bgp-af-ipv6] quit
[PE2-bgp] quit
# Configure the static route to CE 2.
[PE1] ipv6 route-static 4::4 128 serial2/0
# Configure OSPF for LSP establishment.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
[PE1]
4 Configure CE 2
# Enable IPv6 packet forwarding and specify IP addresses for interfaces.
<CE2> system-view
[CE2] ipv6
[CE2] interface serial 2/0
[CE2-Serial2/0] ipv6 address auto link-local
[CE2-Serial2/0] quit
[CE2] interface loopback 0
[CE2-LoopBack0] ipv6 address 4::4/128
[CE2-LoopBack0] quit
# Configure the static route to PE 2.
[CE2] ipv6 route-static :: 0 serial2/0

Troubleshooting IPv6 BGP Configuration 1041
Verify the configuration

# Display MPLS LSP information on PE 1.
<PE1> display mpls lsp
--------------------------------------------------------------
LSP Information: BGP IPV6 LSP
--------------------------------------------------------------
FEC : 1::1/128
In Label : 1024 Out Label : -----
In Interface : ----- OutInterface : -----
Vrf Name :
FEC : 2::2/128
In Label : 1025 Out Label : -----
In Interface : ----- OutInterface : -----
Vrf Name :
---------------------------------------------------------------
LSP Information: LDP LSP
---------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
3.3.3.3/32 NULL/3 -/S1
2.2.2.2/32 3/NULL S1/-
# Display the IPv6 BGP routing table on PE 1.
<PE1> display bgp ipv6 routing-table

h - history, i - internal, s - suppressed
*> Network : 1::1 PrefixLen : 128

NextHop : FE80::E142:0:4607:1 LocPrf :
Path : ? MED : 0
PrefVal : 0
*> Network : 2::2 PrefixLen : 128

NextHop : ::1 LocPrf :
Path : ? MED : 0
PrefVal : 0
*>i Network : 3::3 PrefixLen : 128

NextHop : 3.3.3.3 LocPrf : 100
Path : ? MED : 0
PrefVal : 0
*>i Network : 4::4 PrefixLen : 128

NextHop : 3.3.3.3 LocPrf : 100
Path : ? MED : 0
PrefVal : 0
After the above configuration, you can ping through the IPv6 address 4::4 of CE 2
from CE 1.
Troubleshooting IPv6
BGP Configuration
No IPv6 BGP Peer Symptom

Relationship Established Display BGP peer information using the display bgp ipv6 peer command. The
state of the connection to the peer cannot become established.

Analysis
To become IPv6 BGP peers, any two routers need to establish a TCP session using
port 179 and exchange open messages successfully.
Processing steps
1 Use the display current-configuration command to verify the peer’s AS number.
2 Use the display bgp ipv6 peer command to verify the peer’s IPv6 address.
3 If the loopback interface is used, check whether the peer connect-interface
4 If the peer is not directly connected, check whether the peer ebgp-max-hop
5 Check whether a route to the peer is available in the routing table.
6 Use the ping command to check connectivity.
7 Use the display tcp ipv6 status command to check the TCP connection.
8 Check whether an ACL for disabling TCP port 179 is configured.

IPV6 IS-IS CONFIGURATION
63
When configuring IPv6 IS-IS, go to these sections for information you are
interested in:
■ “Introduction to IPv6 IS-IS” on page 1043
■ “Configuring IPv6 IS-IS Basic Functions” on page 1043
■ “Configuring IPv6 IS-IS Routing Information Control” on page 1044
■ “Displaying and Maintaining IPv6 IS-IS” on page 1045
■ “IPv6 IS-IS Configuration Example” on page 1046
Introduction to IPv6 The IS-IS routing protocol (Intermediate System-to-Intermediate System

IS-IS intra-domain routing information exchange protocol) supports multiple network
protocols, including IPv6. IS-IS with IPv6 support is called IPv6 IS-IS dynamic
routing protocol. The International Engineer Task Force (IETF) defines two
Type-Length-Values (TLVs) and a new Network Layer Protocol Identifier (NLPID) to
enable IPv6 support for IS-IS.
TLV is a variable field in the Link State PDU or Link State Packet (LSP). The two TLVs
are:
■ IPv6 Reachability: Defines the prefix, metric of routing information to indicate

the network reachability, with a type value of 236 (0xEC).
■ IPv6 Interface Address: Similar with the “IP Interface Address” TLV of IPv4, it
transforms the 32-bit IPv4 address to the 128-bit IPv6 address.
NLPID is an 8-bit field with a value of 142 (0x8E), which indicates the network
layer protocol packet. If the IS-IS router supports IPv6, the advertised routing
information must be marked with the NLPID.
For information about IS-IS, refer to “IS-IS Configuration” on page 877.
Configuring IPv6 IS-IS

Basic Functions
n You can implement IPv6 inter-networking through configuring IPv6 IS-IS in IPv6
network environment.

Prerequisites ■ Enable IPv6 globally
■ Configure IP addresses for interfaces, and make sure all neighboring nodes are
reachable.

1044 CHAPTER 63: IPV6 IS-IS CONFIGURATION
■ Enable IS-IS
Configuration Procedure Follow these steps to configure the basic functions of IPv6 IS-IS:
To do... Use command to... Remarks

Enable an IS-IS process and isis [ process-id ] Required
enter IS-IS view [ vpn-instance
vpn-instance-name ]
Configure the network entity network-entity net Required
title for the IS-IS process
Enable IPv6 for the IS-IS ipv6 enable Required
process
Disabled by default
interface-number
Enable IPv6 for an IS-IS isis ipv6 enable [ process-id ] Required
process on the interface
Disabled by default
Configuring IPv6 IS-IS

Routing Information
Control
Configuration You need to complete the IPv6 IS-IS basic function configuration before
Prerequisites configuring this task.
Configuration Procedure Follow these steps to configure IPv6 IS-IS routing information control:

vpn-instance-name ]
Define the priority for ipv6 preference { route-policy Optional
IPv6 IS-IS routes route-policy-name | preference } *
15 by default
Configure an IPv6 ipv6 summary ipv6-prefix prefix-length Optional
IS-IS summary route [ avoid-feedback | generate_null0_route
Not configured by
| [ level-1 | level-1-2 | level-2 ] | tag tag ] *
default
Generate an IPv6 ipv6 default-route-advertise [ [ level-1 | Optional
IS-IS default route level-2 | level-1-2 ] | route-policy
No IPv6 default route is
defined by default.
Configure IPv6 IS-IS ipv6 filter-policy { acl6-number | Optional
to filter incoming ipv6-prefix ipv6-prefix-name | route-policy
No filtering policy is
routes route-policy-name } import
defined by default
Configure IPv6 IS-IS ipv6 import-route protocol [ process-id ] Optional
to redistribute routes [ allow-ibgp ] [ cost cost-value | [ level-1 |
Not configured by
from another routing level-2 | level-1-2 ] | route-policy
default
protocol route-policy-name | tag tag-value ] *

Displaying and Maintaining IPv6 IS-IS 1045

Configure a filter ipv6 filter-policy { acl6-number | Optional
policy to filter ipv6-prefix ipv6-prefix-name | route-policy
Not configured by
redistributed routes route-policy-name } export [ protocol
default
[ process-id ] ]
Enable route leaking ipv6 import-route isisv6 level-2 into Optional
level-1 [ filter-policy { acl6-number |
ipv6-prefix ipv6-prefix-name | route-policy
route-policy-name } | tag tag ]*
Specify the maximum ipv6 maximum load-balancing number Optional
number of equal-cost
n ■ The ipv6 filter-policy export command, usually used in combination with the
ipv6 import-route command, filters redistributed routes when advertising
them to other routers. If no protocol is specified, routes redistributed from all
routing protocol are filtered before advertisement. If a protocol is specified,
only routes redistributed from the routing protocol are filtered for
advertisement.
■ For information about ACL, refer to “Configuring ACLs” on page 1881.
■ For information about routing policy and IPv6 prefix list, refer to “Routing
Policy Configuration” on page 991.
Displaying and
Maintaining IPv6 IS-IS To do... Use the command... Remarks
Display brief IPv6 IS-IS display isis brief Available in any view
information
Display the status of the display isis debug-switches Available in any view
debug switches { process-id | vpn-instance
vpn-instance-name }
Display IS-IS enabled interface display isis interface [ verbose ] Available in any view
vpn-instance-name ]
Display IS-IS license display isis license Available in any view
information
Display LSDB information display isis lsdb [ [ l1 | l2 | level-1 | Available in any view
level-2 ] | [ [ lsp-id lsp-id | lsp-name
lspname | local ] | verbose ] * ] *
vpn-instance-name ]
Display IS-IS mesh group display isis mesh-group [ process-id Available in any view
information | vpn-instance vpn-instance-name ]
Display the mapping table display isis name-table [ process-id | Available in any view
between the host name and vpn-instance vpn-instance-name ]
system ID
Display IS-IS neighbor display isis peer [ verbose ] Available in any view
vpn-instance-name]
Display IPv6 IS-IS routing display isis route ipv6 [ [ level-1 | Available in any view
information level-2 ] | verbose ] * [ process-id ]
Display SPF log information display isis spf-log [ process-id | Available in any view


Display the statistics of the display isis statistics [ level-1 | Available in any view
IS-IS process level-2 | level-1-2 ] [ process-id |
Clear all IS-IS data structure reset isis all [ process-id | Available in user view
information vpn-instance vpn-instance-name ]
Clear the IS-IS data reset isis peer system-id [ process-id | Available in user view
information of a neighbor vpn vpn-instance-name ]
IPv6 IS-IS Network requirements

Configuration As shown in Figure 307, Router A, Router B, Router C and Router D, all enabled
Example with IPv6, reside in the same autonomous system. Configure IPv6 IS-IS on the
routers to make them reachable to each other.
Router A and Router B are Level-1 routers, Router D is a Level-2 router, and Router
C is a Level-1-2 router. Router A, Router B, and Router C belong to area 10, while
Router D is in area 20.
Network diagram
Figure 307 Network diagram for IPv6 IS-IS basic configuration
Router A
L1
S 2/0
2001:1::2 /64
S 2/1 Eth1/0
S2/2 2001 :4 ::1/64
2001:1::1 /64
2001 :3::1/64
S 2/0 S 2/0
2001 :3::2 /64
2001:2::1 /64 Router D
Router C
L2
L1/L2
S2 /0 Area 20
2001 :2::2/64
Router B
Area 10
L1
2 Configure IPv6 IS-IS
[RouterA] isis 1
[RouterA-isis-1] is-level level-1
[RouterA-isis-1] ipv6 enable
[RouterA-Serial2/0] isis ipv6 enable 1

IPv6 IS-IS Configuration Example 1047
[RouterB] isis 1
[RouterB-isis-1] ipv6 enable
[RouterB-Serial2/0] isis ipv6 enable 1
[RouterC] isis 1
[RouterC-isis-1] ipv6 enable
[RouterC-Serial2/0] isis ipv6 enable 1
[RouterD] isis 1
[RouterD-isis-1] ipv6 enable
[RouterD-Serial2/0] isis ipv6 enable 1
[RouterD-Ethernet1/0] isis ipv6 enable 1


IPV6 OSPFV3 CONFIGURATION
64
When configuring OSPF, go to these sections for information you are interested in:
■ “Introduction to OSPFv3” on page 1049
■ “IPv6 OSPFv3 Configuration Task List” on page 1051
■ “Configuring OSPFv3 Basic Functions” on page 1052
■ “Configuring OSPFv3 Area Parameters” on page 1053
■ “Configuring OSPFv3 Routing Information Management” on page 1054
■ “Tuning and Optimizing an OSPFv3 Network” on page 1056
■ “Displaying and Maintaining OSPFv3” on page 1059
■ “OSPFv3 Configuration Examples” on page 1059
■ “Troubleshooting OSPFv3 Configuration” on page 1066
Introduction to
OSPFv3
OSPFv3 Overview OSPFv3 is OSPF (Open Shortest Path First) version 3 for short, supporting IPv6 and
compliant with RFC2740 (OSPF for IPv6).
Identical parts between OSPFv3 and OSPFv2:
■ 32 bits router ID and area ID

■ Packets: Hello, DD (Data Description), LSR (Link State Request), LSU (Link State
Update), LSAck (Link State Acknowledgment)
■ Mechanisms for finding neighbors and establishing adjacencies
■ Mechanisms for LSA flooding and aging
Differences between OSPFv3 and OSPFv2:
■ OSPFv3 now runs on a per-link basis, instead of on a per-IP-subnet basis.

■ OSPFv3 supports multiple instances per link.
■ OSPFv3 identifies neighbors by Router ID, while OSPFv2 by IP address.
OSPFv3 Packets OSPFv3 has also five types of packets: hello, DD, LSR, LSU, and LSAck.
The five packets have the same packet header, which different from the OSPFv2
packet header is only 16 bytes in length, has no authentication field, but is added
with an Instance ID field to support multi-instance per link.

1050 CHAPTER 64: IPV6 OSPFV3 CONFIGURATION
Figure 308 gives the OSPFv3 packet header.
Figure 308 OSPFv3 packet header
0 15 31
Version # Type Packet length
Router ID
Area ID
Checksum Instance ID 0
Major fields:
■ Version #: Version of OSPF, which is 3 for OSPFv3.

■ Type: Type of OSPF packet, from 1 to 5 are hello, DD, LSR, LSU, and LSAck
respectively.
■ Packet Length: Packet length in bytes, including header.
■ Instance ID: Instance ID for a link.
■ 0: Reserved, which must be 0.
OSPFv3 LSA Types OSPFv3 sends routing information in LSAs, which as defined in RFC2740 have the
following types:
■ Router-LSAs: Originated by all routers. This LSA describes the collected states of
the router’s interfaces to an area. Flooded throughout a single area only.
■ Network-LSAs: Originated for broadcast and NBMA networks by the
Designated Router. This LSA contains the list of routers connected to the
network. Flooded throughout a single area only.
■ Inter-Area-Prefix-LSAs: Similar to Type 3 LSA of OSPFv2, originated by ABRs
(Area Border Routers), and flooded throughout the LSA’s associated area. Each
Inter-Area-Prefix-LSA describes a route with IPv6 address prefix to a destination
outside the area, yet still inside the AS (an inter-area route).
■ Inter-Area-Router-LSAs: Similar to Type 4 LSA of OSPFv2, originated by ABRs
and flooded throughout the LSA’s associated area. Each Inter-Area-Router-LSA
describes a route to ASBR (Autonomous System Boundary Router).
■ AS-external-LSAs: Originated by ASBRs, and flooded throughout the AS
(except Stub and NSSA areas). Each AS-external-LSA describes a route to
another Autonomous System. A default route can be described by an AS
external LSA.
■ Link-LSAs: A router originates a separate Link-LSA for each attached link.
Link-LSAs have link-local flooding scope. Each Link-LSA describes the IPv6
address prefix of the link and Link-local address of the router,
■ Intra-Area-Prefix-LSAs: Each Intra-Area-Prefix-LSA contains IPv6 prefix
information on a router, stub area or transit area information, and has area
flooding scope. It was introduced because Router-LSAs and Network-LSAs
contain no address information now.
Timers of OSPFv3 Timers in OSPFv3 include:

IPv6 OSPFv3 Configuration Task List 1051
■ OSPFv3 packet timer

■ LSA delay timer
■ SPF timer
OSPFv3 packet timer

Hello packets are sent periodically between neighboring routers for finding and
maintaining neighbor relationships, or for DR/BDR election. The hello interval must
be identical on neighboring interfaces. The smaller the hello interval, the faster the
network convergence speed and the bigger the network load.
If a router receives no hello packet from a neighbor after a period, it will declare
the peer is down. The period is called dead interval.
After sending an LSA to its adjacency, a router waits for an acknowledgment from
the adjacency. If no response is received after retransmission interval elapses, the
router will send again the LSA. The retransmission interval must be longer than the
round-trip time of the LSA in between.
LSA delay time

Each LSA has an age in the local LSDB (incremented by 1 per second), but an LSA
is not aged on transmission. You need to add an LSA delay time into the age time
before transmission, which is important for low speed networks.
SPF timer
Whenever LSDB changes, SPF recalculation happens. If recalculations become so
frequent, a large amount of resources will be occupied, reducing operation
efficiency of routers. You can adjust SPF calculation interval and delay time to
protect networks from being overloaded due to frequent changes.
OSPFv3 Features ■ Basic features defined in RFC2740

Supported ■ OSPFv3 stub area
■ OSPFv3 multi-process, which enable a router to run multiple OSPFv3 processes
Related RFCs ■ RFC2740: OSPF for IPv6

■ RFC2328: OSPF Version 2
IPv6 OSPFv3 To configure OSPFv3, perform the tasks described in the following sections:
Configuration Task
List Task Description
“Configuring OSPFv3 Basic Functions” on page 1052 Required
“Configuring OSPFv3 Area Parameters” “Configuring an OSPFv3 Optional
on page 1053 Stub Area” on page
1053
“Configuring OSPFv3 Optional
Virtual Links” on page
1054

Task Description
“Configuring OSPFv3 Routing “Configuring OSPFv3 Optional
Information Management” on page Route Summarization”
1054 on page 1054
Inbound Route Filtering”
on page 1054
“Configuring Link Costs Optional
for OSPFv3 Interfaces”
on page 1055
“Configuring the Optional
Maximum Number of
OSPFv3 Load-balanced
“Configuring a Priority Optional
for OSPFv3” on page
1055
Route Redistribution” on
page 1056
“Tuning and Optimizing an OSPFv3 “Configuring OSPFv3 Optional
Network” on page 1056 Timers” on page 1056
“Configuring the DR Optional
Priority for an Interface”
on page 1057
“Ignoring MTU Check Optional
for DD Packets” on page
1057
“Disabling Interfaces Optional
from Sending OSPFv3
“Enabling the Logging Optional
on Neighbor State
Configuring OSPFv3
Basic Functions
Prerequisites ■ Make neighboring nodes accessible with each other at network layer.
■ Enable IPv6 packet forwarding
Configuring OSPFv3 To configure OSPFv3 basic functions, use the following commands:
Basic Functions
Enable OSPFv3 and enter its ospfv3 [ process-id ] Required
view
Specify a router ID router-id router-id Required
interface-number

Configuring OSPFv3 Area Parameters 1053

Enable OSPFv3 on the ospfv3 process-id area Required
interface area-id [ instance
instance-id ]
n ■ Configure an OSPFv3 process ID when enabling OSPFv3. The process ID takes

effect locally, without affecting packet exchange between routers.
■ When configuring a router ID, make sure each router has a unique ID. If a
router runs multiple OSPFv3 processes, you need to specify a router ID for each
process.
■ You need to specify a router ID manually, which is necessary to make OSPFv3
work.
Configuring OSPFv3 The stub area and virtual link support of OSPFv3 has the same principle and
Area Parameters application environments with OSPFv2.
Splitting an OSPFv3 AS into multiple areas reduces the number of LSAs on

networks and extends OSPFv3 application. For those non-backbone areas residing
on the AS boundary, you can configure them as Stub areas to further reduce the
size of routing tables on routers in these areas and the number of LSAs.
Non-backbone areas exchange routing information via the backbone area.

Therefore, the backbone and non-backbone areas, including the backbone itself
must maintain connectivity. In practice, necessary physical links may not be
available for connectivity. You can configure virtual links to address it.
Prerequisites ■ Enable IPv6 packet forwarding

■ Configure OSPFv3 basic functions
Configuring an OSPFv3 To configure an OSPFv3 stub area, use the following commands:
Stub Area
Enter OSPFv3 view ospfv3 [ process-id ] -
Enter OSPFv3 area view area area-id -
Configure the area as a stub stub [ no-summary ] Required
area
Configure the default route default-cost value Optional
cost of sending a packet to
Defaults to 1
the stub area
n ■ Configurations on the routers attached to the same area should be compatible;

otherwise, no neighbor relationships may be established between the routers.
■ You cannot delete an OSPFv3 area directly. Only when you remove all
configurations in area view and all interfaces attached to the area become
down, can the area be removed automatically.
■ All routers attached to a stub area must be configured with the stub
command. The keyword no-summary is only available on the ABR.

■ If you use the stub command with the keyword no-summary on an ABR, the
ABR distributes a default summary LSA into the area rather than generating an
AS-external-LSA or Inter-Area-Prefix-LSA. The stub area of this kind is also
known as totally stub area.
Configuring OSPFv3 You can configure virtual links to maintain connectivity between non-backbone
Virtual Links areas and the backbone, or in the backbone itself.
To configure a virtual link, use the following commands:

Create and configure a virtual vlink-peer router-id [ hello seconds | Required
link retransmit seconds | trans-delay
seconds | dead seconds | instance
instance-id ] *
n Both ends of a virtual link are ABRs that are configured with the vlink-peer
command.
Configuring OSPFv3 This section is to configure management of OSPF routing information

Routing Information advertisement and reception, and route redistribution from other protocols.
Management

Configuring OSPFv3 To configure route summarization between areas, use the following command on
Route Summarization an ABR:

Configure a summary route abr-summary ipv6-address Required
prefix-length
[ not-advertise ]
n The abr-summary command is available on ABRs only. If contiguous network

segments are available in an area, you can use the command to summarize them
into one network segment on the ABR. The ABR will advertise only the summary
route. Any LSA falling into the specified network segment will not be advertised,
reducing the LSDB size in other areas.
Configuring OSPFv3 You can configure OSPFv3 to filter routes that are computed from received LSAs
Inbound Route Filtering according to some rules.

Configuring OSPFv3 Routing Information Management 1055
To configure inbound route filtering, use the following commands:

Configure inbound route filter-policy { acl-number | Required
filtering ipv6-prefix
ipv6-prefix-name } import
n Use of the filter-policy import command can only filter routes computed by
OSPFv3. Only routes not filtered can be added into the local routing table.
Configuring Link Costs You can configure OSPFv3 link costs for interfaces to adjust routing calculation.
for OSPFv3 Interfaces
To configure the link cost for an OSPFv3 interface, use the following commands:

interface-number
Configure the cost for the ospfv3 cost value [ instance Optional
interface instance-id ]
By default, OSPFv3 computes
an interface’s cost according
to the bandwidth on it.
Configuring the If multiple routes to a destination are available, using load balancing to send IPv6
Maximum Number of packets on these routes in turn can improve link utility. To configure the maximum
OSPFv3 Load-balanced number of load-balanced routes, use the following commands:
Routes
Specify the maximum number of maximum load-balancing maximum Optional
load-balanced routes
Configuring a Priority A router may run multiple routing protocols. The system assigns a priority for each
for OSPFv3 protocol. When these routing protocols find the same route, the route found by
the protocol with the highest priority is selected.
To configure a priority for OSPFv3, use the following commands:

Enter OSPFv3 view ospfv3 [ process-id | -
Configure a priority for preference [ ase ] Optional
OSPFv3 [ route-policy
By default, the priority of OSPFv3
route-policy-name ] preference
interval routes is 10, and priority
of OSPFv3 external routes is 150.

Configuring OSPFv3 To configure OSPFv3 route redistribution, use the following commands:
Route Redistribution
Specify a default cost for default cost value Optional
redistributed routes
Defaults to 1
Redistribute routes from import-route { isisv6 process-id | Required
other protocols, including ospfv3 process-id | ripng process-id |
Not configured by
from other OSPFv3 bgp4+ [ allow-ibgp ] | direct | static }
default
processes [ cost value | type type | route-policy
Configure to filter filter-policy { acl6-number | ipv6-prefix Optional
redistributed routes ipv6-prefix-name } export [ isisv6
Not configured by
process-id | ospfv3 process-id | ripng
default
process-id | bgp4+ | direct | static ]
n ■ Using the import-route command on a router makes the router become an

ASBR.
■ Since OSPFv3 is a link state based routing protocol, it cannot directly filter LSAs
to be advertised. Therefore, you need to configure filtering redistributed routes
before advertising routes that are not filtered in LSAs into the routing domain.
■ Use of the filter-policy export command takes effect only on the local router.
However, if the import-route command is not configured, executing the
filter-policy export command does not take effect.
Tuning and This section describes configurations of OSPFv3 timers, interface DR priority, MTU
Optimizing an OSPFv3 check ignorance for DD packets, disabling interfaces from sending OSPFv3
Network packets.
OSPFv3 timers:
■ Packet timer: Specified to adjust topology convergence speed and network

load
■ LSA delay timer: Specified especially for low speed links
■ SPF timer: Specified to protect networks from being over consumed due to
frequent network changes.
For a broadcast network, you can configure DR priorities for interfaces to affect
DR/BDR election.
By disabling an interface from sending OSPFv3 packets, you can make other
routers on the network obtain no information from the interface.

Configuring OSPFv3 To configure OSPFv3 timers, use the following commands:

Timers

Tuning and Optimizing an OSPFv3 Network 1057

interface-number
Configure hello interval ospfv3 timer hello seconds Optional
[ instance instance-id ]
Defaults to 10 seconds on
P2P, broadcast interfaces
Configure dead interval ospfv3 timer dead seconds Optional
[ instance instance-id ]
Defaults to 40 seconds on
P2P, broadcast interfaces
Configure LSA ospfv3 timer retransmit Optional
retransmission interval interval [ instance instance-id ]
Defaults to 5 seconds
Configure LSA ospfv3 trans-delay seconds Optional
transmission delay [ instance instance-id ]
Defaults to 1 second
Configure SPF timer spf timers delay-interval Optional
hold-interval
By default, delay-interval is 5
seconds, and hold-interval is
10 seconds
n ■ The dead interval set on neighboring interfaces cannot be so small. Otherwise,

a neighbor is so easy to be considered as down.
■ The LSA retransmission interval cannot be so small to avoid unnecessary
retransmissions.
Configuring the DR To configure the DR priority for an interface, use the following commands:
Priority for an Interface
Configure the DR ospfv3 dr-priority priority [ instance Optional
priority instance-id ]
Defaults to 1
n The DR priority of an interface determines the interface’s qualification in DR

election. Interfaces having the priority 0 cannot become a DR or BDR.
Ignoring MTU Check for When LSAs are few in DD packets, it is unnecessary to check MTU in DD packets in
DD Packets order to improve efficiency.
To ignore MTU check for DD packets, use the following commands:

interface-number


Ignore MTU check for DD ospfv3 mtu-ignore Required
packets [ instance instance-id ]
Not ignored by default
Disabling Interfaces To disable interfaces from sending OSPFv3 packets, use the following commands:
from Sending OSPFv3
Packets To do... Use the command... Remarks
Disable interfaces from silent-interface Required
sending OSPFv3 packets { interface-type
interface-number | all }
n ■ Multiple processes can disable the same interface from sending OSPFv3
packets. Using the silent-interface command disables only the interfaces
associated with the current process rather than interfaces associated with other
processes.
■ After an OSPF interface is set to silent, direct routes of the interface can still be
advertised in Intra-Area-Prefix-LSAs via other interfaces, but other OSPFv3
packets cannot be advertised. Therefore, no neighboring relationship can be
established on the interface. This feature can enhance the adaptability of
OSPFv3 networking.
Enabling the Logging on To enable the logging on neighbor state changes, use the following commands:
Neighbor State Changes
Enable the logging on log-peer-change Required
neighbor state changes
Enabled by default

Displaying and Maintaining OSPFv3 1059
Displaying and
Maintaining OSPFv3 To do... Use the command... Remarks
Display OSPFv3 debugging display debugging ospfv3 Available in
state information any view
Display OSPFv3 process brief display ospfv3 [ process-id ]
information
Display OSPFv3 interface display ospfv3 interface [ interface-type
information interface-number | statistic ]
Display OSPFv3 LSDB display ospfv3 [ process-id ] lsdb [ [ external |
information inter-prefix | inter-router | intra-prefix | link
| network | router ] [ link-state-id ]
[ originate-router router-id ] | total ]
Display LSA statistics in display ospfv3 lsdb statistic
OSPFv3 LSDB
Display OSPFv3 neighbor display ospfv3 [ process-id ] [ area area-id ]
information peer [ [ interface-type interface-number ]
[ verbose ] | peer-router-id ]
Display OSPFv3 neighbor display ospfv3 peer statistic
statistics
Display OSPFv3 routing table display ospfv3 [ process-id ] routing
information [ ipv6-address prefix-length |
ipv6-address/prefix-length | abr-routes |
asbr-routes | all | statistics ]
Display OSPFv3 area topology display ospfv3 [ process-id ] topology [ area
information area-id ]
Display OSPFv3 virtual link display ospfv3 [ process-id ] vlink
information
Display OSPFv3 next hop display ospfv3 [ process-id ] next-hop
information
Display OSPFv3 link state display ospfv3 [ process-id ] request-list
request list information [ statistics ]
Display OSPFv3 link state display ospfv3 [ process-id ] retrans-list
retransmission list [ statistics ]
information
Display OSPFv3 statistics display ospfv3 statistic
OSPFv3 Configuration
Examples
Configuring OSPFv3 Network requirements

Areas In Figure 309, all routers run OSPFv3. The AS is split into three areas, in which,
Router B and Router C act as ABRs to forward routing information between areas.
It is required to configure Area 2 as a stub area, reducing LSAs into the area
without affecting route reachability.

Network diagram
Figure 309 OSPFv3 area configuration
OSPFv3
Router B Area 0 Router C
S2/0
2001 ::1/64
S2/0
S2/1 2001 ::2/64 S2/1
2001 :1 ::1/64 2001 :2::1/64
OSPFv3
S2/1 OSPFv3 S2/1
Area 1 2001 :2::2/64
2001 :1::2 /64 Area 2
Eth1/0
2001 :3 ::1/64 Stub
Router A Router D
2 Configure OSPFv3 basic functions
[RouterA] ipv6
[RouterA] ospfv3 1
[RouterA-ospfv3-1] router-id 1.1.1.1
[RouterA-ospfv3-1] quit
[RouterA-Ethernet1/0] ospfv3 1 area 1
[RouterA-Serial2/1] ospfv3 1 area 1
[RouterB] ipv6
[RouterB] ospfv3 1
[RouterB-ospf-1] router-id 2.2.2.2
[RouterB-Serial2/0] ospfv3 1 area 0
[RouterB-Serial2/1] ospfv3 1 area 1
[RouterC] ipv6
[RouterC] ospfv3 1
[RouterC-ospfv3-1] router-id 3.3.3.3
[RouterC-ospfv3-1] quit


[RouterC-Serial2/0] ospfv3 1 area 0
[RouterC-Serial2/1] ospfv3 1 area 2
[RouterD] ipv6
[RouterD] ospfv3 1
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD-Serial2/1] ospfv3 1 area 2
# Display OSPFv3 neighbor information on Router B.
[RouterB] display ospfv3 peer
OSPFv3 Area ID 0.0.0.0 (Process 1)

----------------------------------------------------------------------
Neighbor ID Pri State Dead Time Interface Instance ID
3.3.3.3 1 Full/Backup 00:00:34 S2/0 0

----------------------------------------------------------------------
1.1.1.1 1 Full/DR 00:00:35 S2/1 0
# Display OSPFv3 neighbor information on Router C.
[RouterC] display ospfv3 peer

----------------------------------------------------------------------
2.2.2.2 1 Full/DR 00:00:35 S2/0 0

----------------------------------------------------------------------
4.4.4.4 1 Full/Backup 00:00:36 S2/1 0
# Display OSPFv3 routing table information on Router D.
[RouterD] display ospfv3 routing
E1 - Type 1 external route, IA - Inter area route, I - Intra area route

E2 - Type 2 external route, * - Selected route
OSPFv3 Router with ID (4.4.4.4) (Process 1)

------------------------------------------------------------------------
*Destination: 2001::/64
Type : IA Cost : 2
NextHop : FE80::F40D:0:93D0:1 Interface: S2/1
*Destination: 2001:1::/64
Type : IA Cost : 3

Type : I Cost : 1
NextHop : directly-connected Interface: S2/1
Type : IA Cost : 4
3 Configure Area 2 as a stub area
[RouterD] ospfv3
[RouterD-ospfv3-1] area 2
[RouterD-ospfv3-1-area-0.0.0.2] stub
# Configure Router C, with the default route cost to the stub area being 10.
[RouterC] ospfv3
[RouterC-ospfv3-1] area 2
[RouterC-ospfv3-1-area-0.0.0.2] stub
[RouterC-ospfv3-1-area-0.0.0.2] default-cost 10
# Display OSPFv3 routing table information on Router D. You can find a default
route is added, whose cost is the cost of the directly connected route plus the
configured cost.


------------------------------------------------------------------------
*Destination: ::/0
Type : IA Cost : 11
*Destination: 2001::/64
Type : IA Cost : 2
Type : IA Cost : 3
Type : I Cost : 1
Type : IA Cost : 4
4 Configure Area 2 as a totally stub area
# Configure Router C, the ABR, to make Area 2 as a totally stub area.
[RouterC-ospfv3-1-area-0.0.0.2] stub no-summary
# Display OSPFv3 routing table information on Router D. You can find routing
entries are reduced. All non-directly connected routes are removed except the
default route.



------------------------------------------------------------------------
*Destination: ::/0
Type : IA Cost : 11
Type : I Cost : 1
Configuring OSPFv3 DR Network requirements

Election In the following figure:
■ The priority of RouterA is 100, the highest priority on the network, so it will be
the DR.
■ The priority of RouterC is 2, the second highest priority on the network, so it
will be the BDR.
■ The priority of RouterB is 0, so it cannot become the DR.
■ RouterD has the default priority 1.
Network diagram
Figure 310 Network diagram for OSPFv3 DR election configuration
Router A Router B
Eth1/0 Eth1/0
2001 ::1/64 2001 ::2/64
Eth1/0 Eth1/0
2001 ::3/64 2001::4/64
Router C Router D
2 Configure OSPFv3 basic functions
[RouterA] ipv6
[RouterA] ospfv3
[RouterA-ospfv3-1] router-id 1.1.1.1
[RouterA-ospfv3-1] quit

[RouterA-Ethernet1/0] ospfv3 1 area 0

[RouterB] ipv6
[RouterB] ospfv3
[RouterB-ospfv3-1] router-id 2.2.2.2
[RouterB-ospfv3-1] quit
[RouterB-Ethernet1/0] ospfv3 1 area 0
[RouterC] ipv6
[RouterC] ospfv3
[RouterC-ospfv3-1] router-id 3.3.3.3
[RouterC-ospfv3-1] quit
[RouterC-Ethernet1/0] ospfv3 1 area 0
[RouterD] ipv6
[RouterD] ospfv3
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD-Ethernet1/0] ospfv3 1 area 0
# Display neighbor information on Router A. You can find routers have the same
default DR priority 1. In this case, the router with the highest Router ID is elected
as the DR, so Router D is the DR, Router C is the BDR.
[RouterA] display ospfv3 peer

----------------------------------------------------------------------
2.2.2.2 1 2-Way/DROther 00:00:36 Eth1/0 0
3.3.3.3 1 Full/Backup 00:00:35 Eth1/0 0
4.4.4.4 1 Full/DR 00:00:33 Eth1/0 0
# Display neighbor information on Router D. You can find neighbor states

between Router D and other routers are all full.
[RouterD] display ospfv3 peer

----------------------------------------------------------------------
1.1.1.1 1 Full/DROther 00:00:30 Eth1/0 0
2.2.2.2 1 Full/DROther 00:00:37 Eth1/0 0
3.3.3.3 1 Full/Backup 00:00:31 Eth1/0 0
3 Configure DR priorities for interfaces.

# Configure the DR priority of Router A as 100.

[RouterA-Ethernet1/0] ospfv3 dr-priority 100
# Configure the DR priority of Ethernet 1/0 as 0 on Router B.

[RouterB-Ethernet1/0] ospfv3 dr-priority 0
# Configure the DR priority of Ethernet 1/0 as 2 on Router C.

[RouterC-Ethernet1/0] ospfv3 dr-priority 2
# Display neighbor information on Router A. You can find DR priorities have been
updated, but DR and BDR are not changed.

----------------------------------------------------------------------
2.2.2.2 0 2-Way/DROther 00:00:38 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:32 Eth1/0 0
4.4.4.4 1 Full/DR 00:00:36 Eth1/0 0
# Display neighbor information on Router D. You can find Router D is still the DR.

----------------------------------------------------------------------
1.1.1.1 100 Full/DROther 00:00:33 Eth1/0 0
2.2.2.2 0 Full/DROther 00:00:36 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:40 Eth1/0 0
4 Restart DR/BDR election
# Use the shutdown and undo shutdown commands on interfaces to restart

DR/BDR election (omitted).
# Display neighbor information on Router A. You can find Router C becomes the
BDR.

----------------------------------------------------------------------
2.2.2.2 0 Full/DROther 00:00:31 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:39 Eth1/0 0
4.4.4.4 1 Full/DROther 00:00:37 Eth1/0 0
# Display neighbor information on Router D. You can find Router A becomes the
DR.

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

1.1.1.1 100 Full/DR 00:00:34 Eth1/0 0

2.2.2.2 0 2-Way/DROther 00:00:34 Eth1/0 0
3.3.3.3 2 Full/Backup 00:00:32 Eth1/0 0
Troubleshooting
OSPFv3 Configuration
No OSPFv3 Neighbor Symptom

Relationship Established No OSPF neighbor relationship can be established.
Analysis
If the physical link and lower protocol work well, check OSPF parameters
configured on interfaces. The two neighboring interfaces must have the same
parameters, such as the area ID, network segment and mask, network type. If the
network type is broadcast, at least one interface must have a DR priority higher
than 0.
Process steps
1 Display neighbor information using the display ospfv3 peer command.
2 Display OSPFv3 interface information using the display ospfv3 interface
command.
3 Ping the neighbor router’s IP address to check connectivity.
4 Check OSPF timers. The dead interval on an interface must be at least four times
the hello interval.
5 On a broadcast network, at least one interface must have a DR priority higher than
0.
Incorrect Routing Symptom

Information OSPFv3 cannot find routes to other areas.
Analysis
The backbone area must maintain connectivity to all other areas. If a router
connects to more than one area, at least one area must be connected to the
backbone. The backbone cannot be configured as a Stub area.
In a Stub area, all routers cannot receive external routes, and all interfaces
connected to the Stub area must be associated with the Stub area.
Process steps
1 Use the display ospfv3 peer command to display OSPFv3 neighbors.
2 Use the display ospfv3 interface command to display OSPFv3 interface
information.
3 Use the display ospfv3 lsdb command to display Link State Database
information to check integrity.
4 Display information about area configuration using the display
current-configuration configuration command. If more than two areas are
configured, at least one area is connected to the backbone.

Troubleshooting OSPFv3 Configuration 1067
5 In a Stub area, all routers are configured with the stub command.
6 If a virtual link is configured, use the display ospf vlink command to check the
neighbor state.


IPV6 RIPNG CONFIGURATION
65
When configuring RIPng, go to these sections for information you are interested
in:
■ “Introduction to RIPng” on page 1069
■ “Configuring RIPng Basic Functions” on page 1071
■ “Configuring RIPng Advanced Functions” on page 1072
■ “Optimizing the RIPng Network” on page 1074
■ “Displaying and Maintaining RIPng” on page 1076
■ “RIPng Configuration Example” on page 1077
Introduction to RIPng RIP next generation (RIPng) is an extension of RIP-2 for IPv4. Most RIP concepts are
applicable in RIPng.
RIPng for IPv6 made the following changes to RIP:
■ UDP port number: RIPng uses UDP port 521 for sending and receiving routing
information.
■ Multicast address: RIPng uses FF02:9 as the link-local multicast address.
■ Destination Prefix: 128-bit destination address prefix.
■ Next hop: IPv6 address in 128-bit.
■ Source address: RIPng uses FE80::/10 as the link-local source address
RIPng Working RIPng is a routing protocol based on the distance vector (D-V) algorithm. RIPng
Mechanism uses UDP packets to exchange routing information through port 521.
RIPng uses a hop count to measure the distance to a destination. The hop count is
referred to as metric or cost. The hop count from a router to a directly connected
network is 0. The hop count between two directly connected routers is 1. When
the hop count is greater than or equal to 16, the destination network or host is
unreachable.
By default, the routing update is sent every 30 seconds. If the router receives no
routing updates from a neighbor after 180 seconds, the routes learned from the
neighbor are considered as unreachable. After another 240 seconds, if no routing
update is received, the router will remove these routes from the routing table.
RIPng supports Split Horizon and Poison Reverse to prevent routing loops, and
route redistribution.

1070 CHAPTER 65: IPV6 RIPNG CONFIGURATION
Each RIPng router maintains a routing database, including route entries of all
reachable destinations. A route entry contains the following information:
■ Destination address: IPv6 address of a host or a network.

■ Next hop address: IPv6 address of a neighbor along the path to the destination.
■ Egress interface: Outbound interface that forwards IPv6 packets.
■ Metric: Cost from the local router to the destination.
■ Route time: Time that elapsed since a route entry is last changed. Each time a
route entry is modified, the routing time is set to 0.
■ Route tag: Identifies the route, used in routing policy to control routing
information. For information about routing policy, refer to “Routing Policy
RIPng Packet Format Basic format

A RIPng packet consists of a header and multiple Route Table Entries (RTEs). The
maximum number of RTEs in a packet depends on the MTU of the sending
interface.
Figure 311 shows the packet format of RIPng.
Figure 311 RIPng basic packet format
0 7 15 31
Command Version Must be zero
Route table entry 1 (20 octets)
Ă
Route table entry n (20 octets)
■ Command: Type of message. 0x01 indicates Request, 0x02 indicates Response.

■ Version: Version of RIPng. It can only be 0x01 currently.
■ RTE: Route table entry, 20 bytes for each entry.
RTE format
There are two types of RTE in RIPng.
■ Next hop RTE: Defines the IPv6 address of a next hop
■ IPv6 prefix RTE: Describes the destination IPv6 address, route tag, prefix length
and metric in the RIPng routing table.
Figure 312 shows the format of the next hop RTE:
Figure 312 Next hop RTE format
0 7 15 31
IPv6 next hop address (16 octets)
Must be zero Must be zero 0xFF

Configuring RIPng Basic Functions 1071
IPv6 next hop address is the IPv6 address of the next hop.
Figure 313 shows the format of the IPv6 prefix RTE.
Figure 313 IPv6 prefix RTE format
0 7 15 31
IPv6 prefix (16 octets)
Route tag Prefix length Metric
■ IPv6 prefix: Destination IPv6 address prefix.

■ Route tag: Route tag.
■ Prefix len: Length of the IPv6 address prefix.
■ Metric: Cost of a route.
RIPng Packet Processing Request packet

Procedure When a RIPng router first starts or needs to update some entries in its routing
table, generally a multicast request packet is sent to ask for needed routes from
neighbors.
The receiving RIPng router processes RTEs in the request. If there is only one RTE
with the IPv6 prefix and prefix length both being 0, and with a metric value of 16,
the RIPng router will respond with the entire routing table information in response
messages. If there are multiple RTEs in the request message, the RIPng router will
examine each RTE, update its metric, and send the requested routing information
to the requesting router in the response packet.
Response packet
The response packet containing the local routing table information is generated
as:
■ A response to a request
■ An update periodically
■ A trigged update caused by route change
After receiving a response, a router checks the validity of the response before
adding the route to its routing table, such as whether the source IPv6 address is
the link-local address, whether the port number is correct. The response packet
failed the check will be discarded.
Protocols and Standards ■ RFC2080: RIPng for IPv6

■ RFC2081: RIPng Protocol Applicability Statement
■ RFC2453: RIP Version 2
Configuring RIPng In this section, you are presented with the information to configure the basic
Basic Functions RIPng features.

You need to enable RIPng first before configuring other tasks, but it is not
necessary for RIPng related interface configurations, such as assigning an IPv6
address.

Prerequisites ■ Enable IPv6 packet forwarding.
■ Configure an IP address for each interface, and make sure all nodes are
reachable.
Configuration Procedure Follow these steps to configure the basic RIPng functions:

Create a RIPng process and ripng [ process-id ] Required
enter RIPng view
interface-number
Enable RIPng on the interface ripng process-id enable Required
Disabled by default
n If RIPng is not enabled on an interface, the interface will not send and receive any
RIPng route.
Configuring RIPng This section covers the following topics:

Advanced Functions ■ Configuring an Additional Routing Metric
■ Configuring RIPng Route Summarization
■ Advertising a Default Route
■ Configuring a RIPng Route Filtering Policy
■ Configuring a RIPng Priority
■ Configuring RIPng Route Redistribution
Before the configuration, accomplish the following tasks first:
■ Configure an IPv6 address on each interface, and make sure all nodes are
reachable.
■ Configure RIPng basic functions
■ Define an IPv6 ACL before using it for route filtering. Refer to “Configuring
ACLs” on page 1881 for related information.
■ Define an IPv6 address prefix list before using it for route filtering. Refer to
“Routing Policy Configuration” on page 991 for related information.
Configuring an An additional routing metric can be added to the metric of an inbound or

Additional Routing outbound RIP route, namely, the inbound and outbound additional metric.
Metric

Configuring RIPng Advanced Functions 1073
The outbound additional metric is added to the metric of a sent route, the route’s
metric in the routing table is not changed.
The inbound additional metric is added to the metric of a received route before
the route is added into the routing table, so the route’s metric is changed.
Follow these steps to configure an inbound/outbound additional routing metric:

interface-number
Specify an inbound additional ripng metricin value Optional
metric
0 by default
Specify an outbound ripng metricout value Optional
additional metric
1 by default
Configuring RIPng Route Follow these steps to configure RIPng route summarization:
Summarization
interface-number
Advertise a summary IPv6 ripng summary-address ipv6-address Required
prefix prefix-length
Advertising a Default Follow these steps to advertise a default route:

Route
interface-number
Advertise a default route ripng default-route { only | Required
originate } [ cost cost ]
n With this feature enabled, a default route is advertised via the specified interface
regardless of whether the default route is available in the local IPv6 routing table.
Configuring a RIPng You can reference a configured IPv6 ACL or prefix list to filter received/advertised
Route Filtering Policy routing information as needed. For filtering outbound routes, you can also specify
a routing protocol from which to filter routing information redistributed.
Follow these steps to configure a RIPng route filtering policy:

Enter RIPng view ripng [ process-id ] --


Configure a filter policy filter-policy { acl6-number | Required
to filter incoming routes ipv6-prefix ipv6-prefix-name }
By default, RIPng does not
import
filter incoming routing
information.
Configure a filter policy filter-policy { acl6-number | Required
to filter outgoing routes ipv6-prefix ipv6-prefix-name }
export [ protocol [ process-id ] ]
filter outgoing routing
information.
Configuring the RIPng Any routing protocol has its own protocol priority used for optimal route selection.
Priority You can set a priority for RIPng manually. The smaller the value is, the higher the
priority is.
Follow these steps to configure a RIPng priority:

Enter RIPng view ripng [ process-id ] -
Configure a RIPng preference [ route-policy Optional
priority route-policy-name ] preference
By default, the RIPng priority
is 100.
Configuring RIPng Route Follow these steps to configure RIPng route redistribution:
Redistribution
Configure a default routing default cost cost Optional
metric for redistributed routes
By default, the default metric
of redistribute routes is 0.
Redistribute routes from import-route protocol Required
another routing protocol [ process-id ] [ allow-ibgp ]
[ cost cost | route-policy
redistribute any other
protocol route.
Optimizing the RIPng This section describes how to adjust and optimize the performance of the RIPng
Network network as well as applications under special network environments. Before
adjusting and optimizing the RIPng network, complete the following tasks:
■ Configure a network layer address for each interface
■ Configure the basic RIPng functions
This section covers the following topics:
■ Configuring RIPng Timers

■ Configuring the Split Horizon and Poison Reverse
■ Configuring Zero Field Check

Optimizing the RIPng Network 1075
■ Configuring the Maximum Number of Load Balanced Routes
Configuring RIPng You can adjust RIPng timers to optimize the performance of the RIPng network.
Timers
Follow these steps to configure RIPng timers:

Enter RIPng view ripng [ process-id ] -
Configure RIPng timers timers { garbage-collect Optional.
garbage-collect-value |
The RIPng timers have the following
suppress suppress-value |
defaults:
timeout timeout-value |
update update-value } * ■ 30 seconds for the update timer
■ 180 seconds for the timeout
timer
■ 120 seconds for the suppress
timer
■ 120 seconds for the
garbage-collect timer
n When adjusting RIPng timers, you should consider the network performance and
perform unified configurations on routers running RIPng to avoid unnecessary
network traffic increase or route oscillation.
Configuring the Split

Horizon and Poison
Reverse
n If both the split horizon and poison reverse are configured, only the poison reverse
function takes effect.
Configure the split horizon

The split horizon function disables a route learned from an interface from being
advertised via the interface to prevent routing loops between neighbors.
Follow these steps to configure the split horizon:

interface-number
Enable the split horizon ripng split-horizon Optional
function
Enabled by default
n ■ Generally, you are recommended to enable the split horizon to prevent routing
loops.
■ In Frame Relay, X.25 and other non-broadcast multi-access (NBMA) networks,
split horizon should be disabled if multiple VCs are configured on the primary
interface and secondary interfaces to ensure route advertisement. For detailed

information, refer to “Frame Relay Configuration” on page 235 and “X.25 and
LAPB Configuration” on page 283.
Configuring the poison reverse function

The poison reverse function enables a route learned from an interface to be
advertised via the interface. However, the metric of the route is set to 16. That is to
say, the route is unreachable.
Follow these steps to configure poison reverse:

interface-number
Enable the poison reverse ripng poison-reverse Required
function
Disabled by default
Configuring Zero Field Some fields in RIPng packet headers must be zero. These fields are called zero
Check fields. You can enable the zero field check on RIPng packets. If any such field
contains a non-zero value, the entire RIPng packet will be discarded. If you are sure
that all packets are trusty, you can disable the zero field check to save the CPU
processing time.
Follow these steps to configure RIPng zero field check:

Enable the zero field check checkzero Optional
Enabled by default
Configuring the Follow these steps to configure the maximum number of RIPng load balanced
Maximum Number of routes with equal cost:
Load Balanced Routes
Configure the maximum number of maximum load-balancing number Optional
Displaying and
Maintaining RIPng To do... Use the command... Remarks
Display configuration display ripng [ process-id ] Available in any view
information of a RIPng
process
Display routes in the RIPng display ripng process-id Available in any view
database database


Display the routing display ripng process-id Available in any view
information of a specified route
RIPng process
Display the information of a display ripng process-id Available in any view
RIPng interface interface [ interface-type
interface-number ]
RIPng Configuration Network requirements

Example As shown in Figure 314, all routers learn IPv6 routing information via RIPng.
Configure Router B to filter the route (3::/64) learnt from Router C, which means
the route will not be added to the routing table of Router B, and Router B will not
forward it to Router A.
Network diagram
Figure 314 Network diagram for RIPng configuration
Eth1/2
RIPng 4::1/64
Eth1/1
2::1/64 Eth1/0 Eth1/1 Eth1/1
1::1/64 3::1/64 5::1/64
Eth1/0 Eth1 /0
1::2/64 3 ::2/64
1 Configure the IPv6 address for each interface (Omitted)
2 Configure basic RIPng functions
[RouterA] ripng 1
[RouterA-ripng-1] quit
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterB-Ethernet1/0] ripng 1 enable
[RouterB- Ethernet1/0] quit
[RouterB] interface ethernet1/1
[RouterB- Ethernet1/1] ripng 1 enable
[RouterB- Ethernet1/1] quit

[RouterC] ripng 1
[RouterC-ripng-1] quit
[RouterC-Ethernet1/0] ripng 1 enable
# Display the routing table of Router B.
[RouterB] display ripng 1 route

----------------------------------------------------------------
Peer FE80::20F:E2FF:FE23:82F5 on Ethernet1/0

Dest 1::/64,
via FE80::20F:E2FF:FE23:82F5, cost 1, tag 0, A, 6 Sec
Dest 2::/64,
Peer FE80::20F:E2FF:FE00:100 on Ethernet1/1

Dest 3::/64,
via FE80::20F:E2FF:FE00:100, cost 1, tag 0, A, 11 Sec
Dest 4::/64,
Dest 5::/64,
3 Configure Router B to filter incoming and outgoing routes
[RouterB] acl ipv6 number 2000
[RouterB-acl6-basic-2000] rule deny source 3::/64
[RouterB-acl6-basic-2000] rule permit
[RouterB-acl6-basic-2000] quit
[RouterB] ripng 1
[RouterB-ripng-1] filter-policy 2000 import
[RouterB-ripng-1] filter-policy 2000 export
# Display routing tables of Router B and Router A.
[RouterB] display ripng 1 route

----------------------------------------------------------------
Peer FE80::20F:E2FF:FE23:82F5 on Ethernet1/0

Dest 1::/64,
Dest 2::/64,
Peer FE80::20F:E2FF:FE00:100 on Ethernet1/1
Dest 4::/64,

Dest 5::/64,
[RouterA] display ripng 1 route
----------------------------------------------------------------
Peer FE80::20F:E2FF:FE00:1235 on GigabitEthernet0/1

Dest 1::/64,
Dest 4::/64,
Dest 5::/64,


IPV6 STATIC ROUTING
66 CONFIGURATION
When configuring IPv6 Static Routing, go to these sections for information you are
interested in:
■ “Introduction to IPv6 Static Routing” on page 1081
■ “Configuring an IPv6 Static Route” on page 1081
■ “Displaying and Maintaining IPv6 Static Routes” on page 1082
■ “IPv6 Static Routing Configuration Example” on page 1082
Introduction to IPv6 Static routes are special routes that are manually configured by network
Static Routing administrators. They work well in simple networks. Configuring and using them
properly can improve the performance of networks and guarantee enough
bandwidth for important applications.
However, static routes also have shortcomings: any topology changes could result
in unavailable routes, requiring the network administrator to manually configure
and modify the static routes.
Features of IPv6 Static Similar to IPv4 static routes, IPv6 static routes work well in simple IPv6 network
Routes environments.
Their major difference lies in the destination and next hop addresses. IPv6 static
routes use IPv6 addresses whereas IPv4 static routes use IPv4 addresses. Currently,
IPv6 static routes do not support VPN instance.
Default IPv6 Route The IPv6 static route that has the destination address configured as “::/0”
(indicating a prefix length of 0) is the default IPv6 route. If the destination address
of an IPv6 packet does not match any entry in the routing table, this default route
will be used to forward the packet.
Configuring an IPv6 In small IPv6 networks, IPv6 static routes can be used to forward packets. In
Static Route comparison to dynamic routes, it helps to save network bandwidth.
Configuration ■ Configuring parameters for the related interfaces

prerequisites ■ Configuring link layer attributes for the related interfaces
■ Enabling IPv6 packet forwarding
■ Ensuring that the neighboring nodes are IPv6 reachable

1082 CHAPTER 66: IPV6 STATIC ROUTING CONFIGURATION
Configuring an IPv6
Static Route To do... Use the commands... Remarks
Enter system view System-view -
Configure an IPv6 static route ipv6 route-static ipv6-address Required
with the output interface prefix-length [ interface-type
The default
being a broadcast or NBMA interface-number ] nexthop-address
preference of IPv6
interface [ preference preference-value ]
static routes is 60.
Configure an IPv6 static route ipv6 route-static ipv6-address
with the output interface prefix-length { interface-type
being a point-to-point interface-number | nexthop-address }
interface [ preference preference-value ]
n While configuring a static route, you can configure either the output interface or
the next-hop address depending on the situations
■ If the output interface is a broadcast interface, such as an Ethernet interface, a
VLAN interface, or an NBMA interface (such as an X.25 interface or frame relay
interface), then the next hop address must be specified.
■ If the output interface is a point-to-point interface (such as a serial port), you
can specify either the output interface or the next hop address, but not both.
Displaying and
Static Routes Display IPv6 static route display ipv6 routing-table protocol static Available in any
information [ inactive | verbose ] view
Remove all IPv6 static delete ipv6 static-routes all Available in system
routes view
n Using the undo ipv6 route-static command can delete a single IPv6 static route,
while using the delete ipv6 static-routes all command deletes all IPv6 static
routes including the default route.
IPv6 Static Routing Network requirements

Configuration With IPv6 static routes configured, all hosts and routers can interact with each
Example other. The serial ports of the routers use the IPv6 local link addresses.

IPv6 Static Routing Configuration Example 1083
Network diagram
Figure 315 Network diagram for static route configuration
Host B 2::2/64
Eth1 /0
2::1/64
S2/0 S2/1
Router B
S2/0 S2/0
Eth1/0 Eth1/0
1::1/64 3::1/64
Host A 1 ::2/64 Router A Router C
Host C 3::2/64
1 Configure IPv6 addresses for all interfaces (Omitted).
2 Configure IPv6 static routes.
# Configure the default IPv6 route on Router A.
[RouterA] ipv6 route-static :: 0 serial 2/0
# Configure two IPv6 static routes on RouterB.
[RouterB] ipv6 route-static 1:: 64 serial 2/0
[RouterB] ipv6 route-static 3:: 64 serial 2/1
# Configure the default IPv6 route on Router C.
[RouterC] ipv6 route-static :: 0 serial 2/0
3 Configure the IPv6 addresses of hosts and gateways.
Configure the IPv6 addresses of all the hosts based upon the network diagram,
configure the default gateway of Host A as 1::1, that of Host B as 2::1, and that of
Host C as 3::1.
4 Display configuration information
# Display the IPv6 routing table on RouterA.
[RouterA] display ipv6 routing-table

Routing Table :
Destination : :: Protocol : Static

NextHop : FE80::510A:0:8D7:1 Preference : 60
Interface : S2/0 Cost : 0
Destination : ::1 Protocol : Direct

1084 CHAPTER 66: IPV6 STATIC ROUTING CONFIGURATION
NextHop : ::1 Preference : 0

Interface : InLoop0 Cost : 0
Destination : 1:: Protocol : Direct

NextHop : 1::1 Preference : 0
Interface : Eth1/0 Cost : 0
Destination : 1::1 Protocol : Direct

NextHop : ::1 Preference : 0
Interface : InLoop0 Cost : 0
Destination : FE80:: Protocol : Direct

NextHop : :: Preference : 0
Interface : NULL0 Cost : 0
# Check connectivity with the ping command.
[RouterA] ping ipv6 3::1

Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1
Reply from 3::1

0.00% packet loss

MULTICAST OVERVIEW
67
n This manual chiefly focuses on the IP multicast technology and device operations.
Unless otherwise stated, the term “multicast” in this document refers to IP
multicast.
Introduction to As a technique coexisting with unicast and broadcast, the multicast technique
Multicast effectively addresses the issue of point-to-multipoint data transmission. By
allowing high-efficiency point-to-multipoint data transmission over a network,
multicast greatly saves network bandwidth and reduces network load.
With the multicast technology, a network operator can easily provide new
value-added services, such as live Webcasting, Web TV, distance learning,
telemedicine, Web radio, real-time videoconferencing, and other bandwidth- and
time-critical information services.
Comparison of Unicast
Information In unicast, the information source sends a separate copy of information to each
Transmission Techniques host that needs the information, as shown in Figure 316.
Figure 316 Unicast transmission
Host A
Receiver
Host B
Source
Host C
Server
Receiver
Host D
Receiver
Packets for Host B
Packets for Host D Host E
Packets for Host E
Assume that Hosts B, D and E need this information. The information source
establishes a separate transmission channel for each of these hosts.

1086 CHAPTER 67: MULTICAST OVERVIEW
In unicast transmission, the traffic over the network is proportional to the number
of hosts that need the information. If a large number of users need the
information, the information source needs to send a copy of the same information
to each of these users. This means a tremendous pressure on the information
source and the network bandwidth.
As we can see from the information transmission process, unicast is not suitable
for batch transmission of information.
Broadcast
In broadcast, the information source sends information to all hosts on the
network, even if some hosts do not need the information, as shown in Figure 317.
Figure 317 Broadcast transmission
Host A
Receiver
Host B
Source
Host C
Server
Receiver
Host D
Receiver
Packets for all the network Host E
Assume that only Hosts B, D, and E need the information. If the information
source broadcasts the information, Hosts A and C also receive it. In addition to
information security issues, this also causes traffic flooding on the same network.
Therefore, broadcast is disadvantageous in transmitting data to specific hosts;

moreover, broadcast transmission is a significant usage of network resources.
Multicast
As discussed above, the unicast and broadcast techniques are unable to provide
point-to-multipoint data transmissions with the minimum network consumption.
The multicast technique has solved this problem. When some hosts on the
network need multicast information, the multicast source (Source in the figure)
sends only one copy of the information. Multicast distribution trees are built for
the multicast packets through multicast routing protocols, and the packets are
replicated only on nodes where the trees branch, as shown in Figure 318:

Introduction to Multicast 1087
Figure 318 Multicast transmission
Host A
Receiver
Host B
Source
Host C
Server
Receiver
Host D
Receiver
Packets for the multicast group Host E
Assume that Hosts B, D and E need the information. To receive the information
correctly, these hosts need to join a receiver set, which is known as a multicast
group. The routers on the network duplicate and forward the information based
on the distribution of the receivers in this set. Finally, the information is correctly
delivered to Hosts B, D, and E.
To sum up, multicast has the following advantages:
■ Over unicast: As multicast traffic flows to the node the farthest possible from
the source before it is replicated and distributed, an increase of the number of
hosts will not remarkably add to the network load.
■ Over broadcast: As multicast data is sent only to the receivers that need it,
multicast uses the network bandwidth reasonably and brings no waste of
network resources, and enhances network security.
Roles in Multicast The following roles are involved in multicast transmission:

■ An information sender is referred to as a Multicast Source (“Source” in
Figure 318).
■ Each receiver is a Multicast Group Member (“Receiver” in Figure 318).
■ All receivers interested in the same information form a Multicast Group.
Multicast groups are not subject to geographic restrictions.
■ A router that supports Layer 3 multicast is called multicast router or Layer 3
multicast device. In addition to providing the multicast routing function, a
multicast router can also manage multicast group members.
For a better understanding of the multicast concept, you can assimilate multicast
transmission to the transmission of TV programs, as shown in Table 43.

Table 43 An analogy between TV transmission and multicast transmission
Step TV transmission Multicast transmission

1 A TV station transmits a TV A multicast source sends multicast data
program through a channel. to a multicast group.
2 A user tunes the TV set to the A receiver joins the multicast group.
channel.
3 The user starts to watch the TV The receiver starts to receive the
program transmitted by the TV multicast data that the source sends to
station via the channel. the multicast group.
4 The user turns off the TV set or The receiver leaves the multicast group or
tunes to another channel. joins another group.
n ■ A multicast source does not necessarily belong to a multicast group. Namely, a

multicast source is not necessarily a multicast data receiver.
■ A multicast source can send data to multiple multicast groups at the same
time, and multiple multicast sources can send data to the same multicast group
at the same time.
Advantages and Advantages of multicast

Applications of Advantages of the multicast technique include:
Multicast
■ Enhanced efficiency: reduces the CPU load of information source servers and
network devices.
■ Optimal performance: reduces redundant traffic.
■ Distributive application: Enables point-to-multiple-point applications at the
price of the minimum network resources.
Applications of multicast
Applications of the multicast technique include:
■ Multimedia and streaming applications, such as Web TV, Web radio, and
real-time video/audio conferencing.
■ Communication for training and cooperative operations, such as distance
learning and telemedicine.
■ Data warehouse and financial applications (stock quotes).
■ Any other point-to-multiple-point data distribution application.
Multicast Models Based on how the receivers treat the multicast sources, there are two multicast
models:
ASM model
In the ASM model, any sender can send information to a multicast group as a
multicast source and numbers of receivers can join a multicast group identified by
a group address and obtain multicast information addressed to that multicast
group. In this model, receivers are not aware of the position of multicast sources in
advance. However, they can join or leave the multicast group at any time.

SSM model
In the practical life, users may be interested in the multicast data from only certain
multicast sources. The SSM model provides a transmission service that allows users
to specify the multicast sources they are interested in at the client side.
The radical difference between the SSM model and the ASM model is that in the
SSM model, receivers already know the locations of the multicast sources by some
other means. In addition, the SSM model uses a multicast address range that is
different from that of the ASM model, and dedicated multicast forwarding paths
are established between receivers and the specified multicast sources.
Multicast Architecture IP multicast addresses the following questions:

■ Where should the multicast source transmit information to? (multicast
addressing)
■ What receivers exist on the network? (host registration)
■ Where is the multicast source the receivers need to receive multicast data
from? (multicast source discovery)
■ How should information be transmitted to the receivers? (multicast routing)
IP multicast falls in the scope of end-to-end service. The multicast architecture

involves the following four parts:
1 Addressing mechanism: Information is sent from a multicast source to a group of

receivers through a multicast address.
2 Host registration: Receiver hosts are allowed to join and leave multicast groups
dynamically. This mechanism is the basis for group membership management.
3 Multicast routing: A multicast distribution tree (namely a forwarding path tree for
multicast data on the network) is constructed for delivering multicast data from a
multicast source to receivers.
4 Multicast applications: A software system that supports multicast applications,
such as video conferencing, must be installed on multicast sources and receiver
hosts, and the TCP/IP stack must support reception and transmission of multicast
data.
Multicast Addresses To allow communication between multicast sources and multicast group
members, network-layer multicast addresses, namely, multicast IP addresses must
be provided. In addition, a technique must be available to map multicast IP
addresses to link-layer multicast MAC addresses.
IPv4 multicast addresses

Internet Assigned Numbers Authority (IANA) assigned the Class D address space
(224.0.0.0 to 239.255.255.255) for IPv4 multicast. The specific address blocks and
usages are shown in Table 44.

Table 44 Class D IP address blocks and description
Address block Description

224.0.0.0 to Reserved permanent group addresses. The IP address 224.0.0.0 is
224.0.0.255 reserved, and other IP addresses can be used by routing protocols and
for topology searching, protocol maintenance, and so on. Common
permanent group addresses are listed in Table 45. A packet destined
for an address in this block will not be forwarded beyond the local
subnet regardless of the Time to Live (TTL) value in the IP header.
224.0.1.0 to Globally scoped group addresses. This block includes two types of
238.255.255.255 designated group addresses:
■ 232.0.0.0/8: SSM group addresses, and
■ 233.0.0.0/8: Glop group addresses; for details, see RFC 2770.
239.0.0.0 to Administratively scoped multicast addresses for ASM/SFM. These
239.255.255.255 addresses are considered to be locally rather than globally unique, and
can be reused in domains administered by different organizations
without causing conflicts. For details, refer to RFC 2365.
n ■ The membership of a group is dynamic. Hosts can join or leave multicast

groups at any time.
■ Glop" is a mechanism for assigning multicast addresses between different
autonomous systems (ASs). By filling an AS number into the middle two bytes
of 233.0.0.0, you get 255 multicast addresses for that AS.
Table 45 Some reserved multicast addresses
Address Description
224.0.0.1 All systems on this subnet, including hosts and routers
224.0.0.2 All multicast routers on this subnet
224.0.0.3 Unassigned
224.0.0.4 Distance vector multicast routing protocol (DVMRP) routers
224.0.0.5 Open shortest path first (OSPF) routers
224.0.0.6 OSPF designated routers/backup designated routers
224.0.0.7 Shared tree (ST) routers
224.0.0.8 ST hosts
224.0.0.9 Routing information protocol version 2 (RIPv2) routers
224.0.0.11 Mobile agents
224.0.0.12 Dynamic host configuration protocol (DHCP) server/relay agent
224.0.0.13 All protocol independent multicast (PIM) routers
224.0.0.14 Resource reservation protocol (RSVP) encapsulation
224.0.0.15 All core-based tree (CBT) routers
224.0.0.16 Designated subnetwork bandwidth management (SBM)
224.0.0.17 All SBMs
224.0.0.18 Virtual router redundancy protocol (VRRP)
IPv6 multicast addresses

As defined in RFC 4291, the format of an IPv6 multicast is as follows:

Figure 319 IPv6 multicast format
0 7 11 15 31
0xFF Flags Scope
Group ID (112 bits)
■ 0xFF: 8 bits, indicating that this address is an IPv6 multicast address.

■ Flags: 4 bits, of which the highest-order flag is reserved and set to 0; the
definition and usage of the second bit can be found in RFC 3956; and
definition and usage of the third bit can be found in RFC 3306; the
lowest-order bit is the Transient (T) flag. When set to 0, the T flag indicates a
permanently-assigned (well-known) multicast address assigned by IANA; when
set to 1, the T flag indicates a transient, or dynamically assigned multicast
address.
■ Scope: 4 bits, indicating the scope of the IPv6 internetwork for which the
multicast traffic is intended. Possible values of this field are given in Table 46.
■ Reserved: 80 bits, all set to 0 currently.
■ Group ID: 112 bits, identifying the multicast group. For details about this field,
refer to RFC 3306.
Table 46 Values of the Scope field
Value Meaning
0, 3, F Reserved
1 Node-local scope
2 Link-local scope
4 Admin-local scope
5 Site-local scope
6, 7, 9 through D Unassigned
8 Organization-local scope
E Global scope
Ethernet multicast MAC addresses

When a unicast IP packet is transmitted over Ethernet, the destination MAC
address is the MAC address of the receiver. When a multicast packet is transmitted
over Ethernet, however, the destination address is a multicast MAC address
because the packet is directed to a group formed by a number of receivers, rather
than to one specific receiver.
1 IPv4 multicast MAC addresses
As defined by IANA, the high-order 24 bits of an IPv4 multicast MAC address are
0x01005e, bit 25 is 0x0, and the low-order 23 bits are the low-order 23 bits of a
multicast IPv4 address. The IPv4-to-MAC mapping relation is shown in Figure 320.

Figure 320 IPv4-to-MAC address mapping
5 bits lost
XXXX X
32-bit IPv4 address 1110 XXXX XXXX XXXX XXXX XXXX XXXX XXXX
Ă 23 bits Ă
mapped
48-bit MAC address
0000 0001 0000 0000 0101 1110 0XXX XXXX XXXX XXXX XXXX XXXX
25-bit MAC address prefix
The high-order four bits of a multicast IPv4 address are 1110, indicating that this
address is a multicast address, and only 23 bits of the remaining 28 bits are
mapped to a MAC address, so five bits of the multicast IPv4 address are lost. As a
result, 32 multicast IPv4 addresses map to the same MAC address. Therefore, in
Layer 2 multicast forwarding, a device may receive some multicast data addressed
for other IPv4 multicast groups, and such redundant data needs to be filtered by
the upper layer.
2 IPv6 multicast MAC addresses
The high-order 16 bits of an IPv6 multicast MAC address are 0x3333, and the
low-order 32 bits are the low-order 32 bits of a multicast IPv6 address. Figure 321
shows an example of mapping an IPv6 multicast address, FF1E::F30E:0101, to a
MAC address.
Figure 321 An example of IPv6-to-MAC address mapping
128-bit IPv6 address
F F1 E 0000 0000 0000 0000 0000 F 30E 0101
Ă 32 bits Ă
mapped
48-bit MAC address 3333 F 30E

a 0101
16-bit MAC
address prefix
Multicast Protocols
n ■ Generally, we refer to IP multicast working at the network layer as Layer 3

multicast and the corresponding multicast protocols as Layer 3 multicast
protocols, which include IGMP/MLD, PIM/IPv6 PIM, and MSDP; we refer to IP
multicast working at the data link layer as Layer 2 multicast and the
corresponding multicast protocols as Layer 2 multicast protocols, which include
IGMP Snooping/MLD Snooping, and multicast VLAN/IPv6 multicast VLAN.
■ IGMP Snooping, IGMP, multicast VLAN, PIM and MSDP are for IPv4, MLD
Snooping, MLD, IPv6 multicast VLAN, and IPv6 PIM are for IPv6.

This section provides only general descriptions about applications and functions of
the Layer 2 and Layer 3 multicast protocols in a network. For details of these
protocols, refer to “MPLS L2VPN Configuration” on page 1425 and “MPLS L3VPN
Currently, the MSR series routers do not support IGMP Snooping, multicast VLAN,
IPv6 multicast VLAN and MLD Snooping.
Layer 3 multicast protocols

Layer 3 multicast protocols include multicast group management protocols and
multicast routing protocols. Figure 322 describes where these multicast protocols
are in a network.
Figure 322 Positions of Layer 3 multicast protocols
Receiver AS 1 Receiver AS 2
IGMP/MLD
IGMP/MLD
PIM/IPv6 PIM
PIM/IPv6 PIM
MSDP
IGMP/MLD
Source Receiver
1 Multicast management protocols
Typically, the internet group management protocol (IGMP) or multicast listener

discovery protocol (MLD) is used between hosts and Layer 3 multicast devices
directly connected with the hosts. These protocols define the mechanism of
establishing and maintaining group memberships between hosts and Layer 3
multicast devices.
2 Multicast routing protocols
A multicast routing protocol runs on Layer 3 multicast devices to establish and

maintain multicast routes and forward multicast packets correctly and efficiently.
Multicast routes constitute a loop-free data transmission path from a data source
to multiple receivers, namely, a multicast distribution tree.
In the ASM model, multicast routes come in intra-domain routes and inter-domain
routes.
■ An intra-domain multicast routing protocol is used to discover multicast

sources and build multicast distribution trees within an AS so as to deliver
multicast data to receivers. Among a variety of mature intra-domain multicast
routing protocols, protocol independent multicast (PIM) is a popular one. Based

on the forwarding mechanism, PIM comes in two modes - dense mode (often
referred to as PIM-DM) and sparse mode (often referred to as PIM-SM).
■ An inter-domain multicast routing protocol is used for delivery of multicast
information between two ASs. So far, mature solutions include multicast
source discovery protocol (MSDP).
For the SSM model, multicast routes are not divided into inter-domain routes and
intra-domain routes. Since receivers know the position of the multicast source,
channels established through PIM-SM are sufficient for multicast information
transport.
Layer 2 multicast protocols

Layer 2 multicast protocols include IGMP Snooping/MLD Snooping and multicast
VLAN/IPv6 multicast VLAN. Figure 323 shows where these protocols are in the
network.
Figure 323 Position of Layer 2 multicast protocols
Source
Multicast VLAN
/IPv6 Multicast VLAN
IGMP Snooping
/MLD Snooping
Receiver Receiver
IPv4/IPv6 multicast packets

1 IGMP Snooping/MLD Snooping
Running on Layer 2 devices, Internet Group Management Protocol Snooping

(IGMP Snooping) and Multicast Listener Discovery Snooping (MLD Snooping) are
multicast constraining mechanisms that manage and control multicast groups by
listening to and analyzing IGMP or MLD messages exchanged between the hosts
and Layer 3 multicast devices, thus effectively controlling the flooding of multicast
data in a Layer 2 network.
2 Multicast VLAN/IPv6 multicast VLAN
In the traditional multicast-on-demand mode, when users in different VLANs on a

Layer 2 device need multicast information, the upstream Layer 3 device needs to
forward a separate copy of the multicast data to each VLAN of the Layer 2 device.
With the multicast VLAN or IPv6 multicast VLAN feature enabled on the Layer 2
device, the Layer 3 multicast device needs to send only one copy of multicast to
the multicast VLAN or IPv6 multicast VLAN on the Layer 2 device. This avoids
waste of network bandwidth and extra burden on the Layer 3 device.

Multicast Packet Forwarding Mechanism 1095
Multicast Packet In a multicast model, a multicast source sends information to a host group, which
Forwarding is identified by a multicast group address in the destination address field of IP
Mechanism multicast packets. Therefore, to deliver multicast packets to receivers located in
different parts of the network, multicast routers on the forwarding path usually
need to forward multicast packets received on one incoming interface to multiple
outgoing interfaces. Compared with a unicast model, a multicast model is more
complex in the following aspects.
■ To ensure multicast packet transmission in the network, unicast routing tables
or multicast routing tables specially provided for multicast must be used as
guidance for multicast forwarding.
■ To process the same multicast information from different peers received on
different interfaces of the same device, every multicast packet is subject to a
reverse path forwarding (RPF) check on the incoming interface. The result of
the RPF check determines whether the packet will be forwarded or discarded.
The RPF check mechanism is the basis for most multicast routing protocols to
implement multicast forwarding.
n For details about the RPF mechanism, refer to “RPF Mechanism” on page 1097 or
“RPF Mechanism” on page 1209.
Multi-Instance Multi-instance multicast refers to multicast in virtual private networks (VPNs).

Multicast
Introduction to the VPN networks need to be isolated from one another and from the public network.
Multi-Instance Concept As shown in Figure 324, VPN A and VPN B separately access the public network
through PE devices.
Figure 324 Networking diagram for VPN
VPN A
CE a2
CE b2 CE b3
PE 2
VPN B VPN B
CE b1
CE a1 CE a3
PE 1 Public network PE 3
VPN A VPN A

■ The P device belongs to the public network. The CE devices belong to their
respective VPNs. Each CE device serves its own network and maintains only one
set of forwarding mechanism.
■ The PE devices interface with the public network and the VPN networks,
serving multiple networks at the same time. On each PE device, the
information for different networks must be strictly distinguished and a separate
forwarding mechanism must be maintained for each network. On a PE device,
a set of software and hardware that serves the same network forms an
instance. Multiple instances exist on a PE device at the same time, and an
instance resides on different PE devices.
Multi-Instance VPN instances are implemented by the PE devices in a VPNs network. A PE device
Application in Multicast supports the public instance and multiple VPN instances at the same time, and
runs an independent multicast service in each instance. A PE device has the
following characteristics:
■ It maintains a set of independent multicast forwarding mechanism for each
instance, including various multicast protocols, a list of PIM neighbors and a
multicast routing table per instance. Each instance searches its own forwarding
table or routing table to forward multicast data.
■ It guarantees the isolation between different VPN instances.
■ It implements information exchange and data conversion between the public
instance and VPN instances.
Multi-instance multicast is the basis of multicast over a VPNs network. With

multicast VPN, as shown in Figure 324, when a multicast source in VPN A sends a
multicast stream to a multicast group, of all possible receivers on the network for
that group, only those belong to VPN A can receive the multicast stream. The
multicast data is multicast both in VPN A and in the public network.
n ■ Only one set of unified multicast service runs on a non-PE device. It is called
public instance.
■ The configuration made in VPN instance view only takes effect on the VPN
instance interface only. An interface that does not belong to any VPN instance
is called public instance interface.
■ For more information about multicast VPN, refer to “Multicast VPN

MULTICAST ROUTING AND
68 FORWARDING CONFIGURATION
When configuring multicast routing and forwarding, go to the following sections

for information you are interested in:
■ “Multicast Routing and Forwarding Overview” on page 1097
■ “Configuration Task List” on page 1102
■ “Displaying and Maintaining Multicast Routing and Forwarding” on page 1106
■ “Configuration Examples” on page 1108
■ “Troubleshooting Multicast Routing and Forwarding” on page 1112
Multicast Routing and

Forwarding Overview
Introduction to Multicast In multicast implementations, multicast routing and forwarding are implemented
Routing and Forwarding by three types of tables:
■ Each multicast routing protocol has its own multicast routing table, such as PIM
routing table.
■ The information of different multicast routing protocols forms a general
multicast routing table.
■ The multicast forwarding table is directly used to control the forwarding of
multicast packets.
A multicast forwarding table consists of a set of (S, G) entries, each indicating the
routing information for delivering multicast data from a multicast source to a
multicast group. If a router supports multiple multicast protocols, its multicast
routing table will include routes generated by multiple protocols. The router
chooses the optimal route from the multicast routing table based on the
configured multicast routing and forwarding policy and installs the route entry
into its multicast forwarding table.
RPF Mechanism When creating multicast routing table entries, a multicast routing protocol uses
the reverse path forwarding (RPF) mechanism to ensure multicast data delivery
along the correct path.
The RPF mechanism enables routers to correctly forward multicast packets based
on the multicast route configuration. In addition, the RPF mechanism also helps
avoid data loops caused by various reasons.

1098 CHAPTER 68: MULTICAST ROUTING AND FORWARDING CONFIGURATION
Implementation of the RPF mechanism

Upon receiving a multicast packet that a multicast source S sends to a multicast
group G, the router first searches its multicast forwarding table:
1 If the corresponding (S, G) entry exists, and the interface on which the packet
actually arrived is the incoming interface in the multicast forwarding table, the
router forwards the packet to all the outgoing interfaces.
2 If the corresponding (S, G) entry exists, but the interface on which the packet
actually arrived is not the incoming interface in the multicast forwarding table, the
multicast packet is subject to an RPF check.
■ If the result of the RPF check shows that the RPF interface is the incoming
interface of the existing (S, G) entry, this means that the (S, G) entry is correct
but the packet arrived from a wrong path and is to be discarded.
■ If the result of the RPF check shows that the RPF interface is not the incoming
interface of the existing (S, G) entry, this means that the (S, G) entry is no
longer valid. The router replaces the incoming interface of the (S, G) entry with
the interface on which the packet actually arrived and forwards the packet to
all the outgoing interfaces.
3 If no corresponding (S, G) entry exists in the multicast forwarding table, the packet
is also subject to an RPF check. The router creates an (S, G) entry based on the
relevant routing information and using the RPF interface as the incoming interface,
and installs the entry into the multicast forwarding table.
■ If the interface on which the packet actually arrived is the RPF interface, the RPF
check is successful and the router forwards the packet to all the outgoing
interfaces.
■ If the interface on which the packet actually arrived is not the RPF interface, the
RPF check fails and the router discards the packet.
RPF check
The basis for an RPF check is a unicast route or a multicast static route. A unicast
routing table contains the shortest path to each destination subnet, while a
multicast static routing table lists the RPF routing information defined by the user
through static configuration. A multicast routing protocol does not independently
maintain any type of unicast route; instead, it relies on the existing unicast routing
information or multicast static routes in creating multicast routing entries.
When performing an RPF check, a router searches its unicast routing table and
multicast static routing table at the same time. The specific process is as follows:
1 The router first chooses an optimal route from the unicast routing table and
multicast static routing table:
■ The router automatically chooses an optimal unicast route by searching its
unicast routing table, using the IP address of the “packet source” as the
destination address. The outgoing interface in the corresponding routing entry
is the RPF interface and the next hop is the RPF neighbor. The router considers
the path along which the packet from the RPF neighbor arrived on the RPF
interface to be the shortest path that leads back to the source.
■ The router automatically chooses an optimal multicast static route by searching
its multicast static routing table, using the IP address of the “packet source” as

the destination address. The corresponding routing entry explicitly defines the
RPF interface and the RPF neighbor.
2 Then, the router selects one from these two optimal routes as the RPF route. The
selection is as follows:
■ If configured to use the longest match principle, the router selects the longest
match route from the two; if these two routes have the same mask, the route
selects the route with a higher priority; if the two routes have the same priority,
the router selects the multicast static route.
■ If not configured to use the longest match principle, the router selects the
route with a higher priority; if the two routes have the same priority, the router
selects the multicast static route.
n The above-mentioned “packet source” can mean different things in different

situations
■ For a packet traveling along the shortest path tree (SPT) from the multicast
source to the receivers or the source-based tree from the multicast source to
the rendezvous point (RP), “packet source” means the multicast source.
■ For a packet traveling along the rendezvous point tree (RPT) from the RP to the
receivers, “packet source” means the RP.
■ For a bootstrap message from the bootstrap router (BSR), “packet source”
means the BSR.
For details about the concepts of SPT, RPT and BSR, refer to “PIM Configuration”
on page 1161.
Assume that unicast routes exist in the network and no multicast static routes
have been configured on Router C, as shown in Figure 325. Multicast packets
travel along the SPT from the multicast source to the receivers.
Figure 325 RPF check process
Receiver
Router B
POS 5/1
POS5/0
Source
192 .168 .0.1/24 Router A
Multicast packets Receiver

POS5/0
POS 5/1
IP Routing Table on Router C
Destination/Mask Interface Router C

192.168.0.0/24 POS5/1
■ A multicast packet from Source arrives to POS5/0 of Router C, and the

corresponding forwarding entry does not exist in the multicast forwarding
table of Router C. The Router C performs an RPF check, and finds in its unicast
routing table that the outgoing interface to 192.168.0.0/24 is POS5/1. This

means that the interface on which the packet actually arrived is not the RPF
interface. The RPF check fails and the packet is discarded.
■ A multicast packet from Source arrives on POS5/1 of Router C, and the
corresponding forwarding entry does not exist in the multicast forwarding
table of Router C. The router performs an RPF check, and finds in its unicast
routing table that the outgoing interface to 192.168.0.0/24 is the interface on
which the packet actually arrived. The RPF check succeeds and the packet is
forwarded.
Multicast static route If the topology structure of a multicast network is the same as that of a unicast
network, receivers can receive multicast data via unicast routes. However, the
topology structure of a multicast network may differ from that of a unicast
network, and some routers may support only unicast but not multicast. In this
case, you can configure multicast static routes to provide multicast transmission
paths that are different from those for unicast traffic. Note the following two
points:
■ A multicast static route only affects RPF checks, instead of guiding multicast
forwarding, so it is also called an RPF static route.
■ A multicast static route is effective on the multicast router on which it is
configured, and will not be broadcast throughout the network or injected to
other routers.
A multicast static route is an important basis for RPF checks. With a multicast static
route configured on a router, the router searches the unicast routing table and the
multicast static routing table simultaneously in a RPF check, chooses the optimal
unicast RPF route and the optimal multicast static route respectively from the
routing tables, and uses one of them as the RPF route after comparison.
Figure 326 Multicast static route
Multicast Routing Table Static on Router C

Destination/Mask Interface RPF neighbor/Mask
192.168.0.0/24 POS5/0 1.1.1.1/24

Receiver
Router B
Multicast packets POS 5/1

POS 5/0
Multicast static route
1 .1.1.1/24
Source POS 5/0 Receiver

1 .1.1.2/24
POS5 /1
192 .168 .0 .1/24 Router A Router C
As shown in Figure 326, when no multicast static route is configured, Router C’s
RPF neighbor on the path back to Source is Router A and the multicast
information from Source travels along the path from Router A to Router C, which
is the unicast route between the two routers; with a static route configured on
Router C and Router B as Router C’s RPF neighbor on the path back to Source, the

multicast information from Source travels from Router A to Router B and then to
Router C.
Multicast Traceroute The multicast traceroute utility is used to trace the path that a multicast stream
passes from the multicast source to the last-hop router.
Concepts in multicast traceroute

1 Last-hop router: If a router has one of its interfaces connecting to the subnet the
given destination address is on, and if the router is able to forward multicast
streams from the given multicast source onto that subnet, that router is called
last-hop router.
2 First-hop router: the router that directly connects to the multicast source.
3 Querier: the router requesting the multicast traceroute.
Introduction to multicast traceroute packets

A multicast traceroute packet is a special IGMP packet, which differs from
common IGMP packets in that its IGMP Type field is set to 0x1F or 0x1E and that
its destination IP address is a unicast address. There are three types of multicast
traceroute packets:
■ Query, with the IGMP Type field set to 0x1F,
■ Request, with the IGMP Type field set to 0x1F, and
■ Response, with the IGMP Type field set to 0x1E.
Process of multicast traceroute

1 The querier sends a query to the last-hop router.
2 Upon receiving the query, the last-hop router turns the query packet into a request
packet by adding a response data block containing its interface addresses and
packet statistics to the end of the packet, and forwards the request packet via
unicast to the previous hop for the given multicast source and group.
3 From the last-hop router to the multicast source, each hop adds a response data
block to the end of the request packet and unicasts it to the previous hop.
4 When the first-hop router receives the request packet, it changes the packet type
to indicate a response packet, and then sends the completed packet via unicast to
the multicast traceroute querier.
Application of GRE There may be routers that do not support multicast protocols in a network. As
Tunnel in Multicast multicast traffic from a multicast source is forwarded hop by hop by multicast
Forwarding routers along the forwarding tree, when the multicast traffic is forwarded to a
next hop router that does not support IP multicast, the forwarding path is blocked.
In this case, you can enable multicast traffic forwarding across the unicast subnet
where the non-multicast-capable router resides by establishing a generic routing
encapsulation (GRE) tunnel between the routers at both ends of the unicast
subnet.
For details about GRE tunneling, refer to “GRE Configuration” on page 1589.

Figure 327 Multicast data transmission through a GRE tunnel
Multicast router Unicast router Unicast router Multicast router
GRE tunnel
Source Router A Router B Receiver
Unicast router
Unicast router
As shown in Figure 327, with a GRE tunnel established between Router A and
Router B, Router A encapsulates multicast data in unicast IP packets, which are
then forwarded by unicast routers to Router B across the GRE tunnel. Then, Router
B strips off the unicast IP header and continues forwarding the multicast data
down towards the receivers.
However, if unicast static routes are configured across the tunnel, any unicast
packet can be transmitted through the tunnel. If you wish the tunnel to be
dedicated to multicast traffic delivery, you can configure a multicast static route
across the tunnel, so that unicast packets cannot be transmitted through this
tunnel.
Configuration Task Complete these tasks to configure multicast routing and forwarding:
List
Task Remarks
“Enabling IP Multicast Routing” on page 1103 Required
“Configuring Multicast Static Routes” on page 1103 Optional
“Configuring a Multicast Routing Policy” on page 1104 Optional
“Configuring Multicast Forwarding Range” on page Optional
1104
“Configuring Multicast Forwarding Table Size” on page Optional
1105
“Tracing a Multicast Path” on page 1106 Optional
Configuring Multicast
Routing and
Forwarding
Configuration Before configuring multicast routing and forwarding, complete the following
Prerequisites tasks:
■ Configure a unicast routing protocol so that all devices in the domain are
interoperable at the network layer.
■ Enable PIM (PIM-DM or PIM-SM).
Before configuring multicast routing and forwarding, prepare the following data:

■ The minimum TTL value required for a multicast packet to be forwarded

■ The maximum number of downstream nodes for a single route in a multicast
forwarding table
■ The maximum number of routing entries in a multicast forwarding table
Enabling IP Multicast Enabling IP multicast routing in the public instance

Routing Follow these steps to enable IP multicast routing in the public instance:

Enable IP multicast routing multicast routing-enable Required
Disabled by default
Enabling IP multicast routing in a VPN instance

Follow these steps to enable IP multicast routing in a VPN instance:

Create a VPN instance and ip vpn-instance -
enter VPN instance view vpn-instance-name
Configure a route route-distinguisher Required
distinguisher (RD) for the VPN route-distinguisher
No RD is configured by
instance
default.
Disabled by default
c CAUTION: IP multicast does not support the use of secondary IP address

segments. Namely, multicast can be routed and forwarded only through primary IP
addresses, rather than secondary addresses, even if configured on interfaces.
For details about primary and secondary IP addresses, refer to “IP Addressing
n For details about the ip vpn-instance and route-distinguisher commands, refer

to “MPLS L3VPN Configuration” on page 1459.
Configuring Multicast Based on the application environment, a multicast static route has the following
Static Routes two functions:
■ Changing an RPF route. If the multicast topology structure is the same as the
unicast topology in a network, the delivery path of multicast traffic is the same
as in unicast. By configuring a multicast static route, you can change the RPF
route so as to create a transmission path that is different from the unicast
traffic transmission path.
■ Creating an RPF route. When a unicast route is interrupted, multicast traffic
forwarding is stopped due to lack of an RPF route. By configuring a multicast
static route, you can create an RPF route so that a multicast routing entry is
created to guide multicast traffic forwarding.
Follow these steps to configure a multicast static route:


Configure a multicast ip rpf-route-static [ vpn-instance Required
static route vpn-instance-name ] source-address { mask |
No multicast static
mask-length } [ protocol [ process-id ] ]
route configured
[ route-policy policy-name ] { rpf-nbr-address |
by default.
interface-type interface-number } [ preference
preference ] [ order order-number ]
c CAUTION: When configuring a multicast static route, you cannot designate an

RPF neighbor by specifying an interface (by means of the interface-type
interface-number command argument combination) if the interface type of that
router is Ethernet, GigabitEthernet, Loopback or VLAN-interface; instead, you can
designate an RPF neighbor only by specifying an address (rpf-nbr-address).
Configuring a Multicast If multiple unicast routes with the same cost exist to the same multicast source,
Routing Policy you can configure the router to determine the RPF route based on the longest
match (that is, by mask length).
With the load splitting feature enabled, multicast traffic will be evenly distributed
among the equal-cost routes.
Configuring a multicast routing policy in the public instance

Follow these steps to configure a multicast routing policy in the public instance:

Configure the device to select multicast longest-match Optional
a route based on the longest
In order of routing table
match
entries by default
Configuring multicast load multicast load-splitting Optional
splitting { source | source-group }
Disabled by default
Configuring a multicast routing policy in a VPN instance

Follow these steps to configure a multicast routing policy in a VPN instance:

Enter VPN instance view ip vpn-instance -
vpn-instance-name
Configure the device to select multicast longest-match Optional
a route based on the longest
In order of routing table
match
entries by default
Configure multicast load multicast load-splitting Optional
splitting { source | source-group }
Disabled by default
Configuring Multicast Multicast packets do not travel without a boundary in a network. The multicast
Forwarding Range data corresponding to each multicast group must be transmitted within a definite
scope. Presently, you can define a multicast forwarding range by:

■ Specifying boundary interfaces, which form a closed multicast forwarding area,

or
■ Setting the minimum time to live (TTL) value required for a multicast packet to
be forwarded.
You can configure a forwarding boundary specific to a particular multicast group

on all interfaces that support multicast forwarding. A multicast forwarding
boundary sets the boundary condition for the multicast groups in the specified
range. If the destination address of a multicast packet matches the set boundary
condition, the packet will not be forwarded. Once a multicast boundary is
configured on an interface, this interface can no longer forward multicast packets
(including packets sent from the local device) or receive multicast packets.
You can configure the minimum TTL required for a multicast packet to be
forwarded on all interfaces that support multicast forwarding. Before being
forwarded from an interface, every multicast packet (including multicast packet
from the local device) is subject to a TTL check:
■ If the TTL value of the packet (already decremented by 1 on this router) is larger
than the minimum TTL value configured on the interface, the packet will be
forwarded.
■ If the TTL value of the packet is smaller than or equal to the minimum TTL value
configured on the interface, the packet will be discarded.
Follow these steps to configure a multicast forwarding range:

interface-number
Configure a multicast multicast boundary Required
forwarding boundary group-address { mask |
No forwarding boundary by
mask-length }
default
Configure the minimum multicast minimum-ttl Optional
packet TTL required for a ttl-value
1 by default
multicast packet to be
forwarded
Configuring Multicast Too many multicast routing entries can exhaust the router’s memory and thus
Forwarding Table Size result in lower router performance. Therefore, the number of multicast routing
entries should be limited. You can set a limit on the number of entries in the
multicast routing table based on the actual networking situation and the
performance requirements. In any case, the number of route entries must not
exceed the maximum number allowed by the system.
If the configured maximum number of downstream nodes (namely, the maximum

number of outgoing interfaces) for a routing entry in the multicast forwarding
table is smaller than the current number, the downstream nodes in excess of the
configured limit will not be deleted immediately; instead they must be deleted by
the multicast routing protocol. In addition, newly added downstream nodes
cannot be installed to the routing entry in the forwarding table.

If the configured maximum number of routing entries in the multicast forwarding

table is smaller than the current number, the routes in excess of the configured
limit will not be deleted immediately; instead they must be deleted by the
multicast routing protocol. In addition, newly added route entries cannot be
installed to the forwarding table.
Configuring the multicast forwarding table size in the public instance

Follow these steps to configure the multicast forwarding table size in the public
instance:

Configure the maximum number multicast forwarding-table Optional
of downstream nodes for a single downstream-limit limit
The default is 128.
route in the multicast forwarding
table
Configure the maximum number multicast forwarding-table Optional
of routing entries in the multicast route-limit limit
The default is 256.
forwarding table
Configuring the multicast forwarding table size in a VPN instance

Follow these steps to configure the multicast forwarding table size in a VPN
instance:

Enter VPN instance view ip vpn-instance -
vpn-instance-name
Configure the maximum number of multicast forwarding-table Optional
downstream nodes for a single downstream-limit limit
The default is 128.
route in the multicast forwarding
table
Configure the maximum number of multicast forwarding-table Optional
routing entries in the multicast route-limit limit
The default is 256.
forwarding table
Tracing a Multicast Path You can run the mtracert command to trace the path down which the multicast
traffic from a given multicast source flows to the last-hop router for
troubleshooting purposes.

Trace a multicast path mtracert source-address Required
[ [ last-hop-router-address ]
group-address ]
Displaying and
Maintaining Multicast To do... Use the command... Remarks
Routing and View the multicast display multicast boundary [ vpn-instance Available in any
Forwarding boundary vpn-instance-name | all-instance ] [ group-address view
information [ mask | mask-length ] ] [ interface interface-type
interface-number ]

Displaying and Maintaining Multicast Routing and Forwarding 1107

View the multicast display multicast [ vpn-instance Available in any
forwarding table vpn-instance-name | all-instance ] view
information forwarding-table [ source-address [ mask { mask |
mask-length } ] | group-address [ mask { mask |
mask-length } ] | incoming-interface
{ interface-type interface-number | register } |
outgoing-interface { { exclude | include | match }
{ interface-type interface-number | register } } |
statistics ] * [ port-info ]
View the multicast display multicast [ vpn-instance Available in any
routing table vpn-instance-name | all-instance ] routing-table view
information [ source-address [ mask { mask | mask-length } ] |
group-address [ mask { mask | mask-length } ] |
incoming-interface { interface-type
interface-number | register } | outgoing-interface
{ { exclude | include | match } { interface-type
interface-number | register } } ] *
View the display multicast [ vpn-instance Available in any
information of the vpn-instance-name | all-instance ] routing-table view
multicast static static [ config ] [ source-address { mask-length |
routing table mask } ]
View the RPF display multicast [ vpn-instance Available in any
route information vpn-instance-name | all-instance ] rpf-info view
of the specified source-address [ group-address ]
multicast source
View the display multicast [ vpn-instance Available in any
minimum TTL vpn-instance-name | all-instance ] minimum-ttl view
required for a [ interface-type interface-number ]
multicast packet
to be forwarded
Clear forwarding reset multicast [ vpn-instance vpn-instance-name Available in user
entries from the | all-instance ] forwarding-table { { source-address view
multicast [ mask { mask | mask-length } ] | group-address
forwarding table [ mask { mask | mask-length } ] |
interface-number | register } } * | all }
Clear routing reset multicast [ vpn-instance vpn-instance-name Available in user
entries from the | all-instance ] routing-table { { source-address view
multicast routing [ mask { mask | mask-length } ] | group-address
table [ mask { mask | mask-length } ] |
interface-number | register } } * | all }
c CAUTION:
■ The reset command clears the information in the multicast routing table or the
multicast forwarding table, and thus may cause failure of multicast
transmission.
■ When a routing entry is deleted from the multicast routing table, the
corresponding forwarding entry will also be deleted from the multicast
forwarding table.
■ When a forwarding entry is deleted from the multicast forwarding table, the
corresponding route entry will also be deleted from the multicast routing table.

Configuration
Examples
Changing an RPF Route Network requirements

■ PIM-DM runs in the network. All routers in the network support multicast.
■ Router A, Router B and Router C run OSPF.
■ Typically, Receiver can receive the multicast data from Source through the path
Router A - Router B, which is the same as the unicast route.
■ Perform the following configuration so that Receiver can receive the multicast
data from Source through the path Router A - Router C - Router B, which is
different from the unicast route.
Network diagram
Figure 328 Network diagram for RPF route alteration configuration
Router C
Eth1/1 Eth1 /0
40 .1 .1.1/24 20 .1 .1.2/24
Eth1 /1 PIM-DM Eth1/1

40.1.1 .2/24 20 .1.1.1/24
Router A Router B
Eth1/2 Eth1/2
30.1.1.2/24 30.1.1.1 /24
Eth 1/0 Eth1/0
50.1.1.1 /24 10.1.1.1/24
Source Receiver
50 .1.1.100/24 10.1.1.100 /24
1 Configure interface IP addresses and enable unicast routing on each router
Configure the IP address and subnet mask for each interface as per Figure 328.
The detailed configuration steps are omitted here.
Enable OSPF on Router A, Router B and Router C. Ensure the network-layer

interoperation among the routers. Ensure that the routers can dynamically update
their routing information by leveraging the unicast routing protocol. The specific
configuration steps are omitted here.
2 Enable IP multicast routing, and enable PIM on each interface

# Enable IP multicast routing on Router B, enable PIM-DM on each interface, and

enable IGMPv2 on Ethernet 1/0.
[RouterB] multicast routing-enable
[RouterB-Ethernet1/0] igmp enable
[RouterB-Ethernet1/0] pim dm
# Enable IP multicast routing on Router A, and enable PIM-DM on each interface.
The configuration on Router C is similar to the configuration on Router A. The

specific configuration steps are omitted here.
# Use the display multicast rpf-info command to view the RPF route to Source
on Router B.
[RouterB] display multicast rpf-info 50.1.1.100

RPF information about source 50.1.1.100:
RPF interface: Ethernet1/2, RPF neighbor: 30.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: igp
Route selection rule: preference-preferred
Load splitting rule: disable
As shown above, the current RPF route on Router B is contributed by a unicast

routing protocol and the RPF neighbor is Router A.
3 Configure a multicast static route
# Configure a multicast static route on Router B, specifying Router C as its RPF

neighbor to Source.
[RouterB] ip rpf-route-static 50.1.1.100 24 20.1.1.2


# Use the display multicast rpf-info command to view the information about
the RPF route to Source on Router B.

Referenced route type: multicast static
As shown above, the RPF route on Router B has changed. It is now the configured
multicast static route, and the RPF neighbor is now Router C.
Creating an RPF Route Network requirements

■ PIM-DM runs in the network and all routers in the network support IP
multicast.
■ Router B and Router C run OSPF, and have no unicast routes to Router A.
■ Typically, Receiver can receive the multicast data from Source 1 in the OSPF
domain.
■ Perform the following configuration so that Receiver can receive multicast data
from Source 2, which is outside the OSPF domain.
Network diagram
Figure 329 Network diagram for creating an RPF route
PIM-DM
OSPF domain
Eth1 /1 Eth1/2 Eth1 /1
30 .1 .1.2/24 30 .1 .1.1/24 20.1.1 .1/24
Eth1 /1
20 .1 .1.2/24
50.1.1 .1/24 40 .1.1.1/24 10.1.1.1 /24
Source 2 Source 1 Receiver
50.1.1 .100 /24 40.1.1 .100 /24 10 .1.1.100/24
1 Configure the interface IP addresses and unicast routing protocol for each router
The detailed configuration steps are omitted here.
Enable OSPF on Router B and Router C. Ensure the network-layer interoperation

among the routers. Ensure that the routers can dynamically update their routing

information by leveraging the unicast routing protocol. The specific configuration

steps are omitted here.
2 Enable IP multicast routing, and enable PIM on each interface
# Enable IP multicast routing on Router C, enable PIM-DM on each interface, and

enable IGMPv2 on Ethernet 1/0.
[RouterC] multicast routing-enable
[RouterC-Ethernet1/0] igmp enable
[RouterC-Ethernet1/0] pim dm
# Enable IP multicast routing on Router A and enable PIM-DM on each interface.
The configuration on Router B is similar to that on Router A. The specific

configuration steps are omitted here.
# Use the display multicast rpf-info command to view the information of the
RPF route to Source 2 on Router B and Router C.

[RouterC] display multicast rpf-info 50.1.1.100
No information is displayed. This means that no RPF route to Source 2 exists on

Router B and Router C.
3 Configure a multicast static route
# Configure a multicast static route on Router B, specifying Router A as its RPF

neighbor on the route to Source 2.
[RouterB] ip rpf-route-static 50.1.1.100 24 30.1.1.2
# Configure a multicast static route on Router C, specifying Router B as its RPF

neighbor on the route to Source 2.
[RouterC] ip rpf-route-static 50.1.1.100 24 20.1.1.2

# Use the display multicast rpf-info command to view the RPF routes to Source
2 on Router B and Router C.


[RouterC] display multicast rpf-info 50.1.1.100
As shown above, the RPF routes to Source 2 exist on Router B and Router C. The
source is the configured static route.
Troubleshooting
Multicast Routing and
Forwarding
Multicast Static Route Symptom

Failure No dynamic routing protocol is enabled on the routers, and the physic status and
link layer status of interfaces are both up, but the multicast static route fails.
Analysis
■ If the multicast static route is not configured or updated correctly to match the
current network conditions, the route entry and the configuration information
of multicast static routes do not exist in the multicast routing table.
■ If the optimal route is found, the multicast static route may also fail.
Solution
1 In the configuration, you can use the display multicast routing-table static
config command to view the detailed configuration information of multicast
static routes to verify that the multicast static route has been correctly configured
and the route entry exists.
2 In the configuration, you can use the display multicast routing-table static
command to view the information of multicast static routes to verify that the
multicast static route has been correctly configured and the route entry exists in
the multicast routing table.
3 Check the next hop interface type of the multicast static route. If the interface is
not a point-to-point interface, be sure to specify the next hop address to configure
the outgoing interface when you configure the multicast static route.
4 Check that the multicast static route matches the specified routing protocol. If a
protocol was specified when the multicast static route was configured, enter the
display ip routing-table command to check if an identical route was added by
the protocol.

Troubleshooting Multicast Routing and Forwarding 1113
5 Check that the multicast static route matches the specified routing policy. If a
routing policy was specified when the multicast static route was configured, enter
the display route-policy command to check the configured routing policy.
Multicast Data Fails to Symptom

Reach Receivers The multicast data can reach some routers but fails to reach the last hop router.
Analysis
■ When a router receives a multicast packet, it decrements the TTL value of the
multicast packet by 1 and recalculates the checksum value. The router then
forwards the packet to all outgoing interfaces. If the multicast minimum-ttl
command is configured on the outgoing interfaces, the TTL value of the packet
must be larger than the configured minimum TTL value; otherwise, the packet
will be discarded.
■ If a multicast forwarding boundary has been configured through the multicast
boundary command, any multicast packet will be kept from crossing the
boundary.
Solution
1 Use the display pim routing-table command to check whether the
corresponding (S, G) entries exist on the router. If so, the router has received the
multicast data; otherwise, the router has not received the data.
2 Enter the display multicast minimum-ttl command to check the configured
minimum TTL value required for multicast packets to be forwarded. Use the undo
multicast minimum-ttl command on the concerned interfaces to restore the
required minimum TTL value to the system default, or configure multicast packets
to be sent with a higher TTL value from the multicast source.
3 Use the display multicast boundary command to view the multicast boundary
information on the interfaces. Use the multicast boundary command to change
the multicast forwarding boundary setting.
4 In the case of PIM-SM, use the display current-configuration command to
check the BSR and RP information.


IGMP CONFIGURATION
69
When configuring IGMP, go to the following sections for the information you are
interested in:
■ “IGMP Overview” on page 1115
■ “IGMP Configuration Task List” on page 1119
■ “Configuring Basic Functions of IGMP” on page 1120
■ “Adjusting IGMP Performance” on page 1123
■ “Displaying and Maintaining IGMP” on page 1127
■ “IGMP Configuration Example” on page 1127
■ “Troubleshooting IGMP” on page 1129
IGMP Overview As a TCP/IP protocol responsible for IP multicast group member management, the
Internet Group Management Protocol (IGMP) is used by IP hosts to establish and
maintain their multicast group memberships to immediately neighboring multicast
routers.
IGMP Versions So far, there are three IGMP versions:

■ IGMPv1 (documented in RFC 1112)
All IGMP versions support the Any-Source Multicast (ASM) model. In addition,
IGMPv3 can be directly used to implement the Source-Specific Multicast (SSM)
model.
n For more information about the ASM and SSM models, see “Multicast Models” on
page 1088.
Work Mechanism of IGMPv1 manages multicast group memberships mainly based on the query and
IGMPv1 response mechanism.
Of multiple multicast routers on the same subnet, all the routers can hear IGMP
membership report messages (often referred to as reports) from hosts, but only
one router is needed for sending IGMP query messages (often referred to as
queries). So, a querier election mechanism is required to determine which router
will act as the IGMP querier on the subnet.
In IGMPv1, the designated router (DR) elected by a multicast routing protocol

(such as PIM) serves as the IGMP querier.

1116 CHAPTER 69: IGMP CONFIGURATION
n For more information about DR, refer to “PIM Configuration” on page 1161.
Figure 330 Joining multicast groups
DR
Router A Router B
Ethernet

(G2) (G1) (G1)
Query
Report
Assume that Host B and Host C are expected to receive multicast data addressed
to multicast group G1, while Host A is expected to receive multicast data
addressed to G2, as shown in Figure 330. The basic process that the hosts join the
multicast groups is as follows:
1 The IGMP querier (Router B in the figure) periodically multicasts IGMP queries
(with the destination address of 224.0.0.1) to all hosts and routers on the local
subnet.
2 Upon receiving a query message, Host B or Host C (the delay timer of whichever
expires first) sends an IGMP report to the multicast group address of G1, to
announce its interest in G1. Assume it is Host B that sends the report message.
3 Host C, which is on the same subnet, hears the report from Host B for joining G1.
Upon hearing the report, Host C will suppress itself from sending a report message
for the same multicast group, because the IGMP routers (Router A and Router B)
already know that at least one host on the local subnet is interested in G1. This
mechanism, known as IGMP report suppression, helps reduce traffic over the local
subnet.
4 At the same time, because Host A is interested in G2, it sends a report to the
multicast group address of G2.
5 Through the above-mentioned query/report process, the IGMP routers learn that
members of G1 and G2 are attached to the local subnet, and generate (*, G1) and
(*, G2) multicast forwarding entries, which will be the basis for subsequent
multicast forwarding, where * represents any multicast source.
6 When the multicast data addressed to G1 or G2 reaches an IGMP router, because
the (*, G1) and (*, G2) multicast forwarding entries exist on the IGMP router, the
router forwards the multicast data to the local subnet, and then the receivers on
the subnet receive the data.

IGMP Overview 1117
As IGMPv1 does not specifically define a Leave Group mechanism, upon leaving a
multicast group, an IGMPv1 host stops sending reports with the destination
address being the address of that multicast group. If no member of a multicast
group exists on the subnet, the IGMP router will not receive any report addressed
to that multicast group, so the routers will delete the multicast forwarding entries
for that multicast group after a period of time.
Enhancements in Compared with IGMPv1, IGMPv2 has introduced a querier election mechanism
IGMPv2 and a leave-group mechanism.
Querier election mechanism

In IGMPv1, the DR elected by the Layer 3 multicast routing protocol (such as PIM)
serves as the querier among multiple routers on the same subnet.
In IGMPv2, an independent querier election mechanism is introduced. The querier

election process is as follows:
1 Initially, every IGMPv2 router assumes itself as the querier and sends IGMP general
query messages (often referred to as general queries) to all hosts and routers on
the local subnet (the destination address is 224.0.0.1).
2 Upon hearing a general query, every IGMPv2 router compares the source IP
address of the query message with its own interface address. After comparison,
the router with the lowest IP address wins the querier election and all other
IGMPv2 routers become non-queriers.
3 All the non-queriers start a timer, known as “other querier present timer”. If a
router receives an IGMP query from the querier before the timer expires, it resets
this timer; otherwise, it assumes the querier to have timed out and initiates a new
querier election process.
Leave group" mechanism

In IGMPv1, when a host leaves a multicast group, it does not send any notification
to the multicast router. The multicast router relies on host response timeout to
know whether a group no longer has members. This adds to the leave latency.
In IGMPv2, when a host leaves a multicast group:
1 This host sends a Leave Group message (often referred to as leave message) to all
routers (the destination address is 224.0.0.2) on the local subnet.
2 Upon receiving the leave message, the querier sends a configurable number of
group-specific queries to the group being left. The destination address field and
group address field of the message are both filled with the address of the
multicast group being queried.
3 Up receiving a group-specific query, one of the other members of that group, if
any, will respond with a membership report within the maximum response time
set in the query.
4 If the querier receives a membership report from any member of the group within
the maximum response time, it will maintain the memberships of the group;
otherwise, the querier will assume that the group has no longer any member on
the subnet and will stop maintaining the memberships of the group.

Enhancements in Built upon and being compatible with IGMPv1 and IGMPv2, IGMPv3 provides
IGMPv3 hosts with enhanced control capabilities and provides enhancements of query and
report messages.
Enhancements in control capability of hosts

IGMPv3 has introduced source filtering modes (Include and Exclude), so that a
host not only can join a designated multicast group but also can specify to receive
or reject multicast data from a designated multicast source. When a host joins a
multicast group:
■ If it needs to receive multicast data from specific sources like S1, S2, ..., it sends
a report with the Filter-Mode denoted as "Include Sources (S1, S2, ......).
■ If it needs to reject multicast data from specific sources like S1, S2, ..., it sends a
report with the Filter-Mode denoted as "Exclude Sources (S1, S2, ......).
As shown in Figure 331, the network comprises two multicast sources, Source 1
(S1) and Source 2 (S2), both of which can send multicast data to multicast group
G. Host B is interested only in the multicast data that Source 1 sends to G but not
in the data from Source 2.
Figure 331 Flow paths of source-and-group-specific multicast traffic
Source 1
Host A
Receiver
Host B
Source 2
Host C
Packets (S1,G)
Packets (S2,G)
In the case of IGMPv1 or IGMPv2, Host B cannot select multicast sources when it
joins multicast group G. Therefore, multicast streams from both Source 1 and
Source 2 will flow to Host B whether it needs them or not.
When IGMPv3 is running between the hosts and routers, Host B can explicitly
express its interest in the multicast data Source 1 sends to multicast group G
(denoted as (S1, G)), rather than the multicast data Source 2 sends to multicast
group G (denoted as (S2, G)). Thus, only multicast data from Source 1 will be
delivered to Host B.
Enhancements in query and report capabilities

1 Query message carrying the source addresses
IGMPv3 supports not only general queries (feature of IGMPv1) and group-specific
queries (feature of IGMPv2), but also group-and-source-specific queries.

IGMP Configuration Task List 1119
■ A general query does not carry a group address, nor a source address;
■ A group-specific query carries a group address, but no source address;
■ A group-and-source-specific query carries a group address and one or more
source addresses.
2 Reports containing multiple group records
Unlike an IGMPv1 or IGMPv2 report message, an IGMPv3 report message is

destined to 224.0.0.22 and contains one or more group records. Each group
record contains a multicast group address and a multicast source address list.
Group record types include:
■ IS_IN: The source filtering mode is Include, namely, the report sender requests
the multicast data from only the sources defined in the specified multicast
source list. If the specified multicast source list is empty, this means that the
report sender has left the reported multicast group.
■ IS_EX: The source filtering mode is Exclude, namely, the report sender requests
the multicast data from any sources but those defined in the specified multicast
source list.
■ TO_IN: The filtering mode has changed from Exclude to Include.
■ TO_EX: The filtering mode has changed from Include to Exclude.
■ ALLOW: The Source Address fields in this Group Record contain a list of the
additional sources that the system wishes to hear from, for packets sent to the
specified multicast address. If the change was to an Include source list, these
are the addresses that were added to the list; if the change was to an Exclude
source list, these are the addresses that were deleted from the list.
■ BLOCK: indicates that the Source Address fields in this Group Record contain a
list of the sources that the system no longer wishes to hear from, for packets
sent to the specified multicast address. If the change was to an Include source
list, these are the addresses that were deleted from the list; if the change was
to an Exclude source list, these are the addresses that were added to the list.
Multi-Instance IGMP While IGMP collects group memberships on a per-interface base, IGMP in a VPN
instance handles protocol packets based on the VPN instance on the interface.
Upon receiving an IGMP packet, the router determines the instance to which the
message belongs and handles the message within the instance. If it is necessary to
exchange information with another multicast protocol, the router informs the
other multicast protocol only within the VPN instance.
Protocols and Standards The following documents describe different IGMP versions:
■ RFC 1112: Host Extensions for IP Multicasting
■ RFC 2236: Internet Group Management Protocol, Version 2
■ RFC 3376: Internet Group Management Protocol, Version 3
IGMP Configuration Complete these tasks to configure IGMP:

Task List

Task Description
“Configuring Basic Functions of “Enabling IGMP” on page Required
IGMP” on page 1120 1120
“Configuring IGMP Versions” Optional
on page 1121
“Configuring a Static Optional
Member of a Multicast
“Configuring a Multicast Optional
Group Filter” on page 1122
“Adjusting IGMP Performance” “Configuring IGMP Message Optional
on page 1123 Options” on page 1123
“Configuring IGMP Query Optional
and Response Parameters” on
page 1124
“Configuring IGMP Fast Optional
Leave Processing” on page
1126
n ■ Configurations performed in IGMP view are effective on all interfaces, while

configurations performed in interface view are effective on the current
interface only.
■ If a feature is not configured for an interface in interface view, the global
configuration performed in IGMP view will apply to that interface. If a feature
is configured in both IGMP view and interface view, the configuration
performed in interface view will be given priority.
Configuring Basic
Functions of IGMP
Configuration Before configuring the basic functions of IGMP, complete the following tasks:
Prerequisites ■ Configure any unicast routing protocol so that all devices in the domain are
■ Configure PIM-DM or PIM-SM
Before configuring the basic functions of IGMP, prepare the following data:
■ IGMP version
■ Multicast group and multicast source addresses for static group member
configuration
■ ACL rule for multicast group filtering
Enabling IGMP First, IGMP must be enabled on the interface on which the multicast group
memberships are to be established and maintained.
Enabling IGMP in the public instance

Follow these steps to enable IGMP in the public instance:

Configuring Basic Functions of IGMP 1121
To do... Use the command... Description

Disabled by default
interface-number
Enable IGMP igmp enable Required
Disabled by default
Enabling IGMP in a VPN instance

Follow these steps to enable IGMP in a VPN instance:

Configure an RD for the VPN route-distinguisher Required
instance route-distinguisher
default.
Disabled by default
interface-number
Enable IGMP igmp enable Required
Disabled by default
Configuring IGMP Because the protocol packets of different IGMP versions vary in structure and type,
Versions the same IGMP version should be configured for all routers on the same subnet
before IGMP can work properly.
Configuring an IGMP version globally

Follow these steps to configure an IGMP version globally:

Enter public instance IGMP igmp [ vpn-instance -
view or VPN instance IGMP vpn-instance-name ]
view
Configure an IGMP version version version-number Optional
IGMPv2 by default
Configuring an IGMP version for an interface

Follow these steps to configure an IGMP version on an interface:

interface-number


Configure an IGMP version igmp version Optional
version-number
IGMPv2 by default
Configuring a Static After an interface is configured as a static member of a multicast group, it will act
Member of a Multicast as a virtual member of the multicast group to receive multicast data addressed to
Group that multicast group for the purpose of testing multicast data forwarding.
Follow these steps to configure an interface as a statically connected member of a

multicast group:

interface-number
Configure the interface as a igmp static-group Required
static member of a multicast group-address [ source
An interface is not a static
group source-address ]
member of any multicast
group by default.
n ■ Before you can configure an interface of a PIM-SM device as a static member

of a multicast group, if the interface is PIM-SM enabled, it must be a PIM-SM
DR; if this interface is IGMP enabled but not PIM-SM enabled, it must be an
IGMP querier. For more information about PIM-SM and a DR, refer to “PIM
■ As a static member of a multicast group, the interface does not respond to the
queries from the IGMP querier, nor does it send an unsolicited IGMP
membership report or an IGMP leave group message when it joins or leaves a
multicast group. In other words, the interface will not become a real member
of the multicast group.
Configuring a Multicast To restrict the hosts on the network attached to an interface from joining certain
Group Filter multicast groups, you can set an ACL rule on the interface as a packet filter that
limits the range of multicast groups the interface serves.
Follow these steps to configure a multicast group filter:

interface-number
Configure a multicast group igmp group-policy Required
filter acl-number [ version-number ]
No multicast group filter

Adjusting IGMP
Performance
n For the configuration tasks described in this section

■ Configurations performed in IGMP view are effective on all interfaces, while
configurations performed in interface view are effective on the current
interface only.
■ If the same feature is configured in both IGMP view and interface view, the
configuration performed in interface view is given priority, regardless of the
configuration sequence.
Configuration Before adjusting IGMP performance, complete the following tasks:

■ Configure basic functions of IGMP.
Before adjusting IGMP performance, prepare the following data:
■ IGMP general query interval

■ IGMP querier’s robustness variable
■ Maximum response time for IGMP general queries
■ IGMP last-member query interval
■ Other querier present interval
Configuring IGMP As there are IGMP group-specific and group-and-source-specific queries, and
Message Options multicast groups change dynamically, a device cannot join all multicast groups.
Therefore, when receiving a multicast packet but unable to locate the outgoing
interface for the destination multicast group, an IGMP router needs to leverage
the Router-Alert option to pass the multicast packet to the upper-layer protocol for
processing. For details about Router-Alert, refer to RFC 2113.
Depending on whether an IGMP message carries the Router-Alert option in the IP

header, the device processes the message differently:
■ For the consideration of compatibility, the device does not check the
Router-Alert option, namely it processes all the IGMP messages it received. In
this case, IGMP messages are directly passed to the upper layer protocol, no
matter whether the IGMP messages carry the Router-Alert option or not.
■ To enhance the device performance and avoid unnecessary costs, and also for
the consideration of protocol security, you can configure the device to discard
IGMP messages that do not carry the Router-Alert option.
Configuring IGMP packet options globally

Follow these steps to configure IGMP packet options globally:



view
Configure the router to require-router-alert Optional
discard any IGMP message
By default, the device does
that does not carry the
not check the Router-Alert
Router-Alert option
option.
Enable insertion of the send-router-alert Optional
Router-Alert option into IGMP
By default, IGMP messages
messages
carry the Router-Alert option.
Configuring IGMP packet options on an interface

Follow these steps to configure IGMP packet options on an interface:

interface-number
Configure the interface to igmp require-router-alert Optional
discard any IGMP message
By default, the device does
that does not carry the
not check the Router-Alert
Router-Alert option
option.
Enable insertion of the igmp send-router-alert Optional
Router-Alert option into IGMP
By default, IGMP messages
messages
carry the Router-Alert option.
Configuring IGMP Query The IGMP querier periodically sends IGMP general queries at the “IGMP query
and Response interval” to determine whether any multicast group member exists on the
Parameters network. You can tune the IGMP general query interval based on actual condition
of the network.
On startup, the IGMP querier sends “startup query count” IGMP general queries
at the “startup query interval”, which is 1/4 of the “IGMP query interval”. Upon
receiving an IGMP leave message, the IGMP querier sends “last member query
count” IGMP group-specific queries at the “IGMP last member query interval”.
Both startup query count and last member query count are set to the IGMP querier
robustness variable.
IGMP is robust to “robustness variable minus 1” packet losses on a network.

Therefore, a greater value of the robustness variable makes the IGMP querier
“more robust”, but results in a longer multicast group timeout time.
Upon receiving an IGMP query (general query or group-specific query), a host

starts a delay timer for each multicast group it has joined. This timer is initialized to
a random value in the range of 0 to the maximum response time, which is derived
from the Max Response Time field in the IGMP query. When the timer value comes
down to 0, the host sends an IGMP report to the corresponding multicast group.
An appropriate setting of the maximum response time for IGMP queries allows
hosts to respond to queries quickly and avoids bursts of IGMP traffic on the

network caused by reports simultaneously sent by a large number of hosts when

the corresponding timers expire simultaneously.
■ For IGMP general queries, you can configure the maximum response time to fill
their Max Response time field.
■ For IGMP group-specific queries, you can configure the IGMP last member
query interval to fill their Max Response time field. Namely, for IGMP
group-specific queries, the maximum response time equals the IGMP last
member query interval.
When multiple multicast routers exist on the same subnet, the IGMP querier is
responsible for sending IGMP queries. If a non-querier router receives no IGMP
query from the querier within the “other querier present interval”, it will assume
the querier to have expired and a new querier election process is launched;
otherwise, the non-querier router will reset its “other querier present timer”.
Configuring IGMP query and response parameters globally

Follow these steps to configure IGMP query and response parameters globally:

Enter public instance IGMP igmp[ vpn-instance -
view
Configure IGMP general timer query interval Optional
query interval
Configure the IGMP querier robust-count robust-value Optional
robustness variable
2 by default
Configure the maximum max-response-time interval Optional
response time for IGMP
general queries
Configure the IGMP last-member-query-interval Optional
last-member query interval interval
1 second by default
Configure the other querier timer other-querier-present Optional
present interval interval
For the system default, see
“Note” below
Configuring IGMP query and response parameters on an interface

Follow these steps to configure IGMP query and response parameters on an
interface:

interface-number
Configure IGMP general igmp timer query interval Optional
query interval
Configure the IGMP querier igmp robust-count robust-value Optional
robustness variable
2 by default


Configure the maximum igmp max-response-time Optional
response time for IGMP interval
general queries
Configure the IGMP igmp Optional
last-member query interval last-member-query-interval
1 second by default
interval
Configure the other querier igmp timer Optional
present interval other-querier-present interval
“Note” below
n ■ If not statically configured, the other querier present interval is [IGMP

robustness variable] times [ IGMP robustness variable ] plus [maximum
response time for IGMP general queries] divided by two. By default, the values
of these three parameters are 60 (seconds), 2 (times) and 10 (seconds)
respectively, so the default value of the other querier present interval = 60 × 2
+ 10 / 2 = 125 (seconds).
■ If statically configured, the other querier present interval takes the configured
value.
c CAUTION:
■ Make sure that the other querier present interval is greater than the IGMP
query interval; otherwise the IGMP querier may change frequently on the
network.
■ Make sure that the IGMP query interval is greater than the maximum response
time for IGMP general queries; otherwise, multicast group members may be
wrongly removed.
■ The configurations of the maximum response time for IGMP general queries,
the IGMP last member query interval and the IGMP other querier present
interval are effective only for IGMPv2 or IGMPv3.
Configuring IGMP Fast In some applications, such as ADSL dial-up networking, only one multicast receiver
Leave Processing host is attached to a port of the IGMP querier. To allow fast response to the leave
messages of the host when it switches frequently from one multicast group to
another, you can enable IGMP fast leave processing on the IGMP querier.
With the fast leave processing enabled, after receiving an IGMP leave message
from a host, the IGMP querier directly sends a leave notification to the upstream
without sending IGMP group-specific queries. Thus, the leave latency is reduced
on one hand, and the network bandwidth is saved on the other hand.
Configuring IGMP fast leave processing globally

Follow these steps to enable IGMP fast leave processing globally:

view

Displaying and Maintaining IGMP 1127

Configure IGMP fast leave fast-leave [ group-policy Required
processing acl-number ]
Disabled by default
Configuring IGMP fast leave processing on an interface

Follow these steps to configure IGMP fast leave processing on an interface:

interface-number
Configure IGMP fast leave igmp fast-leave [ group-policy Required
processing acl-number ]
Disabled by default
c CAUTION: The IGMP fast leave feature is effective only if the device is running
IGMPv2 or IGMPv3.
Displaying and
Maintaining IGMP To do... Use the command... Remarks
View IGMP multicast display igmp [ vpn-instance Available in any
group information vpn-instance-name | all-instance ] group view
[ group-address | interface interface-type
interface-number ] [ static | verbose ]
View routing display igmp [ vpn-instance Available in any
information in the IGMP vpn-instance-name | all-instance ] view
routing table routing-table [ source-address [ mask { mask
| mask-length } ] | group-address [ mask { mask
| mask-length } ] ] *
Clear IGMP forwarding reset igmp [ vpn-instance Available in user
entries vpn-instance-name | all-instance ] group { all view
| interface interface-type interface-number
{ all | group-address [ mask { mask |
mask-length } ] [ source-address [ mask { mask
| mask-length } ] ] } }
n The reset igmp group command cannot clear the IGMP forwarding entries of
static joins.
c CAUTION: The reset igmp group command may cause an interruption of

receivers’ reception of multicast data.
IGMP Configuration Network requirements

Example ■ Receivers receive VOD information through multicast. Receivers of different
organizations form stub networks N1 and N2, and Host A and Host C are
receivers in N1 and N2 respectively.
■ Router A in the PIM network connects to N1, and both Router B and Router C
connect to another stub network, N2.
■ Router A connects to N1 through Ethernet 1/0, and to other devices in the PIM
network through POS5/0.

■ Router B and Router C connect to N2 through their respective Ethernet 1/0,

and to other devices in the PIM domain through their respective POS5/0.
■ IGMPv3 is required between Router A and N1. IGMPv2 is required between the
other two routers and N2, with Router B as the IGMP querier.
Network diagram
Figure 332 Network diagram for IGMP configuration
PIM network Receiver
Host A
POS 5/0 N1
Eth1/0
10 .110 .1.1/24
Ethernet
Router A
Host B
Querier
Eth1/0
POS 5/0
10 .110 .2.1/24 Receiver
Router B Host C
Eth1/0
N2
10 .110 .2.2/24
POS 5/0
Ethernet
Router C Host D
1 Configure the IP addresses of the router interfaces and configure a unicast routing
protocol
Configure the IP address and subnet mask of each interface as per Figure 332. The
detailed configuration steps are omitted here.
Configure the OSPF protocol for interoperation among the routers. Ensure the
network-layer interoperation among Router A, Router B and Router C on the PIM
network and dynamic update of routing information among the routers through a
unicast routing protocol. The detailed configuration steps are omitted here.
2 Enable IP multicast routing, and enable IGMP on the host-side interfaces
# Enable IP multicast routing on Router A, and enable IGMP (version 3) and

PIM-DM on Ethernet 1/0.
[RouterA-Ethernet1/0] igmp enable
[RouterA-Ethernet1/0] igmp version 3

Troubleshooting IGMP 1129
# Enable IP multicast routing on Router B, and enable IGMP (version 2) and

[RouterB-Ethernet1/0] igmp version 2
# Enable IP multicast routing on Router C, and enable IGMP (version 2) and

[RouterC-Ethernet1/0] igmp enable
[RouterC-Ethernet1/0] igmp version 2
Use the display igmp interface command to view the IGMP configuration and
operation status on each router interface. For example:
# View IGMP information on Ethernet 1/0 of Router B.
[RouterB] display igmp interface ethernet 1/0

Ethernet1/0(10.110.2.1):
IGMP is enabled
Current IGMP version is 2
Value of query interval for IGMP(in seconds): 60
Value of other querier present interval for IGMP(in seconds): 125
Value of maximum query response time for IGMP(in seconds): 10
Querier for IGMP: 10.110.2.1 (this router)
Total 1 IGMP Group reported
Troubleshooting IGMP
No Membership Symptom
Information on the When a host sends a report for joining multicast group G, there is no membership
Receiver-Side Router information of the multicast group G on the router closest to that host.
Analysis
■ The correctness of networking and interface connections directly affects the
generation of group membership information.
■ Multicast routing must be enabled on the router.
■ If the igmp group-policy command has been configured on the interface, the
interface cannot receive report messages that fail to pass filtering.

Solution
1 Check that the networking is correct and interface connections are correct.
2 Check that the interfaces and the host are on the same subnet. Use the display
current-configuration interface command to view the IP address of the
interface.
3 Check that multicast routing is enabled. Carry out the display
current-configuration command to check whether the multicast
routing-enable command has been executed. If not, carry out the multicast
routing-enable command in system view to enable IP multicast routing. In
addition, check that IGMP is enabled on the corresponding interfaces.
4 Check that the interface is in normal state and the correct IP address has been
configured. Carry out the display igmp interface command to view the interface
information. If no interface information is output, this means the interface is
abnormal. Typically this is because the shutdown command has been executed
on the interface, or the interface connection is incorrect, or no correct IP address
has been configured on the interface.
5 Check that no ACL rule has been configured to restrict the host from joining the
multicast group G. Carry out the display current-configuration interface
command to check whether the igmp group-policy command has been
executed. If the host is restricted from joining the multicast group G, the ACL rule
must be modified to allow receiving the reports for the multicast group G.
Inconsistent Symptom
Memberships on Different memberships are maintained on different IGMP routers on the same
Routers on the Same subnet.
Subnet
Analysis
■ A router running IGMP maintains multiple parameters for each interface, and
these parameters influence one another, forming very complicated
relationships. Inconsistent IGMP interface parameter configurations for routers
on the same subnet will surely result in inconsistency of memberships.
■ In addition, although an IGMP routers is compatible with a host that is running
a different IGMP version, all routers on the same subnet must run the same
version of IGMP. Inconsistent IGMP versions running on routers on the same
subnet will also lead to inconsistency of IGMP memberships.
Solution
1 Check the IGMP configuration. Carry out the display current-configuration
command to view the IGMP configuration information on the interfaces.
2 Carry out the display igmp interface command on all routers on the same
subnet to check the IGMP-related timer settings. Make sure that the settings are
consistent on all the routers.
3 Use the display igmp interface command to check whether all the routers on
the same subnet are running the same version of IGMP.

MSDP CONFIGURATION
70
When configuring MSDP, go to these sections for information you are interested
in:
■ “MSDP Overview” on page 1131
■ “Configuring Basic Functions of MSDP” on page 1138
■ “Configuring an MSDP Peer Connection” on page 1140
■ “Configuring SA Messages” on page 1141
■ “Displaying and Maintaining MSDP” on page 1144
■ “MSDP Configuration Examples” on page 1145
■ “Troubleshooting MSDP” on page 1158
n For details about the concepts of designated router (DR), bootstrap router (BSR),
candidate-BSR (C-BSR), rendezvous point (RP), candidate RP (C-RP), shortest path
tree (SPT) and rendezvous point tree (RPT) mentioned in this manual, refer to “PIM
MSDP Overview
Introduction to MSDP Multicast source discovery protocol (MSDP) is an inter-domain multicast solution
developed to address the interconnection of protocol independent multicast
sparse mode (PIM-SM) domains. It is used to discover multicast source information
in other PIM-SM domains.
In the basic PIM-SM mode, a multicast source registers only with the RP in the local
PIM-SM domain, and the multicast source information of a domain is isolated
from that of another domain. As a result, the RP is aware of the source
information only within the local domain and a multicast distribution tree is built
only within the local domain to deliver multicast data from a local multicast source
to local receivers. If there is a mechanism that allows RPs of different PIM-SM
domains to share their multicast source information, the local RP will be able to
join multicast sources in other domains and multicast data can be transmitted
among different domains.
MSDP achieves this objective. By establishing MSDP peer relationships among RPs
of different PIM-SM domains, source active (SA) messages can be forwarded
among domains and the multicast source information can be shared.
c CAUTION:
■ MSDP is applicable only if the intra-domain multicast protocol is PIM-SM.
■ MSDP is meaningful only for the any-source multicast (ASM) model.

1132 CHAPTER 70: MSDP CONFIGURATION
How MSDP Works MSDP peers

With one or more pairs of MSDP peers configured in the network, an MSDP
interconnection map is formed, where the RPs of different PIM-SM domains are
interconnected in series. Relayed by these MSDP peers, an SA message sent by an
RP can be delivered to all other RPs.
Figure 333 Where MSDP peers are in the network
PIM-SM 1
PIM-SM 2
Router A Router B
Source
RP 2
RP 1
PIM-SM 3
MSDP peers Receiver RP 3
As shown in Figure 333, an MSDP peer can be created on any PIM-SM router.
MSDP peers created on PIM-SM routers that assume different roles function
differently.
1 MSDP peers on RPs

■ Source-side MSDP peer: the MSDP peer nearest to the multicast source
(Source), typically the source-side RP, like RP 1. The source-side RP creates SA
messages and sends the messages to its remote MSDP peer to notify the MSDP
peer of the locally registered multicast source information. A source-side MSDP
must be created on the source-side RP; otherwise it will not be able to advertise
the multicast source information out of the PIM-SM domain.
■ Receiver-side MSDP peer: the MSDP peer nearest to the receivers, typically the
receiver-side RP, like RP 3. Upon receiving an SA message, the receiver-side
MSDP peer resolves the multicast source information carried in the message
and joins the SPT rooted at the source across the PIM-SM domain. When
multicast data from the multicast source arrives, the receiver-side MSDP peer
forwards the data to the receivers along the RPT.
■ Intermediate MSDP peer: an MSDP peer with multicast remote MSDP peers,
like RP 2. An intermediate MSDP peer forwards SA messages received from one
remote MSDP peer to other remote MSDP peers, functioning as a relay of
multicast source information.
2 MSDP peers created on common PIM-SM routers (other than RPs), like Router A
and Router B, which just forwards received SA messages.
n An RP is dynamically elected from C-RPs. To enhance network robustness, a

PIM-SM network typically has more than one C-RP. As the RP election result is
unpredictable, MSDP peering relationships should be built among all C-RPs so that
the winner C-RP is always on the “MSDP interconnection map”, while loser C-RPs

MSDP Overview 1133
will assume the role of common PIM-SM routers on the “MSDP interconnection
map”.
Implementing inter-domain multicast delivery by leveraging MSDP peers

As shown in Figure 334, an active source exists in the domain PIM-SM 1, and RP 1
learns the existence of this number source through multicast source registration. If
PIM-SM 2 and PIM-SM 3 also wish to know the specific location of the multicast
source so as to receive multicast traffic originated from it, MSDP peering
relationships should be established between RP1 and RP3 and between RP 3 and
RP 2 respectively.
Figure 334 MSDP peers
Receiver
DR 2
MSDP peers
Multicast packets
SA message
Join message RP 2
PIM-SM 2
Register message
DR 1
Source
PIM-SM 4
RP 1 RP 3
PIM-SM 1 PIM-SM 3
The process of implementing inter-domain multicast delivery by leveraging MSDP

peers is as follows:
1 When the multicast source in PIM-SM 1 sends the first multicast packet to
multicast group G, DR 1 encapsulates the multicast data within a register message
and sends the register message to RP 1. Then, RP 1 gets aware of the information
related to the multicast source.
2 As the source-side RP, RP 1 creates SA messages and periodically sends the SA
messages to its MSDP peer. An SA message contains the source address (S), the
multicast group address (G), and the address of the RP which has created this SA
message (namely RP 1).
3 On MSDP peers, each SA message is subject to a reverse path forwarding (RPF)
check and multicast policy-based filtering, so that only SA messages that have
arrived along the correct path and passed the filtering are received and forwarded.
This avoids delivery loops of SA messages. In addition, you can configure MSDP
peers into an MSDP mesh group so as to avoid flooding of SA messages between
MSDP peers.

4 SA messages are forwarded from one MSDP peer to another, and finally the
information of the multicast source traverses all PIM-SM domains with MSDP
peers (PIM-SM 2 and PIM-SM 3 in this example).
5 Upon receiving the SA message create by RP 1, RP 2 in PIM-SM 2 checks whether
there are any receivers for the multicast group in the domain.
■ If so, the RPT for the multicast group G is maintained between RP 2 and the
receivers. RP 2 creates an (S, G) entry, and sends an (S, G) join message hop by
hop towards DR 1 at the multicast source side, so that it can directly join the
SPT rooted at the source over other PIM-SM domains. Then, the multicast data
can flow along the SPT to RP 2 and is forwarded by RP 2 to the receivers along
the RPT. Upon receiving the multicast traffic, the DR at the receiver side (DR 2)
decides whether to initiate an RPT-to-SPT switchover process.
■ If no receivers for the group exist in the domain, RP 2 does dot create an (S, G)
entry and does join the SPT rooted at the source.
n ■ An MSDP mesh group refers to a group of MSDP peers that have MSDP
peering relationships among one another and share the same group name is
used on all the members of an MSDP mesh group.
■ When using MSDP for inter-domain multicasting, once an RP receives
information form a multicast source, it no longer relies on RPs in other PIM-SM
domains. The receivers can override the RPs in other domains and directly join
the multicast source based SPT.
RPF check rules for SA messages

As shown in Figure 335, there are five autonomous systems in the network, AS 1
through AS 5, with IGP enabled on routers within each AS and EBGP as the
interoperation protocol among different ASs. Each AS contains at least one
PIM-SM domain and each PIM-SM domain contains one ore more RPs. MSDP
peering relationships have been established among different RPs. RP 3, RP 4 and
RP 5 are in an MSDP mesh group. On RP 7, RP 6 is configured as its static RPF peer.
n If only one MSDP peer exists in a PIM-SM domain, this PIM-SM domain is also
called a stub domain. For example, AS 4 in Figure 335 is a stub domain. The MSDP
peer in a stub domain can have multiple remote MSDP peers at the same time.
You can configure one or more remote MSDP peers as static RPF peers. When an
RP receives an SA message from a static RPF peer, the RP accepts the SA message
and forwards it to other peers without performing an RPF check.

MSDP Overview 1135
Figure 335 Diagram for RPF check for SA messages
Source
RP 1
RP 5 RP 9 RP 8
(7)
AS 1
(1)
(3)
AS 5
(2) (4)
Mesh group (6)
AS 3
RP 2 RP 3
AS 2 (3) (5)
MSDP peers (4)

RP 4 RP 6 RP 7
Static RPF peers AS 4
SA message
As illustrated in Figure 335, these MSDP peers dispose of SA messages according

to the following RPF check rules:
1 When RP 2 receives an SA message from RP 1
Because the source-side RP address carried in the SA message is the same as the
MSDP peer address, which means that the MSDP peer where the SA is from is the
RP that has created the SA message, RP 2 accepts the SA message and forwards it
to its other MSDP peer (RP 3).
2 When RP 3 receives the SA message from RP 2
Because the SA message is from an MSDP peer (RP 2) in the same AS, and the
MSDP peer is the next hop on the optimal path to the source-side RP, RP 3 accepts
the message and forwards it to other peers (RP 4 and RP 5).
3 When RP 4 and RP 5 receive the SA message from RP 3
Because the SA message is from an MSDP peer (RP 3) in the same mesh group, RP
4 and RP 5 both accept the SA message, but they do not forward the message to
other members in the mesh group; instead, they forward it to other MSDP peers
(RP 6 in this example) out of the mesh group.
4 When RP 6 receives the SA messages from RP 4 and RP 5 (suppose RP 5 has a

higher IP address)
Although RP 4 and RP 5 are in the same SA (AS 3) and both are MSDP peers of RP
6, because RP 5 has a higher IP address, RP 6 accepts only the SA message from RP
5.
Because the SA message is from a static RPF peer (RP 6), RP 7 accepts the SA
message and forwards it to other peer (RP 8).

An EBGP route exists between two MSDP peers in different ASs. Because the SA
message is from an MSDP peer (RP 7) in a different AS, and the MSDP peer is the
next hop on the EBGP route to the source-side RP, RP 8 accepts the message and
forwards it to its other peer (RP 9).
Because RP 9 has only one MSDP peer, RP 9 accepts the SA message.
SA messages from other paths than described above will not be accepted nor
forwarded by MSDP peers.
Implementing intra-domain Anycast RP by leveraging MSDP peers

Anycast RP refers to such an application that enables load balancing and
redundancy backup between two or more RPs within a PIM-SM domain by
configuring the same IP address for and establishing MSDP peering relationships
between these RPs.
As shown in Figure 336, within a PIM-SM domain, a multicast source sends

multicast data to multicast group G, and Receiver is a member of the multicast
group. To implement Anycast RP, configure the same IP address (known as anycast
RP address, typically a private address) on Router A and Router B, configure these
interfaces as C-RPs, and establish an MSDP peering relationship between Router A
and Router B.
n Usually Anycast RP address is configured on a logic interface, like a loopback

interface.
Figure 336 Typical network diagram of Anycast RP
RP 1 RP 2
Router A Router B
Source Receiver
PIM-SM
MSDP peers
SA message
The work process of Anycast RP is as follows:
1 The multicast source registers with the nearest RP. In this example, Source registers
with RP 1, with its multicast data encapsulated in the register message. When the
register message arrives to RP 1, RP 1 decapsulates the message.
2 Receivers send join messages to the nearest RP to join in the RPT rooted as this RP.
In this example, Receiver joins the RPT rooted at RP 2.
3 RPs share the registered multicast information by means of SA messages. In this
example, RP 1 creates an SA message and sends it to RP 2, with the multicast data

MSDP Configuration Task List 1137
from Source encapsulated in the SA message. When the SA message reaches RP 2,

RP 2 decapsulates the message.
4 Receivers receive the multicast data along the RPT and directly joins the SPT rooted
at the multicast source. In this example, RP 2 forwards the multicast data down
the RPT. When Receiver receives the multicast data from Source, it directly joins
the SPT rooted at Source.
The significance of Anycast RP is as follows:
■ Optimal RP path: A multicast source registers with the nearest RP so that an

SPT with the optimal path is built; a receiver joins the nearest RP so that an RPT
with the optimal path is built.
■ Load balancing between RPs: Each RP just needs to maintain part of the
source/group information within the PIM-SM domain and forward part of the
multicast data, thus achieving load balancing between different RPs.
■ Redundancy backup between RPs: When an RP fails, the multicast source
previously registered on it or the receivers previous joined it will register with or
join another nearest RP, thus achieving redundancy backup between RPs.
c CAUTION:
■ Be sure to configure a 32-bit subnet mask (255.255.255.255) for the Anycast
RP address, namely configure the Anycast RP address into a host address.
■ An MSDP peer address must be different from the Anycast RP address.
Multi-Instance MSDP MSDP peering relationship can be built between multicast-enabled interfaces that
belong to the same instance. Through exchanges of SA messages between MSDP
peers, the MSDP mechanism makes VPN multicast transmission between different
PIM-SM domains possible.
A multicast router running multiple MSDP instances maintains an independent set

of MSDP mechanism for each instance it supports, including SA cache, peering
connection, timers, sending cache, and cache for exchanging information with
PIM, while one instance is isolated from another; therefore, interoperabitity
between MSDP and PIM-SM is available only within the same instance.
Protocols and Standards MSDP is documented in the following specifications:

■ RFC 3618: Multicast Source Discovery Protocol (MSDP)
■ RFC 3446: Anycast Rendezvous Point (RP) mechanism using Protocol
Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
MSDP Configuration Complete these tasks to configure MSDP:

Task List
Task Remarks
“Configuring Basic Functions of “Enabling MSDP” on page Required
MSDP” on page 1138 1138
“Creating an MSDP Peer Required
Connection” on page 1139
“Configuring a Static RPF Optional
Peer” on page 1139

Task Remarks
“Configuring an MSDP Peer “Configuring MSDP Peer Optional
Connection” on page 1140 Description” on page 1140
“Configuring an MSDP Optional
Mesh Group” on page 1140
“Configuring MSDP Peer Optional
Connection Control” on
page 1141
“Configuring SA Messages” on “Configuring SA Message Optional
page 1141 Content” on page 1142
“Configuring SA Request Optional
Messages” on page 1142
“Configuring an SA Optional
Message Filtering Rule” on
page 1143
“Configuring SA Message Optional
Cache” on page 1144
Configuring Basic
Functions of MSDP
n All the configuration tasks shall be implemented on RPs in PIM-SM domains, and
each of these RPs acts as an MSDP peer.
Configuration Before configuring the basic functions of MSDP, complete the following tasks:
■ Configuring PIM-SM to enable intra-domain multicast forwarding.
Before configuring the basic functions of MSDP, prepare the following data:
■ IP addresses of MSDP peers

■ Address prefix list for an RP address filtering policy
Enabling MSDP Enabling MSDP globally in the public instance

Follow these steps to enable MSDP globally in the public instance:

Disabled by default
Enable MSDP and enter public msdp [ vpn-instance Required
instance MSDP view vpn-instance-name ]
Disabled by default
Enabling MSDP in a VPN instance


Configuring Basic Functions of MSDP 1139

Configure a route-distinguisher Required
route-distinguisher route-distinguisher
(RD) for the VPN instance default.
Disabled by default
Enable MSDP and enter VPN msdp [ vpn-instance Required
instance MSDP view vpn-instance-name ]
Disabled by default
Creating an MSDP Peer An MSDP peering relationship is identified by an address pair, namely the address
Connection of the local MSDP peer and that of the remote MSDP peer. An MSDP peer
connection must be created on both devices that are a pair of MSDP peers.
Follow these steps to create an MSDP peer connection:

Enter public instance MSDP msdp [ vpn-instance -
view or VPN instance MSDP vpn-instance-name ]
view
Create an MSDP peer peer peer-address Required
connection connect-interface
No MSDP peer connection
interface-type
created by default
interface-number
n If an interface of the router is shared by an MSDP peer and a BGP peer at the same
time, we recommend that you configuration the same IP address for the MSDP
peer and BGP peer.
Configuring a Static RPF Configuring static RPF peers avoids RPF check of SA messages.
Peer
Follow these steps to configure a static RPF peer:

view
Configure a static RPF peer static-rpf-peer peer-address Required
[ rp-policy ip-prefix-name ]
No static RPF peer configured
by default
n If only one MSDP peer is configured on a router, this MSDP will be registered as a
static RPF peer.

Configuring an MSDP
Peer Connection
Configuration Before configuring MSDP peer connection, complete the following tasks:
Prerequisites ■ Configuring any unicast routing protocol so that all devices in the domain are
interoperable at the network layer
■ Configuring basic functions of MSDP
Before configuring an MSDP peer connection, prepare the following data:
■ Description information of MSDP peers

■ Name of an MSDP mesh group
■ MSDP peer connection retry interval
Configuring MSDP Peer With the MSDP peer description information, the administrator can easily
Description distinguish different MSDP peers and thus better manage MSDP peers.
Follow these steps to configure description for an MSDP peer:

view
Configure description for an peer peer-address Required
MSDP peer description text
No description for MSDP
peers by default
Configuring an MSDP An AS may contain multiple MSDP peers. You can use the MSDP mesh group
Mesh Group mechanism to avoid SA message flooding among these MSDP peers and optimize
the multicast traffic.
On one hand, an MSDP peer in an MSDP mesh group forwards SA messages from
outside the mesh group that have passed the RPF check to the other members in
the mesh group; on the other hand, a mesh group member accepts SA messages
from inside the group without performing an RPF check, and does not forward the
message within the mesh group either. This mechanism not only avoids SA
flooding but also simplifies the RPF check mechanism, because BGP is not needed
to run between these MSDP peers.
By configuring the same mesh group name for multiple MSDP peers, you can
create a mesh group with these MSDP peers.
Follow these steps to create an MSDP mesh group:



view
Create an MSDP peer as a peer peer-address Required
mesh group member mesh-group name
An MSDP peer does not
belong to any mesh group by
default
n ■ Before grouping multiple routers into an MSDP mesh group, make sure that
these routers are interconnected with one another.
■ If you configure more than one mesh group name on an MSDP peer, only the
last configuration is effective.
Configuring MSDP Peer MSDP peers are interconnected over TCP (port number 639). You can flexibly
Connection Control control sessions between MSDP peers by manually deactivating and reactivating
the MSDP peering connections. When the connection between two MSDP peers is
deactivated, SA messages will no longer be delivered between them, and the TCP
connection is closed without any connection setup retry, but the configuration
information will remain unchanged.
When a new MSDP peer is created, or when a previously deactivated MSDP peer
connection is reactivated, or when a previously failed MSDP peer attempts to
resume operation, a TCP connection is required. You can flexibly adjust the interval
between MSDP peering connection retries.
Follow these steps to configure MSDP peer connection control:

view
Deactivate an MSDP peer shutdown peer-address Optional
Active by default
Configure the interval timer retry interval Optional
between MSDP peer
connection retries
Configuring SA
Messages
Configuration Before configuring SA message delivery, complete the following tasks:

■ Configuring basic functions of MSDP
Before configuring SA message delivery, prepare the following data:

■ ACL as a filtering rule for SA request messages

■ ACL as an SA message creation rule
■ ACL as a filtering rule for receiving or forwarding SA messages
■ Minimum TTL value of multicast packets encapsulated in SA messages
■ Maximum SA message cache size
Configuring SA Message Some multicast sources send multicast data at an interval longer than the aging
Content time of (S, G) entries. In this case, the source-side DR has to encapsulate multicast
data packet by packet in register messages and send them to the source-side RP.
The source-side RP transmits the (S, G) information to the remote RP through SA
messages. Then the remote RP joins the source-side DR and builds an SPT. Since
the (S, G) entries have timed out, remote receivers can never receive the multicast
data from the multicast source.
If the source-side RP is enabled to encapsulate register messages in SA messages,

when there is a multicast packet to deliver, the source-side RP encapsulates a
register message containing the multicast packet in an SA message and sends it
out. After receiving the SA message, the remote RP decapsulates the SA message
and delivers the multicast data contained in the register message to the receivers
along the RPT.
The MSDP peers deliver SA messages to one another. Upon receiving an SA

message, a router performs RPF check on the message. If the router finds that the
remote RP address is the same as the local RP address, it will discard the SA
message. In the Anycast RP application, however, you need to configure RPs with
the same IP address on two or more routers in the same PIM-SM domain, and
configure these routers as MSDP peers to one another. Therefore, a logic RP
address (namely the RP address on the logic interface) that is different from the
actual RP address must be designated for SA messages so that the messages can
pass the RPF check.
Follow these steps to configure the SA message content:

view
Enable encapsulation of a encap-data-enable Optional
register message
Disabled by default
Configure the interface originating-rp interface-type Optional
address as the RP address in interface-number
PIM RP address by default
SA messages
Configuring SA Request By default, upon receiving a new Join message, a router does not send an SA
Messages request message to its designated MSDP peer; instead, it waits for the next SA
message from its MSDP peer. This will cause the receiver to delay obtaining
multicast source information. To enable a new receiver to get the currently active
multicast source information as early as possible, you can configure routers to

send SA request messages to the designated MSDP peers up receiving a Join

message of a new receiver.
Follow these steps to configure SA message transmission and filtering:

view
Enable the device to send SA peer peer-address Optional
request messages request-sa-enable
Disabled by default
Configure a filtering rule for peer peer-address Optional
SA request messages sa-request-policy [ acl
SA request messages are not
acl-number ]
filtered by default
c CAUTION: Before you can enable the device to send SA requests, be sure to
disable the SA message cache mechanism.
Configuring an SA By configuring an SA message creation rule, you can enable the router to filter the
Message Filtering Rule (S, G) entries to be advertised when creating an SA message, so that the
propagation of messages of multicast sources is controlled.
In addition to controlling SA message creation, you can also configure filtering

rules for forwarding and receiving SA messages, so as to control the propagation
of multicast source information in the SA messages.
■ By configuring a filtering rule for receiving or forwarding SA messages, you can

enable the router to filter the (S, G) forwarding entries to be advertised when
receiving or forwarding an SA message, so that the propagation of multicast
source information is controlled at SA message reception or forwarding.
■ An SA message with encapsulated multicast data can be forwarded to a
designated MSDP peer only if the TTL value in its IP header exceeds the
threshold. Therefore, you can control the forwarding of such an SA message by
configuring the TTL threshold of the encapsulated data packet.
Follow these steps to configure a filtering rule for receiving or forwarding SA

messages:

view
Configure an SA message import-source [ acl Required
creation rule acl-number ]
No restrictions on (S, G)
entries by default
Configure a filtering rule for peer peer-address sa-policy Required
receiving or forwarding SA { import | export } [ acl
No filtering rule by default
messages acl-number ]


Configure the minimum TTL peer peer-address Optional
value of multicast packets to minimum-ttl ttl-value
0 by default
be encapsulated in SA
messages
Configuring SA Message To reduce the time spent in obtaining the multicast source information, you can
Cache have SA messages cached on the router. However, the more SA messages are
cached, the larger memory space of the router is used.
With the SA cache mechanism enabled, when receiving a new Join message, the
router will not send an SA request message to its MSDP peer; instead, it acts as
follows:
■ If there is no SA message in the cache, the router will wait for the SA message
sent by its MSDP peer in the next cycle;
■ If there is an SA message in the cache, the router will obtain the information of
all active sources directly from the SA message and join the corresponding SPT.
To protect the router against denial of service (DoS) attacks, you can configure the
maximum number of SA messages the route can cache.
Follow these steps to configure the SA message cache:

view
Enable the SA message cache cache-sa-enable Optional
mechanism
Enabled by default
Configure the maximum peer peer-address Optional
number of SA messages the sa-cache-maximum sa-limit
8192 by default
router can cache
Displaying and
Maintaining MSDP To do... Use the command... Remarks
View the brief information display msdp [ vpn-instance Available in any
of MSDP peers vpn-instance-name | all-instance ] brief view
[ state { connect | down | listen | shutdown
| up } ]
View the detailed display msdp [ vpn-instance Available in any
information about the vpn-instance-name | all-instance ] view
status of MSDP peers peer-status [ peer-address ]
View the (S, G) entry display msdp [ vpn-instance Available in any
information in the MSDP vpn-instance-name | all-instance ] sa-cache view
cache [ group-address | source-address | as-number ]
*
View the number of SA display msdp [ vpn-instance Available in any
messages in the MSDP vpn-instance-name | all-instance ] sa-count view
cache [ as-number ]


Reset the TCP connection reset msdp [ vpn-instance Available in user
with an MSDP peer vpn-instance-name | all-instance ] peer view
[ peer-address ]
Clear (S, G) entries in the reset msdp [ vpn-instance Available in user
MSDP cache vpn-instance-name | all-instance ] sa-cache view
[ group-address ]
Clear all statistics reset msdp [ vpn-instance Available in user
information of an MSDP vpn-instance-name | all-instance ] statistics view
peer [ peer-address ]
MSDP Configuration
Examples
Example of Leveraging Network requirements

BGP Routes ■ Two ISPs maintain their ASs, AS 100 and AS 200 respectively. OSPF is running
within each AS, and BGP is running between the two ASs.
■ PIM-SM 1 belongs to AS 100, while PIM-SM 2 and PIM-SM 3 belong to AS
200.
■ Each PIM-SM domain has zero or one multicast source and one or more
receivers. OSPF runs within each domain to provide unicast routes.
■ It is required that the respective Loopback0 of Router C, Router D and Router F
be configured as the C-BSR and C-RP of the respective PIM-SM domains.
■ It is required that an MSDP peering relationship be established between Router
C and Router D through EBGP, and between Router D and Router F through
IBGP.

Network diagram
Figure 337 Network diagram for configuration leveraging a BGP route (on routers)
AS 100 AS 200 Receiver

Receiver
Loop 0
Router G
Router F Eth1/0
Router B Router A S 2/0

PIM-SM 3
Source 1
Receiver
0 /
h1
Eth1/1 S 2/0
Et
POS5 /0 POS 5/0 Eth1/0
Router C Router D Source 2 Router E

Loop 0 Loop 0
PIM-SM 1 PIM-SM 2
MSDP peers
Router C Eth1/0 10.110.1.1/24 Router D Eth1/0 10.110.4.1/24
Eth1/1 10.110.2.1/24 S2/0 192.168.3.1/24
POS5/0 192.168.1.1/24 POS5/0 192.168.1.2/24
Loop0 1.1.1.1/32 Loop0 2.2.2.2/32
Router F Eth1/0 10.110.3.1/24
S2/0 192.168.3.2/24
Loop0 3.3.3.3/32
Detailed configuration steps are omitted.
Configure OSPF for interconnection between routers in each PIM-SM domain.

Ensure the network-layer interoperation among Router A, Router B and Router C
in PIM-SM 1, the network-layer interoperation between Router D and Router E in
PIM-SM 2, and the network-layer interoperation between Router F and Router G
in PIM-SM 3, and ensure the dynamic update of routing information between the
routers in each PIM-SM domain through a unicast routing protocol. Detailed
configuration steps are omitted.
2 Enable IP multicast routing, and enable PIM-SM on each interface
# Enable IP multicast routing on Router C, and enable PIM-SM on each interface.

[RouterC-Ethernet1/0] pim sm
[RouterC-Ethernet1/1] pim sm
[RouterC] interface pos 5/0
[RouterC-Pos5/0] pim sm
The configuration on Router A, Router B, Router D, Router E, Router F and Router

G is similar to the configuration on Router C.
# Configure a BSR admin-scope region boundary on Router C.
[RouterC-Pos5/0] pim bsr-boundary

[RouterC-Pos5/0] quit
The configuration on Router D and Router F is similar to the configuration on

Router C.
3 Configure Loopback0 and the position of C-BSR, and C-RP
# Configure the position of Loopback0, C-BSR, and C-RP on Router C.

[RouterC-LoopBack0] ip address 1.1.1.1 255.255.255.255
[RouterC-LoopBack0] pim sm
[RouterC-LoopBack0] quit
[RouterC] pim
[RouterC-pim] c-bsr loopback 0
[RouterC-pim] c-rp loopback 0
[RouterC-pim] quit

Router C.
4 Configure inter-AS BGP and configure mutual route redistribution between BGP
and OSPF
# Configure EBGP on Router C, and redistribute OSPF routes.
[RouterC] bgp 100

[RouterC-bgp] import-route ospf 1
[RouterC-bgp] quit
# Configure IBGP and EBGP on Router D, and redistribute OSPF routes.
[RouterD] bgp 200

[RouterD-bgp] import-route ospf 1
[RouterD-bgp] quit

# Configure IBGP on Router F, and redistribute OSPF routes.
[RouterF] bgp 200

[RouterF-bgp] router-id 3.3.3.3
[RouterF-bgp] peer 192.168.3.1 as-number 200
[RouterF-bgp] import-route ospf 1
[RouterF-bgp] quit
# Inject BGP routing information into OSPF on Router C.
[RouterC] ospf 1
[RouterC-ospf-1] import-route bgp

Router C.
Carry out the display bgp peer command to view the BGP peering relationships
between the routers. For example:
# View the information about BGP peering relationship on Router C.
[RouterC] display bgp peer


192.168.1.2 4 200 24 21 0 6 00:13:09 Established
# View the information about BGP peering relationship on Router D.
[RouterD] display bgp peer


192.168.1.1 4 100 18 16 0 1 00:12:04 Established
192.168.3.2 4 200 21 20 0 6 00:12:05 Established
# View the information about BGP peering relationships on Router F.
[RouterF] display bgp peer


192.168.3.1 4 200 16 14 0 1 00:10:58 Established
To view the BGP routing table information on the routers, use the display bgp
routing-table command. For example:
# View the BGP routing table information on Router D.



*> 1.1.1.1/32 192.168.1.1 0 0 100?
*>i 2.2.2.2/32 192.168.3.2 0 100 0 ?
*> 3.3.3.3/32 0.0.0.0 0 0 ?
*> 192.168.1.0 0.0.0.0 0 0 ?
* 192.168.1.1 0 0 100?
*> 192.168.1.1/32 0.0.0.0 0 0 ?
*> 192.168.1.2/32 0.0.0.0 0 0 ?
* 192.168.1.1 0 0 100?
*> 192.168.3.0 0.0.0.0 0 0 ?
* i 192.168.3.2 0 100 0 ?
*> 192.168.3.1/32 0.0.0.0 0 0 ?
*> 192.168.3.2/32 0.0.0.0 0 0 ?
* i 192.168.3.2 0 100 0 ?
5 Configure MSDP peers
# Configure an MSDP peer on Router C.
[RouterC] msdp
[RouterC-msdp] peer 192.168.1.2 connect-interface pos 5/0
[RouterC-msdp] quit
# Configure an MSDP peer on Router D.
[RouterD] msdp
[RouterD-msdp] peer 192.168.1.1 connect-interface pos 5/0
[RouterD-msdp] peer 192.168.3.2 connect-interface serial 2/0
[RouterD-msdp] quit
# Configure MSDP peers on Router F.
[RouterF] msdp
[RouterF-msdp] peer 192.168.3.1 connect-interface serial 2/0
[RouterF-msdp] quit
When the multicast source (Source 1) sends multicast information, receivers in

PIM-SM 2 and PIM-SM 3 can receive the multicast data. You can use the display
msdp brief command to view the brief information of MSDP peering
relationships between the routers. For example:
# View the brief information about MSDP peering relationship on Router C.
[RouterC] display msdp brief

MSDP Peer Brief Information of VPN-Instance: public net
Configured Up Listen Connect Shutdown Down
1 1 0 0 0 0
Peer’s Address State Up/Down time AS SA Count Reset Count

192.168.1.2 Up 00:12:27 200 13 0
# View the brief information about MSDP peering relationship on Router D.
[RouterD] display msdp brief

2 2 0 0 0 0

192.168.3.2 Up 00:15:32 200 8 0

192.168.1.1 UP 00:06:39 100 13 0
# View the brief information about MSDP peering relationships on Router F.
[RouterF] display msdp brief

1 1 0 0 0 0

192.168.3.1 Up 01:07:08 200 8 0
# View the detailed BGP peer information on Router C.
[RouterC] display msdp peer-status

MSDP Peer Information of VPN-Instance: public net
MSDP Peer 192.168.1.2, AS 200
Description:
Information about connection status:
State: Up
Up/down time: 00:15:47
Resets: 0
Connection interface: Pos5/0 (192.168.1.1)
Number of sent/received messages: 16/16
Number of discarded output messages: 0
Elapsed time since last connection or counters clear: 00:17:51
Information about (Source, Group)-based SA filtering policy:
Import policy: none
Export policy: none
Information about SA-Requests:
Policy to accept SA-Request messages: none
Sending SA-Requests status: disable
Minimum TTL to forward SA with encapsulated data: 0
SAs learned from this peer: 0, SA-cache maximum for the peer: none
Input queue size: 0, Output queue size: 0
Counters for MSDP message:
Count of RPF check failure: 0
Incoming/outgoing SA messages: 0/0
Incoming/outgoing SA requests: 0/0
Incoming/outgoing SA responses: 0/0
Incoming/outgoing data packets: 0/0
Anycast RP Network requirements

Configuration Example ■ The PIM-SM domain in this example has multiple multicast sources and
receivers. OSPF runs within the domain to provide unicast routes.
■ It is required that to configure the anycast RP application so that the
receiver-side DRs and the source-side DRs can initiate a Join message to their
respective RPs that are the topologically nearest to them.
■ On Router B and Router D, configure the interface Loopback 10 as a C-BSR,
and Loopback 20 as a C-RP.
■ The router ID of Router B is 1.1.1.1, while the router ID of Router D is 2.2.2.2.
Set up an MSDP peering relationship between Router B and Router D.

Network diagram
Figure 338 Network diagram for anycast RP application configuration
Source 1 Source 2
Router A Router C Router E
S2
PO
/0
/0
S5
S2
/0
S5
PO
/1
PO
/0
S5
S5
Receiver 1 Receiver 2
/0
S2
PO
/0
S2
/0
Router B Router D
Eth1/0 Eth1/0
Lo
20
0
Lo
op
op
op
o
Lo
p0
Lo
20
Loop 10 Loop 10
PIM-SM
MSDP peers
Source 1 - 10.110.5.100/24 Router C POS5/0 192.168.1.2/24
Source 2 - 10.110.6.100/24 POS5/1 192.168.2.2/24
Router A S2/0 10.110.2.2/24 Router D Eth1/0 10.110.3.1/24
Router B Eth1/0 10.110.1.1/24 S2/0 10.110.4.1/24
S2/0 10.110.2.1/24 POS5/0 192.168.2.1/24
POS5/0 192.168.1.1/24 Loop0 2.2.2.2/32
Loop0 1.1.1.1/32 Loop10 4.4.4.4/32
Loop10 3.3.3.3/32 Loop20 10.1.1.1/32
Loop20 10.1.1.1/32 Router E S2/0 10.110.4.2/24
Configure OSPF for interconnection between the routers. Detailed configuration

steps are omitted.
# Enable IP multicast routing on Router B, enable PIM-SM on each interface, and

enable IGMPv2 on the host-side interface Ethernet 1/0.

[RouterB-Ethernet1/0] pim sm
[RouterB-Serial2/0] pim sm
[RouterB-Pos5/0] pim sm
[RouterB-Pos5/0] quit
The configuration on Router A, Router C, Router D, and Router E is similar to the

configuration on Router B.
3 Configure the position of interface Loopback 10, Loopback 20, C-BSR, and C-RP.
# Configure different Loopback 10 addresses and identical Loopback 20 address

on Router B, configure C-BSR on each Loopback 10 and configure C-RP on each
Loopback 20.

[RouterB-LoopBack10] ip address 3.3.3.3 32
[RouterB-LoopBack10] pim sm
[RouterB-LoopBack10] quit
[RouterB] pim
[RouterB-pim] c-bsr loopback 10
[RouterB-pim] c-rp loopback 20
[RouterB-pim] quit
The configuration on Router D is similar to the configuration on Router B.
4 Configure Loopback 0 and MSDP peers
# Configure an MSDP peer on Loopback 0 of Router B.

[RouterB] msdp
[RouterB-msdp] originating-rp loopback 0
[RouterB-msdp] peer 2.2.2.2 connect-interface loopback 0
[RouterB-msdp] quit
# Configure an MSDP peer on Loopback 0 of Router D.
[RouterD] interface loopback 0

[RouterD-LoopBack0] ip address 2.2.2.2 32
[RouterD-LoopBack0] pim sm
[RouterD-LoopBack0] quit
[RouterD] msdp
[RouterD-msdp] originating-rp loopback 0
[RouterD-msdp] peer 1.1.1.1 connect-interface loopback 0
[RouterD-msdp] quit

You can use the display msdp brief command to view the brief information of
MSDP peering relationships between the routers.
# View the brief MSDP peer information on Router B.
[RouterB] display msdp brief

1 1 0 0 0 0

2.2.2.2 Up 00:10:17 ? 0 0
# View the brief MSDP peer information on Router D.

1 1 0 0 0 0

1.1.1.1 Up 00:10:18 ? 0 0
To view the PIM routing information on each router, use the display pim
routing-table command.
When Source 1 (10.110.5.100/24) sends multicast data to multicast group G

(225.1.1.1/24), Receiver 1 joins multicast group G. By comparing the PIM routing
information displayed on Router B with that displayed on Router D, you can see
that Router B acts now as the RP for Source 1 and Receiver 1.
# View the PIM routing information on Router B.
[RouterB] display pim routing-table

Vpn-instance: public net
Total 1 (*, G) entry; 1 (S, G) entry
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: WC
UpTime: 00:15:04
Upstream interface: Register
Upstream neighbor: NULL
RPF prime neighbor: NULL
Downstream interface(s) information:
Total number of downstreams: 1
1: Ethernet1/0
Protocol: igmp, UpTime: 00:15:04, Expires: -
(10.110.5.100, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:46:28
Upstream interface: Serial2/0
Upstream neighbor: 10.110.2.2
RPF prime neighbor: 10.110.2.2

1: Ethernet1/0
Protocol: pim-sm, UpTime: - , Expires: -
# View the PIM routing information on Router D.
[RouterD] display pim routing-table
No information is output on Router D.
Receiver 1 has left multicast group G, and Source 1 has stopped sending multicast
data to multicast group G. When Source 2 (10.110.6.100/24) sends multicast data
to G, Receiver 2 joins G. By comparing the PIM routing information displayed on
Router B with that displayed on Router D, you can see that Router D acts now as
the RP for Source 2 and Receiver 2.
# View the PIM routing information on Router B.
[RouterB] display pim routing-table
No information is output on Router B.
# View the PIM routing information on Router D.
[RouterD] display pim routing-table

Vpn-instance: public net
Total 1 (*, G) entry; 1 (S, G) entry
(*, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: WC
UpTime: 00:12:07
Upstream interface: Register
Upstream neighbor: NULL
RPF prime neighbor: NULL
1: Ethernet1/0
Protocol: igmp, UpTime: 00:12:07, Expires: -
(10.110.6.100, 225.1.1.1)
RP: 10.1.1.1 (local)
Protocol: pim-sm, Flag: SPT 2MSDP ACT
UpTime: 00:40:22
Upstream interface: Serial2/0
Upstream neighbor: 10.110.4.2
RPF prime neighbor: 10.110.4.2
1: Ethernet1/0
Protocol: pim-sm, UpTime: - , Expires: -
Static RPF Peer Network requirements

Configuration Example ■ Two ISPs maintain their ASs, AS 100 and AS 200 respectively. OSPF is running
within each AS, and BGP is running between the two ASs.

■ PIM-SM 1 belongs to AS 100, while PIM-SM 2 and PIM-SM 3 belong to AS

200.
■ Each PIM-SM domain has zero or one multicast source and one or more
receivers. OSPF runs within each domain to provide unicast routes.
■ PIM-SM 2 and PIM-SM 3 are both PIM stub domains, and BGP or MBGP is not
required between these two domains and PIM-SM 1. Instead, static RPF peers
are configured to avoid RPF check on SA messages.
■ It is required that the respective Loopback 0 of Router C, Router D and Router F
be configured as a C-BSR and C-RP of the respective PIM-SM domains.
■ It is required that Router D and Router F be configured as static RPF peers of
Router C, and Router C be configured as the only static RPF peer of Router D
and Router F, so that any router can receive SA messages only from its static
RPF peer(s) and permitted by the corresponding filtering policy.
Network diagram
Figure 339 Network diagram for static RPF peer configuration (on routers)
AS 100 AS 200
Receiver
Receiver
Loop 0
Router G
Source 1
0
/ Router F
S2
Router A
Source 3
PIM-SM 3
Receiver
Router B
0
Router D Router E
/
S2
POS 5/0 POS 5/0

Router C
Loop 0 Loop 0
Source 2
PIM-SM 2
PIM-SM 1
Static RPF peers

Router D POS5/0 192.168.1.2/24 Router C POS5/0 192.168.1.1/24
Loop0 2.2.2.2/32 S2/0 192.168.3.1/24
Router F S2/0 192.168.3.2/24 Loop0 1.1.1.1/32
Loop0 3.3.3.3/32

Configure OSPF for interconnection between the routers. Ensure the

network-layer interoperation among Router A, Router B and Router C in PIM-SM
1, the network-layer interoperation between Router D and Router E in PIM-SM 2,
and the network-layer interoperation between Router F and Router G in PIM-SM
3, and ensure the dynamic update of routing information between the routers in
each PIM-SM domain through a unicast routing protocol. Detailed configuration
steps are omitted.
Configure EBGP among Router C, Router D, Router C and Router F, and configure
mutual route redistribution between BGP and OSPF. Detailed configuration steps
are omitted.
# Enable IP multicast routing on Router C, and enable PIM-SM on each interface.
[RouterC-Pos5/0] pim sm
[RouterC-Serial2/0] pim sm
The configuration on Router A, Router B, Router D, Router E, Router F and Router

G is similar to the configuration on Router C.
# Configure a BSR admin-scope region boundary on Router C.
[RouterC-Serial2/0] pim bsr-boundary

[RouterC-Pos5/0] pim bsr-boundary

Router C.
3 Configure the position of interface Loopback0, C-BSR, and C-RP.
# Configure the position of Loopback0, C-BSR, and C-RP on Router C.
[RouterC] router-id 1.1.1.1

[RouterC-LoopBack0] ip address 1.1.1.1 255.255.255.255
[RouterC-LoopBack0] pim sm
[RouterC-LoopBack0] quit
[RouterC] pim
[RouterC-pim] c-bsr loopback 0
[RouterC-pim] c-rp loopback 0
[RouterC-pim] quit

Router C.
4 Configure static RPF peers

# Configure Router D and Router F as MSDP peers and static RPF peers of Router
C.
[RouterC] ip ip-prefix list-df permit 192.168.0.0 16 greater-equal 1

6 less-equal 32
[RouterC] msdp
[RouterC-msdp] peer 192.168.3.2 connect-interface serial 2/0
[RouterC-msdp] peer 192.168.1.2 connect-interface pos 5/0
[RouterC-msdp] static-rpf-peer 192.168.3.2 rp-policy list-df
[RouterC-msdp] static-rpf-peer 192.168.1.2 rp-policy list-df
[RouterC-msdp] quit
# Configure Router C as MSDP peer and static RPF peer of Router D.
[RouterD] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16

less-equal 32
[RouterD] msdp
[RouterD-msdp] peer 192.168.1.1 connect-interface pos 5/0
[RouterD-msdp] static-rpf-peer 192.168.1.1 rp-policy list-c
[RouterD-msdp] quit
# Configure Router C as MSDP peer and static RPF peer of Router F.
[RouterF] ip ip-prefix list-c permit 192.168.0.0 16 greater-equal 16

less-equal 32
[RouterF] msdp
[RouterF-msdp] peer 192.168.3.1 connect-interface serial 2/0
[RouterF-msdp] static-rpf-peer 192.168.3.1 rp-policy list-c
[RouterF-msdp] quit
Carry out the display bgp peer command to view the BGP peering relationships
between the routers. If the command gives no output information, a BGP peering
relationship has not been established between the routers.
When the multicast source (Source 1) in PIM-SM 1 sends multicast information,

receivers in PIM-SM 2 and PIM-SM 3 can receive the multicast data. You can use
the display msdp brief command to view the brief information of MSDP peering
relationships between the routers. For example:
# View the brief MSDP peer information on Router C.
[RouterC] display msdp brief

2 2 0 0 0 0

192.168.3.2 Up 01:07:08 ? 8 0
192.168.1.2 Up 00:16:39 ? 13 0
# View the brief MSDP peer information on Router D.

1 1 0 0 0 0


192.168.1.1 Up 01:07:09 ? 8 0
# View the brief MSDP peer information on Router F.
[RouterF] display msdp brief

1 1 0 0 0 0

192.168.3.1 Up 00:16:40 ? 13 0
Troubleshooting
MSDP
MSDP Peers Stay in Symptom

Down State The configured MSDP peers stay in the down state.
Analysis
■ A TCP connection-based MSDP peering relationship is established between the
local interface address and the MSDP peer after the configuration.
■ The TCP connection setup will fail if there is an inconsistency between the local
interface address and the MSDP peer address configured on the router.
■ If no route is available between the MSDP peers, the TCP connection setup will
also fail.
Solution
1 Check that a route is available between the routers. Carry out the display ip
routing-table command to check whether the unicast route between the routers
is correct.
2 Check that a unicast route is available between the two routers that will become
MSDP peers to each other.
3 Verify the interface address consistency between the MSDP peers. Use the display
current-configuration command to verify that the local interface address and
the MSDP peer address of the remote router are the same.
No SA Entries in the Symptom

Router’s SA Cache MSDP fails to send (S, G) entries through SA messages.
Analysis
■ The import-source command is used to control sending (S, G) entries through
SA messages to MSDP peers. If this command is executed without the
acl-number argument, all the (S, G) entries will be filtered off, namely no (S, G)
entries of the local domain will be advertised.
■ If the import-source command is not executed, the system will advertise all
the (S, G) entries of the local domain. If MSDP fails to send (S, G) entries
through SA messages, check whether the import-source command has been
correctly configured.

Troubleshooting MSDP 1159
Solution
is correct.
MSDP peers to each other.
3 Check configuration of the import-source command and its acl-number
argument and make sure that ACL rule can filter appropriate (S, G) entries.
Inter-RP Communication Symptom

Faults in Anycast RP RPs fail to exchange their locally registered (S, G) entries with one another in the
Application Anycast RP application.
Analysis
■ In the Anycast RP application, RPs in the same PIM-SM domain are configured
to be MSDP peers to achieve load balancing among the RPs.
■ An MSDP peer address must be different from the anycast RP address, and the
C-BSR and C-RP must be configured on different devices or interfaces.
■ If the originating-rp command is executed, MSDP will replace the RP address
in the SA messages with the address of the interface specified in the command.
■ When an MSDP peer receives an SA message, it performs RPF check on the
message. If the MSDP peer finds that the remote RP address is the same as the
local RP address, it will discard the SA message.
Solution
is correct.
MSDP peer to each other.
3 Check the configuration of the originating-rp command. In the Anycast RP
application environment, be sure to use the originating-rp command to
configure the RP address in the SA messages, which must be the local interface
address.
4 Verify that the C-BSR address is different from the anycast RP address.


PIM CONFIGURATION
71
When configuring PIM, go to these sections for information you are interested in:
■ “PIM Overview” on page 1161
■ “Configuring PIM-DM” on page 1173
■ “Configuring PIM-SM” on page 1176
■ “Configuring PIM-SSM” on page 1185
■ “Configuring PIM Common Information” on page 1187
■ “Displaying and Maintaining PIM” on page 1192
■ “PIM Configuration Examples” on page 1193
■ “Troubleshooting PIM Configuration” on page 1205
PIM Overview Protocol Independent Multicast (PIM) provides IP multicast forwarding by

leveraging static routes or unicast routing tables generated by any unicast routing
protocol, such as routing information protocol (RIP), open shortest path first
(OSPF), intermediate system to intermediate system (IS-IS), or border gateway
protocol (BGP). Independent of the unicast routing protocols running on the
device, multicast routing can be implemented as long as the corresponding
multicast routing entries are created through unicast routes. PIM uses the reverse
path forwarding (RPF) mechanism to implement multicast forwarding. When a
multicast packet arrives on an interface of the device, it is subject to an RPF check.
If the RPF check succeeds, the device creates the corresponding routing entry and
forwards the packet; if the RPF check fails, the device discards the packet. For
more information about RPF, refer to “Multicast Routing and Forwarding
Based on the forwarding mechanism, PIM falls into two modes:
■ Protocol Independent Multicast-Dense Mode (PIM-DM), and

■ Protocol Independent Multicast-Sparse Mode (PIM-SM).
n To facilitate description, a network comprising PIM-capable routers is referred to

as a “PIM domain” in this document.
Introduction to PIM-DM PIM-DM is a type of dense mode multicast protocol. It uses the “push mode” for
multicast forwarding, and is suitable for small-sized networks with densely
distributed multicast members.
The basic implementation of PIM-DM is as follows:

1162 CHAPTER 71: PIM CONFIGURATION
■ PIM-DM assumes that at least one multicast group member exists on each
subnet of a network, and therefore multicast data is flooded to all nodes on
the network. Then, branches without multicast forwarding are pruned from
the forwarding tree, leaving only those branches that contain receivers. This
“flood and prune” process takes place periodically, that is, pruned branches
resume multicast forwarding when the pruned state times out and then data is
re-flooded down these branches, and then are pruned again.
■ When a new receiver on a previously pruned branch joins a multicast group, to
reduce the join latency, PIM-DM uses a graft mechanism to resume data
forwarding to that branch.
Generally speaking, the multicast forwarding path is a source tree, namely a

forwarding tree with the multicast source as its “root” and multicast group
members as its “leaves”. Because the source tree is the shortest path from the
multicast source to the receivers, it is also called shortest path tree (SPT).
How PIM-DM Works The working mechanism of PIM-DM is summarized as follows:

■ Neighbor discovery
■ SPT establishment
■ Graft
■ Assert
Neighbor discovery
In a PIM domain, a PIM router discovers PIM neighbors, maintains PIM neighboring
relationships with other routers, and builds and maintains SPTs by periodically
multicasting hello messages to all other PIM routers (224.0.0.13).
n Every activated interface on a router sends hello messages periodically, and thus
learns the PIM neighboring information pertinent to the interface.
SPT establishment
The process of building an SPT is the process of “flood and prune”.
1 In a PIM-DM domain, when a multicast source S sends multicast data to a
multicast group G, the multicast packet is first flooded throughout the domain:
The router first performs RPF check on the multicast packet. If the packet passes
the RPF check, the router creates an (S, G) entry and forwards the data to all
downstream nodes in the network. In the flooding process, an (S, G) entry is
created on all the routers in the PIM-DM domain.
2 Then, nodes without receivers downstream are pruned: A router having no
receivers downstream sends a prune message to the upstream node to tell the
upstream node to delete the corresponding interface from the outgoing interface
list in the (S, G) entry and stop forwarding subsequent packets addressed to that
multicast group down to this node.
n ■ An (S, G) entry contains the multicast source address S, multicast group

address G, outgoing interface list, and incoming interface.
■ For a given multicast stream, the interface that receives the multicast stream is
referred to as “upstream”, and the interfaces that forward the multicast stream
are referred to as “downstream”.

PIM Overview 1163
A prune process is first initiated by a leaf router. As shown in Figure 340, a router
without any receiver attached to it (the router connected with Host A, for
example) sends a prune message, and this prune process goes on until only
necessary branches are left in the PIM-DM domain. These branches constitute the
SPT.
Figure 340 SPT establishment
Host A
Source Receiver
Server Host B
Receiver
SPT
Prune message
Multicast packets
Host C
The “flood and prune” process takes place periodically. A pruned state timeout
mechanism is provided. A pruned branch restarts multicast forwarding when the
pruned state times out and then is pruned again when it no longer has any
multicast receiver.
n Pruning has a similar implementation in PIM-SM.
Graft
When a host attached to a pruned node joins a multicast group, to reduce the join
latency, PIM-DM uses a graft mechanism to resume data forwarding to that
branch. The process is as follows:
1 The node that needs to receive multicast data sends a graft message hop by hop
toward the source, as a request to join the SPT again.
2 Upon receiving this graft message, the upstream node puts the interface on which
the graft was received into the forwarding state and responds with a graft-ack
message to the graft sender.
3 If the node that sent a graft message does not receive a graft-ack message from its
upstream node, it will keep sending graft messages at a configurable interval until
it receives an acknowledgment from its upstream node.
Assert
If multiple multicast routers exist on a multi-access subnet, duplicate packets may
flow to the same subnet. To shut off duplicate flows, the assert mechanism is used
for election of a single multicast forwarder on a multi-access network.

Figure 341 Assert mechanism
Router A Router B
Ethernet
Assert message
Multicast packets Receiver
Router C
As shown in Figure 341, after Router A and Router B receive an (S, G) packet from
the upstream node, they both forward the packet to the local subnet. As a result,
the downstream node Router C receives two identical multicast packets, and both
Router A and Router B, on their own local interface, receive a duplicate packet
forwarded by the other. Upon detecting this condition, both routers send an assert
message to all PIM routers (224.0.0.13) through the interface on which the packet
was received. The assert message contains the following information: the
multicast source address (S), the multicast group address (G), and the preference
and metric of the unicast route to the source. By comparing these parameters,
either Router A or Router B becomes the unique forwarder of the subsequent (S,
G) packets on the multi-access subnet. The comparison process is as follows:
1 The router with a higher unicast route preference to the source wins;
2 If both routers have the same unicast route preference to the source, the router
with a smaller metric to the source wins;
3 If there is a tie in route metric to the source, the router with a higher IP address of
the local interface wins.
Introduction to PIM-SM PIM-DM uses the “flood and prune” principle to build SPTs for multicast data
distribution. Although an SPT has the shortest path, it is built with a low efficiency.
Therefore the PIM-DM mode is not suitable for large- and medium-sized networks.
PIM-SM is a type of sparse mode multicast protocol. It uses the “pull mode” for
multicast forwarding, and is suitable for large- and medium-sized networks with
sparsely and widely distributed multicast group members.
The basic implementation of PIM-SM is as follows:
■ PIM-SM assumes that no hosts need to receive multicast data. In the PIM-SM
mode, routers must specifically request a particular multicast stream before the
data is forwarded to them. The core task for PIM-SM to implement multicast
forwarding is to build and maintain rendezvous point trees (RPTs). An RPT is
rooted at a router in the PIM domain as the common node, or rendezvous
point (RP), through which the multicast data travels along the RPT and reaches
the receivers.

PIM Overview 1165
■ When a receiver is interested in the multicast data addressed to a specific

multicast group, the router connected to this receiver sends a join message to
the RP corresponding to that multicast group. The path along which the
message goes hop by hop to the RP forms a branch of the RPT.
■ When a multicast source sends a multicast packet to a multicast group, the
router directly connected with the multicast source first registers the multicast
source with the RP by sending a register message to the RP by unicast. The
arrival of this message at the RP triggers the establishment of an SPT. Then, the
multicast source sends subsequent multicast packets along the SPT to the RP.
Upon reaching the RP, the multicast packet is duplicated and delivered to the
receivers along the RPT.
n Multicast traffic is duplicated only where the distribution tree branches, and this
process automatically repeats until the multicast traffic reaches the receivers.
How PIM-SM Works The working mechanism of PIM-SM is summarized as follows:

■ DR election
■ RP discovery
■ RPT building
■ Multicast source registration
■ Switchover from RPT to SPT
■ Assert
Neighbor discovery
PIM-SM uses exactly the same neighbor discovery mechanism as PIM-DM does.
Refer to “Neighbor discovery” on page 1162.
DR election
PIM-SM also uses hello messages to elect a designated router (DR) for a
multi-access network. The elected DR will be the only multicast forwarder on this
multi-access network.
A DR must be elected in a multi-access network, no matter this network connects

to multicast sources or to receivers. The DR at the receiver side sends join
messages to the RP; the DR at the multicast source side sends register messages to
the RP.
n ■ A DR is elected on a multi-access subnet by means of comparison of the

priorities and IP addresses carried in hello messages. An elected DR is
substantially meaningful to PIM-SM. PIM-DM itself does not require a DR.
However, if IGMPv1 runs on any multi-access network in a PIM-DM domain, a
DR must be elected to act as the IGMPv1 querier on that multi-access network.
■ IGMP must be enabled on a device that acts as a DR before receivers attached
to this device can join multicast groups through this DR.
For details about IGMP, refer to “IGMP Configuration” on page 1115.

Figure 342 DR election
Receiver
Ethernet
Ethernet
DR
DR RP
Source
Receiver
Hello message
Register message
Join message
As shown in Figure 342, the DR election process is as follows:
1 Routers on the multi-access network send hello messages to one another. The
hello messages contain the router priority for DR election. The router with the
highest DR priority will become the DR.
2 In the case of a tie in the router priority, or if any router in the network does not
support carrying the DR-election priority in hello messages, The router with the
highest IP address will win the DR election.
When the DR fails, a timeout in receiving hello message triggers a new DR election
process among the other routers.
RP discovery
The RP is the core of a PIM-SM domain. For a small-sized, simple network, one RP
is enough for forwarding information throughout the network, and the position of
the RP can be statically specified on each router in the PIM-SM domain. In most
cases, however, a PIM-SM network covers a wide area and a huge amount of
multicast traffic needs to be forwarded through the RP. To lessen the RP burden
and optimize the topological structure of the RPT, each multicast group should
have its own RP. Therefore, a bootstrap mechanism is needed for dynamic RP
election. For this purpose, a bootstrap router (BSR) should be configured.
As the administrative core of a PIM-SM domain, the BSR collects advertisement

messages (C-RP-Adv messages) from candidate-RPs (C-RPs) and chooses the
appropriate C-RP information for each multicast group to form an RP-set, which is
a database of mappings between multicast groups and RPs. The BSR then floods
the RP-set to the entire PIM-SM domain. Based on the information in these
RP-sets, all routers (including the DRs) in the network can calculate the location of
the corresponding RPs.
A PIM-SM domain (or an administratively scoped region) can have only one BSR,
but can have multiple candidate-BSRs (C-BSRs). Once the BSR fails, a new BSR is
automatically elected from the C-BSRs through the bootstrap mechanism to avoid
service interruption. Similarly, multiple C-RPs can be configured in a PIM-SM

PIM Overview 1167
domain, and the position of the RP corresponding to each multicast group is

calculated through the BSR mechanism.
Figure 343 shows the positions of C-RPs and the BSR in the network.
Figure 343 BSR and C-RPs
PIM-SM
BSR
C-RP
C-RP C-BSR
C-RP
BSR message
Advertisement message
RPT building
Figure 344 RPT establishment in a PIM-SM domain
Host A
Source Receiver
RP DR
Server Host B
DR
Receiver
RPT
Join message
Multicast packets
Host C
As shown in Figure 344, the process of building an RPT is as follows:
1 When a receiver joins a multicast group G, it uses an IGMP message to inform the
directly connected DR.
2 Upon getting the receiver information, the DR sends a join message, which is hop
by hop forwarded to the RP corresponding to the multicast group.
3 The routers along the path from the DR to the RP form an RPT branch. Each router
on this branch generates a (*, G) entry in its forwarding table. The * means any
multicast source. The RP is the root, while the DRs are the leaves, of the RPT.

The multicast data addressed to the multicast group G flows through the RP,
reaches the corresponding DR along the established RPT, and finally is delivered to
the receiver.
When a receiver is no longer interested in the multicast data addressed to a

multicast group G, the directly connected DR sends a prune message, which goes
hop by hop along the RPT to the RP. Upon receiving the prune message, the
upstream node deletes its link with this downstream node from the outgoing
interface list and checks whether it itself has receivers for that multicast group. If
not, the router continues to forward the prune message to its upstream router.
Multicast source registration

The purpose of multicast source registration is to inform the RP about the
existence of the multicast source.
Figure 345 Multicast registration
Host A
Source Receiver
DR RP
Server Host B
Receiver
SPT
Join message
Register message
Host C
Multicast packets
As shown in Figure 345, the multicast source registers with the RP as follows:
1 When the multicast source S sends the first multicast packet to a multicast group
G, the DR directly connected with the multicast source, upon receiving the
multicast packet, encapsulates the packet in a PIM register message, and sends
the message to the corresponding RP by unicast.
2 When the RP receives the register message, it extracts the multicast packet from
the register message and forwards the multicast packet down the RPT, and it
sends an (S, G) join message hop by hop toward the multicast source. Thus, the
routers along the path from the RP to the multicast source constitute an SPT
branch. Each router on this branch generates an (S, G) entry in its forwarding
table. The multicast source is the root, while the RP is the leaf, of the SPT.
3 The subsequent multicast data from the multicast source travels along the
established SPT to the RP, and then the RP forwards the data along the RPT to the
receivers. When the multicast traffic arrives at the RP along the SPT, the RP sends a
register-stop message to the source-side DR by unicast to stop the source
registration process.

PIM Overview 1169
Switchover from RPT to SPT

Initially, multicast traffic flows along an RPT from the RP to the receivers. Because
the RPT is not necessarily the tree that has the shortest path, upon receiving the
first multicast packet along the RPT (by default), or when detecting that the
multicast traffic rate reaches a configurable threshold (if so configured), the
receiver-side DR initiates an RPT-to-SPT switchover process, as follows:
1 First, the receiver-side DR sends an (S, G) join message hop by hop to the multicast
source. When the join message reaches the source-side DR, all the routers on the
path have installed the (S, G) entry in their forwarding table, and thus an SPT
branch is established.
2 Subsequently, the receiver-side DR sends a prune message containing the RP bit
hop by hop to the RP. Upon receiving this prune message, the RP forwards it
toward the multicast source (suppose only one receiver exists), thus to implement
RPT-to-SPT switchover.
After the RPT-to-SPT switchover, multicast data can be directly sent from the
source to the receivers. PIM-SM builds SPTs through RPT-to-SPT switchover more
economically than PIM-DM does through the “flood and prune” mechanism.
Assert
PIM-SM uses exactly the same assert mechanism as PIM-DM does. Refer to
“Assert” on page 1163.
Introduction to BSR Division of PIM-SM domains

Admin-scope Regions in Typically, a PIM-SM domain contains only one BSR, which is responsible for
PIM-SM advertising RP-set information within the entire PIM-SM domain. The information
for all multicast groups is forwarded within the network scope administered by the
BSR.
To implement refined management and group-specific services, a PIM-SM domain

can be divided into one global scope zone and multiple BSR administratively
scoped regions (BSR admin-scope regions).
Specific to particular multicast groups, the BSR administrative scoping mechanism

effectively lessens the management workload of a single-BSR domain and provides
group-specific services.
Relationship between BSR admin-scope regions and the global scope zone
A better understanding of the global scope zone and BSR admin-scope regions
should be based on two aspects: geographical space and group address range.
1 Geographical space
BSR admin-scope regions are logical regions specific to particular multicast groups,
and each BSR admin-scope region must be geographically independent of every
other one, as shown in Figure 346.

Figure 346 Relationship between BSR admin-scope regions and the global scope zone in
geographic space
C-RP BSR
C-RP BSR BSR 2 C-RP BSR
BSR 1 BSR 3
C-RP BSR
Global
C-RP BSR C-RP BSR
BSR admin-scope regions are geographically separated from one another. Namely,
a router must not serve different BSR admin-scope regions. In other words,
different BSR admin-scope regions contain different routers, whereas the global
scope zone covers all routers in the PIM-SM domain.
2 In terms of multicast group address ranges
Each BSR admin-scope region serves specific multicast groups. Usually, these
addresses have no intersections; however, they may overlap one another.
Figure 347 Relationship between BSR admin-scope regions and the global scope zone in
group address ranges
BSR 1 BSR 3
G1 address G3 address
Global BSR 2
G-G1-G2 address G2 address
In Figure 347, the group address ranges of admin-scope-scope regions BSR1 and
BSR2 have no intersection, whereas the group address range of BSR3 is a subset of
the address range of BSR1. The group address range of the global scope zone
covers all the group addresses other than those of all the BSR admin-scope
regions. That is, the group address range of the global scope zone is G-G1-G2. In
other words, there is a supplementary relationship between the global scope zone
and all the BSR admin-scope regions in terms of group address ranges.

PIM Overview 1171
Relationships between BSR admin-scope regions and the global scope zone are as
follows:
■ The global scope zone and each BSR admin-scope region have their own C-RPs
and BSR. These devices are effective only in their respective admin-scope
regions. Namely, the BSR election and RP election are implemented
independently within each admin-scope region.
■ Each BSR admin-scope region has its own boundary. The multicast information
(such as C-RP-Adv messages and BSR bootstrap messages) can be transmitted
only within the domain.
■ Likewise, the multicast information in the global scope zone cannot enter any
BSR admin-cope region.
■ In terms of multicast information propagation, BSR admin-scope regions are
independent of one another and each BSR admin-scope region is independent
of the global scope zone, and no overlapping is allowed between any two BSR
admin-scope regions.
SSM Model The source-specific multicast (SSM) model and the any-source multicast (ASM)
Implementation in PIM model are two opposite models. Presently, the ASM model includes the PIM-DM
and PIM-SM modes. The SSM model can be implemented by leveraging part of
the PIM-SM technique.
The SSM model provides a solution for source-specific multicast. It maintains the
relationships between hosts and routers through IGMPv3.
In actual application, part of the PIM-SM technique is adopted to implement the

SSM model. In the SSM model, receivers know exactly where a multicast source is
located by means of advertisements, consultancy, and so on. Therefore, no RP is
needed, no RPT is required, there is no source registration process, and there is no
need of using the multicast source discovery protocol (MSDP) for discovering
sources in other PIM domains.
Compared with the ASM model, the SSM model only needs the support of
IGMPv3 and some subsets of PIM-SM. The operation mechanism of PIM-SSM can
be summarized as follows:
■ DR election
■ SPT building
Neighbor discovery
PIM-SSM uses the same neighbor discovery mechanism as in PIM-DM and
PIM-SM. Refer to “Neighbor discovery” on page 1162.
DR election
PIM-SSM uses the same DR election mechanism as in PIM-SM. Refer to “DR
election” on page 1165.

Construction of SPT
Whether to build an RPT for PIM-SM or an SPT for PIM-SSM depends on whether
the multicast group the receiver is to join falls in the SSM group address range
(SSM group address range reserved by IANA is 232.0.0.0/8).
Figure 348 SPT establishment in PIM-SSM
Host A
Source Receiver
RP DR
Server Host B
DR
Receiver
SPT
Subscribe message
Multicast packets
Host C
As shown in Figure 348, Host B and Host C are multicast information receivers.
They send IGMPv3 report messages denoted as (Include S, G) to the respective DRs
to express their interest in the information of the specific multicast source S. If they
need information from other sources than S, they send an (Exclude S, G) report.
No matter what the description is, the position of multicast source S is explicitly
specified for receivers.
The DR that has received the report first checks whether the group address in this
message falls in the SSM group address range:
■ If so, the DR sends a subscribe message for channel subscription hop by hop
toward the multicast source S. An (Include S, G) or (Exclude S, G) entry is
created on all routers on the path from the DR to the source. Thus, an SPT is
built in the network, with the source S as its root and receivers as its leaves.
This SPT is the transmission channel in PIM-SSM.
■ If not, the PIM-SM process is followed: the DR needs to send a (*, G) join
message to the RP, and a multicast source registration process is needed.
n In PIM-SSM, the “channel” concept is used to refer to a multicast group, and the
“channel subscription” concept is used to refer to a join message.
Multi-Instance PIM A multicast router running multiple instances maintains an independent set of PIM
neighbor table, multicast routing table, BSR information and RP-set information
for each instance. To the outside, the router appears to be a group of multicast
routers, each running PIM independently from the others.
Upon receiving a multicast protocol packet, the multicast router determines the
VPN instance this protocol packet belongs to and passes the packet to PIM

corresponding to that VPN instance for processing. Upon receiving a multicast

data packet, the multicast router determines the VPN instance the data packet
belongs to, and then forwards the packet as per the multicast routing table of that
VPN instance or creates a multicast routing table entry for that VPN instance.
Protocols and Standards PIM-related specifications are as follows:

■ RFC 2362: Protocol Independent Multicast-sparse Mode (PIM-SM): Protocol
Specification
■ RFC 3973: Protocol Independent Multicast-Dense Mode (PIM-DM): Protocol
Specification(Revised)
■ draft-ietf-pim-sm-v2-new-06: Protocol Independent Multicast-Sparse Mode
(PIM-SM)
■ draft-ietf-pim-dm-new-v2-02: Protocol Independent Multicast-Dense Mode
(PIM-DM)
■ draft-ietf-pim-v2-dm-03: Protocol Independent Multicast Version 2 Dense
Mode Specification
■ draft-ietf-pim-sm-bsr-03: Bootstrap Router (BSR) Mechanism for PIM Sparse
Mode
■ draft-ietf-ssm-arch-02: Source-Specific Multicast for IP
■ draft-ietf-ssm-overview-04: An Overview of Source-Specific Multicast (SSM)
Configuring PIM-DM
PIM-DM Configuration Complete these tasks to configure PIM-DM:

Task List
Task Remarks
“Enabling PIM-DM” on page 1173 Required
“Enabling State Refresh” on page 1174 Optional
“Configuring State Refresh Parameters” on page 1175 Optional
“Configuring PIM-DM Graft Retry Period” on page 1175 Optional
“Configuring PIM Common Information” on page 1187 Optional
Configuration Before configuring PIM-DM, complete the following task:

Before configuring PIM-DM, prepare the following data:
■ The interval between state refresh messages

■ Minimum time to wait before receiving a new refresh message
■ TTL value of state refresh messages
■ Graft retry period
Enabling PIM-DM With PIM-DM enabled, a router sends hello messages periodically to discover PIM
neighbors and processes messages from PIM neighbors. When deploying a

PIM-DM domain, you are recommended to enable PIM-DM on all interfaces of

non-border routers (border routers are PIM-enabled routers located on the
boundary of BSR admin-scope regions).
Enabling PIM-DM globally in the public instance

Follow these steps to enable PIM-DM globally in the public instance:

Disable by default
interface-number
Enable PIM-DM pim dm Required
Disabled by default
Enabling PIM-DM in a VPN instance

Follow these steps to enable PIM-DM in a VPN instance:

Disabled by default
interface-number
Enable PIM-DM pim dm Required
Disabled by default
c CAUTION:
■ All the interfaces in the same VPN instance on the same device must work in
the same PIM mode.
■ PIM-DM cannot be used for multicast groups in the SSM group grange.
Enabling State Refresh An interface without the state refresh capability cannot forward state refresh
messages.
Follow these steps to enable the state refresh capability:

interface-number


Enable state refresh pim state-refresh-capable Optional
Enabled by default
Configuring State To avoid the resource-consuming reflooding of unwanted traffic caused by

Refresh Parameters timeout of pruned interfaces, the router directly connected with the multicast
source periodically sends an (S, G) state refresh message, which is forwarded hop
by hop along the initial multicast flooding path of the PIM-DM domain, to refresh
the prune timer state of all the routers on the path.
A router may receive multiple state refresh messages within a short time, of which
some may be duplicated messages. To keep a router from receiving such
duplicated messages, you can configure the time the router must wait before
receiving the next state refresh message. If a new state refresh message is received
within the waiting time, the router will discard it; if this timer times out, the router
will accept a new state refresh message, refresh its own PIM state, and reset the
waiting timer.
The TTL value of a state refresh message decrements by 1 whenever it passes a

router before it is forwarded to the downstream node until the TTL value comes
down to 0. In a small network, a state refresh message may cycle in the network.
To effectively control the propagation scope of state refresh messages, you need
to configure an appropriate TTL value based on the network size.
Follow these steps to configure state refresh parameters:

Enter public instance PIM view pim [ vpn-instance -
or VPN instance PIM view vpn-instance-name ]
Configure the interval state-refresh-interval Optional
between state refresh interval
messages
Configure the time to wait state-refresh-rate-limit Optional
before receiving a new state interval
refresh message
Configure the TTL value of state-refresh-ttl ttl-value Optional
state refresh messages
255 by default
Configuring PIM-DM In PIM-DM, graft is the only type of message that uses the acknowledgment
Graft Retry Period mechanism. In a PIM-DM domain, if a router does not receive a graft-ack message
from the upstream router within the specified time after it sends a graft message,
the router keeps sending new graft messages at a configurable interval, namely
graft retry period, until it receives a graft-ack from the upstream router.
Follow these steps to configure graft retry period:



interface-number
Configure graft retry period pim timer graft-retry Optional
interval
n For the configuration of other timers in PIM-DM, refer to “Configuring PIM

Common Timers” on page 1190.
Configuring PIM-SM
n A device can serve as a C-RP and a C-BSR at the same time.
PIM-SM Configuration Complete these tasks to configure PIM-SM:

Task List
Task Remarks
“Configuring PIM-SM” on page 1176 Required
“Configuring a BSR” on page “Performing basic C-BSR Optional
1178 configuration” on page 1178
“Configuring a global-scope Optional
C-BSR” on page 1179
“Configuring an Optional
admin-scope C-BSR” on
page 1180
“Configuring a BSR Optional
admin-scope region
boundary” on page 1180
“Configuring global C-BSR Optional
parameters” on page 1181
“Configuring an RP” on page “Configuring a static RP” on Optional
1182 page 1182
“Configuring a C-RP” on Optional
page 1182
“Enabling auto-RP” on page Optional
1183
“Configuring C-RP timers” Optional
on page 1183
“Configuring PIM-SM Register Messages” on page 1184 Optional
“Configuring RPT-to-SPT Switchover” on page 1185 Optional
“Configuring PIM Common Information” on page 1187 Optional
Configuration Before configuring PIM-SM, complete the following task:

Before configuring PIM-SM, prepare the following data:
■ An ACL rule defining a legal BSR address range

■ Hash mask length for RP selection calculation

■ C-BSR priority
■ Bootstrap interval
■ Bootstrap timeout time
■ An ACL rule defining a legal C-RP address range and the range of multicast
groups to be served
■ C-RP-Adv interval
■ C-RP timeout time
■ The IP address of a static RP
■ An ACL rule for register message filtering
■ Register suppression time
■ Register probe time
■ The multicast traffic rate threshold, ACL rule, and sequencing rule for
RPT-to-SPT switchover
■ The interval of checking the traffic rate threshold before RPT-to-SPT switchover
Enabling PIM-SM With PIM-SM enabled, a router sends hello messages periodically to discover PIM
neighbors and processes messages from PIM neighbors. When deploying a
PIM-SM domain, you are recommended to enable PIM-SM on all interfaces of
non-border routers (border routers are PIM-enabled routers located on the
boundary of BSR admin-scope regions).
Enabling PIM-SM globally in the public instance

Follow these steps to enable PIM-SM in the public instance:

Disable by default
interface-number
Enable PIM-SM pim sm Required
Disabled by default
Enabling PIM-SM in a VPN instance

Follow these steps to enable PIM-SM in a VPN instance:



Disabled by default
interface-number
Enable PIM-SM pim sm Required
Disabled by default
c CAUTION: All the interfaces in the same VPN instance on the same router must
work in the same PIM mode.
Configuring a BSR
n The BSR is dynamically elected from a number of C-BSRs. Because it is

unpredictable which router will finally win a BSR election, the commands
introduced in this section must be configured on all C-BSRs.
About the Hash mask length and C-BSR priority for RP selection calculation
■ You can configure these parameters at three levels: global configuration level,
global scope level, and BSR admin-scope level.
■ By default, the global scope parameters and BSR admin-scope parameters are
those configured at the global configuration level.
■ Parameters configured at the global scope level or BSR admin-scope level have
higher priority than those configured at the global configuration level.
Performing basic C-BSR configuration

A PIM-SM domain can have only one BSR, but must have at least one C-BSR. Any
router can be configured as a C-BSR. Elected from C-BSRs, a BSR is responsible for
collecting and advertising RP information in the PIM-SM.
C-BSRs should be configured on routers in the backbone network. When

configuring a router as a C-BSR, be sure that this router is PIM-SM enabled. The
BSR election process is as follows:
■ Initially, every C-BSR assumes itself to be the BSR of this PIM-SM domain, and
uses its interface IP address as the BSR address to send bootstrap messages.
■ When a C-BSR receives the bootstrap message of another C-BSR, it first
compares its own priority with the other C-BSR’s priority carried in the
message. The C-BSR with a higher priority wins. If there is a tie in the priority,
the C-BSR with a higher IP address wins. The loser uses the winner’s BSR
address to replace its own BSR address and no longer assumes itself to be the
BSR, while the winner keeps its own BSR address and continues assuming itself
to be the BSR.
Configuring a legal range of BSR addresses enables filtering of BSR messages

based on the address range, thus to prevent malicious hosts from initiating attacks
by disguising themselves as legitimate BSRs. To protect legitimate BSRs from being

maliciously replaced, preventive measures are taken specific to the following two
situations:
1 Some malicious hosts intend to fool routers by forging BSR messages and change
the RP mapping relationship. Such attacks often occur on border routers. Because
a BSR is inside the network whereas hosts are outside the network, you can
protect a BSR against attacks from external hosts by enabling border routers to
perform neighbor check and RPF check on BSR messages and discard unwanted
messages.
2 When a router in the network is controlled by an attacker or when an illegal router
is present in the network, the attacker can configure such a router to be a C-BSR
and make it win BSR election so as to gain the right of advertising RP information
in the network. After being configured as a C-BSR, a router automatically floods
the network with BSR messages. As a BSR message has a TTL value of 1, the whole
network will not be affected as long as the neighbor router discards these BSR
messages. Therefore, if a legal BSR address range is configured on all routers in the
entire network, all routers will discard BSR messages from out of the legal address
range, and thus this kind of attacks can be prevented.
The above-mentioned preventive measures can partially protect the security of

BSRs in a network. However, if a legal BSR is controlled by an attacker, the
above-mentioned problem will also occur.
Follow these steps to complete basic C-BSR configuration:

Configure an interface as a c-bsr interface-type Required
C-BSR interface-number
No C-BSR is configured by
[ hash-length [ priority ] ]
default
Configure a legal BSR address bsr-policy acl-number Optional
range
No restrictions on BSR address
range by default
n ■ Since a large amount of information needs to be exchanged between a BSR

and the other devices in the PIM-SM domain, a relatively large bandwidth
should be provided between the C-BSR and the other devices in the PIM-SM
domain.
■ For BSRs interconnected via a Generic Routing Encapsulation (GRE) tunnel,
multicast static routes need to be configured to ensure that the next hop to a
BSR is a GRE interface. For more information about multicast static routes, refer
to “Multicast Routing and Forwarding Configuration” on page 1097.
Configuring a global-scope C-BSR

Follow these steps to configure a global-scope C-BSR:



Configure a global-scope c-bsr global [ hash-length Required
C-BSR hash-length | priority
No global-scope C-BSRs by
priority ] *
default
Configuring an admin-scope C-BSR

By default, a PIM-SM domain has only one BSR. The entire network should be
managed by this BSR. To manage your network more effectively and specifically,
you can divide a PIM-SM domain into multiple BSR admin-scope regions, with
each BSR admin-scope region having one BSR, which services specific multicast
groups.
Specific to particular multicast groups, the BSR administrative scoping mechanism

effectively lessens the management workload of a single-BSR domain and provides
group-specific services.
In a network divided into BSR admin-scope regions, BSRs are elected from
multitudinous C-BSRs to serve different multicast groups. The C-RPs in a BSR
admin-scope region send C-RP-Adv messages to only the corresponding BSR. The
BSR summarizes the advertisement messages into an RP-set and advertises it to all
the routers in the BSR admin-scope region. All the routers use the same algorithm
to get the RP addresses corresponding to specific multicast groups.
Follow these steps to configure an admin-scope C-BSR:

Enter public instance PIM pim [ vpn-instance -
view or VPN instance PIM vpn-instance-name ]
view
Enable BSR administrative c-bsr admin-scope Required
scoping
Disabled by default
Configure an admin-scope c-bsr group group-address { mask | Optional
C-BSR mask-length } [ hash-length
No admin-scope BSRs by
hash-length | priority priority ] *
default
Configuring a BSR admin-scope region boundary

A BSR has its specific service scope. A number of BSR boundary interfaces divide a
network into different BSR admin-scope regions. Bootstrap messages cannot cross
the admin-scope region boundary, while other types of PIM messages can.
Follow these steps to configure a BSR admin-scope region boundary:

interface-number


Configure a BSR admin-scope pim bsr-boundary Required
region boundary
No BSR admin-scope region
boundary by default
Configuring global C-BSR parameters

The BSR election winner advertises its own IP address and RP-set information
throughout the region it serves through bootstrap messages. The BSR floods
bootstrap messages throughout the network periodically. Any C-BSR that receives
a bootstrap message maintains the BSR state for a configurable period of time
(BSR state timeout), during which no BSR election takes place. When the BSR state
times out, a new BSR election process will be triggered among the C-BSRs.
Follow these steps to configure global C-BSR parameters:

Configure the Hash mask c-bsr hash-length Optional
length for RP selection hash-length
30 by default
calculation
Configure the C-BSR priority c-bsr priority priority Optional
0 by default
Configure the bootstrap c-bsr interval interval Optional
interval
“Note” below.
Configure the bootstrap c-bsr holdtime interval Optional
timeout time
“Note” below.
n About the bootstrap timeout time

■ By default, the bootstrap timeout value is determined by this formula:
Bootstrap timeout = Bootstrap interval × 2 + 10. The default bootstrap interval
is 60 seconds, and so the default bootstrap timeout = 60 × 2 + 10 = 130
(seconds).
■ If this parameter is manually configured, the system will use the configured
value.
About the bootstrap interval

■ By default, the bootstrap interval is determined by this formula: Bootstrap
interval = (Bootstrap timeout - 10) / 2. The default bootstrap timeout is 130
seconds, so the default bootstrap interval = (130 - 10) / 2 = 60 (seconds).
■ If this parameter is manually configured, the system will use the configured
value.
c CAUTION: In configuration, make sure that the bootstrap interval is smaller than
the bootstrap timeout time.

Configuring an RP An RP can be manually configured or dynamically elected through the BSR

mechanism. For a large PIM network, static RP configuration is a tedious job.
Generally, static RP configuration is just a backup means for the dynamic RP
election mechanism to enhance the robustness and operation manageability of a
multicast network.
Configuring a static RP
If there is only one dynamic RP in a network, manually configuring a static RP can
avoid communication interruption due to single-point failures and avoid frequent
message exchange between C-RPs and the BSR. To enable a static RP to work
normally, you must perform this configuration on all the devices in the PIM-SM
domain and specify the same RP address.
Follow these steps to configure a static RP
To do... Use

MSR 3016

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

MSR 3016

Hochgeladen von

Copyright:

Verfügbare Formate

H3C MSR 20/30/50 Series Routers

Configuration Manual (v1.00)

MSR 20 Series Routers

Downloaded from www.Manualslib.com manuals search engine

UNITED STATES GOVERNMENT LEGEND

H3C, , Aolynk, , H3Care, , TOP G, , IRF, NetPilot, Neocean, NeoVTL, SecPro,

Conserving energy, materials and natural resources in all operations.

Improving our environmental record on a continual basis.

End of Life Statement

Regulated Materials Statement

3Com products do not contain any hazardous or ozone-depleting material.

Environmental Statement about the Documentation

Downloaded from www.Manualslib.com manuals search engine

ABOUT THIS GUIDE

1 ATM AND DSL INTERFACE CONFIGURATION

2 POS INTERFACE CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

4 WAN INTERFACE CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

8 FRAME RELAY CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

9 MULTILINK FRAME RELAY

Downloaded from www.Manualslib.com manuals search engine

14 X.25 AND LAPB CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

15 LINK AGGREGATION OVERVIEW

16 LINK AGGREGATION CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

18 PORT MIRRORING CONFIGURATION

19 PPP AND MP CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

Downloaded from www.Manualslib.com manuals search engine

25 VOICE VLAN CONFIGURATION

26 PORT ISOLATION CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

27 DYNAMIC ROUTE BACKUP CONFIGURATION

28 LOGICAL INTERFACE CONFIGURATION

29 CPOS INTERFACE CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

31 PROXY ARP CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

33 DHCP SERVER CONFIGURATION

34 DHCP RELAY AGENT CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

35 DHCP CLIENT CONFIGURATION

36 DHCP SNOOPING CONFIGURATION

37 BOOTP CLIENT CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

42 IP UNICAST POLICY ROUTING CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

45 FAST FORWARDING CONFIGURATION

46 IPV6 BASICS CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

48 DUAL STACK CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

50 IPV6 UNICAST POLICY ROUTING CONFIGURATION

51 TERMINAL ACCESS CONFIGURATION

52 FEP INSTALLATION AND CONFIGURATION

Downloaded from www.Manualslib.com manuals search engine

53 TERMINAL ACCESS TROUBLESHOOTING