H3C SR6600-X, R6600 Configuration Manual

Download

H3C SR6600/SR6600-X Routers

Network Management and Monitoring

Hangzhou H3C Technologies Co., Ltd. http://www.h3c.com

Software version: SR6602X-CMW710-R7103

SR6600X-CMW710-R7103-RSE3 SR6600-CMW710-R7103-RPE3

Document version: 20150715-6PW100

Configuration Guide(V7)

No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Hangzhou H3C Technologies Co., Ltd.

Trademarks

H3C, , H3CS, H3CIE, H3CNE, Aolynk, , H

Care, , IRF, NetPilot, Netflow, SecEngine, SecPath, SecCenter, SecBlade, Comware, ITCMM and HUASAN are trademarks of Hangzhou H3C Technologies Co., Ltd.

All other trademarks that may be mentioned in this manual are the property of their respective owners

Notice

The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.

Preface

The H3C SR6600/SR6600-X documentation set includes 14 configuration guides, which describe the software features for the H3C SR6600/SR6600-X Routers and guide you through the software configuration procedures. These configuration guides also provide configuration examples to help you apply software features to different network scenarios.

The Network Management and Monitoring Configuration Guide describes technical principles and configurations applied during the management and maintenance process of routers and networks.

This preface includes:

• Audience

• Conventions

• About the H3C SR6600/SR6600-X documentation set

• Obtaining documentation

• Technical support

• Documentation feedback

Audience

This documentation is intended for:

• Network planners

• Field technical support and servicing engineers

• Network administrators working with the routers

Conventions

This section describes the conventions used in this documentation set.

Command conventions

Convention Description

Boldface Bold text represents commands and keywords that you enter literally as shown.

Italic Italic text represents arguments that you replace with actual values.

[ ] Square brackets enclose syntax choices (keywords or arguments) that are optional.

{ x | y | ... }

[ x | y | ... ]

Braces enclose a set of required syntax choices separated by vertical bars, from which you select one.

Square brackets enclose a set of optional syntax choices separated by vertical bars, from which you select one or none.

{ x | y | ... } *

[ x | y | ... ] *

Asterisk marked braces enclose a set of required syntax choices separated by vertical bars, from which you select at least one.

Asterisk marked square brackets enclose optional syntax choices separated by vertical

bars, from which you select one choice, multiple choices, or none.

&<1-n>

# A line that starts with a pound (#) sign is comments.

GUI conventions

Convention Description

Boldface

> Multi-level menus are separated by angle brackets. For example, File > Create > Folder.

Symbols

Convention Description

WARNING

CAUTION

IMPORTANT

NOTE

The argument or keyword and argument combination before the ampersand (&) sign can be entered 1 to n times.

Window names, button names, field names, and menu items are in Boldface. For example, the New User window appears; click OK.

An alert that calls attention to important information that if not understood or followed can result in personal injury.

An alert that calls attention to important information that if not understood or followed can result in data loss, data corruption, or damage to hardware or software.

An alert that calls attention to essential information.

An alert that contains additional or supplementary information.

TIP

Network topology icons



An alert that provides helpful information.

Represents a generic network device, such as a router, switch, or firewall.

Represents a routing-capable device, such as a router or Layer 3 switch.

Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports Layer 2 forwarding and other Layer 2 features.

Represents an access controller, a unified wired-WLAN module, or the access controller engine on a unified wired-WLAN switch.

Represents an access point.

Represents a mesh access point.

Represents omnidirectional signals.

Represents directional signals.



Represents a security product, such as a firewall, UTM, multiservice security gateway, or load balancing device.

Represents a security card, such as a firewall, load balancing, NetStream, SSL VPN, IPS,

gory

or ACG card.

Port numbering in examples

The port numbers in this document are for illustration only and might be unavailable on your device.

About the H3C SR6600/SR6600-X documentation set

The H3C SR6600/SR6600-X documentation set includes:

Cate

Product description and specifications

Hardware specifications and installation

Software configuration

Operations and maintenance

Documents

Purposes

Marketing brochures Describe product specifications and benefits.

Technology white papers

Card datasheets

Compliance and safety manual

Installation guide

Card manuals Provide the hardware specifications of cards.

H3C N68 Cabinet Installation and Remodel Introduction

Configuration guides

Command references

H3C SR6602 Release notes

H3C SR6608 Release notes

Provide an in-depth description of software features and technologies.

Describe card specifications, features, and standards.

Provides regulatory information and the safety instructions that must be followed during installation.

Provides a complete guide to hardware installation and hardware specifications.

Guides you through installing and remodeling H3C N68 cabinets.

Describe software features and configuration procedures.

Provide a quick reference to all available commands.

Provide information about the product release, including the version history, hardware and software compatibility matrix, version upgrade information, technical support information, and software upgrading.

Obtaining documentation

You can access the most up-to-date H3C product documentation on the World Wide Web at http://www.h3c.com

Click the links on the top navigation bar to obtain different categories of product documentation:

[Technical Support & Documents > Technical Documents]

upgrading, and software feature configuration and maintenance documentation.

[Products & Solutions]

– Provides hardware installation, software

– Provides information about products and technologies, as well as solutions.

[Technical Support & Documents > Software Download] – Provides the documentation released with the

software version.

Technical support

service@h3c.com

http://www.h3c.com

Documentation feedback

You can e-mail your comments about product documentation to info@h3c.com.

We appreciate your comments.

Using ping, tracert, and system debugging ··············································································································· 1

Ping ····················································································································································································· 1

Using a ping command to test network connectivity ···························································································· 1 Ping example ···························································································································································· 1

Tracert ················································································································································································ 3

Prerequisites ······························································································································································ 4 Using a tracert command to identify failed or all nodes in a path ····································································· 4 Tracert example ························································································································································ 5

System debugging ···························································································································································· 6

Debugging information control switches················································································································ 6 Debugging a feature module ·································································································································· 7

Configuring NQA ························································································································································ 8

Overview ············································································································································································ 8

NQA operation ························································································································································ 8 Collaboration ···························································································································································· 9

Threshold monitoring ············································································································································ 10 NQA configuration task list ·········································································································································· 10 Configuring the NQA server ········································································································································ 10 Enabling the NQA client ··············································································································································· 11 Configuring NQA operations on the NQA client ······································································································ 11

NQA operation configuration task list ················································································································ 11

Configuring the ICMP echo operation ················································································································ 12

Configuring the DHCP operation························································································································· 13

Configuring the DNS operation ··························································································································· 14

Configuring the FTP operation ····························································································································· 14

Configuring the HTTP operation ·························································································································· 15

Configuring the UDP jitter operation ··················································································································· 16

Configuring the SNMP operation ························································································································ 18

Configuring the TCP operation ···························································································································· 18

Configuring the UDP echo operation ·················································································································· 19

Configuring the UDP tracert operation ··············································································································· 20

Configuring the voice operation ·························································································································· 22

Configuring the DLSw operation ························································································································· 24

Configuring the path jitter operation ··················································································································· 24

Configuring optional parameters for the NQA operation ················································································ 25

Configuring the collaboration function ··············································································································· 26

Configuring threshold monitoring ························································································································ 27

Configuring the NQA statistics collection function ···························································································· 30

Configuring the saving of NQA history records ································································································ 30

Scheduling the NQA operation on the NQA client ·························································································· 31 Configuring NQA templates on the NQA client ········································································································ 31

Configuring the ICMP template ··························································································································· 32

Configuring the DNS template ····························································································································· 32

Configuring the TCP template ······························································································································ 33

Configuring the HTTP template ···························································································································· 34

Configuring the FTP template ······························································································································· 35

Configuring optional parameters for the NQA template ·················································································· 36 Displaying and maintaining NQA ······························································································································· 37

NQA configuration examples ······································································································································ 38

ICMP echo operation configuration example ···································································································· 38

DHCP operation configuration example ············································································································· 40

DNS operation configuration example ··············································································································· 41

FTP operation configuration example ················································································································· 42

HTTP operation configuration example ··············································································································· 43

UDP jitter operation configuration example ······································································································· 44

SNMP operation configuration example ············································································································ 47

TCP operation configuration example ················································································································ 48

UDP echo operation configuration example ······································································································ 49

UDP tracert operation configuration example ···································································································· 51

Voice operation configuration example ············································································································· 52

DLSw operation configuration example ·············································································································· 55

Path jitter operation configuration example ······································································································· 56

NQA collaboration configuration example········································································································ 57

ICMP template configuration example ················································································································ 60

DNS template configuration example ················································································································· 61

TCP template configuration example ·················································································································· 62

HTTP template configuration example ················································································································· 62

FTP template configuration example ··················································································································· 63

Configuring NTP ························································································································································ 65

How NTP works ····················································································································································· 65

NTP architecture ···················································································································································· 66

Association modes ················································································································································ 67

NTP security ··························································································································································· 69

NTP for MPLS L3VPNs ·········································································································································· 70

Protocols and standards ······································································································································· 71 Configuration restrictions and guidelines ···················································································································· 71 Configuration task list ···················································································································································· 71 Enabling the NTP service ·············································································································································· 72 Configuring NTP association modes ···························································································································· 72

Configuring NTP in client/server mode ·············································································································· 72

Configuring NTP in symmetric active/passive mode ························································································ 73

Configuring NTP in broadcast mode ·················································································································· 74

Configuring NTP in multicast mode ····················································································································· 75 Configuring access control rights ································································································································· 76 Configuring NTP authentication ··································································································································· 76

Configuring NTP authentication in client/server mode ····················································································· 76

Configuring NTP authentication in symmetric active/passive mode ······························································· 78

Configuring NTP authentication in broadcast mode ························································································· 80

Configuring NTP authentication in multicast mode ··························································································· 82 Configuring NTP optional parameters ························································································································· 84

Specifying the source interface for NTP messages ···························································································· 85

Disabling an interface from processing NTP messages ···················································································· 85

Configuring the maximum number of dynamic associations ············································································ 86

Configuring a DSCP value for NTP packets ······································································································· 86 Configuring the local clock as a reference source ····································································································· 86 Displaying and maintaining NTP ································································································································· 87 NTP client/server mode configuration example ········································································································· 87 IPv6 NTP client/server mode configuration example ································································································· 88 NTP symmetric active/passive mode configuration example ··················································································· 90 IPv6 NTP symmetric active/passive mode configuration example ··········································································· 91 NTP broadcast mode configuration example ············································································································· 92

NTP multicast mode configuration example ················································································································ 94 IPv6 NTP multicast mode configuration example ······································································································· 97 Configuration example for NTP client/server mode with authentication ······························································· 100 Configuration example for NTP broadcast mode with authentication ··································································· 101 Configuration example for MPLS VPN time synchronization in client/server mode ············································ 104 Configuration example for MPLS VPN time synchronization in symmetric active/passive mode ······················· 106

Configuring SNTP ··················································································································································· 108

Configuration restrictions and guidelines ·················································································································· 108 Configuration task list ·················································································································································· 108 Enabling the SNTP service ·········································································································································· 108 Specifying an NTP server for the device ··················································································································· 109 Configuring SNTP authentication ······························································································································· 109 Displaying and maintaining SNTP ····························································································································· 110 SNTP configuration example ······································································································································ 110

Configuring PTP ······················································································································································· 112

Basic concepts ····················································································································································· 112

Synchronization mechanism ······························································································································· 114

Configuration task list ········································································································································· 117

Specifying a PTP standard ·································································································································· 119

Specifying a clock node type ····························································································································· 119

Specifying a PTP domain ···································································································································· 120

Configuring an OC to operate only as a member clock ················································································ 120

Configuring ToD input or output ························································································································ 120

Configuring ToD clock parameters ···················································································································· 121

Configuring a priority for a clock ······················································································································ 121

Configuring the role of a PTP port ····················································································································· 122

Configuring the mode for carrying timestamps ································································································ 122

Specifying a delay measurement mechanism for a BC or an OC ································································· 123

Configuring the port type for a TC+OC ··········································································································· 123

Configuring the interval for sending announce messages ·············································································· 124

Specifying the number of announcement intervals before the receiving node stops receiving announce

messages ······························································································································································ 124

Configuring the interval for sending Pdelay_Req messages ··········································································· 125

Configuring the interval for sending Sync messages ······················································································ 125

Configuring the minimum interval for sending Delay_Req messages ···························································· 125

Configuring the MAC address for non-pdelay messages ··············································································· 126

Specifying the protocol for encapsulating PTP messages as UDP (IPv4) ······················································· 126

Configuring the source IP address for multicast PTP message transmission over UDP (IPv4) ······················ 126

Configuring the destination IP address for unicast PTP message transmission over UDP (IPv4) ················· 127

Configuring the delay correction value············································································································· 127

Configuring the cumulative offset between the UTC and TAI ········································································· 128

Configuring the correction date of the UTC ····································································································· 128

Setting a DSCP value for PTP messages transmitted over UDP (IPv4) ···························································· 128

Specifying the system time source as PTP ········································································································· 129

Enabling PTP on a port ······································································································································· 129 Displaying and maintaining PTP ································································································································· 129 PTP configuration example (IEEE 1588 version 2, IEEE 802.3/Ethernet encapsulation) ···································· 130 PTP configuration example (IEEE 1588 version 2, multicast transmission) ···························································· 132 PTP configuration example (IEEE 1588 version 2, unicast transmission) ······························································· 135



iii

PTP configuration example (IEEE 802.1AS) ·············································································································· 138

Configuring network synchronization ···················································································································· 141

Clock sources ······················································································································································· 141

SSM quality levels ··············································································································································· 141

Clock source priority ··········································································································································· 142

Clock reference selection ···································································································································· 142

Clock mode on a port ········································································································································· 142 Feature and hardware compatibility ·························································································································· 143 Network synchronization configuration task list ······································································································· 143 Configuring clock reference selection ························································································································ 144 Setting the Sa bit for the SSM of BITS clocks ············································································································ 144 Configuring the timing direction of a BITS clock ······································································································ 145 Setting the frequency of a BITS clock ························································································································· 145 Specifying a line clock input port ······························································································································· 146 Configuring automatic reference selection parameters ··························································································· 146

Configuring the method to set the SSM quality level of a clock source ························································ 146

Specifying an SSM quality level for a clock source ························································································ 147

Controlling the use of SSM in automatic reference selection ········································································· 147

Setting the priority of a clock source ················································································································· 148 Enabling the reference manually specified on a non-default MDC ········································································ 148 Displaying and maintaining network clock monitoring module configuration ······················································ 149 Network synchronization configuration example ····································································································· 150

Network requirements ········································································································································· 150

Configuring synchronous Ethernet ························································································································· 151

Quality levels of clocks ······································································································································· 151

Clock reference selection and timing distribution ···························································································· 151

Input QL updating on SyncE ports ····················································································································· 152

Protocols and standards ····································································································································· 152 Feature and hardware compatibility ·························································································································· 152 Configuring SyncE on an Ethernet interface ············································································································· 152 Setting the clock mode on a copper SyncE GE port ································································································ 153 Displaying and maintaining SyncE ···························································································································· 153 SyncE configuration example ····································································································································· 153

Configuring SNMP ·················································································································································· 155

SNMP framework ················································································································································ 155

MIB and view-based MIB access control ·········································································································· 155

SNMP operations ················································································································································ 156

Protocol versions ·················································································································································· 156

Access control modes ········································································································································· 156 FIPS compliance ··························································································································································· 157 Security strength ··························································································································································· 157 Configuring SNMP basic parameters ························································································································ 157

Configuring SNMPv1 or SNMPv2c basic parameters ···················································································· 157

Configuring SNMPv3 basic parameters ··········································································································· 159 Configuring SNMP logging ········································································································································ 163

Configuring SNMP notifications ································································································································· 164

Enabling SNMP notifications ····························································································································· 164

Configuring the SNMP agent to send notifications to a host ········································································· 164 Displaying the SNMP settings ····································································································································· 166 SNMPv1/SNMPv2c configuration example ············································································································· 167

Verifying the configuration ································································································································· 168 SNMPv3 configuration example ································································································································ 168

Configuring RMON ················································································································································ 172

RMON groups ····················································································································································· 172

Sample types for the alarm group and the private alarm group ··································································· 174

Creating an RMON Ethernet statistics entry ····································································································· 174

Creating an RMON history control entry·········································································································· 175 Configuring the RMON alarm function ····················································································································· 175 Displaying and maintaining RMON settings ············································································································ 176 Ethernet statistics group configuration example ······································································································· 177

Configuration procedure ···································································································································· 177 History group configuration example ························································································································ 178

Configuration procedure ···································································································································· 178 Alarm function configuration example ······················································································································· 179

Configuring EAA ····················································································································································· 182

EAA framework ··················································································································································· 182

Elements in a monitor policy ······························································································································ 183

EAA environment variables ································································································································ 184 Configuring a user-defined EAA environment variable ··························································································· 185 Configuring a monitor policy ······································································································································ 186

Configuration restrictions and guidelines ········································································································· 186

Configuring a monitor policy from the CLI ······································································································· 186

Configuring a monitor policy by using Tcl ······································································································· 188 Suspending monitor policies ······································································································································· 189 Displaying and maintaining EAA settings ················································································································· 190 EAA configuration examples ······································································································································ 190

CLI-defined policy configuration example ········································································································ 190

CLI-defined policy with EAA environment variables configuration example ················································ 191

