H3C S5820X Series, S5800 Series Configuration Manual

Download

Page 1

H3C S5820X&S5800 Series Ethernet Switches

Network Management and Monitoring

Configuration Guide

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

Document Version: 6W103-20100716 Product Version: Release 1110

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 S5800&S5820X documentation set includes 11 configuration guides, which describe the software features for the S5800&S5820X 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, collect traffic statistics, sample packets, assess the network p erformance, synchronize time for all devi ces with clocks in your network, supply power for the attached devices by using PoE, perform cluster management for switches, 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 S5800&S5820X Documentation Set z Obtaining Documentation z Documentation Feedback

Audience

This documentation set is intended for:

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

Document Organization

The Network Management and Monitoring Configuration Guide comprises these part s:

System Maintenance and Debugging

PoE Configuration SNMP Configuration MIB Configur ation RMON Configuration Cluster Management

Configuration

NetStream Configuration

NQA Configuration NTP Configuration IPC Configuration

Sampler Configuration

IPv6 NetStream Configuration

Port Mirroring Configuration

sFlow Configuration

Traffic Mirroring Configuration

Information Center Configuration

Page 4

Conventions

This section describes the conventions used in this documentation set.

Command conventions

Convention Description

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

italic

[ ]

{ 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 S5800&S5820X Documentation Set

The H3C S5800&S5820X documentation set also includes:

Category Documents Purposes

Product description and specifications

Pluggable module description

Marketing brochures Describe product specifications and benefits.

Technology white papers

PSR150-A [ PSR150-D ] Power Modules User Manual

PSR300-12A [ PSR300-12D1 ] Power Modules User Manual

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

Describes the appearances, features, specifications, installation, and removal of the pluggable 150W power modules available for the products.

Describes the appearances, features, specifications, installation, and removal of the pluggable 300W power modules available for the products.

Page 5

Category Documents Purposes

PSR750-A [ PSR750-D ] Power Modules User Manual

RPS User Manual

LSW1FAN and LSW1BFAN Installation Manual

LSW148POEM Module User Manual

S5820X [ S5800 ] Series Ethernet Switches Interface Cards User Manual

H3C OAP Cards User Manual

H3C Low End Series Ethernet Switches Pluggable Modules Manual

Describes the appearances, features, specifications, installation, and removal of the pluggable 750W power modules available for the products.

Describes the appearances, features, and specifications of the RPS units available for the products.

Describes the appearances, specifications, installation, and removal of the pluggable fan modules available for the products.

Describes the appearance, features, installation, and removal of the pluggable PoE module available for the products.

Describes the models, hardware specifications, installation, and removal of the interface cards available for the products.

Describes the benefits, features, hardware specifications, installation, and removal of the OAP cards available for the products.

Describes the models, appearances, and specifications of the pluggable modules available for the products.

Power configuration

Hardware installation

S5800-60C-PWR Ethernet Switch Hot Swappable Power Module Ordering Guide

RPS Ordering Information for H3C Low-End Ethernet Switches

z S5800 Series

Ethernet Switches Quick Start

z S5820X Series

Ethernet Switches Quick Start

z S5800 Series

Ethernet Switches CE DOC

z S5820X Series

Ethernet Switches CE DOC

z S5800 Series

Ethernet Switches Quick Start

z S5820X Series

Ethernet Switches Quick Start

Guides you through ordering the hot-swappable power modules available for the S5800-60C-PWR switches in different cases.

Provides the RPS and switch compatibility matrix and RPS cable specifications.

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

Guides you through initial installation and setup procedures to help you quickly set up and use your device with the minimum configuration.

Page 6

Category Documents Purposes

z S5800 Series

Ethernet Switches Installation Manual

z S5820X Series

Ethernet Switches Installation Manual

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

z S5800-60C-PWR

Switch Video Installation Guide

z S5820X-28C Switch

Video Installation Guide

Provides a complete guide to hardware installation and hardware specifications.

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

Shows how to install the H3C S5800-60C-PWR and H3C S5820X-28C Ethernet switches.

Software configuration

Operations and maintenance

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, software

upgrading, and software feature configuration and maintenance documentation.

[Products & Solutions] – Provides information about products an d technologies, as well as solutions.

Configuration guide

Command reference Provide a quick reference to all available commands. H3C Series Ethernet

Switches Login Password Recovery Manual

Release notes

Describe software features and configuration procedures.

Tells how to find the lost password or recover the password when the login password is lost.

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

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

the software version.

Documentation Feedback

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

Page 7

1 System Maintenance 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-3 NQA Configuration Task List ···············································································································2-4 Configuring the NQA Server················································································································2-5 Enabling the NQA Client······················································································································2-5 Creating an NQA Test Group ··············································································································2-5 Configuring an NQA Test Group··········································································································2-6

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

Configuring a DHCP Test·············································································································2-7

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 DLSw Test ···········································································································2-18 Configuring the Collaboration Function ·····························································································2-19 Configuring Trap Delivery··················································································································2-20 Configuring the NQA Statistics Function ···························································································2-20 Configuring the History Records Saving Function·············································································2-21 Configuring Optional Parameters Common to an NQA Test Group··················································2-22 Scheduling an NQA Test Group ········································································································2-23 Displaying and Maintaining NQA·······································································································2-24 NQA Configuration Examples············································································································2-25

Page 8

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

DHCP Test Configuration Example····························································································2-26

DNS Test Configuration Example ······························································································2-27

FTP Test Configuration Example ·······························································································2-28

HTTP Test Configuration Example·····························································································2-29

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

SNMP Test Configuration Example····························································································2-33

TCP Test Configuration Example·······························································································2-34

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

DLSw Test Configuration Example ····························································································2-36

NQA Collaboration Configuration Example················································································2-37

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

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

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

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

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

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

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

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

Configuring NTP Broadcast Mode······························································································3-10

Configuring NTP Multicast Mode································································································3-11 Configuring Optional Parameters of NTP ··························································································3-12

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

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

Configuring the Maximum Number of Dynamic Sessions Allowed ············································3-13 Configuring Access-Control Rights····································································································3-14

Configuration Prerequisites········································································································3-14

Configuration Procedure ············································································································3-14 Configuring NTP Authentication ········································································································3-15

Configuration Prerequisites········································································································3-15

Configuration Procedure ············································································································3-15 Displaying and Maintaining NTP········································································································3-17 NTP Configuration Examples ············································································································3-18

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

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

Configuring NTP Broadcast Mode······························································································3-20

Configuring NTP Multicast Mode································································································3-22

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

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

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

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

Introduction to IPC························································································································4-1 Enabling IPC Performance Statistics Collection··················································································4-2

Page 9

Displaying and Maintaining IPC···········································································································4-3

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

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

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

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

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

Enabling the PSE to Detect Non-Standard PDs···········································································5-5

Configuring a PD Disconnection Detection Mode········································································5-5 Configuring the Maximum PoE Interface Power··················································································5-6 Configuring PoE Power Management··································································································5-6

Configuring PoE Interface Power Management···········································································5-6 Configuring the PoE Monitoring Function····························································································5-8

Configuring PSE Power Monitoring······························································································5-8

Monitoring PD·······························································································································5-8 Configuring PoE Interface Through PoE Profile··················································································5-8

Configuring PoE Profile················································································································5-9

Applying PoE Profile·····················································································································5-9 Upgrading PSE Processing Software in Service ···············································································5-10 Displaying and Maintaining PoE········································································································5-11 PoE Configuration Example···············································································································5-11 Troubleshooting PoE ·························································································································5-12

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

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

iii

Page 10

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

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

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

Working Mechanism·····················································································································8-1

RMON Groups······························································································································8-2 Configuring the RMON Statistics Collection························································································8-3

Configuring RMON Ethernet Statistics Collection········································································8-4

Configuring RMON History Statistics Collection···········································································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

9 Cluster Management Configuration ·····································································································9-1

Cluster Management Overview ···········································································································9-1

What is Cluster Management·······································································································9-1

Roles in a Cluster·························································································································9-1

How a Cluster Works····················································································································9-2 Cluster Configuration Task List············································································································9-6 Configuring the Management Device ··································································································9-7

Enabling NDP Globally and for Specific Ports··············································································9-7

Configuring NDP Parameters·······································································································9-8

Enabling NTDP Globally and for Specific Ports ···········································································9-9

Configuring NTDP Parameters·····································································································9-9

Manually Collecting Topology Information ·················································································9-10

Enabling the Cluster Function····································································································9-10

Establishing a Cluster·················································································································9-11

Enabling Management VLAN Auto-Negotiation ·········································································9-12

Configuring Communication Between the Management Device and the Member Devices·······9-12

Configuring Cluster Management Protocol Packets···································································9-13

Cluster Member Management····································································································9-13 Configuring the Member Devices ······································································································9-14

Enabling NDP·····························································································································9-14

Enabling NTDP···························································································································9-14

Manually Collecting Topology Information ·················································································9-14

Enabling the Cluster Function····································································································9-15

Deleting a Member Device from a Cluster ·················································································9-15 Configuring Access Between the Management Device and Member Devices··································9-15 Adding a Candidate Device to a Cluster····························································································9-16 Configuring Advanced Cluster Functions ··························································································9-16

Configuring Topology Management ···························································································9-16

Configuring Interaction for a Cluster ··························································································9-17

SNMP Configuration Synchronization························································································9-19

Page 11

Configuring Web User Accounts in Batches ··············································································9-20 Displaying and Maintaining Cluster Management ·············································································9-20 Cluster Management Configuration Example····················································································9-21

10 Sampler Configuration·······················································································································10-1

Sampler Overview ·····························································································································10-1 Creating a Sampler····························································································································10-1 Displaying and Maintaining Sampler ·································································································10-2 Sampler Configuration Examples ······································································································10-2

Using the Sampler with NetStream ····························································································10-2

11 Port Mirroring Configuration·············································································································11-1

Introduction to Port Mirroring·············································································································11-1

Classification of Port Mirroring ···································································································11-1

Implementing Port Mirroring·······································································································11-2 Configuring Local Port Mirroring········································································································11-4

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

Creating a Local Mirroring Group·······························································································11-5

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

Configuring Mirroring CPUs for the Local Mirroring Group ························································11-6

Configuring the Monitor Port for the Local Mirroring Group ·······················································11-7 Configuring Layer 2 Remote Port Mirroring·······················································································11-8

Layer 2 Remote Port Mirroring Configuration Task List·····························································11-8

Configuration Prerequisites········································································································ 11-9

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

Configuring a Remote Destination Mirroring Group (on the Destination Device)·····················11-12 Configuring Layer 3 Remote Port Mirroring·····················································································11-14

Layer 3 Remote Port Mirroring Configuration Task List···························································11-14

Configuration Prerequisites······································································································ 11-15

Configuring Local Mirroring Groups ·························································································11-15

Configuring Mirroring Ports for a Local Mirroring Group ··························································11-16

Configuring Mirroring CPUs for a Local Mirroring Group ·························································11-17

Configuring the Monitor Port for a Local Mirroring Group ························································11-17 Displaying and Maintaining Port Mirroring·······················································································11-18 Port Mirroring Configuration Examples····························································································11-18

Local Port Mirroring Configuration Example (in Mirroring Port Mode) ·····································11-18

Layer 2 Remote Port Mirroring Configuration Example···························································· 11-19

Layer 3 Remote Port Mirroring Configuration Example···························································· 11-21

12 Traffic Mirroring Configuration·········································································································12-1

Traffic Mirroring Overview··················································································································12-1 Configuring Traffic Mirroring··············································································································12-1

Mirroring Traffic to an Interface··································································································12-1

Mirroring Traffic to the CPU········································································································12-2

Applying a QoS Policy················································································································12-3 Displaying and Maintaining Traffic Mirroring······················································································12-5 Traffic Mirroring Configuration Examples ·························································································· 12-5

Example for Mirroring Traffic to an Interface·············································································· 12-5

Page 12

Configuration Procedure ············································································································ 12-5

13 NetStream Configuration···················································································································13-1

NetStream Overview ··························································································································13-1 Basic Concepts of NetStream············································································································13-2

What Is a Flow····························································································································13-2

How NetStream Works···············································································································13-2 Key Technologies of NetStream········································································································13-3

Flow Aging··································································································································13-3

NetStream Data Export ··············································································································13-3

NetStream Export Formats·········································································································13-5 Introduction to NetStream Sampling and Filtering·············································································13-5

NetStream Sampling ··················································································································13-5

NetStream Filtering ····················································································································13-6 NetStream Configuration Task List····································································································13-6 Enabling NetStream···························································································································13-7 Configuring NetStream Filtering and Sampling ················································································· 13-7

Configuring NetStream Filtering·································································································13-7

Configuring NetStream Sampling·······························································································13-9 Configuring NetStream Data Export ································································································13-10

Configuring NetStream Common Data Export ·········································································13-10

Configuring NetStream Aggregation Data Export ····································································13-11 Configuring Attributes of NetStream Export Data············································································13-13

Configuring NetStream Export Format·····················································································13-13

Configuring Refresh Rate for NetStream Version 9 Templates ··············································· 13-14 Configuring NetStream Flow Aging ·································································································13-15

Flow Aging Approaches ···········································································································13-15

Configuring NetStream Flow Aging··························································································13-16 Displaying and Maintaining NetStream····························································································13-16 NetStream Configuration Examples ································································································13-17

NetStream Common Data Export Configuration Example ·······················································13-17

NetStream Aggregation Data Export Configuration Example ··················································13-17

14 IPv6 NetStream Configuration ··········································································································14-1

IPv6 NetStream Overview ·················································································································14-1 Basic Concepts of IPv6 NetStream ···································································································14-2

What Is an IPv6 Flow ················································································································· 14-2

How IPv6 NetStream Works·······································································································14-2 Key Technologies of IPv6 NetStream································································································14-3

Flow Aging··································································································································14-3

IPv6 NetStream Data Export······································································································14-3

IPv6 NetStream Export Formats ································································································14-4 Introduction to IPv6 NetStream Sampling and Filtering·····································································14-4

IPv6 NetStream Sampling··········································································································14-4

IPv6 NetStream Filtering ············································································································14-4 IPv6 NetStream Configuration Task List····························································································14-5 Enabling IPv6 NetStream ··················································································································14-5

Page 13

Configuring IPv6 NetStream Data Export··························································································14-6

Configuring IPv6 NetStream Common Data Export···································································14-6

Configuring IPv6 NetStream Aggregation Data Export······························································14-7 Configuring Attributes of IPv6 NetStream Data Export······································································14-9

Configuring IPv6 NetStream Export Format···············································································14-9

Configuring Refresh Rate for IPv6 NetStream Version 9 Templates ·········································14-9 Displaying and Maintaining IPv6 NetStream ···················································································14-11 IPv6 NetStream Configuration Examples ························································································14-11

IPv6 NetStream Common Data Export Configuration Example···············································14-11

Pv6 NetStream Aggregation Data Export Configuration Example ···········································14-12

15 sFlow Configuration···························································································································15-1

sFlow Overview ·································································································································15-1

Introduction to sFlow··················································································································15-1

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

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

16 Information Center Configuration·····································································································16-1

Information Center Overview·············································································································16-1

Introduction to Information Center······························································································16-1

Classification of System Information ··························································································16-2

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

Eight Output Destinations and Ten Channels of System Information ········································16-3

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

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

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

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

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

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

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

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

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

Outputting System Information to the SNMP Module·······························································16-13

Outputting System Information to the Web Interface ·······························································16-15

Saving System Information to a Log File·················································································· 16-16

Configuring Synchronous Information Output··········································································16-17

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

Outputting Log Information to a Unix Log Host········································································16-19

Outputting Log Information to a Linux Log Host·······································································16-21

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

vii

Page 14

17 Index····················································································································································17-1

viii

Page 15

1 System Maintenance and Debugging

This chapter includes these sections:

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

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

The ping command allows you 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 interface-type interfac e-numb er | -m interval | -n | -p pad | -q | -r | -s packet-size | -t timeout |

-vpn-instance

ping ipv6

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

vpn-instance-name ] * host

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

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

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

