11-Network Management and Monitoring Configuration Guide

HomeSupportResource CenterSwitchesS12500X-AF SeriesS12500X-AF SeriesTechnical DocumentsConfigure & DeployConfiguration GuidesH3C S12500X-AF Switch Series Configuration Guides(R26xx)-6W10211-Network Management and Monitoring Configuration Guide

01-Text

Download Book  (4.12 MB)

Contents

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· 4

System debugging· 5

Debugging information control switches· 6

Debugging a feature module· 6

Configuring NQA·· 7

Overview·· 7

NQA operation·· 7

Collaboration·· 8

Threshold monitoring· 8

NQA configuration task list 9

Configuring the NQA server 9

Enabling the NQA client 10

Configuring NQA operations on the NQA client 10

NQA operation configuration task list 10

Configuring the ICMP echo operation·· 11

Configuring the ICMP jitter operation·· 12

Configuring the DHCP operation·· 13

Configuring the DNS operation·· 13

Configuring the FTP operation·· 14

Configuring the HTTP operation·· 15

Configuring the UDP jitter operation·· 16

Configuring the SNMP operation·· 17

Configuring the TCP operation·· 18

Configuring the UDP echo operation·· 19

Configuring the UDP tracert operation·· 20

Configuring the voice operation·· 21

Configuring the DLSw operation·· 23

Configuring the path jitter operation·· 23

Configuring optional parameters for the NQA operation·· 24

Configuring the collaboration feature· 26

Configuring threshold monitoring· 26

Configuring the NQA statistics collection feature· 29

Configuring the saving of NQA history records· 29

Scheduling the NQA operation on the NQA client 30

Configuring NQA templates on the NQA client 30

NQA template configuration task list 31

Configuring the ICMP template· 31

Configuring the DNS template· 32

Configuring the TCP template· 33

Configuring the TCP half open template· 34

Configuring the UDP template· 35

Configuring the HTTP template· 36

Configuring the FTP template· 37

Configuring the RADIUS template· 38

Configuring optional parameters for the NQA template· 39

Displaying and maintaining NQA·· 40

NQA configuration examples· 40

ICMP echo operation configuration example· 40

ICMP jitter operation configuration example· 42

DHCP operation configuration example· 44

DNS operation configuration example· 45

FTP operation configuration example· 47

HTTP operation configuration example· 48

UDP jitter operation configuration example· 49

SNMP operation configuration example· 51

TCP operation configuration example· 53

UDP echo operation configuration example· 54

UDP tracert operation configuration example· 55

Voice operation configuration example· 57

DLSw operation configuration example· 59

Path jitter operation configuration example· 60

NQA collaboration configuration example· 62

ICMP template configuration example· 64

DNS template configuration example· 65

TCP template configuration example· 66

TCP half open template configuration example· 67

UDP template configuration example· 67

HTTP template configuration example· 68

FTP template configuration example· 69

RADIUS template configuration example· 69

Configuring NTP·· 71

Overview·· 71

How NTP works· 71

NTP architecture· 72

Association modes· 73

NTP security· 75

NTP for MPLS L3VPN instances· 76

Protocols and standards· 77

Configuration restrictions and guidelines· 77

Configuration task list 77

Enabling the NTP service· 78

Configuring NTP association mode· 78

Configuring NTP in client/server mode· 78

Configuring NTP in symmetric active/passive mode· 79

Configuring NTP in broadcast mode· 79

Configuring NTP in multicast mode· 80

Configuring access control rights· 81

Configuring NTP authentication·· 81

Configuring NTP authentication in client/server mode· 81

Configuring NTP authentication in symmetric active/passive mode· 83

Configuring NTP authentication in broadcast mode· 85

Configuring NTP authentication in multicast mode· 86

Configuring NTP optional parameters· 88

Specifying the source interface for NTP messages· 88

Disabling an interface from receiving NTP messages· 89

Configuring the maximum number of dynamic associations· 89

Setting a DSCP value for NTP packets· 90

Configuring the local clock as a reference source· 90

Displaying and maintaining NTP·· 90

NTP configuration examples· 91

NTP client/server mode configuration example· 91

IPv6 NTP client/server mode configuration example· 92

NTP symmetric active/passive mode configuration example· 93

IPv6 NTP symmetric active/passive mode configuration example· 94

NTP broadcast mode configuration example· 95

NTP multicast mode configuration example· 97

IPv6 NTP multicast mode configuration example· 100

Configuration example for NTP client/server mode with authentication·· 103

Configuration example for NTP broadcast mode with authentication·· 105

Configuration example for MPLS L3VPN network time synchronization in client/server mode· 107

Configuration example for MPLS L3VPN network time synchronization in symmetric active/passive mode· 109

Configuring SNTP·· 111

Configuration restrictions and guidelines· 111

Configuration task list 111

Enabling the SNTP service· 111

Specifying an NTP server for the device· 111

Configuring SNTP authentication·· 112

Displaying and maintaining SNTP·· 113

SNTP configuration example· 113

Network requirements· 113

Configuration procedure· 113

Configuring SNMP·· 115

Overview·· 115

SNMP framework· 115

MIB and view-based MIB access control 115

SNMP operations· 116

Protocol versions· 116

Access control modes· 116

SNMP silence· 116

FIPS compliance· 117

Configuring SNMP basic parameters· 117

Configuring SNMPv1 or SNMPv2c basic parameters· 117

Configuring SNMPv3 basic parameters· 119

Configuring SNMP logging· 123

Configuring SNMP notifications· 124

Enabling SNMP notifications· 124

Configuring the SNMP agent to send notifications to a host 124

Displaying the SNMP settings· 126

SNMPv1/SNMPv2c configuration example· 126

Network requirements· 126

Configuration procedure· 127

Verifying the configuration·· 127

SNMPv3 configuration example· 128

Network requirements· 128

Configuration procedure· 128

Verifying the configuration·· 130

Configuring RMON·· 131

Overview·· 131

RMON groups· 131

Sample types for the alarm group and the private alarm group· 133

Protocols and standards· 133

Configuring the RMON statistics function·· 133

Creating an RMON Ethernet statistics entry· 133

Creating an RMON history control entry· 133

Configuring the RMON alarm function·· 134

Displaying and maintaining RMON settings· 135

RMON configuration examples· 135

Ethernet statistics group configuration example· 135

History group configuration example· 136

Alarm function configuration example· 137

Configuring the Event MIB·· 139

Overview·· 139

Monitored objects· 139

Object owner 139

Trigger test 139

Event actions· 140

Prerequisites· 141

Event MIB configuration task list 141

Configuring Event MIB sampling· 141

Configuring Event MIB object lists· 141

Configuring an event 142

Creating an event 142

Configuring a set action for an event 142

Configuring a notification action for an event 143

Configuring a trigger 143

Configuring a Boolean trigger test 144

Configuring an existence trigger test 145

Configuring a threshold trigger test 145

Enabling SNMP notifications for Event MIB·· 146

Displaying and maintaining the Event MIB·· 147

Event MIB configuration examples· 147

Existence trigger test configuration example· 147

Boolean trigger test configuration example· 149

Threshold trigger test configuration example· 152

Configuring NETCONF· 155

Overview·· 155

NETCONF structure· 155

NETCONF message format 156

How to use NETCONF·· 157

Protocols and standards· 157

FIPS compliance· 157

NETCONF configuration task list 158

Configuring NETCONF over SOAP·· 158

Enabling NETCONF over SSH·· 159

Enabling NETCONF logging· 159

Establishing a NETCONF session·· 160

Setting the NETCONF session idle timeout time· 160

Entering XML view·· 160

Exchanging capabilities· 160

Subscribing to event notifications· 161

Subscription procedure· 161

Example for subscribing to event notifications· 162

Locking/unlocking the configuration·· 163

Locking the configuration·· 163

Unlocking the configuration·· 164

Example for locking the configuration·· 164

Performing service operations· 165

Performing the <get>/<get-bulk> operation·· 165

Performing the <get-config>/<get-bulk-config> operation·· 167

Performing the <edit-config> operation·· 167

All-module configuration data retrieval example· 168

Syslog configuration data retrieval example· 170

Example for retrieving a data entry for the interface table· 171

Example for changing the value of a parameter 172

Saving, rolling back, and loading the configuration·· 173

Saving the configuration·· 173

Rolling back the configuration based on a configuration file· 173

Rolling back the configuration based on a rollback point 174

Loading the configuration·· 178

Example for saving the configuration·· 178

Enabling preprovisioning· 179

Filtering data· 179

Table-based filtering· 180

Column-based filtering· 180

Example for filtering data with regular expression match·· 183

Example for filtering data by conditional match·· 184

Performing CLI operations through NETCONF·· 185

Configuration procedure· 185

CLI operation example· 186

Retrieving NETCONF information·· 187

Retrieving YANG file content 188

Retrieving NETCONF session information·· 188

Terminating another NETCONF session·· 190

Configuration procedure· 190

Configuration example· 190

Returning to the CLI 191

Appendix· 192

Appendix A Supported NETCONF operations· 192

Configuring EAA·· 202

Overview·· 202

EAA framework· 202