Tcl-defined policy configuration example ········································································································· 192

Monitoring and maintaining processes ················································································································· 194

Displaying and maintaining processes ······················································································································ 194 Displaying and maintaining user processes ·············································································································· 195 Monitoring kernel threads ··········································································································································· 196

Configuring kernel thread deadloop detection ································································································ 196

Configuring kernel thread starvation detection ································································································ 197

Displaying and maintaining kernel threads ······································································································ 198

Configuring samplers ·············································································································································· 200

Creating a sampler ······················································································································································ 200 Displaying and maintaining a sampler ····················································································································· 200 Sampler configuration example ································································································································· 200

Configuring port mirroring ····································································································································· 202

Terminology ························································································································································· 202

Port mirroring implementation ···························································································································· 203 Configuring local port mirroring ································································································································ 203

Local port mirroring configuration task list ······································································································· 203

Creating a local mirroring group ······················································································································ 204

Configuring source ports for the local mirroring group ·················································································· 204

Configuring the monitor port for the local mirroring group ············································································ 205 Displaying and maintaining port mirroring ··············································································································· 205 Local port mirroring configuration example ·············································································································· 206

Configuring NetStream ··········································································································································· 207

NetStream architecture ······································································································································· 207

Flow aging ··························································································································································· 208

NetStream data export ······································································································································· 208

NetStream filtering and sampling ······················································································································ 211 NetStream configuration task list ································································································································ 211 Enabling NetStream ····················································································································································· 212 Configuring NetStream filtering ································································································································· 213 Configuring NetStream sampling ······························································································································· 213 Configuring attributes of the NetStream data export ······························································································· 213

Configuring the NetStream data export format ······························································································· 213

Configuring the refresh rate for NetStream version 9 templates ···································································· 215

Configuring MPLS-aware NetStream ················································································································ 215 Configuring NetStream flow aging ···························································································································· 215

Flow aging methods ············································································································································ 215

Configuration procedure ···································································································································· 216 Configuring the NetStream data export ···················································································································· 217

Configuring the NetStream traditional data export ························································································· 217

Configuring the NetStream aggregation data export ····················································································· 217 Displaying and maintaining NetStream ···················································································································· 218 NetStream configuration examples ···························································································································· 219

NetStream traditional data export configuration example ············································································· 219

NetStream aggregation data export configuration example ········································································· 220

Configuring IPv6 NetStream ·································································································································· 225

IPv6 NetStream architecture ······························································································································· 225

IPv6 NetStream data export ······························································································································· 226

IPv6 NetStream filtering and sampling ············································································································· 227

IPv6 NetStream configuration task list ······················································································································· 228 Enabling IPv6 NetStream ············································································································································ 229 Configuring IPv6 NetStream filtering ························································································································· 229 Configuring IPv6 NetStream sampling ······················································································································ 230 Configuring attributes of the IPv6 NetStream data export ······················································································ 230

Configuring the IPv6 NetStream data export format ······················································································· 230

Configuring the refresh rate for IPv6 NetStream version 9 templates ··························································· 231

Configuring MPLS-aware NetStream ················································································································ 232 Configuring IPv6 NetStream flow aging ··················································································································· 232

Configuration procedure ···································································································································· 233 Configuring the IPv6 NetStream data export ············································································································ 233

Configuring the IPv6 NetStream traditional data export ················································································ 233

Configuring the IPv6 NetStream aggregation data export············································································· 234 Displaying and maintaining IPv6 NetStream ············································································································ 235 IPv6 NetStream configuration examples ··················································································································· 236

IPv6 NetStream traditional data export configuration example ····································································· 236

IPv6 NetStream aggregation data export configuration example ································································· 237

Configuring the information center ························································································································ 241

Log types ······························································································································································ 241

Log levels ······························································································································································ 241

Log destinations ··················································································································································· 242

Default output rules for logs ································································································································ 242

Default output rules for diagnostic logs ············································································································· 242

Default output rules for security logs ················································································································· 243

Default output rules for hidden logs··················································································································· 243

Default output rules for trace logs ······················································································································ 243

Default output rules for custom logs ··················································································································· 243

Log formats ··························································································································································· 244 FIPS compliance ··························································································································································· 246 Information center configuration task list ··················································································································· 246 Outputting logs to the console ···································································································································· 247 Outputting logs to the monitor terminal ····················································································································· 247 Outputting logs to a log host ······································································································································ 248 Outputting logs to the log buffer ································································································································ 249 Saving logs to a log file ·············································································································································· 249 Managing security logs ··············································································································································· 250

Saving security logs to the security log file ······································································································· 250

Managing the security log file ··························································································································· 251 Saving diagnostic logs to a diagnostic log file ········································································································· 251 Configuring the maximum size of the trace log file ································································································· 252 Outputting custom NAT444 logs to a log host ········································································································· 253 Enabling synchronous information output ················································································································· 253 Enabling duplicate log suppression ··························································································································· 254 Disabling an interface from generating link up or link down logs ········································································· 254 Displaying and maintaining information center ······································································································· 255 Information center configuration examples ··············································································································· 255

Configuration example for outputting logs to the console ·············································································· 255

Configuration example for outputting logs to a UNIX log host ······································································ 256

Configuration example for outputting logs to a Linux log host ······································································· 257

Configuring flow log ··············································································································································· 259

Flow log configuration task list ··································································································································· 261

vii

Configuration prerequisites ········································································································································· 261 Configuring the flow log version ································································································································ 261 Specifying a source IP address for flow log packets ································································································ 261 Enabling load balancing for flow log entries ············································································································ 262 Configuring the timestamp of flow logs ····················································································································· 262 Specifying a flow log export destination ··················································································································· 263

Specifying a log host as the flow log export destination ················································································ 263

Specifying the information center as the flow log export destination ···························································· 263 Displaying and maintaining flow log ························································································································· 263 Flow log configuration example ································································································································· 264

Index ········································································································································································ 266

viii

Using ping, tracert, and system debugging

This chapter covers ping, tracert, and information about debugging the system.

Ping

Use the ping utility to determine if an address is reachable.

Ping sends ICMP echo requests (ECHO-REQUEST) to the destination device. Upon receiving the requests, the destination device responds with ICMP echo replies (ECHO-REPLY) to the source device. The source device outputs statistics about the ping operation, including the number of packets sent, number of echo replies received, and the round-trip time. You can measure the network performance by analyzing these statistics.

Using a ping command to test network connectivity

Execute ping commands in any view.

Task Command

Determine if an address in an IP network is reachable.

For more information about the ping mpls command, see MPLS Command Reference.

Ping example

Network requirements

When you configure the ping command for a low-speed network, set a larger value for the timeout timer (indicated by the

-t keyword in the command).

• For IPv4 networks:

-q | -r | -s packet-size | -t timeout | -tos tos | -v | { -topology topo-name | -vpn-instance vpn-instance-name } ] * host

• For IPv6 networks:

As shown in Figure 1, determine if Device A and Device C can reach each other. If they can reach each other, get detailed information about routes from Device A to Device C.

Figure 1 Network diagram

Configuration procedure

# Use the ping command on Device A to test connectivity to Device C.

Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press CTRL_C to break 56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=2.137 ms 56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=2.051 ms 56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=1.996 ms 56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=1.963 ms 56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=1.991 ms

--- Ping statistics for 1.1.2.2 --5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.963/2.028/2.137/0.062 ms

The output shows that:

• Device A sends five ICMP packets to Device C and Device A receives five ICMP packets.

• No ICMP packet is lost.

• The route is reachable.

# Get detailed information about routes from Device A to Device C.

<DeviceA> ping -r 1.1.2.2 Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press CTRL_C to break 56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=4.685 ms RR: 1.1.2.1

1.1.2.2

1.1.1.2

1.1.1.1 56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=4.834 ms (same route) 56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=4.770 ms (same route) 56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=4.812 ms (same route) 56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=4.704 ms (same route)

--- Ping statistics for 1.1.2.2 --5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 4.685/4.761/4.834/0.058 ms

The test procedure of ping –r is as shown in Figure 1:

1. The source device (Device A) sends an ICMP echo request to the destination device (Device C) with

2. The intermediate device (Device B) adds the IP address of its outbound interface (1.1.2.1) to the RR

3. Upon receiving the request, the destination device copies the RR option in the request and adds the

4. The intermediate device adds the IP address of its outbound interface (1.1.1.2) to the RR option in

5. Upon receiving the reply, the source device adds the IP address of its inbound interface (1.1.1.1)

Tracert

Tracert (also called Traceroute) enables retrieval of the IP addresses of Layer 3 devices in the path to a destination. In the event of network failure, use tracert to test network connectivity and identify failed nodes.

the RR option blank.

option of the ICMP echo request, and forwards the packet.

IP address of its outbound interface (1.1.2.2) to the RR option. Then the destination device sends an ICMP echo reply.

the ICMP echo reply, and then forwards the reply.

to the RR option. The detailed information of routes from Device A to Device C is formatted as:

1.1.1.1 <-> {1.1.1.2; 1.1.2.1} <-> 1.1.2.2.

Figure 2 Tracert operation

Device A Device B Device DDevice C

1.1.1.1/24

1.1.1.2/24

Hop Lmit=1

TTL exceeded

Hop Lmit=2

TTL exceeded

1.1.2.1/24

1.1.2.2/24 1.1.3.2/24

Hop Lmit=n

UDP port unreachable

1.1.3.1/24

Tracert uses received ICMP error messages to get the IP addresses of devices. Tracert works as shown in Figure 2:

1. T

he source device sends a UDP packet with a TTL value of 1 to the destination device. The

destination UDP port is not used by any application on the destination device.

2. The first hop (Device B, the first Layer 3 device that receives the packet) responds by sending a

TTL-expired ICMP error message to the source, with its IP address (1.1.1.2) encapsulated. This way, the source device can get the address of the first Layer 3 device (1.1.1.2).

3. The source device sends a packet with a TTL value of 2 to the destination device.

4. The second hop (Device C) responds with a TTL-expired ICMP error message, which gives the

source device the address of the second Layer 3 device (1.1.2.2).

5. This process continues until a packet sent by the source device reaches the ultimate destination

device. Because no application uses the destination port specified in the packet, the destination device responds with a port-unreachable ICMP message to the source device, with its IP address encapsulated. This way, the source device gets the IP address of the destination device (1.1.3.2).

6. The source device thinks that:

