H3C S7500E User Manual

Download

Page 1

H3C S7500E Series Ethernet Switches

Network Management and Monitoring

Configuration Guide

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

Document Version: 20100722-C-1.01 Product Version: Release 6605 and Later

Page 2

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

Trademarks

Notice

H3C, , Aolynk, , H3Care, SecPro, SecPoint, SecEngine, SecPath, Comware, Secware, Storware, NQA, VVG, V

, TOP G, , IRF, NetPilot, Neocean, NeoVTL,

G, VnG, PSPT, XGbus, N-Bus, TiGem, InnoVision and HUASAN are trademarks of Hangzhou H3C Technologies Co., Ltd.

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

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

Page 3

Preface

The H3C S7500E documentation set includes 12 configuration guides, which describe the software features for the H3C S7500E Series Ethernet Switches and guide you through the software configuration procedures. These configuration guides also provide configuration examples to help you apply software features to different network scenarios.

The Network Management and Monitoring Configuration Guide describes network management and monitoring fundamentals and configuration. It describes how to view the system information, sample packets, assess t he networ k perform ance, synch ronize time for all devices with clo cks in your network, supply power for the attached devices by using PoE, and use the ping, tracert, and debug commands to check and debug the current network connectivity.

This preface includes:

z Audience z Document Organization z Conventions z About the H3C S7500E Documentation Set z Obtaining Documentation z Documentation Feedback

Audience

This documentation is intended for:

z Network planners z Field technical support and servicing engineers z Network administrators working with the S7500E series

Document Organization

The Network Management and Monitoring Configuration Guide comprises these parts:

System Maintenance and Debugging

PoE Configuration SNMP Configuration MIB Style Configuration RMON Configuration Port Mirroring

Configuration

NQA Configuration NTP Configuration IPC Configuration

Traffic Mirroring Configuration

Conventions

sFlow Configuration

Information Center Configuration

This section describes the conventions used in this documentation set.

Command conventions

Convention Description

Boldface Bold

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

Page 4

Convention Description

italic

[ ]

{ x | y | ... }

[ x | y | ... ]

{ x | y | ... } *

[ x | y | ... ] *

&<1-n>

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

Italic text represents arguments that you replace with actual values. Square brackets enclose syntax choices (keywords or arguments) that are

optional. Braces enclose a set of required syntax choices separated by vertical bars,

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

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

vertical bars, from which you select at least one. Asterisk marked square brackets enclose optional syntax choices separated by

vertical bars, from which you may select multiple choices or none. The argument or keyword and argument combination before the ampersand (&)

sign can be entered 1 to n times.

Symbols

Convention Description

Means reader be extremely careful. Improper operation may cause bodily injury.

Means reader be careful. Improper operation may cause data loss or damage to equipment.

Means a complementary description.

About the H3C S7500E Documentation Set

The H3C S7500E documentation set includes:

Category Documents Purposes

Marketing brochures Describe product specifications and benefits.

Product description and specifications

Technology white papers

Card datasheets Describe card specifications, features, and standards.

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

Page 5

Category Documents Purposes

Hardware installation

Software configuration

Installation guide

H3C N68 Cabinet Installation and Remodel Introduction

H3C Pluggable SFP [SFP+][XFP] Transceiver Modules Installation Guide

H3C Mid-Range Series Ethernet Switches Pluggable Modules Manual

H3C PoE DIMM Module Installation Guide

Single PoE DIMM Module Installation Guide

Configuration guides

Command references Provide a quick reference to all available commands.

Configuration examples

Provides a complete guide to hardware installation and hardware specifications.

Guides you through installing and remodeling H3C N68 cabinets.

Guides you through installing SFP/SFP+/XFP transceiver modules.

Describes the hot-swappable modules available for the Mid-Range Series Ethernet Switches, their external views, and specifications.

Describes how to install the DIMM (LSBM1POEDIMMH) for PoE master and slave power management.

Describes how to install the 24-port DIMM (LSQM1POEDIMMS0) for PoE power management.

Describe software features and configuration procedures.

Describe typical network scenarios and provide configuration examples and instructions.

Operations and maintenance

Power configuration

Release notes

H3C PSR320-A[PSR320-D] Power Module User Manual

H3C PSR650-A[PSR650-D] Power Module User Manual

H3C PSR1400-A[PSR1400-D] Power Module User Manual

H3C PSR2800-ACV Power Module User Manual

H3C PSR6000-ACV Power Module User Manual

H3C PWR-SPA Power Module Adapter User Manual

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

Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR320-A/PSR320-D power module.

Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR650-A/PSR650-D power module.

Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR1400-A/PSR1400-D power module.

Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR2800-ACV power module.

Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR6000-ACV power module.

Describes the functions and appearance of the H3C PWR-SPA power module adapter, and how to use it with the PSR650 power module.

H3C S7500E Power Configuration Guide

Guides you to select power modules in various cases.

Page 6

Category Documents Purposes

Optional cards Card manuals

Obtaining Documentation

You can access the most up-to-date H3C product documentation on the World Wide Web at

http://www.h3c.com.

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

[Technical Support & Documents > Technical Documents] – Provides hardware installation, and

software feature configuration and maintenance documentation.

[Products & Solutions] – Provides information about products and technologies, as well as solutions. [Technical Support & Documents > Software Download] – Provides the documentation released with

the software version.

The S7500E series Ethernet switches support various card models. Each model is provided with a card manual that describes:

z The type, number, and transmission rate of

interfaces

z Applicable switches of the card z Required software version z Pluggable modules supported by the card

Documentation Feedback

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

Page 7

1 System Maintaining and Debugging ····································································································1-1

System Maintaining and Debugging····································································································1-1 Ping······················································································································································1-1

Introduction···································································································································1-1 Configuring Ping···························································································································1-1 Ping Configuration Example·········································································································1-2

Tracert ·················································································································································1-4

Introduction···································································································································1-4 Configuring Tracert·······················································································································1-4

System Debugging·······························································································································1-5

Introduction to System Debugging ·······························································································1-5 Configuring System Debugging····································································································1-6

Ping and Tracert Configuration Example·····························································································1-7

2 NQA Configuration·································································································································2-1

NQA Overview·····································································································································2-1

Introduction to NQA······················································································································2-1 Features of NQA ··························································································································2-1 Basic Concepts of NQA················································································································ 2-3

NQA Test Operation·····················································································································2-4 NQA Configuration Task List ···············································································································2-4 Configuring the NQA Server················································································································2-5 Enabling the NQA Client······················································································································2-5 Creating an NQA Test Group ··············································································································2-6 Configuring an NQA Test Group··········································································································2-6

Configuring an ICMP Echo Test···································································································2-6

Configuring a DHCP Test·············································································································2-8

Configuring a DNS Test ···············································································································2-8

Configuring an FTP Test ··············································································································2-9

Configuring an HTTP Test··········································································································2-11

Configuring a UDP Jitter Test·····································································································2-12

Configuring an SNMP Test·········································································································2-14

Configuring a TCP Test··············································································································2-15

Configuring a UDP Echo Test ····································································································2-16

Configuring a Voice Test············································································································2-18

Configuring a DLSw Test ···········································································································2-21 Configuring the Collaboration Function ·····························································································2-21 Configuring Trap Delivery··················································································································2-22 Configuring the NQA Statistics Function ···························································································2-23 Configuring the History Records Saving Function·············································································2-24 Configuring Optional Parameters Common to an NQA Test Group··················································2-25 Scheduling an NQA Test Group ········································································································2-26

Page 8

Displaying and Maintaining NQA·······································································································2-27 NQA Configuration Examples············································································································2-28

ICMP Echo Test Configuration Example····················································································2-28

DHCP Test Configuration Example····························································································2-29

DNS Test Configuration Example ······························································································2-30

FTP Test Configuration Example ·······························································································2-31

HTTP Test Configuration Example·····························································································2-32

UDP Jitter Test Configuration Example······················································································2-33

SNMP Test Configuration Example····························································································2-36

TCP Test Configuration Example·······························································································2-37

UDP Echo Test Configuration Example ·····················································································2-38

Voice Test Configuration Example·····························································································2-39

DLSw Test Configuration Example ····························································································2-42

NQA Collaboration Configuration Example················································································2-43

3 NTP Configuration··································································································································3-1

NTP Overview······································································································································3-1

Applications of NTP······················································································································3-1

Advantages of NTP ······················································································································3-2

How NTP Works···························································································································3-2

NTP Message Format ··················································································································3-3

Operation Modes of NTP·············································································································· 3-5

Multiple Instances of NTP ············································································································3-7 NTP Configuration Task List················································································································3-8 Configuring the Operation Modes of NTP····························································································3-8

Configuring NTP Client/Server Mode···························································································3-9

Configuring the NTP Symmetric Peers Mode ············································································3-10

Configuring NTP Broadcast Mode······························································································3-11

Configuring NTP Multicast Mode································································································3-12 Configuring the Local Clock as a Reference Source·········································································3-13 Configuring Optional Parameters of NTP ··························································································3-14

Specifying the Source Interface for NTP Messages···································································3-14

Disabling an Interface from Receiving NTP Messages······························································3-15

Configuring the Maximum Number of Dynamic Sessions Allowed ············································3-15 Configuring Access-Control Rights····································································································3-16

Configuration Prerequisites········································································································3-16

Configuration Procedure ············································································································3-16 Configuring NTP Authentication ········································································································3-17

Configuration Prerequisites········································································································3-17

Configuration Procedure ············································································································3-17 Displaying and Maintaining NTP········································································································3-19 NTP Configuration Examples ············································································································3-20

Configuring NTP Client/Server Mode·························································································3-20

Configuring the NTP Symmetric Mode·······················································································3-21

Configuring NTP Broadcast Mode······························································································3-22

Configuring NTP Multicast Mode································································································3-24

Page 9

Configuring NTP Client/Server Mode with Authentication··························································3-27

Configuring NTP Broadcast Mode with Authentication ······························································3-28

Configuring MPLS VPN Time Synchronization in Client/server Mode ·······································3-30

Configuring MPLS VPN Time Synchronization in Symmetric Peers Mode································3-32

4 IPC Configuration ···································································································································4-1

IPC Overview·······································································································································4-1

Introduction to IPC························································································································4-1 Enabling IPC Performance Statistics···································································································4-2 Displaying and Maintaining IPC···········································································································4-3

5 PoE Configuration··································································································································5-1

PoE Overview······································································································································5-1

Introduction to PoE·······················································································································5-1

Protocol Specification···················································································································5-3 PoE Configuration Task List ················································································································5-3 Enabling PoE·······································································································································5-4

Enabling PoE for a PSE ···············································································································5-4

Enabling PoE for a PoE Interface·································································································5-5 Detecting PDs······································································································································5-6

Enabling the PSE to Detect Nonstandard PDs ············································································5-6 Configuring the PoE Power ·················································································································5-7

Configuring the Maximum PoE Power ·························································································5-7

Configuring the Maximum PSE Power·························································································5-8

Configuring the Maximum PoE Interface Power ··········································································5-8 Configuring PoE Power Management ·································································································5-8

Configuring PSE Power Management··························································································5-9

Configuring PoE Interface Power Management·········································································5-10 Configuring the PoE Monitoring Function··························································································5-11

Configuring PoE Power Supply Monitoring················································································5-11

Configuring PSE Power Monitoring····························································································5-12

Monitoring PD·····························································································································5-13 Configuring PoE Interface through PoE Profile ·················································································5-13

Configuring PoE Profile··············································································································5-13

Applying PoE Profile···················································································································5-14 Upgrading PSE Processing Software in Service ··············································································· 5-15 Displaying and Maintaining PoE········································································································5-16 PoE Configuration Example···············································································································5-18 Troubleshooting PoE ·························································································································5-19

6 SNMP Configuration ······························································································································6-1

SNMP Overview···································································································································6-1

SNMP Mechanism························································································································6-1

SNMP Protocol Version················································································································6-2

MIB Overview·······························································································································6-2 SNMP Configuration····························································································································6-3 Configuring SNMP Logging ·················································································································6-6

Introduction to SNMP Logging ·····································································································6-6

iii

Page 10

Enabling SNMP Logging ··············································································································6-6 Configuring SNMP Trap·······················································································································6-7

Enabling the Trap Function ··········································································································6-7

Configuring Trap Parameters·······································································································6-8 Displaying and Maintaining SNMP ····································································································6-10 SNMPv1/SNMPv2c Configuration Example ······················································································6-11 SNMPv3 Configuration Example ·······································································································6-12 SNMP Logging Configuration Example ·····························································································6-13

7 MIB Style Configuration·························································································································7-1

Setting the MIB Style ···························································································································7-1 Displaying and Maintaining MIB ··········································································································7-1

8 RMON Configuration······························································································································8-1

RMON Overview··································································································································8-1

Introduction···································································································································8-1

Working Mechanism·····················································································································8-2

RMON Groups······························································································································8-2 Configuring the RMON Statistics Function··························································································8-4

Configuring the RMON Ethernet Statistics Function ····································································8-4

Configuring the RMON History Statistics Function·······································································8-4 Configuring the RMON Alarm Function ·······························································································8-5

Configuration Prerequisites·········································································································· 8-5

Configuration Procedure ··············································································································8-5 Displaying and Maintaining RMON······································································································8-7 Ethernet Statistics Group Configuration Example ···············································································8-7 History Group Configuration Example ·································································································8-8 Alarm Group Configuration Example·································································································8-10 Private Alarm Group Configuration Example·····················································································8-11

9 Port Mirroring Configuration·················································································································9-1

Introduction to Port Mirroring···············································································································9-1

Classification of Port Mirroring ·····································································································9-1

Implementing Port Mirroring·········································································································9-1 Configuring Local Port Mirroring··········································································································9-4

Local Port Mirroring Configuration Task List················································································9-4

Creating a Local Mirroring Group·································································································9-4

Configuring Mirroring Ports for the Local Mirroring Group ···························································9-5

Configuring the Monitor Port for the Local Mirroring Group ·························································9-6 Configuring Layer 2 Remote Port Mirroring·························································································9-7

Layer 2 Remote Port Mirroring Configuration Task List·······························································9-7

Configuration Prerequisites·········································································································· 9-8

Configuring a Remote Source Mirroring Group (on the Source Device)······································9-8

Configuring a Remote Destination Mirroring Group (on the Destination Device)·······················9-10 Configuring Layer 3 Remote Port Mirroring·······················································································9-13

Layer 3 Remote Port Mirroring Configuration Task List·····························································9-13

Configuration Prerequisites········································································································ 9-13

Configuring Local Mirroring Groups ··························································································· 9-13

Page 11

Configuring Mirroring Ports for a Local Mirroring Group ····························································9-14

Configuring the Monitor Port for a Local Mirroring Group ··························································9-15 Configuring Local Port Mirroring for an ONU·····················································································9-16 Displaying and Maintaining Port Mirroring·························································································9-16 Port Mirroring Configuration Examples······························································································9-17

Local Port Mirroring Configuration Example (in Mirroring Port Mode) ·······································9-17

Layer 2 Remote Port Mirroring Configuration Example······························································ 9-18

Layer 3 Remote Port Mirroring Configuration Example······························································ 9-19

Local Port Mirroring Configuration Example for ONUs·······························································9-22

10 Traffic Mirroring Configuration·········································································································10-1

Traffic Mirroring Overview··················································································································10-1

Traffic Mirroring Overview··········································································································10-1

Remote Traffic Mirroring Overview·····························································································10-1 Configuring Traffic Mirroring··············································································································10-2

Configuring Traffic Mirroring·······································································································10-2

Applying a QoS Policy················································································································10-2

Configuring Remote Traffic Mirroring·························································································10-4 Displaying and Maintaining Traffic Mirroring······················································································10-5 Traffic Mirroring Configuration Examples ··························································································10-5

Traffic Mirroring Configuration Example·····················································································10-5

Network Requirements···············································································································10-5

Configuration Procedure ············································································································10-5

Remote Traffic Mirroring Configuration Example·······································································10-6

11 sFlow Configuration···························································································································11-1

sFlow Overview ·································································································································11-1

Introduction to sFlow··················································································································11-1

Operation of sFlow·····················································································································11-2 Configuring sFlow······························································································································11-2 Displaying and Maintaining sFlow ·····································································································11-3 sFlow Configuration Example············································································································11-3 Troubleshooting sFlow Configuration································································································11-4

The Remote sFlow Collector Cannot Receive sFlow Packets ···················································11-4

12 Information Center Configuration·····································································································12-1