Ping Configuration Example

Network requirements

As shown in Figure 1-1, check whether Device A and Device C can reach each other. If they can reach each other, get the detailed information of routes from Device A to Device C.

Figure 1-1 Ping network diagram

Configuration procedure

# Use the ping command to display whether Device A and Device C can reach each other.

<DeviceA> ping 1.1.2.2 PING 1.1.2.2: 56 data bytes, press CTRL_C to 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 statistics ---

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 PING 1.1.2.2: 56 data bytes, press CTRL_C to break Reply from 1.1.2.2: bytes=56 Sequence=1 ttl=254 time=53 ms Record Route:

1.1.2.1

1-2

Page 17

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

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 18

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

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

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

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

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

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

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

Figure 1-2:

Configuring Tracert

Configuration prerequisites

z Enable sending of ICMP timeout packets on the intermediate device (the device between the

source and destination devices). If the intermediate device is an H3C device, execute the ip

ttl-expires enable command on the device. For more information about this command, see IP Performance Optimization Configuration Commands in the Layer 3 - IP Services Command Reference.

1-4

Page 19

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

destination device is an H3C device, execute the ip unreachables enable command. For more information about this command, see IP Performance Optimization Configuration Commands in the Layer 3 - IP Services Command Reference.

Tracert configuration