{ The packet has reached the destination device after receiving the port-unreachable ICMP

message.

{ T he p a t h to t h e d e st i n a t io n d ev i c e i s 1.1.1. 2 t o 1.1. 2. 2 t o 1.1. 3. 2.

Prerequisites

Before you use a tracert command, perform the tasks in this section.

For an IPv4 network:

• Enable sending of ICMP timeout packets on the intermediate devices (devices between the source

and destination devices). If the intermediate devices are H3C devices, execute the ip ttl-expires enable command on the devices. For more information about this command, see Layer 3—IP

Services Command Reference.

• Enable sending of ICMP destination unreachable packets on the destination device. If the

destination device is an H3C device, execute the ip unreachables enable command. For more information about this command, see Layer 3—IP Services Command Reference.

For an IPv6 network:

• Enable sending of ICMPv6 timeout packets on the intermediate devices (devices between the

source and destination devices). If the intermediate devices are H3C devices, execute the ipv6 hoplimit-expires enable command on the devices. For more information about this command, see

Layer 3—IP Services Command Reference.

• Enable sending of ICMPv6 destination unreachable packets on the destination device. If the

destination device is an H3C device, execute the ipv6 unreachables enable command. For more information about this command, see Layer 3—IP Services Command Reference.

Using a tracert command to identify failed or all nodes in a path

Execute tracert commands in any view.

Task Command

• For IPv4 networks:

tracert [ -a source-ip | -f first-ttl | -m max-ttl | -p port | -q packet-number | -t tos { -topology topo-name | -vpn-instance vpn-instance-name

Display the routes from source to destination.

For more information about the tracert mpls ipv4 command, see MPLS Command Reference.

[ -resolve-as { global | none | vpn } ] } | -w timeout ] * host

• For IPv6 networks:

tracert ipv6 [ -f first-hop| -m max-hops | -p port | -q packet-number | -t traffic-class | -vpn-instance vpn-instance-name [ -resolve-as { global |

none | vpn } ] | -w timeout ] * host

Tracert example

Network requirements

As shown in Figure 3, Device A failed to Telnet to Device C.

Test the network connectivity between Device A and Device C. If they cannot reach each ot h er, loca te the failed nodes in the network.

Figure 3 Network diagram

1.1.1.1/24 1.1.1.2/24 1.1.2.1/24

Device A Device B Device C

Configuration procedure

1. Configure the IP addresses for devices as shown in Figure 3.

2. Configure a static route on Device A.

<DeviceA> system-view [DeviceA] ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 [DeviceA] quit

3. Use the ping command to test connectivity between Device A and Device C.

<DeviceA> ping 1.1.2.2 Ping 1.1.2.2(1.1.2.2): 56 -data bytes, press CTRL_C to break Request time out Request time out Request time out Request time out Request time out

--- Ping statistics for 1.1.2.2 --5 packet(s) transmitted,0 packet(s) received,100.0% packet loss

The output shows that Device A and Device C cannot reach each other.

1.1.2.2/24

4. Use the tracert command to identify failed nodes:

# Enable sending of ICMP timeout packets on Device B.

<DeviceB> system-view [DeviceB] ip ttl-expires enable

# Enable sending of ICMP destination unreachable packets on Device C.

<DeviceC> system-view [DeviceC] ip unreachables enable

# Execute the tracert command on Device A.

<DeviceA> tracert 1.1.2.2 traceroute to 1.1.2.2 (1.1.2.2) 30 hops at most,40 bytes each packet, press CTRL_C

to break 1 1.1.1.2 (1.1.1.2) 1 ms 2 ms 1 ms 2 * * * 3 * * * 4 * * *

5 <DeviceA>

The output shows that Device A can reach Device B but cannot reach Device C. An error has occurred on the connection between Device B and Device C.

5. Use the debugging ip icmp command on Device A and Device C to verify that they can send and

receive the specific ICMP packets.

Or use the display ip routing-table command to verify that there is a route from Device A to Device C.

System debugging

The device supports debugging for the majority of protocols and features, and provides debugging information to help users diagnose errors.

Debugging information control switches

The following switches control the display of debugging information:

• Module debugging switch—Controls whether to generate the module-specific debugging

information.

• Screen output switch—Controls whether to display the debugging information on a certain screen.

Use terminal monitor and terminal logging level commands to turn on the screen output switch. For more information about these two commands, see Network Management and Monitoring Command Reference.

As shown in Figure 4, a The debugging information can be output on a terminal only when both the module debugging switch and the screen output switch are turned on.

Debugging information is typically displayed on a console. You can also send debugging information to other destinations. For more information, see "Configuring the information center."

Figure 4 Relationship between the module and screen output switch

ssume that the device can provide debugging for the three modules 1, 2, and 3.

Debugging a feature module

Output of debugging commands is memory intensive. To guarantee system performance, enable debugging only for modules that are in an exceptional condition. When debugging is complete, use the undo debugging all command to disable all the debugging functions.

To debug a feature module:

Step Command

1. Enable debugging for a

module in user view.

2. (Optional.) Display the

enabled debugging in any view.

debugging { all [ timeout time ] | module-name [ option ] }

display debugging [ module-name ]

Remarks

By default, all debugging functions are disabled.

N/A

Configuring NQA

Overview

Network quality analyzer (NQA) allows you to measure network performance, verify the service levels for IP services and applications, and troubleshoot network problems. It provides the following types of operations:

• ICMP echo.

• DHCP.

• DNS.

• FTP.

• HTTP.

• UDP jitter.

• SNMP.

• TCP.

• UDP echo.

• UDP tracert.

• Voice.

• Path jitter.

• DLSw.

As shown in Figure 5, the NQA by simulating IP services and applications to measure network performance. The obtained performance metrics include the one-way latency, jitter, packet loss, voice quality, application performance, and server response time.

All types of NQA operations require the NQA client, but only the TCP, UDP echo, UDP jitter, and voice operations require the NQA server. The NQA operations for services that are already provided by the destination device such as FTP do not need the NQA server.

You can configure the NQA server to listen and respond to specific IP addresses and ports to meet various test needs.

Figure 5 Network diagram

source device (NQA client) sends data to the NQA destination device

NQA operation

The following describes how NQA performs different types of operations:

• A TCP or DLSw operation sets up a connection.

• A UDP jitter or a voice operation sends a number of probe packets. The number of probe packets

is set by using the probe packet-number command.

• An FTP operation uploads or downloads a file.

• An HTTP operation gets a Web page.

• A DHCP operation gets an IP address through DHCP.

• A DNS operation translates a domain name to an IP address.

• An ICMP echo operation sends an ICMP echo request.

• A UDP echo operation sends a UDP packet.

• An SNMP operation sends one SNMPv1 packet, one SNMPv2c packet, and one SNMPv3 packet.

• A path jitter operation is accomplished in the following steps:

a. The operation uses tracert to obtain the path from the NQA client to the destination. A

maximum of 64 hops can be detected.

b. The NQA client sends ICMP echo requests to each hop along the path. The number of ICMP

echo requests is set by using the probe packet-number command.

• A UDP tracert operation determines the routing path from the source to the destination. The number

of the probes to each hop is set by using the probe count command.

Collaboration

NQA can collaborate with the Track module to notify application modules of state or performance changes so that the application modules can take predefined actions.

Figure 6 Collaboration

Detection

module

NQA

Associates with a

detection entry

Sends the

detection results

Track

module

Associates with

a track entry

Sends the track

entry status

Application modules

VRRP

VSRP

Static routing

Policy-based

routing

Interface backup

Traffic redirecting

WLAN uplink

detection

Smart Link

The following describes how a static route destined for 192.168.0.88 is monitored through collaboration:

1. NQA monitors the reachability to 192.168.0.88.

2. When 192.168.0.88 becomes unreachable, NQA notifies the Track module of the change.

3. The Track module notifies the static routing module of the state change.

4. The static routing module sets the static route as invalid according to a predefined action.

For more information about collaboration, see High Availability Configuration Guide.

Threshold monitoring

Threshold monitoring enables the NQA client to take a predefined action when the NQA operation performance metrics violate the specified thresholds.

Table 1 de

scribes the relationships between performance metrics and NQA operation types.

Table 1 Performance metrics and NQA operation types

Performance metric NQA o

Probe duration

Number of probe failures

Round-trip time UDP jitter and voice

Number of discarded packets UDP jitter and voice

One-way jitter (source-to-destination or destination-to-source)

One-way latency (source-to-destination or destination-to-source)

Calculated Planning Impairment Factor (ICPIF) (see "Configuring the voice operation")

Mean Opinion Scores (MOS) (see "Configuring the voice operation")

All NQA operation types except UDP jitter, UDP tracert, path jitter, and voice

UDP jitter and voice

Voice

eration types that can gather the metric

NQA configuration task list

Tasks at a glance

Configuring the NQA server

(Required.) Enabling the NQA client N/A

(Required.) Perform at least one of the following tasks:

• Configuring NQA operations on the NQA client

• Configuring NQA templates on the NQA client

Configuring the NQA server

To perform TCP, UDP echo, UDP jitter, and voice operations, you must enable the NQA server on the destination device. The NQA server listens and responds to requests on the specified IP addresses and ports.

You can configure multiple TCP or UDP listening services on an NQA server, where each corresponds to a specific IP address and port number. The IP address and port number for a listening service must be unique on the NQA server and match the configuration on the NQA client.

Remarks

Required for TCP, UDP echo, UDP jitter, and voice operations.

When you configure an NQA template to analyze network performance, the feature that uses the template performs the NQA operation.

To configure the NQA server:

Step Command

1. Enter system view.

2. Enable the NQA server.

system-view N/A

nqa server enable

• TCP listening service:

nqa server tcp-connect ip-address port-number [ vpn-instance

3. Configure a TCP or UDP

listening service.

vpn-instance-name ] [ tos tos ]

• UDP listening service:

nqa server udp-echo ip-address

port-number [ vpn-instance vpn-instance-name ] [ tos tos ]

Enabling the NQA client

Step Command

1. Enter system view.

2. Enable the NQA client.

system-view N/A

nqa agent enable By default, the NQA client is enabled.

Remarks

By default, the NQA server is disabled.

You can set the ToS value in the IP header of reply packets sent by the NQA server. The default ToS value is 0.

Remarks

Configuring NQA operations on the NQA client

NQA operation configuration task list

Tasks at a glance

(Required.) Perform at least one of the following tasks:

• Configuring the ICMP echo operation

• Configuring the DHCP operation

• Configuring the DNS operation

• Configuring the FTP operation

• Configuring the HTTP operation

• Configuring the UDP jitter operation

• Configuring the SNMP operation

• Configuring the TCP operation

• Configuring the UDP echo operation

• Configuring the UDP tracert operation

• Configuring the DLSw operation

• Configuring the path jitter operation

(Optional.) Configuring optional parameters for the NQA operation

(Optional.) Configuring the collaboration function

Tasks at a glance

(Optional.) Configuring threshold monitoring

(Optional.) Configuring the NQA statistics collection function

(Optional.) Configuring the saving of NQA history records

(Required.) Scheduling the NQA operation on the NQA client

Configuring the ICMP echo operation

The ICMP echo operation measures the reachability of a destination device. It has the same function as the ping command, but provides more output information. In addition, if multiple paths exist between the source and destination devices, you can specify the next hop for the ICMP echo operation.

The ICMP echo operation is not supported in IPv6 networks. To test the reachability of an IPv6 address, use the ping ipv6 command. For more information about the command, see Network Management and

Monitoring Command Reference.

To configure the ICMP echo operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the ICMP echo type

and enter its view.

4. Specify the destination

address of ICMP echo requests.

5. (Optional.) Specify the

payload size in each ICMP echo request.

6. (Optional.) Specify the string

to be filled in the payload of each ICMP echo request.

7. (Optional.) Specify the

output interface for ICMP echo requests.

system-view N/A

nqa entry admin-name operation-tag

type icmp-echo N/A

destination ip ip-address

data-size size The default setting is 100 bytes.

data-fill string

out interface interface-type interface-number

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

The default setting is the hexadecimal number

00010203040506070809.

By default, the output interface for ICMP echo requests is not specified. The NQA client determines the output interface based on the routing table lookup.

Step Command

• Specify the IP address of the

specified interface as the source

8. (Optional.) Specify the

source IP address of ICMP echo requests.

IP address:

source interface interface-type interface-number

• Specify the source IP address:

source ip ip-address

9. (Optional.) Specify the next

hop for ICMP echo requests.

next-hop ip-address

Configuring the DHCP operation

The DHCP operation measures whether or not the DHCP server can respond to client requests. DHCP also measures the amount of time it takes the NQA client to obtain an IP address from a DHCP server.

Remarks

By default, no source IP address is specified. The requests take the primary IP address of the output interface as their source IP address.

If you configure both the source ip and source interface commands, the most recent configuration takes effect.

The specified source interface must be up. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

By default, no next hop is configured.

The NQA client simulates the DHCP relay agent to forward DHCP requests for IP address acquisition from the DHCP server. The interface that performs the DHCP operation does not change its IP address. When the DHCP operation completes, the NQA client sends a packet to release the obtained IP address.

To configure the DHCP operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the DHCP type and

enter its view.

4. Specify the IP address of the

DHCP server as the destination IP address of DHCP packets.

5. (Optional.) Specify an

output interface for DHCP request packets.

system-view N/A

nqa entry admin-name operation-tag

type dhcp N/A

destination ip ip-address

out interface interface-type interface-number

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

By default, the output interface for DHCP request packets is not specified. The NQA client determines the output interface based on the routing table lookup.

Step Command

6. (Optional.) Specify the

source IP address of DHCP request packets.

source ip ip-address

Configuring the DNS operation

The DNS operation measures the time for the NQA client to translate a domain name into an IP address through a DNS server.

A DNS operation simulates domain name resolution and does not save the obtained DNS entry.

To configure the DNS operation:

Remarks

By default, no source IP address is specified for the request packets. The requests take the IP address of the output interface as their source IP address.

The specified source IP address must be the IP address of a local interface, and the local interface must be up. Otherwise, no probe packets can be sent out.

The NQA client adds the source IP address to the giaddr field in DHCP requests to be sent to the DHCP server. For more information about the giaddr field, see Layer 3—IP Services Configuration Guide.

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the DNS type and

enter its view.

4. Specify the IP address of the

DNS server as the destination address of DNS packets.

5. Specify the domain name to

be translated.

system-view N/A

nqa entry admin-name operation-tag

type dns N/A

destination ip ip-address

resolve-target domain-name

Configuring the FTP operation

The FTP operation measures the time for the NQA client to transfer a file to or download a file from an FTP server.

When you configure the FTP operation, follow these restrictions and guidelines:

• When you perform the put operation with the filename command configured, make sure the file

exists on the NQA client.

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

By default, no domain name is specified.

• If you get a file from the FTP server, make sure the file specified in the URL exists on the FTP server.

• The NQA client does not save the file obtained from the FTP server.

• Use a small file for the FTP operation. A big file might result in transfer failure because of timeout,

or might affect other services for occupying much network bandwidth.

To configure the FTP operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the FTP type and

enter its view.

4. Specify the URL of the

destination FTP server.

5. (Optional.) Specify the

source IP address of FTP request packets.

system-view N/A

nqa entry admin-name operation-tag

type ftp N/A

url url

source ip ip-address

Remarks

By default, no NQA operation is created.

By default, no URL is specified for the destination FTP server.

Enter the URL in one of the following formats:

• ftp://host/filename.

• ftp://host:port/filename.

When you perform the get operation, the file name is required.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no FTP requests can be sent out.

6. Specify the FTP operation

type.

7. Specify an FTP login

username.

8. Specify an FTP login

password.

9. (Optional.) Specify the

name of a file to be transferred.

10. Set the data transmission

mode.

operation { get | put }

username username

password { cipher | simple } password

filename file-name

mode { active | passive } The default mode is active.

Configuring the HTTP operation

An HTTP operation measures the time for the NQA client to obtain data from an HTTP server.

To configure an HTTP operation:

Step Command

1. Enter system view.

system-view N/A

By default, the FTP operation type is get, which means obtaining files from the FTP server.

By default, no FTP login username is configured.

By default, no FTP login password is configured.

By default, no file is specified.

This step is required if you perform the put operation.

Remarks

Step Command

2. Create an NQA operation

and enter NQA operation view.

3. Specify the HTTP type and

enter its view.

4. Specify the URL of the

destination HTTP server.

5. Specify an HTTP login

username.

6. Specify an HTTP login

password.

7. (Optional.) Specify the source

IP address of request packets.

nqa entry admin-name operation-tag

type http N/A

url url

username username

password { cipher | simple } password

source ip ip-address

Remarks

By default, no NQA operation is created.

By default, no URL is specified for the destination HTTP server.

Enter the URL in one of the following formats:

• http://host/resource.

• http://host:port/resource.

By default, no HTTP login username is specified.

By default, no HTTP login password is specified.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no request packets can be sent out.

8. Specify the HTTP operation

type.

9. Specify the HTTP version.

10. (Optional.) Enter raw request

view.

11. (Optional.) Specify the

content of a GET request for the HTTP operation.

12. Save the input and exit to

HTTP operation view.

operation { get | post | raw }

version { v1.0 | v1.1 } By default, HTTP 1.0 is used.

raw-request

Enter or paste the content.

quit N/A

Configuring the UDP jitter operation

CAUTION:

To ensure successful UDP jitter operations and avoid affecting existing services, do not perform the operations on well-known ports from 1 to 1023.

Jitter means inter-packet delay variance. A UDP jitter operation measures unidirectional and bidirectional jitters. You can verify whether the network can carry jitter-sensitive services such as real-time voice and video services through the UDP jitter operation.

By default, the HTTP operation type is get, which means obtaining data from the HTTP server.

Every time you enter raw request view, the previously configured content of the HTTP request is removed.

By default, no contents are specified.

This step is required for the raw operation.

The UDP jitter operation works as follows:

1. The NQA client sends UDP packets to the destination port at a regular interval.

2. The destination device takes a time stamp to each packet that it receives, and then sends the

packet back to the NQA client.

3. Upon receiving the responses, the NQA client calculates the jitter according to the time stamps.

The UDP jitter operation requires both the NQA server and the NQA client. Before you perform the UDP jitter operation, configure the UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server."

o configure a UDP jitter operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the UDP jitter type

and enter its view.

4. Specify the destination

address of UDP packets.

5. Specify the destination port of

UDP packets.

6. (Optional.) Specify the source

port number of UDP packets.

7. (Optional.) Specify the

payload size in each UDP packet.

system-view N/A

nqa entry admin-name operation-tag

type udp-jitter N/A

destination ip ip-address

destination port port-number

source port port-number

data-size size The default setting is 100 bytes.

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

The destination IP address must be the same as the IP address of the listening service on the NQA server.

By default, no destination port number is specified.

The destination port number must be the same as the port number of the listening service on the NQA server.

By default, no source port number is specified.

8. (Optional.) Specify the string

to be filled in the payload of each UDP packet.

9. (Optional.) Specify the

number of UDP packets sent in one UDP jitter operation.

10. (Optional.) Configure the

interval for sending UDP packets.

11. (Optional.) Specify how long

the NQA client waits for a response from the server before it regards the response times out.

data-fill string

probe packet-number

packet-number

probe packet-interval

packet-interval

probe packet-timeout

packet-timeout

The default setting is the hexadecimal number

00010203040506070809.

The default setting is 10.

The default setting is 20 milliseconds.

The default setting is 3000 milliseconds.

Step Command

12. (Optional.) Specify the source

IP address for UDP packets.

source ip ip-address

NOTE:

Use the display nqa result or display nqa statistics command to verify the UDP jitter operation. The display nqa history command does not display the UDP jitter operation results or statistics.

Configuring the SNMP operation

The SNMP operation measures the time for the NQA client to get a response packet from an SNMP agent.

To configure the SNMP operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the SNMP type and

enter its view.

system-view N/A

nqa entry admin-name operation-tag

type snmp N/A

Remarks

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no UDP packets can be sent out.

Remarks

By default, no NQA operation is created.

4. Specify the destination

address of SNMP packets.

5. (Optional.) Specify the source

port of SNMP packets.

6. (Optional.) Specify the source

IP address of SNMP packets.

destination ip ip-address

source port port-number

source ip ip-address

Configuring the TCP operation

The TCP operation measures the time for the NQA client to establish a TCP connection to a port on the NQA server.

The TCP operation requires both the NQA server and the NQA client. Before you perform a TCP operation, configure a TCP listening service on the NQA server. For more information about the TCP listening service configuration, see "Configuring the NQA server."

o configure the TCP operation:

By default, no destination IP address is specified.

By default, no source port number is specified.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no SNMP packets can be sent out.

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the TCP type and

enter its view.

4. Specify the destination

address of TCP packets.

5. Specify the destination port of

TCP packets.

6. (Optional.) Specify the source

IP address of TCP packets.

system-view N/A

nqa entry admin-name operation-tag

type tcp N/A

destination ip ip-address

destination port port-number

source ip ip-address

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

The destination address must be the same as the IP address of the listening service configured on the NQA server.

By default, no destination port number is configured.

The destination port number must be the same as the port number of the listening service on the NQA server.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no TCP packets can be sent out.

Configuring the UDP echo operation

The UDP echo operation measures the round-trip time between the client and a UDP port on the NQA server.

The UDP echo operation requires both the NQA server and the NQA client. Before you perform a UDP echo operation, configure a UDP listening service on the NQA server. For more information about the UDP listening service configuration, see "Configuring the NQA server."

To configure the UDP echo operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the UDP echo type

and enter its view.

4. Specify the destination

address of UDP packets.

system-view N/A

nqa entry admin-name operation-tag

type udp-echo N/A

destination ip ip-address

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

The destination address must be the same as the IP address of the listening service configured on the NQA server.

Step Command

5. Specify the destination port of

UDP packets.

6. (Optional.) Specify the

payload size in each UDP packet.

7. (Optional.) Specify the string

to be filled in the payload of each UDP packet.

8. (Optional.) Specify the source

port of UDP packets.

9. (Optional.) Specify the source

IP address of UDP packets.

destination port port-number

data-size size The default setting is 100 bytes.

data-fill string

source port port-number

source ip ip-address

Remarks

By default, no destination port number is specified.

The destination port number must be the same as the port number of the listening service on the NQA server.

The default setting is the hexadecimal number

00010203040506070809.

By default, no source port number is specified.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no UDP packets can be sent out.

Configuring the UDP tracert operation

The UDP tracert operation determines the routing path from the source device to the destination device.

Before you configure the UDP tracert operation, perform the following tasks:

• Enable sending ICMP time exceeded messages on the intermediate devices between the source

and destination devices. If the intermediate devices are H3C devices, use the ip ttl-expires enable command.

• Enable sending ICMP destination unreachable messages on the destination device. If the

destination device is an H3C device, use the ip unreachables enable command.

For more information about the ip ttl-expires enable and ip unreachable enable commands, see Layer 3—IP Services Command Reference.

The UDP tracert operation is not supported in IPv6 networks. To determine the routing path that the IPv6 packets traverse from the source to the destination, use the tracert ipv6 command. For more information about the command, see Network Management and Monitoring Command Reference.

To configure the UDP tracert operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the UDP tracert

operation type and enter its view.

system-view N/A

nqa entry admin-name operation-tag

type udp-tracert N/A

Remarks

By default, no NQA operation is created.

Step Command

4. Specify the destination

address of UDP packets.

5. (Optional.) Specify the

destination port of UDP packets.

6. (Optional.) Specify the

payload size in each UDP packet.

7. (Optional.) Enable the

no-fragmentation function.

8. (Optional.) Set the maximum

number of consecutive probe failures.

9. (Optional.) Specify the TTL

value for UDP packets in the start round of the UDP tracert operation.

destination ip ip-address

destination port port-number

data-size size The default setting is 100 bytes.

no-fragment enable

max-failure value The default setting is 5.

init-ttl ttl The default setting is 1.

Remarks

By default, no destination IP address is configured.

By default, the destination port number is 33434.

This port number must be an unused number on the destination device, so that the destination device can reply with ICMP port unreachable messages.

By default, the no-fragmentation function is disabled.

10. (Optional.) Specify an output

interface for UDP packets.

11. (Optional.) Specify the source

port of UDP packets.

12. (Optional.) Specify the source

IP address of UDP packets.

out interface interface-type interface-number

source port port-number

• Specify the IP address of the

specified interface as the source IP address: source interface

interface-type interface-number

• Specify the source IP

address: source ip ip-address

By default, the output interface for UDP packets is not specified. The NQA client determines the output interface based on the routing table lookup.

By default, no source port number is specified.

By default, no source IP address is specified. The packets take the primary IP address of the output interface as their source IP address.

If you configure both the source ip and source interface commands, the most recent configuration takes effect.

The specified source interface must be up. The source IP address must be the IP address of a local interface, and the local interface must be up. Otherwise, no probe packets can be sent out.

Configuring the voice operation

CAUTION:

To ensure successful voice operations and avoid affecting existing services, do not perform the operations on well-known ports from 1 to 1023.

The voice operation measures VoIP network performance.

The voice operation works as follows:

1. The NQA client sends voice packets at sending intervals to the destination device (NQA server).

The voice packets are of one of the following codec types:

{ G.711 A-law.

{ G.711 μ-law.

{ G.729 A-law.

2. The destination device takes a time stamp to each voice packet it receives and sends it back to the

source.

3. Upon receiving the packet, the source device calculates the jitter and one-way delay based on the

time stamp.

The following parameters that reflect VoIP network performance can be calculated by using the metrics gathered by the voice operation:

• Calculated Planning Impairment Factor (ICPIF)—Measures impairment to voice quality in a VoIP

network. It is decided by packet loss and delay. A higher value represents a lower service quality.

• Mean Opinion Scores (MOS)—A MOS value can be evaluated by using the ICPIF value, in the

range of 1 to 5. A higher value represents a higher service quality.

The evaluation of voice quality depends on users' tolerance for voice quality. For users with higher tolerance for voice quality, use the advantage-factor command to configure the advantage factor. When the system calculates the ICPIF value, it subtracts the advantage factor to modify ICPIF and MOS values for voice quality evaluation.

The voice operation requires both the NQA server and the NQA client. Before you perform a voice operation, configure a UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server."

he voice operation cannot repeat.

To configure the voice operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the voice type and

enter its view.

system-view N/A

nqa entry admin-name operation-tag

type voice N/A

Remarks

By default, no NQA operation is created.

Step Command

4. Specify the destination

address of voice packets.

5. Specify the destination port of

voice packets.

6. (Optional.) Specify the codec

type.

7. (Optional.) Specify the

advantage factor for calculating MOS and ICPIF values.

8. (Optional.) Specify the source

IP address of voice packets.

destination ip ip-address

destination port port-number

codec-type { g711a | g711u | g729a }

advantage-factor factor By default, the advantage factor is 0.

source ip ip-address

Remarks

By default, no destination IP address is configured.

The destination IP address must be the same as the IP address of the listening service on the NQA server.

By default, no destination port number is configured.

The destination port number must be the same as the port number of the listening service on the NQA server.

By default, the codec type is G.711 A-law.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no voice packets can be sent out.

9. (Optional.) Specify the source

port number of voice packets.

10. (Optional.) Specify the

payload size in each voice packet.

11. (Optional.) Specify the string

to be filled in the payload of each voice packet.

12. (Optional.) Specify the

number of voice packets to be sent in a voice probe.

13. (Optional.) Specify the

interval for sending voice packets.

14. (Optional.) Specify how long

the NQA client waits for a response from the server before it regards the response times out.

source port port-number

data-size size

data-fill string

probe packet-number

packet-number

probe packet-interval

packet-interval

probe packet-timeout

packet-timeout

By default, no source port number is specified.

By default, the voice packet size varies by codec type. The default packet size is 172 bytes for G.711A-law and G.711 μ-law codec type, and 32 bytes for G.729 A-law codec type.

The default setting is the hexadecimal number

00010203040506070809.

The default setting is 1000.

The default setting is 20 milliseconds.

The default setting is 5000 milliseconds.

NOTE:

Use the display nqa result or display nqa statistics command to verify the voice operation. The display nqa history command does not display the voice operation results or statistics.

Configuring the DLSw operation

The DLSw operation measures the response time of a DLSw device.

To configure the DLSw operation:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify the DLSw type and

enter its view.

4. Specify the destination IP

address of probe packets.

5. (Optional.) Specify the source

IP address of probe packets.

system-view N/A

nqa entry admin-name operation-tag

type dlsw N/A

destination ip ip-address

source ip ip-address

Configuring the path jitter operation

The path jitter operation measures the jitter, negative jitters, and positive jitters from the NQA client to each hop on the path to the destination.

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

Before you configure the path jitter operation, perform the following tasks:

• Enable sending ICMP time exceeded messages on the intermediate devices between the source

and destination devices. If the intermediate devices are H3C devices, use the ip ttl-expires enable command.

• Enable sending ICMP destination unreachable messages on the destination device. If the

destination device is an H3C device, use the ip unreachables enable command.

For more information about the ip ttl-expires enable and the ip unreachable enable command, see Layer 3—IP Services Command Reference.

To configure the path jitter operation:

Step Command

1. Enter system view.

2. Create an NQA operation and

enter NQA operation view.

3. Specify the path jitter type and

enter its view.

4. Specify the destination address

of ICMP echo requests.

system-view N/A

nqa entry admin-name operation-tag

type path-jitter N/A

destination ip ip-address

Remarks

By default, no NQA operation is created.

By default, no destination IP address is specified.

Step Command

5. (Optional.) Specify the payload

size in each ICMP echo request.

6. (Optional.) Specify the string to

be filled in the payload of each ICMP echo request.

7. Specify the source IP address of

ICMP echo requests.

8. (Optional.) Specify the number

of ICMP echo requests to be sent in a path jitter operation.

9. (Optional.) Specify the interval

for sending ICMP echo requests.

10. (Optional.) Specify how long

the NQA client waits for a response from the server before it regards the response times out.

data-size size The default setting is 100 bytes.

data-fill string

source ip ip-address

probe packet-number packet-number

probe packet-interval packet-interval

probe packet-timeout packet-timeout

Remarks

The default setting is the hexadecimal number

00010203040506070809.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no ICMP echo requests can be sent out.

The default setting is 10.

The default setting is 20 milliseconds.

The default setting is 3000 milliseconds.

By default, no LSR path is specified.

11. (Optional.) Specify an LSR path.

12. (Optional.) Perform the path

jitter operation only on the destination address.

lsr-path ip-address&<1-8>

target-only

The path jitter operation uses the tracert to detect the LSR path to the destination, and sends ICMP echo requests to each hop on the LSR.

By default, the path jitter operation is performed on each hop on the path to the destination.

Configuring optional parameters for the NQA operation

Unless otherwise specified, the following optional parameters apply to all types of NQA operations.

To configure optional parameters for an NQA operation:

Step Command

1. Enter system view.

2. Create an NQA

operation and enter NQA operation view.

3. Specify an NQA

operation type and enter its view.

system-view N/A

nqa entry admin-name operation-tag

type { dhcp | dlsw | dns | ftp | http | icmp-echo | path-jitter | snmp | tcp | udp-echo | udp-jitter | udp-tracert | voice }

Remarks

By default, no NQA operation is created.

N/A

4. Configure a description.

description text By default, no description is configured.

Step Command

5. Specify the interval at

which the NQA operation repeats.

6. Specify the probe times.

7. Specify the probe timeout

time.

frequency interval

probe count times

probe timeout timeout

Remarks

For a voice or path jitter operation, the default setting is 60000 milliseconds.

For other operations, the default setting is 0 milliseconds. Only one operation is performed.

If the operation is not completed when the interval expires, the next operation does not start.

By default:

• In an UDP tracert operation, the NQA

client performs three probes to each hop to the destination.

• In other types of operations, the NQA

client performs one probe to the destination per operation.

This command is not available for the path jitter and voice operations. Each of these operations performs only one probe.

The default setting is 3000 milliseconds.

This command is not available for the path jitter, UDP jitter, and voice operations.

8. Specify the maximum

number of hops that the probe packets can traverse.

9. Specify the ToS value in

the IP header of probe packets.

10. Enable the routing table

bypass function.

11. Specify the VPN where

the operation is performed.

ttl value

tos value The default setting is 0.

route-option bypass-route

vpn-instance vpn-instance-name

Configuring the collaboration function

Collaboration is implemented by associating a reaction entry of an NQA operation with a track entry. The reaction entry monitors the NQA operation. If the number of operation failures reaches the specified threshold, the configured action is triggered.

The default setting is 30 for probe packets of the UDP tracert operation, and is 20 for probe packets of other types of operations.

This command is not available for the DHCP and path jitter operations.

By default, the routing table bypass function is disabled.

This command is not available for the DHCP and path jitter operations.

By default, the operation is performed on the public network.

To configure the collaboration function:

Step Command

1. Enter system view.

system-view N/A

Remarks

Step Command

2. Create an NQA operation

and enter NQA operation view.

3. Specify an NQA operation

type and enter its view.

4. Configure a reaction entry.

5. Exit to system view.

6. Associate Track with NQA.

7. Associate Track with an

application module.

nqa entry admin-name operation-tag

type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo }

reaction item-number checked-element probe-fail threshold-type consecutive consecutive-occurrences action-type trigger-only

quit N/A

See High Availability Configuration Guide.

Configuring threshold monitoring

Remarks

By default, no NQA operation is created.

The collaboration function is not available for the path jitter, UDP tracert, UDP jitter, and voice operations.

By default, no reaction entry is configured.

You cannot modify the content of an existing reaction entry.

N/A

This function allows you to monitor the NQA operation running status.

Threshold types

An NQA operation supports the following threshold types:

• average—If the average value for the monitored performance metric either exceeds the upper

threshold or goes below the lower threshold, a threshold violation occurs.

• accumulate—If the total number of times that the monitored performance metric is out of the

specified value range reaches or exceeds the specified threshold, a threshold violation occurs.

• consecutive—If the number of consecutive times that the monitored performance metric is out of the

specified value range reaches or exceeds the specified threshold, a threshold violation occurs.

Threshold violations for the average or accumulate threshold type are determined on a per NQA operation basis. The threshold violations for the consecutive type are determined from the time the NQA operation starts.

Triggered actions

The following actions might be triggered:

• none—NQA displays results only on the terminal screen. It does not send traps to the NMS.

• trap-only—NQA displays results on the terminal screen, and meanwhile it sends traps to the NMS.

• trigger-only—NQA displays results on the terminal screen, and meanwhile triggers other modules

for collaboration.

The DNS operation does not support the action of sending trap messages.

Reaction entry

In a reaction entry, configure a monitored element, a threshold type, and an action to be triggered to implement threshold monitoring.

The state of a reaction entry can be invalid, over-threshold, or below-threshold.

• Before an NQA operation starts, the reaction entry is in invalid state.

• If the threshold is violated, the state of the entry is set to over-threshold. Otherwise, the state of the

entry is set to below-threshold.

If the action is configured as trap-only for a reaction entry, a trap message is sent to the NMS when the state of the entry changes.

Configuration procedure

Before you configure threshold monitoring, configure the destination address of the trap messages by using the snmp-agent target-host command. For more information about the command, see Network Management and Monitoring Command Reference.

To configure threshold monitoring:

Step Command

1. Enter system view.

2. Create an NQA

operation and enter NQA operation view.

3. Enter NQA

operation view.

4. Enable sending

traps to the NMS when specific conditions are met.

system-view N/A

nqa entry admin-name operation-tag

type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo | udp-jitter | udp-tracert | voice }

reaction trap { path-change | probe-failure consecutive-probe-failures | test-complete | test-failure [ cumulate-probe-failures ] }

Remarks

By default, no NQA operation is created.

Path jitter does not support threshold monitoring.

By default, no traps are sent to the NMS.

The UDP jitter and voice operations support only the test-complete keyword.

The UDP tracert operation supports the path-change, test-complete, and test-failure keywords.

Step Command

• Monitor the operation duration (not

supported in the UDP jitter and voice operations):

reaction item-number checked-element

probe-duration threshold-type { accumulate accumulate-occurrences | average | consecutive consecutive-occurrences } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

• Monitor failure times (not supported in the

UDP jitter and voice operations):

reaction item-number checked-element

probe-fail threshold-type { accumulate

accumulate-occurrences | consecutive

consecutive-occurrences } [ action-type { none

| trap-only } ]

• Monitor the round-trip time (only for the in

UDP jitter and voice operations):

reaction item-number checked-element rtt

threshold-type { accumulate accumulate-occurrences | average }

threshold-value upper-threshold

lower-threshold [ action-type { none | trap-only } ]

• Monitor packet loss (only for the UDP jitter

5. Configure

threshold monitoring.

and voice operations):

reaction item-number checked-element

packet-loss threshold-type accumulate

accumulate-occurrences [ action-type { none

| trap-only } ]

• Monitor the one-way jitter (only for the UDP

jitter and voice operations): reaction item-number checked-element

{ jitter-ds | jitter-sd } threshold-type

{ accumulate accumulate-occurrences |

average } threshold-value upper-threshold

lower-threshold [ action-type { none |

trap-only } ]

• Monitor the one-way delay (only for the UDP

jitter and voice operations): reaction item-number checked-element

{ owd-ds | owd-sd } threshold-value upper-threshold lower-threshold

• Monitor the ICPIF value (only for the voice

operation):

reaction item-number checked-element icpif

threshold-value upper-threshold

lower-threshold [ action-type { none | trap-only } ]

• Monitor the MOS value (only for the voice

operation):

reaction item-number checked-element mos

threshold-value upper-threshold

lower-threshold [ action-type { none | trap-only } ]

Remarks

N/A

Configuring the NQA statistics collection function

NQA forms statistics within the same collection interval as a statistics group. To display information about the statistics groups, use the display nqa statistics command.

NQA does not generate any statistics group for the operation that runs once. To set the NQA operation to run only once, use the frequency command to set the interval to 0 milliseconds.

To configure the NQA statistics collection function:

Step Command

1. Enter system view.

2. Create an NQA operation

and enter NQA operation view.

3. Specify an NQA operation

type and enter its view.

4. (Optional.) Specify the

interval for collecting the statistics.

5. (Optional.) Specify the

maximum number of statistics groups that can be saved.

6. (Optional.) Specify the hold

time of statistics groups.

system-view N/A

nqa entry admin-name operation-tag

type { dhcp | dlsw | dns | ftp | http | icmp-echo | path-jitter | snmp | tcp | udp-echo | udp-jitter| udp-tracert | voice }

statistics interval interval The default setting is 60 minutes.

statistics max-group number

statistics hold-time hold-time

Remarks

By default, no NQA operation is created.

The UDP tracert operation does not support the NQA statistics collection function.

The default setting is two groups.

To disable collecting NQA statistics, set the maximum number to 0.

When the maximum number of statisti cs groups is re ached, to save a new statistics group, the oldest statistics group is deleted.

The default setting is 120 minutes.

A statistics group is deleted when its hold time expires.

Configuring the saving of NQA history records

Step Command

1. Enter system view.

2. Create an NQA

operation and enter NQA operation view.

3. Enter NQA operation

type view.

system-view N/A

nqa entry admin-name operation-tag

type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo | udp-tracert }

Remarks

By default, no NQA operation is created.

The UDP jitter, path jitter, and voice operations do not support saving history records.

Step Command

4. Enable the saving of

history records for the NQA operation.

5. (Optional.) Set the

lifetime of history records.

6. (Optional.) Specify the

maximum number of history records that can be saved.

7. (Optional.) Display

NQA history records.

history-record enable

history-record keep-time keep-time

history-record number number

display nqa history N/A

Remarks

By default, this function is enabled only for the UDP tracert operation.

The default setting is 120 minutes.

A record is deleted when its lifetime is reached.

The default setting is 50.

If the maximum number of history records for an NQA operation is reached, the earliest history records are deleted.

Scheduling the NQA operation on the NQA client

The NQA operation works between the specified start time and the end time (the start time plus operation duration). If the specified start time is ahead of the system time, the operation starts immediately. If both the specified start and end time are ahead of the system time, the operation does not start. To display the current system time, use the display clock command.

When you schedule an NQA operation, follow these restrictions and guidelines:

• You cannot enter the operation type view or the operation view of a scheduled NQA operation.

• A system time adjustment does not affect started or completed NQA operations. It affects only the

NQA operations that have not started.

To schedule the NQA operation on the NQA client:

Step Command

1. Enter system view.

2. Specify the scheduling parameters

for an NQA operation.

system-view

nqa schedule admin-name operation-tag start-time { hh:mm:ss

[ yyyy/mm/dd | mm/dd/yyyy ] | now } lifetime { lifetime | forever } [ recurring ]

Configuring NQA templates on the NQA client

An NQA template is a set of operation parameters, such as the destination address, the destination port number, and the destination server URL. You can use an NQA template in a feature module to provide statistics. You can create multiple templates on a device, and each template must be uniquely named.

NQA template supports the ICMP, DNS, HTTP, TCP, and FTP operation types.

Some operation parameters for an NQA template can be specified by the template configuration or the feature that uses the template. When both are specified, the parameters in the template configuration take effect.

Configuring the ICMP template

A feature that uses the ICMP template performs the ICMP operation to measure the reachability of a destination device. The ICMP template is supported in both IPv4 and IPv6 networks.

To configure the ICMP template:

Step Command

1. Enter system view.

2. Create an ICMP template and

enter its view.

system-view N/A

nqa template icmp name N/A

• IPv4 address:

3. (Optional.) Specify the

destination IPv4 or IPv6 address of the operation.

4. Specify the payload size in

each ICMP request.

5. Specify the string to be filled in

the payload of each request.

6. (Optional.) Specify the IP

address of the specified interface as the source IP address of ICMP echo requests.

destination ip ip-address

• IPv6 address:

destination ipv6

ipv6-address

data-size size The default setting is 100 bytes.

data-fill string

source interface interface-type interface-number

Remarks

By default, no destination IP address is configured.

The default setting is the hexadecimal number

00010203040506070809.

By default, no source IP address is specified. The requests use the primary IP address of the output interface as their source IP address.

The specified source interface must be up.

If you configure the source interface command with the source ip or source ipv6 command, the most recent configuration takes effect.

7. (Optional.) Specify the source

IPv4 or IPv6 address for the probe packets.

• IPv4 address:

source ip ip-address

• IPv6 address:

source ipv6 ipv6-address

Configuring the DNS template

A feature that uses the DNS template performs the DNS operation to determine the status of the server. It is supported in both IPv4 and IPv6 networks.

In DNS template view, you can specify the address expected to be returned. If the returned IP addresses include the expected address, the DNS server is valid and the operation succeeds. Otherwise, the operation fails.

Create a mapping between the domain name and an address before you perform the DNS operation. For information about configuring the DNS server, see Layer 3—IP Services Configuration Guide.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

To configure the DNS template:

Step Command

1. Enter system view.

2. Create a DNS template and

enter DNS template view.

3. (Optional.) Specify the

destination IPv4 or IPv6 address of DNS packets.

4. Configure the destination port

number for the operation.

5. Specify the domain name that

needs to be translated.

6. Configure the domain name

resolution type.

7. (Optional.) Specify the source

IPv4 or IPv6 address for the probe packets.

system-view N/A

nqa template dns name N/A

• IPv4 address:

destination ip ip-address

• IPv6 address:

destination ipv6 ipv6-address

destination port port-number

resolve-target domain-name

resolve-type { A | AAAA }

• IPv4 address:

source ip ip-address

• IPv6 address:

source ipv6 ipv6-address

Remarks

By default, no destination address is specified.

By default, the destination port number is 53.

By default, no domain name is specified.

By default, the type is type A.

A type A query resolves a domain name to a mapped IPv4 address, and a type AAAA query to a mapped IPv6 address.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

8. (Optional.) Configure the

source port for probe packets.

9. (Optional.) Specify the IPv4 or

IPv6 address that is expected to be returned.

source port port-number

• IPv4 address:

expect ip ip-address

• IPv6 address:

expect ipv6 ipv6-address

Configuring the TCP template

A feature that uses the TCP template performs the TCP operation to test the following items:

• Whether the NQA client can establish a TCP connection to a specific port on the server.

• Whether the requested service is available on the server.

In TCP template view, you can specify the expected data to be returned. If you do not specify the expected data, the TCP operation tests only whether the client can establish a TCP connection to the server.

o configure the TCP template:

By default, no source port number is configured.

By default, no expected IP address is specified.

Step Command

1. Enter system view.

2. Create a TCP template and

enter its view.

3. (Optional.) Specify the

destination IPv4 or IPv6 address of the operation.

4. (Optional.) Configure the

destination port number for the operation.

5. Specify the string to be filled in

the payload of each request.

6. (Optional.) Specify the source

IPv4 or IPv6 address for the probe packets.

system-view N/A

nqa template tcp name N/A

• IPv4 address:

destination ip ip-address

• IPv6 address:

destination ipv6 ipv6-address

destination port port-number

data-fill string

• IPv4 address:

source ip ip-address

• IPv6 address:

source ipv6 ipv6-address

Remarks

By default, no destination address is specified.

The destination address must be the same as the IP address of the listening service configured on the NQA server.

By default, no destination port number is configured.

The destination port number must be the same as the port number of the listening service on the NQA server.

The default setting is the hexadecimal number

00010203040506070809.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

7. (Optional.) Configure the

expected data.

expect data expression [ offset number ]

Configuring the HTTP template

A feature that uses the HTTP template performs the HTTP operation to measure the time it takes the NQA client to obtain data from an HTTP server.

The expected data is checked only when the expected data is configured and the HTTP response contains the Content-Length field in the HTTP header. The Content-Length field indicates the packet body length, and it does not include the header length. An HTTP packet with this field indicates that the packet data does not include the multipart type and the packet body is a data type.

The status code of the HTTP packet is a three-digit field in decimal notation, and it includes the status information for the HTTP server. The first digit defines the class of response, and the last two digits do not have any categorization role.

Configure the HTTP server before you perform the HTTP operation.

To configure the HTTP template:

By default, no expected data is configured.

The expected data is checked only when you configure both the data-fill and expect-data commands.

Step Command

1. Enter system view.

2. Create an HTTP template and

enter its view.

3. Specify the URL of the

destination HTTP server.

4. Specify an HTTP login

username.

5. Specify an HTTP login

password.

6. Specify the HTTP operation

type.

system-view N/A

nqa template http name N/A

url url

username username

password { cipher | simple } password

operation { get | post | raw }

Remarks

By default, no URL is specified for the destination HTTP server.

Enter the URL in one of the following formats:

• http://host/resource.

• http://host:port/resource.

By default, no HTTP login username is specified.

By default, no HTTP login password is specified.

By default, the HTTP operation type is get, which means obtaining data from the HTTP server.

In the HTTP raw operation, use the raw-request command to specify the content of the GET request to be sent to the HTTP server.

7. (Optional.) Enter raw request

view.

8. (Optional.) Enter or paste the

content of the GET request for the HTTP operation.

9. (Optional.) Save the input and

exit to HTTP template view.

10. (Optional.) Specify the source

IPv4 or IPv6 address for the probe packets.

11. (Optional.) Configure the

expected status codes.

12. (Optional.) Configure the

expected data.

This step is required for the raw operation.

raw-request

N/A

quit N/A

• IPv4 address:

source ip ip-address

• IPv6 address:

source ipv6 ipv6-address

expect status status-list

expect data expression

[ offset number ]

Every time you enter the raw request view, the previously configured content of the GET request is removed.

This step is required for the raw operation.

By default, no contents are specified.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

By default, no expected status code is configured.

By default, no expected data is configured.

Configuring the FTP template

A feature that uses the FTP template performs the FTP operation. The operation measures the time it takes the NQA client to transfer a file to or download a file from an FTP server.

Configure the username and password for the FTP client to log in to the FTP server before you perform an FTP operation. For information about configuring the FTP server, see Fundamentals Configuration Guide.

To configure the FTP template:

Step Command

1. Enter system view.

2. Create an FTP template

and enter its view.

3. Specify the URL of the

destination FTP server.

4. (Optional.) Specify the FTP

operation type.

5. Specify an FTP login

username.

system-view N/A

nqa template ftp name N/A

url url

operation { get | put }

username username

Remarks

By default, no URL is specified for the destination FTP server.

Enter the URL in one of the following formats:

• ftp://host/filename.

• ftp://host:port/filename.

When you perform the get operation, the file name is required.

When you perform the put operation, the filename argument does not take effect, even if it is specified. The file name for the put operation is determined by the filename command.

By default, the FTP operation type is get, which means obtaining files from the FTP server.

By default, no FTP login username is specified.

6. Specify an FTP login

password.

7. (Optional.) Specify the

name of a file to be transferred.

8. Set the data transmission

mode.

9. (Optional.) Specify the

source IPv4 or IPv6 address for the probe packets.

password { cipher | simple }

password

filename filename

mode { active | passive } The default mode is active.

• IPv4 address:

source ip ip-address

• IPv6 address:

source ipv6 ipv6-address

By default, no FTP login password is specified.

This step is required if you perform the put operation.

This configuration does not take effect for the get operation.

By default, no file is specified.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

Configuring optional parameters for the NQA template

Step Command

1. Enter system view.

system-view N/A

Remarks

Step Command

2. Create an NQA template

and enter its view.

3. Configure a description.

4. Specify the interval at

which the NQA operation repeats.

5. Specify the probe timeout

time.

6. Specify the TTL for probe

packets.

7. Specify the ToS value in

the IP header of probe packets.

8. Specify the VPN where

the operation is performed.

9. Configure the number of

consecutive successful probes that lead to a successful operation.

nqa template { dns | ftp | http | icmp | tcp } name

description text By default, no description is configured.

frequency interval

probe timeout timeout The default setting is 3000 milliseconds.

ttl value The default setting is 20.

tos value The default setting is 0.

vpn-instance vpn-instance-name

reaction trigger probe-pass count

Remarks

N/A

The default setting is 5000 milliseconds.

If the operation is not completed when the interval expires, the next operation does not start.

By default, the operation is performed on the public network.

The default setting is 3.

If the number of consecutive successful probes for an NQA operation is reached, the NQA client notifies the feature that uses the template of the successful operation event.

10. Configure the number of

consecutive probe failures that lead to an operation failure.

reaction trigger probe-fail count

The default setting is 3.

If the number of consecutive probe failures for an NQA operation is reached, the NQA client notifies the feature that uses the NQA template of the operation failure.

Displaying and maintaining NQA

Execute display commands in any view.

Task Command

Display history records of NQA operations.

Display the current monitoring results of reaction entries.

Display the most recent result of the NQA operation.

Display NQA statistics. display nqa statistics [ admin-name operation-tag ]

Display NQA server status. display nqa server status

display nqa history [ admin-name operation-tag ]

display nqa reaction counters [ admin-name operation-tag

[ item-number ] ]

display nqa result [ admin-name operation-tag ]

NQA configuration examples

ICMP echo operation configuration example

Network requirements

As shown in Figure 7, configure an ICMP echo operation from the NQA client Device A to Device B to test the round-trip time. The next hop of Device A is Device C.

Figure 7 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create an ICMP echo operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type icmp-echo

# Specify the destination IP address of ICMP echo requests as 10.2.2.2.

[DeviceA-nqa-admin-test1-icmp-echo] destination ip 10.2.2.2

# Configure 10.1.1.2 as the next hop. The ICMP echo requests are sent through Device C to Device B.

[DeviceA-nqa-admin-test1-icmp-echo] next-hop 10.1.1.2

# Configure the ICMP echo operation to perform 10 probes.

[DeviceA-nqa-admin-test1-icmp-echo] probe count 10

# Specify the probe timeout time for the ICMP echo operation as 500 milliseconds.

[DeviceA-nqa-admin-test1-icmp-echo] probe timeout 500

# Configure the ICMP echo operation to repeat at an interval of 5000 milliseconds.

[DeviceA-nqa-admin-test1-icmp-echo] frequency 5000

# Enable saving history records.

[DeviceA-nqa-admin-test1-icmp-echo] history-record enable

# Configure the maximum number of history records that can be saved as 10.

[DeviceA-nqa-admin-test1-icmp-echo] history-record number 10 [DeviceA-nqa-admin-test1-icmp-echo] quit

# Start the ICMP echo operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the ICMP echo operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the ICMP echo operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 2/5/3 Square-Sum of round trip time: 96 Last succeeded probe time: 2011-08-23 15:00:01.2 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the ICMP echo operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test) history records: Index Response Status Time 370 3 Succeeded 2007-08-23 15:00:01.2 369 3 Succeeded 2007-08-23 15:00:01.2 368 3 Succeeded 2007-08-23 15:00:01.2 367 5 Succeeded 2007-08-23 15:00:01.2 366 3 Succeeded 2007-08-23 15:00:01.2 365 3 Succeeded 2007-08-23 15:00:01.2 364 3 Succeeded 2007-08-23 15:00:01.1 363 2 Succeeded 2007-08-23 15:00:01.1 362 3 Succeeded 2007-08-23 15:00:01.1 361 2 Succeeded 2007-08-23 15:00:01.1

The output shows th at t he packets sent by Device A can reach Device B through Devic e C. No packet loss occurs during the operation. The minimum, maximum, and average round-trip times are 2, 5, and 3 milliseconds, respectively.

DHCP operation configuration example

Network requirements

As shown in Figure 8, configure a DHCP operation to test the time required for Router A to obtain an IP address from the DHCP server.

Figure 8 Network diagram

NQA client

10.1.1.1/16

Configuration procedure

# Create a DHCP operation.

<RouterA> system-view [RouterA] nqa entry admin test1 [RouterA-nqa-admin-test1] type dhcp

# Specify the DHCP server IP address 10.1.1.2 as the destination address.

[RouterA-nqa-admin-test1-dhcp] destination ip 10.1.1.2

# Enable the saving of history records.

[RouterA-nqa-admin-test1-dhcp] history-record enable [RouterA-nqa-admin-test1-dhcp] quit

# Start the DHCP operation.

[RouterA] nqa schedule admin test1 start-time now lifetime forever

# After the DHCP operation runs for a period of time, stop the operation.

[RouterA] undo nqa schedule admin test1

10.1.1.2/16

DHCP server

Router BRouter A

# Display the most recent result of the DHCP operation.

[RouterA] display nqa result admin test1 NQA entry (admin admin, tag test) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 512/512/512 Square-Sum of round trip time: 262144 Last succeeded probe time: 2007-11-22 09:54:03.8 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the DHCP operation.

[RouterA] display nqa history admin test1 NQA entry (admin admin, tag test) history records: Index Response Status Time 1 512 Succeeded 2007-11-22 09:54:03.8

The output shows that it took Router A 512 milliseconds to obtain an IP address from the DHCP server.

DNS operation configuration example

Network requirements

As shown in Figure 9, configure a DNS operation to test whether Device A can perform address resolution through the DNS server and test the resolution time.

Figure 9 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create a DNS operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type dns

# Specify the IP address of the DNS server 10.2.2.2 as the destination address.

[DeviceA-nqa-admin-test1-dns] destination ip 10.2.2.2

# Specify the domain name to be translated as host.com.

[DeviceA-nqa-admin-test1-dns] resolve-target host.com

# Enable the saving of history records.

[DeviceA-nqa-admin-test1-dns] history-record enable [DeviceA-nqa-admin-test1-dns] quit

# Start the DNS operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the DNS operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the DNS operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 62/62/62 Square-Sum of round trip time: 3844 Last succeeded probe time: 2011-11-10 10:49:37.3 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the DNS operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test) history records: Index Response Status Time 1 62 Succeeded 2011-11-10 10:49:37.3

The output shows that it took Device A 62 milliseconds to translate domain name host.com into an IP address.

FTP operation configuration example

Network requirements

As shown in Figure 10, configure an FTP operation to test the time required for Device A to upload a file to the FTP server. The login username and password are admin and systemtest, respectively. The file to be transferred to the FTP server is config.txt.

Figure 10 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create an FTP operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type ftp

# Specify the URL of the FTP server.

[DeviceA-nqa-admin-test-ftp] url ftp://10.2.2.2

# Specify 10.1.1.1 as the source IP address.

[DeviceA-nqa-admin-test1-ftp] source ip 10.1.1.1

# Configure the device to upload file config.txt to the FTP server.

[DeviceA-nqa-admin-test1-ftp] operation put [DeviceA-nqa-admin-test1-ftp] filename config.txt

# Specify the username for the FTP operation as admin.

[DeviceA-nqa-admin-test1-ftp] username admin

# Specify the password for the FTP operation as systemtest.

[DeviceA-nqa-admin-test1-ftp] password simple systemtest

# Enable the saving of history records.

[DeviceA-nqa-admin-test1-ftp] history-record enable [DeviceA-nqa-admin-test1-ftp] quit

# Start the FTP operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the FTP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the FTP operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 173/173/173 Square-Sum of round trip time: 29929 Last succeeded probe time: 2011-11-22 10:07:28.6 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the FTP operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 173 Succeeded 2011-11-22 10:07:28.6

The output shows that it took Device A 173 milliseconds to upload a file to the FTP server.

HTTP operation configuration example

Network requirements

As shown in Figure 11, configure an HTTP operation on the NQA client to test the time required to obtain data from the HTTP server.

Figure 11 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create an HTTP operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type http

# Specify the URL of the HTTP server.

[DeviceA-nqa-admin-test-http] url http://10.2.2.2/index.htm

# Configure the HTTP operation to get data from the HTTP server.

[DeviceA-nqa-admin-test1-http] operation get

# Configure the operation to use HTTP version 1.0.

[DeviceA-nqa-admin-test1-http] version v1.0

# Enable the saving of history records.

[DeviceA-nqa-admin-test1-http] history-record enable [DeviceA-nqa-admin-test1-http] quit

# Start the HTTP operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the HTTP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the HTTP operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 64/64/64 Square-Sum of round trip time: 4096 Last succeeded probe time: 2011-11-22 10:12:47.9 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the HTTP operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 64 Succeeded 2011-11-22 10:12:47.9

The output shows that it took Device A 64 milliseconds to obtain data from the HTTP server.

UDP jitter operation configuration example

Network requirements

As shown in Figure 12, configure a UDP jitter operation to test the jitter, delay, and round-trip time between Device A and Device B.

Figure 12 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown.)

2. Configure static routes or a routing protocol to make sure the devices can reach each other.

(Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view [DeviceB] nqa server enable

# Configure a listening service to listen on the IP address 10.2.2.2 and UDP port 9000.

[DeviceB] nqa server udp-echo 10.2.2.2 9000

4. Configure Device A:

# Create a UDP jitter operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type udp-jitter

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqa-admin-test1-udp-jitter] destination ip 10.2.2.2 [DeviceA-nqa-admin-test1-udp-jitter] destination port 9000

# Configure the operation to repeat at an interval of 1000 milliseconds.

[DeviceA-nqa-admin-test1-udp-jitter] frequency 1000 [DeviceA-nqa-admin-test1-udp-jitter] quit

# Start the UDP jitter operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the UDP jitter operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the UDP jitter operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 15/32/17 Square-Sum of round trip time: 3235 Last packet received time: 2011-05-29 13:56:17.6 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 UDP-jitter results: RTT number: 10 Min positive SD: 4 Min positive DS: 1 Max positive SD: 21 Max positive DS: 28 Positive SD number: 5 Positive DS number: 4 Positive SD sum: 52 Positive DS sum: 38

Positive SD average: 10 Positive DS average: 10 Positive SD square-sum: 754 Positive DS square-sum: 460 Min negative SD: 1 Min negative DS: 6 Max negative SD: 13 Max negative DS: 22 Negative SD number: 4 Negative DS number: 5 Negative SD sum: 38 Negative DS sum: 52 Negative SD average: 10 Negative DS average: 10 Negative SD square-sum: 460 Negative DS square-sum: 754 One way results: Max SD delay: 15 Max DS delay: 16 Min SD delay: 7 Min DS delay: 7 Number of SD delay: 10 Number of DS delay: 10 Sum of SD delay: 78 Sum of DS delay: 85 Square-Sum of SD delay: 666 Square-Sum of DS delay: 787 SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: 0

# Display the statistics of the UDP jitter operation.

[DeviceA] display nqa statistics admin test1 NQA entry (admin admin, tag test1) test statistics: NO. : 1 Start time: 2011-05-29 13:56:14.0 Life time: 47 seconds Send operation times: 410 Receive response times: 410 Min/Max/Average round trip time: 1/93/19 Square-Sum of round trip time: 206176 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 UDP-jitter results: RTT number: 410 Min positive SD: 3 Min positive DS: 1 Max positive SD: 30 Max positive DS: 79 Positive SD number: 186 Positive DS number: 158 Positive SD sum: 2602 Positive DS sum: 1928 Positive SD average: 13 Positive DS average: 12 Positive SD square-sum: 45304 Positive DS square-sum: 31682 Min negative SD: 1 Min negative DS: 1 Max negative SD: 30 Max negative DS: 78 Negative SD number: 181 Negative DS number: 209 Negative SD sum: 181 Negative DS sum: 209 Negative SD average: 13 Negative DS average: 14 Negative SD square-sum: 46994 Negative DS square-sum: 3030 One way results: Max SD delay: 46 Max DS delay: 46

Min SD delay: 7 Min DS delay: 7 Number of SD delay: 410 Number of DS delay: 410 Sum of SD delay: 3705 Sum of DS delay: 3891 Square-Sum of SD delay: 45987 Square-Sum of DS delay: 49393 SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: 0

SNMP operation configuration example

Network requirements

As shown in Figure 13, configure an SNMP operation to test the time the NQA client uses to get a response from the SNMP agent.

Figure 13 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown.)