Information Center Overview·············································································································12-1

Introduction to Information Center······························································································12-1

Classification of System Information ··························································································12-2

Eight Levels of System Information····························································································12-2

Seven Output Destinations and Ten Channels of System Information ······································12-3

Outputting System Information by Source Module·····································································12-4

Default Output Rules of System Information··············································································12-4

System Information Format········································································································12-5 Configuring Information Center··········································································································12-7

Information Center Configuration Task List················································································12-7

Outputting System Information to the Console···········································································12-8

Outputting System Information to a Monitor Terminal································································12-9

Page 12

Outputting System Information to a Log Host ··········································································12-10

Outputting System Information to the Trap Buffer····································································12-11

Outputting System Information to the Log Buffer·····································································12-13

Outputting System Information to the SNMP Module·······························································12-14

Saving System Information to a Log File·················································································· 12-15

Configuring Synchronous Information Output··········································································12-16

Disabling a Port from Generating Link Up/Down Logging Information·····································12-16 Displaying and Maintaining Information Center···············································································12-17 Information Center Configuration Examples····················································································12-18

Outputting Log Information to a Unix Log Host········································································12-18

Outputting Log Information to a Linux Log Host·······································································12-20

Outputting Log Information to the Console···············································································12-22

13 Index····················································································································································13-1

Page 13

1 System Maintaining and Debugging

When maintaining and debugging the system, go to these sections for information you are interested in:

z System Maintaining and Debugging z Ping z Tracert z System Debugging z Ping and Tracert Configuration Example

System Maintaining and Debugging

You can use the ping command and the tracert command to verify the current network connectivity, and use the debug command to enable debugging and thus to diagnose system faults based on the debugging information.

Ping

Introduction

You can use the ping command to verify whether a device with a specified address is reachable, and to examine network connectivity.

The ping function is implemented through the Internet Control Message Protocol (ICMP):

1) The source device sends an ICMP echo request to the destination device.

2) The source device determines whether the destination is reachable based on whether it receives an ICMP echo reply; if the destination is reachable, the source device determines the link quality based on the numbers of ICMP echo requests sent and replies received, determines the distance between the source and destination based on the round trip time of ping packets.

Configuring Ping

Follow the step below to configure the ping function:

To do… Use the command… Remarks

Check whether a specified address in an IP network is reachable

ping

[

] [ -a source-ip | -c count | -f | -h ttl | -i

-vpn-instance

ping ipv6

packet-size | -t timeout ] * host [ -i interface-type interface-number ]

vpn-instance-name ] * host

[ -a source-ipv6 | -c count | -m interval | -s

-tos

tos |

-v

Required Use either approach

ping

The applicable in an IPv4 network; the applicable in an IPv6 network.

Available in any view

command is

ping ipv6

command is

1-1

Page 14

z For a low-speed network, you are recommended to set a larger value for the timeout timer

(indicated by the -t parameter in the command) when configuring the ping command.

z Only the directly connected segment address can be pinged if the outgoing interface is

specified with the -i argument

z For detailed description of the ping lsp command, refer to MPLS Basics Commands in the

MPLS Command Reference.

Ping Configuration Example

Network requirements

As shown in Figure 1-1, check whether an available route exists between Device A and Device C. If there is an available route exists between the two devices, get the detailed information of routes from Device A to Devic e C.

Figure 1-1 Ping network diagram

Configuration procedure

# Use the ping command to display whether an available route exists between Device A and Device C.

<DeviceA> ping 1.1.2.2 PING 1.1.2 .2: 56 data bytes , pre ss CTR L_C t o break Reply from 1.1.2.2: bytes=56 Sequence=1 ttl=254 time=205 ms Reply from 1.1.2.2: bytes=56 Sequence=2 ttl=254 time=1 ms Reply from 1.1.2.2: bytes=56 Sequence=3 ttl=254 time=1 ms Reply from 1.1.2.2: bytes=56 Sequence=4 ttl=254 time=1 ms Reply from 1.1.2.2: bytes=56 Sequence=5 ttl=254 time=1 ms

--- 1.1.2. 2 ping stat istics ---

5 packet(s) transmitted 5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/41/205 ms

# Get the detailed information of routes from Device A to Device C.

<DeviceA> ping -r 1.1.2.2

1-2

Page 15

PING 1.1.2 .2: 56 data bytes , pre ss CTR L_C t o break Reply from 1.1.2.2: bytes=56 Sequence=1 ttl=254 time=53 ms Record Route:

1.1.2.1

1.1.2.2

1.1.1.2

1.1.1.1

Reply from 1.1.2.2: bytes=56 Sequence=2 ttl=254 time=1 ms Record Route:

1.1.2.1

1.1.2.2

1.1.1.2

1.1.1.1

Reply from 1.1.2.2: bytes=56 Sequence=3 ttl=254 time=1 ms Record Route:

1.1.2.1

1.1.2.2

1.1.1.2

1.1.1.1

Reply from 1.1.2.2: bytes=56 Sequence=4 ttl=254 time=1 ms Record Route:

1.1.2.1

1.1.2.2

1.1.1.2

1.1.1.1

Reply from 1.1.2.2: bytes=56 Sequence=5 ttl=254 time=1 ms Record Route:

1.1.2.1

1.1.2.2

1.1.1.2

1.1.1.1

--- 1.1.2. 2 ping stat istics ---

5 packet(s) transmitted 5 packet(s) received

0.00% packet loss

round-trip min/avg/max = 1/11/53 ms

The principle of ping –r is as shown in Figure 1-1.

1) The source (Device A) sends an ICMP echo request with the RR option being empty to the destination (Device C).

2) The intermediate device (Device B) adds the IP address (1.1.2.1) of its outbound interface 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 (1.1.2.2) of its outbound interface to the RR option. Then the destination device sends an ICMP echo reply.

4) The intermediate device adds the IP address (1.1.1.2) of its outbound interface 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 (1.1.1.1) of its inbound interface to the RR option. Finally, you can get the detailed information of routes from Device A to Device C: 1.1.1.1 <-> {1.1.1.2; 1.1.2.1} <-> 1.1.2.2.

1-3

Page 16

Tracert

Introduction

By using the tracert command, you can trace the Layer 3 devices involved in delivering an IP packet from source to destination to check whether a network is available. This is useful for identification of failed node(s) in the event of network failure.

Figure 1-2 Tracert diagram

The tracert function is implemented through ICMP, as shown in The source (Device A) sends a packet with a TTL value of 1 to the destination (Device D). The UDP

port of the packet is a port number that will not be used by any application of the destination.

1) The first hop (Device B) (the Layer 3 device that first receives the packet) responds by sending a TTL-expired ICMP error message to the source, with its IP address 1.1.1.2 encapsulated. In this way, the source device can get the address (1.1.1.2) of the first Layer 3 device.

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

3) The second hop (Device C) responds with a TTL-expired ICMP error message, which gives the source device the address (1.1.2.2) of the second Layer 3 device.

4) The above process continues until the ultimate destination device is reached. No application of the destination uses this UDP port. Therefore, the destination replies a port unreachable ICMP error message with the destination IP address 1.1.3.2.

5) When the source device receives the port unreachable ICMP error message, it knows that the packet has reached the destination, and it can get the addresses of all the Layer 3 devices involved to get to the destination device (1.1.1.2, 1 .1.2.2, 1 .1.3 .2).

Configuring Tracert

Figure 1-2:

Follow these steps to configure tracert:

To do… Use the command… Remarks

Enter system view

Enable sending of ICMP timeout packets

system-view

ip ttl-expires enable

—

Required Disabled by default.

1-4

Page 17

To do… Use the command… Remarks

Enable sending of ICMP destination unreachable packets

Display the routes from source to destination

ip unreachables enable

tracert

tracert ipv6

packet-number | -w timeout ] * host

[ -f first-ttl | -m max-ttl | -p port | -q

-w

timeout ] * host

-m

-vpn-instance

max-ttl |

Required Disabled by default.

Required

-p

Use either approach

tracert

The applicable in an IPv4 network;

tracert ipv6

the applicable in an IPv6 network.

Available in any view

command is

For the introduction to the tracert lsp command, refer to MPLS Basics Commands in the MPLS Command Reference.

System Debugging

Introduction to System Debugging

The device provides various debugging functions. For the majority of protocols and features supported, the system provides corresponding debugging information to help users diagnose errors.

The following two switches control the display of debugging information:

z Protocol debugging switch, which controls protocol-specific debugging information. z Screen output switch, which controls whether to display the debugging information on a certain

screen.

Figure 1-3 illustrates, suppose the device can provide debugging for the three modules 1, 2, and

3. Only when both the protocol debugging switch and the screen output switch are turned on can debugging information be output on a terminal.

1-5

Page 18

Figure 1-3 The relationship between the protocol and screen debugging switch

Debugging information

Protocol

debugging

switch

Screen output switch

1 2 3

OFF

Configuring System Debugging

Output of the debugging information may reduce system efficiency. The debugging commands are usually used by administrators in diagnosing network failure. After completing the debugging, disable the corresponding debugging function, or use the undo debugging all command to disable all the debugging functions.

Debugging information

Protocol debugging switch

Screen output switch

1 2 3

OFF

Output of debugging information is related to the configurations of the information cente r and the debugging commands of each protocol and functional module. Displaying the debugging information on a terminal (including console or VTY) is a common way to output debugging information. You can also output debugging information to other destinations. For the detailed configurations, refer to Information Center Commands in the Network Management and Monitoring Command Reference. By default, you can output debugging information to a terminal by following these steps:

To do… Use the command… Remarks

Optional

The terminal monitoring on the Enable the terminal monitori ng of system information

Enable the terminal display of debugging information

terminal monitor

terminal debugging

console is enabled by default and

that on the monitoring terminal is

disabled by default.

Available in user view

Required

Disabled by default

Available in user view

1-6

Page 19

To do… Use the command… Remarks

Enable debugging for a specified module

debugging

module-name [ option ] }

all [ timeout

{

time ] |

Required

Disabled by default

Available in user view

Display the enabled debugging functions

display debugging [ interface

interface-type interface-number ] [ module-name ]

You must configure the debugging, terminal debugging and terminal monitor commands first to display the detailed debugging information on the terminal. For the detailed description on the terminal debugging and terminal monitor commands, refer to Information Center Commands in the Network Management and Monitoring Command Reference.

Ping and Tracert Configuration Example

Network requirements

As shown in Figure 1-4, Device A failed to telnet Device C. Now it is required to determine whether an available route exists between Device A and Device C. If no such a route exists, you need to locate the failed nodes in the network.

Optional

Available in any view

Figure 1-4 Ping and tracert network diagram

Configuration procedure

# Use the ping command to display whether an available route exists between Device A and Device C.

<DeviceA> ping 1.1.2.2 PING 1.1.2 .2: 56 data bytes , pre ss CTR L_C t o break Request time out Request time out Request time out Request time out Request time out

--- 1.1.2. 2 ping stat istics -- 5 packet(s) transmitted 0 packet(s) received

100.00% packet loss

1-7

Page 20

# No such a route exists. Use the tracert command to determine failed nodes.

<DeviceA> system-view [DeviceA] ip ttl-expires enable [DeviceA] ip unreachables enable [DeviceA] tracert 1.1.2.2 traceroute to 1.1.2.2(1.1.2.2) 30 hops max,40 bytes packet, press CTRL_C to bre ak 1 1.1.1.2 14 ms 10 ms 20 ms 2 * * * 3 * * * 4 * * * 5 <DeviceA>

The above output shows that no available route exists between Device A and Device C; an available router exists between Device A and Device B; an error occurred on the connection between Device B and Device C. In this case, you can use the debugging ip icmp command to enable ICMP debugging on Device A and Device C to check whether the devices send or receive the specified ICMP packets, or you can use the display ip routing-table command to display whether a route exists between the two devices.

1-8

Page 21

2 NQA Configuration

This chapter includes these sections:

z NQA Overview z NQA Configuration Task List z Configuring the NQA Server z Enabling the NQA Client z Creating an NQA Test Group z Configuring an NQA Test Group z Configuring the Collaboration Function z Configuring Trap Delivery z Configuring the NQA Statistics Function z Configuring the History Records Saving Function z Configuring Optional Parameters Common to an NQA Test Group z Scheduling an NQA Test Group z Displaying and Maintaining NQA z NQA Configuration Examples

NQA Overview

Introduction to NQA

Network Quality Analyzer (NQA) analyzes network performance, services and service quality through sending test packets, and provides you with network performance and service quality parameters such as delay jitter , TCP connection delay, FTP connection delay and file transfer rate.

With the NQA test results, you can:

1) Know network performance in time and then take corresponding measures.

2) Diagnose and locate network faults.

Features of NQA

Supporting multiple test types

Ping can use only the Internet Control Message Protocol (ICMP) to test the reachability of the destination host and the round-trip time of a packet to the destination. As an enhancement to the Ping tool, NQA provides multiple test types and more functions.

At present, NQA supports 11 test types: ICMP echo, DHCP, DNS, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo, voice and DLSw.

In an NQA test, the client sends different types of test packets to the peer to detect the availability and the response time of the peer, helping you know protocol availability and network performance based on the test results.

2-1

Page 22

Supporting the collaboration function

Collaboration is implemented by establishing reaction entries to monitor the detection results of the current test group. If the number of consecutive probe failures reaches a certain limit, NQA’s collaboration with other modules is triggered. The implementation of collaboration is shown in

2-1.

Figure 2-1 Implementation of collaboration

The collaboration involves three parts: the application modules, the track module, and the detection modules.

z The detection modules monitor the link status, network performance and so on, and inform the

track module of the detection result.

Figure

z Upon receiving the detection result, the track module changes the status of the track entry

accordingly and informs the application modules. The track module works between the application modules and the detection modules and is mainly used to obscure the difference of various detection modules to provide a unified interface for application modules.

z The application modules then deal with the changes accordingly based on the status of the track

entry, and thus collaboration is implemented.

Take static routing as an example. You have configured a static route with the next hop 192.168.0.88. If 192.168.0.88 is reachable, the static route is valid; if 192.168.0.88 is unreachable, the static route is invalid. With the collaboration between NQA, track module and application modules, real time monitoring of reachability of the static route can be implemented:

1) Monitor reachability of the destination 192.168.0.88 through NQA.

2) If 192.168.0.88 is detected to be unreachable, NQA will inform the static routing module through track module.

3) The static routing module then can know that the static route is invalid.

For the detailed description of the Track module, see Track Configuration in the High Availability Configuration Guide.

Supporting delivery of traps

You can set whether to send traps to the network management server when an NQA test is performed. When a probe fails or a test is completed, the network management server can be notified, and the network administrator can know the network running statu s and performa nce in time throug h the traps sent.

2-2

Page 23

Basic Concepts of NQA

Test group

Before performing an NQA test, create an NQA test group, and configure NQA test parameters such as test type, destination address and destination port.

Each test group has an administrator name and operation t ag, whi ch can uniq uely define a t est g roup.

Test and probe

After an NQA test is started, one test is performed at a regular interval and you can set the interval as needed.

One NQA test involves multiple consecutive probes and you can set the number of the probes.

Only one probe can be made in one voice test.

In different test types, probe has different meanings:

z For a TCP or DLSw test, one probe means one connection; z For a UDP jitter or a voice test, multiple packets are sent successively in one probe, and the

number of packets sent in one probe depends on the configuration of the probe packet-number command;

z For an FTP, HTTP, DHCP or DNS test, one probe means to carry out a corresponding function; z For an ICMP echo or UDP echo test, one packet is sent in one probe; z For an SNMP test, three packets are sent in one probe.

NQA client and server

NQA client is the device that initiates an NQA test and the NQA test group is created on the NQA client.

NQA server processes the test packets sent from the NQA client, as shown in

Figure 2-2. The NQA

server makes a response to the request sent by the NQA client by listening to the specified destination address and port number.

Figure 2-2 Relationship between the NQA client and NQA server

In most NQA test s, you o nly need to con figure the NQ A client; while in TCP, UDP echo, UDP jitter, and voice tests, you must configure the NQA server.

You can create multiple TCP or UDP listening services on the NQA server, each of which corresponds to a specified destination address and port number. The IP address and port number specified for a listening service on the server must be consistent with those on the client and must be different from those of an existing listening service.

2-3

Page 24

NQA Test Operation

An NQA test operation involves the following steps:

1) The NQA client constructs packets with the specified type, and sends them to the peer device.