Follow these steps to configure tracert:

To do… Use the command… Remarks

Enter system view

Display the routes from source to destination

system-view

tracert

max-ttl |

-vpn-instance

timeout ] * host

tracert ipv6

port | -q packet-number | -w timeout ] * host

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.

[ -a source-ip | -f first-ttl |

-p

port | -q packet-number |

vpn-instance-name |

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

-m

—

Required Use either approach

-w tracert

The applicable in an IPv4 network;

tracert ipv6

the applicable in an IPv6 network.

Available in any view

command is

z Screen output switch, which controls whether to display the debugging information on a certain

screen.

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

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

1-5

Page 20

Figure 1-3 The relationship between the protocol and screen output 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. Administrators usually use the debugging commands to diagnose 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 depends on the configurations of the information center 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 more information, see Information Center Configuration 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 21

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 debugging [ interface

Display the enabled debugging functions

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

exclude | include

regular-expression ]

begin

}

To display the detailed debugging information on the terminal, configure the debugging, terminal debugging and terminal m onitor commands. For more information about the terminal debugging and terminal monitor commands, see Information Center Configuration Commands in the Network Management and Monitoring Command Reference.

Ping and Tracert Configuration Example

Network requirements

Optional

Available in any view

As shown in Figure 1-4, Device A failed to telnet Device C. It is required to determine whether Device A and Device C can reach each other. If they cannot reach each other, locate the failed nodes in the network.

Figure 1-4 Ping and tracert network diagram

Configuration procedure

# Use the ping command to display whether Device A and Device C can reach each other.

<DeviceA> ping 1.1.2.2 PING 1.1.2.2: 56 data bytes, press CTRL_C to break Request time out Request time out Request time out Request time out Request time out

--- 1.1.2.2 ping statistics -- 5 packet(s) transmitted 0 packet(s) received

1-7

Page 22

100.00% packet loss

# Device A and Device C cannot reach each other. 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 Device A and Device C cannot reach other, Device A and Device B can reach each other, and an error occurred on the connection between Device B and Device C. In this case, 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 use the display ip routing-table command to display whether Device A and Device C can reach each other.

1-8

Page 23

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 support s ten test types: ICMP echo, DHCP , DNS, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo 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 24

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 more information about 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 25

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. 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 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 tests, you only need to configure the NQA client; while in TCP, UDP echo, and UDP jitter 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.

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.

2-3

Page 26

NQA Configuration Task List

To perform TCP, UDP jitter or UDP echo tests, 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 and UDP jitter 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 ICMP Echo Test

Configuring a DHCP Test

Configuring an FTP Test

Configuring a DNS Test

Configuring an HTTP Test

Configuring an NQA Test Group

Configuring a UDP Jitter Test

Configuring an SNMP Test

Configuring a TCP Test

Configuring a UDP Echo Test

Configuring a DLSw Test

Required Use any of the approaches

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

2-4

Page 27

Task Remarks

Scheduling an NQA Test Group Required

Configuring the NQA Server

Before performing TCP, UDP echo or UDP jitter tests, configur e 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

Creating an NQA Test Group

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

Follow theses steps to create an NQA test group:

—

Optional Enabled by default.

2-5

Page 28

To do… Use the command… Remarks

Enter system view

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

system-view

nqa entry

operation-tag

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.

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.

admin-name

—

Required

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

Configure the size of probe packets sent

Configure the filler string of a probe packet sent

system-view

nqa entry

operation-tag

type icmp-echo

destination ip

data-size

data-fill

admin-name

ip-address

size

string

—

Required

Required By default, no destination IP

address is configured for a test operation.

Optional 100 bytes by default.

Optional By default, the filler string of a

probe packet is the hexadecimal number 00010203040506070809.

Specify a VPN instance

vpn-instance

instance

Optional Not specified by default.