2. Configure static routes or a routing protocol to make sure the devices can reach each other.

(Details not shown.)

3. Configure the SNMP agent (Device B):

# Set the SNMP version to all.

<DeviceB> system-view [DeviceB] snmp-agent sys-info version all

# Set the read community to public.

[DeviceB] snmp-agent community read public

# Set the write community to private.

[DeviceB] snmp-agent community write private

4. Configure Device A:

# Create an SNMP operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type snmp

# Configure 10.2.2.2 as the destination IP address of the SNMP operation.

[DeviceA-nqa-admin-test1-snmp] destination ip 10.2.2.2

# Enable the saving of history records.

[DeviceA-nqa-admin-test1-snmp] history-record enable [DeviceA-nqa-admin-test1-snmp] quit

# Start the SNMP operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the SNMP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the SNMP operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 50/50/50 Square-Sum of round trip time: 2500 Last succeeded probe time: 2011-11-22 10:24:41.1 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the SNMP operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 50 Succeeded 2011-11-22 10:24:41.1

The output shows that it took Device A 50 milliseconds to receive a response from the SNMP agent.

TCP operation configuration example

Network requirements

As shown in Figure 14, configure a TCP operation to test the time required for Device A and Device B to establish a TCP connection.

Figure 14 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown.)