2) Upon receiving the packet, the peer device replies with a response with a timestamp.

3) The NQA client computes the packet loss rate and RTT based on whether it has received the

response and the timestamp in the response.

NQA Configuration Task List

To perform TCP, UDP jitter, UDP echo or voice te sts, configure the NQA server on the peer device. Complete the following task to enable the NQA server:

Task Remarks

Configuring the NQA Server

Required for TCP, UDP echo, UDP jitter and voice tests

To perform an NQA test successfully, make the following configurations on the NQA client:

1) Enable the NQA client;

2) Create a test group and configure test parameters according to the test type. The test parameters

may vary with test types;

3) Start the NQA test. To view test results about the test, use the display or debug commands. Complete these tasks to configure NQA client:

Task Remarks

Enabling the NQA Client Required

Creating an NQA Test Group Required

Configuring an NQA Test Group

Configuring an ICMP Echo Test

Configuring a DHCP Test

Required Use any of the approaches

Configuring an FTP Test

Configuring a DNS Test

Configuring an HTTP Test

Configuring a UDP Jitter Test

Configuring an SNMP Test

Configuring a TCP Test

Configuring a UDP Echo Test

Configuring a Voice Test

2-4

Page 25

Task Remarks

Configuring a DLSw Test

Configuring the Collaboration Function Optional

Configuring Trap Delivery Optional

Configuring the NQA Statistics Function Optional

Configuring the History Records Saving Function Optional

Configuring Optional Parameters Common to an NQA Test Group Optional

Scheduling an NQA Test Group Required

Configuring the NQA Server

Before performing TCP, UDP echo, UDP jitter, or voice tests, configure the NQA server on the peer device. The NQA server makes a response to the request sent by the NQA client by listening to the specified destination address and port number.

Follow these steps to configure the NQA server:

To do… Use the command… Remarks

Enter system view

Enable the NQA server

Configure the listening service on the NQA server

system-view

nqa server enable

nqa server { tcp-connect | udp-echo }

port-number

ip-address

—

Required Disabled by default.

Required The IP address and port number

must be consistent with those configured on the NQA client and must be different from those of an existing listening service.

Enabling the NQA Client

Configurations on the NQA client take effect only when the NQA client is enabled. Follow these steps to enable the NQA client:

To do… Use the command… Remarks

Enter system view

Enable the NQA client

system-view

nqa agent enable

2-5

—

Optional Enabled by default.

Page 26

Creating an NQA Test Group

One test corresponds to one test group. You can configure test types after you create a test group and enter the test group view.

Follow theses steps to create an NQA test group:

To do… Use the command… Remarks

Enter system view

Create an NQA test group and enter the NQA test group view

If you execute the nqa entry command to enter the test group view with test type configured, you directly enter the test type view of the test group.

system-view

nqa entry

operation-tag

admin-name

—

Required

Configuring an NQA Test Group

Configuring an ICMP Echo Test

An ICMP echo test is used to test reachability of the destination host according to the ICMP echo reply or timeout information. An ICMP echo test has the same function as the ping command but provides more output information. It enables you to locate connectivity problems in a network.

Follow these steps to configure an ICMP echo test:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as ICMP echo and enter test type view

Configure the destination address for a test operation

system-view

nqa entry

operation-tag

type icmp-echo

destination ip

admin-name

ip-address

—

Required

Required By default, no destination IP

address is configured for a test operation.

Configure the size of probe packets sent

data-size

size

Optional 100 bytes by default.

2-6

Page 27

To do… Use the command… Remarks

Optional

Configure the filler string of a probe packet sent

Specify a VPN instance

Specify the IP address of an interface as the source IP address of an ICMP echo request

data-fill

vpn-instance

source interface

interface-number

string

instance

interface-type

By default, the filler string of a probe packet is the hexadecimal number 00010203040506070809.

Optional Not specified by default.

Optional By default, no interface address is

specified as the source IP address of ICMP probe requests.

If you use the to configure the source IP address of ICMP echo probe requests, the

source interface

invalid. The interface specified by this

command must be up. Otherwise, the probe will fail.

source ip

command is

command

Configure the source IP address of a probe request

Configure the next hop IP address for an ICMP echo request

Configure common optional parameters

source ip

next-hop

See

Parameters Common to an NQA Test Group

ip-address

Configuring Optional

Optional By default, no source IP address is

specified. If no source IP address is

specified, but the source interface is specified, the IP address of the source interface is taken as the source IP address of ICMP probe requests.

The source IP address must be that of an interface on the device and the interface must be up. Otherwise, the probe will fail.

Optional By default, no next hop IP address

is configured.

Optional

2-7

Page 28

Configuring a DHCP Test

A DHCP test is mainly used to test the existence of a DHCP server on the network as well as the time necessary for the DHCP server to respond to a client request and assign an IP address to the client.

Configuration prerequisites

Before performing a DHCP test, configure the DHCP server. If the NQA (DHCP client) and the DHCP server are not in the same network segment, configure a DHCP relay. For the configuration of DHCP server and DHCP relay, see DHCP Server Configuration and DHCP Relay Agent Configuration in the Layer 3 - IP Services Configuration Guide.

Configuring a DHCP test

Follow these steps to configure a DHCP test:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as DHCP and enter test type view

Specify an interface for a DHCP test

Configure common optional parameters

system-view

nqa entry

operation-tag

type dhcp

operation interface

interface-number

Configuring Optional

See

Parameters Common to an NQA Test Group

admin-name

interface-type

—

Required

Required By default, no interface is specified

to perform a DHCP test. The interface specified by the

source interface

be up; otherwise, the test fails.

Optional

command must

z Because a DHCP test is a process to simulate address allocation in DHCP, the IP address of the

interface that performs the DHCP test does not change.

z When the DHCP test is completed, the NQA client sends a DHCP-RELEASE packet to release

the obtained IP address.

Configuring a DNS Test

A DNS test is mainly used to test whether the NQA client can resolve a domain name into an IP address through a DNS server and the time required for resolution.

2-8

Page 29

Configuration prerequisites

Before performing a DNS test, configure the mapping between a domain name and an IP address on a DNS server.

Configuring a DNS test

Follow these steps to configure a DNS test:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as DNS and enter test type view

Specify a destination address for a DNS test

Configure the domain name

Configure optional parameters common to an NQA test group

system-view

nqa entry

type dns

destination ip

resolve-target

See Configuring Optional Parameters

Common to an NQA Test Group

admin-name operation-tag

ip-address

domain-name

—

Required

Required By default, no destination IP

address is configured for a test operation.

The destination IP address must be the IP address of the DNS server.

Required By default, no domain name is

configured for a DNS test.

Optional

Because a DNS test is a process to simulate the domain name resolution, the mapping between the domain name and the IP address is not saved.

Configuring an FTP Test

An FTP test is mainly used to test the connection between the NQA client and a specified FTP server and the time necessary for the FTP client to transfer a file to or download a file from the FTP server.

Configuration prerequisites

Before an FTP test, perform some configurations on the FTP server. For example, configure the username and password that are used to log in to the FTP server. For more information about FTP server configuration, see FTP Configuration in the Fun dam ent als Configuration Guide.

Configuring an FTP test

Follow these steps to configure an FTP test:

2-9

Page 30

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as FTP and enter test type view

Configure the destination address for a test operation

Configure the source IP address of a probe request

system-view

nqa entry

operation-tag

type ftp

destination ip

source ip

admin-name

ip-address

—

Required

Required By default, no destination IP

address is configured for a test operation.

The destination IP address for a test operation is the IP address of the FTP server.

Required By default, no source IP address is

specified. The source IP address must be

that of an interface on the device and the interface must be up. Otherwise, the test will fail.

Configure the operation type

Configure a login username

Configure a login password

Specify a file to be transferred between the FTP server and the FTP client

Configure common optional parameters

operation { get | put }

username

password

filename

See

Parameters Common to an NQA Test Group

name

password

file-name

Configuring Optional

Optional By default, the operation type for

the FTP is obtaining files from the FTP server.

Required By default, no login username is

configured.

Required By default, no login password is

configured.

Required By default, no file is specified.

Optional

get

, which means

2-10

Page 31

z When you execute the put command, a file file-name with fixed size and content is created on the

FTP server. When you execute the get command, the device does not save the files obtained from the FTP server.

z When you execute the get command, the FTP test cannot succeed if a file named file-name does

not exist on the FTP server.

z When you execute the get command, use a file with a smaller size because a big file may result in

test failure due to timeout, or may affect other services because of occupying too much network bandwidth.

Configuring an HTTP Test

An HTTP test is used to test the connection between the NQA client and a specified HTTP server and the time required to obtain data from the HTTP server, thus detecting the connectivity and performance of the HTTP server.

Configuration prerequisites

Before performing an HTTP test, configure the HTTP serve r.

Configuring an HTTP test

Follow these steps to configure an HTTP test:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as HTTP and enter test type view

Configure the destination address for a test operation

system-view

nqa entry

operation-tag

type http

destination ip

admin-name

ip-address

—

Required

Required By default, no destination IP

address is configured for a test operation.

The destination IP address for a test operation is the IP address of the HTTP server.

2-11

Page 32

To do… Use the command… Remarks

Optional By default, no source IP address is

Configure the source IP address of a probe request

Configure the operation type

source ip

operation

ip-address

get

post

{

}

specified. The source IP address must be

that of an interface on the device and the interface must be up. Otherwise, the test will fail.

Optional By default, the operation type for

the HTTP is obtaining data from the HTTP server.

get

, which means

Configure the website that an HTTP test visits

Configure the HTTP version used in the HTTP test

Configure common optional parameters

The TCP port number for the HTTP server must be 80 in an HTTP test. Otherwise, the test will fail.

Configuring a UDP Jitter Test

url

http-version v1.0

Configuring Optional

See

Parameters Common to an NQA Test Group

Required

Optional By default, HTTP 1.0 is used in an

HTTP test.

Optional

It is recommended not to perform an NQA UDP jitter test on known ports, namely, ports from 1 to 1023. Otherwise, the NQA test will fail or the corresponding services of this port will be unavailable.

Real-time services such as voice and video have high requirements on delay jitters. With the UDP jitter test, uni/bi-directional delay jitters can be obtained to judge whether a network can carry real-time services.

2-12

Page 33

Delay jitter refers to the difference between the interval of receiving two packet s consecutively and the interval of sending these two packets. The procedure of a UDP jitter test is as follows:

z The source sends packets at regular intervals to the destination port. z The destination affixes a time stamp to each packet that it receives and then sends it back to the

source.

z Upon receiving the packet, the source calculates the delay jitter, and the network status can be

analyzed.

Configuration prerequisites

A UDP jitter test requires cooperation between the NQA server and the NQA client. Before the UDP jitter test, make sure that the UDP listening function is configured on the NQA server. For the configuration of the UDP listening function, see

Configuring a UDP jitter test

Follow these steps to configure a UDP jitter test:

To do… Use the command… Remarks

Configuring the NQA Server.

Enter system view

Enter NQA test group view

Configure the test type as UDP jitter and enter test type view

Configure the destination address for a test operation

Configure the destination port for a test operation

system-view

nqa entry

operation-tag

type udp-jitter

destination ip

destination port

admin-name

ip-address

port-number

—

Required

Required By default, no destination IP

address is configured for a test operation.

The destination IP address must be consistent with that of the existing listening service on the NQA server.

Required By default, no destination port

number is configured for a test operation.

The destination port must be consistent with that of the existing listening service on the NQA server.

Specify the source port number for a request

source port

port-number

2-13

Optional By default, no source port number

is specified.

Page 34

To do… Use the command… Remarks

Configure the size of a probe packet sent

Configure the filler string of a probe packet sent

Configure the number of packets sent in a UDP jitter probe

Configure the interval for sending packets in a UDP jitter probe

Configure the time for waiting for a response in a UDP jitter test

Configure the source IP address of a probe request in a test operation

data-size

data-fill

probe packet-number

packet-number

probe packet-interval

packet-interval

probe packet-timeout

packet-timeout

source ip

size

string

ip-address

Optional 100 bytes by default.

Optional By default, the filler string of a

probe packet is the hexadecimal number 00010203040506070809.

Optional 10 by default.

Optional 20 milliseconds by default.

Optional 3000 milliseconds by default.

Optional By default, no source IP address is

specified. The source IP address must be

that of an interface on the device and the interface must be up. Otherwise, the test will fail.

Configure common optional parameters

The number of probes made in a UDP jitter test depends on the probe count command. The number of probe packets sent in each probe depends on the configuration of the probe packet-number command.

Configuring an SNMP Test

An SNMP query test is used to test the time the NQA client takes to send an SNMP query packet to the SNMP agent and then receive a response packet.

Configuring Optional

See

Parameters Common to an NQA Test Group

Optional

2-14

Page 35

Configuration prerequisites

The SNMP agent function must be enabled on the device that serves as an SNMP agent before an SNMP test. For the configuration of SNMP agent, see SNMP Configuration in the Network Management and Monitoring Configuration Guide.

Configuring an SNMP test

Follow these steps to configure an SNMP test:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as SNMP and enter test type view

Configure the destination address for a test operation

Specify the source port number for a probe request in a test operation

Configure the source IP address of a probe request in a test operation

system-view

nqa entry

operation-tag

type snmp

destination ip

source port

source ip

admin-name

ip-address

port-number

—

Required

Required By default, no destination IP

address is configured for a test operation.

Optional By default, no source port number

is specified.

Optional By default, no source IP address is

specified. The source IP address must be

that of an interface on the device and the interface must be up. Otherwise, the test will fail.

Configure common optional parameters

Configuring a TCP Test

A TCP test is used to test the TCP connection between the client and the specified port on the NQA server and the setup time for the connection, thus judging the availability and performance of the services provided on the specified port on the server.

Configuration prerequisites

A TCP test requires cooperation between the NQA server and the NQA client. Configure the TCP listening function on the NQA server before the TCP test. For the configuration of the TCP listening function, see

Configuring the NQA Server.

Configuring Optional

See

Parameters Common to an NQA Test Group

2-15

Optional

Page 36

Configuring a TCP test

Follow these steps to configure a TCP test:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as TCP and enter test type view

Configure the destination address for a test operation

Configure the destination port

system-view

nqa entry

operation-tag

type tcp

destination ip

destination port

admin-name

ip-address

port-number

—

Required

Required By default, no destination IP

address is configured for a test operation.

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

Required By default, no destination port

number is configured for a test operation.

The destination port number must be consistent with port number of the listening service configured on the NQA server.

Configure the source IP address of a probe request in a test operation

Configure common optional parameters

Configuring a UDP Echo Test

A UDP echo test is used to test the connectivity and round-trip time of a UDP echo packet from the client to the specified UDP port on the NQA server.

source ip

See

Parameters Common to an NQA Test Group

ip-address

Configuring Optional

2-16

Optional By default, no source IP address is

specified. The source IP address must be

that of an interface on the device and the interface must be up. Otherwise, the test will fail.

Optional

Page 37

Configuration prerequisites

A UDP echo test requires cooperation between the NQA server and the NQA client. Configure the UDP listening function on the NQA server before the UDP echo test. For the configuration of the UDP listening function, see

Configuring a UDP echo test

Follow these steps to configure a UDP e cho te st

To do… Use the command… Remarks

Configuring the NQA Server.

Enter system view

Enter NQA test group view

Configure the test type as UDP echo and enter test type view

Configure the destination address for a test operation

Configure the destination port

system-view

nqa entry

operation-tag

type udp-echo

destination ip

destination port

admin-name

ip-address

port-number

—

Required

Required By default, no destination IP

address is configured for a test operation.

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

Required By default, no destination port

number is configured for a test operation.

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

Configure the size of probe packets sent

Configure the filler string of a probe packet sent

Specify a source port number for a probe request in a test operation

data-size

data-fill

source port

size

string

port-number

2-17

Optional 100 bytes by default.

Optional By default, the filler string of a probe

packet is the hexadecimal number

00010203040506070809.

Optional By default, no source port number is

specified.

Page 38

To do… Use the command… Remarks

Configure the source IP address of a probe request in a test operation

Configure common optional parameters

Configuring a Voice Test

source ip

See

Parameters Common to an NQA Test Group

ip-address

Configuring Optional

Optional By default, no source IP address is

specified. The source IP address must be that

of an interface on the device and the interface must be up. Otherwise, the test will fail.

Optional

It is recommended not to perform an NQA UDP jitter test on known ports, namely, ports from 1 to 1023. Otherwise, the NQA test will fail or the corresponding services of these ports will be unavailable.