2-6

Page 29

To do… Use the command… Remarks

Optional By default, no interface address is

specified as the source IP address of ICMP probe requests.

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

Configure the source IP address of a probe request

source interface

interface-number

source ip

ip-address

interface-type

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.

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.

source ip

command is

command

Configure the next hop IP address for an ICMP echo request

Configure common optional parameters

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

next-hop

See

Parameters Common to an NQA Test Group

ip-address

Configuring Optional

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

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

2-7

Page 30

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.

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:

2-8

Page 31

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:

To do… Use the command… Remarks

Enter system view

system-view

2-9

—

Page 32

To do… Use the command… Remarks

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

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 33

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 34

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 35

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 36

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 37

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 38

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 39

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 40

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 DLSw Test

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

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

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

system-view

nqa entry

operation-tag

type dlsw

destination ip

admin-name

ip-address

—

Required

Required By default, no destination IP

address is configured for a test operation.

Optional

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

source ip

ip-address

2-18

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.

Page 41

To do… Use the command… Remarks

See

Configure common optional parameters

Configuring Optional Parameters Common to an NQA Test Group

Optional

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

Enter test type view of the test group

Configure a reaction entry

system-view

nqa entry

operation-tag

type

{

icmp-echo

udp-echo }

reaction checked-element probe-fail threshold-type consecutive

occurrences [

trigger-only

admin-name

dhcp

dlsw

snmp

item-num

action-type

} ]

dns

tcp

—

ftp

http

{

none

The collaboration function is not supported in UDP jitter tests.

Required Not created by default.

Exit to system view

Configure a track entry and associate it with the specified reaction entry of the NQA test group

quit

track

entry-number admin-name operation-tag item-num

nqa entry

reaction

—

Required Not created by default.

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

reaction entry is created.

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

2-19

Page 42

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, configure the destination address of the trap message with the snmp-agent target-host comman d, 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

Enter test type view of the test group

system-view

nqa entry

type

snmp

admin-name operation-tag

dhcp

{

tcp

dlsw

dns

ftp

udp-echo | udp-jitter }

http

icmp-echo

—

Optional

Configure to send traps to network management server under specified conditions

reaction trap { probe-failure

consecutive-probe-failures |

test-failure

cumulate-probe-failures }

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.

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.

test-complete

No traps are sent to

the network management server by default.

Follow these steps to configure the NQA statistics function:

To do… Use the command… Remarks

Enter system view

Enter NQA test group view

system-view

nqa entry

operation-tag

admin-name

2-20

—

Page 43

To do… Use the command… Remarks

type

dlsw

dns

ftp

Enter test type view of the test group

{

icmp-echo udp-echo | udp-jitter }

snmp

http

tcp

—

Configure the interval for collecting the statistics of the test results

Configure the maximum number of statistics groups that can be kept

Configure the hold time of a statistics group

statistics interval

statistics max-group

statistics hold-time

interval

number

hold-time

Optional 60 minutes by default.

Optional 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

system-view

nqa entry

type icmp-echo udp-jitter }

admin-name operation-tag

dhcp

{

dlsw

snmp

| |

dns

tcp

ftp

http

udp-echo |

—

2-21

Page 44

To do… Use the command… Remarks

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

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 enable

history-record keep-time

history-record number

number

keep-time

Required By default, history records of

the NQA test group are not saved.

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

system-view

nqa entry

operation-tag

type

{

http

udp-echo | udp-jitter }

description

admin-name

dhcp

dlsw | dns

icmp-echo

text

snmp

ftp

tcp

—

Optional By default, no descriptive string is

available for a test group.

2-22

Page 45

To do… Use the command… Remarks

Optional By default, the interval between

two consecutive tests for a test

Configure the interval between two consecutive tests for a test group

frequency

interval

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

Configure the number of probes in an NQA test

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

probe count

probe timeout

ttl

value

tos

value

times

timeout

Optional By default, one probe is performed

in a test.

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

Enable the routing table bypass function

route-option bypass-route

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.

Optional Disabled by default. This parameter is not available for

a DHCP test.

2-23

Page 46

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

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

operation-tag

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

lifetime {

nqa agent max-concurrent

number

lifetime |

admin-name

start-time

forever }

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 nqa history

operation-tag ]

display nqa result

operation-tag ]

2-24

[ admin-name

Available in any view

Page 47

To do… Use the command… Remarks

Display the statistics of a type of NQA test

Display NQA server status

display nqa statistics

operation-tag ]

display nqa server status

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