Elements in a monitor policy· 203

EAA environment variables· 204

Configuring a user-defined EAA environment variable· 205

Configuring a monitor policy· 206

Configuration restrictions and guidelines· 206

Configuring a monitor policy from the CLI 206

Configuring a monitor policy by using Tcl 208

Suspending monitor policies· 209

Displaying and maintaining EAA settings· 210

EAA configuration examples· 210

CLI event monitor policy configuration example· 210

Track event monitor policy configuration example· 211

CLI-defined policy with EAA environment variables configuration example· 213

Tcl-defined policy configuration example· 214

Configuring samplers· 216

Creating a sampler 216

Displaying and maintaining a sampler 216

Sampler configuration example for IPv4 NetStream·· 216

Network requirements· 216

Configuration procedure· 217

Verifying the configuration·· 217

Configuring port mirroring· 218

Overview·· 218

Terminology· 218

Port mirroring classification and implementation·· 219

Configuring local port mirroring· 222

Local port mirroring configuration task list 223

Creating a local mirroring group· 223

Configuring source ports for the local mirroring group· 223

Configuring source CPUs for the local mirroring group· 224

Configuring the monitor port for the local mirroring group· 224

Configuring Layer 2 remote port mirroring· 225

Layer 2 remote port mirroring with reflector port configuration task list 226

Layer 2 remote port mirroring with egress port configuration task list 226

Configuring a remote destination group on the destination device· 226

Configuring a remote source group on the source device· 228

Configuring Layer 3 remote port mirroring· 231

Layer 3 remote port mirroring configuration task list 231

Configuration prerequisites· 232

Configuring local mirroring groups· 232

Configuring source ports for a local mirroring group· 232

Configuring source CPUs for a local mirroring group· 233

Configuring the monitor port for a local mirroring group· 233

Displaying and maintaining port mirroring· 234

Port mirroring configuration examples· 234

Local port mirroring configuration example (in source port mode) 234

Local port mirroring configuration example (in source CPU mode) 235

Layer 2 remote port mirroring configuration example (reflector port) 236

Layer 2 remote port mirroring configuration example (egress port) 239

Layer 3 remote port mirroring configuration example· 241

Configuring flow mirroring· 244

Flow mirroring configuration task list 244

Configuring match criteria· 244

Configuring a traffic behavior 245

Configuring a QoS policy· 245

Applying a QoS policy· 245

Applying a QoS policy to an interface· 245

Applying a QoS policy to a VLAN·· 246

Applying a QoS policy globally· 246

Applying a QoS policy to the control plane· 246

Flow mirroring configuration example· 246

Network requirements· 246

Configuration procedure· 247

Verifying the configuration·· 248

Configuring NetStream·· 249

Overview·· 249

NetStream architecture· 249

Flow aging· 250

NetStream data export 250

NetStream filtering· 252

NetStream sampling· 252

Protocols and standards· 252

Feature and hardware compatibility· 253

NetStream configuration task list 253

Enabling NetStream·· 253

Configuring NetStream filtering· 253

Configuring NetStream sampling· 254

Configuring attributes of the NetStream data export 254

Configuring the NetStream data export format 254

Configuring the refresh rate for NetStream version 9 or version 10 template· 255

Configuring MPLS-aware NetStream·· 256

Configuring VXLAN-aware NetStream·· 256

Configuring NetStream flow aging· 256

Flow aging methods· 256

Configuration procedure· 257

Configuring the NetStream data export 257

Configuring the NetStream traditional data export 257

Configuring the NetStream aggregation data export 258

Displaying and maintaining NetStream·· 259

NetStream configuration examples· 259

NetStream traditional data export configuration example· 259

NetStream aggregation data export configuration example· 261

Configuring IPv6 NetStream·· 264

Overview·· 264

IPv6 NetStream architecture· 264

Flow aging· 265

IPv6 NetStream data export 265

IPv6 NetStream filtering· 266

IPv6 NetStream sampling· 266

Protocols and standards· 266

Feature and hardware compatibility· 267

IPv6 NetStream configuration task list 267

Enabling IPv6 NetStream·· 267

Configuring IPv6 NetStream filtering· 267

Configuring IPv6 NetStream sampling· 268

Configuring attributes of the IPv6 NetStream data export 268

Configuring the IPv6 NetStream data export format 268

Configuring the refresh rate for IPv6 NetStream version 9 or version 10 template· 269

Configuring MPLS-aware IPv6 NetStream·· 270

Configuring IPv6 NetStream flow aging· 270

Flow aging methods· 270

Configuration procedure· 271

Configuring the IPv6 NetStream data export 271

Configuring the IPv6 NetStream traditional data export 271

Configuring the IPv6 NetStream aggregation data export 272

Displaying and maintaining IPv6 NetStream·· 272

IPv6 NetStream configuration examples· 273

IPv6 NetStream traditional data export configuration example· 273

IPv6 NetStream aggregation data export configuration example· 275

Configuring sFlow·· 278

Protocols and standards· 278

sFlow configuration task list 278

Configuring the sFlow agent and sFlow collector information·· 279

Configuring flow sampling· 279

Configuring counter sampling· 280

Displaying and maintaining sFlow·· 280

sFlow configuration example· 281

Network requirements· 281

Configuration procedure· 281

Verifying the configurations· 282

Troubleshooting sFlow configuration·· 282

The remote sFlow collector cannot receive sFlow packets· 282

Configuring the information center 284

Overview·· 284

Log types· 284

Log levels· 284

Log destinations· 285

Default output rules for logs· 285

Default output rules for diagnostic logs· 285

Default output rules for security logs· 285

Default output rules for hidden logs· 286

Default output rules for trace logs· 286

Log formats· 286

FIPS compliance· 289

Information center configuration task list 289

Outputting logs to the console· 289

Outputting logs to the monitor terminal 290

Outputting logs to log hosts· 291

Outputting logs to the log buffer 291

Saving logs to the log file· 292

Managing security logs· 293

Saving security logs to the security log file· 293

Managing the security log file· 293

Saving diagnostic logs to the diagnostic log file· 294

Configuring the maximum size of the trace log file· 295

Setting the minimum storage period for log files and logs in the log buffer 295

Logs in the log buffer 295

Log files· 295

Configuration procedure· 296

Enabling synchronous information output 296

Enabling duplicate log suppression·· 296

Configuring log suppression for a module· 297

Disabling an interface from generating link up or link down logs· 297

Enabling SNMP notifications for system logs· 297

Displaying and maintaining information center 298

Information center configuration examples· 298

Configuration example for outputting logs to the console· 298

Configuration example for outputting logs to a UNIX log host 299

Configuration example for outputting logs to a Linux log host 300

Configuring GOLD·· 302

Configuring monitoring diagnostics· 302

Configuring on-demand diagnostics· 303

Starting a device startup check by using on-demand diagnostics· 303

Starting on-demand diagnostics during device operation·· 303

Simulating test results· 304

Configuring the log buffer size· 305

Displaying and maintaining GOLD·· 305

GOLD configuration example (in standalone mode) 306

Network requirements· 306

Configuration procedure· 306

Verifying the configuration·· 307

Configuring the packet capture· 308

Overview·· 308

Packet capture modes· 308

Filter elements· 308

Building a capture filter 314

Building a display filter 315

Packet capture configuration task list 315

Configuring local packet capture· 316

Configuring remote packet capture· 316

Configuring feature image-based packet capture· 317

Saving captured packets to a file· 317

Filtering packet data to display· 318

Displaying the contents in a packet file· 318

Displaying and maintaining packet capture· 318

Packet capture configuration examples· 318

Remote packet capture configuration example· 318

Filtering packet data to display configuration example· 319

Saving captured packets to a file configuration example· 321

Configuring VCF fabric· 322

Overview·· 322

VCF fabric topology· 322

Neutron concepts and components· 323

Neutron deployment 324

Automated VCF fabric provisioning and deployment 325

Topology discovery· 325

Automated underlay network provisioning· 325

Automated overlay network deployment 327

Configuration restrictions and guidelines· 327

VCF fabric configuration task list 328

Enabling VCF fabric topology discovery· 328

Configuration restrictions and guidelines· 328

Configuration procedure· 328

Configuring automated underlay network provisioning· 328

Configuration restrictions and guidelines· 328

Configuration procedure· 329

Configuring automated overlay network deployment 329

Configuration restrictions and guidelines· 329

Configuration procedure· 329

Displaying and maintaining VCF fabric· 330

Automated VCF fabric configuration example· 331

Network requirements· 331

Configuration procedure· 331

Verifying the configuration·· 333

Index· 337

 


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.

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:
ping [ ip ] [ -a source-ip | -c count | -f | -h ttl | -i interface-type interface-number | -m interval | -n | -p pad | -q | -r | -s packet-size | -t timeout | -tos tos | -v | -vpn-instance vpn-instance-name ] * host

·         For IPv6 networks:
ping ipv6 [ -a source-ipv6 | -c count | -i interface-type interface-number | -m interval | -q | -s packet-size | -t timeout | -tc traffic-class | -v | -vpn-instance vpn-instance-name ] * host

 

Ping example