A voice test is used to test voice over IP (VoIP) network status, and collect VoIP network parameters so that users can adjust the network according the network status. The procedure of a voice test is as follows:

1) The source (NQA client) sends voice packets of G.711 A-law, G.711 µ-law or G.729 A-law codec

type at regular intervals to the destination (NQA server).

2) The destination affixes a time stamp to each packet that it receives and then sends it back to the

source.

3) Upon receiving the packets, the source calculates the delay jitter and delay by calculating the

difference between the interval for the destination to receive two successive packets and the interval for the source to send these two successive packets, and thus the network status can be analyzed.

The voice parameter values that indicate VoIP network status can also be calculated in a voice test, including:

z Calculated Planning Impairment Factor (ICPIF): Measures attenuation of voice data in a network,

depending on packet loss and delay. A higher value represents a lower network quality.

z Mean Opinion Scores (MOS): Measures quality of a VoIP network. A MOS value can be

evaluated by using the ICPIF value, in the range 1 to 5. A higher value represents a highe r quality of a VoIP network.

The evaluation of voice quality depends on users’ tolerance to voice quality, which should be taken into consideration. For users with higher tolerance to voice quality, use the advantage-factor

2-18

Page 39

command to configure the advantage factor. When the system calculates the ICPIF value, this advantage factor is subtracted to modify ICPIF and MOS values and thus both the objective and subjective factors are considered when you evaluate the voice quality.

Configuration prerequisites

A voice test requires cooperation between the NQA server and the NQA client. Before a voice test, make sure that the UDP listening function is configured on the NQA server. For the configuration of UDP listening function, see

Configuring a voice test

Follow these steps to configure a voice test:

To do… Use the command… Remarks

Configuring the NQA Server.

Enter system view

Enter NQA test group view

Configure the test type as voice and enter test type view

Configure the destination address for a test operation

Configure the destination port for a test operation

system-view

nqa entry

operation-tag

type voice

destination ip

destination port

admin-name

ip-address

port-number

—

Required

Required By default, no destination IP address

is configured for a test operation. The destination IP address must be

consistent with that of the existing listening service on the NQA server.

Required By default, no destination port number

is configured for a test operation. The destination port must be

consistent with that of the existing listening service on the NQA server.

Configure the codec type

Configure the advantage factor for calculating MOS and ICPIF values

codec-type { g711a g729a }

advantage-factor

2-19

g711u |

factor

Optional By default, the codec type is G.711

A-law.

Optional By default, the advantage factor is 0.

Page 40

To do… Use the command… Remarks

Optional By default, no source IP address is

Specify the source IP address for the requests in a test operation

source ip

ip-address

specified. The source IP address must be that of

an interface on the device and the interface must be up. Otherwise, the test will fail.

Specify the source port number for the requests in a test operation

Configure the size of a probe packet to be sent

Configure the filler string of a probe packet sent

Configure the number of packets sent in a voice probe

source port

data-size

data-fill

probe packet-number

packet-number

port-number

size

string

Optional By default, no source port number is

specified.

Optional By default, the probe packet size

depends on the codec type. The default packet size is 172 bytes for G.711A-law and G.711 µ-law codec type, and is 32 bytes for G.729 A-law codec type.

Optional By default, the filler string of a probe

packet is the hexadecimal number

00010203040506070809.

Optional 1000 by default.

Configure the interval for sending packets in a voice probe

Configure the timeout for waiting for a response in a voice test

Configure common optional parameters

probe packet-interval

packet-interval

probe packet-timeout

packet-timeout

Configuring Optional

See

Parameters Common to an NQA Test Group

Optional 20 milliseconds by default.

Optional 5000 milliseconds by default.

Optional

Only one probe can be made in one voice test, and the number of probe packets sent in each probe depends on the configuration of the probe packet-number command.

2-20

Page 41

Configuring a DLSw Test

A DLSw test is used to test the response time of the DLSw device.

Configuration prerequisites

Enable the DLSw function on the peer device before DLSw test.

Configuring a DLSw test

Follow these steps to configure a DLSw test:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Configure the test type as DLSw and enter test type view

Configure the destination address for a test operation

Configure the source IP address of a probe request in a test operation

system-view

nqa entry

operation-tag

type dlsw

destination ip

source ip

admin-name

ip-address

—

Required

Required By default, no destination IP

address is configured for a test operation.

Optional By default, no source IP address is

specified. The source IP address must be

that of an interface on the device and the interface must be up. Otherwise, the test will fail.

Configuring Optional

Configure common optional parameters

See

Parameters Common to an NQA Test Group

Configuring the Collaboration Function

Collaboration is implemented by establishing collaboration entries to monitor the detection results of the current test group. If the number of consecutive probe failures reaches the threshold, the configured action is triggered.

Follow these steps to configure the collaboration function:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

system-view

nqa entry

operation-tag

admin-name

2-21

Optional

—

Page 42

To do… Use the command… Remarks

Enter test type view of the test group

Create a collaboration entry

Exit to system view

Create a track entry and associate it with the specified collaboration entry of the NQA test group

type

dhcp

dlsw

dns

{

http

icmp-echo

udp-echo }

reaction checked-element probe-fail threshold-type consecutive

occurrences [

trigger-only

quit

track

admin-name operation-tag

reaction

item-num

entry-number

item-num

action-type

} ]

ftp

snmp

tcp

{

nqa entry

none

The collaboration function is not supported in UDP jitter and voice

tests.

Required Not created by default.

—

Required Not created by default.

z You cannot modify the content of a reaction entry using the reaction command after the

collaboration entry is created.

z The collaboration function is not supported in a UDP jitter or voice test.

Configuring Trap Delivery

Traps can be sent to the network management server when test is completed, test fails or probe fails.

Configuration prerequisites

Before configuring trap delivery, you need to configure the destination address of the trap message with the snmp-agent target-host command, create an NQA test group, and configure related parameters. For the introduction to the snmp-agent target-host command, refer to SNMP Configuration Commands in the Network Management and Monitoring Command Reference.

Configuring trap delivery

Follow these steps to configure trap delivery:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

system-view

nqa entry

admin-name operation-tag

—

Enter test type view of the test group

type snmp

{

dhcp

dlsw

tcp

udp-echo | udp-jitter

2-22

dns

ftp

http

icmp-echo

voice }

—

Page 43

To do… Use the command… Remarks

Optional

Configure to send traps to network management server under specified conditions

reaction trap { probe-failure

consecutive-probe-failures |

test-failure

cumulate-probe-failures }

Only the reaction trap test-complete command is supported in a voice test, namely, in a voice test, traps are sent to the NMS only if the test succeeds.

Configuring the NQA Statistics Function

NQA puts the NQA tests completed in a specified interval into one group, and calculates the statistics of the test results of the group. These statistics form a statistics group. To view information of the statistics group, use the display nqa statistics command. To set the interval for collecting statistics, use the statistics interval command.

test-complete

No traps are sent to

the network management server by default.

When the number of statistics groups kept reaches the upper limit, if a new statistics group is generated, the statistics group that is kept for the longest time is deleted. To set the maximum number of statistics groups that can be kept, use the statistics max-group command.

A statistics group is formed after the last test is completed within the specified interval. A statistics group has the aging mechanism. A st atistics group will be deleted af ter it is kept for a period of time. To set the hold time of a statistics group, use the statistics hold-time command.

Follow these steps to configure the NQA statistics function:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Enter test type view of the test group

Configure the interval for collecting the statistics of the test results

system-view

nqa entry

operation-tag

type

{

icmp-echo udp-echo | udp-jitter

statistics interval

admin-name

dlsw

dns

snmp

ftp

interval

http

tcp

voice }

—

Optional 60 minutes by default.

2-23

Page 44

To do… Use the command… Remarks

Optional

Configure the maximum number of statistics groups that can be kept

Configure the hold time of a statistics group

statistics max-group

statistics hold-time

number

hold-time

2 by default. If the maximum number is 0, it

indicates that no statistics is performed.

Optional 120 minutes by default.

z The NQA statistics function is not supported in a DHCP test. z If you specify the interval argument in the frequency interval command as 0, no statistics group

information is generated.

Configuring the History Records Saving Function

With the history records saving function enabled, the system saves the history records of the NQA test. To view the history records of a test group, use the display nqa history command.

The configuration task also allows you to configure:

z Lifetime of the history records: The records are removed when the lifetime is reached. z The maximum number of history records that can be saved in a test group: If the number of

history records in a test group exceeds the maximum number, the earliest history records are removed.

Follow these steps to configure the history records saving function of an NQA test group:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Enter NQA test type view

Enable the saving of the history records of the NQA test group

system-view

nqa entry

type icmp-echo udp-jitter

history-record enable

admin-name operation-tag

dhcp

dlsw

{

snmp

voice }

| |

dns

tcp

ftp

http

udp-echo |

—

Required By default, history records of

the NQA test group are not saved.

2-24

Page 45

To do… Use the command… Remarks

Set the lifetime of the history records in an NQA test group

Configure the maximum number of history records that can be saved in a test group

history-record keep-time

history-record number

number

keep-time

Optional By default, the history records

in the NQA test group are kept for 120 minutes.

Optional By default, the maximum

number of records that can be saved in a test group is 50

Configuring Optional Parameters Common to an NQA Test Group

Optional parameters common to an NQA test group are valid only for tests in this test group. Unless otherwise specified, the following parameters are applicable to all test types and they can be

configured according to the actual conditions. Follow these steps to configure optional parameters common to an NQA test group:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

Enter test type view of a test group

Configure the descriptive string for a test group

Configure the interval between two consecutive tests for a test group

system-view

nqa entry

operation-tag

type

{

http

icmp-echo

udp-echo | udp-jitter

description

frequency

admin-name

dhcp

dlsw | dns

text

interval

snmp

voice }

ftp

tcp

—

Optional By default, no descriptive string is

available for a test group.

Optional By default, the interval between

two consecutive tests for a test group is 0 milliseconds, that is, only one test is performed.

If the last test is not completed when the interval specified by the

frequency

new test is not started.

command is reached, a

2-25

Page 46

To do… Use the command… Remarks

Optional By default, one probe is performed

Configure the number of probes in an NQA test

probe count

times

in a test. Only one probe can be made in

one voice test. Therefore, this command is not available in a voice test.

Optional

Configure the NQA probe timeout time

Configure the maximum number of hops a probe packet traverses in the network

Configure the ToS field in an IP packet header in an NQA probe packet

Enable the routing table bypass function

probe timeout

ttl

value

tos

value

route-option bypass-route

timeout

By default, the timeout time is 3000 milliseconds.

This parameter is not available for a UDP jitter test.

Optional 20 by default. This parameter is not available for

a DHCP test.

Optional 0 by default. This parameter is not available for

a DHCP test.

Optional Disabled by default. This parameter is not available for

a DHCP test.

Scheduling an NQA Test Group

By configuring NQA test group scheduli ng, you can set the start time and test duration for a test group to perform NQA tests. The start time can take a specific value or can be now, which indicates that a test is started immediately; the test duration can take a specific value or can be forever, which indicates that a test does not stop until you use the undo nqa schedule command to stop the test.

A test group perfo rms tests when the system time is between the start time and the end time (the start time plus test duration). If the system time is behind the start time when you execute the nqa schedule command, a test is started when the system time reaches the start time. If the system time is between the start time and the end time, a test is started at once. If the system time is ahead of the end time, no test is started. To view the current system time, use the display clock command.

2-26

Page 47

Configuration prerequisites

Before scheduling an NQA test group, make sure:

z Required test parameters corresponding to a test type have been configured; z For a test that needs the cooperation with the NQA server, configuration on the NQA server has

been completed.

Scheduling an NQA test group

Follow these steps to schedule an NQA test group:

To do… Use the command… Remarks

Enter system view

Schedule an NQA test group

Configure the maximum number of tests that the NQA client can simultaneously perform

system-view

nqa schedule start-time { lifetime {

nqa agent max-concurrent

admin-name operation-tag

hh:mm:ss [ yyyy/mm/dd ] |

lifetime |

forever }

number

now }

—

Required

Optional 2 by default.

z After an NQA test group is scheduled, you cannot enter the test group view or test type view. z A started test group or a test group that has completed tests will not be influenced by the system

time change; only a test group that is waiting to perform tests will be influenced by the system time change.

Displaying and Maintaining NQA

To do… Use the command… Remarks

Display history records of NQA test operation information

Display the results of the last NQA test

Display the statistics of a type of NQA test

Display NQA server status

display nqa history

operation-tag ]

display nqa result

operation-tag ]

display nqa statistics

operation-tag ]

display nqa server status

[ admin-name

Available in any view

[ admin-name

2-27

Page 48

NQA Configuration Examples

ICMP Echo Test Configuration Example

Network requirements

As shown in Figure 2-3, use the NQA ICMP function to test whether the NQA client (Device A) can send packets to the specified destination (Device B) and test the round-trip time of packets.

Figure 2-3 Network diagram for ICMP echo tests

Configuration procedure

# Create an ICMP echo test group and configure related test p arameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type icmp-echo [DeviceA-nqa-admin-test-icmp-echo] destination ip 10.2.2.2

# Configure optional parameters.

[DeviceA-nqa-admin-test-icmp-echo] probe count 10 [DeviceA-nqa-admin-test-icmp-echo] probe timeout 500 [DeviceA-nqa-admin-test-icmp-echo] frequency 5000

# Enable the saving of history records.

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

# Enable ICMP echo test.

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

# Disable ICMP echo test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last ICMP echo test.

2-28

Page 49

Packet(s) arrived late: 0

# Display the history of ICMP echo tests.

[DeviceA] display nqa history admin test NQA entry (admin admin, tag test) history record(s): 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

DHCP Test Configuration Example

Network requirements

Use the NQA DHCP function to test the time necessary for Switch A to obtain an IP address from the DHCP server Switch B.

Figure 2-4 Network diagram for DHCP test

Configuration procedure

# Create a DHCP test group and configure related test parameters.

<SwitchA> system-view [SwitchA] nqa entry admin test [SwitchA-nqa-admin-test] type dhcp [SwitchA-nqa-admin-test-dhcp] operation interface vlan-interface 2

# Enable the saving of history records.

[SwitchA-nqa-admin-test-dhcp] history-record enable [SwitchA-nqa-admin-test-dhcp] quit

# Enable DHCP test.

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

# Disable DHCP test after the test begins for a period of time.

[SwitchA] undo nqa schedule admin test

# Display the result of the last DHCP test.

[SwitchA] display nqa result admin test NQA entry(admin admin, tag test) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 624/624/624 Square-Sum of round trip time: 389376 Last succeeded probe time: 2007-11-22 09:56:03.2

2-29

Page 50

Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0

# Display the history of DHCP tests.

[SwitchA] display nqa history admin test NQA entry(admin admin, tag test) history record(s): Index Response Status Time 1 624 Succeeded 2007-11-22 09:56:03.2

DNS Test Configuration Example

Network requirements

As shown in Figure 2-5, use the DNS function to test whether Device A can resolve the domain name

host.com into an IP address through the DNS server and test the time required for resolution. Figure 2-5 Network diagram for DNS tests

Configuration procedure

# Create a DNS test group and configure related test parameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type dns [DeviceA-nqa-admin-test-dns] destination ip 10.2.2.2 [DeviceA-nqa-admin-test-dns] resolve-target host.com

# Enable the saving of history records.

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

# Enable DNS test.

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

# Disable DNS test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last DNS test.

2-30

Page 51

Last succeeded probe time: 2008-11-10 10:49:37.3 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0

# Display the history of DNS tests.

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

FTP Test Configuration Example

Network requirements

As shown in Figure 2-6, use the NQA FTP function to test the connection with a specified FTP server and the time necessary for Device A to upload a file to the FTP server. The login username is admin, the login password is systemtest, and the file to be transferred to the FTP server is config.txt.

Figure 2-6 Network diagram for FTP tests

Configuration procedure

# Create an FTP test group and configure related test parameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type ftp [DeviceA-nqa-admin-test-ftp] destination ip 10.2.2.2 [DeviceA-nqa-admin-test-ftp] source ip 10.1.1.1 [DeviceA-nqa-admin-test-ftp] operation put [DeviceA-nqa-admin-test-ftp] username admin [DeviceA-nqa-admin-test-ftp] password systemtest [DeviceA-nqa-admin-test-ftp] filename config.txt

# Enable the saving of history records.

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

# Enable FTP test.

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

# Disable FTP test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last FTP test.

2-31

Page 52

[DeviceA] display nqa result admin test NQA entry(admin admin, tag test) test results: Destination IP address: 10.2.2.2 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: 2007-11-22 10:07:28.6 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0

# Display the history of FTP tests.

[DeviceA] display nqa history admin test NQA entry (admin admin, tag test) history record(s): Index Response Status Time 1 173 Succeeded 2007-11-22 10:07:28.6

HTTP Test Configuration Example

Network requirements

As shown in Figure 2-7, use the HTTP function to test the connection with a specified HTTP server and the time required to obtain data from the HTTP server.

Figure 2-7 Network diagram for the HTTP tests

Configuration procedure

# Create an HTTP test group and configure related test pa rameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type http [DeviceA-nqa-admin-test-http] destination ip 10.2.2.2 [DeviceA-nqa-admin-test-http] operation get [DeviceA-nqa-admin-test-http] url /index.htm [DeviceA-nqa-admin-test-http] http-version v1.0

# Enable the saving of history records.

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

# Enable HTTP test.

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

2-32

Page 53

# Disable HTTP test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last HTTP test.

[DeviceA] display nqa result admin test NQA entry(admin admin, tag test) test results: Destination IP address: 10.2.2.2 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: 2007-11-22 10:12:47.9 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0

Failures due to internal error: 0 Failures due to other errors: Packet(s) arrived late: 0

# Display the history of HTTP tests.

[DeviceA] display nqa history admin test NQA entry (admin admin, tag test) history record(s): Index Response Status Time 1 64 Succeeded 2007-11-22 10:12:47.9

UDP Jitter Test Configuration Example

Network requirements

As shown in Figure 2-8, use the NQA UDP jitter function to test the delay jitter of packet transmission between Device A and Device B.

Figure 2-8 Network diagram for UDP jitter tests

Configuration procedure

1) Configure Device B # Enable the NQA server a nd configu re the listeni ng I P address as 10.2.2.2 and port number as 9000.

<DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo 10.2.2.2 9000

2) Configure Device A # Create a UDP jitter test group and configure related test p arameters.

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