[ admin-name

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

Page 48

Last succeeded probe time: 2007-08-23 15:00:01.2 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 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

As shown in Figure 2-4, use the NQA DHCP function to test the time necessary for Device A to obtain an IP address from the DHCP server Device B.

Figure 2-4 Network diagram for DHCP test

NQA client

Configuration procedure

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

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

# Enable the saving of history records.

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

# Enable DHCP test.

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

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

Vlan-int2

10.1.1.1/16

IP network

Vlan-int2

10.2.2.2/16

DHCP server

Device BDevice A

2-26

Page 49

[DeviceA] undo nqa schedule admin test

# Display the result of the last DHCP test.

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

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

2-27

Page 50

[DeviceA] undo nqa schedule admin test

# Display results of the last DNS 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: 62/62/62 Square-Sum of round trip time: 3844 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.

2-28

Page 51

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

[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

2-29

Page 52

[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

# 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

2-30

Page 53

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

2-31

Page 54

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: NO. : 1 Destination IP address: 10.2.2.2 Start time: 2008-05-29 13:56:14.0 Life time: 47 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

2-32

Page 55

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.

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

2-33

Page 56

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

2-34

Page 57

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

[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: 13/13/13 Square-Sum of round trip time: 169 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

2-35

Page 58

[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

# 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

DLSw Test Configuration Example

Network requirements

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

Figure 2-12 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

2-36

Page 59

[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

NQA Collaboration Configuration Example

Network requirements

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

2-37

Page 60

Figure 2-13 Network diagram for NQA collaboration configuration example

Vlan-int3

10.2.1.1/24

Vlan-int3

10.2.1.2/24

Device A

Device B

Vlan-int2

10.1.1.1/24

Vlan-int2

10.1.1.2/24

Device C

Configuration procedure

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

2) On Device 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.

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

3) On Device A, create an NQA test group. # Create an NQA test group with the administrator name being admin and operation tag being test.

[DeviceA] nqa entry admin test

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

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

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

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

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

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

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

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

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

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

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

[DeviceA] track 1 nqa entry admin test reaction 1

5) Verify the configuration. # On Device A, display information about all the track entries.

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

2-38

Page 61

Reaction: 1

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

[DeviceA] 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 Device B.

<DeviceB> system-view [DeviceB] interface vlan-interface 3 [DeviceB-Vlan-interface3] undo ip address

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

[DeviceA] 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 Device A.

[DeviceA] 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-39

Page 62

3 NTP Configuration

This chapter includes these sections:

z NTP Overview z NTP Configuration Task List z Configuring the Operation Modes of NTP 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 that runs NTP, its time can be synchronized by other reference sources and used as a reference source to synchronize other clocks.

Applications of NTP

An administrator is unable to 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 high 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.

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

synchronized between the backup server and all the clients.

3-1

Page 63

z Clock stratum determines the accuracy of a server, which ranges from 1 to 16. The stra tum

of a reference clock ranges from 1 to 15. The clock accuracy decreases as the stratum number increases. A stratum 16 clock is in the unsynchronized state and cannot serve as a reference clock.

z The local clock of an S5820X&S5800 series Ethernet switch cannot operate as a reference

clock. It can serve as an NTP server only after being s ynchronized.

NTP features these advantages:

z NTP uses stratum to describe the clock precision, and is able to synchronize time among

all devices within a 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 work flow of NTP. Device A and Device B are connected over a

network. They have their own independent system clocks, which need to be automatically synchronized through NTP. For an easy understanding, assume tha t:

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.

3-2

Page 64

Figure 3-1 Basic work flow of NTP

NTP message

Device A

NTP message received at 10:00:03 am

Device A

10:00:00 am

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

IP network

NTP message

IP network

Device BDevice A

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

Device B

The process of system clock synchronization is as follows:

z Device A sends Device B an NTP message, which is time stamped when it leaves Device A.

The time stamp is 10:00:00 am (T1).

z When this NTP message arrives at Device B, it is time stamped by Device B. The

timestamp is 11:00:01 am (T2).

z When the NTP message leaves Device B, Device B time stamps 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 parameter s:

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 th e clock of Device B. This is only a rough description of the work mechanism of NTP. For details, refer to R FC 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. Because it is not a must for clock synchronization, it is not described in this documen t.

3-3

Page 65

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

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

Figure 3-2.

Figure 3-2 Clock synchronization message format

Main fields of a clock synchronization message are described a s 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: An 8-bit signed integer indicating the poll interval, namely the maximum interval

between successive messages.

z Precision: An 8-bit signed integer indicating the precision o f 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.

3-4

Page 66

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 send end for

the service host.

z Receive Timestamp: The local time at which the request arrived a t the receive end . z Transmit Timestamp: The local time at which the reply departed from the service host for

the client.

z Authenticator: Authentication information.

Operation Modes of NTP

Devices that run NTP implement clock synchronization in one of the following modes :

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

You can select operation modes of NTP as needed. If the IP address of an NTP server or peer is unknown and many devices in the network need to be synchronized, adopt the broadcast or multicast mode. In the client/server and symmetric peers modes, a device is synchronized fro m the specified server or 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 filters clocks, 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.

Symmetric peers mode

3-5

Page 67

Figure 3-4 Symmetric peers mode

In the symmetric peers mode, devices that work in the symmetric active mode and symmetric passive mode exchange NTP messages with the Mode field 3 (client mode) and 4 (server mode). Then the device that works in the symmetric active mode periodically sends clock synchronization messages, with the Mode field in the messages set to 1 (symmetric active); the device that receives the messages automatically enters the symmetric passive mode and sends a reply, with the Mode field in the message set to 2 (symmetric 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 synchronizes 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 68

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.

NTP Configuration Task List

Complete the following tasks to configure NTP:

Task Remarks

Configuring the Oper ation Modes of NTP

Configuring Optional Parameters of NTP

Configuring Access-Control Rights

Configuring NTP Authentication

Required

Optional

3-7

Page 69

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

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

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 is removed if the system fails to receive messages from it over a specific long time. In the client/server mode, for example, when you execute a command to synchronize the time to a server, the system creates a static association, and the server responds passive ly upon the receipt of a message, rather than creating an association (static o r dynamic). In the symmetric mode, static associations are created at the symmetric-active peer side, and dynamic associations are created at the symmetric-passive peer side; in the broadcast or multicast mode, static associations are created at the server side, and dynamic associations are created at the clien t side.

Configuring NTP Client/Server Mode

For devices that work in the client/server mode, 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-8

Page 70

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 is 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 when its clock

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

z To configure multiple servers, repeat the ntp-service unicast-server command. The

clients will select the optimal reference source.

Configuring the NTP Symmetric Peers Mod e

For devices that work in the symmetric mode, 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-9

Page 71

z In the symmetric mode, use any NTP configuration command in Configuring the Operation

Modes of NTP

to enable NTP. Otherwise, a symmetric-passive peer does not process N TP

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 is 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 does not proceed.

z To configure multiple symmetric-passive peers. repeat the ntp-se rvice 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 that work in NTP broadcast client mode sends a reply and synchronizes its local clock.

For devices that work in the broadcast mode, configure both the server and clients. Because an interface needs to be specified on the broadcast server for sending NTP broadcast messages and an interface also needs to be specifie d 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

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

system-view

interface

interface-number

ntp-service broadcast-client

interface-type

—

— Enter the interface used to

receive NTP broadcast messages.

Required

Configuring the broadcast server

To do… Use the command… Remarks

Enter system view

system-view

—

3-10

Page 72

To do… Use the command… Remarks

Enter interface view

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

interface

interface-number

ntp-service broadcast-server

[

version

A broadcast server can synchronize broadcast clients only when 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.

For devices that work in the multicast mode, configure both the server and clients. The NTP multicast mode must be configured in the specific interface view.

interface-type

authentication-keyid

number ] *

keyid |

Enter the interface used to send NTP broadcast messages.

Required

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 ]

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 receive NTP multicast messages.

Required

—

Enter the interface used to send NTP multicast message.

3-11

Page 73

To do… Use the command… Remarks

ntp-service multicast-server

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

[ ip-address ]

authentication-keyid

[

ttl

ttl-number |

versi on

keyid |

number ]

z A multicast server can synchronize broadcast clients only when its c lock is synchronized. z You can configure up to 1024 multicast clients, among which 128 can take effect at the

same time.

Configuring Optional Parameters of NT P

Specifying the Source Interface fo r NTP Messages

Required

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.

Follow 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-12

Page 74

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

Required 100 by default

Page 75

Configuring Access-Control Rights

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 leve l of right 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 performs an access-control right match and uses the first matched right.

Configuration Prerequisites

Prior to configuring the NTP service access-control right to the local device, create and configure an ACL associated with the access-control right. For the configuration of ACL, see 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-14

Page 76

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

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 NTP authentication, note the following:

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

an authentication key and specify it as a trusted key. In other words, 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, 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, associate the specified

authentication key on the broadcast server or multicast server with the corr esponding NTP server. Otherwise, the NTP authentication fea ture cannot be normally enab led.

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 configurations on the server and client s ide must be the

same.

Configuration Procedure

Configuring NTP authentication for a client

Follow these steps to configure NTP authentication for a client:

3-15

Page 77

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 NT P 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-16

Page 78

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 NT P 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 information about NTP service status

View information about NTP sessions

View brief information about 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-17

Page 79

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 mode and Device A is to be used as the NTP server of Device

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 B: # View the NTP status of Device B before clock synchronization.

<DeviceB> display ntp-service sta tus Clock s tatus: unsync hronized Clock s tratum: 16 Reference clo ck ID: none Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz Clock p recision: 2^1 8 Clock o ffset: 0.0000 ms Root de lay: 0.00 ms Root di spersion: 0.0 0 ms Peer di spersion: 0.0 0 ms Referen ce time: 00:0 0:00.000 UT C Jan 1 1 900 (000000 00.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 s tatus: synchr onized Clock s tratum: 3 Reference clo ck ID: 1.0.1.11 Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz Clock p recision: 2^1 8 Clock o ffset: 0.0000 ms Root delay: 31.0 0 ms Root di spersion: 1.0 5 ms Peer di spersion: 7.8 1 ms

3-18

Page 80

Reference tim e: 14:53:27.371 UT C Sep 19 2005 (C6D94F6 7.5EF9DB22)

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 After Device B is synchronized to Device A , 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 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

3) View the NTP s tatus of Device B a fter clock synchronization.

[DeviceB] display ntp-service sta tus Clock s tatus: synchr onized Clock s tratum: 3

3-19

Page 81

Reference clo ck ID: 3.0.1.31 Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz Clock p recision: 2^1 8 Clock o ffset: -21.19 82 ms Root delay: 15.0 0 ms Root dispersi on: 775.15 ms Peer di spersion: 34. 29 ms Reference tim e: 15:22:47.083 UT C Sep 19 2005 (C6D9564 7.153F7CED)

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

4) Configuration on Device C (after Device B is synchronized to Device A) : # 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 16 while that of Device B is 3, Device B is synchronized to Device C.

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

[DeviceC] display ntp-service sta tus Clock s tatus: synchr onized Clock s tratum: 4 Reference clo ck ID: 3.0.1.32 Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz Clock p recision: 2^1 8 Clock o ffset: -21.19 82 ms Root delay: 15.0 0 ms Root dispersi on: 775.15 ms Peer di spersion: 34. 29 ms Reference tim e: 15:22:47.083 UT C Sep 19 2005 (C6D9564 7.153F7CED)

As shown above, Device C has been synchronized to Device B an d the clock stratum level of Device C is 4.

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

[DeviceC] display ntp-service ses sions source reference stra reach poll now offset delay disper **************************** ******** *********** *********** *********** *********** [12345] 3.0.1.32 3.0.1.31 3 3 64 16 -6.4 4.8 1.0 note: 1 source(master),2 source(p eer),3 selecte d,4 candidate,5 co nfigured Total associations : 1

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

3-20

Page 82

z Switch C works in the broadcast server mode and sends out broadcast messages from

VLAN-interface 2.

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 receiving a broadcast mess age from Switch C. # View the NTP status of Switch A after clock synchronization.

[SwitchA-Vlan-interface2] di splay nt p-service s tatus Clock s tatus: synchr onized Clock s tratum: 3 Reference clo ck ID: 3.0.1.31 Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz

3-21

Page 83

Clock p recision: 2^1 8 Clock o ffset: 0.0000 ms Root delay: 31.0 0 ms Root di spersion: 8.3 1 ms Peer di spersion: 34. 30 ms Reference tim e: 16:01:51.713 UT C Sep 19 2005 (C6D95F6 F.B6872B02)

As shown above, Switch A has been synchronized to Switch C, and the clock stratum level of Switch A is 3, while that of Swi tch 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 multip le devices on different network segments and synchronizes the time among multiple devices. 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:

3-22

Page 84

# 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 s tatus: synchr onized Clock s tratum: 3 Reference clo ck ID: 3.0.1.31 Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz Clock p recision: 2^1 8 Clock o ffset: 0.0000 ms Root delay: 31.0 0 ms Root di spersion: 8.3 1 ms Peer di spersion: 34. 30 ms Reference tim e: 16:01:51.713 UT C Sep 19 2005 (C6D95F6 F.B6872B02)

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 the IP multicast function.

<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 1/0/1

3-23

Page 85

[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 1/0/1 [SwitchB-GigabitEthernet1/0/ 1] igmp- snooping st atic-group 224.0.1.1 v lan 3

5) Configuration on Switch A:

<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 s tatus: synchr onized Clock s tratum: 3 Reference clo ck ID: 3.0.1.31 Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz Clock p recision: 2^1 8 Clock o ffset: 0.0000 ms Root delay: 40.0 0 ms Root di spersion: 10. 83 ms Peer di spersion: 34. 30 ms Reference tim e: 16:02:49.713 UT C Sep 19 2005 (C6D95F6 F.B6872B02)

As shown above, Switch A has been synchronized to Switch C, and the clock stratum level of Switch A is 3, while that of Swi tch 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

See IGMP Configuration and PIM Configuration in the IP Multicast Configuration Guide for introduction to the IP multicast technology.

3-24

Page 86

Configuring NTP Client/Server Mode with Authentication

Network requirements

As shown in Figure 3-11, perform the following configurations to synchronize the time between Device B and Device A and ensure clock synchronization sec urity.

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

3-25

Page 87

Clock o ffset: 0.0000 ms Root delay: 31.0 0 ms Root di spersion: 1.0 5 ms Peer di spersion: 7.8 1 ms Reference tim e: 14:53:27.371 UT C Sep 19 2005 (C6D94F6 7.5EF9DB22)

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 the same network segment and synchronizes the time among multiple devices. 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

Configuration procedure

1) Configure IP addresses for in terfaces (omitted)

2) Configuration on Switch C: # Configure NTP authentication.