2. Configure static routes or a routing protocol to make sure the devices can reach each other.

(Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view [DeviceB] nqa server enable

# Configure a listening service to listen on the IP address 10.2.2.2 and TCP port 9000.

[DeviceB] nqa server tcp-connect 10.2.2.2 9000

4. Configure Device A:

# Create a TCP operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type tcp

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqa-admin-test1-tcp] destination ip 10.2.2.2 [DeviceA-nqa-admin-test1-tcp] destination port 9000

# Enable the saving of history records.

[DeviceA-nqa-admin-test1-tcp] history-record enable [DeviceA-nqa-admin-test1-tcp] quit

# Start the TCP operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the TCP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the TCP operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 13/13/13 Square-Sum of round trip time: 169 Last succeeded probe time: 2011-11-22 10:27:25.1 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the TCP operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 13 Succeeded 2011-11-22 10:27:25.1

The output shows that it took Device A 13 milliseconds to establish a TCP connection to port 9000 on the NQA server.

UDP echo operation configuration example

Network requirements

As shown in Figure 15, configure a UDP echo operation to test the round-trip time between Device A and Device B. The destination port number is 8000.

Figure 15 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown.)

2. Configure static routes or a routing protocol to make sure the devices can reach each other.

(Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view [DeviceB] nqa server enable

# Configure a listening service to listen on the IP address 10.2.2.2 and UDP port 8000.

[DeviceB] nqa server udp-echo 10.2.2.2 8000

4. Configure Device A:

# Create a UDP echo operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type udp-echo

# Configure 10.2.2.2 as the destination IP address and port 8000 as the destination port.

[DeviceA-nqa-admin-test1-udp-echo] destination ip 10.2.2.2 [DeviceA-nqa-admin-test1-udp-echo] destination port 8000

# Enable the saving of history records.

[DeviceA-nqa-admin-test1-udp-echo] history-record enable [DeviceA-nqa-admin-test1-udp-echo] quit

# Start the UDP echo operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the UDP echo operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the UDP echo operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 25/25/25 Square-Sum of round trip time: 625 Last succeeded probe time: 2011-11-22 10:36:17.9 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the UDP echo operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 25 Succeeded 2011-11-22 10:36:17.9

The output shows that the round-trip time between Device A and port 8000 on Device B is 25 milliseconds.

UDP tracert operation configuration example

Network requirements

As shown in Figure 16, configure a UDP tracert operation to determine the routing path from Device A to Device B.

Figure 16 Network diagram

Configuration procedure

1. Assign an IP address to each interface. (Details not shown.)

2. Configure static routes or a routing protocol to make sure the devices can reach each other.

(Details not shown.)

3. Use the ip ttl-expires enable command on the intermediate device and use the ip unreachables

enable command on Device B.

4. Configure Device A:

# Create a UDP tracert operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type udp-tracert

# Configure 10.2.2.2 as the destination IP address and port 33434 as the destination port.

[DeviceA-nqa-admin-test1-udp-tracert] destination ip 10.2.2.2 [DeviceA-nqa-admin-test1-udp-tracert] destination port 33434

# Configure Device A to perform three probes to each hop.

[DeviceA-nqa-admin-test1-udp-tracert] probe count 3

# Configure the probe timeout time as 500 milliseconds.

[DeviceA-nqa-admin-test1-udp-tracert] probe timeout 500

# Configure the UDP tracert operation to repeat at an interval of 5000 milliseconds.

[DeviceA-nqa-admin-test1-udp-tracert] frequency 5000

# Specify the output interface for UDP packets as GigabitEthernet 2/0/1.

[DeviceA-nqa-admin-test1-udp-tracert] out interface gigabitethernet 2/0/1

# Enable the no-fragmentation function.

[DeviceA-nqa-admin-test1-udp-tracert] no-fragment enable

# Specify the maximum number of consecutive probe failures as 6.

[DeviceA-nqa-admin-test1-udp-tracert] max-failure 6

# Set the TTL value to 1 for UDP packets in the start round of the UDP tracert operation.

[DeviceA-nqa-admin-test1-udp-tracert] init-ttl 1

# Start the UDP tracert operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the UDP tracert operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the UDP tracert operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 6 Receive response times: 6 Min/Max/Average round trip time: 1/1/1 Square-Sum of round trip time: 1 Last succeeded probe time: 2013-09-09 14:46:06.2 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 UDP-tracert results: TTL Hop IP Time 1 3.1.1.1 2013-09-09 14:46:03.2 2 10.2.2.2 2013-09-09 14:46:06.2

# Display the history records of the UDP tracert operation.

[DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index TTL Response Hop IP Status Time 1 2 2 10.2.2.2 Succeeded 2013-09-09 14:46:06.2 1 2 1 10.2.2.2 Succeeded 2013-09-09 14:46:05.2 1 2 2 10.2.2.2 Succeeded 2013-09-09 14:46:04.2 1 1 1 3.1.1.1 Succeeded 2013-09-09 14:46:03.2 1 1 2 3.1.1.1 Succeeded 2013-09-09 14:46:02.2 1 1 1 3.1.1.1 Succeeded 2013-09-09 14:46:01.2

Voice operation configuration example

Network requirements

As shown in Figure 17, configure a voice operation to test jitters between Device A and Device B.

Figure 17 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown.)

2. Configure static routes or a routing protocol to make sure the devices can reach each other.

(Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view [DeviceB] nqa server enable

# Configure a listening service to listen on IP address 10.2.2.2 and UDP port 9000.

[DeviceB] nqa server udp-echo 10.2.2.2 9000

4. Configure Device A:

# Create a voice operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type voice

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqa-admin-test1-voice] destination ip 10.2.2.2 [DeviceA-nqa-admin-test1-voice] destination port 9000 [DeviceA-nqa-admin-test1-voice] quit

# Start the voice operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the voice operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the voice operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1000 Receive response times: 1000 Min/Max/Average round trip time: 31/1328/33 Square-Sum of round trip time: 2844813 Last packet received time: 2011-06-13 09:49:31.1 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Voice results: RTT number: 1000 Min positive SD: 1 Min positive DS: 1 Max positive SD: 204 Max positive DS: 1297 Positive SD number: 257 Positive DS number: 259 Positive SD sum: 759 Positive DS sum: 1797 Positive SD average: 2 Positive DS average: 6 Positive SD square-sum: 54127 Positive DS square-sum: 1691967 Min negative SD: 1 Min negative DS: 1 Max negative SD: 203 Max negative DS: 1297 Negative SD number: 255 Negative DS number: 259 Negative SD sum: 759 Negative DS sum: 1796 Negative SD average: 2 Negative DS average: 6 Negative SD square-sum: 53655 Negative DS square-sum: 1691776 One way results: Max SD delay: 343 Max DS delay: 985 Min SD delay: 343 Min DS delay: 985 Number of SD delay: 1 Number of DS delay: 1

Sum of SD delay: 343 Sum of DS delay: 985 Square-Sum of SD delay: 117649 Square-Sum of DS delay: 970225 SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: 0 Voice scores: MOS value: 4.38 ICPIF value: 0

# Display the statistics of the voice operation.

[DeviceA] display nqa statistics admin test1 NQA entry (admin admin, tag test1) test statistics: NO. : 1

Start time: 2011-06-13 09:45:37.8 Life time: 331 seconds Send operation times: 4000 Receive response times: 4000 Min/Max/Average round trip time: 15/1328/32 Square-Sum of round trip time: 7160528 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Voice results: RTT number: 4000 Min positive SD: 1 Min positive DS: 1 Max positive SD: 360 Max positive DS: 1297 Positive SD number: 1030 Positive DS number: 1024 Positive SD sum: 4363 Positive DS sum: 5423 Positive SD average: 4 Positive DS average: 5 Positive SD square-sum: 497725 Positive DS square-sum: 2254957 Min negative SD: 1 Min negative DS: 1 Max negative SD: 360 Max negative DS: 1297 Negative SD number: 1028 Negative DS number: 1022 Negative SD sum: 1028 Negative DS sum: 1022 Negative SD average: 4 Negative DS average: 5 Negative SD square-sum: 495901 Negative DS square-sum: 5419 One way results: Max SD delay: 359 Max DS delay: 985 Min SD delay: 0 Min DS delay: 0 Number of SD delay: 4 Number of DS delay: 4 Sum of SD delay: 1390 Sum of DS delay: 1079 Square-Sum of SD delay: 483202 Square-Sum of DS delay: 973651 SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: 0 Voice scores: Max MOS value: 4.38 Min MOS value: 4.38 Max ICPIF value: 0 Min ICPIF value: 0

DLSw operation configuration example

Network requirements

As shown in Figure 18, configure a DLSw operation to test the response time of the DLSw device.

Figure 18 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create a DLSw operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type dlsw

# Configure 10.2.2.2 as the destination IP address.

[DeviceA-nqa-admin-test1-dlsw] destination ip 10.2.2.2

# Enable the saving of history records.

[DeviceA-nqa-admin-test1-dlsw] history-record enable [DeviceA-nqa-admin-test1-dlsw] quit

# Start the DLSw operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the DLSw operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the DLSw operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 19/19/19 Square-Sum of round trip time: 361 Last succeeded probe time: 2011-11-22 10:40:27.7 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error: 0 Failures due to other errors: 0

# Display the history records of the DLSw operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 19 Succeeded 2011-11-22 10:40:27.7

The output shows that the response time of the DLSw device is 19 milliseconds.

Path jitter operation configuration example

Network requirements

As shown in Figure 19, configure a path jitter operation to test the round trip time and jitters from Device A to Device B and Device C.

Figure 19 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Use the ip ttl-expires enable command on Device B and use the ip unreachables enable command on Device C.

# Create a path jitter operation.

<DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type path-jitter

# Specify 10.2.2.2 as the destination IP address of ICMP echo requests.

[DeviceA-nqa-admin-test1-path-jitter] destination ip 10.2.2.2

# Configure the path jitter operation to repeat at an interval of 10000 milliseconds.

[DeviceA-nqa-admin-test1-path-jitter] frequency 10000 [DeviceA-nqa-admin-test1-path-jitter] quit

# Start the path jitter operation.

[DeviceA] nqa schedule admin test1 start-time now lifetime forever

# After the path jitter operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the path jitter operation.

[DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Hop IP 10.1.1.2 Basic Results Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 9/21/14 Square-Sum of round trip time: 2419

Extended Results Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Path-Jitter Results Jitter number: 9 Min/Max/Average jitter: 1/10/4 Positive jitter number: 6 Min/Max/Average positive jitter: 1/9/4 Sum/Square-Sum positive jitter: 25/173 Negative jitter number: 3 Min/Max/Average negative jitter: 2/10/6 Sum/Square-Sum positive jitter: 19/153

Hop IP 10.2.2.2 Basic Results Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 15/40/28 Square-Sum of round trip time: 4493 Extended Results Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Path-Jitter Results Jitter number: 9 Min/Max/Average jitter: 1/10/4 Positive jitter number: 6 Min/Max/Average positive jitter: 1/9/4 Sum/Square-Sum positive jitter: 25/173 Negative jitter number: 3 Min/Max/Average negative jitter: 2/10/6 Sum/Square-Sum positive jitter: 19/153

NQA collaboration configuration example

Network requirements

As shown in Figure 20, configure a static route to Router C with Router B as the next hop on Router A. Associate the static route, a track entry, and an ICMP echo operation to monitor the state of the static route.

Figure 20 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown.)

2. On Router A, configure a static route, and associate the static route with track entry 1.

<RouterA> system-view [RouterA] ip route-static 10.1.1.2 24 10.2.1.1 track 1

3. On Router A, configure an ICMP echo operation:

# Create an NQA operation with the administrator name admin and operation tag test1.

[RouterA] nqa entry admin test1

# Configure the NQA operation type as ICMP echo.

[RouterA-nqa-admin-test1] type icmp-echo

# Configure 10.2.2.1 as the destination IP address.

[RouterA-nqa-admin-test1-icmp-echo] destination ip 10.2.1.1

# Configure the operation to repeat at an interval of 100 milliseconds.

[RouterA-nqa-admin-test1-icmp-echo] frequency 100

# Create reaction entry 1. If the number of consecutive probe failures reaches 5, collaboration is triggered.

[RouterA-nqa-admin-test1-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only

[RouterA-nqa-admin-test1-icmp-echo] quit

# Start the ICMP echo operation.

[RouterA] nqa schedule admin test1 start-time now lifetime forever

4. On Router A, create track entry 1, and associate it with reaction entry 1 of the NQA operation.

[RouterA] track 1 nqa entry admin test1 reaction 1

Verifying the configuration

# On Router A, display information about all the track entries.

[RouterA] display track all Track ID: 1 State: Positive Duration: 0 days 0 hours 0 minutes 0 seconds Notification delay: Positive 0, Negative 0 (in seconds) Tracked object: NQA entry: admin test1 Reaction: 1

# Display brief information about active routes in the routing table on Router A.

[RouterA] display ip routing-table

Destinations : 13 Routes : 13

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 Static 60 0 10.2.1.1 GE2/0/1

10.2.1.0/24 Direct 0 0 10.2.1.2 GE2/0/1

10.2.1.0/32 Direct 0 0 10.2.1.2 GE2/0/1

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.255/32 Direct 0 0 10.2.1.2 GE2/0/1

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

The output shows that the static route with the next hop 10.2.1.1 is active, and the status of the track entry is positive.

# Remove the IP address of GigabitEthernet 2/0/1 on Router B.

<RouterB> system-view [RouterB] interface gigabitethernet 2/0/1 [RouterB-GigabitEthernet2/0/1] undo ip address

# On Router A, display information about all the track entries.

[RouterA] display track all Track ID: 1 State: Negative Duration: 0 days 0 hours 0 minutes 0 seconds Notification delay: Positive 0, Negative 0 (in seconds) Tracked object: NQA entry: admin test1 Reaction: 1

# Display brief information about active routes in the routing table on Router A.

[RouterA] display ip routing-table

Destinations : 12 Routes : 12

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.0/24 Direct 0 0 10.2.1.2 GE2/0/1

10.2.1.0/32 Direct 0 0 10.2.1.2 GE2/0/1

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.255/32 Direct 0 0 10.2.1.2 GE2/0/1

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

The output shows that the static route does not exist, and the status of the track entry is negative.

ICMP template configuration example

Network requirements

As shown in Figure 21, configure an ICMP template for a feature to perform the ICMP echo operation from Device A to Device B.

Figure 21 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create ICMP template icmp.

<DeviceA> system-view [DeviceA] nqa template icmp icmp

# Specify 10.2.2.2 as the destination IP address of ICMP echo requests.

[DeviceA-nqatplt-icmp-icmp] destination ip 10.2.2.2

# Set the probe timeout time for the ICMP echo operation to 500 milliseconds.

[DeviceA-nqatplt-icmp-icmp] probe timeout 500

# Configure the ICMP echo operation to repeat at an interval of 3000 milliseconds.

[DeviceA-nqatplt-icmp-icmp] frequency 3000

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-icmp-icmp] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-icmp-icmp] reaction trigger probe-fail 2