2-33

Page 54

[DeviceA-nqa-admin-test-udp-jitter] destination ip 10.2.2.2 [DeviceA-nqa-admin-test-udp-jitter] destination port 9000 [DeviceA-nqa-admin-test-udp-jitter] frequency 1000 [DeviceA-nqa-admin-test-udp-jitter] quit

# Enable UDP jitter test.

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

# Disable UDP jitter test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last UDP jitter test.

[DeviceA] display nqa result admin test NQA entry(admin admin, tag test) test results: Destination IP address: 10.2.2.2 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 succeeded probe time: 2008-05-29 13:56:17.6 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) 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 packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0

# Display the statistics of UDP jitter tests.

[DeviceA] display nqa statistics admin test NQA entry (admin admin, tag test) test statistics:

2-34

Page 55

NO. : 1 Destination IP address: 10.2.2.2 Start time: 2008-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 lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) 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 packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0

The display nqa history command does not show the results of UDP jitter tests. Therefore, to know the result of a UDP jitter test, you are recommended to use the display nqa result command to view the probe results of the latest NQA test, or use the display nqa statistics command to view the statistics of NQA tests.

2-35

Page 56

SNMP Test Configuration Example

Network requirements

As shown in Figure 2-9, use the NQA SNMP query function to test the time it takes for Device A to send an SNMP query packet to the SNMP agent and receive a response packet.

Figure 2-9 Network diagram for SNMP tests

Configuration procedure

1) Configurations on SNMP agent # Enable the SNMP agent service and set the SNMP version to all, the read community to public, and

the write community to private.

<DeviceB> system-view [DeviceB] snmp-agent sys-info version all [DeviceB] snmp-agent community read public [DeviceB] snmp-agent community write private

2) Configurations on Device A # Create an SNMP query test group and configure related test parameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type snmp [DeviceA-nqa-admin-test-snmp] destination ip 10.2.2.2

# Enable the saving of history records.

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

# Enable SNMP query test.

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

# Disable SNMP query test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last SNMP test.

[DeviceA] display nqa result admin test NQA entry (admin admin, tag test) test results: Destination IP address: 10.2.2.2 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: 2007-11-22 10:24:41.1 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0

2-36

Page 57

Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0

# Display the history of SNMP tests.

[DeviceA] display nqa history admin test NQA entry (admin admin, tag test) history record(s): Index Response Status Time 1 50 Timeout 2007-11-22 10:24:41.1

TCP Test Configuration Example

Network requirements

As shown in Figure 2-10, use the NQA TCP function to test the time for establishing a TCP conne ction between Device A and Device B. Port 9000 is used.

Figure 2-10 Network diagram for TCP tests

Configuration procedure

1) Configure Device B # Enable the NQA server a nd configu re the listeni ng I P address as 10.2.2.2 and port number as 9000.

<DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server tcp-connect 10.2.2.2 9000

2) Configure Device A # Create a TCP test group and configure related test parameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type tcp [DeviceA-nqa-admin-test-tcp] destination ip 10.2.2.2 [DeviceA-nqa-admin-test-tcp] destination port 9000

# Enable the saving of history records.

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

# Enable TCP test.

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

# Disable TCP test after the test begin s for a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last TCP test.

2-37

Page 58

Last succeeded probe time: 2007-11-22 10:27:25.1 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0

# Display the history of TCP tests.

[DeviceA] display nqa history admin test NQA entry (admin admin, tag test) history record(s):

Index Response Status Time 1 13 Succeeded 2007-11-22 10:27:25.1

UDP Echo Test Configuration Example

Network requirements

As shown in Figure 2-1 1, use the NQA UDP echo function to test the round-trip time between Device A and Device B. The port number is 8000.

Figure 2-11 Network diagram for the UDP echo tests

Configuration procedure

1) Configure Device B # Enable the NQA server a nd configu re the listeni ng I P address as 10.2.2.2 and port number as 8000.

<DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo 10.2.2.2 8000

2) Configure Device A # Create a UDP echo test group and configure related test parameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type udp-echo [DeviceA-nqa-admin-test-udp-echo] destination ip 10.2.2.2 [DeviceA-nqa-admin-test-udp-echo] destination port 8000

# Enable the saving of history records.

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

# Enable UDP echo test.

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

# Disable UDP echo test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

2-38

Page 59

# Display results of the last UDP echo test.

[DeviceA] display nqa result admin test NQA entry (admin admin, tag test) test results: Destination IP address: 10.2.2.2 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: 2007-11-22 10:36:17.9 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0

# Display the history of UDP echo tests.

[DeviceA] display nqa history admin test NQA entry (admin admin, tag test) history record(s): Index Response Status Time 1 25 Succeeded 2007-11-22 10:36:17.9

Voice Test Configuration Example

Network requirements

As shown in Figure 2-12, use the NQA voice function to test the delay jitter of voice packet transmission and voice quality between Device A and Device B.

Figure 2-12 Network diagram for voice tests

Configuration procedure

1) Configure Device B # Enable the NQA server a nd configu re the listeni ng I P address as 10.2.2.2 and port number as 9000.

<DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo 10.2.2.2 9000

2) Configure Device A # Create a voice test group and configure related test parameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type voice [DeviceA-nqa-admin-test-voice] destination ip 10.2.2.2 [DeviceA-nqa-admin-test-voice] destination port 9000

2-39

Page 60

[DeviceA-nqa-admin-test-voice] quit

# Enable voice test.

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

# Disable the voice test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last voice test.

[DeviceA] display nqa result admin test NQA entry (admin admin, tag test) test results: Destination IP address: 10.2.2.2 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 succeeded probe time: 2008-06-13 09:49:31.1 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) 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 packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0 Voice scores: MOS value: 4.38 ICPIF value: 0

# Display the statistics of voice tests.

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

2-40

Page 61

Destination IP address: 10.2.2.2 Start time: 2008-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 lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) 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 packet(s): 0 DS lost packet(s): 0 Lost packet(s) for unknown reason: 0 Voice scores: Max MOS value: 4.38 Min MOS value: 4.38 Max ICPIF value: 0 Min ICPIF value: 0

The display nqa history command cannot show you the results of voice tests. Therefore, to know the result of a voice test, you are recommended to use the display nqa result command to view the probe results of the latest NQA test, or use the display nqa statistics command to view the statistics of NQA tests.

2-41

Page 62

DLSw Test Configuration Example

Network requirements

As shown in Figure 2-13, use the NQA DLSw function to test the response time of the DLSw device.

Figure 2-13 Network diagram for the DLSw tests

Configuration procedure

# Create a DLSw test group and configure related test parameters.

<DeviceA> system-view [DeviceA] nqa entry admin test [DeviceA-nqa-admin-test] type dlsw [DeviceA-nqa-admin-test-dlsw] destination ip 10.2.2.2

# Enable the saving of history records.

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

# Enable DLSw test.

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

# Disable DLSw test after the test begins for a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last DLSw test.

[DeviceA] display nqa result admin test NQA entry (admin admin, tag test) test results: Destination IP address: 10.2.2.2 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: 2007-11-22 10:40:27.7 Extended results: Packet lost in test: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to sequence error: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packet(s) arrived late: 0

# Display the history of DLSw tests.

[DeviceA] display nqa history admin test NQA entry (admin admin, tag test) history record(s): Index Response Status Time 1 19 Succeeded 2007-11-22 10:40:27.7

2-42

Page 63

NQA Collaboration Configuration Example

Network requirements

As shown in Figure 2-14, configure a static route to Switch C on Switch A, with Switch B as the next hop. Associate the static route, track entry, and NQA test group to verify whether static route is active in real time.

Figure 2-14 Network diagram for NQA collaboration configuration example

Switch B

Vlan-int3

10.2.1.1/24

Vlan-int3

10.2.1.2/24

Switch A

Vlan-int2

10.1.1.1/24

Vlan-int2

10.1.1.2/24

Switch C

Configuration procedure

1) Assign each interface an IP address. (omitted)

2) On Switch A, configure a unicast static route and associate the static route with a track entry. # Configure a static route, whose destination address is 10.2.1.1, 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, create an NQA test group. # Create an NQA test group with the administrator name being admin and operation tag being test.

[SwitchA] nqa entry admin test

# Configure the test type of the NQA test group as ICMP echo.

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

# Configure the destination IP address of the ICMP echo test operation as 10.2.1.1.

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

# Configure the interval between two consecutive tests as 100 millise conds.

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

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

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

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

# Configure the test start time and test duration for the test group.

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

4) On Switch A, create the track entry. # Create track entry 1 to associate it with Reaction entry 1 of the NQA test group (admin-test).

[SwitchA] track 1 nqa entry admin test reaction 1

5) Verify the configuration.

2-43

Page 64

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

[SwitchA] display track all Track ID: 1 Status: Positive Notification delay: Positive 0, Negative 0 (in seconds) Reference object: NQA entry: admin test Reaction: 1

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

[SwitchA] display ip routing-table Routing Tables: Public Destinations : 5 Routes : 5

Destination/Mask Proto Pre Cost NextHop Interface

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.2/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The information shows that the static route with the next hop 10.2.1.1 is active, and the status of the track entry is positive. The static route configuration works.

# 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

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

[SwitchA] display track all Track ID: 1 Status: Negative Notification delay: Positive 0, Negative 0 (in seconds) Reference object: NQA entry: admin test Reaction: 1

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

[SwitchA] display ip routing-table Routing Tables: Public Destinations : 4 Routes : 4

Destination/Mask Proto Pre Cost NextHop Interface

10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The information shows that the next hop 10.2.1.1 of the static route is not reachable, and the status of the track entry is negative. The static route does not work.

2-44

Page 65

3 NTP Configuration

When configuring NTP, go to these sections for information you are interes ted in:

z NTP Overview z NTP Configuration Task List z Configuring the Operation Modes of NTP z Configuring the Local Clock as a Reference Source z Configuring Optional Parameters of NTP z Configuring Access-Control Rights z Configuring NTP Authentication z Displaying and Maintaining NTP z NTP Configuration Examples

NTP Overview

Defined in RFC 1305, the Network Time Protocol (NTP) synchronizes timekeeping among distributed time servers and clients. NTP runs over the User Datagram Protocol (UDP), using UDP port 123.

The purpose of using NTP is to keep consistent timekeeping among all clock-dependent devices within the network so that the devices ca n provide diverse applications based on the consistent time.

For a local system running NTP, its time can be synchronized by other reference sources and can be used as a reference source to synchronize other clocks.

Applications of NTP

An administrator can by no means keep time synchronized among all the devices within a network by changing the system clock on each station, because this is a huge amount of workload and cannot guarantee the clock precision. NTP, however, allows quick clock synchronization within the entire network while it ensures a h igh clock precision.

NTP is used when all devices within the network must be consistent in timekeeping, for example:

z In analysis of the log information and debugging information collected from different

devices in network management, time must be used as reference basis.

z All devices must use the same reference clock in a charging s ystem. z To implement certain functions, such as scheduled restart of all devices within the network,

all devices must be consistent in timekeeping.

z When multiple systems process a complex event in cooperation, these systems must use

that same reference clock to ensure the correct execution sequence.

3-1

Page 66

z For incremental backup between a backup server and clients, timekeeping must be

synchronized between the backup server and all the clients.

Advantages of NTP

z NTP uses a stratum to describe the clock precision, and is able to synchro nize time among

all devices within the network.

z NTP supports access control and MD5 authentication. z NTP can unicast, multicast or broadcast protocol messages.

How NTP Works

Figure 3-1 shows the basic workflow of NTP. Device A and Device B are interconnected over a

network. They have their own independent system clocks, which need to be automatically synchronized through NTP. For an e asy understanding, we assume that:

z Prior to system clock synchronization between Device A and Device B, the clock of Devic e

A is set to 10:00:00 am while that o f Device B is set to 11:00:00 am .

z Device B is used as the NTP time server, namely, Device A synchronizes its clock to that of

Device B.

z It takes 1 second for an NTP message to travel from one de vice to the other.

Figure 3-1 Basic work flow of NTP

NTP message

Device A

NTP message received at 10:00:03 am

10:00:00 am

IP network

Device BDevice A

NTP message

10:00:00 am 11:00:01 am

IP network

Device B

NTP message 10:00:00 am 11:00:01 am 11:00:02 am

IP network

Device B

IP network

Device A

Device B

The process of system clock synchronization is as follows:

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

3-2

Page 67

z When this NTP message arrives at Device B, it is timestamped by Device B. The timestamp

is 11:00:01 am (T2).

z When the NTP message leaves Device B, Device B timestamps it. The timestamp is

11:00:02 am (T3).

z When Device A receives the NTP message, the lo cal time o f D evice A is 10:00 :03 am ( T4).

Up to now, Device A has sufficient information to calculate the following two important parameters:

z The roundtrip delay of NTP message: Delay = (T4–T1) – (T3- T2) = 2 seconds. z Time difference between Device A and Device B: Offset = ((T2-T1) + (T3-T4))/2 = 1 hour.

Based on these parameters, Device A can synchronize its own clock to the clock o f Device B. This is only a rough description of the work mechanism of NTP. For details, refer to RFC 1305.

NTP Message Format

NTP uses two types of messages, clock synchronization message and NTP control message. An NTP control message is used in environments where network management is needed. As it is not a must for clock synchronization, it will not be discussed in this document.

All NTP messages mentioned in this document refer to NTP clock synchronization messages.

A clock synchronization message is encapsulated in a UDP message, in the format shown in

Figure 3-2.

3-3

Page 68

Figure 3-2 Clock synchronization message format

Main fields are described as follows:

z LI: 2-bit leap indicator. When set to 11, it warns of an alarm condition (clock

unsynchronized); when set to any other value, it is not to be pr ocessed by NTP.

z VN: 3-bit version number, indicating the version of NTP. The latest version is version 3. z Mode: a 3-bit code indicating the work mode of NTP. This field can be set to these values: 0

– reserved; 1 – symmetric active; 2 – symmetric passive; 3 – client; 4 – server; 5 – broadcast or multicast; 6 – NTP control message; 7 – reserved for private u se.

z Stratum: an 8-bit integer indicating the stratum level of the local clock, with the value

ranging from 1 to 16. The clock precision dec reases from stratum 1 through stratum 16. A stratum 1 clock has the highest precision, and a stratum 16 clock is not synchronized and cannot be used as a reference clock.

z Poll: 8-bit signed integer indicating the poll interval, namely the maximum interval between