3-26

Page 88

[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, a nd 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 s tatus: synchr onized Clock s tratum: 4 Reference clo ck ID: 3.0.1.31 Nominal frequency: 1 00.0000 Hz Actual freque ncy: 100.0000 Hz Clock p recision: 2^1 8 Clock o ffset: 0.0000 ms Root delay: 31.0 0 ms Root di spersion: 8.3 1 ms Peer di spersion: 34. 30 ms Reference tim e: 16:01:51.713 UT C Sep 19 2005 (C6D95F6 F.B6872B02)

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 Total associations : 1

3-27

Page 89

4 IPC Configuration

This chapter includes these sections:

z IPC Overview z Enabling IPC Performance Statistics Collection 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 that supports 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) virtual device is an interconnection of several centralized

devices, with each member device corresponding to one node. Therefore, an IRF virtual device corresponds to multiple nodes.

z Typically a distributed device is available with multiple cards, each having one CPU, some cards

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 virtual device or distributed device; it provides a reliable transmission mechanism between different devices and cards.

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 by using link status. An IPC node can have multiple links, each having its own status.

Channel

An IPC channel allows for communication between application modules of peer nodes.. Each node assigns a locally unique channel number to its upper layer application modul e to identify the module.

Data of from an application module is sent to the IPC module through an IPC channel, and the IPC module sends the data to a peer node through the IPC link. The relat ionshi p bet wee n a node, link and channel is as shown in

Figure 4-1.

4-1

Page 90

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 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 are 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: Both unicast and multicast are supported.

Enabling IPC Performance Statistics Collection

When IPC performance statistics collection 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 collection is disabled, statistics collection is stopped. At this time, if you execute the display command, the system displays the statistics at the time when IPC performance statistics collection wa s disabled.

Follow these steps to enable IPC performance statisti cs collection:

To do… Use the command… Remarks

Enable IPC performance statistics collection

ipc performance enable

node-id | channel-id ]