Network requirements

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 the following information:

·          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 the RR option blank.

2.        The intermediate device (Device B) adds the IP address of its outbound interface (1.1.2.1) to the RR option of the ICMP echo request, and forwards the packet.

3.        Upon receiving the request, the destination device copies the RR option in the request and adds the IP address of its outbound interface (1.1.2.2) to the RR option. Then the destination device sends an ICMP echo reply.

4.        The intermediate device adds the IP address of its outbound interface (1.1.1.2) to the RR option in the ICMP echo reply, and then forwards the reply.

5.        Upon receiving the reply, the source device adds the IP address of its inbound interface (1.1.1.1) 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.

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.

Figure 2 Tracert operation

 

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

1.        The 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 determines that:

?  The packet has reached the destination device after receiving the port-unreachable ICMP message.

?  The path to the destination device is 1.1.1.2 to 1.1.2.2 to 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

 

Display the routes from source to destination.

·         For IPv4 networks:
tracert [ -a source-ip | -f first-ttl | -m max-ttl | -p port | -q packet-number | -t tos | -vpn-instance vpn-instance-name [ -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 other, locate the failed nodes in the network.

Figure 3 Network diagram

 

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.

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.        To identify the cause of the problem, execute the following commands on Device A and Device C:

?  Execute the debugging ip icmp command and verify that Device A and Device C can send and receive the correct ICMP packets.

?  Execute the display ip routing-table command to verify that Device A and Device C have a route to each other.

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, the device can provide debugging for the three modules 1, 2, and 3. 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

 

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

Remarks

1.       Enable debugging for a module in user view.

debugging module-name [ option ]

By default, all debugging functions are disabled.

2.       (Optional.) Display the enabled debugging in any view.

display debugging [ module-name ]

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.

·          ICMP jitter.

·          DHCP.

·          DLSw.

·          DNS.

·          FTP.

·          HTTP.

·          Path jitter.

·          SNMP.

·          TCP.

·          UDP echo.

·          UDP jitter.

·          UDP tracert.

·          Voice.

As shown in Figure 5, the NQA source device (NQA client) sends data to the NQA destination device 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

 

NQA operation

The following describes how NQA performs different types of operations:

·          A TCP or DLSw operation sets up a connection.

·          An ICMP jitter, UDP jitter, or 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 probe packets sent 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

 

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 to 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 describes the relationships between performance metrics and NQA operation types.

Table 1 Performance metrics and NQA operation types

Performance metric

NQA operation types that can gather the metric

Probe duration

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

Number of probe failures

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

Round-trip time

ICMP jitter, UDP jitter, and voice

Number of discarded packets

ICMP jitter, UDP jitter, and voice

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

ICMP jitter, UDP jitter, and voice

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

ICMP jitter, UDP jitter, and voice

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

Voice

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

Voice

 

NQA configuration task list

Tasks at a glance

Remarks

Configuring the NQA server

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

(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

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

 

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.

To configure the NQA server:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable the NQA server.

nqa server enable

By default, the NQA server is disabled.

3.       Configure a TCP or UDP listening service.

·         TCP listening service:
nqa server tcp-connect
ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ]

·         UDP listening service:
nqa server udp-echo
ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ]

The default ToS value is 0.

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

 

Enabling the NQA client

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable the NQA client.

nqa agent enable

By default, the NQA client is enabled.

The NQA client configuration takes effect after you enable the NQA client.

 

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 ICMP jitter 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

(Optional.) Configuring optional parameters for the NQA operation

(Optional.) Configuring the collaboration feature

(Optional.) Configuring threshold monitoring

(Optional.) Configuring the NQA statistics collection feature

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

To configure the ICMP echo operation:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the ICMP echo type and enter its view.

type icmp-echo

N/A

4.       Specify the destination IP address for ICMP echo requests.

·         IPv4 address:
destination ip ip-address

·         IPv6 address:
destination ipv6 ipv6-address

By default, no destination IP address is specified.

5.       (Optional.) Set the payload size for each ICMP echo request.

data-size size

The default setting is 100 bytes.

6.       (Optional.) Specify the payload fill string for ICMP echo requests.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

7.       (Optional.) Specify the output interface for ICMP echo requests.

out interface interface-type interface-number

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.

8.       (Optional.) Specify the source IP address for ICMP echo requests.

·         Use the IP address of the specified interface as the source IP address:
source interface interface-type interface-number

·         Specify the source IPv4 address:
source ip ip-address

·         Specify the source IPv6 address:
source ipv6 ipv6-address

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

If you execute the source interface, source ip, and source ipv6 commands multiple times, the most recent configuration takes effect.

The specified source interface must be up.

The specified 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.

9.       (Optional.) Specify the next hop IP address for ICMP echo requests.

·         IPv4 address:
next-hop ip ip-address

·         IPv6 address:
next-hop ipv6 ipv6-address

By default, no next hop IP address is configured.

 

Configuring the ICMP jitter operation

The ICMP jitter operation measures unidirectional and bidirectional jitters. The operation result helps you to determine whether the network can carry jitter-sensitive services such as real-time voice and video services.

The ICMP jitter operation works as follows:

1.        The NQA client sends ICMP packets to the destination device.

2.        The destination device time stamps each packet 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 timestamps.

Before starting the operation, make sure the network devices are time synchronized by using NTP. For more information about NTP, see "Configuring NTP."

To configure the ICMP jitter operation:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the ICMP jitter type and enter its view.

type icmp-jitter

N/A

4.       Specify the destination address of ICMP packets.

destination ip ip-address

By default, no destination IP address is specified.

5.       (Optional.) Set the number of ICMP packets sent in one ICMP jitter operation.

probe packet-number

packet-number

The default setting is 10.

6.       (Optional.) Set the interval for sending ICMP packets.

probe packet-interval interval

The default setting is 20 milliseconds.

7.       (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out.

probe packet-timeout timeout

The default setting is 3000 milliseconds.

8.       (Optional.) Specify the source IP address for ICMP packets.

source ip ip-address

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

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

 

 

NOTE:

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

 

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.

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the DHCP type and enter its view.

type dhcp

N/A

4.       Specify the IP address of the DHCP server as the destination IP address of DHCP packets.

destination ip ip-address

By default, no destination IP address is specified.

5.       (Optional.) Specify an output interface for DHCP request packets.

out interface interface-type interface-number

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.

6.       (Optional.) Specify the source IP address of DHCP request packets.

source ip ip-address

By default, the packets take the primary 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.

 

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:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the DNS type and enter its view.

type dns

N/A

4.       Specify the IP address of the DNS server as the destination address of DNS packets.

destination ip ip-address

By default, no destination IP address is specified.

5.       Specify the domain name to be translated.

resolve-target domain-name

By default, no domain name is specified.

 

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.

·          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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the FTP type and enter its view.

type ftp

N/A

4.       Specify the URL of the destination FTP server.

url url

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.

5.       (Optional.) Specify the source IP address of FTP request packets.

source ip ip-address

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

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.       (Optional.) Specify the FTP operation type.

operation { get | put }

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

7.       Specify an FTP login username.

username username

By default, no FTP login username is configured.

8.       Specify an FTP login password.

password { cipher | simple } string

By default, no FTP login password is configured.

9.       (Optional.) Specify the name of a file to be transferred.

filename file-name

By default, no file is specified.

This step is required if you perform the put operation.

10.     Set the data transmission mode.

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the HTTP type and enter its view.

type http

N/A

4.       Specify the URL of the destination HTTP server.

url url

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.

5.       Specify an HTTP login username.

username username

By default, no HTTP login username is specified.

6.       Specify an HTTP login password.

password { cipher | simple } string

By default, no HTTP login password is specified.

7.       (Optional.) Specify the source IP address of request packets.

source ip ip-address

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

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.       (Optional.) Specify the HTTP version.

version { v1.0 | v1.1 }

By default, HTTP 1.0 is used.

9.       (Optional.) Specify the HTTP operation type.

operation { get | post | raw }

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

If you set the HTTP operation type to raw, configure the content of the HTTP request to be sent to the HTTP server in raw request view.

10.     (Optional.) Enter raw request view.

raw-request

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

11.     (Optional.) Specify the HTTP request content.

Enter or paste the content.

By default, no contents are specified.

This step is required for the raw operation.

12.     Save the input and return to HTTP operation view.

quit

N/A

 

Configuring the UDP jitter operation

CAUTION

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. The operation result helps you to determine whether the network can carry jitter-sensitive services such as real-time voice and video services through the UDP jitter operation.

The UDP jitter operation works as follows:

1.        The NQA client sends UDP packets to the destination port.

2.        The destination device time stamps each packet 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 timestamps.

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

Before starting the operation, make sure the network devices are time synchronized by using NTP. For more information about NTP, see "Configuring NTP."

To configure a UDP jitter operation:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the UDP jitter type and enter its view.

type udp-jitter

N/A

4.       Specify the destination address of UDP packets.

destination ip ip-address

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.

5.       Specify the destination port of UDP packets.

destination port port-number

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.

6.       (Optional.) Specify the source IP address for UDP packets.

source ip ip-address

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

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.

7.       (Optional.) Specify the source port number of UDP packets.

source port port-number

By default, no source port number is specified.

8.       (Optional.) Set the payload size for each UDP packet.

data-size size

The default setting is 100 bytes.

9.       (Optional.) Specify the payload fill string for UDP packets.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

10.     (Optional.) Set the number of UDP packets sent in one UDP jitter operation.

probe packet-number

packet-number

The default setting is 10.

11.     (Optional.) Set the interval for sending UDP packets.

probe packet-interval interval

The default setting is 20 milliseconds.

12.     (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out.

probe packet-timeout timeout

The default setting is 3000 milliseconds.

 

 

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the SNMP type and enter its view.

type snmp

N/A

4.       Specify the destination address of SNMP packets.

destination ip ip-address

By default, no destination IP address is specified.

5.       (Optional.) Specify the source port of SNMP packets.

source port port-number

By default, no source port number is specified.

6.       (Optional.) Specify the source IP address of SNMP packets.

source ip ip-address

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

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.

7.       (Optional.) Specify the community name for the SNMP operation if the operation uses the SNMPv1 or SNMPv2c agent.

community read { cipher | simple } community-name

By default, the SNMP operation uses community name public.

Make sure the specified community name is the same as the community name configured on the SNMP agent.

 

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

To configure the TCP operation:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the TCP type and enter its view.

type tcp

N/A

4.       Specify the destination address of TCP packets.

destination ip ip-address

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.

5.       Specify the destination port of TCP packets.

destination port port-number

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.

6.       (Optional.) Specify the source IP address of TCP packets.

source ip ip-address

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

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the UDP echo type and enter its view.

type udp-echo

N/A

4.       Specify the destination address of UDP packets.

destination ip ip-address

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.

5.       Specify the destination port of UDP packets.

destination port port-number

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.

6.       (Optional.) Set the payload size for each UDP packet.

data-size size

The default setting is 100 bytes.

7.       (Optional.) Specify the payload fill string for UDP packets.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

8.       (Optional.) Specify the source port of UDP packets.

source port port-number

By default, no source port number is specified.

9.       (Optional.) Specify the source IP address of UDP packets.

source ip ip-address

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

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the UDP tracert operation type and enter its view.

type udp-tracert

N/A

4.       Specify the destination device for the operation.

·         Specify the destination device by its host name:
destination host
host-name

·         Specify the destination device by its IP address:
destination ip ip-address

By default, no destination IP address or host name is specified.

5.       (Optional.) Specify the destination port of UDP packets.

destination port port-number

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.

6.       (Optional.) Set the payload size for each UDP packet.

data-size size

The default setting is 100 bytes.

7.       (Optional.) Enable the no-fragmentation feature.

no-fragment enable

By default, the no-fragmentation feature is disabled.

8.       (Optional.) Set the maximum number of consecutive probe failures.

max-failure times

The default setting is 5.

9.       (Optional.) Set the TTL value for UDP packets in the start round of the UDP tracert operation.

init-ttl value

The default setting is 1.

10.     (Optional.) Specify an output interface for UDP packets.

out interface interface-type interface-number

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

11.     (Optional.) Specify the source port of UDP packets.

source port port-number

By default, no source port number is specified.

12.     (Optional.) Specify the source IP address of UDP packets.

·         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 packets take the primary IP address of the output interface as their source IP address.

If you execute the source ip and source interface commands multiple times, 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

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 time stamps 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 timestamp.

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 set an 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."

The voice operation cannot repeat.

Before starting the operation, make sure the network devices are time synchronized by using NTP. For more information about NTP, see "Configuring NTP."

To configure the voice operation:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the voice type and enter its view.

type voice

N/A

4.       Specify the destination address of voice packets.

destination ip ip-address

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.

5.       Specify the destination port of voice packets.

destination port port-number

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.

6.       (Optional.) Specify the codec type.

codec-type { g711a | g711u | g729a }

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

7.       (Optional.) Set the advantage factor for calculating MOS and ICPIF values.

advantage-factor factor

By default, the advantage factor is 0.

8.       (Optional.) Specify the source IP address of voice packets.

source ip ip-address

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

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.

source port port-number

By default, no source port number is specified.

10.     (Optional.) Set the payload size for each voice packet.

data-size size

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.

11.     (Optional.) Specify the payload fill string for voice packets.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

12.     (Optional.) Set the number of voice packets to be sent in a voice probe.

probe packet-number packet-number

The default setting is 1000.

13.     (Optional.) Set the interval for sending voice packets.

probe packet-interval interval

The default setting is 20 milliseconds.

14.     (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out.

probe packet-timeout timeout

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the DLSw type and enter its view.

type dlsw

N/A

4.       Specify the destination IP address of probe packets.

destination ip ip-address

By default, no destination IP address is specified.

5.       (Optional.) Specify the source IP address of probe packets.

source ip ip-address

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

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

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 ip unreachables enable commands, see Layer 3—IP Services Command Reference.

To configure the path jitter operation:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify the path jitter type and enter its view.

type path-jitter

N/A

4.       Specify the destination address of ICMP echo requests.

destination ip ip-address

By default, no destination IP address is specified.

5.       (Optional.) Set the payload size for each ICMP echo request.

data-size size

The default setting is 100 bytes.

6.       (Optional.) Specify the payload fill string for ICMP echo requests.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

7.       Specify the source IP address of ICMP echo requests.

source ip ip-address

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

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.

8.       (Optional.) Set the number of ICMP echo requests to be sent in a path jitter operation.

probe packet-number packet-number

The default setting is 10.

9.       (Optional.) Set the interval for sending ICMP echo requests.

probe packet-interval interval

The default setting is 20 milliseconds.

10.     (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out.

probe packet-timeout timeout

The default setting is 3000 milliseconds.

11.     (Optional.) Specify an LSR path.

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

By default, no LSR path is specified.

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.

12.     (Optional.) Perform the path jitter operation only on the destination address.

target-only

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.

The parameter settings take effect only on the current operation.

To configure optional parameters for an NQA operation:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify an NQA operation type and enter its view.

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

N/A

4.       Configure a description.

description text

By default, no description is configured.

5.       Set the interval at which the NQA operation repeats.

frequency interval

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

For other types of operations, the default setting is 0 milliseconds, and only one operation is performed.

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

6.       Specify the probe times.

probe count times

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.

7.       Set the probe timeout time.

probe timeout timeout

The default setting is 3000 milliseconds.

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

8.       Set the maximum number of hops that the probe packets can traverse.

ttl value

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 or path jitter operation.

9.       Set the ToS value in the IP header of probe packets.

tos value

The default setting is 0.

10.     Enable the routing table bypass feature.

route-option bypass-route

By default, the routing table bypass feature is disabled.

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

This command does not take effect if the destination address of the NQA operation is an IPv6 address.

11.     Specify the VPN instance where the operation is performed.

vpn-instance vpn-instance-name

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

 

Configuring the collaboration feature

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.

To configure the collaboration feature:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify an NQA operation type and enter its view.

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

The collaboration feature is not available for the ICMP jitter, path jitter, UDP tracert, UDP jitter, or voice operations.

4.       Configure a reaction entry.

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

By default, no reaction entry is configured.

You cannot modify the content of an existing reaction entry.

5.       Return to system view.

quit

N/A

6.       Associate Track with NQA.

See High Availability Configuration Guide.

N/A

7.       Associate Track with an application module.

See High Availability Configuration Guide.

N/A

 

Configuring threshold monitoring

This feature 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 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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Enter NQA operation view.

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

The threshold monitoring feature is not available for path jitter operations.

4.       Enable sending traps to the NMS when specific conditions are met.

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

By default, no traps are sent to the NMS.

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

The following parameters are not available for the UDP tracert operation:

·         The probe-failure consecutive-probe-failures option.

·         The accumulate-probe-failures argument.

5.       Configure threshold monitoring.

·         Monitor the operation duration (not supported in the ICMP jitter, UDP jitter, UDP tracert, or 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 ICMP jitter, UDP jitter, UDP tracert, or 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 ICMP jitter, 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 ICMP jitter, UDP jitter, 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 ICMP jitter, 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 ICMP jitter, 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 } ]

N/A

 

Configuring the NQA statistics collection feature

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.

If you use the frequency command to set the interval to 0 milliseconds for an NQA operation, NQA does not generate any statistics group for the operation.

To configure the NQA statistics collection feature:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Specify an NQA operation type and enter its view.

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

The NQA statistics collection feature is not available for UDP tracert operations.

4.       (Optional.) Set the interval for collecting the statistics.

statistics interval interval

The default setting is 60 minutes.

5.       (Optional.) Set the maximum number of statistics groups that can be saved.

statistics max-group number

The default setting is two groups.

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

When the maximum number of statistics groups is reached, to save a new statistics group, the oldest statistics group is deleted.

6.       (Optional.) Set the hold time of statistics groups.

statistics hold-time hold-time

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA operation and enter NQA operation view.

nqa entry admin-name operation-tag

By default, no NQA operations exist.

3.       Enter NQA operation type view.

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

The history record saving feature is not available for the ICMP jitter, UDP jitter, path jitter, or voice operations.

4.       Enable the saving of history records for the NQA operation.

history-record enable

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

5.       (Optional.) Set the lifetime of history records.

history-record keep-time keep-time

The default setting is 120 minutes.

A record is deleted when its lifetime is reached.

6.       (Optional.) Set the maximum number of history records that can be saved.

history-record number number

The default setting is 50.

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

7.       (Optional.) Display NQA history records.

display nqa history

N/A

 

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.

system-view

2.       Specify the scheduling parameters for an NQA operation.

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 load balancing, health monitoring, and other feature modules to provide statistics. You can create multiple templates on a device, and each template must be uniquely named.

NQA template supports the ICMP, DNS, TCP, TCP half open, UDP, HTTP, FTP, and RADIUS 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. For example, the server load balancing uses the NQA ICMP template for health monitoring. If the destination IP address in the template is different from the real server address, the destination IP address in the template takes effect.

NQA template configuration task list

Tasks at a glance

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

·         Configuring the ICMP template

·         Configuring the DNS template

·         Configuring the TCP template

·         Configuring the TCP half open template

·         Configuring the UDP template

·         Configuring the HTTP template

·         Configuring the FTP template

·         Configuring the RADIUS template

(Optional.) Configuring optional parameters for the NQA template

 

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an ICMP template and enter its view.

nqa template icmp name

By default, no ICMP templates exist.

3.       (Optional.) Specify the destination IP address of the operation.

·         IPv4 address:
destination ip ip-address

·         IPv6 address:
destination ipv6 ipv6-address

By default, no destination IP address is configured.

4.       (Optional.) Set the payload size for each ICMP request.

data-size size

The default setting is 100 bytes.

5.       (Optional.) Specify the payload fill string for requests.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

6.       (Optional.) Specify the source IP address for ICMP echo requests.

·         Use the IPv4 address of the specified interface as the source IP address:
source interface interface-type interface-number

·         Specify the source IPv4 address:
source ip ip-address

·         Specify the source IPv6 address:
source ipv6 ipv6-address

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

If you execute the source interface, source ip, and source ipv6 commands multiple times, the most recent configuration takes effect.

The specified source interface must be up.

The specified 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.) Specify the next hop IP address for ICMP echo requests.

·         IPv4 address:
next-hop ip ip-address

·         IPv6 address:
next-hop ipv6 ipv6-address

By default, no IP address of the next hop is configured.

8.       (Optional.) Configure the probe result sending on a per-probe basis.

reaction trigger per-probe

By default, the probe result is sent to the feature that uses the template after three consecutive failed or successful probes.

If you execute the reaction trigger per-probe and reaction trigger probe-pass commands multiple times, the most recent configuration takes effect.

If you execute the reaction trigger per-probe and reaction trigger probe-fail commands multiple times, the most recent configuration takes effect.

 

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.

To configure the DNS template:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create a DNS template and enter DNS template view.

nqa template dns name

By default, no DNS templates exist.

3.       (Optional.) Specify the destination IP address of DNS packets.

·         IPv4 address:
destination ip ip-address

·         IPv6 address:
destination ipv6 ipv6-address

By default, no destination address is specified.

4.       (Optional.) Specify the destination port number for the operation.

destination port port-number

By default, the destination port number is 53.

5.       Specify the domain name to be translated.

resolve-target domain-name

By default, no domain name is specified.

6.       Specify the domain name resolution type.

resolve-type { A | AAAA }

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.

7.       (Optional.) Specify the source IP address for the probe packets.

·         IPv4 address:
source ip
ip-address

·         IPv6 address:
source ipv6
ipv6-address

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

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.) Specify the source port for probe packets.

source port port-number

By default, no source port number is specified.

9.       (Optional.) Specify the IP address that is expected to be returned.

·         IPv4 address:
expect ip ip-address

·         IPv6 address:
expect ipv6 ipv6-address

By default, no expected IP address is specified.

 

Configuring the TCP template

A feature that uses the TCP template performs the TCP operation to test whether the NQA client can establish a TCP connection to a specific port 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.

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

To configure the TCP template:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create a TCP template and enter its view.

nqa template tcp name

By default, no TCP templates exist.

3.       (Optional.) Specify the destination IP address of the operation.

·         IPv4 address:
destination ip ip-address

·         IPv6 address:
destination ipv6 ipv6-address

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.

4.       (Optional.) Specify the destination port number for the operation.

destination port port-number

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.

5.       (Optional.) Specify the payload fill string for requests.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

6.       (Optional.) Specify the source IP address for the probe packets.

·         IPv4 address:
source ip
ip-address

·         IPv6 address:
source ipv6
ipv6-address

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

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 ]

By default, no expected data is configured.

The NQA client performs expect data check only when you configure both the data-fill and expect-data commands.

 

Configuring the TCP half open template

A feature that uses the TCP half open template performs the TCP half open operation to test whether the TCP service is available on the server. The TCP half open operation is used when the feature cannot get a response from the TCP server through an existing TCP connection.

In the TCP half open operation, the NQA client sends a TCP ACK packet to the server. If the client receives an RST packet, it considers that the TCP service is available on the server.

To configure the TCP half open template:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create a TCP half open template and enter its view.

nqa template tcphalfopen name

By default, no TCP half open templates exist.

3.       (Optional.) Specify the destination IP address of the operation.

·         IPv4 address:
destination ip ip-address

·         IPv6 address:
destination ipv6 ipv6-address

By default, no destination address is specified.

4.       (Optional.) Specify the source IP address for the probe packets.

·         IPv4 address:
source ip
ip-address

·         IPv6 address:
source ipv6
ipv6-address

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

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.

5.       (Optional.) Specify the next hop IP address for the probe packets.

·         IPv4 address:
next-hop ip ip-address

·         IPv6 address:
next-hop ipv6 ipv6-address

By default, the IP address of the next hop is configured.

6.       (Optional.) Configure the probe result sending on a per-probe basis.

reaction trigger per-probe

By default, the probe result is sent to the feature that uses the template after three consecutive failed or successful probes.

If you execute the reaction trigger per-probe and reaction trigger probe-pass commands multiple times, the most recent configuration takes effect.

If you execute the reaction trigger per-probe and reaction trigger probe-fail commands multiple times, the most recent configuration takes effect.

 

Configuring the UDP template

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

·          Reachability of a specific port on the NQA server.

·          Availability of the requested service on the NQA server.

In UDP template view, you can specify the expected data to be returned. If you do not specify the expected data, the UDP operation tests only whether the client can receive the response packet from the server.

The UDP operation requires both the NQA server and the NQA client. Before you perform a UDP 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 template:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create a UDP template and enter its view.

nqa template udp name

By default, no UDP templates exist.

3.       (Optional.) Specify the destination IP address of the operation.

·         IPv4 address:
destination ip ip-address

·         IPv6 address:
destination ipv6 ipv6-address

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.

4.       (Optional.) Specify the destination port number for the operation.

destination port port-number

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.

5.       (Optional.) Specify the payload fill string for the probe packets.

data-fill string

The default payload fill string is hexadecimal string 00010203040506070809.

6.       (Optional.) Set the payload size for the probe packets.

data-size size

The default setting is 100 bytes.

7.       (Optional.) Specify the source IP address for the probe packets.

·         IPv4 address:
source ip
ip-address

·         IPv6 address:
source ipv6
ipv6-address

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

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 expected data.

expect data expression [ offset number ]

By default, no expected data is configured.

If you want to configure this command, make sure the data-fill command is already executed.

 

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 data is configured and the HTTP response contains the Content-Length field in the HTTP header.

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.

Configure the HTTP server before you perform the HTTP operation.

To configure the HTTP template:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an HTTP template and enter its view.

nqa template http name

By default, no HTTP templates exist.

3.       Specify the URL of the destination HTTP server.

url url

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.

4.       Specify an HTTP login username.

username username

By default, no HTTP login username is specified.

5.       Specify an HTTP login password.

password { cipher | simple } string

By default, no HTTP login password is specified.

6.       (Optional.) Specify the HTTP version.

version { v1.0 | v1.1 }

By default, HTTP 1.0 is used.

7.       (Optional.) Specify the HTTP operation type.

operation { get | post | raw }

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

If you set the HTTP operation type to raw, use the raw-request command to specify the content of the HTTP request to be sent to the HTTP server.

8.       (Optional.) Enter raw request view.

raw-request

This step is required for the raw operation.

Every time you enter the raw request view, the existing request content configuration is removed.

9.       (Optional.) Enter or paste the content of the HTTP request for the HTTP operation.

N/A

This step is required for the raw operation.

By default, the HTTP request content is not specified.

10.     (Optional.) Return to HTTP template view.

quit

The system automatically saves the configuration in raw request view before it returns to HTTP template view.

11.     (Optional.) Specify the source IP address for the probe packets.

·         IPv4 address:
source ip
ip-address

·         IPv6 address:
source ipv6
ipv6-address

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

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.

12.     (Optional.) Configure the expected status codes.

expect status status-list

By default, no expected status code is configured.

13.     (Optional.) Configure the expected data.

expect data expression [ offset number ]

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

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an FTP template and enter its view.

nqa template ftp name

By default, no FTP templates exist.

3.       Specify the URL of the destination FTP server.

url url

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.

4.       (Optional.) Specify the FTP operation type.

operation { get | put }

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

5.       Specify an FTP login username.

username username

By default, no FTP login username is specified.

6.       Specify an FTP login password.

password { cipher | simple } sting

By default, no FTP login password is specified.

7.       (Optional.) Specify the name of a file to be transferred.

filename filename

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.

8.       Set the data transmission mode.

mode { active | passive }

The default mode is active.

9.       (Optional.) Specify the source IP address for the probe packets.

·         IPv4 address:
source ip
ip-address

·         IPv6 address:
source ipv6
ipv6-address

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

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 the RADIUS template

A feature that uses the RADIUS template performs the RADIUS operation to check the availability of the authentication service on the RADIUS server.

The RADIUS operation authentication workflow is as follows:

1.        The NQA client sends an authentication request (Access-Request) to the RADIUS server. The request includes the username and the user's password. The password has been encrypted by the MD5 algorithm and the shared key.

2.        The RADIUS server authenticates the username and password.

?  If the authentication succeeds, the server sends an Access-Accept packet to the NQA client.

?  If the authentication fails, the server sends an Access-Reject packet to the NQA client.

If the NQA client can receive the Access-Accept packet from the RADIUS server, the authentication service is available on the RADIUS server. Otherwise, the authentication service is not available on the RADIUS server.

Before you configure the RADIUS template, specify a username, password, and shared key on the RADIUS server. For more information about configuring the RADIUS server, see Security Configuration Guide.

To configure the RADIUS template:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create a RADIUS template and enter its view.

nqa template radius name

By default, no RADIUS templates exist.

3.       (Optional.) Specify the destination IP address of the operation.

·         IPv4 address:
destination ip ip-address

·         IPv6 address:
destination ipv6 ipv6-address

By default, no destination IP address is configured.

4.       (Optional.) Specify the destination port number for the operation.

destination port port-number

By default, the destination port number is 1812.

5.       Specify a username.

username username

By default, no username is specified.

6.       Specify a password.

password { cipher | simple } string

By default, no password is specified.

7.       Specify a shared key for secure RADIUS authentication.

key { cipher | simple } string

By default, no shared key is specified for RADIUS authentication.

8.       (Optional.) Specify the source IP address for the probe packets.

·         IPv4 address:
source ip
ip-address

·         IPv6 address:
source ipv6
ipv6-address

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

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

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

The parameter settings take effect only on the current NQA template.

To configure optional parameters for an NQA template:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Create an NQA template and enter its view.

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

By default, no NQA templates exist.

3.       Configure a description.

description text

By default, no description is configured.

4.       Set the interval at which the NQA operation repeats.

frequency interval

The default setting is 5000 milliseconds.

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

5.       Set the probe timeout time.

probe timeout timeout

The default setting is 3000 milliseconds.

6.       Set the TTL for probe packets.

ttl value

The default setting is 20.

7.       Set the ToS value in the IP header of probe packets.

tos value

The default setting is 0.

8.       Specify the VPN instance where the operation is performed.

vpn-instance vpn-instance-name

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

9.       Set the number of consecutive successful probes to determine a successful operation event.

reaction trigger probe-pass count

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.     Set the number of consecutive probe failures to determine 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 nqa history [ admin-name operation-tag ]

Display the current monitoring results of reaction entries.

display nqa reaction counters [ admin-name operation-tag [ item-number ] ]

Display the most recent result of the NQA operation.

display nqa result [ admin-name operation-tag ]

Display NQA statistics.

display nqa statistics [ admin-name operation-tag ]

Display NQA server status.

display nqa server status

 

NQA configuration examples

For configuration examples of using an NQA template for a feature, see High Availability Configuration Guide.

ICMP echo operation configuration example

Network requirements

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

Figure 7 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 7. (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 10.2.2.2 as the destination IP address of ICMP echo requests.

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

# Specify 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 ip 10.1.1.2

# Configure the ICMP echo operation to perform 10 probes.

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

# Set the probe timeout time to 500 milliseconds for the ICMP echo operation.

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

# Configure the ICMP echo operation to repeat every 5000 milliseconds.

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

# Enable saving history records.

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

# Set the maximum number of history records to 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 that the packets sent by Device A can reach Device B through Device C. No packet loss occurs during the operation. The minimum, maximum, and average round-trip times are 2, 5, and 3 milliseconds, respectively.

ICMP jitter operation configuration example

Network requirements

As shown in Figure 8, configure an ICMP jitter operation to test the jitter between Device A and Device B.

Figure 8 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 8. (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 A:

# Create an ICMP jitter operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type icmp-jitter

# Specify 10.2.2.2 as the destination address for the operation.

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

# Configure the operation to repeat every 1000 milliseconds.

[DeviceA-nqa-admin-test1-icmp-jitter] frequency 1000

[DeviceA-nqa-admin-test1-icmp-jitter] quit

# Start the ICMP jitter operation.

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

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

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the ICMP 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: 1/2/1

    Square-Sum of round trip time: 13

    Last packet received time: 2015-03-09 17:40:29.8

  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

  ICMP-jitter results:

   RTT number: 10

    Min positive SD: 0                     Min positive DS: 0

    Max positive SD: 0                     Max positive DS: 0

    Positive SD number: 0                  Positive DS number: 0

    Positive SD sum: 0                     Positive DS sum: 0

    Positive SD average: 0                 Positive DS average: 0

    Positive SD square-sum: 0              Positive DS square-sum: 0

    Min negative SD: 1                     Min negative DS: 2

    Max negative SD: 1                     Max negative DS: 2

    Negative SD number: 1                  Negative DS number: 1

    Negative SD sum: 1                     Negative DS sum: 2

    Negative SD average: 1                 Negative DS average: 2

    Negative SD square-sum: 1              Negative DS square-sum: 4

  One way results:

    Max SD delay: 1                        Max DS delay: 2

    Min SD delay: 1                        Min DS delay: 2

    Number of SD delay: 1                  Number of DS delay: 1

    Sum of SD delay: 1                     Sum of DS delay: 2

    Square-Sum of SD delay: 1              Square-Sum of DS delay: 4

    Lost packets for unknown reason: 0

# Display the statistics of the ICMP jitter operation.

[DeviceA] display nqa statistics admin test1

NQA entry (admin admin, tag test1) test statistics:

  NO. : 1

    Start time: 2015-03-09 17:42:10.7

    Life time: 156 seconds

    Send operation times: 1560           Receive response times: 1560

    Min/Max/Average round trip time: 1/2/1

    Square-Sum of round trip time: 1563

  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

  ICMP-jitter results:

   RTT number: 1560

    Min positive SD: 1                     Min positive DS: 1

    Max positive SD: 1                     Max positive DS: 2

    Positive SD number: 18                 Positive DS number: 46

    Positive SD sum: 18                    Positive DS sum: 49

    Positive SD average: 1                 Positive DS average: 1

    Positive SD square-sum: 18             Positive DS square-sum: 55

    Min negative SD: 1                     Min negative DS: 1

    Max negative SD: 1                     Max negative DS: 2

    Negative SD number: 24                 Negative DS number: 57

    Negative SD sum: 24                    Negative DS sum: 58

    Negative SD average: 1                 Negative DS average: 1

    Negative SD square-sum: 24             Negative DS square-sum: 60

  One way results:

    Max SD delay: 1                        Max DS delay: 2

    Min SD delay: 1                        Min DS delay: 1

    Number of SD delay: 4                  Number of DS delay: 4

    Sum of SD delay: 4                     Sum of DS delay: 5

    Square-Sum of SD delay: 4              Square-Sum of DS delay: 7

    Lost packets for unknown reason: 0

DHCP operation configuration example

Network requirements

As shown in Figure 9, configure a DHCP operation to test the time required for Switch A to obtain an IP address from the DHCP server (Switch B).

Figure 9 Network diagram

 

Configuration procedure

# Create a DHCP operation.

<SwitchA> system-view

[SwitchA] nqa entry admin test1

[SwitchA-nqa-admin-test1] type dhcp

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

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

# Enable the saving of history records.

[SwitchA-nqa-admin-test1-dhcp] history-record enable

[SwitchA-nqa-admin-test1-dhcp] quit

# Start the DHCP operation.

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

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

[SwitchA] undo nqa schedule admin test1

# Display the most recent result of the DHCP operation.

[SwitchA] 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: 512/512/512

    Square-Sum of round trip time: 262144

    Last succeeded probe time: 2011-11-22 09:56:03.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 DHCP operation.

[SwitchA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

  Index      Response     Status           Time

  1          512          Succeeded        2011-11-22 09:56:03.2

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

DNS operation configuration example

Network requirements

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

Figure 10 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 10. (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 host.com as the domain name to be translated.

[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 11, 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 11 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 11. (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

# Set the username to admin for the FTP operation.

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

# Set the password to systemtest for the FTP operation.

[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 12, configure an HTTP operation on the NQA client to test the time required to obtain data from the HTTP server.

Figure 12 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 12. (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 13, configure a UDP jitter operation to test the jitter, delay, and round-trip time between Device A and Device B.

Figure 13 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 13. (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

# Specify 10.2.2.2 as the destination address of the operation.

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

# Set the destination port number to 9000.

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

# Configure the operation to repeat every 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 14, configure an SNMP operation to test the time the NQA client uses to get a response from the SNMP agent.

Figure 14 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 14. (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

# Specify 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 15, configure a TCP operation to test the time required for Device A to establish a TCP connection with Device B.

Figure 15 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 15. (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

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 9000.

[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 16, configure a UDP echo operation on the NQA client to test the round-trip time to Device B. The destination port number is 8000.

Figure 16 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 16. (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

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 8000.

[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 17, configure a UDP tracert operation to determine the routing path from Device A to Device B.

Figure 17 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 17. (Details not shown.)

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

3.        Execute the ip ttl-expires enable command on the intermediate devices and execute 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

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 33434.

[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

# Set the probe timeout time to 500 milliseconds.

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

# Configure the UDP tracert operation to repeat every 5000 milliseconds.

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

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

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

# Enable the no-fragmentation feature.

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

# Set the maximum number of consecutive probe failures to 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 18, configure a voice operation to test jitters, delay, MOS, and ICPIF between Device A and Device B.

Figure 18 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 18. (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

# Specify 10.2.2.2 as the destination IP address.

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

# Set the destination port number to 9000.

[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 19, configure a DLSw operation to test the response time of the DLSw device.

Figure 19 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 19. (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

# Specify 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 20, configure a path jitter operation to test the round trip time and jitters from Device A to Device B and Device C.

Figure 20 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 20. (Details not shown.)

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

# Execute the ip ttl-expires enable command on Device B and execute 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 every 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 21, configure a static route to Switch C with Switch B as the next hop on Switch A. Associate the static route, a track entry, and an ICMP echo operation to monitor the state of the static route.

Figure 21 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 21. (Details not shown.)

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

<SwitchA> system-view

[SwitchA] ip route-static 10.1.1.2 24 10.2.1.1 track 1

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

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

[SwitchA] nqa entry admin test1

# Configure the NQA operation type as ICMP echo.

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

# Specify 10.2.1.1 as the destination IP address.

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

# Configure the operation to repeat every 100 milliseconds.

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

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

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

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

# Start the ICMP operation.

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

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

[SwitchA] track 1 nqa entry admin test1 reaction 1

Verifying the configuration

# Display information about all the track entries on Switch A.

[SwitchA] 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 Switch A.

[SwitchA] 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        Vlan3

10.2.1.0/24         Direct 0    0            10.2.1.2        Vlan3

10.2.1.0/32         Direct 0    0            10.2.1.2        Vlan3

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        Vlan3

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 VLAN-interface 3 on Switch B.

<SwitchB> system-view

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] undo ip address

# Display information about all the track entries on Switch A.

[SwitchA] 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 Switch A.

[SwitchA] 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        Vlan3

10.2.1.0/32         Direct 0    0            10.2.1.2        Vlan3

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        Vlan3

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 22, configure an ICMP template for a feature to perform the ICMP echo operation from Device A to Device B.

Figure 22 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 22. (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 to 500 milliseconds for the ICMP echo operation.

[DeviceA-nqatplt-icmp-icmp] probe timeout 500

# Configure the ICMP echo operation to repeat every 3000 milliseconds.

[DeviceA-nqatplt-icmp-icmp] frequency 3000

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-icmp-icmp] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-icmp-icmp] reaction trigger probe-fail 2

DNS template configuration example

Network requirements

As shown in Figure 23, 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 23 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 23. (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 host.com as the domain name to be translated.

[DeviceA-nqatplt-dns-dns] resolve-target host.com

# Set the domain name resolution type to type A.

[DeviceA-nqatplt-dns-dns] resolve-type A

# Specify 3.3.3.3 as the expected IP address.

[DeviceA-nqatplt-dns-dns] expect ip 3.3.3.3

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-dns-dns] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-dns-dns] reaction trigger probe-fail 2

TCP template configuration example

Network requirements

As shown in Figure 24, 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 24 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 24. (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

# Specify 10.2.2.2 as the destination IP address.

[DeviceA-nqatplt-tcp-tcp] destination ip 10.2.2.2

# Set the destination port number to 9000.

[DeviceA-nqatplt-tcp-tcp] destination port 9000

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-tcp-tcp] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-tcp-tcp] reaction trigger probe-fail 2

TCP half open template configuration example

Network requirements

As shown in Figure 25, configure a TCP half open template for a feature to test whether Device B can provide the TCP service for Device A.

Figure 25 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 25. (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 A:

# Create TCP half open template test.

<DeviceA> system-view

[DeviceA] nqa template tcphalfopen test

# Specify 10.2.2.2 as the destination IP address.

[DeviceA-nqatplt-tcphalfopen-test] destination ip 10.2.2.2

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-tcphalfopen-test] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-tcphalfopen-test] reaction trigger probe-fail 2

UDP template configuration example

Network requirements

As shown in Figure 26, configure a UDP template for a feature to perform the UDP operation. The operation tests whether Device A can receive a response from Device B.

Figure 26 Network diagram

 

Configuration procedure

1.        Assign IP addresses to interfaces, as shown in Figure 26. (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 UDP port 9000.

[DeviceB] nqa server udp-echo 10.2.2.2 9000

4.        Configure Device A:

# Create UDP template udp.

<DeviceA> system-view

[DeviceA] nqa template udp udp

# Specify 10.2.2.2 as the destination IP address.

[DeviceA-nqatplt-udp-udp] destination ip 10.2.2.2

# Set the destination port number to 9000.

[DeviceA-nqatplt-udp-udp] destination port 9000

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-udp-udp] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-udp-udp] reaction trigger probe-fail 2

HTTP template configuration example

Network requirements

As shown in Figure 27, 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 27 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 27. (Details not shown.)

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

# Create the HTTP template http.

<DeviceA> system-view

[DeviceA] nqa template http http

# Specify http://10.2.2.2/index.htm as the URL of the HTTP server.

[DeviceA-nqatplt-http-http] url http://10.2.2.2/index.htm

# Set the HTTP operation type to get.

[DeviceA-nqatplt-http-http] operation get

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-http-http] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-http-http] reaction trigger probe-fail 2

FTP template configuration example

Network requirements

As shown in Figure 28, 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 28 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 28. (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

# Set the username to admin for the FTP server login.

[DeviceA-nqatplt-ftp-ftp] username admin

# Set the password to systemtest for the FTP server login.

[DeviceA-nqatplt-ftp-ftp] password simple systemtest

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-ftp-ftp] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-ftp-ftp] reaction trigger probe-fail 2

RADIUS template configuration example

Network requirements

As shown in Figure 29, configure a RADIUS template for a feature to test whether the RADIUS server (Device B) can provide authentication service for Device A. The username and password are admin and systemtest, respectively. The shared key is 123456 for secure RADIUS authentication.

Figure 29 Network diagram

 

Configuration procedure

# Assign IP addresses to interfaces, as shown in Figure 29. (Details not shown.)

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

# Configure the RADIUS server. (Details not shown.)

# Create RADIUS template radius.

<DeviceA> system-view

[DeviceA] nqa template radius radius

# Specify 10.2.2.2 as the destination IP address of the operation.

[DeviceA-nqatplt-radius-radius] destination ip 10.2.2.2

# Set the username to admin.

[DeviceA-nqatplt-radius-radius] username admin

# Set the password to systemtest.

[DeviceA-nqatplt-radius-radius] password simple systemtest

# Set the shared key to 123456 in plain text for secure RADIUS authentication.

[DeviceA-nqatplt-radius-radius] key simple 123456

# Configure the NQA client to notify the feature of the successful operation event if the number of consecutive successful probes reaches 2.

[DeviceA-nqatplt-radius-radius] reaction trigger probe-pass 2

# Configure the NQA client to notify the feature of the operation failure if the number of consecutive failed probes reaches 2.

[DeviceA-nqatplt-radius-radius] 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.

·      Layer 3 aggregate subinterfaces.

·      VLAN interfaces, and tunnel interfaces.

How NTP works

Figure 30 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 is set to 10:00:00 am for Device A and 11:00:00 am for Device B.

·          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 30 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 31. 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 31 NTP architecture

 

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

NTP supports the following association modes:

·          Client/server mode

·          Symmetric active/passive mode

·          Broadcast mode

·          Multicast mode

Table 2 NTP association mode

Mode

Working process

Principle

Application scenario

Client/server

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

A client can synchronize to a server, but a server cannot synchronize to a client.

As Figure 31 shows, this mode is intended for configurations where devices of a higher stratum synchronize to devices with a lower stratum.

Symmetric active/passive

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.

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.

As Figure 31 shows, this 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.

Broadcast

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 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 broadcast client can synchronize to a broadcast server, but a broadcast server cannot synchronize to a broadcast client.

A broadcast server sends clock synchronization messages to synchronize clients in the same subnet. As Figure 31 shows, 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.

Multicast

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.

A multicast client can synchronize to a multicast server, but a multicast server cannot synchronize to a multicast client.

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.

 

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 the least restrictive to the 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.

When the device receives an NTP request, it matches the request with the access rights in the order from the least restrictive to the most restrictive: peer, server, synchronization, and query.

·          If no NTP access control is configured, the peer access right applies.

·          If the IP address of the peer device matches a permit statement in an ACL, the 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 specified for an access right or the ACL specified for the access right is not created, the access right is not granted.

·          If none of the ACLs specified for the access rights is created, the peer access right applies.

·          If none of the ACLs specified for the access rights contains rules, no access right 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 32 NTP authentication

 

As shown in Figure 32, 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 different, the receiver discards the message.

-      If they are the same and an NTP session is not required to be created, the receiver responds to the message. For information about NTP sessions, see "Configuring the maximum number of dynamic associations."

-      If they are the same and an NTP session is to be created or has been created, the local device determines whether the sender is allowed to use the authentication ID after the NTP session is established. If the sender is allowed to use the authentication ID, the receiver accepts the message. If the sender is not allowed to use the authentication ID, the receiver discards the message.

NTP for MPLS L3VPN instances

On an MPLS L3VPN network, a PE that acts as an NTP client or active peer can synchronize with the NTP server or passive peer in an MPLS L3VPN instance.

As shown in Figure 33, users in VPN 1 and VPN 2 are connected to the MPLS backbone network through provider edge (PE) devices. VPN instances vpn1 and vpn2 have been created for VPN 1 and VPN 2, respectively on the PEs. Services of the two VPN instances are isolated. Time synchronization between PEs and devices in the two VPN instances can be realized if you perform the following tasks:

·          Configure the PEs to operate in NTP client or symmetric active mode.

·          Specify the VPN instance to which the NTP server or NTP symmetric passive peer belongs.

Figure 33 Network diagram

 

For more information about MPLS L3VPN, VPN instance, and PE, see MPLS Configuration Guide.

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 avoid frequent time changes or even synchronization failures, do not specify more than one reference source on a network.

·          Make sure you use the clock protocol command to specify the time protocol as NTP. For more information about the clock protocol command, see Fundamentals Command Reference.

Configuration task list

Tasks at a glance

(Required.) Enabling the NTP service

(Required.) Perform one or both of the following tasks:

·         Configuring NTP association mode

·         Configuring the local clock as a reference source

(Optional.) Configuring access control rights

(Optional.) Configuring NTP authentication

(Optional.) Configuring NTP optional parameters

 

Enabling the NTP service

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable the NTP service.

ntp-service enable

By default, the NTP service is disabled.

 

Configuring NTP association mode

This section describes how to configure NTP association mode.

Configuring NTP in client/server mode

Follow these guidelines when you configure an NTP client:

·          For the client to synchronize to an NTP server, make sure the server is synchronized by other devices or uses its local clock as a reference source.

·          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 executing the ntp-service unicast-server or ntp-service ipv6 unicast-server commands multiple times.

·          When the device operates in client/server mode, specify the IP address for the server on the client.

To configure an NTP client:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Specify an NTP server for the device.

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

 

Configuring NTP in symmetric active/passive mode

Follow these guidelines when you configure a symmetric-active peer:

·          For a symmetric-passive peer to process NTP messages from a symmetric-active peer, execute the ntp-service enable command on the symmetric passive peer to enable NTP.

·          For time synchronization between the symmetric-active peer and the symmetric-passive peer, make sure either or both of them are in synchronized state.

·          You can configure multiple symmetric-passive peers by executing the ntp-service unicast-peer or ntp-service ipv6 unicast-peer command multiple times.

·          When the device operates in symmetric active/passive mode, specify on a symmetric-active peer the IP address for a symmetric-passive peer.

To configure a symmetric-active peer:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Specify a symmetric-passive peer for the device.

·         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 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 ] *

By default, no symmetric-passive peer is specified.

 

Configuring NTP in broadcast mode

For a broadcast client to synchronize to a broadcast server, make sure the broadcast server is synchronized by other devices or uses its local clock as a reference source.

Configure NTP in broadcast mode on both the broadcast server and client.

Configuring a broadcast client

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

Enter the interface for receiving NTP broadcast messages.

3.       Configure the device to operate in broadcast client mode.

ntp-service broadcast-client

By default, the device does not operate in any NTP association mode.

After you execute the command, the device receives NTP broadcast messages from the specified interface.

 

Configuring the broadcast server

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

Enter the interface for sending NTP broadcast messages.

3.       Configure the device to operate in NTP broadcast server mode.

ntp-service broadcast-server [ authentication-keyid keyid | version number ] *

By default, the device does not operate in any NTP association mode.

After you execute the command, the device sends NTP broadcast messages from the specified interface.

 

Configuring NTP in multicast mode

For a multicast client to synchronize to a multicast server, make sure the multicast server is synchronized by other devices or uses its local clock as a reference source.

Configure NTP in multicast mode on both the multicast server and client.

Configuring a multicast client

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

Enter the interface for receiving NTP multicast messages.

3.       Configure the device to operate in multicast client mode.

·         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-address

By default, the device does not operate in any NTP association mode.

After you execute the command, the device receives NTP multicast messages from the specified interface.

 

Configuring the multicast server

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

Enter the interface for sending NTP multicast message.

3.       Configure the device to operate in multicast server mode.

·         Configure the device to operate in multicast server mode:
ntp-service multicast-server
[ ip-address ] [ authentication-keyid keyid | ttl ttl-number | version number ] *

·         Configure the device to operate in multicast server mode:
ntp-service ipv6 multicast-server
ipv6-address [ authentication-keyid keyid | ttl ttl-number ] *

By default, the device does not operate in any NTP association mode.

After you execute the command, the device receives NTP multicast messages from the specified interface.

 

Configuring access control rights

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Configure the NTP service access control right for a peer device to access the local device.

·         Configure the NTP service access control right for a peer device to access the local device
ntp-service access { peer | query | server | synchronization } acl ipv4-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 ipv6-acl-number

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

To ensure a successful NTP authentication, configure the same key ID, authentication algorithm, and key on the server and client. Make sure the peer device is allowed to use the authentication ID.

To configure NTP authentication for a client:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.       Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode { hmac-sha-1 | hmac-sha-256 | hmac-sha-384 | hmac-sha-512 | md5 } { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key exists.

4.       Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

By default, no authentication key is configured as a trusted key.

5.       Associate the specified key with an NTP server.

·         Associate the specified key with an NTP server:
ntp-service
unicast-server { server-name | ip-address } [ vpn-instance vpn-instance-name ] 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

N/A

 

To configure NTP authentication for a server:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.       Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode { hmac-sha-1 | hmac-sha-256 | hmac-sha-384 | hmac-sha-512 | md5 } { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key exists.

4.       Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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 table means that whether the configuration is performed does not make any difference.)

Table 3 NTP authentication results

Client

Server

Authentication result

Enable NTP authentication

Configure a key and configure it as a trusted key

Associate the key with an NTP server

Enable NTP authentication

Configure a key and configure it as a trusted key

Yes

Yes

Yes

Yes

Yes

Succeeded

Yes

Yes

Yes

Yes

No

Failed

Yes

Yes

Yes

No

N/A

Failed

Yes

No

Yes

N/A

N/A

Failed

Yes

N/A

No

N/A

N/A

No authentication

No

N/A

N/A

N/A

N/A

No authentication

 

Configuring NTP authentication in symmetric active/passive mode

To ensure a successful NTP authentication, configure the same key ID, authentication algorithm, and key on the active peer and passive peer. Make sure the peer device is allowed to use the authentication ID.

To configure NTP authentication for an active peer:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.       Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode { hmac-sha-1 | hmac-sha-256 | hmac-sha-384 | hmac-sha-512 | md5 } { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key exists.

4.       Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

By default, no authentication key is configured as a trusted key.

5.       Associate the specified key with a passive peer.

·         Associate the specified key with a passive peer:
ntp-service unicast-peer
{ ip-address | peer-name } [ vpn-instance vpn-instance-name ] 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

N/A

 

To configure NTP authentication for a passive peer:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable NTP authentication.

ntp-service authentication enable

By default, NTP authentication is disabled.

3.       Configure an NTP authentication key.

ntp-service authentication-keyid keyid authentication-mode { hmac-sha-1 | hmac-sha-256 | hmac-sha-384 | hmac-sha-512 | md5 } { cipher | simple } string [ acl ipv4-acl-number | ipv6 acl ipv6-acl-number ] *

By default, no NTP authentication key exists.

4.       Configure the key as a trusted key.

ntp-service reliable authentication-keyid keyid

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 peer

Passive peer

Authentication result

Enable NTP authentication

Configure a key and configure it as a trusted key

Associate the key with a passive peer

Enable NTP authentication

Configure a key and configure it as a trusted key

Stratum level of the active and passive peers is not considered.

Yes

Yes

Yes

Yes

Yes

Succeeded

Yes

Yes

Yes

Yes

No

Failed

Yes

Yes

Yes

No

N/A

Failed

Yes

N/A

No

Yes

N/A

Failed

Yes

N/A

No

No