successive messages.

z Precision: an 8-bit signed integer indicating the p recision of the local clock. z Root Delay: roundtrip delay to the primary reference source. z Root Dispersion: the maximum error of the local clock relative to the primary reference

source.

z Reference Identifier: Identifier of the particular reference source. z Reference Timestamp: the local time at which the local clock was last set or corrected. z Originate Timestamp: the local time at which the request departed from the client for the

service host.

z Receive Timestamp: the local time at which the request arrived at the service host. z Transmit Timestamp: the local time at which the reply departed from the service host for

the client.

3-4

Page 69

z Authenticator: authentication information.

Operation Modes of NTP

Devices running NTP can implement clock synchronization in one of the following mod es:

z Client/server mode z Symmetric peers mode z Broadcast mode z Multicast mode

You can select operation modes of NTP as needed. In case that the IP address of the NTP server or peer is unknown and many devices in the network need to be synchronized, you can adopt the broadcast or multicast mode; while in the client/server and symmetric peers modes, a device is synchronized from the specified server o r peer, and thus clock reliability is enhanced.

Client/server mode

Figure 3-3 Client/server mode

When working in the client/server mode, a client sends a clock synchronization message to servers, with the Mode field in the message set to 3 (client mode). Upon receiving the message, the servers automatically work in the server mode and send a reply, with the Mode field in the messages set to 4 (server mode). Upon receiving the replies from the servers, the client performs clock filtering and selection, and synchronizes its local clock to that of the optimal reference source.

In this mode, a client can be synchronized to a ser ver, but not vice versa.

3-5

Page 70

Symmetric peers mode

Figure 3-4 Symmetric peers mode

A device working in the symmetric active mode periodically sends clock synchronization messages, with the Mode field in the message set to 1 (symmetric active); the device that receives this message automatically enters the symmetric passive mode and sends a reply, with the Mode field in the message set to 2 (symme tric passive). By exchanging messages, the symmetric peers mode is established between the two devices. Then, the two devices can synchronize, or be synchronized by each other. If the clocks of both devices have been already synchronized, the device whose local clock has a lower stratum level will synchronize the clock of the other device.

Broadcast mode

Figure 3-5 Broadcast mode

ClientServer

Network

Periodically broadcasts clock

synchronization messages (Mode 5)

Clock synchronization message exchange (Mode 3 and Mode 4)

Periodically broadcasts clock

synchronization messages (Mode 5)

After receiving the first

broadcast message, the

client sends a request

Calculates the network delay

between client and the server

and enters the broadcast

client mode

Receives broadcast

messages and synchronizes

its local clock

In the broadcast mode, a server periodically sends clock synchronization messages to the broadcast address 255.255.255.255, with the Mode field in the messages set to 5 (broadcast mode). Clients listen to the broadcast messages from servers. After a client receives the first broadcast message, the client and the server start to exchange messages , with the Mode field set to 3 (client mode) and 4 (server mode) to calculate the network delay between client and the server. Then, the client enters the broadcast client mode and continues listening to broadcast messages, and synchronizes its local clock based on the received broadcast messages.

3-6

Page 71

Multicast mode

Figure 3-6 Multicast mode

ClientServer

Network

Periodically multicasts clock

synchronization messages (Mode 5)

Clock synchronization message exchange (Mode 3 and Mode 4)

Periodically multicasts clock

synchronization messages (Mode 5)

After receiving the first

multicast message, the

client sends a request

Calculates the network delay

between client and the server

and enters the multicast

client mode

Receives multicast

messages and synchronizes

its local clock

In the multicast mode, a server periodically sends clock synchronization messages to the user-configured multicast address, or, if no multicast address is configured, to the default NTP multicast address 224.0.1.1, with the Mode field in the messages set to 5 (multicast mode). Clients listen to the multicast messages from servers. After a client receives the first multicast message, the client and the server start to exchange messages, with the Mode field set to 3 (client mode) and 4 (server mode) to calculate the network delay between client and the server. Then, the client enters the multicast client mode and continues listening to multicast messages, and synchronizes its local clock based on the received multicast messages.

In symmetric peers mode, broadcast mode and multicast mode, the client (or the symmetric active peer) and the server (the symmetric passive peer) can work in the specified NTP working mode only after they exchange NTP messages with the Mode field being 3 (client mode) and the Mode field being 4 (server mode). During this message exchange process, NTP clock synchronization can be implemented.

Multiple Instances of NTP

The client/server mode and symmetric mode support multiple instances of NTP and thus support clock synchronization within an MPLS VPN network. Namely, network devices (CEs and PEs) at different physical location can get their clocks synchronized through NTP, as long as they are in the same VPN. The specific functions are as follows:

z The NTP client on a customer edge device (CE) can be synchr onized to the NTP server on

another CE.

z The NTP client on a CE can be synchronized to the NTP server on a provider edge device

(PE).

z The NTP client on a PE can be synchronized to the NTP server on a CE through a

designated VPN instance.

3-7

Page 72

z The NTP client on a PE can be synchronized to the NTP server on another PE through a

designated VPN instance.

z The NTP server on a PE can synchronize the NTP clients on multiple CEs in different

VPNs.

z A CE is a device that has an interface directly connecting to the service provider (SP). A CE

is not “aware of” the presence of the VPN.

z A PE is a device directly connecting to CEs. In an MPLS netwo rk, all e vents rela ted to VPN

processing occur on the PE.

NTP Configuration Task List

Complete the following tasks to configure NTP:

Task Remarks

Configuring the Oper ation Modes of NTP

Configuring the Loc al Clock as a Refer ence Source

Configuring Optional Parameters of NTP

Configuring Access-Control Rights

Configuring NTP Authentication

Configuring the Operation Modes of NTP

Devices can implement clock synchronization in one of the following mo des:

z Client/server mode z Symmetric mode z Broadcast mode z Multicast mode

Required

Optional

For the client/server mode or symmetric mode, you need to configure only clients or symmetric-active peers; for the broadcast or multicast mode, you need to configure both servers and clients.

3-8

Page 73

A single device can have a maximum of 128 associations at the same time, including static associations and dynamic associations. A static association refers to an association that a user has manually created by using an NTP command, while a dynamic association is a temporary association created by the system during operation. A dynamic association will be removed if the system fails to receive messages from it over a specific long time. In the client/server mode, for example, when you carry out a command to synchronize the time to a server, the system will create a static association, and the server will just respond passively upon the receipt of a message, rather than creating an association (static or dynamic). In the symmetr ic mode, s ta tic associations will be created at the symmetric-active peer side, and dynamic associations will be created at the symmetric-passive peer side; in the broadcast or multicast mode, static associations will be created at the server side, and dynamic associations will be created at the client side.

Configuring NTP Client/Server Mode

For devices working in the client/server mode, you only need to make configurations on the clients, but not on the servers.

Follow these steps to configure an NTP client:

To do… Use the command… Remarks

Enter system view

Specify an NTP serv er for th e device

system-view

ntp-service unicast-server

vpn-instance

[ vpn-instance-name ] { ip-address | server-name }

authentication-keyid

[

priority

interface-type interfac e-number

version

source-interface

number ] *

keyid |

—

Required No NTP server is specif ied by

default.

3-9

Page 74

z In the ntp-service unicast-server command, ip-address must be a unicast address, rather

than a broadcast address, a multicast address or the IP address of the local clock.

z When the source interface for NTP messages is specified by the source-interface

argument, the source IP address of the NTP messages will be configured as the primary IP address of the specified interface.

z A device can act as a server to synchronize the clock of other devices only after its clock

has been synchronized. If the clock of a server has a stratum level higher than or equal to that of a client’s clock, the client will not synchronize its clock to the server ’s.

z You can configure multiple servers by repeating the nt p-service unic ast-server command.

The clients will choose the optimal reference source.

Configuring the NTP Symmetric Peers Mod e

For devices working in the symmetric mode, you need to specify a symmetric-passive peer on a symmetric-active peer.

Following these steps to configure a symmetric-active device:

To do… Use the command… Remarks

Enter system view

Specify a symmetric- passive peer for the device

system-view

ntp-service unicast-peer

vpn-instance

[ vpn-instance-name ] { ip-address | peer-name }

authentication-keyid

[

priority

interface-type interfac e-number

version

source-interface

number ] *

keyid |

—

Required No symmetric-passive peer is

specified by default.

3-10

Page 75

z In the symmetric mode, you should use the ntp-service refclock-master command or any

NTP configuration command in

Configuring the Operation Modes of NTP to enable NTP;

otherwise, a symmetric-passive peer will not process NTP messages from a symmetric-active peer.

z In the ntp-service unicast-peer command, ip-address must be a unicast address, rather

than a broadcast address, a multicast address or the IP address of the local clock.

z When the source interface for NTP messages is specified by the source-interface

argument, the source IP address of the NTP messages will be configured as the primary IP address of the specified interface.

z Typically, at least one of the symmetric-active and symmetric-passive peers has been

synchronized; otherwise the clock synchronization will not proceed.

z You can configure multiple symmetric-passive peers by repeating the ntp-service

unicast-peer command.

Configuring NTP Broadcast Mode

The broadcast server periodically sends NTP broadcast messages to the broadcast address

255.255.255.255. After receiving the messages, the device working in NTP broadcast client mode sends a reply and synchronizes its local clock.

For devices working in the broadcast mode, you need to configure both the server and clients. Because an interface needs to be specified on the broadcast server for sending NT P broadcast messages and an interface also needs to be specified on each broadcast client for receiving broadcast messages, the NTP broadcast mode can be configured only in the specific interface view.

Configuring a broadcast client

To do… Use the command… Remarks

Enter system view

Enter interface view

system-view

interface

interface-number

interface-type

—

Required Enter the interface used to

receive NTP broadcast messages.

Configure the dev ice to wor k in the NTP broadcast client mode

ntp-service broadcast-client

3-11

Required

Page 76

Configuring the broadcast server

To do… Use the command… Remarks

Enter system view

Enter interface view

Configure the dev ice to wor k in the NTP broadcast server mode

system-view

interface

interface-number

ntp-service broadcast-server

[

version

A broadcast server can synchronize broadcast clients only after its clock has been synchronized.

Configuring NTP Multicast Mode

The multicast server periodically sends NTP multicast messages to multicast clients, which send replies after receiving the messages and synchronize their local clocks.

interface-type

authentication-keyid

number ] *

keyid |

—

Enter the interface used to send NTP broadcast messages.

Required

For devices working in the multicast mode, you n eed to configure both the server and clients. The NTP multicast mode must be configured in the specific interface view.

Configuring a multicast client

To do… Use the command… Remarks

Enter system view

Enter interface view

Configure the dev ice to wor k in the NTP multicast client mo de

system-view

interface

interface-number

ntp-service multicast-client

[ ip-address ]

interface-type

—

Enter the interface used to receive NTP multicast messages.

Required

Configuring the multicast server

To do… Use the command… Remarks

Enter system view

Enter interface view

system-view

interface

interface-number

interface-type

—

Enter the interface used to send NTP multicast message.

3-12

Page 77

To do… Use the command… Remarks

Configure the dev ice to wor k in the NTP multicast server m ode

ntp-service multicast-server

[ ip-address ]

authentication-keyid

[

ttl

ttl-number |

versi on

number ]

keyid |

Required

z A multicast server can synchronize broadcast clients only after its clock has been

synchronized.

z You can configure up to 254 multicast clients, among which 128 can take effect at the same

time.

Configuring the Local Clock as a Reference Source

A network device can get its clock synchronized in one of the following two ways:

z Synchronized to the local clock, which works as the reference source. z Synchronized to another device on the network in any of the four NTP operation modes

previously described.

If you configure two synchronization modes, the device will choose the optimal clock as the reference source.

Follow these steps to configure the local clock as a reference source:

To do… Use the command… Remarks

Enter system view

Configure the local cl ock as a reference source

system-view

ntp-service refclock-master

[ ip-address ] [ stratum ]

—

Required

3-13

Page 78

z Typically, the stratum level of the NTP server which is synchronized from an authoritative

clock (such as an atomic clock) is set to 1. This NTP server operates as the primary reference source on the network; and other devices synchronize themselves to it. The synchronization distances between the primary reference source and other devices on the network, namely, the number of NTP servers on the NTP synchronization paths, determine the clock stratum levels of the devices.

z After you have configured the local clock as a reference clock, the local device can act as a

reference clock to synchronize other devices in the network. Therefore, perform this configuration with caution to avoid clock errors of the devices in the network.

z In this command, ip-address must be 127.127.1.u, where u ranges 0 to 3, representing the

NTP process ID.

Configuring Optional Parameters of NT P

Specifying the Source Interface fo r NTP Messages

If you specify the source interface for NTP messages, the device sets the s ource IP address of the NTP messages as the primary IP address of the specified interface when sending the NTP messages.

When the device responds to an NTP request received, the source IP address of the NTP response is always the IP address of the interface that received the NTP request.

Following these steps to specify the source interface for NTP messages:

To do… Use the command… Remarks

Enter system view

Specify the source interface for NTP messages

system-view

ntp-service source-interface

interface-type interfac e-number

—

Required By default, no source interface

is specified for NTP mes sages, and the system uses the IP address of the interface determined by the matching route as the source IP a ddress of NTP messages.

3-14

Page 79

z If you have specified the source interface for NTP messages in the ntp-service

unicast-server or ntp-service unicast-peer command, the interface specified in the ntp-service unicast-server or ntp-service unicast-peer command serves as the source

interface of NTP messages.

z If you have configured the ntp-ser vice broadcast-server or ntp-ser vice multicast-server

command, the source interface of the broadcast or multicast NTP messages is the interface configured with the respective command.

z If the specified source interface for NTP messages is down, the source IP address for an

NTP message that is sent out is the primary IP address of the outgoing interface of the NTP message.

Disabling an Interface from Receiving NTP Messages

When NTP is enabled, NTP messages can be received from all the interfaces by default, and you can disable an interface from receiving NTP messages through the following configuration.

To do… Use the command… Remarks

Enter system view

Enter interface view

Disable the interface from receiving NTP messages

system-view

interface

interface-number

ntp-service in-interface disable

interface-type

—

Required An interface is enabled to

receive NTP messages by default.

Configuring the Maximum Number of Dynamic Sessions Allowed

To do… Use the command… Remarks

Enter system view

system-view

—

Configure the maximum numb er of dynamic sessions allowed to be established locally

ntp-service max-dynamic-sessions

number

3-15

Required 100 by default

Page 80

Configuring Access-Control Rights

With the following command, you can configure the NTP service access-control right to the local device. There are four access-control rights, as follows:

z query: control query permitted. This level of right permits the peer devices to perform

control query to the NTP service on the local device but does not permit a peer device to synchronize its clock to that of the local device. The so-called “control query” refers to query of some states of the NTP service, including alarm information, authentication status, clock source information, and so on.

z synchronization: server access only. This level of right permits a peer device to

synchronize its clock to that of the local device but does not permit the peer devices to perform control query.

z server: server access and query permitted. This level of r ight permits the peer devices to

perform synchronization and control query to the local device but does not permit the local device to synchronize its clock to that of a peer device.

z peer: full access. This level of right permits the peer devices to perform synchronization

and control query to the local device and also pe rmits the local device to synchronize its clock to that of a peer device.

From the highest NTP service access-control right to the lowest one are peer, server, synchronization, and query. When a device receives an NTP request, it will perform an access-control right match and will use the first matched right.

Configuration Prerequisites

Prior to configuring the NTP service access-control right to the local device, you need to create and configure an ACL associated with the access-control right. For the configuration of ACL , refer to ACL Configuration in the ACL and QoS Configuration Guide.

Configuration Procedure

Follow these steps to configure the NTP service access-control right to the local device:

To do… Use the command… Remarks

Enter system view

Configure the NTP se rvice access-control right for a peer device to access the local device

system-view

ntp-service access { peer query | server | synchronization

} acl-number

—

Required

peer

by default

3-16

Page 81

The access-control right mechanism provides only a minimum degree of security protec tion for the system running NTP. A more secure method is identity authentica tion.

Configuring NTP Authentication

The NTP authentication feature should be enabled for a system running NTP in a network where there is a high security demand. This feature enhances the network security by means of client-server key authentication, which prohibits a client from synchronizing with a device that has failed authentication.

Configuration Prerequisites

The configuration of NTP authentication involves configuration tasks to be implemented on the client and on the server.

When configuring the NTP authentication feature, pay attention to the following principles:

z For all synchronization modes, when you enable the NTP authentication feature, you

should configure an authentication key and specify it as a trusted key. Namely, the

ntp-service authentication enable command must work together with the ntp-service authentication-keyid command and the ntp-service reliable authentication-keyid

command. Otherwise, the NTP authentication function cannot be norma lly enabled.

z For the client/server mode or symmetric mode, you need to associate the specified

authentication key on the client (symmetric-active peer if in the symmetric peer mode) with the corresponding NTP server (symmetric-passive peer if in the symmetric peer mode). Otherwise, the NTP authentication feature cannot be normally enabled.

z For the broadcast server mode or multicast server mode, you need to associate the

specified authentication key on the broadcast server or multicast server with the corresponding NTP server. Otherwise, the NTP authentication feature cannot be normally enabled.

z For the client/server mode, if the NTP au thentication feature has not been enabled for the

client, the client can synchronize with the server regardless of whether the NTP authentication feature has been enabled for the server or not. If the NTP authentication is enabled on a client, the client can be synchronized only to a server that can provide a trusted authentication key.

z For all synchronization modes, the server side and the client side must be consistently

configured.

Configuration Procedure

Configuring NTP authentication for a client

Follow these steps to configure NTP authentication for a client:

3-17

Page 82

To do… Use the command… Remarks

Enter system view

Enable NTP authentication

Configure an NTP authentication key

Configure the key as a trust ed key

Associate the spec ified ke y with an NTP server

system-view

ntp-service authenticatio n enable

ntp-service authentication-keyid authentication-mode md5

value

ntp-service reliable authentication-keyid

Client/server mode:

ntp-service unicast-server

{ ip-address | server-name }

authentication-keyid

Symmetric peers mode:

ntp-service unicast-peer

{ ip-address | peer-name }

authentication-keyid

keyid

—

Required Disabled by default

Required No NTP authentication key by

default

Required No authentication key is

configured to be trusted b y default.

Required You can associate a

non-existing key with an NTP server. To enable NTP authentication, you must configure the key and sp ecify it as a trusted key aft er associating the ke y with t he NTP server.

After you enable the NTP authentication fea ture for the client, make sure that you con figure for the client an authentication key that is the same as on the server and specify that the authentication key is trusted; otherwise, the client cannot be synchronized to the server.

Configuring NTP authentication for a server

Follow these steps to configure NTP authentication for a server:

To do… Use the command… Remarks

Enter system view

Enable NTP authentication

system-view

ntp-service authentication enable

—

Required Disabled by default

3-18

Page 83

To do… Use the command… Remarks

Configure an NTP authentication key

Configure the key as a trust ed key

Enter interface view

Associate the spec ified ke y with an NTP server

ntp-service authentication-keyid authentication-mode md5

value

ntp-service reliable authentication-keyid

interface

interface-number

Broadcast server mode:

ntp-service broadcast-server authentication-keyid

Multicast server mode:

ntp-service multicast-server authentication-keyid

interface-type

keyid

Required No NTP authentication key by

default

Required No authentication key is

configured to be trusted b y default.

—

Required You can associate a

non-existing key with an NTP server. To enable NTP authentication, you must configure the key and sp ecify it as a trusted key aft er associating the ke y with t he NTP server.

The procedure of configuring NTP authentication on a server is the same as that on a client, and the same authentication key must be configured on both the server an d client sides.

Displaying and Maintaining NTP

To do… Use the command… Remarks

View the information of NTP service status

View the information of NTP sessions

View the brief informat ion of the NTP servers from the loc al device back to the primary reference source

display ntp-service status

display ntp-service sessions

verbose

[

display ntp-service trace

]

Available in any view

3-19

Page 84

NTP Configuration Examples

Configuring NTP Client/Server Mode

Network requirements

Perform the following configurations to synchronize the time between Device B and D evice A:

z The local clock of Device A is to be used as a reference source, with the stratum level of 2. z Device B works in the client/server mode and Device A is to be used as the NTP server of

Device B.

Figure 3-7 Network diagram for NTP client/server mode configuration

Configuration procedure

1) Configure IP addresses for in terfaces (omitted)

2) Configuration on Device A: # Specify the local clock as the reference source, with the stratum level of 2.

<DeviceA> system-view [DeviceA] ntp-service refclock-m aster 2

3) Configuration on Device B: # View the NTP status of Device B before clock synchronization.

<DeviceB> display ntp-service sta tus Clock status: unsynchronized Clock stratum: 16 Ref erence clock ID: n one Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Root delay: 0.00 ms Root dispersion: 0.00 ms Peer dispersion: 0.00 ms Reference time: 00:00:00.000 UTC Ja n 1 1900 (00000000. 00000000)

# Specify Device A as the NTP server of Device B so that Device B is synchronized to Device A.

<DeviceB> system-view [DeviceB] ntp-service unicast-se rver 1.0.1.1 1

# View the NTP status of Device B after clock synchronization.

[DeviceB] display ntp-service sta tus Clock status: synchronized Clock stratum: 3 Ref erence clock ID: 1 .0.1.11 Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz

3-20

Page 85

Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 31.00 ms Root dispersion: 1.05 ms Peer dispersion: 7.81 ms Ref erence time: 14:5 3:27.371 UTC Sep 19 20 05 (C6D94F67.5E F9DB22)

As shown above, Device B has been synchronized to Device A, and the clock stratum level of Device B is 3, while that of Device A is 2.

# View the NTP session information of Device B, which shows that an association has been set up between Device B and Device A.

[DeviceB] display ntp-service ses sions source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [12345] 1.0.1.11 127.127.1.0 2 63 64 3 -75.5 31.0 16.5 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 1

Configuring the NTP Symmetric Mode

Network requirements

Perform the following configurations to synchronize time among de vices:

z The local clock of Device A is to be configured as a reference source, with the stratum level

of 2.

z Device B works in the client mode and Device A is to be used as the NTP server of Device

z Device C works in the symmetric-active mode and Device B will act as peer of Device C.

Device C is the symmetric-active peer while Device B is the symmetric-passive peer .

Figure 3-8 Network diagram for NTP symmetric peers mode configuration

Switch A

3.0.1.31/24

3.0.1.32/24 3.0.1.33/24

Switch B Switch C

Configuration procedure

1) Configure IP addresses for in terfaces (omitted).

2) Configuration on Device A: # Specify the local clock as the reference source, with the stratum level of 2.

<DeviceA> system-view [DeviceA] ntp-service refclock-m aster 2

3-21

Page 86

3) Configuration on Device B: # Specify Device A as the NTP server of Device B.

<DeviceB> system-view [DeviceB] ntp-service unicast-se rver 3.0.1.3 1

4) Configuration on Device C (after Device B is synchronized to Device A) : # Specify the local clock as the reference source, with the stratum level of 1.

<DeviceC> system-view [DeviceC] ntp-service refclock-m aster 1

# Configure Device B as a symmetric peer after local synchronization.

[DeviceC] ntp-service unicast-pe er 3.0.1.32

In the step above, Device B and Device C are configured as symmetric peers , with Device C in the symmetric-active mode and Device B in the symmetr ic-passive mode. Because the stratus level of Device C is 1 while that of Device B is 3, Device B is synchronized to Device C.

# View the NTP status of Device B after clock synchronization.

[DeviceB] display ntp-service sta tus Clock status: synchronized Clock stratum: 2 Ref erence clock ID: 3 .0.1.33 Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz Clock precision: 2^18 Clock offset: -21.1982 ms Roo t delay: 15.00 ms Roo t dispersion: 775 .15 ms Peer dispersion: 34.29 ms Ref erence time: 15:2 2:47.083 UTC Sep 19 20 05 (C6D95647.15 3F7CED)

As shown above, Device B has been synchronized to Device C, and the clock stratum level of Device B is 2, while that of Devic e C is 1.

# View the NTP session information of Device B, which shows that an association has been set up between Device B and Device C.

[DeviceB] display ntp-service ses sions source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [245] 3.0.1.31 127.127.1.0 2 15 64 24 10535.0 19.6 14.5 [1234] 3.0.1.33 LOCL 1 14 64 27 -77.0 16.0 14.8 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 2

Configuring NTP Broadcast Mode

Network requirements

As shown in Figure 3-9, Switch C functions as the NTP server for multiple devices on a network segment and synchronizes the time among multiple devices. To realize this requirement, perform the following configurations:

z Switch C’s local clock is to be used as a reference source, with the s tratum leve l of 2. z Switch C works in the broadcast server mode and sends out broadcast messages from

VLAN-interface 2.

3-22

Page 87

z Switch A and Switch B work in the broadcast client mode. Switch A an d Switch B listens to

broadcast messages through its VLAN-interface 2.

Figure 3-9 Network diagram for NTP broadcast mode configuration

Vlan-int2

3.0.1.31/24

Switch C

Vlan-int2

3.0.1.30/24

Switch A

Vlan-int2

3.0.1.32/24

Switch B

Configuration procedure

1) Configure IP addresses for in terfaces (omitted).

2) Configuration on Switch C: # Configure Switch C to work in the broadcast server mode and send broadcast messages

through VLAN-interface 2.

[SwitchC] interface vlan-int erface 2 [SwitchC-Vlan-interface2] nt p-servic e broadcast -server

3) Configuration on Switch A: # Configure Switch A to work in the broadcast client mode and receive broadcast messages on

VLAN-interface 2.

<SwitchA> system-view [SwitchA] interface vlan-int erface 2 [SwitchA-Vlan-interface2] nt p-servic e broadcast -client

4) Configuration on Switch B: # Configure Switch B to work in the broadcast client mode and receive bro adcast messages on

VLAN-interface 2.

<SwitchB> system-view [SwitchB] interface vlan-int erface 2 [SwitchB-Vlan-interface2] nt p-servic e broadcast -client

Switch A gets synchronized upon rec eiving a broadcast message from Switch C. # View the NTP status of Switch A after clock synchronization.

[SwitchA-Vlan-interface2] di splay nt p-service s tatus Clock status: synchronized Clock stratum: 3 Ref erence clock ID: 3 .0.1.31 Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 31.00 ms

3-23

Page 88

Root dispersion: 8.31 ms Peer dispersion: 34.30 ms Ref erence time: 16:0 1:51.713 UTC Sep 19 20 05 (C6D95F6F.B6 872B02)

As shown above, Switch A has been synchronized to Switch C, and the clock stratum level of Switch A is 3, while that of Switc h C is 2.

# View the NTP session information of Switch A, which shows that an association has been set up between Switch A and Switch C.

[SwitchA-Vlan-interface2] di splay nt p-service s essions source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [1234] 3.0.1.31 127.127.1.0 2 254 64 62 -16.0 32.0 16.6 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 1

Configuring NTP Multicast Mode

Network requirements

As shown in Figure 3-10, Switch C functions as the NTP server for multiple devices on different network segments and synchronizes the time among multiple devices. To realize this requirement, perform the following configurations:

z Switch C’s local clock is to be used as a reference source, with the s tratum leve l of 2. z Switch C works in the multicast server mode and sends out multicast messages from

VLAN-interface 2.

z Switch A and Switch D work in the multicast client mode and receive multicast messages

through VLAN-interface 3 and VLAN-interface 2 r espectively.

Figure 3-10 Network diagram for NTP multicast mode configuration

Configuration procedure

1) Configure IP addresses for in terfaces (omitted).

2) Configuration on Switch C: # Specify the local clock as the reference source, with the stratum level of 2.

<SwitchC> system-view [SwitchC] ntp-service refclock-m aster 2

3-24

Page 89

# Configure Switch C to work in the multicast server mode and send multicast messages through VLAN-interface 2.

[SwitchC] interface vlan-int erface 2 [SwitchC-Vlan-interface2] nt p-servic e multicast -server

3) Configuration on Switch D: # Configure Switch D to work in the multicast client mode and receive multicast mes sages on

VLAN-interface 2.

<SwitchD> system-view [SwitchD] interface vlan-int erface 2 [SwitchD-Vlan-interface2] nt p-servic e multicast -client

Because Switch D and Switch C are on the same subnet, Switch D can receive the multicast messages from Switch C without being enabled with the multicast functions and can be synchronized to Switch C.

# View the NTP status of Switch D after clock synchronization.

[SwitchD-Vlan-interface2] di splay nt p-service s tatus Clock status: synchronized Clock stratum: 3 Ref erence clock ID: 3 .0.1.31 Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 31.00 ms Root dispersion: 8.31 ms Peer dispersion: 34.30 ms Ref erence time: 16:0 1:51.713 UTC Sep 19 20 05 (C6D95F6F.B6 872B02)

As shown above, Switch D has been synchronized to Switch C, and the clock stratum level of Switch D is 3, while that of Switch C is 2.

# View the NTP session information of Switch D, which shows that an association has been s e t up between Switch D and Switch C.

[SwitchD-Vlan-interface2] di splay nt p-service s essions source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [1234] 3.0.1.31 127.127.1.0 2 254 64 62 -16.0 31.0 16.6 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 1

4) Configuration on Switch B: Because Switch A and Switch C are on different subnets, you must enable the multicast

functions on Switch B before Switch A can receive multicast messages from Switch C. # Enable IP multicast routing and IGMP.

<SwitchB> system-view [SwitchB] multicast routing-enab le [SwitchB] interface vlan-int erface 2 [SwitchB-Vlan-interface2] pi m dm [SwitchB-Vlan-interface2] qu it [SwitchB] vlan 3 [SwitchB-vlan3] port gigabit ethernet 2/0/1

3-25

Page 90

[SwitchB-vlan3] quit [SwitchB] interface vlan-int erface 3 [SwitchB-Vlan-interface3] ig mp enabl e [SwitchB-Vlan-interface3] ig mp stati c-group 224 .0.1.1 [SwitchB-Vlan-interface3] qu it [SwitchB] interface gigabitether net 2/0/1 [SwitchB- GigabitEthernet2/0/1 ] igmp-snoopi ng static-group 224.0.1.1 vlan 3

5) Configuration on Switch A: # Enable IP multicast routing and IGMP.

<SwitchA> system-view [SwitchA] interface vlan-int erface 3

# Configure Switch A to work in the multicast client mode and receive multicast messages on VLAN-interface 3.

[SwitchA-Vlan-interface3] nt p-servic e multicast -client

# View the NTP status of Switch A after clock synchronization.

[SwitchA-Vlan-interface3] di splay nt p-service s tatus Clock status: synchronized Clock stratum: 3 Ref erence clock ID: 3 .0.1.31 Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 40.00 ms Root dispersion: 10.83 ms Peer dispersion: 34.30 ms Ref erence time: 16:0 2:49.713 UTC Sep 19 20 05 (C6D95F6F.B6 872B02)

As shown above, Switch A has been synchronized to Switch C, and the clock stratum level of Switch A is 3, while that of Switc h C is 2.

# View the NTP session information of Switch A, which shows that an association has been set up between Switch A and Switch C.

[SwitchA-Vlan-interface3] di splay nt p-service s essions source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [1234] 3.0.1.31 127.127.1.0 2 255 64 26 -16.0 40.0 16.6 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 1

Refer to IGMP Configuration in the IP Multicast Configuration Guide for ho w to configure IGM P and PIM.

3-26

Page 91

Configuring NTP Client/Server Mode with Authentication

Network requirements

As shown in Figure 3-11 , perform the following configurations to synchronize the time b etween Device B and Device A and ensure network security.

z The local clock of Device A is to be configured as a reference source, with the stratum level

of 2.

z Device B works in the client mode and Device A is to be used as the NTP server of Device

B, with Device B as the client.

z NTP authentication is to be enabled on both Device A and Device B.

Figure 3-11 Network diagram for configuration of NTP client/s erver mode with authentication

Configuration procedure

1) Configure IP addresses for in terfaces (omitted).

2) Configuration on Device A: # Specify the local clock as the reference source, with the stratum level of 2.

<DeviceA> system-view [DeviceA] ntp-service refclock-m aster 2

3) Configuration on Device B:

<DeviceB> system-view

# Enable NTP authentication on Device B.

[DeviceB] ntp-service authentica tion enable

# Set an authentication key.

[DeviceB] ntp-service authentica tion-keyid 4 2 authentication- mode md5 aNiceKe y

# Specify the key as a trusted key.

[DeviceB] ntp-service reliable au thenticatio n-keyid 42

# Specify Device A as the NTP server of Device B.

[DeviceB] ntp-service unicas t-server 1.0.1.11 a uthenticati on-keyid 42

Before Device B can synchronize its clock to that of Device A, enable NTP authentication for Device A.