self-node

} [

node

{

channel

Required Disabled by default Available in user view

4-2

Page 91

Displaying and Maintaining IPC

To do… Use the command… Remarks

Display IPC node information

Display channel information about a node

Display queue information about a node

Display multicast group information about a node

Display packet information about a node

Display link status information about a node

Display IPC performance statistics information of a node

Clear IPC performance statistics information about 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

{

node-id |

channel

} [

[

channel

] [

node-id

}

node-id

{

node

Available in any view

Available in user view

4-3

Page 92

5 PoE Configuration

This chapter includes these sections:

z PoE Overview z PoE Configuration Task List z Enabling PoE z Detecting PDs z Configuring the Maximum PoE Interface 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.

z Promising: It can be applied to IP telephones, wireless L AN access points (APs), portable

chargers, card readers, web cameras, and data collectors.

Composition

As shown in Figure 5-1, a PoE system comprises PoE power, PSE, power interface (PI), and PD.

1) PoE power: The whole PoE s ystem is powered by the PoE power.

2) PSE: A device that supplies power to PDs. A PSE can be built-in (Endpoint) or exte rnal

(Midspan). A built-in PSE is integrated in a switch or router, and an external PSE is independent from a switch or router. The PSEs of H3C are built in, and can be classified into two types:

5-1

Page 93

z Device with a single PSE: Only one PSE is available on the device, so the whole devic e is

considered as a PSE.

z Device with multiple PSEs: For a device with multiple PSEs, an in terface board with the

PoE power supply capability is a PSE. The system uses PSE IDs to identify different PSEs. To display the mapping between a PSE ID and the slot number o f an interface board, use the display poe device command .

A PSE can examine the Ethernet cables connected to PoE interfaces, search for PDs, classify them, and manage the power. When detecting that a PD is unplugged, the PSE stops supplying power to the PD.

For an S5820X&S5800 series Ethernet switch, its PSE ID is its member ID multiplies 3 and then plus 1. For example, if the member ID of the device is 3, the PSE ID of the device is 3 × 3 + 1 =

10.

3) PI: An Ethernet interface with the PoE capability is called a Po E interface. Currently, a PoE

interface can be an FE or GE interface.

4) PD: A device that is powered by the PSE, including IP phones, access points (APs),

chargers of portable devices, POS, and web cameras.

A PD that is being powered by the PSE can be connected to another power supply unit for redundancy power backup.

Figure 5-1 PoE system diagram

Protocol Specification

The protocol specification related to PoE is IEEE 802.3af.

PoE Configuration Task List

You can configure a PoE interface in either of the following two ways:

z At the command line interface (CLI). z Through configuring the PoE profile and applying the PoE profile to the PoE interface.

When configuring a single PoE interface, you can configure it at the CLI; when you configure PoE interfaces in batches, you can use the PoE profile. For a PoE configur ation parameter of a

5-2

Page 94

PoE interface, you can only select one mode (including modification and removal of a PoE interface).

Complete these tasks to configure PoE:

Task Remarks

Enabling PoE Enabling PoE for a PoE Interface Required

Detecting PDs

Configuring the M aximum

PoE Interface Power

Configuring PoE Power

Management

Configuring the P oE

Monitoring Functio n

Enabling the PSE to Detect

Non-Standard PDs

Configuring a PD Disconnection

Detection Mode

Configuring the Maxim um PoE

Interface Power

Configuring PoE Interfa ce Power

Management

Configuring PSE Power Monitoring Optional

Monitoring PD

Optional

Optional The device automatical ly

monitors PDs when supplying power to them, so no CLI configuration is required.

Configuring PoE Prof ile Optional

Configuring PoE Inter face

Through PoE Profile

Applying PoE Profile Optional

Upgrading PSE Processing Software in Service Optional

5-3

Page 95

z Before configure PoE, make sure that the PoE power supply and PSE is operating normally;

otherwise, you cannot configure PoE or the configured PoE function does not take e ffect.

z Turning off the PoE power supply during the startup of the device might cause the PoE

configuration in the PoE profile invalid.

Enabling PoE

Enabling PoE for a PoE Interfac e

The system does not supply power to or reserve power for the PDs connected to a PoE interface if the PoE interface is not enabled with the PoE function.