DNS template configuration example

Network requirements

As shown in Figure 22, configure a DNS template for a feature to perform the DNS operation. The operation tests whether Device A can perform the address resolution through the DNS server.

Figure 22 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create DNS template dns.

<DeviceA> system-view [DeviceA] nqa template dns dns

# Specify the IP address of the DNS server 10.2.2.2 as the destination IP address.

[DeviceA-nqatplt-dns-dns] destination ip 10.2.2.2

# Specify the domain name to be translated as host.com.

[DeviceA-nqatplt-dns-dns] resolve-target host.com

# Specify the domain name resolution type as type A.

[DeviceA-nqatplt-dns-dns] resolve-type A

# Specify the expected IP address as 3.3.3.3.

[DeviceA-nqatplt-dns-dns] expect ip 3.3.3.3

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-dns-dns] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-dns-dns] reaction trigger probe-fail 2

TCP template configuration example

Network requirements

As shown in Figure 23, configure a TCP template for a feature to perform the TCP operation. The operation tests whether Device A can establish a TCP connection to Device B.

Figure 23 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown.)

2. Configure static routes or a routing protocol to make sure the devices can reach each other.

(Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view [DeviceB] nqa server enable

# Configure a listening service to listen to the IP address 10.2.2.2 and TCP port 9000.

[DeviceB] nqa server tcp-connect 10.2.2.2 9000

4. Configure Device A:

# Create TCP template tcp.

<DeviceA> system-view [DeviceA] nqa template tcp tcp

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqatplt-tcp-tcp] destination ip 10.2.2.2 [DeviceA-nqatplt-tcp-tcp] destination port 9000

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-tcp-tcp] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-tcp-tcp] reaction trigger probe-fail 2