Perform the following configuration on Device A: # Enable NTP authentication.

[DeviceA] ntp-service authentica tion enable

# Set an authentication key.

[DeviceA] ntp-service authentica tion-keyid 4 2 authentication- mode md5 aNiceKe y

# Specify the key as a trusted key.

[DeviceA] ntp-service reliable au thenticatio n-keyid 42

# View the NTP status of Device B after clock synchronization.

[DeviceB] display ntp-service sta tus Clock status: synchronized Clock stratum: 3

3-27

Page 92

Ref erence clock ID: 1 .0.1.11 Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 31.00 ms Root dispersion: 1.05 ms Peer dispersion: 7.81 ms Ref erence time: 14:5 3:27.371 UTC Sep 19 20 05 (C6D94F67.5E F9DB22)

As shown above, Device B has been synchronized to Device A, and the clock stratum level of Device B is 3, while that of Device A is 2.

# View the NTP session information of Device B, which shows that an association has been set up Device B and Device A.

Configuring NTP Broadcast Mode with Authentication

Network requirements

As shown in Figure 3-12, Switch C functions as the NTP server for multiple devices on different network segments and synchronizes the time among multiple devices. To realize this requirement and ensure network security, perform the following configurations:

z Switch C’s local clock is to be used as a reference source, with the s tratum leve l of 3. z Switch C works in the broadcast server mode and sends out broadcast messages from

VLAN-interface 2.

z Switch D works in the broadcast client mode and receives broadcast messages through

VLAN-interface 2.

z NTP authentication is enabled on both Switch C and Sw itch D.

Figure 3-12 Network diagram for configuration of NTP broadcast mode w ith authentication

Vlan-int2

3.0.1.31/24

Switch C

Vlan-int3

1.0.1.11/24

Vlan-int3

1.0.1.10/24

Vlan-int2

3.0.1.30/24

Switch A Switch B

3.0.1.32/24

3-28

Vlan-int2

Switch D

Page 93

Configuration procedure

1) Configure IP addresses for in terfaces (omitted).

2) Configuration on Switch C: # Specify the local clock as the reference source, with the stratum level of 3.

<SwitchC> system-view [SwitchC] ntp-service refclock-m aster 3

# Configure NTP authentication.

[SwitchC] ntp-service authentica tion enable [SwitchC] ntp-service authentica tion-keyid 8 8 authentication- mode md5 123456 [SwitchC] ntp-service reliable au thenticatio n-keyid 88

# Specify Switch C as an NTP broadcast server, and specify an authentication key.

[SwitchC] interface vlan-int erface 2 [SwitchC-Vlan-interface2] nt p-servic e broadcast -server aut hentication -keyid 88

3) Configuration on Switch D: # Configure NTP authentication.

<SwitchD> system-view [SwitchD] ntp-service authentica tion enable [SwitchD] ntp-service authentica tion-keyid 8 8 authentication- mode md5 123456 [SwitchD] ntp-service reliable au thenticatio n-keyid 88

# Configure Switch D to work in the NTP broadcast client mode.

[SwitchD] interface vlan-int erface 2 [SwitchD-Vlan-interface2] nt p-servic e broadcast -client

Now, Switch D can receive broadcast messages through VLAN-interface 2, and Switch C can send broadcast messages through VLAN-interface 2. Upon receiving a broadcast message from Switch C, Switch D synchronizes its clock to that of Switch C.

# View the NTP status of Switch D after clock synchronization.

[SwitchD-Vlan-interface2] di splay nt p-service s tatus Clock status: synchronized Clock stratum: 4 Ref erence clock ID: 3 .0.1.31 Nominal frequency: 100.0000 Hz Act ual frequency: 10 0.0000 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 31.00 ms Root dispersion: 8.31 ms Peer dispersion: 34.30 ms Ref erence time: 16:0 1:51.713 UTC Sep 19 20 05 (C6D95F6F.B6 872B02)

As shown above, Switch D has been synchronized to Switch C, and the clock stratum level of Switch D is 4, while that of Switch C is 3.

# View the NTP session information of Switch D, which shows that an association has been s e t up between Switch D and Switch C.

[SwitchD-Vlan-interface2] di splay nt p-service s essions source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [1234] 3.0.1.31 127.127.1.0 3 254 64 62 -16.0 32.0 16.6 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured

3-29

Page 94

Total associations : 1

Configuring MPLS VPN Time Synchronization in Client/server Mode

Network requirements

As shown in Figure 3-13, two VPNs are present on PE 1 and PE 2: VPN 1 and VPN 2. CE 1 and CE 3 are devices in VPN 1. To synchronize the time between CE 1 and CE 3 in VPN 1, perform the following configurations:

z CE 1’s local clock is to be used as a reference source, with th e stratum level of 1. z CE 3 is synchronized to CE 1 in the client/server mode.

At present, MPLS VPN time synchronization can be implemented only in the unicast mode (client/server mode or symmetric peers mode), but not in the multicast or broadcast mode.

Figure 3-13 Network diagram for MPLS VPN time synchronization configuration

VPN 1

CE 1

Vlan-int 10

Vlan-int 20

CE 2 CE 4

VPN 2

PE 1 PE 2P

Vlan-int 30

MPLS backbone

Vlan-int 40

Vlan-int 50

Vlan-int 60

VPN 1

CE 3

VPN 2

Device Interface IP address Device Interface IP address CE 1 Vlan-int 10 10.1.1.1/24 PE 1 Vlan-int 10 10.1.1.2/24 CE 2 Vlan-int 20 10.2.1.1/24 Vlan-int 30 172.1.1.1/24 CE 3 Vlan-int 50 10.3.1.1/24 Vlan-int 20 10.2.1.2/24 CE 4 Vlan-int 60 10.4.1.1/24 PE 2 Vlan-int 50 10.3.1.2/24 P Vlan-int 30 172.1.1.2/24 Vlan-int 40 172.2.1.2/24 Vlan-int 40 172.2.1.1/24 Vlan-int 60 10.4.1.2/24

3-30

Page 95

Configuration procedure

Prior to performing the following configuration, be sure you have completed MPLS VPN-related configurations and make sure of the reachability between CE 1 and PE 1, between PE 1 and PE 2, and between PE 2 and CE 3. Refer to the MPLS Configuration Guide to configure MPLS VPN.

1) Configure IP addresses for in terfaces (omitted).

2) Configuration on CE 1 : # Specify the local clock as the reference source, with the stratum level of 1.

<CE1> system-view [CE1] ntp-service refclock-m aster 1

3) Configuration on CE 3 : # Specify CE 1 in VPN 1 as the NTP server of CE 3.

<CE3> system-view [CE3] ntp-service unicast-server 10.1.1.1

# View the NTP session information and status information on CE 3 a certain period of time later. The information should show that CE 3 has been synchronized to CE 1, with the clock stratum level of 2.

[CE3] display ntp-service status Clock status: synchronized Clock stratum: 2 Ref erence clock ID: 1 0.1.1.1 Nominal frequency: 99.9100 Hz Act ual frequency: 99 .9100 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 47.00 ms Root dispersion: 0.18 ms Peer dispersion: 34.29 ms Ref erence time: 02:3 6:23.119 UTC Jan 1 200 1(BDFA6BA7.1 E76C8B4) [CE3] display ntp-service session s source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [12345]10.1.1.1 LOCL 1 7 64 15 0.0 47.0 7.8 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 1 [CE3] display ntp-service trace server 127.0.0.1,stratum 2, offset -0.013500, synch distance 0.03154 server 10.1.1.1,stratum 1, offset -0.506500, synch distance 0.03429 refid 127.127.1.0

3-31

Page 96

Configuring MPLS VPN Time Synchronization in Symmetric Peers Mode

Network requirements

As shown in Figure 3-13, two VPNs are present on PE 1 and PE 2: VPN 1 and VPN 2. To synchronize the time between PE 1 and PE 2 in VPN 1, perform the following configurations:

z PE 1’s local clock is to be used as a reference source, with the stratum level o f 1. z PE 2 is synchronized to PE 1 in the symmetric peers mode, and specify that the VPN

instance is VPN 1.

Configuration procedure

1) Configure IP addresses for in terfaces (omitted).

2) Configuration on PE 1: # Specify the local clock as the reference source, with the stratum level of 1.

<PE1> system-view [PE1] ntp-service refclock-m aster 1

3) Configuration on PE 2: # Specify PE 1 in VPN 1 as the symmetric-passive peer of PE 2.

<PE2> system-view [PE2] ntp-service unicast-pe er vpn-i nstance vpn 1 10.1.1.2

# View the NTP session information and status information on PE 2 a certain period of time later. The information should show that PE 2 has been synchronized to PE 1, with the clock stratum level of 2.

[PE2] display ntp-service status Clock status: synchronized Clock stratum: 2 Ref erence clock ID: 1 0.1.1.2 Nominal frequency: 99.9100 Hz Act ual frequency: 99 .9100 Hz Clock precision: 2^18 Clock offset: 0.0000 ms Roo t delay: 32.00 ms Root dispersion: 0.60 ms Peer dispersion: 7.81 ms Ref erence time: 02:4 4:01.200 UTC Jan 1 200 1(BDFA6D71.3 3333333) [PE2] display ntp-service session s source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** ***** [12345]10.1.1.2 LOCL 1 1 64 29 -12.0 32.0 15.6 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 1 [PE2] display ntp-service trace server 127.0.0.1,stratum 2, offset -0.01200 0, synch di stance 0.02 448 server 10.1.1.2,stratum 1, offset 0 .003500, synch dist ance 0.0078 1 refid 127.127.1.0

3-32

Page 97

4 IPC Configuration

When configuring IPC, go to these sections for information you are interested in:

z IPC Overview z Enabling IPC Performance Statistics z Displaying and Maintaining IPC

IPC Overview

Introduction to IPC

Inter-Process Communication (IPC) is a reliable communication mechanism among different nodes. The following are the basic concepts in IPC.

Node

An IPC node is an entity supporting IPC; it is an independent processing unit. In actual application, an IPC node corresponds to one CPU.

z One centralized device has only one CPU, therefore corresponding to one node. z An Intelligent Resilient Framework (IRF) is an interconnection of several centralized devices, with

each member device corresponding to one node. Therefore, an IRF corresponds to multiple nodes.

z Typically a distributed device is available with multiple boards, each having one CPU, some

boards are available with multiple CPUs. Some distributed devices may be available with multiple CPUs, for example service CPU and OAM CPU. Therefore, a distributed device corresponds to multiple nodes.

Therefore, in actual application, IPC is mainly applied on an IRF or distributed device; it provides a reliable transmission mechanism between diff erent devices and boards.

Link

An IPC link is a connection between any two IPC nodes. There is one and only one link between any two nodes for packet sending and receiving. All IPC nodes are fully connected.

IPC links are created when the system is initialized: When a node starts up, it sends handshake packets to other nodes; a connection is established between them if the handshake succeeds.

The system identifies the link connectivity between two nodes using link status. An IPC node can have multiple links, each having its own status.

Channel

A channel is a communication interface for an upper layer application module of a node to communicate with an application module of a peer node. Each node assigns a locally unique channel number to each upper layer application module.

Data of an upper layer application module is sent to the IPC module through a channel, and the IPC module sends the data to a peer node through the link. The relationship between a node, link and channel is as shown in

Figure 4-1.

4-1

Page 98

Figure 4-1 Relationship between a node, link and channel

Node 1

Application 2

Node 2

nnel

IPC

Application 2

nel

Application 3Application 1

Packet sending modes

IPC supports three packet sending modes: unicast, multicast (broadcast is considered as a special multicast), and mixcast, each having a corresponding queue. The upper layer application modules can select one as needed.

z Unicast: packet sending between two single nodes. z Multicast: packet sending between a single node and multiple nodes. To use the multicast mode,

a multicast group needs to be created first. Multicasts will be sent to all the nodes in the multicast group. An application can create multiple multicast groups. The creation and deletion of a multicast group and multicast group members depend on the application module.

z Mixcast, namely, both unicast and multicast are supported.

Enabling IPC Performance Statistics

When IPC performance statistics is enabled, the system collects statistics for packet sending and receiving of a node in a specified time range (for example, in the past 10 seconds, or in the past 1 minute). When IPC performance statistics is disabled, statistics collection is stopped. At this time, if you execute the display command, the system displays the statistics information at the time when IPC performance statistics was disabled.

Follow these steps to enable IPC performance statisti cs:

To do… Use the command… Remarks

ipc performance enable

Enable IPC performance statistics

node-id | channel-id ]

self-node

} [

node

{

channel

Required Disabled by default Available in user view

4-2

Page 99

Displaying and Maintaining IPC

To do… Use the command… Remarks

Display IPC node information

Display channel information of a node

Display queue information of a node

Display multicast group information of a node

Display packet information of a node

Display link status information of a node

Display IPC performance statistics information of a node

Clear IPC performance statistics information of a node

display ipc node

display ipc channel

node-id |

display ipc queue

self-node

display ipc multicast-group

node

{

display ipc packet

self-node

display ipc link self-node

display ipc performance

node-id | channel-id ]

reset ipc performance

node-id | channel-id ]

self-node

}

node-id |

}

self-node

node

{

}

node

{

self-node

node

{

node

{

channel

} [

channel

] [

node-id

}

node-id

node-id |

{

node

[

node

Available in any view

Available in user view

4-3

Page 100

5 PoE Configuration

The S7500E Series Ethernet Switches are distributed de vices supporting Intelligent Resilient Framework (IRF). Two S7500E series can be connected together to form a distributed IRF device. If an S7500E series is not in any IRF, it operates as a distributed d evice; if the S7500E series is in an IRF, it operates as a di stributed IRF device. Fo r introduction of IRF , refer to IRF Configuration in the IRF Configuration Guide.

When configuring PoE, go to these sections for information you are in terested in:

z PoE Overview z PoE Configuration Task List z Enabling PoE z Detecting PDs z Configuring the PoE Power z Configuring PoE Power Management z Configuring the PoE Monitoring Function z Configuring PoE Interface through PoE Profile z Upgrading PSE Processing Software in Service z Displaying and Maintaining PoE z PoE Configuration Example z Troubleshooting PoE

PoE Overview

Introduction to PoE

Power over Ethernet (PoE) means that power sourcing equipment (PSE) supplies power to powered devices (PDs) from Ethernet interfaces through twisted pair cables.

Advantages

z Reliable: Power is supplied in a centralized way so that it is very con venient to provide a

backup power supply.

z Easy to connect: A network terminal requires no external power supply but only an Ethernet

cable.

z Standard: In compliance with IEEE 802.3af, and a globally uniform power interface is

adopted.

5-1

H3C S7500E User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Preface

Audience

Document Organization

Conventions

Command conventions

Symbols

About the H3C S7500E Documentation Set

Obtaining Documentation

Documentation Feedback

Table of Contents

1 System Maintaining and Debugging

System Maintaining and Debugging

Ping

Introduction

Configuring Ping

Ping Configuration Example

Network requirements

Configuration procedure

Tracert

Introduction

Configuring Tracert

System Debugging

Introduction to System Debugging

Configuring System Debugging

Ping and Tracert Configuration Example

Network requirements

Configuration procedure

2 NQA Configuration

NQA Overview

Introduction to NQA

Features of NQA

Supporting multiple test types

Supporting the collaboration function

Supporting delivery of traps

Basic Concepts of NQA

Test group

Test and probe

NQA client and server

NQA Test Operation

NQA Configuration Task List

Configuring the NQA Server

Enabling the NQA Client

Creating an NQA Test Group

Configuring an NQA Test Group

Configuring an ICMP Echo Test

Configuring a DHCP Test

Configuration prerequisites

Configuring a DHCP test

Configuring a DNS Test

Configuration prerequisites

Configuring a DNS test

Configuring an FTP Test

Configuration prerequisites

Configuring an FTP test

Configuring an HTTP Test

Configuration prerequisites

Configuring an HTTP test

Configuring a UDP Jitter Test

Configuration prerequisites

Configuring a UDP jitter test

Configuring an SNMP Test

Configuration prerequisites

Configuring an SNMP test

Configuring a TCP Test

Configuration prerequisites

Configuring a TCP test

Configuring a UDP Echo Test

Configuration prerequisites

Configuring a UDP echo test

Configuring a Voice Test

Configuration prerequisites

Configuring a voice test

Configuring a DLSw Test

Configuration prerequisites

Configuring a DLSw test

Configuring the Collaboration Function