You are allowed to enable Po E for a PoE interface if adding of the PoE interface does not result in PoE power overload; otherwise, whether you can enable PoE for the PoE interface depends on whether the PoE interface is enabled with the PoE power management function (for the detailed description of the PoE power management function, refer to

Management

Configuring PoE Power

z If the PoE interface is not enabled with the PoE p ower management function, you are not

allowed to enable PoE for the PoE interface.

z If the PoE interface is enabled with the PoE power management function , you are allowed

to enable PoE for the PoE interface (whether the PDs can be powered depends on other factors such as the power supply priority of the PoE in terface).

The PSE supplies power for a PoE interface in the following two modes :

z Over signal wires: The PSE uses the pairs (1, 2, 3, 6) for transmitting data in category 3/5

twisted pair cables to supply DC power while transmitting data to PDs.

z Over spare wires: The PSE uses the pairs (4, 5, 7, 8) not transmitting data in category 3/5

twisted pair cables to supply DC power to PDs.

z When the sum of the power consumption of all powered PoE interfaces on a PSE exceeds

the maximum power of the PSE, the system considers the PSE is overloaded (The maximum PSE power depends upon user configuration).

z A PSE can supply power to a PD only when the selected power supply mode is supported

by both the PSE and PD. If the PSE and PD support different power supply modes (for example, the PSE does not support power over spare wires, while the PD only supports power over spare wires), you have to change the order of the lines in the twisted pair c able to supply power to the PD.

Follow these steps to enable PoE for a PoE inter face:

5-4

Page 96

To do… Use the command… Remarks

Enter system view

Enter PoE interface view

Enable PoE for the PoE interface

Configure PoE interface power supply mode

Configure a descriptio n for the PD connected to the PoE interface

Detecting PDs

system-view

interface

interface-number

poe enable

poe mode signal

poe pd-description

interface-type

text

—

Required Disabled by default.

Optional

signal

(power over signal

cables) by default.

Optional By default, no description for the

PD connected to the PoE interface is available.

Enabling the PSE to Detect Non-Standard PDs

There are standard PDs and non-standard PDs. Standard PDs are PDs in compliance with IEEE 802.3af. Usually, a PSE can detect only standard PDs and supply power to them. A PSE can detect non-standard PDs and supply power to them only when the PSE is enabled to detect non-standard PDs.

Follow these steps to enable a PSE to detect non-standard PDs:

To do… Use the command… Remarks

Enter system view

Enable a PSE to detect non-standard PDs

system-view

poe legacy enable pse

pse-id

Configuring a PD Disconnection Detection Mode

—

Required By default, a PSE can detect

standard PDs rather than non-standard PDs.

To detect the PD connection with a PSE, PoE pr ovides two detection modes: AC detection and DC detection. The AC detection mode is energy saving relative to the DC detection mode.

Follow these steps to configure a PD disconnection detection mode:

5-5

Page 97

To do… Use the command… Remarks

Enter system view

Configure a PD disconne ction detection mode

system-view

poe disconnect { ac | dc

}

—

Optional The default PD disconnection

detection mode is ac.

If you change the PD disc onnection detection mode when the device is supplying power to the PDs, the connected PDs will be powered off. Therefore, be ca utious to do so.

Configuring the Maximum PoE Interface Power

The maximum PoE interface power is the maximum power that the PoE interface can provide to a connected PD. If the power required by the PD is larger than the maximum PoE interface power, the PoE interface does not supply power to the PD.

Follow these steps to configure the maximum PoE interface power:

To do… Use the command… Remarks

Enter system view

Enter PoE interface view

Configure the maximum power for the PoE interface

system-view

interface

interface-number

poe max-power

interface-type

max-power

Configuring PoE Power Management

Configuring PoE Interface Power Management

The power supply priority of a PD depends on the priority of the PoE interface. The priority levels of PoE interfaces include critical, high and low in descending order. Power supply to a PD is subject to PoE interface power management policies.

All PSEs implement the same PoE interface power management policies. When a PSE supplies power to a PD,

—

Optional 30000 milliwatts by default.

z When the PoE interface power management is not enabled, no power is supplied to a new

PD if the PSE power is overloaded.

5-6

Page 98

z When the PoE interface power management priority policy is enabled, if the PSE power is

overloaded and a new PD is added, the PD with a lower priority is first powered off to guarantee the power supply to the PD with a higher prior ity.

z 19 watts guard band is reserved for each PoE inte rface on the device to pre vent a PD fr om

being powered off because of a sudden increase of the PD power. When the remaining power of the PSE where the PoE interface resides is lower than 19 watts and no prior ity is configured for the PoE interface, the PSE does not supply power to a new PD; when the remaining power of the PSE where the PoE inter face resides is lower than 19 watts, but priority is configured for the PoE interface, the interface with a higher priority can pree mpt the power of the interface with a lower priority to ensure the normal working of th e higher priority interface.

z If the sudden increase of the power of a connected PD results in PSE power overload,

power supply to the PD on the PoE interface with a lower priority is stopped to ensure the power supply to the PD with a higher priority.

If the guaranteed remaining PSE power (the maximum PSE power minus the ma ximum power allocated to the critical PoE interface, regardless of whether PoE is enabled for the PoE interface) is lower than the maximum power of the PoE i nterface, you fail to set the p riority of the PoE interface to critical. Otherwise, you can succeed in setting the priority of the PoE interface to critical, and this PoE interface preempts the power of other PoE interfaces with a lower priority. In the latter case, the PoE interfaces whose power is preempted are powered off, but their configurations remain unchanged. When you change the priority of a PoE interface from critical to a lower level, the PDs that connect to other PoE inter faces have an opportunity of being powered.

Configuration prerequisites

Enable PoE for PoE interfaces.

Configuration procedure

Follow these steps to configure PoE interface power management:

To do… Use th e command… Remarks

Enter system view

Configure PoE interface power management priority policy

system-view

poe pd-policy priority

—

Required Not configured by default.

Enter PoE interface view

Configure the p ower supp ly priority for a PoE interf ace

interface

interface-number

poe priority

interface-type

critical | high

{

5-7

}

—

Optional

low

by default.

low

Page 99

Configuring the PoE Monitoring Function

When the PoE monitoring function is enabled, the system monitors the parameter values related to PoE power supply, PSE, PD, and device temperature in real time. When a specific value exceeds the limited range, the system automatically takes some measures to protect itself.

Configuring PSE Power Monitoring

The system sends a trap message when the percentage of power utilization exceeds the alarm threshold. If the percentage of the power utilization always keeps above the alarm thr eshold, the system does not send any trap message. When the percentage of the power utilization drops below the alarm threshold, the system sends a trap message again.

Follow these steps to configure a power alarm threshold for the PSE:

To do… Use the command… Remarks

Enter system view

Configure a power alarm threshold for the PSE

system-view

poe utilization-threshold

utilization-thresho ld-valu e pse-id

pse

—

Optional 80% by default.

Monitoring PD

When a PSE starts or stops supplying power to a PD, the system sends a trap message.

Configuring PoE Interface Through PoE Profile

To configure a PoE interface, you :

z Configure it at the CLI. This mode is applicable to a single PoE interface . z Use a PoE profile, and apply the PoE profile to the specified PoE interfaces. This mode is

applicable to multiple PoE interfaces.

A PoE profile is a collection of configurations that contains multiple PoE features. On large-scale networks, you can apply a PoE profile to multiple PoE inter faces, and thus these interfaces have the same PoE features. If the PoE inter face that connects to a PD changes to another one, you just apply the PoE profile applied on the originally connected interfa ce to the currently connected interface instead of reconfiguring the fe atures defined in the PoE profile one by one, thus simplifying the PoE configurations.

The device supports multiple PoE profiles. You can define PoE configurations based on each PD, save the configurations for different PDs into different PoE profiles, and apply the PoE profiles to the access interfaces of PDs accordingly.

5-8

Page 100

Configuring PoE Profile

Follow these steps to configure a PoE profile:

To do… Use the command… Remarks

Enter system view

Create a PoE profile, and enter PoE profile view

Enable PoE for the PoE interface

Configure the maximum power for the PoE interface

Configure PoE power supply mode for the PoE interface

Configure power supply priority for the PoE interface

system-view

poe-profile

poe enable

poe max-power

poe mode signal

poe priority

profile-name [ index ]

critical

{

max-power

high

low }

—

Required

Required Disabled by default.

Optional 15400 milliwatts by

default.

Optional

signal

(power over signal cables) by default.

Optional

low

by default.

z If a PoE profile is applied, it cannot be deleted or modified before you cancel its application. z The poe max-power max-power and poe priority { crit ical | high | low } commands must

be configured in the same way, that is, either at the CLI or through a PoE profile.

z A PoE parameter for a PoE interface must be configured , modified and delete d in only one

way. If a parameter configured in a way (for example, at the CLI) is then configured in the other way (for example, through PoE profile), the latter configuration fails and the original one is still effective. To make the latter configuration effective, you must cancel the original one first.

Applying PoE Profile

A PoE profile can be applied in either system view or interface view. If you apply a PoE profile to a PoE interface in both views, the latter application takes effect. To apply a PoE profile to multiple PoE interfaces, applying it in system view is more efficient.

Follow these steps to apply the PoE profile in system view:

5-9

H3C S5820X Series, S5800 Series Configuration Manual

Preface

Audience

Document Organization

Conventions

Command conventions

Symbols

About the H3C S5800&S5820X Documentation Set

Obtaining Documentation

Documentation Feedback

Table of Contents

1 System Maintenance and Debugging

Ping

Introduction

Configuring Ping

Ping Configuration Example

Network requirements

Configuration procedure

Tracert

Introduction

Configuring Tracert

Configuration prerequisites

Tracert configuration

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 DLSw Test

Configuration prerequisites

Configuring a DLSw test

Configuring the Collaboration Function

Configuring Trap Delivery

Configuration prerequisites

Configuring trap delivery

Configuring the NQA Statistics Function

Configuring the History Records Saving Function