HTTP template configuration example

Network requirements

As shown in Figure 24, configure an HTTP template for a feature to perform the HTTP operation. The operation tests whether the NQA client can get data from the HTTP server.

Figure 24 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create HTTP template http.

<DeviceA> system-view [DeviceA] nqa template http http

# Specify the URL of the server.

[DeviceA-nqatplt-http-http] url http://10.2.2.2/index.htm

# Configure the HTTP operation to get data from the HTTP server.

[DeviceA-nqatplt-http-http] operation get

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-http-http] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-http-http] reaction trigger probe-fail 2

FTP template configuration example

Network requirements

As shown in Figure 25, configure an FTP template for a feature to perform the FTP operation. The operation tests whether Device A can upload a file to the FTP server. The login username and password are admin and systemtest, respectively. The file to be transferred to the FTP server is config.txt.

Figure 25 Network diagram

Configuration procedure

# Assign each interface an IP address. (Details not shown.)

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create FTP template ftp.

<DeviceA> system-view [DeviceA] nqa template ftp ftp

# Specify the URL of the FTP server.

[DeviceA-nqatplt-ftp-ftp] url ftp://10.2.2.2

# Specify 10.1.1.1 as the source IP address.

[DeviceA-nqatplt-ftp-ftp] source ip 10.1.1.1

# Configure the device to upload file config.txt to the FTP server.

[DeviceA-nqatplt-ftp-ftp] operation put [DeviceA-nqatplt-ftp-ftp] filename config.txt

# Specify the username for the FTP server login as admin.

[DeviceA-nqatplt-ftp-ftp] username admin

# Specify the password for the FTP server login as systemtest.

[DeviceA-nqatplt-ftp-ftp] password simple systemtest

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-ftp-ftp] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-ftp-ftp] reaction trigger probe-fail 2

Configuring NTP

Synchronize your device with a trusted time source by using the Network Time Protocol (NTP) or changing the system time before you run it on a live network. Various tasks, including network management, charging, auditing, and distributed computing depend on an accurate system time setting, because the timestamps of system messages and logs use the system time.

Overview

NTP is typically used in large networks to dynamically synchronize time among network devices. It guarantees higher clock accuracy than manual system clock setting. In a small network that does not require high clock accuracy, you can keep time synchronized among devices by changing their system clocks one by one.

NTP runs over UDP and uses UDP port 123.

NOTE:

NTP is supported only on the following Layer 3 interfaces:

• Layer 3 Ethernet interfaces

• Layer 3 Ethernet subinterfaces

• Layer 3 aggregate interfaces

• VLAN interfaces

• Tunnel interfaces

How NTP works

Figure 26 shows how NTP synchronizes the system time between two devices (Device A and Device B, in

this example). Assume that:

• Prior to the time synchronization, the time of Device A is set to 10:00:00 am and that of Device B

is set to 11:00:00 am.

• Device B is used as the NTP server. Device A is to be synchronized to Device B.

• It takes 1 second for an NTP message to travel from Device A to Device B, and from Device B to

Device A.

• It takes 1 second for Device B to process the NTP message.

Figure 26 Basic work flow

The synchronization process is as follows:

1. Device A sends Device B an NTP message, which is timestamped when it leaves Device A. The

time stamp is 10:00:00 am (T1).

2. When this NTP message arrives at Device B, Device B adds a timestamp showing the time when

the message arrived at Device B. The timestamp is 11:00:01 am (T2).

3. When the NTP message leaves Device B, Device B adds a timestamp showing the time when the

message left Device B. The timestamp is 11:00:02 am (T3).

4. When Device A receives the NTP message, the local time of Device A is 10:00:03 am (T4).

Up to now, Device A can calculate the following parameters based on the timestamps:

• The roundtrip delay of the NTP message: Delay = (T4 – T1) – (T3 – T2) = 2 seconds.

• Time difference between Device A and Device B: Offset = ((T2 – T1) + (T3 – T4)) /2 = 1 hour.

Based on these parameters, Device A can be synchronized to Device B.

This is only a rough description of the work mechanism of NTP. For more information, see the related protocols and standards.

NTP architecture

NTP uses stratums 1 to 16 to define clock accuracy, as shown in Figure 27. A lower stratum value represents higher accuracy. Clocks at stratums 1 through 15 are in synchronized state, and clocks at stratum 16 are not synchronized.

Figure 27 NTP architecture

Primary servers

(Stratum 1)

Secondary servers

(Stratum 2)

Tertiary servers

(Stratum 3)

Quaternary servers

(Stratum 4)

Authoritative

clock

Server Client

Typically, a stratum 1 NTP server gets its time from an authoritative time source, such as an atomic clock. It provides time for other devices as the primary NTP server. The accuracy of each server is the stratum, with the topmost level (primary servers) assigned as one and each level downwards in the hierarchy assigned as one greater than the preceding level. NTP uses a stratum to describe how many NTP hops away a device is from the primary time server. A stratum 2 time server receives its time from a stratum 1 time server, and so on.

To ensure time accuracy and availability, you can specify multiple NTP servers for a device. The device selects an optimal NTP server as the clock source based on parameters such as stratum. The clock that the device selects is called the reference source. For more information about clock selection, see the related protocols and standards.

If the devices in a network cannot synchronize to an authoritative time source, you can perform the following tasks:

• Select a device that has a relatively accurate clock from the network.

• Use the local clock of the device as the reference clock to synchronize other devices in the network.

Association modes

Symmetric

peer

Symmetric

peer

Broadcast/multicast

server

Broadcast/multicast

client

NTP supports the following association modes:

• Client/server mode

• Symmetric active/passive mode

• Broadcast mode

• Multicast mode

Table 2 NTP association modes

g p

App

Mode Workin

On the client, specify the IP address of the NTP server.

A client sends a clock synchronization message to the NTP servers. Upon receiving the message, the servers automatically operate in server

Client/server

Symmetric active/passive

mode and send a reply.

If the client can be synchronized to multiple time servers, it selects an optimal clock and synchronizes its local clock to the optimal reference source after receiving the replies from the servers.

On the symmetric active peer, specify the IP address of the symmetric passive peer.

A symmetric active peer periodically sends clock synchronization messages to a symmetric passive peer. The symmetric passive peer automatically operates in symmetric passive mode and sends a reply.

If the symmetric active peer can be synchronized to multiple time servers, it selects an optimal clock and synchronizes its local clock to the optimal reference source after receiving the replies from the servers.

rocess

Principle

A client can synchronize to a server, but a server cannot synchronize to a client.

A symmetric active peer and a symmetric passive peer can be synchronized to each other. If both of them are synchronized, the peer with a higher stratum is synchronized to the peer with a lower stratum.

lication scenario

As Figure 27 sh mode is intended for configurations where devices of a higher stratum synchronize to devices with a lower stratum.

Figure 27 sh

mode is most often used between servers with the same stratum to operate as a backup for one another. If a server fails to communicate with all the servers of a lower stratum, the server can still synchronize to the servers of the same stratum.

ows, this

App

Mode Working process

A server periodically sends clock synchronization messages to the broadcast address

255.255.255.255. Clients listen to the broadcast messages from the servers to synchronize to the server according to the broadcast

Broadcast

Multicast

messages.

When a client receives the first broadcast message, the client and the server start to exchange messages to calculate the network delay between them. Then, only the broadcast server sends clock synchronization messages.

A multicast server periodically sends clock synchronization messages to the user-configured multicast address. Clients listen to the multicast messages from servers and synchronize to the server according to the received messages.

Principle

A broadcast client can synchronize to a broadcast server, but a broadcast server cannot synchronize to a broadcast client.

A multicast client can synchronize to a multicast server, but a multicast server cannot synchronize to a multicast client.

lication scenario

A broadcast server sends clock synchronization messages to synchronize clients in the same subnet. As Figure 27 sh broadcast mode is intended for configurations involving one or a few servers and a potentially large client population.

The broadcast mode has a lower time accuracy than the client/server and symmetric active/passive modes because only the broadcast servers send clock synchronization messages.

A multicast server can provide time synchronization for clients in the same subnet or in different subnets.

The multicast mode has a lower time accuracy than the client/server and symmetric active/passive modes.

ows,

In this document, an "NTP server" or a "server" refers to a device that operates as an NTP server in client/server mode. Time servers refer to all the devices that can provide time synchronization, including NTP servers, NTP symmetric peers, broadcast servers, and multicast servers.

NTP security

To improve time synchronization security, NTP provides the access control and authentication functions.

NTP access control

You can control NTP access by using an ACL. The access rights are in the following order, from least restrictive to most restrictive:

• Peer—Allows time requests and NTP control queries (such as alarms, authentication status, and time

server information) and allows the local device to synchronize itself to a peer device.

• Server—Allows time requests and NTP control queries, but does not allow the local device to

synchronize itself to a peer device.

• Synchronization—Allows only time requests from a system whose address passes the access list

criteria.

• Query—Allows only NTP control queries from a peer device to the local device.

The device processes an NTP request, as follows:

• If no NTP access control is configured, peer is granted to the local device and peer devices.

• If the IP address of the peer device matches a permit statement in an ACL for more than one access

right, the least restrictive access right is granted to the peer device. If a deny statement or no ACL is matched, no access right is granted.

• If no ACL is created for an access right, the associated access right is not granted.

• If no ACL is created for any access right, peer is granted.

This feature provides minimal security for a system running NTP. A more secure method is NTP authentication.

NTP authentication

Use this feature to authenticate the NTP messages for security purposes. If an NTP message passes authentication, the device can receive it and get time synchronization information. If not, the device discards the message. This function makes sure the device does not synchronize to an unauthorized time server.

Figure 28 NTP authentication

Message

Sender

Compute the

digest

Key value

Message

Key ID

Digest

Sends to the

receiver

Message

Key ID

Digest

Key value

Compute the

digest

Digest

Compare

Receiver

As shown in Figure 28, NTP authentication works as follows:

1. The sender uses the MD5 algorithm to calculate the NTP message according to the key identified

by a key ID. Then, it sends the calculated digest together with the NTP message and key ID to the receiver.

2. Upon receiving the message, the receiver performs the following actions: a. Finds the key according to the key ID in the message. b. Uses the MD5 algorithm to calculate the digest. c. Compares the digest with the digest contained in the NTP message. If they are the same, the

receiver accepts the message. Otherwise, it discards the message.

NTP for MPLS L3VPNs

In an MPLS L3VPN network, the device supports multiple VPN instances when:

• It functions as an NTP client to synchronize with the NTP server.

• It functions as a symmetric active peer to synchronize with the symmetric passive peer.

Only the client/server and symmetric active/passive modes support VPN instances. For more information about MPLS L3VPN, VPN instance, and PE, see MPLS Configuration Guide.

As shown in Figure 29, u provider edge (PE) devices, and services of the two VPNs are isolated. Time synchronization between PEs and devices of the two VPNs can be realized if you perform the following tasks:

sers in VPN 1 and VPN 2 are connected to the MPLS backbone network through

• Configure the PEs to operate in NTP client or symmetric active mode.

• Specify the VPN to which the NTP server or NTP symmetric passive peer belongs.

Figure 29 Network diagram

Protocols and standards

• RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis

• RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification

Configuration restrictions and guidelines

When you configure NTP, follow these restrictions and guidelines:

• You cannot configure both NTP and SNTP on the same device.

• Do not configure NTP on an aggregate member port.

• The NTP service and SNTP service are mutually exclusive. You can only enable either NTP service

or SNTP service at a time.

• To ensure time synchronization accuracy, H3C recommends not specifying more than one reference

source. Doing so might cause frequent time changes or even synchronization failures.

• Make sure you use the clock protocol comma nd to s pecif y the t im e proto co l as NTP on a n M DC . For

more information about the clock protocol command, see Fundamentals Command Reference.

• You can configure NTP only on one MDC.

Configuration task list

Tasks at a glance

(Required.) Enabling the NTP service

(Required.) Perform at least one of the following tasks:

• Configuring NTP association modes

• Configuring the local clock as a reference source

(Optional.) Configuring access control rights

Tasks at a glance

(Optional.) Configuring NTP authentication

(Optional.) Configuring NTP optional parameters

Enabling the NTP service

Step Command

1. Enter system view.

2. Enable the NTP service.

system-view N/A

ntp-service enable

Remarks

By default, the NTP service is not enabled.

Configuring NTP association modes

This section describes how to configure NTP association modes.

Configuring NTP in client/server mode

When the device operates in client/server mode, specify the IP address for the server on the client.

Follow these guidelines when you configure an NTP client:

• A server must be synchronized by other devices or use its local clock as a reference source before

synchronizing an NTP client. Otherwise, the client will not be synchronized to the NTP server.

• If the stratum level of a server is higher than or equal to a client, the client will not synchronize to that

server.

• You can configure multiple servers by repeating the ntp-service unicast-server and ntp-service ipv6

unicast-server commands.

To configure an NTP client:

Step Command

1. Enter system view.

system-view N/A

Remarks

Step Command

Remarks

• Specify an NTP server for the

device: ntp-service unicast-server { server-name | ip-address } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid |

priority | source interface-type

2. Specify an NTP server for the

device.

interface-number | version number ] *

• Specify an IPv6 NTP server for

the device:

ntp-service ipv6 unicast-server

{ server-name | ipv6-address } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid |

priority | source interface-type interface-number ] *

By default, no NTP server is specified for the device.

Configuring NTP in symmetric active/passive mode

When the device operates in symmetric active/passive mode, specify on a symmetric-active peer the IP address for a symmetric-passive peer.

Follow these guidelines when you configure a symmetric-active peer:

• Execute the ntp-service enable command on a symmetric passive peer to enable NTP. Otherwise,

the symmetric-passive peer will not process NTP messages from a symmetric-active peer.

• Either the symmetric-active peer, or the symmetric-passive peer, or both of them must be in

synchronized state. Otherwise, their time cannot be synchronized.

• You can configure multiple symmetric-passive peers by repeating the ntp-service unicast-peer or

ntp-service ipv6 unicast-peer command.

To configure a symmetric-active peer:

Step Command

1. Enter system view.

system-view N/A

Remarks

Step Command

• Specify a symmetric-passive

peer: ntp-service unicast-peer

{ peer-name | ip-address } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid |

priority | source interface-type

2. Specify a symmetric-passive

peer for the device.

interface-number | version number ] *

• Specify an IPv6

symmetric-passive peer: ntp-service ipv6 unicast-peer

{ peer-name | ipv6-address } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid |

priority | source interface-type interface-number ] *

Configuring NTP in broadcast mode

Remarks

By default, no symmetric-passive peer is specified.

A broadcast server must be synchronized by other devices or use its local clock as a reference source before synchronizing a broadcast client. Otherwise, the broadcast client will not be synchronized to the broadcast server.

Configure NTP in broadcast mode on both broadcast server and client.

Configuring a broadcast client

Step Command

1. Enter system view.

2. Enter interface view.

3. Configure the device to

operate in broadcast client mode.

Configuring the broadcast server

Step Command

1. Enter system view.

Remarks

system-view N/A

interface interface-type interface-number

ntp-service broadcast-client

Enter the interface for receiving NTP broadcast messages.

By default, the device does not operate in broadcast client mode.

After you execute the command, the device receives NTP broadcast messages from the specified interface.

Remarks

system-view N/A

2. Enter interface view.

interface interface-type interface-number

Enter the interface for sending NTP broadcast messages.

Step Command

3. Configure the device to

operate in NTP broadcast server mode.

ntp-service broadcast-server [ authentication-keyid keyid | version number ] *

Configuring NTP in multicast mode

A multicast server must be synchronized by other devices or use its local clock as a reference source before synchronizing a multicast client. Otherwise, the multicast client will not be synchronized to the multicast server.

Configure NTP in multicast mode on both a multicast server and client.

Configuring a multicast client

Step Command

1. Enter system view.

2. Enter interface view.

3. Configure the device to

operate in multicast client mode.

system-view N/A

interface interface-type interface-number

• Configure the device to operate

in multicast client mode: ntp-service multicast-client

[ ip-address ]

• Configure the device to operate

in IPv6 multicast client mode: ntp-service ipv6 multicast-client

ipv6-multicast-address

Remarks

By default, the device does not operate in broadcast server mode.

After you execute the command, the device receives NTP broadcast messages from the specified interface.

Remarks

Enter the interface for receiving NTP multicast messages.

By default, the device does not operate in multicast server mode.

After you execute the command, the device receives NTP multicast messages from the specified interface.

Configuring the multicast server

Step Command

1. Enter system view.

2. Enter interface view.

Remarks

system-view N/A

interface interface-type interface-number

Enter the interface for sending NTP multicast message.

Step Command

• Configure the device to operate

in multicast server mode: ntp-service multicast-server

[ ip-address ] [ authentication-keyid keyid |

3. Configure the device to

operate in multicast server mode.

ttl ttl-number | version number ] *

• Configure the device to operate

in multicast server mode: ntp-service ipv6 multicast-server ipv6-multicast-address [ authentication-keyid keyid | ttl ttl-number ] *

Configuring access control rights

Step Command

1. Enter system view.

2. Configure the NTP service

access control right for a peer device to access the local device.

system-view N/A

• Configure the NTP service

access control right for a peer device to access the local device

ntp-service access { peer | query | server | synchronization } acl-number

• Configure the IPv6 NTP service

access control right for a peer device to access the local device ntp-service ipv6 { peer | query | server | synchronization } acl acl-number

Remarks

By default, the device does not operate in multicast server mode.

After you execute the command, the device receives NTP multicast messages from the specified interface.

Remarks

By default, the NTP service access control right for a peer device to access the local device is peer.

Before you configure the NTP service access control right to the local device, create and configure an ACL associated with the access control right. For more information about ACL, see ACL and QoS Configuration Guide.

Configuring NTP authentication

This section provides instructions for configuring NTP authentication.

Configuring NTP authentication in client/server mode

When you configure NTP authentication in client/server mode:

• Enable NTP authentication.

• Configure an authentication key.

• Set the key as a trusted key on both client and server.

• Associate the key with the NTP server on the client.

The key IDs and key values configured on the server and client must be the same. Otherwise, NTP authentication fails.

To configure NTP authentication for a client:

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

• Associate the specified key with

an NTP server: ntp-service unicast-server

{ server-name | ip-address } [ vpn-instance vpn-instance-name ]

5. Associate the specified key

with an NTP server.

authentication-keyid keyid

• Associate the specified key with

an IPv6 NTP server: ntp-service ipv6 unicast-server

{ server-name | ipv6-address } [ vpn-instance vpn-instance-name ]

authentication-keyid keyid

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

By default, the trusted key is not associated with an NTP server.

To configure NTP authentication for a server:

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

NTP authentication results differ when different configurations are performed on client and server. For more information, see Table 3. (N/A in the ta

ble means that whether the configuration is performed does

not make any difference.)

Table 3 NTP authentication results

Client Server

Configure

a key and Enable NTP authentication

configure

it as a

trusted

Yes Yes Yes Yes Yes

Yes Yes Yes Yes No

Yes Yes Yes No N/A

Yes No Yes N/A N/A

Associate the key with an NTP server

Enable NTP authentication

Configure a key and configure it as a trusted key

Authentication result

Succeeded. NTP messages can be sent and received correctly.

Failed. NTP messages cannot be sent and received correctly.

No authentication.

Yes N/A No N/A N/A

No N/A N/A N/A N/A

NTP messages can be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Configuring NTP authentication in symmetric active/passive mode

When you configure NTP authentication in symmetric peers mode:

• Enable NTP authentication.

• Configure an authentication key.

• Set the key as a trusted key on both active peer and passive peer.

• Associate the key with the passive peer on the active peer.

The key IDs and key values configured on the active peer and passive peer must be the same. Otherwise, NTP authentication fails.

To configure NTP authentication for an active peer:

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

• Associate the specified key with

a passive peer: ntp-service unicast-peer

{ ip-address | peer-name } [ vpn-instance vpn-instance-name ]

5. Associate the specified key

with a passive peer.

authentication-keyid keyid

• Associate the specified key with

a passive peer: ntp-service ipv6 unicast-peer

{ ipv6-address | peer-name } [ vpn-instance vpn-instance-name ]

authentication-keyid keyid

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

By default, the trusted key is not associated with a passive peer.

To configure NTP authentication for a passive peer:

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

NTP authentication results differ when different configurations are performed on active peer and passive peer. For more information, see Table 4.

(N/A in the table means that whether the configuration is

performed does not make any difference.)

Table 4 NTP authentication results

Active

Enable NTP authentication

eer Passive

Configure a

key and

configure it

as a trusted

Associate the key with a passive

eer

Enable NTP authentication

eer

Configure a key and configure it as a trusted ke

Authentication result

Stratum level of the active and passive peers is not considered.

Active peer Passive

Configure a

Enable NTP authentication

Yes Yes Yes Yes Yes

Yes Yes Yes Yes No

Yes Yes Yes No N/A

Yes N/A No Yes N/A

Yes N/A No No N/A

key and

configure it

as a trusted

Associate the key with a passive

eer

Enable NTP authentication

eer

Configure a key and configure it as a trusted ke

Authentication result

Succeeded. NTP messages can be sent and received correctly.

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

No N/A N/A Yes N/A

No N/A N/A No N/A

The active peer has a higher stratum than the passive peer.

Yes No Yes N/A N/A

The passive peer has a higher stratum than the active peer.

Yes No Yes Yes N/A

Yes No Yes No N/A

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Configuring NTP authentication in broadcast mode

When you configure NTP authentication in broadcast mode:

• Enable NTP authentication.

• Configure an authentication key.

• Set the key as a trusted key on both the broadcast client and server.

• Configure an NTP authentication key on the broadcast server.

The key IDs and key values configured on the broadcast server and client must be the same. Otherwise, NTP authentication fails.

To configure NTP authentication for a broadcast client:

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

To configure NTP authentication for a broadcast server:

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

5. Enter interface view.

6. Associate the specified key

with the broadcast server.

interface interface-type interface-number

ntp-service broadcast-server authentication-keyid keyid

N/A

By default, the broadcast server is not associated with any key.

NTP authentication results differ when different configurations are performed on broadcast client and server. For more information, see Table 5. (N/A in the ta

ble means that whether the configuration is

performed does not make any difference.)

Table 5 NTP authentication results

Broadcast server

Configure

a key and Enable NTP authentication

configure

it as a

trusted

Yes Yes Yes Yes Yes

Yes Yes Yes Yes No

Yes Yes Yes No N/A

Yes No Yes Yes N/A

Yes No Yes No N/A

Associate the key with a broadcast server

Broadcast client

Enable NTP authentication

Configure a key and configure it as a trusted ke

Authentication result

Succeeded. NTP messages can be sent and received correctly.

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Failed. NTP messages

Yes N/A No Yes N/A

Yes N/A No No N/A

No N/A N/A Yes N/A

No N/A N/A No N/A

cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Configuring NTP authentication in multicast mode

When you configure NTP authentication in multicast mode:

• Enable NTP authentication.

• Configure an authentication key.

• Set the key as a trusted key on both the multicast client and server.

• Configure an NTP authentication key on the multicast server.

The key IDs and key values configured on the multicast server and client must be the same. Otherwise, NTP authentication fails.

To configure NTP authentication for a multicast client:

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

To configure NTP authentication for a multicast server:

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

Step Command

1. Enter system view.

2. Enable NTP authentication.

3. Configure an NTP

authentication key.

4. Configure the key as a trusted

key.

system-view N/A

ntp-service authentication enable

ntp-service authentication-keyid

keyid authentication-mode md5 { cipher | simple } value

ntp-service reliable authentication-keyid keyid

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

Remarks

By default, NTP authentication is disabled.

By default, no NTP authentication key is configured.

By default, no authentication key is configured as a trusted key.

5. Enter interface view.

interface interface-type interface-number

N/A

• Associate the specified key with

a multicast server: ntp-service multicast-server

[ ip-address ]

6. Associate the specified key

with the multicast server.

authentication-keyid keyid

• Associate the specified key with

an IPv6 multicast server: ntp-service ipv6 multicast-server

ipv6-multicast-address authentication-keyid keyid

By default, no multicast server is associated with the specified key.

NTP authentication results differ when different configurations are performed on broadcast client and server. For more information, see Table 6. (N/A in the ta

ble means that whether the configuration is

performed does not make any difference.)

Table 6 NTP authentication results

Multicast server Multicast client

Configure a

Enable NTP authentication

Yes Yes Yes Yes Yes

Yes Yes Yes Yes No

Yes Yes Yes No N/A

Yes No Yes Yes N/A

Yes No Yes No N/A

key and

configure it

as a trusted

Associate the key with a multicast server

Enable NTP authentication

Configure a key and configure it as a trusted ke

Authentication result

Succeeded. NTP messages can be sent and received correctly.

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Yes N/A No Yes N/A

Yes N/A No No N/A

No N/A N/A Yes N/A

No N/A N/A No N/A

Configuring NTP optional parameters

The configuration tasks in this section are optional tasks. Configure them to improve NTP security, performance, or reliability.

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Failed. NTP messages cannot be sent and received correctly.

No authentication. NTP messages can be sent and received correctly.

Specifying the source interface for NTP messages

To prevent interface status changes from causing NTP communication failures, configure the device to use the IP address of an interface that is always up. For example, you can configure the device to use a loopback interface as the source IP address for the NTP messages to be sent.

When the device responds to an NTP request, the source IP address of the NTP response is always the IP address of the interface that has received the NTP request.

Follow these guidelines when you specify the source interface for NTP messages:

• If you have specified the source interface for NTP messages in the ntp-service [ ipv6 ] unicast-server

or ntp-service [ ipv6 ] unicast-peer command, the interface specified in the ntp-service [ ipv6 ] unicast-server or ntp-service [ ipv6 ] unicast-peer command works as the source interface for NTP messages.

• If you have configured the ntp-service broadcast-server or ntp-service [ ipv6 ] multicast-server

command, the source interface for the broadcast or multicast NTP messages is the interface configured with the respective command.

To specify the source interface for NTP messages:

Step Command

1. Enter system view.

system-view N/A

Remarks

• Specify the source interface for

NTP messages: ntp-service source

2. Specify the source interface

for NTP messages.

interface-type interface-number

• Specify the source interface for

IPv6 NTP messages: ntp-service ipv6 source

interface-type interface-number

By default, no source interface is specified for NTP messages.

Disabling an interface from processing NTP messages

When NTP is enabled, all interfaces by default can process NTP messages. For security purposes, you can disable some of the interfaces from processing NTP messages.

To disable an interface from processing NTP messages:

Step Command

1. Enter system view.

2. Enter interface view.

system-view N/A

interface interface-type interface-number

• For IPv4:

undo ntp-service inbound

3. Disable the interface from

processing NTP messages.

enable

• For IPv6:

undo ntp-service ipv6 inbound enable

Remarks

N/A

By default, an interface processes NTP messages.

Configuring the maximum number of dynamic associations

NTP has the following types of associations:

• Static association—A manually created association.

• Dynamic association—Temporary association created by the system during NTP operation. A

dynamic association is removed if no messages are exchanged within about 12 minutes.

The following describes how an association is established in different association modes:

• Client/server mode—After you specify an NTP server, the system creates a static association on the

client. The server simply responds passively upon the receipt of a message, rather than creating an association (static or dynamic).

• Symmetric active/passive mode—After you specify a symmetric-passive peer on a symmetric active

peer, static associations are created on the symmetric-active peer, and dynamic associations are created on the symmetric-passive peer.

• Broadcast or multicast mode—Static associations are created on the server, and dynamic

associations are created on the client.

A single device can have a maximum of 128 concurrent associations, including static associations and dynamic associations.

Perform this task to restrict the number of dynamic associations to prevent dynamic associations from occupying too many system resources.

To configure the maximum number of dynamic associations:

Step Command

1. Enter system view.

2. Configure the maximum

number of dynamic sessions allowed to be established.

system-view N/A

ntp-service max-dynamic-sessions

number

Configuring a DSCP value for NTP packets

The DSCP value determines the sending precedence of a packet.

To configure a DSCP value for NTP packets:

Step Command

1. Enter system view.

2. Set a DSCP value for NTP

packets.

system-view N/A

• IPv4 packets:

ntp-service dscp dscp-value

• IPv6 packets:

ntp-service ipv6 dscp

dscp-value

Remarks

By default, the command can establish up to 100 dynamic sessions.

Remarks

The defaults for a DSCP value:

• 48 for IPv4 NTP packets.

• 56 for IPv6 NTP packets.

Configuring the local clock as a reference source

Follow these guidelines when you configure the local clock as a reference source:

H3C SR6600-X, R6600 Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Preface

Audience

Conventions

Command conventions

GUI conventions

Symbols

Network topology icons

Port numbering in examples

About the H3C SR6600/SR6600-X documentation set

Obtaining documentation

Technical support

Documentation feedback

Contents

Using ping, tracert, and system debugging

Ping

Using a ping command to test network connectivity

Ping example

Network requirements

Configuration procedure

Tracert

Prerequisites

Using a tracert command to identify failed or all nodes in a path

Tracert example

Network requirements

Configuration procedure

System debugging

Debugging information control switches

Debugging a feature module

Configuring NQA

Overview

NQA operation

Collaboration

Threshold monitoring

NQA configuration task list

Configuring the NQA server

Enabling the NQA client

Configuring NQA operations on the NQA client

NQA operation configuration task list

Configuring the ICMP echo operation

Configuring the DHCP operation

Configuring the DNS operation

Configuring the FTP operation

Configuring the HTTP operation

Configuring the UDP jitter operation

Configuring the SNMP operation

Configuring the TCP operation

Configuring the UDP echo operation

Configuring the UDP tracert operation

Configuring the voice operation

Configuring the DLSw operation

Configuring the path jitter operation

Configuring optional parameters for the NQA operation

Configuring the collaboration function

Configuring threshold monitoring

Threshold types

Triggered actions

Reaction entry

Configuration procedure

Configuring the NQA statistics collection function

Configuring the saving of NQA history records

Scheduling the NQA operation on the NQA client

Configuring NQA templates on the NQA client

Configuring the ICMP template

Configuring the DNS template

Configuring the TCP template

Configuring the HTTP template

Configuring the FTP template

Configuring optional parameters for the NQA template

Displaying and maintaining NQA

NQA configuration examples

ICMP echo operation configuration example

Network requirements

Configuration procedure

DHCP operation configuration example

Network requirements

Configuration procedure